Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1639110
| 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 |
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 | Next — Previous in thread | Find similar | Unroll 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