From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: cr3 OOS optimisation breaks 32-bit GNU/kFreeBSD guest Date: Sun, 5 Apr 2009 08:29:17 -0300 Message-ID: <20090405112917.GA4105@amt.cnet> References: <20090223003305.GW12976@hall.aurel32.net> <20090320231405.GA26415@amt.cnet> <49C60644.2090904@redhat.com> <20090323172725.GA28775@amt.cnet> <49C8AC35.3030803@redhat.com> <20090403214548.GA5394@amt.cnet> <49D73873.2090302@redhat.com> <20090404170143.GA3303@amt.cnet> <49D86EC3.3070902@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Aurelien Jarno , kvm@vger.kernel.org To: Avi Kivity Return-path: Received: from mx2.redhat.com ([66.187.237.31]:36350 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751363AbZDELaC (ORCPT ); Sun, 5 Apr 2009 07:30:02 -0400 Content-Disposition: inline In-Reply-To: <49D86EC3.3070902@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Sun, Apr 05, 2009 at 11:41:39AM +0300, Avi Kivity wrote: > Marcelo Tosatti wrote: >> The problem is when the page is unreachable due to a higher level path >> being unlinked. Say: >> >> level 4 -> level 3 . level 2 -> level 1 (global unsync) >> >> The dot there means level 3 is not linked to level 2, so invlpg can't >> reach the global unsync at level 1. >> >> kvm_mmu_get_page does sync pages when it finds them, so the code is >> already safe for the "linking a page which contains global ptes" case >> you mention above. >> > > The recursive resync ignores global pages (or it would hit them on cr3 > switch too). > > But we have a bigger problem, invlpg can miss even if nothing is unlinked: > > access address x through global pte > -> pte instantiated into spte > switch to cr3 where x is not mapped, or mapped differently > write to pte > -> no fault since pte is unsync > invlpg x > -> no way this can hit the spte > switch cr3 back > access address x > -> use old spte > > Here's one way to make this work: > > - add a hash of global pagetables, indexed by virtual address instead > of the pagetable's gfn > - invlpg checks this hash in addition to the recursive walk > > We'd need to make the virtual address part of sp->role to avoid needing > to link the same page multiple times in the virtual address hash. Humpf, yes. It seems its too expensive/complex to handle this, for such small gain (~= 2% on AIM7 with RHEL3 guest). Are you okay with just disabling the global pages optimization?