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/
Home Products Support Community News


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

To: Mike Sun <msun@xxxxxxxxxx>
Subject: Re: [Xen-devel] Sharing Memory between userspace of dom0 and userspace of domU
From: Daniel Stodden <stodden@xxxxxxxxxx>
Date: Tue, 19 Feb 2008 18:02:46 +0100
Cc: Derek.Murray@xxxxxxxxxxxx, Kareem Dana <kareem.dana@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 19 Feb 2008 09:03:47 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <e4e579070802190816l6fb073b2hf5408fe3ea10bbfb@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Fakultät für Informatik I10, Technische Universität München
References: <3bb76bfe0802171554y34d668c9n48adb00a57cd799b@xxxxxxxxxxxxxx> <617dbaa80802180158g7207a21eg5688bbf927434cbb@xxxxxxxxxxxxxx> <e4e579070802190816l6fb073b2hf5408fe3ea10bbfb@xxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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.


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