| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Two shadow page tables for HVM
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
|
|
|
| |
|
Home