[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: Derek.Murray@xxxxxxxxxxxx
  • From: "Kareem Dana" <kareem.dana@xxxxxxxxx>
  • Date: Tue, 19 Feb 2008 11:03:47 -0500
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 19 Feb 2008 08:04:48 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=O6Q4mvQtgkGJycuYnAKemIcJPA/XZRmf2mIh8SiZaCLbtfRSUSKBn961ENYe9/XRKzUkEidxVrNkOUbnLp2P37ftENPyyhCe8el+0QVISMf5Qeu2qs6PphKDJzwwIYnVuNs7MAHwXukactIjkV5yCSSv6+z+Wh4VsWQ9+ELOT+A=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

Thanks Derek. This info helped a lot. I'll try to post my code/results
back when I get some more time to work on a kernel module.

On Feb 18, 2008 4:58 AM, Derek Murray <Derek.Murray@xxxxxxxxxxxx> wrote:
> 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



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