RE: [Xen-devel] paging mechanism clarification

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Pradeep Singh, TLS-Chennai
> Sent: 12 March 2007 05:56
> To: xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: [Xen-devel] paging mechanism clarification
> 
> 
> Hi All,
> 
> The Xen uses 2 level Paging Mechanism to resolve the Virtual 
> Addresses into frame numbers from domU.The first level is 
> taken care by the MMU for the domU i.e translation from 
> virtual address to the physical address just like normal 
> paging mechanism. The second level of translation is done by 
> the Xen hypervisor.It translates the pseduo physical address 
> recieved from the domU and treats it as a normal virtual 
> address and finds the page frame using regualr paging mechanism.

No, not in the current model. 

The paging in HVM (fully virtualized domains) is managed by the Shadow
paging, which simplified works like this:
When paging is disabled in the guest, still enable paging in the
processor and give a CR3 to the processor that points to a map of where
the guest memory is. 

When paging is enabled, we use a shadow page-table, which is essentially
that the GUEST sees one page-table, and the processor another (thanks to
the fact that the hypervisor intercepts the CR3 read/write operations,
and when CR3 is read back by the guest, we don't send back the value
it's ACTUALLY POINTING TO IN THE PROCESSOR, but the value that was set
by the guest). So there are two page-tables. 

To make the page-table updates by the guest visible to the hypervisor,
all of the guest-page-tables are made read-only (by scanning the new CR3
value whenever one is set). 

Whenever a page-fault happens, the hypervisor has "first look", and
determines if the update is for a page-table or not. If it is a
page-table update, the guest operation is emulated (in x86_emulate.c),
and the result is written to the shadow-page-table AND the
guest-page-table, but in the shadow-page-table, the value is modified to
reflect the actual address in machine-space, rather than what the guest
thinks it should be. 

In futuer versions of AMD processors (and I believe Intel are working on
something very similar if not the same), there will be a mode where the
processor is able to work in "nested paging mode", which means that
there are two "parallel" page-tables. The first one is the
"guest-page-table", the second one is the "host-page-table". In this
case, every lookup in the guest-page-table will be done through the
host-page-table. So we have a "simple" way to just take the
guest-page-table and translate it to machine-physical-address - with the
good thing that the host-page-table needn't change, since the pages that
the host consists of is pretty much static for the duration of the
guest. 

Say for example, we have a guest that lives at 256-512MB. The
guest-page-table would contain, for example, a mapping for 0x12200000 ->
guest-physical 0x100000 (1MB). The host-page-table translates this to
0x10100000 because the 1MB entry in guest-address is 256+1MB in
machine-address. 

[In reality, it's very likely that the guest never gets all the space in
one big chunk, but rather a few pages here and a few pages there. If
there are big chunks, we could use large pages to map those!]. 

The support for nested paging (called HAP, Hardware Assisted Paging) is
in the Unstable version of Xen since a few days back.

--
Mats
> 
> And this whole 2 level paging consitutes Xen's shadow page 
> tables. Right?
> 
> Is my understanding of Xen's paging mechanism correct?or am i 
> missing something?
> 
> Thank you
> 
> -pradeep 
> 
> 



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