From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Guthro Subject: Re: [PATCH] Flush stale TLBs Date: Tue, 30 Oct 2007 10:45:00 -0400 Message-ID: <4727436C.7010107@virtualiron.com> References: <47273D31.6030303@virtualiron.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------030303030706010002020105" Return-path: In-Reply-To: <47273D31.6030303@virtualiron.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel Cc: Robert Phillips List-Id: xen-devel@lists.xenproject.org This is a multi-part message in MIME format. --------------030303030706010002020105 Content-Type: multipart/alternative; boundary="------------070603010902020809010106" --------------070603010902020809010106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Apologies. The prior version caused build errors in unstable. Please use the attached version instead Ben Guthro wrote: > This patch causes a flush of the local host TLBs after any > modification of the linearpagetable mapping. > > This was not needed when vmenter/vmexit always had the side effect of > flushing host TLBs. > > But, with SVM ASIDs, it is possible to: > (1) Update CR3 update, > (2) vmenter the guest, and > (3) and vmexit due to a page fault > all without an intervening host TLB flush. > > Then the page fault code could use the linear pagetable > to read a top-level shadow page table entry. > > But, without this change, it would fetch the wrong value > due to a stale TLB. > > This code applies to unstable. > We also have a 3.1.2 version available upon request. > > Signed-off-by: Robert Phillips > Signed-off-by: Ben Guthro > --------------070603010902020809010106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Apologies. The prior version caused build errors in unstable.
Please use the attached version instead


Ben Guthro wrote:
This patch causes a flush of the local host TLBs after any
modification of the linearpagetable mapping.

This was not needed when vmenter/vmexit always had the side effect of
flushing host TLBs.

But, with SVM ASIDs, it is possible to:
(1) Update CR3 update,
(2) vmenter the guest, and
(3) and vmexit due to a page fault
all without an intervening host TLB flush.

Then the page fault code could use the linear pagetable
to read a top-level shadow page table entry.

But, without this change, it would fetch the wrong value
due to a stale TLB.

This code applies to unstable. 
We also have a 3.1.2 version available upon request.

Signed-off-by: Robert Phillips <rphillips@virtualiron.com>
Signed-off-by: Ben Guthro <bguthro@virtualiron.com>
  

--------------070603010902020809010106-- --------------030303030706010002020105 Content-Type: text/x-patch; name="xen-stale-tlb.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xen-stale-tlb.patch" diff -r 5612da277300 xen/arch/x86/mm/shadow/multi.c --- a/xen/arch/x86/mm/shadow/multi.c Mon Oct 29 07:54:17 2007 -0400 +++ b/xen/arch/x86/mm/shadow/multi.c Mon Oct 29 07:56:15 2007 -0400 @@ -3392,6 +3392,20 @@ sh_update_linear_entries(struct vcpu *v) #else #error this should not happen #endif + if ( shadow_mode_external(d) ) + { + /* Having modified the linear pagetable mapping, flush local host TLBs. + * This was not needed when vmenter/vmexit always had the side effect of + * flushing host TLBs but, with SVM ASIDs, it is possible to + * finish this CR3 update, vmenter the guest, vmexit due to a + * page fault, without an intervening host TLB flush. + * Then the page fault code could use the linear pagetable + * to read a top-level shadow page table entry. + * But, without this change, it would fetch the wrong value + * due to a stale TLB. + */ + flush_tlb_local(); + } } --------------030303030706010002020105 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel --------------030303030706010002020105--