From mboxrd@z Thu Jan 1 00:00:00 1970 From: Emre Can Sezer Subject: Re: Two shadow page tables for HVM Date: Mon, 29 Dec 2008 11:17:40 -0500 Message-ID: <4958F824.10400@ncsu.edu> References: <494985DF.9040701@ncsu.edu> <20081218113225.GN460@york.uk.xensource.com> <494FC8C7.8030508@ncsu.edu> <20081223161006.GB28336@york.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20081223161006.GB28336@york.uk.xensource.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 List-Id: xen-devel@lists.xenproject.org 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. > >