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] Passing a grant reference to another domain!

To: Daniel Stodden <stodden@xxxxxxxxxx>
Subject: RE: [Xen-devel] Passing a grant reference to another domain!
From: "Jayaraman, Bhaskar" <Bhaskar.Jayaraman@xxxxxxx>
Date: Mon, 25 Aug 2008 18:06:29 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: Xen Developers <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Mon, 25 Aug 2008 03:07:14 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1219170108.7100.86.camel@xxxxxxxxxxxxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <7F0FB2108857B5449321AEA91CF47903185A6F6F82@xxxxxxxxxxxxxxxxx> <1219092118.19737.39.camel@xxxxxxxxxxxxxxxxxxxx> <7F0FB2108857B5449321AEA91CF47903185A8651F2@xxxxxxxxxxxxxxxxx> <1219170108.7100.86.camel@xxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AckCKHlYhs+0GYvpTm+SUEXsF9fhRgEYl8iA
Thread-topic: [Xen-devel] Passing a grant reference to another domain!
Daniel sorry for the late reply, from the mail threads in the past week I can 
see that grant references aren't supported in HVMs currently but we require it 
on HVMs so we can run unmodified OSes and code like a stubdom, which makes me 
conclude that stubdoms are PVs. Right?

        I'm using CentOS and I'm not sure how to use libxc because there aren't 
any man pages or docs that I'm able to look into but thanks for the tip on how 
the kernel is accessed from libxc.

        For accessing libxenstore from the kernel I guess I'm gonna have to go 
through the code and figure out which char devices these are and how the entry 
points are called and maybe invoke the char s/w table func pointer directly 
(still new to Linux kernel).

Thanks again.

-----Original Message-----
From: Daniel Stodden [mailto:stodden@xxxxxxxxxx]
Sent: Tuesday, August 19, 2008 11:52 PM
To: Jayaraman, Bhaskar
Cc: Xen Developers
Subject: RE: [Xen-devel] Passing a grant reference to another domain!

On Tue, 2008-08-19 at 15:54 +0800, Jayaraman, Bhaskar wrote:
> Daniel thanks for the reply, I have a few more q's.
> 1] A grant reference number is the array index in the grant table?


> 2] Passing more than one reference would require more than one key in the XS

> and the sharing domain will simply populate values and keys in xs, that

> are assumed to be known to the domain with which it is sharing those 
> references?

Yes, the key paths need to be known by convention. Note that access
privileges need consideration. This is trivial between dom0 (owning the
whole xenstore) and and domU (owning a respective subtree). Not sure
about different pairings.

> 3] The reason I'm asking you this is because I want to do so in an HVM which 
> is a requirement

> for my project. I am not sure if libxenstore is available for an HVM?? Also 
> since an

>  HVM cannot use the backend mechanism that blkfront and netfront drivers use, 
> I will

>  have to transfer pages using grant references on my own between domains if 
> I'm right??

Are you  really sure it really needs to be full virtualization
exclusively? XenStore is available to HVM as well. I'm not sure what's
presently available for userland access. Which OS?

> This is for making I/Os.
> 4] Plus if I want to transfer many pages, I will have to keep increasing my 
> memory

>  allocation with Xen by the number of pages that I lose as a result of sharing

> those pages and the shared domain will have to free up the shared pages

>  once used to remain within its prescribed memory allocation range?

It quite simple: You cannot allocate more memory than you have. Grant
tabs manage sharing, not allocation. Xen requires you to own the page
you're going to share. Thinking client/server, services typically employ
a scheme where the client is required allocates the memory needed to
fulfill his demands. Prevents DoS patterns and similar issues.

> 5] To pass a grant ref I guess I'll be doing the following: -
> In the sharing domain: -
> xsh = xs_domain_open()
> xth = xs_transaction_start(xsh)

Transactions are only necessary if the updates to xenstore are required
to be atomic. If you can do without them, don't use them. It's been a
while since I used libxs, but if you do transactions, I believe should
be an accompanying function call to commit it.

> xs_write(xsh, xth, "/local/domain/1/shm/tx-ring-ref", "2045", 5);
> xs_write(xsh, xth, "/local/domain/1/shm/rx-ring-ref", "2046", 5);
> In the shared domain: -
> xsh = xs_domain_open()
> xth = xs_transaction_start(xsh)
> char* val1 = xs_read(xsh, xth, "/local/domain/1/shm/tx-ring-ref", NULL);
> char* val2 = xs_read(xsh, xth, "/local/domain/1/shm/rx-ring-ref", NULL);
> Would this be a way of passing references between domains?

In part yes. Can the reading domain rely on the data being readily
available when it's going through that path?

If not, there's a concept called watches. Basically a callback mechanism
in which you can register. A change to the key you subscribed to will
let your (re-)read the new information without resorting to needless

> 6] If so, the above code uses libxenstore and this is is user space. Is there 
> a way to do this from kernel space?

For a PV kernel in support of libxc, all those libxc features just call
into to a chardev interface backed by the kernel.

But generally, it may depend on the OS you're targeting.


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