| Message ID | 1374123157-11142-1-git-send-email-xiaoguangrong@linux.vnet.ibm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 07/18/2013 12:52 PM, Xiao Guangrong wrote: > Currently, fast page fault tries to fix mmio page fault when the > generation number is invalid (spte.gen != kvm.gen) and returns to > guest to retry the fault since it sees the last spte is nonpresent > which causes infinity loop > > It can be triggered only on AMD host since the mmio page fault is > recognized as ept-misconfig Sorry, It should be "recognized as ept-misconfig on Intel host." -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jul 18, 2013 at 12:52:37PM +0800, Xiao Guangrong wrote: > Currently, fast page fault tries to fix mmio page fault when the > generation number is invalid (spte.gen != kvm.gen) and returns to > guest to retry the fault since it sees the last spte is nonpresent > which causes infinity loop > > It can be triggered only on AMD host since the mmio page fault is > recognized as ept-misconfig > We still call into regular page fault handler from ept-misconfig handler, but fake zero error_code we provide makes page_fault_can_be_fast() return false. Shouldn't shadow paging trigger this too? I haven't encountered this on Intel without ept. > Fix it by filtering the mmio page fault out in page_fault_can_be_fast > > Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de> > Tested-by: Markus Trippelsdorf <markus@trippelsdorf.de> > Signed-off-by: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com> > --- > arch/x86/kvm/mmu.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c > index bf7af1e..3a9493a 100644 > --- a/arch/x86/kvm/mmu.c > +++ b/arch/x86/kvm/mmu.c > @@ -2811,6 +2811,13 @@ exit: > static bool page_fault_can_be_fast(struct kvm_vcpu *vcpu, u32 error_code) > { > /* > + * Do not fix the mmio spte with invalid generation number which > + * need to be updated by slow page fault path. > + */ > + if (unlikely(error_code & PFERR_RSVD_MASK)) > + return false; > + > + /* > * #PF can be fast only if the shadow page table is present and it > * is caused by write-protect, that means we just need change the > * W bit of the spte which can be done out of mmu-lock. > -- > 1.8.1.4 -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/18/2013 01:31 PM, Gleb Natapov wrote: > On Thu, Jul 18, 2013 at 12:52:37PM +0800, Xiao Guangrong wrote: >> Currently, fast page fault tries to fix mmio page fault when the >> generation number is invalid (spte.gen != kvm.gen) and returns to >> guest to retry the fault since it sees the last spte is nonpresent >> which causes infinity loop >> >> It can be triggered only on AMD host since the mmio page fault is >> recognized as ept-misconfig >> > We still call into regular page fault handler from ept-misconfig > handler, but fake zero error_code we provide makes page_fault_can_be_fast() > return false. Yes. > > Shouldn't shadow paging trigger this too? I haven't encountered this on > Intel without ept. Since currently fast page fault only works for direct mmu. :) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jul 18, 2013 at 02:01:47PM +0800, Xiao Guangrong wrote: > On 07/18/2013 01:31 PM, Gleb Natapov wrote: > > On Thu, Jul 18, 2013 at 12:52:37PM +0800, Xiao Guangrong wrote: > >> Currently, fast page fault tries to fix mmio page fault when the > >> generation number is invalid (spte.gen != kvm.gen) and returns to > >> guest to retry the fault since it sees the last spte is nonpresent > >> which causes infinity loop > >> > >> It can be triggered only on AMD host since the mmio page fault is > >> recognized as ept-misconfig > >> > > We still call into regular page fault handler from ept-misconfig > > handler, but fake zero error_code we provide makes page_fault_can_be_fast() > > return false. > > Yes. > > > > > Shouldn't shadow paging trigger this too? I haven't encountered this on > > Intel without ept. > > Since currently fast page fault only works for direct mmu. :) Ah, yes. So with shadow page and paging disabled in a guest is can happen eventually, but we do not trigger it for some reason? -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index bf7af1e..3a9493a 100644 --- a/arch/x86/kvm/mmu.c +++ b/arch/x86/kvm/mmu.c @@ -2811,6 +2811,13 @@ exit: static bool page_fault_can_be_fast(struct kvm_vcpu *vcpu, u32 error_code) { /* + * Do not fix the mmio spte with invalid generation number which + * need to be updated by slow page fault path. + */ + if (unlikely(error_code & PFERR_RSVD_MASK)) + return false; + + /* * #PF can be fast only if the shadow page table is present and it * is caused by write-protect, that means we just need change the * W bit of the spte which can be done out of mmu-lock.