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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 5/11/2017 4:00 AM, Bandan Das wrote:
Paolo Bonzini <pbonzini@xxxxxxxxxx> 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




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux