From: Ben Guthro Subject: [PATCH] Flush stale TLBs Date: Tue, 30 Oct 2007 10:18:25 -0400 Message-ID: <47273D31.6030303@virtualiron.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------040100060104060804080202" Return-path: 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. --------------040100060104060804080202 Content-Type: multipart/alternative; boundary="------------080305060300050700020702" --------------080305060300050700020702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 --------------080305060300050700020702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
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>
--------------080305060300050700020702-- --------------040100060104060804080202 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_local_tlb(); + } } --------------040100060104060804080202 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 --------------040100060104060804080202--