linux-kernel - Re: [PATCH] x86/tdx: Enhance code generation for TDCALL and SEAMCALL wrappers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <8e3146250f31db92fa42a29a892858c9ec33aeab.camel@intel.com>
Date: Wed, 28 Aug 2024 13:34:54 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "kirill.shutemov@...ux.intel.com" <kirill.shutemov@...ux.intel.com>,
	"seanjc@...gle.com" <seanjc@...gle.com>
CC: "linux-coco@...ts.linux.dev" <linux-coco@...ts.linux.dev>,
	"jpoimboe@...nel.org" <jpoimboe@...nel.org>, "Hansen, Dave"
	<dave.hansen@...el.com>, "dave.hansen@...ux.intel.com"
	<dave.hansen@...ux.intel.com>, "haiyangz@...rosoft.com"
	<haiyangz@...rosoft.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "mingo@...hat.com" <mingo@...hat.com>,
	"pbonzini@...hat.com" <pbonzini@...hat.com>, "kys@...rosoft.com"
	<kys@...rosoft.com>, "Cui, Dexuan" <decui@...rosoft.com>,
	"tglx@...utronix.de" <tglx@...utronix.de>, "hpa@...or.com" <hpa@...or.com>,
	"peterz@...radead.org" <peterz@...radead.org>, "wei.liu@...nel.org"
	<wei.liu@...nel.org>, "bp@...en8.de" <bp@...en8.de>,
	"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
	"x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH] x86/tdx: Enhance code generation for TDCALL and SEAMCALL
 wrappers

On Tue, 2024-06-04 at 12:34 -0700, Sean Christopherson wrote:
> 
> If we're willing to suffer a few gnarly macros, I think we get a satisfactory
> mix
> of standardized arguments and explicit operands, and generate vastly better
> code.

Hi Sean,

We are kind of stuck on improving the code generation for the existing calls.
x86 maintainers don't seem to be enthusiastic about tackling this urgently and
there is not consensus on how to weigh source code clarity with code generation
sanity [0]. I think we are going to table it for the time being, unless it's a
showstopper for you.

An option is still to have a separate helper infrastructure for KVM's calls, but
as discussed originally this duplicates code.

Rick

[0] https://lore.kernel.org/all/3a210286-7d0f-4404-ad79-c8eab1514381@intel.com/