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

["Mike Sun" <msun@xxxxxxxxxx>]

Thanks Daniel, Derek.  I think that cleared up a good number of things for me.

Regarding page table pages...  you mentioned:
> 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.

My question is what would happen if the guest OS swaps out page table
pages and the mfn backing that PT page is now allocated to a normal
user page.  How would Xen know that the type of that page has changed
if this were allowed to happen?

Thanks,
Mike

On Feb 19, 2008 12:02 PM, Daniel Stodden <stodden@xxxxxxxxxx> wrote:
>
>
> 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