WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] Info regarding implementation of page tables

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Info regarding implementation of page tables
From: jeet <jeet_sat12@xxxxxxxxxxx>
Date: Fri, 23 Feb 2007 11:17:33 +0530 (IST)
Delivery-date: Thu, 22 Feb 2007 21:47:00 -0800
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=Zu95Co+kTQJSAZaDbvq7gvPQ2P2Y0yJOKgb7ouQ2EVg2lCNLf8KbnKGpEiCNwAWtFF1xOtD5Pq9v31qsfvdVuvUu61pVUP3hBwtDKyJuI2cgtEC8TRKfvFqh7+uYXov7I+hMcqKebd66ELxiroiJL6nE6ZCZEFOxffImCRnuoYw=;
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
Hi All,

I am trying to understand shadow implementation in Xen for HVM (intel vt-x)

A guest operating system is given a range of "physical" memory to 
work with, and it implements its own page tables to map between its virtual 
address spaces and that memory range. But the guest's "physical" memory is a 
virtual range administered by the host; guests do not deal directly with "bare 
metal" memory (RAM).
 The result is that there are actually two sets of page tables 
between a virtual address space on a virtualized guest and the real, physical 
memory it maps to. The guest can set up one level of translation (guest page 
table), but only the 
host can manage the mapping between the guest's "physical" memory and the real 
thing.


This situation is handled by way of shadow page tables. The guest OS thinks it 
is maintaining its own page tables, but the processor 
does not actually use them. Instead, the VMM implements a "shadow" table 
which mirror's the guest's table, but which maps guest virtual addresses 
directly to physical addresses(RAM).


 When a guest is created all the shadow table entry are invaild(empty); every 
page 
fault on the guest then results in the filling in of the appropriate shadow 
entry. Once the guest has faulted in the pages it needs, it will be able to run 
at native speed with no further hypervisor attention required. 



But once the guest performs a context switch, shadow page table is dumped and a 
new one is started. Changing 
the shadow table is required, since the process running after the context 
switch 
will have a different set of address mappings. 
 

Is this how, shadow page table is implemented in xen?
if not It would be great help if any one could explain implementation of shadow 
PT in Xen.

TIA
jeet






                
__________________________________________________________
Yahoo! India Answers: Share what you know. Learn something new
http://in.answers.yahoo.com/

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

<Prev in Thread] Current Thread [Next in Thread>
  • [Xen-devel] Info regarding implementation of page tables, jeet <=