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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

> 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