From: Gleb Natapov <gleb@redhat.com>
To: Xiao Guangrong <xiaoguangrong.eric@gmail.com>
Cc: Jan Kiszka <jan.kiszka@web.de>,
kvm@vger.kernel.org,
Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>,
Jun Nakajima <jun.nakajima@intel.com>,
Yang Zhang <yang.z.zhang@intel.com>,
pbonzini@redhat.com
Subject: Re: [PATCH v6 00/15] Nested EPT
Date: Sun, 4 Aug 2013 20:24:18 +0300 [thread overview]
Message-ID: <20130804172418.GF30072@redhat.com> (raw)
In-Reply-To: <C3A03A69-3986-4F7C-8B5E-CE5FCBC67E2E@gmail.com>
On Mon, Aug 05, 2013 at 01:19:26AM +0800, Xiao Guangrong wrote:
>
> On Aug 5, 2013, at 12:58 AM, Gleb Natapov <gleb@redhat.com> 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@web.de> 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.
prev parent reply other threads:[~2013-08-04 17:24 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-01 14:08 [PATCH v6 00/15] Nested EPT Gleb Natapov
2013-08-01 14:08 ` [PATCH v6 01/15] nEPT: Support LOAD_IA32_EFER entry/exit controls for L1 Gleb Natapov
2013-08-02 3:04 ` Zhang, Yang Z
2013-08-02 6:35 ` Jan Kiszka
2013-08-02 7:27 ` Zhang, Yang Z
2013-08-02 7:33 ` Jan Kiszka
2013-08-01 14:08 ` [PATCH v6 02/15] nEPT: Fix cr3 handling in nested exit and entry Gleb Natapov
2013-08-02 9:23 ` Xiao Guangrong
2013-08-01 14:08 ` [PATCH v6 03/15] nEPT: Fix wrong test in kvm_set_cr3 Gleb Natapov
2013-08-01 14:08 ` [PATCH v6 04/15] nEPT: Move common code to paging_tmpl.h Gleb Natapov
2013-08-01 14:08 ` [PATCH v6 05/15] nEPT: make guest's A/D bits depends on guest's paging mode Gleb Natapov
2013-08-01 14:08 ` [PATCH v6 06/15] nEPT: Support shadow paging for guest paging without A/D bits Gleb Natapov
2013-08-01 14:08 ` [PATCH v6 07/15] nEPT: Add EPT tables support to paging_tmpl.h Gleb Natapov
2013-08-01 14:08 ` [PATCH v6 08/15] nEPT: Redefine EPT-specific link_shadow_page() Gleb Natapov
2013-08-01 14:08 ` [PATCH v6 09/15] nEPT: correctly check if remote tlb flush is needed for shadowed EPT tables Gleb Natapov
2013-08-02 5:58 ` Xiao Guangrong
2013-08-01 14:08 ` [PATCH v6 10/15] nEPT: Nested INVEPT Gleb Natapov
2013-08-02 8:06 ` Xiao Guangrong
2013-08-02 10:00 ` Gleb Natapov
2013-08-01 14:08 ` [PATCH v6 11/15] nEPT: Add nEPT violation/misconfigration support Gleb Natapov
2013-08-02 6:12 ` Xiao Guangrong
2013-08-01 14:08 ` [PATCH v6 12/15] nEPT: MMU context for nested EPT Gleb Natapov
2013-08-02 6:13 ` Xiao Guangrong
2013-08-01 14:08 ` [PATCH v6 13/15] nEPT: Advertise EPT to L1 Gleb Natapov
2013-08-02 8:29 ` Xiao Guangrong
2013-08-01 14:08 ` [PATCH v6 14/15] nEPT: Some additional comments Gleb Natapov
2013-08-02 6:26 ` Xiao Guangrong
2013-08-01 14:08 ` [PATCH v6 15/15] nEPT: Miscelleneous cleanups Gleb Natapov
2013-08-02 6:45 ` Xiao Guangrong
2013-08-04 9:24 ` [PATCH v6 00/15] Nested EPT Jan Kiszka
2013-08-04 9:32 ` Gleb Natapov
2013-08-04 9:53 ` Gleb Natapov
2013-08-04 13:44 ` Gleb Natapov
2013-08-04 15:14 ` Jan Kiszka
2013-08-04 16:15 ` Xiao Guangrong
2013-08-04 16:42 ` Jan Kiszka
2013-08-04 16:58 ` Gleb Natapov
2013-08-04 17:19 ` Xiao Guangrong
2013-08-04 17:24 ` Gleb Natapov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130804172418.GF30072@redhat.com \
--to=gleb@redhat.com \
--cc=jan.kiszka@web.de \
--cc=jun.nakajima@intel.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=xiaoguangrong.eric@gmail.com \
--cc=xiaoguangrong@linux.vnet.ibm.com \
--cc=yang.z.zhang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.