Hi Folks,
I am trying to understand the shadow page table implementation for HVM domains.
In this process I have some assumptions and some questions. I will be very
thankful if ppl can give me comments/answers so as to convert these assumptions
to true beliefs. Some of the questions/explanations might be specific to 64-bit
machines.
Assumtion 1: All page table pages (hereafter refered to as GPT pages) are
mapped R/O for guest.
Explanation: Necessary to make remap work. If GPT pages were writable, guest
could change a VA to point to a different page, without VMM having any chance
to change the shadow table pages (hereafter refered to as SPT pages). I think
that new mappings can still be created w/o assuming the above. Basically, on
every PG fault, VMM just checks/converts to entry in GPT page and installs it in
SPT page.
Question: How are new entries in page table created?
Possible Explanation 1: Since GPT pages are R/O mapped, a write on them to
install the new PTE will cause a write protection fault (WP). At this point,
the VMM does a full scale emulation of the instruction at current EIP, decoding
what value guest wanted written in the GPT page and validates/performs that
write
along with installing corresponding translated entry in SPT page. This sounds
very expensive.
Possible Explanation 2: After the WP fault as in explanation 1, the VMM makes
the
GPT page(s) R/W. It must also unhook the corresponding SPT pages, otherwise the
remap won't work for any address on the GPT page. The VMM then restarts the
faulting instruction, which successfully installs the PTE in a GPT page. Next,
an access to that VA will cause an no page (NP) fault. At this point, the VMM
can validate the entry in GPT and install the corresponding entry in SPT.
This explanation sounds very similar to direct mapped PT manipulation for para
virt domains.
In both of the above explanations, I don't know how to fit the "out_of_sync"
list
maintained by the VMM. Similarly, what is the reason behind using snapshots. For
64-bit system, where VMM has the whole physical ram mapped all the time, it
doesn't
seem to be of any use.
That is long enough for one email :-). I hope it does bore the list. Please do
reply even if you have a comment/suggestion/answer to only a smaller part of
the email.
Thanks and best regards,
Himanshu
--
-------------------------------------------------------------------------
Himanshu Raj
PhD Student, GaTech (www.cc.gatech.edu/~rhim)
I prefer to receive attachments in an open, non-proprietary format.
-------------------------------------------------------------------------
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home