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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cc3a968d-c581-4784-b69b-b887d3b90a94@intel.com>
Date: Thu, 21 Mar 2024 10:00:24 +1300
From: "Huang, Kai" <kai.huang@...el.com>
To: Dave Hansen <dave.hansen@...el.com>, "seanjc@...gle.com"
	<seanjc@...gle.com>
CC: "Zhang, Tina" <tina.zhang@...el.com>, "Edgecombe, Rick P"
	<rick.p.edgecombe@...el.com>, "Yuan, Hang" <hang.yuan@...el.com>,
	"x86@...nel.org" <x86@...nel.org>, "Chen, Bo2" <chen.bo@...el.com>,
	"sagis@...gle.com" <sagis@...gle.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "isaku.yamahata@...il.com"
	<isaku.yamahata@...il.com>, "Aktas, Erdem" <erdemaktas@...gle.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>, "pbonzini@...hat.com"
	<pbonzini@...hat.com>, "Yamahata, Isaku" <isaku.yamahata@...el.com>
Subject: Re: [PATCH v19 007/130] x86/virt/tdx: Export SEAMCALL functions



On 21/03/2024 4:07 am, Dave Hansen wrote:
> On 3/20/24 05:09, Huang, Kai wrote:
>> I can try to do if you guys believe this should be done, and should be done
>> earlier than later, but I am not sure _ANY_ optimization around SEAMCALL will
>> have meaningful performance improvement.
> 
> I don't think Sean had performance concerns.
> 
> I think he was having a justifiably violent reaction to how much more
> complicated the generated code is to do a SEAMCALL versus a good ol' KVM
> hypercall.

Ah, I automatically linked "generating better code" to "in order to have 
better performance".  My bad.

> 
> "Complicated" in this case means lots more instructions and control
> flow.  That's slower, sure, but the main impact is that when you go to
> debug it, it's *MUCH* harder to debug the SEAMCALL entry assembly than a
> KVM hypercall.

[...]

> 
> My takeaway from this, though, is that we are relying on the compiler
> for a *LOT*.  There are also so many levels in the helpers that it's
> hard to avoid silly things like two _separate_ retry loops.
> 
> We should probably be looking at the generated code a _bit_ more often
> than never, and it's OK to tinker a _bit_ to make things out-of-line or
> make sure that the compiler optimizes everything that we think that it
> should.

Yeah, agreed.

> 
> Also remember that there are very fun tools out there that can make this
> much easier than recompiling the kernel a billion times:
> 
> 	https://godbolt.org/z/8ooE4d465

Ah, this is useful.  Thanks for sharing :-)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