[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: "Jayaraman, Bhaskar" <Bhaskar.Jayaraman@xxxxxxx>
  • From: "pradeep singh rautela" <rautelap@xxxxxxxxx>
  • Date: Mon, 25 Aug 2008 15:49:40 +0530
  • Cc: Xen Developers <xen-devel@xxxxxxxxxxxxxxxxxxx>, Daniel Stodden <stodden@xxxxxxxxxx>
  • Delivery-date: Mon, 25 Aug 2008 03:20:04 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=wUWA/aiFSKEVSgfmoQGc8VcS3UB418MAaUJOQrYguTyo+X1nDmFhmhpIwMvubataN2 NSo0iR2dpY31lAKIUQwghOfN2G7F79QQXJFJnA8y5MGWrMXnr4QuBVYR0A9QhjlP+QZQ vwd7XKeiPpdOdK2BuQNIO7gzpMNmini/bVRtc=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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.


>        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
Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.