On Wed, 2024-12-04 at 23:33 +0800, Xiaoyao Li wrote:
> >
>
> There were discussion[1] on whether KVM to gatekeep the
> configurable/supported CPUIDs for TDX. I stand by Sean that KVM needs to
> do so.
>
> Regarding KVM opt in the new feature, KVM gatekeeps the CPUID bit that
> can be set by userspace is exactly the behavior of opt-in. i.e., for a
> given KVM, it only allows a CPUID set {S} to be configured by userspace,
> if new TDX module supports new feature X, it needs KVM to opt-in X by
> adding X to {S} so that X is allowed to be configured by userspace.
>
> Besides, I find current interface between KVM and userspace lacks the
> ability to tell userspace what bits are not supported by KVM.
> KVM_TDX_CAPABILITIES.cpuid doesn't work because it represents the
> configurable CPUIDs, not supported CPUIDs (I think we might rename it to
> configurable_cpuid to better reflect its meaning). So userspace has to
> hardcode that TSX and WAITPKG is not support itself.
>
> [1] https://lore.kernel.org/all/ZuM12EFbOXmpHHVQ@xxxxxxxxxx/
I mean, this is kind of a good example for why we might want to go back to
filtering CPUID bits. It kind of depends on how KVM wants to treat the TDX
module. Hostile like userspace, or more trusting. KVM maintaining code to let
the TDX module evolve unsafely would be unfortunate though.
If we keep the current approach, it probably would be educational to highlight
this example to the TDX module team. "Don't do this or you will have a bug on
your side".
