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

[Tim Deegan <Tim.Deegan@xxxxxxxxxx>]

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.

>  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.

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Citrix Systems (R&D) Ltd.
[Company #02300071, SL9 0DZ, UK.]

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