xenstore documentation

xenstore documentation

[Jacob Gorm Hansen]

hi,

it would be extremely useful for me if someone with knowledge of how
the current tools and drivers use Xenstore would be kind enough to
update the Wiki with current information. I have been spending quite a
lot of time trying to get my domU connected to a block device in dom0
using a home-brewed domain creation tool, and I am still at the
'Timeout connecting to device!' stage.

My stragegy has been to log all calls to xs_write() under Xend, and
then replay those same calls with my own tool on a freshly booted
machine, but to no avail. In general things work with Xend, at least
as long as I am not trying to restart xenstored without a reboot.

I have noticed that with the most recent Xen-unstable, the store is
now split into /vm and /local, but there seems to be some overlap,
e.g. UUIDs are in some cases referred from /local even though they
seem to only belong in /vm. Also, the amount of info in the store
seems to be growing to Windows Registry-like proportions, making it
very hard to keep up and the store hard to navigate. Perhaps we could
agree not to write any default settings to the store to save some
space and confusion?

Thanks in advance,
Jacob
--
Save time and bandwidth with EDelta: http://www.diku.dk/~jacobg/edelta/

Re: xenstore documentation

[Rami Rosen]

[-- Attachment #1.1: Type: text/plain, Size: 2134 bytes --]

Hello ,

I had written some pages which I had inserted into XenWiki this morning.
It is in http://wiki.xensource.com/xenwiki/XenIntro.

This is an initial draft, and I intend to deliver an enhanced version
in a few days, and to update it from time to time.

Currently It deals with XenStore,frontend/backend drivers,Xend daemon, but
it
is still very partial and there is still a lot to add.

It will probably not help you with this specific problem,
but I hope that this may be a helpful resource for everybody, espcially when
I will add more into it.

Regards,
Rami Rosen

On 10/3/05, Jacob Gorm Hansen <jacobg@diku.dk> wrote:
>
> hi,
>
> it would be extremely useful for me if someone with knowledge of how
> the current tools and drivers use Xenstore would be kind enough to
> update the Wiki with current information. I have been spending quite a
> lot of time trying to get my domU connected to a block device in dom0
> using a home-brewed domain creation tool, and I am still at the
> 'Timeout connecting to device!' stage.
>
> My stragegy has been to log all calls to xs_write() under Xend, and
> then replay those same calls with my own tool on a freshly booted
> machine, but to no avail. In general things work with Xend, at least
> as long as I am not trying to restart xenstored without a reboot.
>
> I have noticed that with the most recent Xen-unstable, the store is
> now split into /vm and /local, but there seems to be some overlap,
> e.g. UUIDs are in some cases referred from /local even though they
> seem to only belong in /vm. Also, the amount of info in the store
> seems to be growing to Windows Registry-like proportions, making it
> very hard to keep up and the store hard to navigate. Perhaps we could
> agree not to write any default settings to the store to save some
> space and confusion?
>
> Thanks in advance,
> Jacob
> --
> Save time and bandwidth with EDelta: http://www.diku.dk/~jacobg/edelta/
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>

[-- Attachment #1.2: Type: text/html, Size: 2707 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: xenstore documentation

[Jacob Gorm Hansen]

On 10/4/05, Rami Rosen <rosenrami@gmail.com> wrote:
> Hello ,
>
>  I had written some pages which I had inserted into XenWiki this morning.
>  It is in http://wiki.xensource.com/xenwiki/XenIntro.

Thanks a lot for this work. I suppose my main problem right now is
finding out why the backend probe function is never called. Does
anyone know what the tools in dom0 have to do to trigger the backend
driver probe function?

Thanks,
Jacob

Re: xenstore documentation

[harry]

If you look at writeDetails in
tools/python/xen/xend/server/DevController.py you'll see the
transactions which cause the back and front ends to get probed.

The transactions contain extra fields as provided by the derived class
specific to the device type and are written into the store in the
locations constructed in the frontendPath and backendPath functions in
DevController.py.  These paths contain the device id string as specified
when you registered your xenbus drivers.

Looking at the current code, it looks like
domainpath/backend/device_class/frontend_uuid/device_id/transaction_stuff_here
for the back-end and and
domainpath/device_id/transaction_stuff_here
for the front-end.

HTH

Harry.

On Tue, 2005-10-04 at 14:20 +0200, Jacob Gorm Hansen wrote:
> On 10/4/05, Rami Rosen <rosenrami@gmail.com> wrote:
> > Hello ,
> >
> >  I had written some pages which I had inserted into XenWiki this morning.
> >  It is in http://wiki.xensource.com/xenwiki/XenIntro.
> 
> Thanks a lot for this work. I suppose my main problem right now is
> finding out why the backend probe function is never called. Does
> anyone know what the tools in dom0 have to do to trigger the backend
> driver probe function?
> 
> Thanks,
> Jacob
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

Re: xenstore documentation

[harry]

Sorry, I think that should have been

domainpath/device/device_class/device_id/transaction_stuff_here for the
front_end.

Also, see correction below:

On Tue, 2005-10-04 at 13:42 +0100, harry wrote:
> If you look at writeDetails in
> tools/python/xen/xend/server/DevController.py you'll see the
> transactions which cause the back and front ends to get probed.
> 
> The transactions contain extra fields as provided by the derived class
> specific to the device type and are written into the store in the
> locations constructed in the frontendPath and backendPath functions in
> DevController.py.  These paths contain the

> device id - nope.

device_class

> string as specified
> when you registered your xenbus drivers.
> 
> Looking at the current code, it looks like
> domainpath/backend/device_class/frontend_uuid/device_id/transaction_stuff_here
> for the back-end and and
> domainpath/device_id/transaction_stuff_here
> for the front-end.
> 
> HTH
> 
> Harry.
> 
> On Tue, 2005-10-04 at 14:20 +0200, Jacob Gorm Hansen wrote:
> > On 10/4/05, Rami Rosen <rosenrami@gmail.com> wrote:
> > > Hello ,
> > >
> > >  I had written some pages which I had inserted into XenWiki this morning.
> > >  It is in http://wiki.xensource.com/xenwiki/XenIntro.
> > 
> > Thanks a lot for this work. I suppose my main problem right now is
> > finding out why the backend probe function is never called. Does
> > anyone know what the tools in dom0 have to do to trigger the backend
> > driver probe function?
> > 
> > Thanks,
> > Jacob
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> > 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

Re: xenstore documentation

[NAHieu]

On 10/4/05, harry <harry@hebutterworth.freeserve.co.uk> wrote:
> If you look at writeDetails in
> tools/python/xen/xend/server/DevController.py you'll see the
> transactions which cause the back and front ends to get probed.
>
> The transactions contain extra fields as provided by the derived class
> specific to the device type and are written into the store in the
> locations constructed in the frontendPath and backendPath functions in
> DevController.py.  These paths contain the device id string as specified
> when you registered your xenbus drivers.
>

Does that mean if I want to write a new split device, I must patch
xend to let it aware of the new type of device?

I have the same problem here: I am struggling on the first simple
backend/frontend driver, and I cannot figure out why probe functions
in the frontend is not called.

Jacob, would you please share some of your experiences if you make
your code run successfully?

Many thanks.
Hieu.

Re: xenstore documentation

[Jacob Gorm Hansen]

(longing for the days when all one had to do was poke a few values in /proc/xen)

On 10/4/05, harry <harry@hebutterworth.freeserve.co.uk> wrote:

> > Looking at the current code, it looks like domainpath/backend/device_class/frontend_uuid/device_id/transaction_stuff_here
> > for the back-end and and
> > domainpath/device_id/transaction_stuff_here
> > for the front-end.

Hmm why does the backend need to deal with the uuid, I thought that
was solely for the tools? So to recap, I have to:

- introduce dom0 to xenstore, with prefix=/local/domain/0
- mkdir /local/domain/0/backend
- mkdir /local/domain/0/device

And that will trigger the blkback-probe? Sorry if I am sounding
confused, but I am fairly confident this stuff is more complex than it
needs to be.

Thanks,
Jacob

Re: xenstore documentation

[harry]

On Tue, 2005-10-04 at 14:56 +0200, Jacob Gorm Hansen wrote:
> (longing for the days when all one had to do was poke a few values in /proc/xen)
> 
> On 10/4/05, harry <harry@hebutterworth.freeserve.co.uk> wrote:
> 
> > > Looking at the current code, it looks like domainpath/backend/device_class/frontend_uuid/device_id/transaction_stuff_here
> > > for the back-end and and
> > > domainpath/device_id/transaction_stuff_here
> > > for the front-end.
> 
> Hmm why does the backend need to deal with the uuid, I thought that
> was solely for the tools? So to recap, I have to:
> 
> - introduce dom0 to xenstore, with prefix=/local/domain/0
> - mkdir /local/domain/0/backend
> - mkdir /local/domain/0/device

I doubt that mkdir will work.  I would expect that you would have to go
through xenstored to modify the store.  vm-tools contained a utility to
submit an arbitrary transaction to xenstored.

> 
> And that will trigger the blkback-probe? Sorry if I am sounding
> confused, but I am fairly confident this stuff is more complex than it
> needs to be.

Ouch, don't shoot the messenger.

> 
> Thanks,
> Jacob
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

Re: xenstore documentation

[harry]

On Tue, 2005-10-04 at 21:55 +0900, NAHieu wrote:
> On 10/4/05, harry <harry@hebutterworth.freeserve.co.uk> wrote:
> > If you look at writeDetails in
> > tools/python/xen/xend/server/DevController.py you'll see the
> > transactions which cause the back and front ends to get probed.
> >
> > The transactions contain extra fields as provided by the derived class
> > specific to the device type and are written into the store in the
> > locations constructed in the frontendPath and backendPath functions in
> > DevController.py.  These paths contain the device id string as specified
> > when you registered your xenbus drivers.
> >
> 
> Does that mean if I want to write a new split device, I must patch
> xend to let it aware of the new type of device?

Yes.  You have to add a new class in python/xen/xend/server (see
blkif.py as an example) and then hook this class into xend in
XendDomainInfo.py and xm/create.py to get the config parameters passed
correctly.

> 
> I have the same problem here: I am struggling on the first simple
> backend/frontend driver, and I cannot figure out why probe functions
> in the frontend is not called.

Well, I have managed to get my probe functions called successfully :-)
But I'm struggling with creating a mechanism which correctly constructs
and tears-down the shared memory page in all the following scenarios:

FE module load/unload
BE module load/unload
device hot plug/remove
domain suspend/resume
domain start/stop

If someone with superior understanding would like to document a complete
solution that would be really helpful.

Harry.
> 
> Jacob, would you please share some of your experiences if you make
> your code run successfully?
> 
> Many thanks.
> Hieu.
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

Re: xenstore documentation

[Jacob Gorm Hansen]

On 10/4/05, harry <harry@hebutterworth.freeserve.co.uk> wrote:


> I doubt that mkdir will work.  I would expect that you would have to go
> through xenstored to modify the store.  vm-tools contained a utility to
> submit an arbitrary transaction to xenstored.

Sorry, I meant xs_mkdir().

> > And that will trigger the blkback-probe? Sorry if I am sounding
> > confused, but I am fairly confident this stuff is more complex than it
> > needs to be.
>
> Ouch, don't shoot the messenger.

Sorry about that too, whoever dreamed this whole thing up has not been
able to answer my increasingly desperate cries for help recently, and
I am a little frustrated with the amount of time I have spent just
getting a simple block device attached.

Jacob

Re: xenstore documentation

[Rolf Neugebauer]

On Tue, 2005-10-04 at 14:25, harry wrote:
> On Tue, 2005-10-04 at 21:55 +0900, NAHieu wrote:
> > On 10/4/05, harry <harry@hebutterworth.freeserve.co.uk> wrote:
> > > If you look at writeDetails in
> > > tools/python/xen/xend/server/DevController.py you'll see the
> > > transactions which cause the back and front ends to get probed.
> > >
> > > The transactions contain extra fields as provided by the derived class
> > > specific to the device type and are written into the store in the
> > > locations constructed in the frontendPath and backendPath functions in
> > > DevController.py.  These paths contain the device id string as specified
> > > when you registered your xenbus drivers.
> > >
> > 
> > Does that mean if I want to write a new split device, I must patch
> > xend to let it aware of the new type of device?
> 
> Yes.  You have to add a new class in python/xen/xend/server (see
> blkif.py as an example) and then hook this class into xend in
> XendDomainInfo.py and xm/create.py to get the config parameters passed
> correctly.

or no ;) depending on what you want to do. so for example if you only
ever have one backend in the system then you "could" store that under a
well known name in the store and the frontends can simply read that.
you'll also need a place for the BE to watch for FE updates in a similar
fashion.

