Re: [Xen-devel] Sharing Memory between userspace of dom0 and userspace of domU

[Daniel Stodden <stodden@xxxxxxxxxx>]

On Tue, 2008-02-19 at 11:16 -0500, Mike Sun wrote:
> Hi --
> 
> > > At the moment, yes, the only way to grant access to a page is from the
> > > kernel. This is due to the fact that kernel memory corresponds to
> > > physical memory, and we don't have to worry about interactions with
> > > the swapper, or what happens when the process dies.
> 
> >From what I understand of what you've said, are you saying that the
> shared memory pages that granted access must always be in physical
> memory and cannot be swapped out, even if the guest kernel decided to
> for some reason?  Does Xen enforce this in any way, e.g. pinning the
> pages somehow?

Xen never swaps out domain pages. So there's no need to pin them on the
side of the VMM. I believe that will answer your original question
regarding swapping out of domain page tables. 

Regarding swapping by domains: For memory mapped across domains, or
shared with the VMM by dom0 *tools*, the control library will presently
take care to properly mlock() the pages. Kernel space memory (e.g.
shared by driver pairs) is typically not swappable, or will get marked
accordingly. Generally, it's the domain's own responsibility to keep the
maps consistent, as it is solely its own security and stability which
suffers otherwise.

Regarding you question how Xen distinguishes page frame types (i.e. page
tables): A page frame becomes a page table to Xen, as soon as the domain
makes it so (e.g. by linking cr3 to it, or referencing it in the page
directory,... etc.). The overall mechanism is that all (most) of these
operations are done with hypercalls. There's no writable access to page
tables, and Xen enforces this. Xen will declare the memory a PT and keep
a reference count which keeps it that way. Take a look into the Xen
interface manual and/or e.g. arch/x86/mm.c if you're interested in that.

regards,
Daniel

-- 
Daniel Stodden
LRR     -      Lehrstuhl fÃr Rechnertechnik und Rechnerorganisation
Institut fÃr Informatik der TU MÃnchen             D-85748 Garching
http://www.lrr.in.tum.de/~stodden         mailto:stodden@xxxxxxxxxx
PGP Fingerprint: F5A4 1575 4C56 E26A 0B33  3D80 457E 82AE B0D8 735B



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