On Sat, Jun 6, 2026 at 8:12 AM Jim Mattson <jmattson@google.com> wrote:
>
> On Fri, May 29, 2026 at 3:47 PM Sean Christopherson <seanjc@google.com> wrote:
> >
> > On Wed, 27 May 2026 10:43:42 -0700, Jim Mattson wrote:
> > > AMD's "disable CPUID in usermode" feature is analogous to Intel's "CPUID
> > > faulting" feature, but it is advertised and activated differently. The AMD
> > > feature is advertised via CPUID.80000021H:EAX.CpuidUserDis[bit 17] and
> > > activated by setting HWCR.CpuidUserDis[bit 35].
> > >
> > > Add virtualization support for the AMD feature.
> > >
> > > [...]
> >
> > Applied to kvm-x86 misc, thanks!
>
> Oops! You haven't sent a pull request for this series yet, have you?
>
> Our internal Sashiko asks:
>
> > In kvm_set_msr_common(), the MSR_PLATFORM_INFO handler uses cpuid_fault_enabled() to prevent the host from clearing MSR_PLATFORM_INFO_CPUID_FAULT while CPUID faulting is enabled:
> >
> > case MSR_PLATFORM_INFO:
> > if (!msr_info->host_initiated ||
> > (!(data & MSR_PLATFORM_INFO_CPUID_FAULT) &&
> > cpuid_fault_enabled(vcpu)))
> > return 1;
> >
> > If a VMM restores MSR_K7_HWCR before MSR_PLATFORM_INFO during live migration, and the guest had enabled AMD CPUID faulting, won't the write to MSR_PLATFORM_INFO fail if it doesn't have MSR_PLATFORM_INFO_CPUID_FAULT set?
>
> Sadly, I think it's right. Even on AMD systems, MSR_PLATFORM_INFO is
> enumerated by KVM_GET_MSR_INDEX_LIST. It does come before MSR_K7_HWCR
> in that list, but userspace is free to restore the virtual MSRs in any
> order. For any sane AMD-hosted vCPU, MSR_PLATFORM_INFO will be zero.
Never mind. This Sashiko observation was on a backport to a branch
that doesn't have commit 1ded7a57b805 ("KVM: x86: Remove ordering
check b/w MSR_PLATFORM_INFO and MISC_FEATURES_ENABLES"). Everything is
fine at tip.