Re: [PATCH kvm-unit-tests 2/2] vmx: fix expected results of new EPT tests

[Paolo Bonzini <pbonzini@redhat.com>]

> On Fri, May 12, 2017 at 1:45 AM, Paolo Bonzini <pbonzini@redhat.com> wrote:
> > On 11/05/2017 21:51, David Matlack wrote:
> >>> No, I've tried the tests on upstream Linux with eptad=0 (so that EPT A/D
> >>> is not used by KVM on the host) and they also hang with an infinite
> >>> stream
> >>> of EPT violations.
> >>
> >> I think the failures are caused by this code in handle_ept_violation,
> >> which clears the ACC_WRITE bit of the exit qualification before
> >> handling the fault, when EPT A/D is disabled:
> >>
> >> if (is_guest_mode(vcpu)
> >>    && !(exit_qualification & EPT_VIOLATION_GVA_TRANSLATED)) {
> >>         /*
> >>          * Fix up exit_qualification according to whether guest
> >>          * page table accesses are reads or writes.
> >>          */
> >>         u64 eptp = nested_ept_get_cr3(vcpu);
> >>         if (!(eptp & VMX_EPT_AD_ENABLE_BIT))
> >>                 exit_qualification &= ~EPT_VIOLATION_ACC_WRITE;
> >> }
> >
> > I thought so as well; that's why my hypervisor patch moved
> > trace_kvm_page_fault before munging exit_qualification.  Then I searched
> > for 0x82 or 0x8a in the traces, didn't find it, and got terribly confused.
> >
> > What actually happens doesn't match what the SDM says.  You correctly cite
> > this:
> >
> >> Per 28.2.3.2 EPT Violations: "Writes by the logical processor to guest
> >> paging structures to update accessed and dirty flags are considered to
> >> be data writes."
> >
> > though here you mean EPT_VIOLATION_GVA_TRANSLATED=0,
> > EPT_VIOLATION_ACC_WRITE=1:
> >
> >> In other words, it's valid for
> >> EPT_VIOLATION_GVA_TRANSLATED and EPT_VIOLATION_ACC_WRITE to both be
> >> set in the exit qual when EPT A/D is disabled.
> >
> > What really happens is that the processor first reads the page tables,
> > then translates the resulting GPA, and then finally does _another_ EPT
> > translation for the page tables, this time with EPT_VIOLATION_ACC_READ=1
> > and EPT_VIOLATION_ACC_WRITE=1:
> >
> >         qemu-kvm-3683  [042]  2364.196479: kvm_entry:            vcpu 0
> >         qemu-kvm-3683  [042]  2364.196479: kvm_exit:             reason
> >         EPT_VIOLATION rip 0x40519e info 8b 0
> >         qemu-kvm-3683  [042]  2364.196479: kvm_nested_vmexit:    rip:
> >         0x000000000040519e reason: EPT_VIOLATION ext_inf1:
> >         0x000000000000008b ext_inf2: 0x0000000000000000 ext_int:
> >         0x00000000 ext_int_err: 0x00000000
> >         qemu-kvm-3683  [042]  2364.196480: kvm_page_fault:       address
> >         479000 error_code 8b
> >         qemu-kvm-3683  [042]  2364.196480: kvm_mmu_pagetable_walk: addr
> >         479000 pferr 7 P|W|U
> >         qemu-kvm-3683  [042]  2364.196480: kvm_mmu_paging_element: pte
> >         472007 level 4
> >         qemu-kvm-3683  [042]  2364.196480: kvm_mmu_paging_element: pte
> >         473007 level 3
> >         qemu-kvm-3683  [042]  2364.196480: kvm_mmu_paging_element: pte
> >         67c007 level 2
> >         qemu-kvm-3683  [042]  2364.196480: kvm_mmu_paging_element: pte
> >         479001 level 1
> >
> > (This trace comes from vanilla Linux 4.11.0).  This matches your
> > kvm-unit-tests
> > patch ("x86: fix ept_access_test_paddr exit qualifications").  Aargh.
> >
> > So Peter is right; the only way to get this behavior is to run with
> > EPT A/D bits disabled when L1 disables them.  I'll wait for you guys to
> > send
> > a patch for this---we have plenty of time to include it in 4.12.0.  In the
> > meanwhile Radim shall drop patch 2 from the KVM series.
> 
> Sounds good, we'll get you that patch. When does 4.12.0 close?

Sending it within the next 3-4 weeks should be fine, even if it needs a
couple iterations to get everything in shape.

Paolo