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] Two shadow page tables for HVM

To: Xen Devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Two shadow page tables for HVM
From: Emre Can Sezer <ecsezer@xxxxxxxx>
Date: Mon, 29 Dec 2008 11:17:40 -0500
Delivery-date: Mon, 29 Dec 2008 08:18:20 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20081223161006.GB28336@xxxxxxxxxxxxxxxxxxxxx>
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: <494985DF.9040701@xxxxxxxx> <20081218113225.GN460@xxxxxxxxxxxxxxxxxxxxx> <494FC8C7.8030508@xxxxxxxx> <20081223161006.GB28336@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.18 (Windows/20081105)
Tim Deegan wrote:
Hi,

At 12:05 -0500 on 22 Dec (1229947511), Emre Can Sezer wrote:
Wouldn't this mean that the two page tables are NOT synchronized? When we switch paging modes, wouldn't we have to rebuild the entire shadow page tables from guest?

We maintain shadow pagetables for pagetables that are not in use, and
even for modes that aren't in use.  We only get rid of shadows when we're
running out of memory, or when the guest uses the page for sonmething else.
If we didn't do that our context-switch costs would be enormous.
I've been trying to understand the shadow code for a while now and I
have one last question about this approach.  In my case, the guest OS
will have only a single set of page tables and in return I will have two
sets of shadows for them.  I understand that once you change your shadow
mode, the shadow pages are still kept and the mapping is stored in the
shadow cache.  However, if a page table is updated in one mode, how does
the other mode know of this change? As far as I understand, the same gfn
will be inserted to the hash twice with two types.  However, does Xen
determine that the guest page's contents have changed? That change must
somehow propagate to the second shadow mode's page tables with the
appropriate permission changes. How is this being done? How does Xen
determine that the page contents have changed?

Thanks for all the input,

John
The reason I was thinking of synchronized page tables is because I will have to switch between them quite often - several times during a system call. So I want to minimize the tlb flushes and make the switch as fast as possible. With synced PT's, my plan was to set the guest CR3 to point to the new top level page table and only flush the kernel pages.

That might be just as expensive -- ISTR Keir measured the cost of invlpg
vs TLB flush a while ago and found that invlpg'ing more than one or two
PTEs was slower than just flushing the whole TLB.

When considering the performance penalties of flushing the kernel page tables from the TLB, how significant is traversing all the shadow page tables for the guest kernel and updating their permissions? If there isn't an order of magnitude of difference, it might be reasonable to take the short cut in implementation.

I don't have any measurements for doing walks of the whole set of
shadows, but in general we've found it's worth doing almost any trick
that will avoid that.

Cheers,

Tim.





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

<Prev in Thread] Current Thread [Next in Thread>