All of lore.kernel.org
 help / color / mirror / Atom feed
From: Krish Sadhukhan <krish.sadhukhan@oracle.com>
To: Paolo Bonzini <pbonzini@redhat.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: Fri, 28 Aug 2020 18:39:01 -0700	[thread overview]
Message-ID: <c36d4ccb-95f1-5fbb-9973-6977145a9d1f@oracle.com> (raw)
In-Reply-To: <605458bd-b4a5-69ca-99e1-3494f5a67d09@oracle.com>


On 8/18/20 11:25 AM, Krish Sadhukhan wrote:
>
> On 8/17/20 11:38 PM, Paolo Bonzini wrote:
>> 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?
>
>
> Yes, I am working on it. I need to complete some more investigation.


I have sent out a patch for testing the non-MBZ reserved bits in long mode.

I haven't been able to find a reliable way to test the non-MBZ reserved 
bits in legacy (PAE and non-PAE) modes.  In long mode if I set any MBZ 
bit and an in valid NPT entry, I get VMEXIT_INVALID before VMEXIT_NPF.  
But I am not sure if this same method of testing is working when a 
non-MBZ reserved bit is set. It seems that consistency checking is not 
enforced on these low-order reserved bits. My goal is to get past the 
consistency checking phase and then trigger a VMEXIT_NPF during 
translation of guest pages in NPT.  I created a 3-level page table for 
legacy PAE mode (as per APM) and tried VMRUN with a  non-MBZ reserved 
bit set, I am getting VMEXIT_NPF but the EXITINFO1 field contains the 
nested guest's CR3. So I am not entirely sure if I have gotten past the 
consistency checking phase.

If there's a better way to test these bits, please let me know.

>>
>> Thanks,
>>
>> Paolo
>>

  reply	other threads:[~2020-08-29  1:39 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
2020-08-18 18:25                     ` Krish Sadhukhan
2020-08-29  1:39                       ` Krish Sadhukhan [this message]
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=c36d4ccb-95f1-5fbb-9973-6977145a9d1f@oracle.com \
    --to=krish.sadhukhan@oracle.com \
    --cc=jmattson@google.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 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.