WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] a quick question about _PAGE_GLOBAL flag in para virt m

To: weiming <zephyr.zhao@xxxxxxxxx>
Subject: Re: [Xen-devel] a quick question about _PAGE_GLOBAL flag in para virt mode
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Sun, 15 Feb 2009 14:26:13 -0800
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sun, 15 Feb 2009 14:26:42 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <add59a3f0902150930m57ab843bi5bcdb90b6a4859a8@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <add59a3f0902141740j58f0223eu4d04a169885b6f54@xxxxxxxxxxxxxx> <4997E249.1050407@xxxxxxxx> <add59a3f0902150930m57ab843bi5bcdb90b6a4859a8@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.19 (X11/20090105)
weiming wrote:
When a normal context switch happens (like process switch), those tlb entries will still be flushed no matter if global bit is set or not, is it correct?

Things would go very wrong if it didn't... I haven't checked in detail, but presumably when the kernel does a user cr3 reload, Xen will do a global tlb flush (or at least make sure one happens when needed).

why not set global bit for user kernel pages? I guess this is because when domain switchs, all tlb entries will still be flushed, so it's not necessary for user kernel pages. Is my understanding right?

64-bit Xen uses paging to protect the guest kernel from guest usermode, and protect Xen from the guest kernel, and as a result has to do a cr3 reload for any user->kernel switch (which is why it has to go via Xen). We don't want kernel mappings to be visible to usermode, so they have to only be in tlb while we're actually running in guest kernel mode; setting global on the kernel mappings wouldn't be useful because we always need to flush them anyway when returning to usermode.

Or to put it another way, it makes sense to set global on user mappings because they're always mapped, regardless of what context we're in; the only time they need to be flushed is either doing a user process context switch, or a vcpu context switch.

   J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel