public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Brijesh Singh <brijesh.singh@amd.com>
To: Paolo Bonzini <pbonzini@redhat.com>, kvm@vger.kernel.org
Cc: brijesh.singh@amd.com, thomas.lendacky@amd.com,
	rkrcmar@redhat.com, joro@8bytes.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, mingo@redhat.com, hpa@zytor.com,
	tglx@linutronix.de, bp@suse.de
Subject: Re: [PATCH v2 1/3] kvm: svm: Add support for additional SVM NPF error codes
Date: Mon, 31 Jul 2017 11:54:42 -0500	[thread overview]
Message-ID: <d7266e60-3bcc-946d-4325-dfd1126c9fc4@amd.com> (raw)
In-Reply-To: <21b9f4db-f929-80f6-6ad2-6fa3b77f82c0@redhat.com>


On 07/31/2017 10:44 AM, Paolo Bonzini wrote:
> On 31/07/2017 15:30, Brijesh Singh wrote:
>> Hi Paolo,
>>
>> On 07/27/2017 11:27 AM, Paolo Bonzini wrote:
>>> On 23/11/2016 18:01, Brijesh Singh wrote:
>>>>    +    /*
>>>> +     * Before emulating the instruction, check if the error code
>>>> +     * was due to a RO violation while translating the guest page.
>>>> +     * This can occur when using nested virtualization with nested
>>>> +     * paging in both guests. If true, we simply unprotect the page
>>>> +     * and resume the guest.
>>>> +     *
>>>> +     * Note: AMD only (since it supports the PFERR_GUEST_PAGE_MASK used
>>>> +     *       in PFERR_NEXT_GUEST_PAGE)
>>>> +     */
>>>> +    if (error_code == PFERR_NESTED_GUEST_PAGE) {
>>>> +        kvm_mmu_unprotect_page(vcpu->kvm, gpa_to_gfn(cr2));
>>>> +        return 1;
>>>> +    }
>>>
>>>
>>> What happens if L1 is mapping some memory that is read only in L0?  That
>>> is, the L1 nested page tables make it read-write, but the L0 shadow
>>> nested page tables make it read-only.
>>>
>>> Accessing it would cause an NPF, and then my guess is that the L1 guest
>>> would loop on the failing instruction instead of just dropping the write.
>>>
>>
>>
>> Not sure if I am able to follow your use case. Could you please explain me
>> in bit detail.
>>
>> The purpose of the code above was really for when we resume from the L2 guest
>> back to the L1 guest. The L1 page tables are marked RO when in the L2 guest
>> (for shadow paging) as I recall, so when we come back to the L1 guest, it can
>> get a fault since its page tables are not marked writeable at L0 as they
>> need to be.
> 
> There can be different cases where an L0->L2 shadow nested page table is
> marked read only, in particular when a page is read only in L1's nested
> page tables.  If such a page is accessed by L2 while walking page tables
> it will cause a nested page fault (page table walks are write accesses).
>   However, after kvm_mmu_unprotect_page you will get another page fault,
> and again in an endless stream.
> 
> Instead, emulation would have caused a nested page fault vmexit, I think.
> 

If possible could you please give me some pointer on how to create this use
case so that we can get definitive answer.

Looking at the code path is giving me indication that the new code
(the kvm_mmu_unprotect_page call) only happens if vcpu->arch.mmu_page_fault()
returns an indication that the instruction should be emulated. I would not expect
that to be the case scenario you described above since L1 making a page read-only
(this is a page table for L2) is an error and should result in #NPF being injected
into L1. It's bit hard for me to visualize the code flow and figure out exactly
how that would happen, but I just tried booting nested virtualization and it seem
to be working okay.

Is there a kvm-unit-test which I can run to trigger this scenario ? thanks

-Brijesh

  reply	other threads:[~2017-07-31 16:54 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-23 17:01 [PATCH v2 0/3] x86: SVM: add additional SVM NPF error and use HW GPA Brijesh Singh
2016-11-23 17:01 ` [PATCH v2 1/3] kvm: svm: Add support for additional SVM NPF error codes Brijesh Singh
2017-07-27 16:27   ` Paolo Bonzini
2017-07-31 13:30     ` Brijesh Singh
2017-07-31 15:44       ` Paolo Bonzini
2017-07-31 16:54         ` Brijesh Singh [this message]
2017-07-31 20:05           ` Paolo Bonzini
2017-08-01 13:36             ` Brijesh Singh
2017-08-02 10:42               ` Paolo Bonzini
2017-08-04  0:30                 ` Brijesh Singh
2017-08-04 14:05                   ` Paolo Bonzini
2017-08-04 14:23                     ` Brijesh Singh
2016-11-23 17:01 ` [PATCH v2 2/3] kvm: svm: Add kvm_fast_pio_in support Brijesh Singh
2016-11-23 17:02 ` [PATCH v2 3/3] kvm: svm: Use the hardware provided GPA instead of page walk Brijesh Singh
2016-11-23 21:53   ` Paolo Bonzini
2016-12-08 14:52   ` Paolo Bonzini
2016-12-08 15:39     ` Brijesh Singh
2016-12-08 19:00       ` Brijesh Singh
2016-12-09 15:41         ` Paolo Bonzini
2016-12-12 17:51           ` Brijesh Singh
2016-12-13 17:09             ` Paolo Bonzini
2016-12-14 17:07               ` Brijesh Singh
2016-12-14 17:23                 ` Paolo Bonzini
2016-12-14 18:39                   ` Brijesh Singh
2016-12-14 18:47                     ` Paolo Bonzini
2016-11-24 20:51 ` [PATCH v2 0/3] x86: SVM: add additional SVM NPF error and use HW GPA Radim Krčmář

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=d7266e60-3bcc-946d-4325-dfd1126c9fc4@amd.com \
    --to=brijesh.singh@amd.com \
    --cc=bp@suse.de \
    --cc=hpa@zytor.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=x86@kernel.org \
    /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