Re: [PATCH v6 00/15] Nested EPT

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Aug 05, 2013 at 01:19:26AM +0800, Xiao Guangrong wrote:
> 
> On Aug 5, 2013, at 12:58 AM, Gleb Natapov <gleb@xxxxxxxxxx> wrote:
> 
> > On Sun, Aug 04, 2013 at 06:42:09PM +0200, Jan Kiszka wrote:
> >> On 2013-08-04 18:15, Xiao Guangrong wrote:
> >>> 
> >>> On Aug 4, 2013, at 11:14 PM, Jan Kiszka <jan.kiszka@xxxxxx> 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!
> >> 
> > Awesome!
> > 
> >> Obviously, previous version were less strict or imprecise with reserved
> >> bit checking as this pattern exists in the version that worked here as well.
> >> 
> > Previous version did not use mmu->rsvd_bits_mask for nEPT reserved bit
> > checking so is_rsvd_bits_set() happened to work correctly for nested mmu
> > using non nested mmu pointer, but when I change it to use
> > mmu->rsvd_bits_mask the bug become triggerable. In theory this bug
> > should be triggerable on nested SVM to if two levels of paging use
> > different modes, no?
> 
> Yes, it should be.
> 
> BTW, i will post this fix with the right format when i work in the office.
Cool, thanks. It can be applied independent of this patch series since
it fixes nested NPT too.

--
			Gleb.
--
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




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux