RE: [Xen-devel] Passing a grant reference to another domain!

[Daniel Stodden <stodden@xxxxxxxxxx>]

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?

Yup.

> 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
polling.

> 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

-- 
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel