[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
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 Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |