[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

> 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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.