linux-kernel - Re: [PATCH RESEND 5/5] KVM: x86: selftests: Fix write MSR_TSC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aYuO673vMcZ-DJ7m@google.com>
Date: Tue, 10 Feb 2026 12:02:51 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Zhiquan Li <zhiquan_li@....com>
Cc: pbonzini@...hat.com, shuah@...nel.org, kvm@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH RESEND 5/5] KVM: x86: selftests: Fix write MSR_TSC_AUX
 reserved bits test failure on Hygon

On Tue, Feb 10, 2026, Zhiquan Li wrote:
> 
> On 2/10/26 00:41, Sean Christopherson wrote:
> > On Mon, Feb 09, 2026, Zhiquan Li wrote:
> >> Therefore, the expectation of writing MSR_TSC_AUX reserved bits on Hygon
> >> CPUs should be:
> >> 1) either RDTSCP or RDPID is supported case, and both are supported
> >>    case, expect success and a truncated value, not #GP.
> >> 2) neither RDTSCP nor RDPID is supported, expect #GP.
> > 
> > That's how Intel and AMD behave as well.  I don't understand why there needs to
> > be a big pile of special case code for Hygon.  Presumably just fixup_rdmsr_val()
> > needs to be changed?
> > 
> 
> Currently the conditions cannot cover the case that the host *only* supports
> RDTSCP but not support RDPID, like Hygon CPU.  Let me give more details for this
> test failure.
> 
> When testing the case MSR_TEST2(MSR_TSC_AUX, 0x12345678, u64_val, RDPID,
> RDTSCP), the cupid bit for RDPID (as feature) of vCPU 0 and vCPU1 will be
> removed because host is not supported it, but please note RDTSCP (as feature2)
> is supported.  Therefore, the preceding condition “!this_cpu_has(msr->feature)”
> here is true and then the test run into the first branch.  Because the feature2
> RDTSCP is supported, writing reserved bits (that is, guest_test_reserved_val())
> will succeed, unfortunately, the expectation for the first branch is #GP.
> 
> The check to fixup_rdmsr_val() is too late, since the preceding condition
> already leads to the test run into the wrong branch.
> 
> The test can be passed on AMD CPU is because RDPID is usually supported by host,
> the cupid bit for RDPID of vCPU 0 and vCPU1 can be kept, then fixup_rdmsr_val()
> can drive it to the second branch.  Theoretically, the failure also can be
> reproduced on some old AMD CPUs which only support RDTSCP, it’s hard to find
> such an old machine to confirm it, but I suppose this case can be covered by
> slight changes based on this patch.
> 
> Intel CPU no such failure, because writing MSR_TSC_AUX reserved bits results in
> #GP is expected behavior.

Gah, I think I tested -rdpid and -rdtscp in a VM on Intel, but not AMD.  I think
the fix is just this:

diff --git a/tools/testing/selftests/kvm/x86/msrs_test.c b/tools/testing/selftests/kvm/x86/msrs_test.c
index 40d918aedce6..ebd900e713c1 100644
--- a/tools/testing/selftests/kvm/x86/msrs_test.c
+++ b/tools/testing/selftests/kvm/x86/msrs_test.c
@@ -175,7 +175,7 @@ void guest_test_reserved_val(const struct kvm_msr *msr)
         * If the CPU will truncate the written value (e.g. SYSENTER on AMD),
         * expect success and a truncated value, not #GP.
         */
-       if (!this_cpu_has(msr->feature) ||
+       if ((!this_cpu_has(msr->feature) && !this_cpu_has(msr->feature2)) ||
            msr->rsvd_val == fixup_rdmsr_val(msr->index, msr->rsvd_val)) {
                u8 vec = wrmsr_safe(msr->index, msr->rsvd_val);