however this pretty adhoc and breaks a few conventions and might not
work with well save/restore etc.but for prototyping it is sufficient and
doesn't require xend mods.

if you want the split device be general available you'd probably have to
mod xend. 

Rolf

> > 
> > I have the same problem here: I am struggling on the first simple
> > backend/frontend driver, and I cannot figure out why probe functions
> > in the frontend is not called.
> 
> Well, I have managed to get my probe functions called successfully :-)
> But I'm struggling with creating a mechanism which correctly constructs
> and tears-down the shared memory page in all the following scenarios:
> 
> FE module load/unload
> BE module load/unload
> device hot plug/remove
> domain suspend/resume
> domain start/stop
> 
> If someone with superior understanding would like to document a complete
> solution that would be really helpful.
> 
> Harry.
> > 
> > Jacob, would you please share some of your experiences if you make
> > your code run successfully?
> > 
> > Many thanks.
> > Hieu.
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@lists.xensource.com
> > http://lists.xensource.com/xen-devel
> > 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel

Re: xenstore documentation

[Anthony Liguori]

Jacob Gorm Hansen wrote:

>Sorry about that too, whoever dreamed this whole thing up has not been
>able to answer my increasingly desperate cries for help recently, and
>I am a little frustrated with the amount of time I have spent just
>getting a simple block device attached.
>  
>
1) Create domain
    domid = 0
    xc_domain_create(&domid)
    xc_domain_maxmem(domid, memory >> 10);
    xc_domain_memory_increase_reservation(domid, memory >> 12);

