This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Understanding shadow page tables for fully virtualized guest

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Understanding shadow page tables for fully virtualized guests ....
From: Himanshu Raj <rhim@xxxxxxxxxxxxx>
Date: Tue, 2 May 2006 16:57:05 -0400
Cc: Ivan Borissov Ganev <ganev@xxxxxxxxxxxxx>
Delivery-date: Tue, 02 May 2006 13:57:29 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.1i
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

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 
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 
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" 
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 
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 Raj
PhD Student, GaTech (www.cc.gatech.edu/~rhim)
I prefer to receive attachments in an open, non-proprietary format.

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] Understanding shadow page tables for fully virtualized guests ...., Himanshu Raj <=