On Mon, Aug 25, 2008 at 3:36 PM, Jayaraman, Bhaskar
<Bhaskar.Jayaraman@xxxxxxx> wrote:
> 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?
Yes they are PV domains.
Thanks,
--Pradeep
> 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.
> Bhaskar.
>
> -----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?
>
> 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
>
--
Pradeep Singh Rautela
http://eagain.wordpress.com
http://emptydomain.googlepages.com
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home