2) Build domain
    lconsole = rconsole = 0;
    xc_evtchn_bind_interdomain(0, domid, &lconsole, &rconsole);
    lstore = rstore = 0;
    xc_evtchn_bind_interdomain(0, domid, &lconsole, &rconsole);

    xc_linux_build(domid, kernel, ramdisk, cmdline, 0, vcpus, rstore, 
&mfn_store, rconsole, &mfn_console)
    home = "/tools/<yourtool>/domain/%d" % domid
    xs_domain_introduce(domid, mfn_store, lstore, home);
    xs_write(home + "/console/ring-ref", mfn_console)
    xs_write(home + "/console/port", lconsole)

3) Create block device (pdev, vdev)
    static int uuid;

    dom0_home = xs_get_domain_path(0)

    backend = dom0_home + "/backend/vbd/%s/%s' % (uuid, domid)
    frontend = home + "/device/vbd/%s' % uuid

    transaction_start()
    xs_write(backend + "/frontend", frontend);
    xs_write(backend + "/frontend-id", domid);
    transaction_end()

    transaction_start()
    xs_write(frontend + "/backend", backend);
    xs_write(frontend + "/backend-id", 0);
    xs_write(frontend + "/virtual-device", vdev)
    transaction_end()

    xs_write(backend + "/physical-device", pdev)

This might seem complicated, but compared to what you had to do under 
2.0.x, it's a 1000x times easier.

Regards,

Anthony Liguori

>Jacob
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel
>
>  
>

Re: xenstore documentation

[Nivedita Singhvi]

Anthony Liguori wrote:
> Jacob Gorm Hansen wrote:

> 1) Create domain
>    domid = 0
>    xc_domain_create(&domid)
>    xc_domain_maxmem(domid, memory >> 10);
>    xc_domain_memory_increase_reservation(domid, memory >> 12);

Hi Anthony,

Sounds like you're the right person to get the interface
documentation written? :). Would be very helpful.

thanks,
Nivedita


> 2) Build domain
>    lconsole = rconsole = 0;
>    xc_evtchn_bind_interdomain(0, domid, &lconsole, &rconsole);
>    lstore = rstore = 0;
>    xc_evtchn_bind_interdomain(0, domid, &lconsole, &rconsole);
> 
>    xc_linux_build(domid, kernel, ramdisk, cmdline, 0, vcpus, rstore, 
> &mfn_store, rconsole, &mfn_console)
>    home = "/tools/<yourtool>/domain/%d" % domid
>    xs_domain_introduce(domid, mfn_store, lstore, home);
>    xs_write(home + "/console/ring-ref", mfn_console)
>    xs_write(home + "/console/port", lconsole)
> 
> 3) Create block device (pdev, vdev)
>    static int uuid;
> 
>    dom0_home = xs_get_domain_path(0)
> 
>    backend = dom0_home + "/backend/vbd/%s/%s' % (uuid, domid)
>    frontend = home + "/device/vbd/%s' % uuid
> 
>    transaction_start()
>    xs_write(backend + "/frontend", frontend);
>    xs_write(backend + "/frontend-id", domid);
>    transaction_end()
> 
>    transaction_start()
>    xs_write(frontend + "/backend", backend);
>    xs_write(frontend + "/backend-id", 0);
>    xs_write(frontend + "/virtual-device", vdev)
>    transaction_end()
> 
>    xs_write(backend + "/physical-device", pdev)
> 
> This might seem complicated, but compared to what you had to do under 
> 2.0.x, it's a 1000x times easier.
> 
> Regards,
> 
> Anthony Liguori
> 
>> Jacob
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>>  
>>
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
> 

Re: xenstore documentation

[Jacob Gorm Hansen]

Excellent, thank you!

One question: What (if anything) do I need to do to introduce dom0 and
xenstore to eachother?

Thanks again, just what I was looking for.
Jacob

Re: xenstore documentation

[Anthony Liguori]

Nivedita Singhvi wrote:

> Anthony Liguori wrote:
>
>> Jacob Gorm Hansen wrote:
>
>
>> 1) Create domain
>>    domid = 0
>>    xc_domain_create(&domid)
>>    xc_domain_maxmem(domid, memory >> 10);
>>    xc_domain_memory_increase_reservation(domid, memory >> 12);
>
>
> Hi Anthony,
>
> Sounds like you're the right person to get the interface
> documentation written? :). Would be very helpful.

