All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Huang, Kai" <kai.huang@linux.intel.com>
To: Bandan Das <bsd@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/3] nVMX: Implement emulated Page Modification Logging
Date: Thu, 11 May 2017 11:21:25 +1200	[thread overview]
Message-ID: <54ec213c-ef9f-23ed-4de8-4a1eeb50aca0@linux.intel.com> (raw)
In-Reply-To: <jpginl8zoq2.fsf@linux.bootlegged.copy>



On 5/11/2017 4:00 AM, Bandan Das wrote:
> Paolo Bonzini <pbonzini@redhat.com> writes:
> ...
>>> Is the purpose of returning 1 to make upper layer code to inject PML
>>> full VMEXIt to L1 in nested_ept_inject_page_fault?
>>
>> Yes, it triggers a fault
>>>> +
>>>> +        gpa = vmcs_read64(GUEST_PHYSICAL_ADDRESS) & ~0xFFFull;
>>>> +
>>>> +        page = nested_get_page(vcpu, vmcs12->pml_address);
>>>> +        if (!page)
>>>> +            return 0;
>>>
>>> If PML is enabled in L1, I think nested_get_page should never return a
>>> NULL PML page (unless L1 does something wrong)? Probably better to
>>> return 1 rather than 0, and handle error in nested_ept_inject_page_fault
>>> according to vmcs12->pml_address?
>>
>> This happens if the PML address is invalid (where on real hardware, the
>> write would just be "eaten") or MMIO (where we expect to diverge from
>
> Yes, that was my motivation. On real hardware, the hypervisor would still
> run except that the PML buffer is corrupt.

Right. Fine to me. :)

>
> Bandan
>
>> real hardware behavior).
>>
>>>> +
>>>> +        pml_address = kmap(page);
>>>> +        pml_address[vmcs12->guest_pml_index--] = gpa;
>>>
>>> This gpa is L2 guest's GPA. Do we also need to mark L1's GPA (which is
>>> related to L2 guest's GPA above) in to dirty-log? Or has this already
>>> been done?
>>
>> L1's PML contains L1 host physical addresses, i.e. L0 guest physical
>> addresses.  This GPA comes from vmcs02 and hence it is L0's GPA.

Do you mean pml_address? I was talking about gpa got from 
vmcs_read64(GUEST_PHYSICAL_ADDRESS). From hardware's point of view, PML 
always logs "GPA" into PML buffer so I was saying the gpa from 
vmcs_read64(GUEST_PHYSICAL_ADDRESS) should be L2 guest's PA. Anyway this 
is not important now. :)

>>
>> L0's HPA is marked by hardware through PML, as usual.  If L0 has EPT A/D
>> but not PML, it can still provide emulated PML to L1, but L0's HPA will
>> be marked as dirty via write protection.

Yes this is what I was thinking. For L0 PML takes care of L1 
hpyervisor's dirty page, while write protection takes care of dirty page 
from L2. No problem.

Thanks,
-Kai

>>
>> Paolo
>

  reply	other threads:[~2017-05-10 23:21 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-05 19:25 [PATCH v2 0/3] nVMX: Emulated Page Modification Logging for Nested Virtualization Bandan Das
2017-05-05 19:25 ` [PATCH v2 1/3] kvm: x86: Add a hook for arch specific dirty logging emulation Bandan Das
2017-05-10 10:49   ` Huang, Kai
2017-05-10 15:53     ` Bandan Das
2017-05-10 23:23       ` Huang, Kai
2017-05-11 18:36         ` Bandan Das
2017-05-05 19:25 ` [PATCH v2 2/3] nVMX: Implement emulated Page Modification Logging Bandan Das
2017-05-10 10:48   ` Huang, Kai
2017-05-10 14:46     ` Paolo Bonzini
2017-05-10 16:00       ` Bandan Das
2017-05-10 23:21         ` Huang, Kai [this message]
2017-05-05 19:25 ` [PATCH v2 3/3] nVMX: Advertise PML to L1 hypervisor Bandan Das
2017-05-09 15:22 ` [PATCH v2 0/3] nVMX: Emulated Page Modification Logging for Nested Virtualization Paolo Bonzini
2017-05-09 16:03   ` Bandan Das
2017-05-09 16:04     ` 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=54ec213c-ef9f-23ed-4de8-4a1eeb50aca0@linux.intel.com \
    --to=kai.huang@linux.intel.com \
    --cc=bsd@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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.