Re: [PATCH v5 1/4] KVM: TDX: Explicitly set user-return MSRs that *may* be clobbered by the TDX-Module

From: Sean Christopherson

Date: Tue Nov 04 2025 - 12:57:02 EST


On Tue, Nov 04, 2025, Yan Zhao wrote:
> On Tue, Nov 04, 2025 at 04:40:44PM +0800, Xiaoyao Li wrote:
> > On 11/4/2025 3:06 PM, Yan Zhao wrote:
> > > Another nit:
> > > Remove the tdx_user_return_msr_update_cache() in the comment of __tdx_bringup().
> > >
> > > Or could we just invoke tdx_user_return_msr_update_cache() in
> > > tdx_prepare_switch_to_guest()?
> >
> > No. It lacks the WRMSR operation to update the hardware value, which is the
> > key of this patch.
> As [1], I don't think the WRMSR operation to update the hardware value is
> necessary. The value will be updated to guest value soon any way if
> tdh_vp_enter() succeeds, or the hardware value remains to be the host value or
> the default value.

As explained in the original thread:

: > If the MSR's do not get clobbered, does it matter whether or not they get
: > restored.
:
: It matters because KVM needs to know the actual value in hardware. If KVM thinks
: an MSR is 'X', but it's actually 'Y', then KVM could fail to write the correct
: value into hardware when returning to userspace and/or when running a different
: vCPU.

I.e. updating the cache effectively corrupts state if the TDX-Module doesn't
clobber MSRs as expected, i.e. if the current value is preserved in hardware.

> But I think invoking tdx_user_return_msr_update_cache() in
> tdx_prepare_switch_to_guest() is better than in
> tdx_prepare_switch_to_host().
>
> [1] https://lore.kernel.org/kvm/aQhJol0CvT6bNCJQ@xxxxxxxxxxxxxxxxxxxxxxxxx/
>