KVM: MMU: prefetch ptes when intercepted guest #PF
in [Kernel]
|
Prev: i2c:i2c_core Fix warning: variable 'dummy' set but not used
Next: KVM: MMU: support pte prefetch when intercepted guest #PF
From: Avi Kivity on 17 Jun 2010 05:30 On 06/17/2010 12:04 PM, Xiao Guangrong wrote: > > >> So we can change the fault path to always fault 16 ptes, aligned on 16 >> pte boundary, with the needed pte called with specualtive=false. >> > Avi, i not understand it clearly, Could you please explain it? :-( > Right now if the fault is in spte i, you prefetch ptes (i+1)..(i+MAX_PREFETCH-1). I'd like to prefetch ptes (i & ~(MAX_PREFETCH-1))..(i | (MAX_PREFETCH - 1)). Read all those gptes, and map them one by one with speculative = false only for spte i. Perhaps we need to integrate it into walk_addr, there's no reason to read the gptes twice. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Xiao Guangrong on 17 Jun 2010 05:40 Avi Kivity wrote: > On 06/17/2010 12:04 PM, Xiao Guangrong wrote: >> >> >>> So we can change the fault path to always fault 16 ptes, aligned on 16 >>> pte boundary, with the needed pte called with specualtive=false. >>> >> Avi, i not understand it clearly, Could you please explain it? :-( >> > > Right now if the fault is in spte i, you prefetch ptes > (i+1)..(i+MAX_PREFETCH-1). I'd like to prefetch ptes (i & > ~(MAX_PREFETCH-1))..(i | (MAX_PREFETCH - 1)). Read all those gptes, and > map them one by one with speculative = false only for spte i. > Thanks for your explanation, i see. > Perhaps we need to integrate it into walk_addr, there's no reason to > read the gptes twice. > OK, will do it. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Marcelo Tosatti on 2 Jul 2010 13:30 On Thu, Jul 01, 2010 at 09:55:17PM +0800, Xiao Guangrong wrote: > Support prefetch ptes when intercept guest #PF, avoid to #PF by later > access > > If we meet any failure in the prefetch path, we will exit it and > not try other ptes to avoid become heavy path > > Note: this speculative will mark page become dirty but it not really > accessed, the same issue is in other speculative paths like invlpg, > pte write, fortunately, it just affect host memory management. After > Avi's patchset named "[PATCH v2 1/4] KVM: MMU: Introduce drop_spte()" > merged, we will easily fix it. Will do it in the future. > > Signed-off-by: Xiao Guangrong <xiaoguangrong(a)cn.fujitsu.com> > --- > arch/x86/kvm/mmu.c | 79 ++++++++++++++++++++++++++++++++++++++++++++ > arch/x86/kvm/paging_tmpl.h | 76 ++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 155 insertions(+), 0 deletions(-) > > + if (pte_prefetch_topup_memory_cache(vcpu)) > + return; > + > + for (j = 0; i < max; i++, j++) { > + pt_element_t gpte; > + unsigned pte_access; > + u64 *spte = sp->spt + i; > + gfn_t gfn; > + pfn_t pfn; > + > + if (spte == sptep) > + continue; > + > + if (*spte != shadow_trap_nonpresent_pte) > + continue; > + > + gpte = gptep[j]; > + > + if (is_rsvd_bits_set(vcpu, gpte, PT_PAGE_TABLE_LEVEL)) > + break; BTW, doesnt sync_page also lack reserved bit checking? (unrelated to this patch). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Marcelo Tosatti on 5 Jul 2010 08:10
On Sat, Jul 03, 2010 at 04:08:42PM +0800, Xiao Guangrong wrote: > > > Marcelo Tosatti wrote: > > >> + > >> + if (is_rsvd_bits_set(vcpu, gpte, PT_PAGE_TABLE_LEVEL)) > >> + break; > > > > BTW, doesnt sync_page also lack reserved bit checking? (unrelated to > > this patch). > > > > I think it's not since if EPT is enabled, no unsync page exist, the sync page > path can't be trigged. :-) What i mean is, why the sync_page path does not require reserved bit checking? (EPT disabled). Just to clarify, this has nothing to do with your patch. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |