2016-09-05 21:02 GMT+08:00 Jan Dakinevich <[email protected]>: > > > On 09/05/2016 03:49 AM, Wanpeng Li wrote: >> 2016-09-05 2:22 GMT+08:00 Jan Dakinevich <[email protected]>: >>> If EPT support is exposed to L1 hypervisor, guest linear-address field >>> of VMCS should contain GVA of L2, the access to which caused EPT violation. >>> >>> Signed-off-by: Jan Dakinevich <[email protected]> >>> --- >>> arch/x86/kvm/vmx.c | 3 +++ >>> 1 file changed, 3 insertions(+) >>> >>> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c >>> index 5cede40..a4bb2bd 100644 >>> --- a/arch/x86/kvm/vmx.c >>> +++ b/arch/x86/kvm/vmx.c >>> @@ -10500,6 +10500,9 @@ static void prepare_vmcs12(struct kvm_vcpu *vcpu, >>> struct vmcs12 *vmcs12, >>> vmcs12->guest_pdptr3 = vmcs_read64(GUEST_PDPTR3); >>> } >>> >>> + if (nested_cpu_has_ept(vmcs12)) >>> + vmcs12->guest_linear_address = >>> vmcs_readl(GUEST_LINEAR_ADDRESS); >>> + >> >> No, nested_ept_inject_page_fault() will set >> vmcs12->guest_linear_address after L0 walks L1's EPT page table and >> finds that the mapping is invalid if nested EPT is enabled. > > Acctually, nested_ept_inject_page_fault() doesn't do that, the routine > sets only vmcs12->guest_physical_address, but > vmcs12->guest_linear_address remains untouched. As result, after EPT > fault from L2, vmcs_readl(GUEST_LINEAR_ADDRESS) in L1 always returns 0.
Agreed, I misread guest_linear_address as guest_physical_address. > >> prepare_vmcs12() just copies the vmcs field that could have changed by >> the L2 guest or the exit-information etc instead of all fields since >> other fields are modified by L1 with VMWRITE, which already writes to >> vmcs12 directly. > > Yes, and guest linear-address considered as a part of exit information, > provided by hardware. Thanks for the patch. Reviewed-by: Wanpeng Li <[email protected]>
