From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pg1-f201.google.com (mail-pg1-f201.google.com [209.85.215.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4163F330339 for ; Tue, 10 Feb 2026 20:02:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.215.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770753774; cv=none; b=DyH3uq5A7dr6qEH6so3IN57vIuRuGUCPB57cN10qM4gegCB+hcM+634Kr0ZgG+2t1mAz3XgOpCKb+CciT/PahQCECfRUIbaa9dno9wlRu4nrq1+bBSRmC2HhkN8dEltN3o6pCRlr0HPihVi1aR4Ax1FqiVJXjVj0+p8I3Kr4G5A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770753774; c=relaxed/simple; bh=1SYXPdM3M3vfEgCTCDusnEPl7C4uxKeZQM4ZhwqUDoo=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=TPHDu22flz1ezB+J/X1AB9XAQtqJbfXyFB3cPNrwdzMYHfhu6iAEi+xhEG4LU05bS9qYWQec/xXjqrP0SDwv/AGbcvOB1y2OZw4SheCxiiqtfeKkQn4o35dtrP/ewbGK2s50iSQudqfcSLtN+yhfKDbh3YqlMVZN7S/Kx+ROynw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=iChO9uWa; arc=none smtp.client-ip=209.85.215.201 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--seanjc.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="iChO9uWa" Received: by mail-pg1-f201.google.com with SMTP id 41be03b00d2f7-b62da7602a0so3180064a12.2 for ; Tue, 10 Feb 2026 12:02:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1770753773; x=1771358573; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=AMxnwFoC86g7Xm0uspYe7BKHCLo0vPLy6IdXieZNUcM=; b=iChO9uWa5GoSdLcSwnVdiqXRHhqv3MDMRr3MaKBqhworME+Hf8ROjB8sbs3ZrIutiw zgvJtr2dRXRYprU9pc75gknOdql1Yb46wnjhyF+n4aGOqJ51/9lC8Y3NajuNwZVTGwDo xDeZvf3zTQQZgUkNIGjxlvHSeUaoJxPEBlHj+E2m4QbZsPDrkwma2bN1tseAQ3aYdRHb OLxf7w13okj5q6+hHQeRiVXJfBY1Mz/qzideFU/bCWnTKUS2boMUOUKrwtgcBMoDLYFI 6BJKxRMDl5KQKq/R84XfB/DX/nMjx1jA5D9tpqcu8CKoh8o8IAt0YRsaxAFyZURpVOEj F1PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770753773; x=1771358573; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=AMxnwFoC86g7Xm0uspYe7BKHCLo0vPLy6IdXieZNUcM=; b=hOFUk3ibL7KGXribujqHT6sng07pUwkaY3VQ3FMzUAzfd9MNmGrqSbpAwFdW63JXeI y3dypBrnXNjQqrl/VNRyBjSENg7Di5WE/C2psimDzfJ/gD0hYoveDavLWP5+RDxu6MfD h++Up3iQg+2x6ZbqmpHyMbee2jPnRG42tDXQcYeWSiZy6H/AA2MNe/ZANegdCXg0o24N hlpHL7q/ck8t/jcT4d6O+kphQb7sqmCJfpb9J0wi98oLEC10eBETGMTv7RG5VX3CHfHR muIaGZxbGzWLa0tDdGIXVBUApzfBxK8xYImueqBbGvYPrs+Gi2oMdduK6oo+gE5g6uq7 AzUg== X-Forwarded-Encrypted: i=1; AJvYcCVQwgpnSKUg3d3rMgng+3peim0UUFUiBwdhCsO+I6l/9//vOv6G3i1obvJj50Ksg8sFM//cPi558S+lHOs=@vger.kernel.org X-Gm-Message-State: AOJu0YzoOXBd6pymeX8FyjvDHEaP9jkxR3xXDVnGHcmf6NR4BddFBbtv oqCWWvuIFh9+wLBNog1/+atl1d7ZdzzbhPd2l0WrqlGqXvVK5hOFHCClzFUMWmC3OhIRyOiTIMa SwxYhnA== X-Received: from pghg12.prod.google.com ([2002:a63:e60c:0:b0:c6d:ce5b:b37f]) (user=seanjc job=prod-delivery.src-stubby-dispatcher) by 2002:a05:6a21:a42:b0:38f:86c0:44c with SMTP id adf61e73a8af0-3942e6d5ab5mr282050637.73.1770753772651; Tue, 10 Feb 2026 12:02:52 -0800 (PST) Date: Tue, 10 Feb 2026 12:02:51 -0800 In-Reply-To: <65765e72-fce0-48ed-ab95-af2736a562cd@163.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260209041305.64906-1-zhiquan_li@163.com> <20260209041305.64906-6-zhiquan_li@163.com> <65765e72-fce0-48ed-ab95-af2736a562cd@163.com> Message-ID: Subject: Re: [PATCH RESEND 5/5] KVM: x86: selftests: Fix write MSR_TSC_AUX reserved bits test failure on Hygon From: Sean Christopherson To: Zhiquan Li Cc: pbonzini@redhat.com, shuah@kernel.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 10, 2026, Zhiquan Li wrote: >=20 > 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 Hyg= on > >> 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. > >=20 > > 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_rd= msr_val() > > needs to be changed? > >=20 >=20 > Currently the conditions cannot cover the case that the host *only* suppo= rts > RDTSCP but not support RDPID, like Hygon CPU. Let me give more details f= or this > test failure. >=20 > 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 feat= ure2) > is supported. Therefore, the preceding condition =E2=80=9C!this_cpu_has(= msr->feature)=E2=80=9D > here is true and then the test run into the first branch. Because the fe= ature2 > RDTSCP is supported, writing reserved bits (that is, guest_test_reserved_= val()) > will succeed, unfortunately, the expectation for the first branch is #GP. >=20 > The check to fixup_rdmsr_val() is too late, since the preceding condition > already leads to the test run into the wrong branch. >=20 > The test can be passed on AMD CPU is because RDPID is usually supported b= y 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 b= e > reproduced on some old AMD CPUs which only support RDTSCP, it=E2=80=99s h= ard to find > such an old machine to confirm it, but I suppose this case can be covered= by > slight changes based on this patch. >=20 > Intel CPU no such failure, because writing MSR_TSC_AUX reserved bits resu= lts 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/se= lftests/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 =3D=3D fixup_rdmsr_val(msr->index, msr->rsvd_val)= ) { u8 vec =3D wrmsr_safe(msr->index, msr->rsvd_val);