On 09/05/2016 03:49 AM, Wanpeng Li wrote: > 2016-09-05 2:22 GMT+08:00 Jan Dakinevich <jan.dakinevich@xxxxxxxxx>: >> 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 <jan.dakinevich@xxxxxxxxx> >> --- >> 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. > 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. > > Regards, > Wanpeng Li > -- Best regards Jan Dakinevich -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
