On 2013-08-04 18:15, Xiao Guangrong wrote: > > On Aug 4, 2013, at 11:14 PM, Jan Kiszka <[email protected]> wrote: > >> On 2013-08-04 15:44, Gleb Natapov wrote: >>> On Sun, Aug 04, 2013 at 12:53:56PM +0300, Gleb Natapov wrote: >>>> On Sun, Aug 04, 2013 at 12:32:06PM +0300, Gleb Natapov wrote: >>>>> On Sun, Aug 04, 2013 at 11:24:41AM +0200, Jan Kiszka wrote: >>>>>> On 2013-08-01 16:08, Gleb Natapov wrote: >>>>>>> Another day -- another version of the nested EPT patches. In this >>>>>>> version >>>>>>> included fix for need_remote_flush() with shadowed ept, set bits 6:8 >>>>>>> of exit_qualification during ept_violation, update_permission_bitmask() >>>>>>> made to work with shadowed ept pages and other small adjustment >>>>>>> according >>>>>>> to review comments. >>>>>> >>>>>> Was just testing it here and ran into a bug: I've L2 accessing the HPET >>>>>> MMIO region that my L1 passed through from L0 (where it is supposed to >>>>>> be emulated in this setup). This used to work with an older posting of >>>>> Not sure I understand your setup. L0 emulates HPET, L1 passes it through >>>>> to L2 (mmaps it and creates kvm slot that points to it) and when L2 >>>>> accessed it it locks up? >>>>> >>>>>> Jun, but now it locks up (infinite loop over L2's MMIO access, no L2->L1 >>>>>> transition). Any ideas where to look for debugging this? >>>>>> >>>>> Can you do an ftrace -e kvm -e kvmmmu? Unit test will also be helpful :) >>>>> >>>> I did an MMIO access from nested guest in the vmx unit test (which is >>>> naturally passed through to L0 since L1 is so simple) and I can see that >>>> the access hits L0. >>>> >>> But then unit test not yet uses nested EPT :) >> >> Indeed, that's what I was about to notice as well. EPT test cases are on >> Arthur's list, but I suggested to start easier with some MSR switches >> (just to let him run into KVM's PAT bugs ;) ). >> >> Anyway, here are the traces: >> >> qemu-system-x86-11521 [000] 4724.170191: kvm_entry: vcpu 0 >> qemu-system-x86-11521 [000] 4724.170192: kvm_exit: reason >> EPT_VIOLATION rip 0xffffffff8102ab70 info 181 0 >> qemu-system-x86-11521 [000] 4724.170192: kvm_page_fault: address >> 1901978 error_code 181 >> qemu-system-x86-11521 [000] 4724.170193: kvm_mmu_pagetable_walk: addr >> 1901978 pferr 0 >> qemu-system-x86-11521 [000] 4724.170193: kvm_mmu_paging_element: pte >> 3c04c007 level 4 >> qemu-system-x86-11521 [000] 4724.170193: kvm_mmu_paging_element: pte >> 3c04d007 level 3 >> qemu-system-x86-11521 [000] 4724.170193: kvm_mmu_paging_element: pte >> 3c05a007 level 2 >> qemu-system-x86-11521 [000] 4724.170193: kvm_mmu_paging_element: pte >> 1901037 level 1 >> qemu-system-x86-11521 [000] 4724.170197: kvm_entry: vcpu 0 >> qemu-system-x86-11521 [000] 4724.170198: kvm_exit: reason >> EPT_VIOLATION rip 0xffffffff8102ab77 info 81 0 >> qemu-system-x86-11521 [000] 4724.170199: kvm_page_fault: address >> 3a029000 error_code 81 >> qemu-system-x86-11521 [000] 4724.170199: kvm_mmu_pagetable_walk: addr >> 3a029000 pferr 0 >> qemu-system-x86-11521 [000] 4724.170199: kvm_mmu_paging_element: pte >> 3c04c007 level 4 >> qemu-system-x86-11521 [000] 4724.170199: kvm_mmu_paging_element: pte >> 3c04d007 level 3 >> qemu-system-x86-11521 [000] 4724.170199: kvm_mmu_paging_element: pte >> 3c21e007 level 2 >> qemu-system-x86-11521 [000] 4724.170200: kvm_mmu_paging_element: pte >> 3a029037 level 1 >> qemu-system-x86-11521 [000] 4724.170203: kvm_entry: vcpu 0 >> qemu-system-x86-11521 [000] 4724.170204: kvm_exit: reason >> EPT_VIOLATION rip 0xffffffff8102ab77 info 181 0 >> qemu-system-x86-11521 [000] 4724.170204: kvm_page_fault: address >> fed000f0 error_code 181 >> qemu-system-x86-11521 [000] 4724.170205: kvm_mmu_pagetable_walk: addr >> fed000f0 pferr 0 >> qemu-system-x86-11521 [000] 4724.170205: kvm_mmu_paging_element: pte >> 3c04c007 level 4 >> qemu-system-x86-11521 [000] 4724.170205: kvm_mmu_paging_element: pte >> 3c42f003 level 3 >> qemu-system-x86-11521 [000] 4724.170205: kvm_mmu_paging_element: pte >> 3c626003 level 2 >> qemu-system-x86-11521 [000] 4724.170206: kvm_mmu_paging_element: pte >> fed00033 level 1 >> qemu-system-x86-11521 [000] 4724.170213: mark_mmio_spte: >> sptep:0xffff88014e8ad800 gfn fed00 access 6 gen b7f >> qemu-system-x86-11521 [000] 4724.170214: kvm_mmu_pagetable_walk: addr >> ffffffff8102ab77 pferr 10 F >> qemu-system-x86-11521 [000] 4724.170215: kvm_mmu_pagetable_walk: addr >> 1710000 pferr 6 W|U >> qemu-system-x86-11521 [000] 4724.170215: kvm_mmu_paging_element: pte >> 3c04c007 level 4 >> qemu-system-x86-11521 [000] 4724.170215: kvm_mmu_paging_element: pte >> 3c04d007 level 3 >> qemu-system-x86-11521 [000] 4724.170216: kvm_mmu_paging_element: pte >> 3c059007 level 2 >> qemu-system-x86-11521 [000] 4724.170216: kvm_mmu_paging_element: pte >> 1710037 level 1 >> qemu-system-x86-11521 [000] 4724.170216: kvm_mmu_paging_element: pte >> 1711067 level 4 >> qemu-system-x86-11521 [000] 4724.170216: kvm_mmu_walker_error: pferr 19 >> P|RSVD|F > > I guess the bug is here, could you please change this code to: > > - if (unlikely(is_rsvd_bits_set(&vcpu->arch.mmu, pte, > + if (unlikely(is_rsvd_bits_set(mmu, pte, > walker->level))) { > > ( > In static int FNAME(walk_addr_generic)(struct guest_walker *walker, > struct kvm_vcpu *vcpu, struct kvm_mmu *mmu, > gva_t addr, u32 access) > ) > > and try again? >
Thanks, that fixed the bug! Obviously, previous version were less strict or imprecise with reserved bit checking as this pattern exists in the version that worked here as well. Jan
signature.asc
Description: OpenPGP digital signature
