Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1639110

Re: [PATCH v2 2/3] nVMX: Implement emulated Page Modification Logging

From "Huang, Kai" <kai.huang@linux.intel.com>
Newsgroups linux.kernel
Subject Re: [PATCH v2 2/3] nVMX: Implement emulated Page Modification Logging
Date 2017-05-11 01:30 +0200
Message-ID <tFJdn-70m-11@gated-at.bofh.it> (permalink)
References <tDR5o-5Ye-5@gated-at.bofh.it> <tDR5o-5Ye-13@gated-at.bofh.it> <tFxlT-82s-13@gated-at.bofh.it> <tFB69-1Xf-13@gated-at.bofh.it> <tFClA-2QH-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw



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
>

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

[PATCH v2 2/3] nVMX: Implement emulated Page Modification Logging Bandan Das <bsd@redhat.com> - 2017-05-05 21:30 +0200
  Re: [PATCH v2 2/3] nVMX: Implement emulated Page Modification Logging "Huang, Kai" <kai.huang@linux.intel.com> - 2017-05-10 12:50 +0200
    Re: [PATCH v2 2/3] nVMX: Implement emulated Page Modification Logging Paolo Bonzini <pbonzini@redhat.com> - 2017-05-10 16:50 +0200
      Re: [PATCH v2 2/3] nVMX: Implement emulated Page Modification Logging Bandan Das <bsd@redhat.com> - 2017-05-10 18:10 +0200
        Re: [PATCH v2 2/3] nVMX: Implement emulated Page Modification Logging "Huang, Kai" <kai.huang@linux.intel.com> - 2017-05-11 01:30 +0200

csiph-web