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: "Derek Murray" <Derek.Murray@xxxxxxxxxxxx>
Date: Tue, 19 Feb 2008 16:59:16 +0000
Cc: Kareem Dana <kareem.dana@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 19 Feb 2008 08:59:45 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=87krGrIWt6NUqd+AzhVDzKl4KMP2aZ5UwHhXS02Tu3E=; b=Oyo78FKjEi/8ch2GSS9067w2pWEFTxcvVue6RU46hrNVQQXK3HGtexcrXtuRTtbs+vEvbFB6x9TVJ/0p9DuvXQFD0X8pxS0Qz52kKJO16+5nWDl4+c82j7HE/9SuYfkbFc3aoWOY/H9oirdHYFxWiBVeJujtMmIhpxOWHL1FDhA=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=mtvN2uRz3RNrfd7+3bauH5mEC9j1WPt5xqh9XXhj737YwOdh0HerewTZEvF3GClZngPkeEMplT8joajgO8WT4a9TQcepG+TbPJb5f9mNELayXJsCjGsKri1107sk8IeewU0TbpAxdraQFafBIVY/uB+wred7xo1vAdQLsu1GSW4=
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>
References: <3bb76bfe0802171554y34d668c9n48adb00a57cd799b@xxxxxxxxxxxxxx> <617dbaa80802180158g7207a21eg5688bbf927434cbb@xxxxxxxxxxxxxx> <e4e579070802190816l6fb073b2hf5408fe3ea10bbfb@xxxxxxxxxxxxxx>
Reply-to: Derek.Murray@xxxxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi Mike,

On Feb 19, 2008 4:16 PM, Mike Sun <msun@xxxxxxxxxx> wrote:
> > > 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?

A shared (granted) page is shared based on its (G)MFN. There is in
fact no interaction with Xen when granting a page, as this can be done
by simply writing to the grant table.

The granted physical page is pinned when it is mapped, however, this
only means that, if the granting domain dies, the page is not freed

However, as far as I can tell, the granting domain is free to do
whatever it likes with the physical page. Therefore, if the process
containing the granted page dies, you need to keep a reference to the
physical page that was granted, because another domain has mapped it
and can therefore read the contents of the page, or overwrite them.
This could cause a security problem or unexpected behaviour in the
granting domain.

Likewise, if the kernel decided to swap out the page that you granted,
and replace it with another virtual page, you would not  observe the
effect of granting access to a particular virtual address (which is
all you would know about in user-space). Therefore you would have to
pin the page using mlock() or something similar.

I hope this makes things clearer, but let me know if anything I've
said doesn't make sense.


Derek Murray.

Xen-devel mailing list