[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v1 1/6] nestedsvm: Fix CR3 MBZ check


  • To: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • From: Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>
  • Date: Tue, 26 May 2026 14:23:35 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zD6lhTUAjdgXqG5782mJEZt1e6GgZGY5iYzec1ILZas=; b=m/LCdzQVKPx1DgENjAofE/bpfOpC3fmI5sSwZwtNNQxzOKdSf6WhazTxNBQfYyOzJoYXI0qEcxmHZRcgnRlX4VJdJFurWq8PDtf32v0HoaUUHOC5e388ozBB6N2IhDTzfkhsKYiejBNZpW4A/nEGLAGiWhE/QKCG4cFInZGZkL228tVWFgOAGJGkn+RyGPrc2OtGXrROp0OHXNkS89Oep1vEznJ51oKYk/w+k7fvaoQA1c6lO7JlLDfd0mFSAJ4mkYPQf4zCgEOVJXxMlZdbdgQWutPx3cps5XXTyLyH+xCAL1Z5GHfJWbUp0sc7Beg+xKj/fYobMkQNbEBB//xf6w==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=A3cNEu31c51lvq4n7llfJsMotiEig3h0OdD+iEdJluiCVeOIBfWCNnaI8kg/AC72DGDxYB1z7AsE1WQze0leV4mI0nARd6yVE/FyqpeBLs/XQmEUmdte02vilFPE+kSleSuyYsNVhGqCJDJsDpTXGBvqIllT/Y3xKXiv+Xi4o9DMyH/Vxukq9ShPfZVrnHkLgwZ1Fpl0ETBDJ4D1R1LzyeZxedUiL/I0F2oDoiXH/PllbQN7f/d8hOSI+ugsO46gIpqRUy3FpyPDn/TvOJRyHvg28ta8XImcCrTa/RyYU5OPFeeGPS3zwhhQHMNSPeTG15jgR2zxS+ERU/9kS+vXzg==
  • Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=citrix.com header.i="@citrix.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck"
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=citrix.com;
  • Cc: Jan Beulich <jbeulich@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Jason Andryuk <jason.andryuk@xxxxxxx>, Teddy Astie <teddy.astie@xxxxxxxxxx>
  • Delivery-date: Tue, 26 May 2026 13:23:54 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 5/26/26 2:01 PM, Andrew Cooper wrote:
On 26/05/2026 1:40 pm, Ross Lagerwall wrote:
The existing code checks for any reserved bit set while the APM only
considers it invalid if an MBZ bit is set. Relax the check to match the
APM and hardware.

Some of the reserved bits were observed to be set running Rocky Linux
10.1 on Xen on Xen.

Fixes: 9a779e4fc161 ("Implement SVM specific part for Nested Virtualization")
Signed-off-by: Ross Lagerwall <ross.lagerwall@xxxxxxxxxx>
---
  xen/arch/x86/hvm/svm/vmcb.c | 6 ++----
  1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/xen/arch/x86/hvm/svm/vmcb.c b/xen/arch/x86/hvm/svm/vmcb.c
index 975a1eaef806..9ada491e57db 100644
--- a/xen/arch/x86/hvm/svm/vmcb.c
+++ b/xen/arch/x86/hvm/svm/vmcb.c
@@ -347,10 +347,8 @@ bool svm_vmcb_isvalid(
          PRINTF("CR0: bits [63:32] are not zero (%#"PRIx64")\n", cr0);
if ( (cr0 & X86_CR0_PG) &&
-         ((cr3 & 7) ||
-          ((!(cr4 & X86_CR4_PAE) || (efer & EFER_LMA)) && (cr3 & 0xfe0)) ||
-          ((efer & EFER_LMA) &&
-           (cr3 >> v->domain->arch.cpuid->extd.maxphysaddr))) )
+         ((efer & EFER_LMA) &&
+           (cr3 >> v->domain->arch.cpuid->extd.maxphysaddr)) )
          PRINTF("CR3: MBZ bits are set (%#"PRIx64")\n", cr3);
valid = hvm_cr4_guest_valid_bits(v->domain);

The APM does say MBZ for VMRUN, but the end result of a VMEntry (virtual
or otherwise) must be a legal CR3 value.

For 5.2.1 CR3 Register (Legacy) and 5.3.2 CR3 (Long), the APM states:

Reserved Bits. Reserved fields should be cleared to 0 by software when
writing CR3.

What's the real behaviour for trying to set a reserved, non-MBZ bit in
CR3?  On Intel it's strictly a #GP, and I really hope it's the same on AMD.

i.e. I really hope this is a documentation error on AMD's behalf, and
not a misfeature we need to support.


An hvm32pae XTF test that does this...

    write_cr3(read_cr3() | 1);
    printk("cr3 is %lx\n", read_cr3());

... succeeds and prints:

    cr3 is 105001

This was similarly observed by the KVM folks in this thread:
https://patchwork.kernel.org/project/kvm/patch/20200713043908.39605-1-namit@xxxxxxxxxx/#23578493

Ross



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.