On Fri, Nov 29, 2024, Adrian Hunter wrote:
> On 27/11/24 16:00, Sean Christopherson wrote:
> > On Fri, Nov 22, 2024, Chao Gao wrote:
> >>> diff --git a/arch/x86/kvm/vmx/tdx.h b/arch/x86/kvm/vmx/tdx.h
> >>> index 48cf0a1abfcc..815ff6bdbc7e 100644
> >>> --- a/arch/x86/kvm/vmx/tdx.h
> >>> +++ b/arch/x86/kvm/vmx/tdx.h
> >>> @@ -29,6 +29,14 @@ struct kvm_tdx {
> >>> u8 nr_tdcs_pages;
> >>> u8 nr_vcpu_tdcx_pages;
> >>>
> >>> + /*
> >>> + * Used on each TD-exit, see tdx_user_return_msr_update_cache().
> >>> + * TSX_CTRL value on TD exit
> >>> + * - set 0 if guest TSX enabled
> >>> + * - preserved if guest TSX disabled
> >>> + */
> >>> + bool tsx_supported;
> >>
> >> Is it possible to drop this boolean and tdparams_tsx_supported()? I think we
> >> can use the guest_can_use() framework instead.
> >
> > Yeah, though that optimized handling will soon come for free[*], and I plan on
> > landing that sooner than TDX, so don't fret too much over this.
> >
> > [*] https://lore.kernel.org/all/20240517173926.965351-1-seanjc@xxxxxxxxxx
>
> guest_can_use() is per-vcpu whereas we are currently using the
> CPUID from TD_PARAMS (as per spec) before there are any VCPU's.
> It is a bit of a disconnect so let's keep tsx_supported for now.
No, as was agreed upon[*], KVM needs to ensure consistency between what KVM sees
as guest CPUID and what is actually enabled/exposed to the guest. If there are
no vCPUs, then there's zero reason to snapshot the value in kvm_tdx. And if there
are vCPUs, then their CPUID info needs to be consistent with respect to TDPARAMS.
- Don't hardcode fixed/required CPUID values in KVM, use available metadata
from TDX Module to reject "bad" guest CPUID (or let the TDX module reject?).
I.e. don't let a guest silently run with a CPUID that diverges from what
userspace provided.
[*] https://lore.kernel.org/all/20240405165844.1018872-1-seanjc@xxxxxxxxxx
