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

Re: [Xen-devel] And if guestOS doesn't register a new page...

To: Guillaume Thouvenin <guillaume.thouvenin@xxxxxxxxxx>
Subject: Re: [Xen-devel] And if guestOS doesn't register a new page...
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Thu, 20 Nov 2003 10:40:55 +0000
Cc: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 20 Nov 2003 10:43:14 +0000
Envelope-to: steven.hand@xxxxxxxxxxxx
In-reply-to: Your message of "Thu, 20 Nov 2003 05:34:32 EST." <1069324472.3fbc98b87d167@xxxxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
> I'm currently reading the xen source (it's very intresting and cool :) and I
> have a question concerning the memory management. To improve performance you
> decided that the GuestOS is responsible for managing his hardware page table. 
> It
> just have to register its memory manipulations to Xen (using hypercall
> HYPERVISOR_update_va_mapping() I think). 

The fully general hypercall is
HYPERVISOR_mmu_update. update_va_mapping is a 'fast' call that is
useful when synchronously fixing up page faults.

> At this point, guestOS relinquishes write privilege. This mechanism ensure 
> that
> a guestOS will not modify its page table for accessing memory owning by 
> another
> domain because Xen control that. So, the safety and isolation (concerning the
> guestOS memory management) is allowed because guestOS registers its allocation
> to the hypervisor. Thus, what happens if I build a guestOS which will not
> register allocation? it could generate some problems? 

It cannot. This is because only page tables that have been registered
with Xen can ever be written to register CR3 (and therefore be used by
the real MMU). This is checked by Xen -- only Xen can change the
contents of CR3. See MMUEXT_NEW_BASEPTR in common/memory.c.

 -- Keir


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel

<Prev in Thread] Current Thread [Next in Thread>