All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Krish Sadhukhan <krish.sadhukhan@oracle.com>,
	Jim Mattson <jmattson@google.com>
Cc: Nadav Amit <namit@vmware.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: [kvm-unit-tests PATCH] x86: svm: low CR3 bits are not MBZ
Date: Tue, 18 Aug 2020 08:38:39 +0200	[thread overview]
Message-ID: <02cab471-0023-08f9-1722-2d42a3686a50@redhat.com> (raw)
In-Reply-To: <4bb7c975-70dd-0247-3824-973229f3337b@oracle.com>

On 05/08/20 01:13, Krish Sadhukhan wrote:
>>
> 
> I did some experiments on the processor behavior on an Epyc 2 system via
> KVM:
> 
>    1. MBZ bits:  VMRUN passes even if these bits are set to 1 and
> guest is exiting with exit code of            SVM_EXIT_VMMCALL.
> According to the APM, this settting should constitute an invalid guest
> state and hence I should get and exit code of SVM_EXIT_ERR. There's no
> KVM check in place for these CR3 bits, so the check is all done in
> hardware.
> 
>    2. non-MBZ reserved bits:  Based on Nadav Amit's suggestion, I set
> the 'not present' bit in an upper level NPT in order to trigger an NPF
> and I did get an exit code of SVM_EXIT_NPF when I set any of these bits.
> I am hoping that the processor has done the consistency check before it
> tripped on NPF and not the other way around, so that our test is useful :
> 
>     In PAE-legacy and non-PAE-legacy modes, the guest doesn't exit
> with SVM_EXIT_VMMCALL when these bits are set to 0. I am not sure if I
> am missing any special setting for the PAE-legacy and non-PAE-legacy
> modes. In long-mode, however, the processor seems to behave as per APM,
> i.e., guest exits with SVM_EXIT_VMMCALL when these bits are set to 0.

Are you going to send patches for this?

Thanks,

Paolo


  reply	other threads:[~2020-08-18  6:38 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
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 [this message]
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=02cab471-0023-08f9-1722-2d42a3686a50@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=jmattson@google.com \
    --cc=krish.sadhukhan@oracle.com \
    --cc=kvm@vger.kernel.org \
    --cc=namit@vmware.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.