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] Shadow page table questions

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Shadow page table questions
From: Arne Mejlholm <mejlholm@xxxxxxxxx>
Date: Wed, 19 Apr 2006 12:35:24 +0200
Delivery-date: Wed, 19 Apr 2006 03:35:50 -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: Thunderbird 1.5 (X11/20051201)
Dear All,

I'm trying to understand some of the details of the shadow page table
implementation. In particular I'm interested in the inner workings of
translated mode.

Now as I understand it, the principle behind Shadow Page Tables (SPTs)
is to provide a level of indirection between virtual and machine
addresses. In Xen this is implemented by a P2M table for each domain (at
least in translated mode this address space is reused). Each entry in
this table is indexed by "physical" addresses and point to a given
machine frame number (mfn). As far as I can tell from the code, this
structure is walked much like a normal page table. In translated mode
the guest VM however cannot make use of the two level lookup (first
from virtual to physical and then from physical to machine addresses),
so a hardware specific version (the SPT) of the two mappings is
produced and given to the MMU instead of the ordinary page table.

My first question is have the status bits of each entry in the P2M
table changed semantics (compared to a normal l1 entry) or do they
signify the same flags? If the read/write flag is not set (read only),
will this be propagated to the SPT seen by the MMU?

Normally producing a SPT each time a the cr3 register is updated (as
required per context switch), is considered to be an overhead. One
solution to this is to make use of a cache, where references to old
SPTs are kept. This again involves the overhead in terms of memory
usage and tracking if the cached SPT is valid.

My second question is thus, does the implementation make use of a SPT
cache or are SPTs produced on demand? If a cache is used, can anyone
give me pointers to where I can find this structure?

The implementation makes use of snapshots, how do these fit into big

Finally some of the terminology used for the implementation seems a
bit un-intuitive to me. Throughout the source, there is the concept of
a hl2 table. As far as I can tell, a l2 table is the PGD in Linux
kernel terminology and a l1 table is the table pointed to by an entry
in the l2 table (PT in Linux). My first guess was that the hl2 table
was the table actually pointed to by the cr3 register, but I cannot
seem to confirm this. What does the h in hl2 stand for and what is it
used for?

Thank you,
Arne Mejlholm

Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] Shadow page table questions, Arne Mejlholm <=