Thanks Mark, the Xenbus drivers you're talking about are for a paravirtualized
kernel. Any idea if these are being ported onto an HVM? If not grant references
can be passed around in HVMs using TCP connects?
Assuming I'm accesing XS from an HVM or PV guest, for guest A to read a grant
reference from guest B's xenstored dictionary path it will need to know the
domain ID of B. There's no way of assigning specific or known domainID while VM
creation. So how will they each know what their respective domain IDs are to go
and read each others' grant references from a known key?
Bhaskar.
-----Original Message-----
From: M.A. Williamson [mailto:maw48@xxxxxxxxxxxxxxxx] On Behalf Of Mark
Williamson
Sent: Monday, August 25, 2008 9:36 PM
To: xen-devel@xxxxxxxxxxxxxxxxxxx
Cc: Jayaraman, Bhaskar; Daniel Stodden
Subject: Re: [Xen-devel] Passing a grant reference to another domain!
On Monday 25 August 2008 11:06:29 Jayaraman, Bhaskar 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?
>
> 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).
You can access Xenstore functionality directly from an in-kernel API in either
a PV domain or an HVM domain with PV drivers installed. Would this be
adequate for your needs? You probably shouldn't need to hijack any userspace
APIs for this part of your work.
The in-kernel API to Xenstore is called "Xenbus". Interesting files for you
include:
drivers/xen/xenbus/*
include/xen/xenbus.h
drivers/xen/{blkback,netback}/xenbus.c
drivers/xen/{blkfront,netfront}/*.c
Hope this helps,
Cheers,
Mark
> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home