On Fri, May 29, 2026 at 3:47 PM Sean Christopherson <[email protected]> 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.
