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
|
Home