Doh!  Seriously though, I'm more than happy to once 3.0 ships.

Regards,

Anthony Liguori

> thanks,
> Nivedita
>
>
>> 2) Build domain
>>    lconsole = rconsole = 0;
>>    xc_evtchn_bind_interdomain(0, domid, &lconsole, &rconsole);
>>    lstore = rstore = 0;
>>    xc_evtchn_bind_interdomain(0, domid, &lconsole, &rconsole);
>>
>>    xc_linux_build(domid, kernel, ramdisk, cmdline, 0, vcpus, rstore, 
>> &mfn_store, rconsole, &mfn_console)
>>    home = "/tools/<yourtool>/domain/%d" % domid
>>    xs_domain_introduce(domid, mfn_store, lstore, home);
>>    xs_write(home + "/console/ring-ref", mfn_console)
>>    xs_write(home + "/console/port", lconsole)
>>
>> 3) Create block device (pdev, vdev)
>>    static int uuid;
>>
>>    dom0_home = xs_get_domain_path(0)
>>
>>    backend = dom0_home + "/backend/vbd/%s/%s' % (uuid, domid)
>>    frontend = home + "/device/vbd/%s' % uuid
>>
>>    transaction_start()
>>    xs_write(backend + "/frontend", frontend);
>>    xs_write(backend + "/frontend-id", domid);
>>    transaction_end()
>>
>>    transaction_start()
>>    xs_write(frontend + "/backend", backend);
>>    xs_write(frontend + "/backend-id", 0);
>>    xs_write(frontend + "/virtual-device", vdev)
>>    transaction_end()
>>
>>    xs_write(backend + "/physical-device", pdev)
>>
>> This might seem complicated, but compared to what you had to do under 
>> 2.0.x, it's a 1000x times easier.
>>
>> Regards,
>>
>> Anthony Liguori
>>
>>> Jacob
>>>
>>> _______________________________________________
>>> Xen-devel mailing list
>>> Xen-devel@lists.xensource.com
>>> http://lists.xensource.com/xen-devel
>>>
>>>  
>>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
>
>

Re: xenstore documentation

[Anthony Liguori]

Jacob Gorm Hansen wrote:

>Excellent, thank you!
>
>One question: What (if anything) do I need to do to introduce dom0 and
>xenstore to eachother?
>  
>
After booting and before doing anything else (but after starting xenstore):

lstore = rstore = 0;
xc_evtchn_bind_interdomain(0, 0, &lstore, &rstore)
mfn_store = xc_init_store(rstore);
xs_mkdir("/tools/<yourtool>/domain/0")
xs_introduce_domain(0, mfn_store, lstore, "/tools/<yourtool>/domain/0")

The store is supposed to remember introductions but I'm not sure if 
Rusty has gotten to that yet.  If things don't work when you restart the 
store, it means that it isn't remembering them, in which case, you have 
to reintroduce.  You'll have to remember the domain-0 stuff somehow as 
you cannot call xc_init_store more than once.

Regards,

Anthony Liguori

>Thanks again, just what I was looking for.
>Jacob
>
>  
>

Re: xenstore documentation

[NAHieu]

On 10/4/05, Rolf Neugebauer <rolf.neugebauer@intel.com> wrote:
> On Tue, 2005-10-04 at 14:25, harry wrote:
> > On Tue, 2005-10-04 at 21:55 +0900, NAHieu wrote:
> > > On 10/4/05, harry <harry@hebutterworth.freeserve.co.uk> wrote:
> > > > If you look at writeDetails in
> > > > tools/python/xen/xend/server/DevController.py you'll see the
> > > > transactions which cause the back and front ends to get probed.
> > > >
> > > > The transactions contain extra fields as provided by the derived class
> > > > specific to the device type and are written into the store in the
> > > > locations constructed in the frontendPath and backendPath functions in
> > > > DevController.py.  These paths contain the device id string as specified
> > > > when you registered your xenbus drivers.
> > > >
> > >
> > > Does that mean if I want to write a new split device, I must patch
> > > xend to let it aware of the new type of device?
> >
> > Yes.  You have to add a new class in python/xen/xend/server (see
> > blkif.py as an example) and then hook this class into xend in
> > XendDomainInfo.py and xm/create.py to get the config parameters passed
> > correctly.
>
> or no ;) depending on what you want to do. so for example if you only
> ever have one backend in the system then you "could" store that under a
> well known name in the store and the frontends can simply read that.
> you'll also need a place for the BE to watch for FE updates in a similar
> fashion.
>

Rolf, I am really suprised here: how can BE watch for FE updates? BE
and FE are in different domain, so they cannot access each other
xenstore tree. (??)

So exactly what did you mean?

Thanks.
Hieu

Re: xenstore documentation

[Rolf Neugebauer]

On Tue, 2005-10-04 at 18:24, NAHieu wrote:
> On 10/4/05, Rolf Neugebauer <rolf.neugebauer@intel.com> wrote:
> > On Tue, 2005-10-04 at 14:25, harry wrote:
> > > On Tue, 2005-10-04 at 21:55 +0900, NAHieu wrote:
> > > > On 10/4/05, harry <harry@hebutterworth.freeserve.co.uk> wrote:
> > > > > If you look at writeDetails in
> > > > > tools/python/xen/xend/server/DevController.py you'll see the
> > > > > transactions which cause the back and front ends to get probed.
> > > > >
> > > > > The transactions contain extra fields as provided by the derived class
> > > > > specific to the device type and are written into the store in the
> > > > > locations constructed in the frontendPath and backendPath functions in
> > > > > DevController.py.  These paths contain the device id string as specified
> > > > > when you registered your xenbus drivers.
> > > > >
> > > >
> > > > Does that mean if I want to write a new split device, I must patch
> > > > xend to let it aware of the new type of device?
> > >
> > > Yes.  You have to add a new class in python/xen/xend/server (see
> > > blkif.py as an example) and then hook this class into xend in
> > > XendDomainInfo.py and xm/create.py to get the config parameters passed
> > > correctly.
> >
> > or no ;) depending on what you want to do. so for example if you only
> > ever have one backend in the system then you "could" store that under a
> > well known name in the store and the frontends can simply read that.
> > you'll also need a place for the BE to watch for FE updates in a similar
> > fashion.
> >
> 
> Rolf, I am really suprised here: how can BE watch for FE updates? BE
> and FE are in different domain, so they cannot access each other
> xenstore tree. (??)
> 
> So exactly what did you mean?

so, you BE could set up:
/foobar/backend/domid = 2
/foobar/frontends          <- watch on this

then FE looks up /foobar/backend/domid
setup its end of eventchannel + grant for shared page
then creates:
/foobar/frontends/<domid>/fe_port
/foobar/frontends/<domid>/grant_ref

BE watch fires, reads port and GR and finalises device channel set up

Seems to work for me.

Rolf

Re: xenstore documentation

[Anthony Liguori]

NAHieu wrote:

>>or no ;) depending on what you want to do. so for example if you only
>>ever have one backend in the system then you "could" store that under a
>>well known name in the store and the frontends can simply read that.
>>you'll also need a place for the BE to watch for FE updates in a similar
>>fashion.
>>
>>    
>>
>
>Rolf, I am really suprised here: how can BE watch for FE updates? BE
>and FE are in different domain, so they cannot access each other
>xenstore tree. (??)
>  
>
Yes they can.  Permissions are currently off so technically any domain 
can access any other domains tree.

When permissions are enabled, the backends will have at least read 
permission on all the frontend domains.

Regards,

Anthony Liguori

>So exactly what did you mean?
>
>Thanks.
>Hieu
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.xensource.com
>http://lists.xensource.com/xen-devel
>
>  
>

Re: xenstore documentation

[NAHieu]

On 10/5/05, Anthony Liguori <aliguori@us.ibm.com> wrote:
> NAHieu wrote:
>
> >>or no ;) depending on what you want to do. so for example if you only
> >>ever have one backend in the system then you "could" store that under a
> >>well known name in the store and the frontends can simply read that.
> >>you'll also need a place for the BE to watch for FE updates in a similar
> >>fashion.
> >>
> >>
> >>
> >
> >Rolf, I am really suprised here: how can BE watch for FE updates? BE
> >and FE are in different domain, so they cannot access each other
> >xenstore tree. (??)
> >
> >
> Yes they can.  Permissions are currently off so technically any domain
> can access any other domains tree.
>
> When permissions are enabled, the backends will have at least read
> permission on all the frontend domains.
>

If so, I think we can do simply like this to exchange information
between dom0 & domU:

- dom0 watch for @introduceDomain to detect the new domU comes up.
Then dom0 watch for /domU/<device>/{evtchn,grant-ref}

- domU write evtchn,grant-ref,... to /domU/<device>/{evtchn,grant-ref}
(better doesnt write it outside its home, like in Rolf's example)

- dom0 detect the updates, setup evtchn, then start to notify domU via
this channel. Other data can be written into the share memory (like
grant-ref above) to exchange information at this step.

This way is good (if it works - I will try it myself), since we don't
need to mod xend, which is horrified to many.  Any ideas?

But like Rolf pointed out, this solution is not good incase we want to
save/restore(?)

Thanks.
Hieu

> Regards,
>
> Anthony Liguori
>
> >So exactly what did you mean?
> >
> >Thanks.
> >Hieu
> >
> >_______________________________________________
> >Xen-devel mailing list
> >Xen-devel@lists.xensource.com
> >http://lists.xensource.com/xen-devel
> >
> >
> >
>
>

Re: xenstore documentation

[Anthony Liguori]

NAHieu wrote:

>If so, I think we can do simply like this to exchange information
>between dom0 & domU:
>
>- dom0 watch for @introduceDomain to detect the new domU comes up.
>Then dom0 watch for /domU/<device>/{evtchn,grant-ref}
>  
>
Tools should store their information in /tool/<toolname>/.  Otherwise, 
yeah, it seems sane to me.

Regards,

Anthony Liguori

>- domU write evtchn,grant-ref,... to /domU/<device>/{evtchn,grant-ref}
>(better doesnt write it outside its home, like in Rolf's example)
>
>- dom0 detect the updates, setup evtchn, then start to notify domU via
>this channel. Other data can be written into the share memory (like
>grant-ref above) to exchange information at this step.
>
>This way is good (if it works - I will try it myself), since we don't
>need to mod xend, which is horrified to many.  Any ideas?
>
>But like Rolf pointed out, this solution is not good incase we want to
>save/restore(?)
>
>Thanks.
>Hieu
>
>  
>
>>Regards,
>>
>>Anthony Liguori
>>
>>    
>>
>>>So exactly what did you mean?
>>>
>>>Thanks.
>>>Hieu
>>>
>>>_______________________________________________
>>>Xen-devel mailing list
>>>Xen-devel@lists.xensource.com
>>>http://lists.xensource.com/xen-devel
>>>
>>>
>>>
>>>      
>>>
>>    
>>
>
>  
>

Re: xenstore documentation

[Jacob Gorm Hansen]

[-- Attachment #1: Type: text/plain, Size: 423 bytes --]

hi Anthony, others

I have converted your pseudocode to C, but I am still not able to
connect the device. I hope it's OK that I attach my code that I have
trouble getting working, if anyone could try to run it or comment if
anything obvious looks wrong.

The two files are businit.c and buscreate.c. The former inits xenstore
and dom0, and the latter creates a domU and attempts to connect hda1.

Thanks,
Jacob

[-- Attachment #2: businit.c --]
[-- Type: text/x-csrc, Size: 537 bytes --]

#include <xenctrl.h>
#include <xenguest.h>

#include <stdio.h>
#include <errno.h>
#include <stdlib.h>
#include <string.h>

#include <xs.h>
#include <fcntl.h>


int main(int argc,char** argv)
{
	int xc = xc_interface_open();
	struct xs_handle *xs = xs_daemon_open();
	char home[] = "/local/domain/0";

	int lstore = 0;
	int rstore = 0;

	xc_evtchn_bind_interdomain(xc, 0, 0, &lstore, &rstore);
	unsigned long mfn_store = xc_init_store(xc, rstore);
	xs_mkdir(xs,home);
	xs_introduce_domain(xs, 0, mfn_store, lstore, home);

	return 0;

}


[-- Attachment #3: buscreate.c --]
[-- Type: text/x-csrc, Size: 2517 bytes --]

#include <xenctrl.h>
#include <xenguest.h>

#include <stdio.h>
#include <errno.h>
#include <stdlib.h>
#include <string.h>

#include <xs.h>
#include <fcntl.h>


#define xs_write(a,b,c,d) printf("write %s <- %s : %d\n", b,c,xs_write(a,b,c,d));
#define xs_transaction_end(a,b) printf("end : %d\n", xs_transaction_end(a,b));
int main(int argc,char** argv)
{
	int xc = xc_interface_open();
	struct xs_handle *xs = xs_daemon_open();
	
	char kernel[] = "/vmlinux";
	char ramdisk[] = "/domUinitrd";
	char cmdline[] = "init=/linuxrc root=/dev/ram";
	char pdev[] = "0x301";
	char vdev[] = "0x301";
	int vcpus = 1;
	char home[256];

	unsigned long memory = 64*1024*1024;

	int domid = 0;
	xc_domain_create(xc, ACM_DEFAULT_SSID, &domid);
	xc_domain_setmaxmem(xc,domid, memory >> 10);
	xc_domain_memory_increase_reservation(xc,domid, memory >> 12, 0,0,0);

	// 2) Build domain
	int lconsole = 0;
	int rconsole = 0;
	int lstore = 0;
	int rstore = 0;
	unsigned long mfn_store, mfn_console;

	xc_evtchn_bind_interdomain(xc, 0, domid, &lconsole, &rconsole);
	xc_evtchn_bind_interdomain(xc, DOMID_SELF, domid, &lstore, &rstore);

	xc_linux_build(xc, domid, kernel, ramdisk, cmdline, 0, vcpus,
			rstore, &mfn_store, rconsole, &mfn_console);

	sprintf(home,"/local/domain/%d",domid);
	xs_introduce_domain(xs, domid, mfn_store, lstore, home);

	char s[256];
	char s2[256];

	sprintf(s,"%s/console/ring-ref",home);
	sprintf(s2,"%lu",mfn_console);
	xs_write(xs, s, s2, strlen(s2));

	sprintf(s,"%s/console/port",home);
	sprintf(s2,"%d",lconsole);
	xs_write(xs, s, s2, strlen(s2));

	// 3) Create block device (pdev, vdev);
	int uuid = 1000 + domid;

	char* dom0_home = xs_get_domain_path(xs,0);
	printf("dom0_home is %s\n",dom0_home);

	char backend[256];
	char frontend[256];
	sprintf(backend,"%s/backend/vbd/%d/%d",dom0_home,uuid,domid);
	sprintf(frontend, "%s/device/vbd/%d",home,uuid);


	xs_transaction_start(xs);
	sprintf(s,"%s/frontend",backend);
	xs_write(xs, s, frontend, strlen(frontend));

	sprintf(s,"%s/frontend-id",backend);
	sprintf(s2,"%d",domid);
	xs_write(xs, s, s2, strlen(s2));
	xs_transaction_end(xs,0);


	xs_transaction_start(xs);
	sprintf(s,"%s/backend",frontend);
	xs_write(xs, s, backend, strlen(backend));

	sprintf(s, "%s/backend-id", frontend);
	xs_write(xs, s, "0",1);
	
	sprintf(s, "%s/virtual-device", frontend);
	xs_write(xs, s, vdev, strlen(vdev));
	xs_transaction_end(xs,0);



	sprintf(s, "%s/physical-device",backend);
	xs_write(xs, s, pdev, strlen(pdev));

	xc_domain_unpause(xc,domid);

	return 0;
}

[-- Attachment #4: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: xenstore documentation

[Anthony Liguori]

Jacob Gorm Hansen wrote:

>hi Anthony, others
>
>I have converted your pseudocode to C, but I am still not able to
>connect the device. I hope it's OK that I attach my code that I have
>trouble getting working, if anyone could try to run it or comment if
>anything obvious looks wrong.
>
>The two files are businit.c and buscreate.c. The former inits xenstore
>and dom0, and the latter creates a domU and attempts to connect hda1.
>  
>
I'll run play with it tomorrow.  Some people are having problems with 
block devices timing out.  You should verify you can create a domain 
with a block device with Xend to determine if it's your platform.

Regards,

Anthony Liguori

>Thanks,
>Jacob
>  
>
>------------------------------------------------------------------------
>
>#include <xenctrl.h>
>#include <xenguest.h>
>
>#include <stdio.h>
>#include <errno.h>
>#include <stdlib.h>
>#include <string.h>
>
>#include <xs.h>
>#include <fcntl.h>
>
>
>int main(int argc,char** argv)
>{
>	int xc = xc_interface_open();
>	struct xs_handle *xs = xs_daemon_open();
>	char home[] = "/local/domain/0";
>
>	int lstore = 0;
>	int rstore = 0;
>
>	xc_evtchn_bind_interdomain(xc, 0, 0, &lstore, &rstore);
>	unsigned long mfn_store = xc_init_store(xc, rstore);
>	xs_mkdir(xs,home);
>	xs_introduce_domain(xs, 0, mfn_store, lstore, home);
>
>	return 0;
>
>}
>
>  
>
>------------------------------------------------------------------------
>
>#include <xenctrl.h>
>#include <xenguest.h>
>
>#include <stdio.h>
>#include <errno.h>
>#include <stdlib.h>
>#include <string.h>
>
>#include <xs.h>
>#include <fcntl.h>
>
>
>#define xs_write(a,b,c,d) printf("write %s <- %s : %d\n", b,c,xs_write(a,b,c,d));
>#define xs_transaction_end(a,b) printf("end : %d\n", xs_transaction_end(a,b));
>int main(int argc,char** argv)
>{
>	int xc = xc_interface_open();
>	struct xs_handle *xs = xs_daemon_open();
>	
>	char kernel[] = "/vmlinux";
>	char ramdisk[] = "/domUinitrd";
>	char cmdline[] = "init=/linuxrc root=/dev/ram";
>	char pdev[] = "0x301";
>	char vdev[] = "0x301";
>	int vcpus = 1;
>	char home[256];
>
>	unsigned long memory = 64*1024*1024;
>
>	int domid = 0;
>	xc_domain_create(xc, ACM_DEFAULT_SSID, &domid);
>	xc_domain_setmaxmem(xc,domid, memory >> 10);
>	xc_domain_memory_increase_reservation(xc,domid, memory >> 12, 0,0,0);
>
>	// 2) Build domain
>	int lconsole = 0;
>	int rconsole = 0;
>	int lstore = 0;
>	int rstore = 0;
>	unsigned long mfn_store, mfn_console;
>
>	xc_evtchn_bind_interdomain(xc, 0, domid, &lconsole, &rconsole);
>	xc_evtchn_bind_interdomain(xc, DOMID_SELF, domid, &lstore, &rstore);
>
>	xc_linux_build(xc, domid, kernel, ramdisk, cmdline, 0, vcpus,
>			rstore, &mfn_store, rconsole, &mfn_console);
>
>	sprintf(home,"/local/domain/%d",domid);
>	xs_introduce_domain(xs, domid, mfn_store, lstore, home);
>
>	char s[256];
>	char s2[256];
>
>	sprintf(s,"%s/console/ring-ref",home);
>	sprintf(s2,"%lu",mfn_console);
>	xs_write(xs, s, s2, strlen(s2));
>
>	sprintf(s,"%s/console/port",home);
>	sprintf(s2,"%d",lconsole);
>	xs_write(xs, s, s2, strlen(s2));
>
>	// 3) Create block device (pdev, vdev);
>	int uuid = 1000 + domid;
>
>	char* dom0_home = xs_get_domain_path(xs,0);
>	printf("dom0_home is %s\n",dom0_home);
>
>	char backend[256];
>	char frontend[256];
>	sprintf(backend,"%s/backend/vbd/%d/%d",dom0_home,uuid,domid);
>	sprintf(frontend, "%s/device/vbd/%d",home,uuid);
>
>
>	xs_transaction_start(xs);
>	sprintf(s,"%s/frontend",backend);
>	xs_write(xs, s, frontend, strlen(frontend));
>
>	sprintf(s,"%s/frontend-id",backend);
>	sprintf(s2,"%d",domid);
>	xs_write(xs, s, s2, strlen(s2));
>	xs_transaction_end(xs,0);
>
>
>	xs_transaction_start(xs);
>	sprintf(s,"%s/backend",frontend);
>	xs_write(xs, s, backend, strlen(backend));
>
>	sprintf(s, "%s/backend-id", frontend);
>	xs_write(xs, s, "0",1);
>	
>	sprintf(s, "%s/virtual-device", frontend);
>	xs_write(xs, s, vdev, strlen(vdev));
>	xs_transaction_end(xs,0);
>
>
>
>	sprintf(s, "%s/physical-device",backend);
>	xs_write(xs, s, pdev, strlen(pdev));
>
>	xc_domain_unpause(xc,domid);
>
>	return 0;
>}
>  
>

RE: xenstore documentation

[Neugebauer, Rolf]

> -----Original Message-----
> From: NAHieu [mailto:nahieu@gmail.com]
> Sent: 04 October 2005 19:00
> To: Anthony Liguori
> Cc: Neugebauer, Rolf; Rami Rosen; harry; Jacob Gorm Hansen; xen-
> devel@lists.xensource.com
> Subject: Re: [Xen-devel] xenstore documentation
> 
> On 10/5/05, Anthony Liguori <aliguori@us.ibm.com> wrote:
> > NAHieu wrote:
> >
> > >>or no ;) depending on what you want to do. so for example if you
only
> > >>ever have one backend in the system then you "could" store that
under
> a
> > >>well known name in the store and the frontends can simply read
that.
> > >>you'll also need a place for the BE to watch for FE updates in a
> similar
> > >>fashion.
> > >>
> > >>
> > >>
> > >
> > >Rolf, I am really suprised here: how can BE watch for FE updates?
BE
> > >and FE are in different domain, so they cannot access each other
> > >xenstore tree. (??)
> > >
> > >
> > Yes they can.  Permissions are currently off so technically any
domain
> > can access any other domains tree.
> >
> > When permissions are enabled, the backends will have at least read
> > permission on all the frontend domains.
> >
> 
> If so, I think we can do simply like this to exchange information
> between dom0 & domU:
> 
> - dom0 watch for @introduceDomain to detect the new domU comes up.
> Then dom0 watch for /domU/<device>/{evtchn,grant-ref}
> 
> - domU write evtchn,grant-ref,... to /domU/<device>/{evtchn,grant-ref}
> (better doesnt write it outside its home, like in Rolf's example)
> 
> - dom0 detect the updates, setup evtchn, then start to notify domU via
> this channel. Other data can be written into the share memory (like
> grant-ref above) to exchange information at this step.
> 
> This way is good (if it works - I will try it myself), since we don't
> need to mod xend, which is horrified to many.  Any ideas?

The main problem is that it doesn't work when you have multiple BE in
different domains. Something you can't do at the moment but consider
multiple NICs and device drivers in for them in multiples VMs. Which one
is dealing with it when the front end comes up. How does the FE know
which BE to connect to (ie who to grant access to the shared page to)
etc.

> But like Rolf pointed out, this solution is not good incase we want to
> save/restore(?)

Your approach above might still work with save restore etc. but you
essentially need xend to tell FE and possibly BEs which one to pick if
there are multiples out there. so xend needs to be involved as it is
parsing the VMs config file.

Basically the way it is implement for blk/net/tpm device is the right
way. I was just suggesting that of you want to prototype something you
don't necessarily need to follow this and don't initially need to
modifiy xend.

Rolf

 
> Thanks.
> Hieu
> 
> > Regards,
> >
> > Anthony Liguori
> >
> > >So exactly what did you mean?
> > >
> > >Thanks.
> > >Hieu
> > >
> > >_______________________________________________
> > >Xen-devel mailing list
> > >Xen-devel@lists.xensource.com
> > >http://lists.xensource.com/xen-devel
> > >
> > >
> > >
> >
> >

Re: xenstore documentation

[Jacob Gorm Hansen]

On 10/4/05, Jacob Gorm Hansen <jacobg@diku.dk> wrote:
> hi Anthony, others
>
> I have converted your pseudocode to C, but I am still not able to
> connect the device. I hope it's OK that I attach my code that I have
> trouble getting working, if anyone could try to run it or comment if
> anything obvious looks wrong.

Funny, removing the xc_transaction_* calls changes things. The blkdev
still does not work, but now blkback_probe gets called in dom0...

Jacob

Re: xenstore documentation

[Anthony Liguori]

Jacob Gorm Hansen wrote:

>hi Anthony, others
>
>I have converted your pseudocode to C, but I am still not able to
>connect the device. I hope it's OK that I attach my code that I have
>trouble getting working, if anyone could try to run it or comment if
>anything obvious looks wrong.
>  
>
The code works for me.

Can you be more specific about what error you are seeing and what 
changeset you are on?  It works just fine on my snapshot from Monday.

Regards,

Anthony Liguori

>The two files are businit.c and buscreate.c. The former inits xenstore
>and dom0, and the latter creates a domU and attempts to connect hda1.
>
>Thanks,
>Jacob
>  
>
>------------------------------------------------------------------------
>
>#include <xenctrl.h>
>#include <xenguest.h>
>
>#include <stdio.h>
>#include <errno.h>
>#include <stdlib.h>
>#include <string.h>
>
>#include <xs.h>
>#include <fcntl.h>
>
>
>int main(int argc,char** argv)
>{
>	int xc = xc_interface_open();
>	struct xs_handle *xs = xs_daemon_open();
>	char home[] = "/local/domain/0";
>
>	int lstore = 0;
>	int rstore = 0;
>
>	xc_evtchn_bind_interdomain(xc, 0, 0, &lstore, &rstore);
>	unsigned long mfn_store = xc_init_store(xc, rstore);
>	xs_mkdir(xs,home);
>	xs_introduce_domain(xs, 0, mfn_store, lstore, home);
>
>	return 0;
>
>}
>
>  
>
>------------------------------------------------------------------------
>
>#include <xenctrl.h>
>#include <xenguest.h>
>
>#include <stdio.h>
>#include <errno.h>
>#include <stdlib.h>
>#include <string.h>
>
>#include <xs.h>
>#include <fcntl.h>
>
>
>#define xs_write(a,b,c,d) printf("write %s <- %s : %d\n", b,c,xs_write(a,b,c,d));
>#define xs_transaction_end(a,b) printf("end : %d\n", xs_transaction_end(a,b));
>int main(int argc,char** argv)
>{
>	int xc = xc_interface_open();
>	struct xs_handle *xs = xs_daemon_open();
>	
>	char kernel[] = "/vmlinux";
>	char ramdisk[] = "/domUinitrd";
>	char cmdline[] = "init=/linuxrc root=/dev/ram";
>	char pdev[] = "0x301";
>	char vdev[] = "0x301";
>	int vcpus = 1;
>	char home[256];
>
>	unsigned long memory = 64*1024*1024;
>
>	int domid = 0;
>	xc_domain_create(xc, ACM_DEFAULT_SSID, &domid);
>	xc_domain_setmaxmem(xc,domid, memory >> 10);
>	xc_domain_memory_increase_reservation(xc,domid, memory >> 12, 0,0,0);
>
>	// 2) Build domain
>	int lconsole = 0;
>	int rconsole = 0;
>	int lstore = 0;
>	int rstore = 0;
>	unsigned long mfn_store, mfn_console;
>
>	xc_evtchn_bind_interdomain(xc, 0, domid, &lconsole, &rconsole);
>	xc_evtchn_bind_interdomain(xc, DOMID_SELF, domid, &lstore, &rstore);
>
>	xc_linux_build(xc, domid, kernel, ramdisk, cmdline, 0, vcpus,
>			rstore, &mfn_store, rconsole, &mfn_console);
>
>	sprintf(home,"/local/domain/%d",domid);
>	xs_introduce_domain(xs, domid, mfn_store, lstore, home);
>
>	char s[256];
>	char s2[256];
>
>	sprintf(s,"%s/console/ring-ref",home);
>	sprintf(s2,"%lu",mfn_console);
>	xs_write(xs, s, s2, strlen(s2));
>
>	sprintf(s,"%s/console/port",home);
>	sprintf(s2,"%d",lconsole);
>	xs_write(xs, s, s2, strlen(s2));
>
>	// 3) Create block device (pdev, vdev);
>	int uuid = 1000 + domid;
>
>	char* dom0_home = xs_get_domain_path(xs,0);
>	printf("dom0_home is %s\n",dom0_home);
>
>	char backend[256];
>	char frontend[256];
>	sprintf(backend,"%s/backend/vbd/%d/%d",dom0_home,uuid,domid);
>	sprintf(frontend, "%s/device/vbd/%d",home,uuid);
>
>
>	xs_transaction_start(xs);
>	sprintf(s,"%s/frontend",backend);
>	xs_write(xs, s, frontend, strlen(frontend));
>
>	sprintf(s,"%s/frontend-id",backend);
>	sprintf(s2,"%d",domid);
>	xs_write(xs, s, s2, strlen(s2));
>	xs_transaction_end(xs,0);
>
>
>	xs_transaction_start(xs);
>	sprintf(s,"%s/backend",frontend);
>	xs_write(xs, s, backend, strlen(backend));
>
>	sprintf(s, "%s/backend-id", frontend);
>	xs_write(xs, s, "0",1);
>	
>	sprintf(s, "%s/virtual-device", frontend);
>	xs_write(xs, s, vdev, strlen(vdev));
>	xs_transaction_end(xs,0);
>
>
>
>	sprintf(s, "%s/physical-device",backend);
>	xs_write(xs, s, pdev, strlen(pdev));
>
>	xc_domain_unpause(xc,domid);
>
>	return 0;
>}
>  
>

Re: xenstore documentation

[Jacob Gorm Hansen]

hi Anthony, thanks for testing the code.

I am on:

Changeset:   7267:89b1b67fc2c4
user:        kaf24@firebug.cl.cam.ac.uk
date:        Wed Oct  5 17:54:09 2005 +0100
summary:     Emulate guest reads of CR4, masking features that Xen

(but I have had these problems with various 'latest' versions over the
last couple of days).

Basically I am getting a timeout from the blkfront, which seems to
because the blkback_probe function never gets called. At least now I
know the code ought to be working, then I can start looking for the
problem elsewhere. Perhaps this has to do with my hotplug
installation.

Jacob