public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Krish Sadhukhan <krish.sadhukhan@oracle.com>
To: Nadav Amit <namit@vmware.com>, Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org
Subject: Re: [kvm-unit-tests PATCH] x86: svm: low CR3 bits are not MBZ
Date: Mon, 13 Jul 2020 16:06:01 -0700	[thread overview]
Message-ID: <ce87fd51-8e27-e5ff-3a90-06cddbf47636@oracle.com> (raw)
In-Reply-To: <20200713043908.39605-1-namit@vmware.com>


On 7/12/20 9:39 PM, Nadav Amit wrote:
> The low CR3 bits are reserved but not MBZ according to tha APM. The
> tests should therefore not check that they cause failed VM-entry. Tests
> on bare-metal show they do not.
>
> Signed-off-by: Nadav Amit <namit@vmware.com>
> ---
>   x86/svm.h       |  4 +---
>   x86/svm_tests.c | 26 +-------------------------
>   2 files changed, 2 insertions(+), 28 deletions(-)
>
> diff --git a/x86/svm.h b/x86/svm.h
> index f8e7429..15e0f18 100644
> --- a/x86/svm.h
> +++ b/x86/svm.h
> @@ -325,9 +325,7 @@ struct __attribute__ ((__packed__)) vmcb {
>   #define SVM_CR0_SELECTIVE_MASK (X86_CR0_TS | X86_CR0_MP)
>   
>   #define	SVM_CR0_RESERVED_MASK			0xffffffff00000000U
> -#define	SVM_CR3_LEGACY_RESERVED_MASK		0xfe7U
> -#define	SVM_CR3_LEGACY_PAE_RESERVED_MASK	0x7U
> -#define	SVM_CR3_LONG_RESERVED_MASK		0xfff0000000000fe7U
> +#define	SVM_CR3_LONG_RESERVED_MASK		0xfff0000000000000U
>   #define	SVM_CR4_LEGACY_RESERVED_MASK		0xff88f000U
>   #define	SVM_CR4_RESERVED_MASK			0xffffffffff88f000U
>   #define	SVM_DR6_RESERVED_MASK			0xffffffffffff1ff0U
> diff --git a/x86/svm_tests.c b/x86/svm_tests.c
> index 3b0d019..1908c7c 100644
> --- a/x86/svm_tests.c
> +++ b/x86/svm_tests.c
> @@ -2007,38 +2007,14 @@ static void test_cr3(void)
>   {
>   	/*
>   	 * CR3 MBZ bits based on different modes:
> -	 *   [2:0]		    - legacy PAE
> -	 *   [2:0], [11:5]	    - legacy non-PAE
> -	 *   [2:0], [11:5], [63:52] - long mode
> +	 *   [63:52] - long mode
>   	 */
>   	u64 cr3_saved = vmcb->save.cr3;
> -	u64 cr4_saved = vmcb->save.cr4;
> -	u64 cr4 = cr4_saved;
> -	u64 efer_saved = vmcb->save.efer;
> -	u64 efer = efer_saved;
>   
> -	efer &= ~EFER_LME;
> -	vmcb->save.efer = efer;
> -	cr4 |= X86_CR4_PAE;
> -	vmcb->save.cr4 = cr4;
> -	SVM_TEST_CR_RESERVED_BITS(0, 2, 1, 3, cr3_saved,
> -	    SVM_CR3_LEGACY_PAE_RESERVED_MASK);
> -
> -	cr4 = cr4_saved & ~X86_CR4_PAE;
> -	vmcb->save.cr4 = cr4;
> -	SVM_TEST_CR_RESERVED_BITS(0, 11, 1, 3, cr3_saved,
> -	    SVM_CR3_LEGACY_RESERVED_MASK);
> -
> -	cr4 |= X86_CR4_PAE;
> -	vmcb->save.cr4 = cr4;
> -	efer |= EFER_LME;
> -	vmcb->save.efer = efer;
>   	SVM_TEST_CR_RESERVED_BITS(0, 63, 1, 3, cr3_saved,
>   	    SVM_CR3_LONG_RESERVED_MASK);
>   
> -	vmcb->save.cr4 = cr4_saved;
>   	vmcb->save.cr3 = cr3_saved;
> -	vmcb->save.efer = efer_saved;
>   }
>   
>   static void test_cr4(void)

APM says,

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

If processor allows these bits to be left non-zero, "should be cleared 
to 0" means it's not mandatory then. I am wondering what this "should 
be" actually means :-) !


  reply	other threads:[~2020-07-13 23:06 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-13  4:39 [kvm-unit-tests PATCH] x86: svm: low CR3 bits are not MBZ Nadav Amit
2020-07-13 23:06 ` Krish Sadhukhan [this message]
2020-07-13 23:11   ` Nadav Amit
2020-07-13 23:17     ` Krish Sadhukhan
2020-07-13 23:30       ` Nadav Amit
2020-07-15 22:21         ` Krish Sadhukhan
2020-07-15 22:27           ` Nadav Amit
2020-07-15 22:39             ` Krish Sadhukhan
2020-07-15 22:51               ` Nadav Amit
2020-07-15 23:12               ` Jim Mattson
2020-08-04 23:13                 ` Krish Sadhukhan
2020-08-18  6:38                   ` Paolo Bonzini
2020-08-18 18:25                     ` Krish Sadhukhan
2020-08-29  1:39                       ` Krish Sadhukhan
2020-07-28 21:27           ` Paolo Bonzini
2020-07-28 21:27 ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ce87fd51-8e27-e5ff-3a90-06cddbf47636@oracle.com \
    --to=krish.sadhukhan@oracle.com \
    --cc=kvm@vger.kernel.org \
    --cc=namit@vmware.com \
    --cc=pbonzini@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox