Re: [PATCH 21/25] KVM: x86: Introduce KVM_TDX_GET_CPUID

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 26.08.24 г. 20:46 ч., Edgecombe, Rick P wrote:
On Mon, 2024-08-26 at 17:09 +0300, Nikolay Borisov wrote:
+               /*
+                * Work around missing support on old TDX modules, fetch
+                * guest maxpa from gfn_direct_bits.
+                */


Define old TDX module? I believe the minimum supported TDX version is
1.5 as EMR are the first public CPUs to support this, no? Module 1.0 was
used for private previews etc? Can this be dropped altogether?

Well, today "old" means all released TDX modules. This is a new feature under
development, that KVM maintainers were ok working around being missing for now.
The comment should be improved.

See here for discussion of the design and purpose of the feature:
https://lore.kernel.org/kvm/f9f1da5dc94ad6b776490008dceee5963b451cda.camel@xxxxxxxxx/

It is
much easier to mandate the minimum supported version now when nothing
has been merged. Furthermore, in some of the earlier patches it's
specifically required that the TDX module support NO_RBP_MOD which
became available in 1.5, which already dictates that the minimum version
we should care about is 1.5.

There is some checking in Kai's TDX module init patches:
https://lore.kernel.org/kvm/d307d82a52ef604cfff8c7745ad8613d3ddfa0c8.1721186590.git.kai.huang@xxxxxxxxx/

Yes, that's why I mentioned this. I have already reviewed those patches :)


But beyond checking for supported features, there are also bug fixes that can
affect usability. In the NO_RBP_MOD case we need a specific recent TDX module in
order to remove the RBP workaround patches.

My point was that if having the NO_RPB_MOD implied that the CPUID 0x8000000 configuration capability is also there (not that there is a direct connection between the too but it seems the TDX module isn't being updated that often, I might be wrong of course!), there is no point in having the workaround as NO_RPB_MOD is the minimum required version.

Anyway, this was an assumption on my part.


We could just check for a specific TDX module version instead, but I'm not sure
whether KVM would want to get into the game of picking preferred TDX module
versions. I guess in the case of any bugs that affect the host it will have to
do it though. So we will have to add a version check before live KVM support
lands upstream.

Hmm, thanks for the question.




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux