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

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


  • To: "Kareem Dana" <kareem.dana@xxxxxxxxx>
  • From: "Derek Murray" <Derek.Murray@xxxxxxxxxxxx>
  • Date: Mon, 18 Feb 2008 09:58:37 +0000
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 18 Feb 2008 01:59:03 -0800
  • 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=oX+wbu7yE7eamXIHqGo9sy7RJMHcd4POzBP8+oVjckFT2azZEMbWJab/3OlOQr94uZPlBF9SIAI/v8nnMV+rr7JqUPnujSR5N4yVkPuEtbPkB3ya4BMjD3heRmuz5+9X8ZfdlchjVV8NukhUUJBuP9ACRnzOk8FfoDfgxQaq/Wo=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Hi Kareem,

On Feb 17, 2008 11:54 PM, Kareem Dana <kareem.dana@xxxxxxxxx> wrote:
> I'm trying to better understand how xen shares memory between domains.
> Ultimately what I would like to do is share memory between a userspace
> tool in dom0 and a userspace application running in domU. Is that
> currently possible?

At present, this isn't supported in the tools, however there is no
technological reason why we couldn't do this.

> The two methods for sharing memory that I found were grant tables and
> using xc_map_foreign_range(). Grant tables seem to be just for kernel
> space? I found xc_gnttab_map_grant_ref and other xc_gnttab_ userspace
> API, but that requires a grant reference and I don't see a way to
> generate or even get a grant reference from userspace.

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.

> Second, I tried xc_map_foreign_range() from my dom0 userspace program.
> I started up a userspace program in domU and told it to malloc several
> bytes of memory and print out the virtual address returned by malloc.
> It wrote the string "hello" to the memory location and then just sat
> in a loop. Then I started up a userspace program in dom0 and ran
> xc_translate_foreign_address on the given virtual address and used
> that as my MFN for xc_map_foreign_range. No errors were returned but
> the memory mapped to dom0 is just garbage compared to "hello". When I
> specify an arbitrary virtual address for xc_translate_foreign_address,
> it generally gives me an error saying that address is not valid. So I
> assume I'm doing something right, but I must be missing something.
> What am I doing wrong with this?

One possibility is that your process is not active when you run
xc_translate_foreign_address: this function works on the basis of a
VCPU id, and your process must have its page directory base address in
CR3 on that VCPU for the translation to succeed.

> If none of these methods are supposed to be used in this manner, is
> there any way to share memory between user programs in different
> domains like I'm trying to do?

You're going to need a kernel module to achieve this. I can think of
two approaches:

* Allocate a buffer in the kernel, grant another domain access to this
buffer, and mmap it into your process. (I've managed to get this to
work, but it's not yet robust.)
* Allocate a buffer in userspace, then use get_user_pages and kmap to
map it into the kernel, and then grant access to the other domain.
(Michael Abd-El-Malek had success with this method, as described in
this thread: 
http://lists.xensource.com/archives/html/xen-devel/2008-01/msg01204.html
)

Hope this helps!

Regards,

Derek Murray.

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


 


Rackspace

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