Re: [Xen-devel] Two shadow page tables for HVM

[Emre Can Sezer <ecsezer@xxxxxxxx>]

Tim Deegan wrote:
> Hi,
>
> At 18:06 -0500 on 17 Dec (1229537167), Emre Can Sezer wrote:
>   
> > So far I can think of only two ways of doing this.  First, I can have two 
> > top level shadow page tables and use one of the unused slots in struct 
> > arch_domain to store this page.  Then I modify propagate_l*e_from_guest 
> > functions to ensure that they create and synchronize the second page table. 
> >     
> You could double up the shadow pagetable types, so that as well as
> having a 32-bit l1 shadow there would also be a 32-bit alternate-mode
> shadow.  Then by doubling the number of times multi.c is built, you
> could hopefully do what you want without _too_ much extra hacking.
> Switching back and forth would involve chaging the paging mode and
> calling shadow_update_paging_modes() to cause the right set of shadows
> to be loaded.
>   
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?

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.

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.


> >  Second, I can have pages that are twice as large as original page tables.  
> > I'm not sure what the implications are concerning shadow cache and the 
> > linear page table mappings. 
> >     
> I think that would involve a lot more hacking around in the code that
> builds the tables, and probably many more infuriating bugs. :)
>
>   
> > Which one of these methods would be easier to implement?  Is there an 
> > easier way of having two sets of page tables?  If I had the means, would it 
> > be worth switching to AMD for the NPT?
> >     
> Probably -- duplicating the p2m table with appropriate changes would be
> simpler than duplicating all shadows everywhere, and the switchover
> would be trivial.
>
> One thing to consider in either case is how to choose which frames are
> accessible: if you modify the shadows you will at least be able to see
> the virtual addresses so you can decide what's kernel and what isn't;
> with NPT you deal only in guest-physical addresses.  But then again, in
> the NPT case you don't have to worry about aliased mappings of the
> frame.
>
> Cheers,
>
> Tim.
>
>   



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