Mailing List Archive

Roger Pau Monne writes ("[Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6 on domain destroy"):
> libxl: set frontend status to 6 on domain destroy
>
> Set frontend status to 6 on domain destruction and wait for devices to
> be disconnected before executing hotplug scripts.

There seems to be a race here.

> + libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", fe_path, "state"), "6");

So here, the kernel or backendd start racing, and you hope that they
win the race and close the device before ...

> libxl__device_execute_hotplug(gc, dev, DISCONNECT);

... the hotplug script tries to remove it.

Is there something we can do to make sure that we always get this
right ?

Ian.

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

2011/12/13 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> Roger Pau Monne writes ("[Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6 on domain destroy"):
>> libxl: set frontend status to 6 on domain destroy
>>
>> Set frontend status to 6 on domain destruction and wait for devices to
>> be disconnected before executing hotplug scripts.
>
> There seems to be a race here.
>
>> +    libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", fe_path, "state"), "6");
>
> So here, the kernel or backendd start racing, and you hope that they
> win the race and close the device before ...

From my experience in NetBSD, the kernel only closes the device when
it's frontend state is set to 6, since we destroy the domain, it is
unable to set the status to 6, and thus the kernel doesn't detach the
devices. I've added some libxl__wait_for_device_state logic here, to
assure the backend state is set to 6 before trying to execute hotplug
scripts. The truth is that I had it in previous versions of my patch,
but it seems the kernel always switches contexts and detaches the
devices before executing hotplug scripts (it might just be luck).

Also this patch speeds domain destruction a lot (which is also quite
slow under Linux from what I saw).

>>      libxl__device_execute_hotplug(gc, dev, DISCONNECT);
>
> ... the hotplug script tries to remove it.
>
> Is there something we can do to make sure that we always get this
> right ?
>
> Ian.

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

On Wed, 2011-12-14 at 09:13 +0000, Roger Pau Monné wrote:
> 2011/12/13 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> > Roger Pau Monne writes ("[Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6 on domain destroy"):
> >> libxl: set frontend status to 6 on domain destroy
> >>
> >> Set frontend status to 6 on domain destruction and wait for devices to
> >> be disconnected before executing hotplug scripts.
> >
> > There seems to be a race here.
> >
> >> + libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/%s", fe_path, "state"), "6");
> >
> > So here, the kernel or backendd start racing, and you hope that they
> > win the race and close the device before ...
>
> From my experience in NetBSD, the kernel only closes the device when
> it's frontend state is set to 6, since we destroy the domain, it is
> unable to set the status to 6, and thus the kernel doesn't detach the
> devices.

So if you rm the backend directory the NetBSD does not take that as a
sign to tear down the device? That sounds like a bug in the NetBSD
backend -- it should treat deletion of the backend state dir as if it
were reading state = "6" and shut everything down.

Or is the issue only in the userspace portions?

> I've added some libxl__wait_for_device_state logic here, to
> assure the backend state is set to 6 before trying to execute hotplug
> scripts.

But that will always be true with this patch since you set it that way
just before, right?

If you go down this path then I think you need to set the state to
"5" (Closing) in order to prompt the backend to transition to
"6" (Closed) itself. However you need to be careful about adding a
synchronous wait to the device destroy function. This should eventually
work even if the frontend and backend are not co-operating. That starts
to look a bit like calling libxl__device_remove instead.

> The truth is that I had it in previous versions of my patch,
> but it seems the kernel always switches contexts and detaches the
> devices before executing hotplug scripts (it might just be luck).

Probably just luck and partly due e.g. to your presumably system being
only very lightly loaded.

Ian.

>
> Also this patch speeds domain destruction a lot (which is also quite
> slow under Linux from what I saw).
>
> >> libxl__device_execute_hotplug(gc, dev, DISCONNECT);
> >
> > ... the hotplug script tries to remove it.
> >
> > Is there something we can do to make sure that we always get this
> > right ?
> >
> > Ian.
>
> _______________________________________________
> 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

2011/12/14 Ian Campbell <Ian.Campbell@citrix.com>:
> So if you rm the backend directory the NetBSD does not take that as a
> sign to tear down the device? That sounds like a bug in the NetBSD
> backend -- it should treat deletion of the backend state dir as if it
> were reading state = "6" and shut everything down.

Yes, if I delete the frontend from xenstore, the devices are detached.
Anyway, doing it one way or another (deletion or setting state to 6)
doesn't really make a difference, you still have to wait for the
backend to be disconnected (detached) before executing hotplug
scripts.

> Or is the issue only in the userspace portions?
>
>>  I've added some libxl__wait_for_device_state logic here, to
>> assure the backend state is set to 6 before trying to execute hotplug
>> scripts.
>
> But that will always be true with this patch since you set it that way
> just before, right?

I set frontend status to 6, and I suggest to wait for backend status
to be 6 also, then execute hotplug scripts. It won't be true, because
frontend and backend status are not tied (in the NetBSD case backend
status is set by the Dom0 kernel or hotplug scripts, while frontend
status is set by the DomU).

> If you go down this path then I think you need to set the state to
> "5" (Closing) in order to prompt the backend to transition to
> "6" (Closed) itself. However you need to be careful about adding a
> synchronous wait to the device destroy function. This should eventually
> work even if the frontend and backend are not co-operating. That starts
> to look a bit like calling libxl__device_remove instead.

Do you mean to set backend status to 5 instead of setting frontend to
6, and then wait for the kernel to do the transition from 5 to 6,
instead of setting the frontend to 6?

>>  The truth is that I had it in previous versions of my patch,
>> but it seems the kernel always switches contexts and detaches the
>> devices before executing hotplug scripts (it might just be luck).
>
> Probably just luck and partly due e.g. to your presumably system being
> only very lightly loaded.
>
> Ian.

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

Roger Pau Monné writes ("Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6 on domain destroy"):
> 2011/12/13 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> > So here, the kernel or backendd start racing, and you hope that they
> > win the race and close the device before ...
>
> From my experience in NetBSD, the kernel only closes the device when
> it's frontend state is set to 6, since we destroy the domain, it is
> unable to set the status to 6, and thus the kernel doesn't detach the
> devices.

This is no good, because you need to be able to force unplug a device
without guest cooperation, and the frontend state is controlled by the
guest. So I think there is a NetBSD kernel bug in this area.

It needs to be possible to tell the backend to shut down without
regard to the frontend state.

> I've added some libxl__wait_for_device_state logic here, to
> assure the backend state is set to 6 before trying to execute hotplug
> scripts. The truth is that I had it in previous versions of my patch,
> but it seems the kernel always switches contexts and detaches the
> devices before executing hotplug scripts (it might just be luck).

Well that's very nice but of course not reliable.

> Also this patch speeds domain destruction a lot (which is also quite
> slow under Linux from what I saw).

You're saying that not waiting for the backends to close speeds up
domain destruction ? Where is the time going ?

Ian.

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

Roger Pau Monné writes ("Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6 on domain destroy"):
> 2011/12/14 Ian Campbell <Ian.Campbell@citrix.com>:
> > So if you rm the backend directory the NetBSD does not take that as a
> > sign to tear down the device? That sounds like a bug in the NetBSD
> > backend -- it should treat deletion of the backend state dir as if it
> > were reading state = "6" and shut everything down.
>
> Yes, if I delete the frontend from xenstore, the devices are detached.
> Anyway, doing it one way or another (deletion or setting state to 6)
> doesn't really make a difference, you still have to wait for the
> backend to be disconnected (detached) before executing hotplug
> scripts.

So device destruction could be achieved by simply deleting the backend
directory. But, we would need some other way to detect when the
backend has actually closed the device so that we can run the script.

Ian.

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

On Wed, 2011-12-14 at 11:12 +0000, Roger Pau Monné wrote:
> 2011/12/14 Ian Campbell <Ian.Campbell@citrix.com>:
> > So if you rm the backend directory the NetBSD does not take that as a
> > sign to tear down the device? That sounds like a bug in the NetBSD
> > backend -- it should treat deletion of the backend state dir as if it
> > were reading state = "6" and shut everything down.
>
> Yes, if I delete the frontend from xenstore, the devices are detached.
> Anyway, doing it one way or another (deletion or setting state to 6)
> doesn't really make a difference, you still have to wait for the
> backend to be disconnected (detached) before executing hotplug
> scripts.

Right. This might actually be tricky in the case where the backend dir
has been removed since I expect there will be nowhere else which
indicates this.

> > Or is the issue only in the userspace portions?
> >
> >> I've added some libxl__wait_for_device_state logic here, to
> >> assure the backend state is set to 6 before trying to execute hotplug
> >> scripts.
> >
> > But that will always be true with this patch since you set it that way
> > just before, right?
>
> I set frontend status to 6, and I suggest to wait for backend status
> to be 6 also, then execute hotplug scripts. It won't be true, because
> frontend and backend status are not tied (in the NetBSD case backend
> status is set by the Dom0 kernel or hotplug scripts, while frontend
> status is set by the DomU).

I think (but I'm not sure) that it is not permissible for the toolstack
to mess with the frontend state like that.

> > If you go down this path then I think you need to set the state to
> > "5" (Closing) in order to prompt the backend to transition to
> > "6" (Closed) itself. However you need to be careful about adding a
> > synchronous wait to the device destroy function. This should eventually
> > work even if the frontend and backend are not co-operating. That starts
> > to look a bit like calling libxl__device_remove instead.
>
> Do you mean to set backend status to 5 instead of setting frontend to
> 6, and then wait for the kernel to do the transition from 5 to 6,
> instead of setting the frontend to 6?

Yes.

Ian.



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

2011/12/14 Ian Jackson <Ian.Jackson@eu.citrix.com>:
>> Yes, if I delete the frontend from xenstore, the devices are detached.
>> Anyway, doing it one way or another (deletion or setting state to 6)
>> doesn't really make a difference, you still have to wait for the
>> backend to be disconnected (detached) before executing hotplug
>> scripts.
>
> So device destruction could be achieved by simply deleting the backend
> directory.  But, we would need some other way to detect when the
> backend has actually closed the device so that we can run the script.

Device detach, will in turn allows destruction, can be achieved in two ways:

* Set frontend status to 6.
* Remove frontend entries.

There is no need to change backend entries to force detach a device.

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

2011/12/14 Ian Campbell <Ian.Campbell@citrix.com>:
> On Wed, 2011-12-14 at 11:12 +0000, Roger Pau Monné wrote:
>> 2011/12/14 Ian Campbell <Ian.Campbell@citrix.com>:
>> > So if you rm the backend directory the NetBSD does not take that as a
>> > sign to tear down the device? That sounds like a bug in the NetBSD
>> > backend -- it should treat deletion of the backend state dir as if it
>> > were reading state = "6" and shut everything down.
>>
>> Yes, if I delete the frontend from xenstore, the devices are detached.
>> Anyway, doing it one way or another (deletion or setting state to 6)
>> doesn't really make a difference, you still have to wait for the
>> backend to be disconnected (detached) before executing hotplug
>> scripts.
>
> Right. This might actually be tricky in the case where the backend dir
> has been removed since I expect there will be nowhere else which
> indicates this.

No, there's no other easy way to know if the device has been detached.
If hotplug scripts are executed from xl, I think it is safe to assume
that nobody else is messing with xenstore entries. Backend folder
should not be removed untill hotplug script execution has happened.

>
>> > Or is the issue only in the userspace portions?
>> >
>> >>  I've added some libxl__wait_for_device_state logic here, to
>> >> assure the backend state is set to 6 before trying to execute hotplug
>> >> scripts.
>> >
>> > But that will always be true with this patch since you set it that way
>> > just before, right?
>>
>> I set frontend status to 6, and I suggest to wait for backend status
>> to be 6 also, then execute hotplug scripts. It won't be true, because
>> frontend and backend status are not tied (in the NetBSD case backend
>> status is set by the Dom0 kernel or hotplug scripts, while frontend
>> status is set by the DomU).
>
> I think (but I'm not sure) that it is not permissible for the toolstack
> to mess with the frontend state like that.

Well, xl already removes frontend xenstore entries, so I assumed
setting frontend status to 6 was not a problem. If it is, I could
always do the following sequence to force the detach:

1. Delete frontend xenstore dir.
2. Wait for backend xenstore to switch to disconnected state (6).
3. Execute hotplug script.
4. Remove backend.

>> > If you go down this path then I think you need to set the state to
>> > "5" (Closing) in order to prompt the backend to transition to
>> > "6" (Closed) itself. However you need to be careful about adding a
>> > synchronous wait to the device destroy function. This should eventually
>> > work even if the frontend and backend are not co-operating. That starts
>> > to look a bit like calling libxl__device_remove instead.
>>
>> Do you mean to set backend status to 5 instead of setting frontend to
>> 6, and then wait for the kernel to do the transition from 5 to 6,
>> instead of setting the frontend to 6?
>
> Yes.

No luck, setting backend state to 5 did not make the kernel detach the
device. It seems like the kernel is only watching frontend xenstore
entries.

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

On Wed, 2011-12-14 at 12:12 +0000, Roger Pau Monné wrote:
> 2011/12/14 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> >> Yes, if I delete the frontend from xenstore, the devices are detached.
> >> Anyway, doing it one way or another (deletion or setting state to 6)
> >> doesn't really make a difference, you still have to wait for the
> >> backend to be disconnected (detached) before executing hotplug
> >> scripts.
> >
> > So device destruction could be achieved by simply deleting the backend
> > directory. But, we would need some other way to detect when the
> > backend has actually closed the device so that we can run the script.
>
> Device detach, will in turn allows destruction, can be achieved in two ways:
>
> * Set frontend status to 6.
> * Remove frontend entries.
>
> There is no need to change backend entries to force detach a device.

The correct method for forcibly destroying a device is to remove the
backend directory.

The correct method to perform a graceful remove is to set the backend
state to "5" and wait for it to coordinate with the guest to reach state
"6". However this is not a forced operation and may not complete in a
timely manner or indeed at all.

Some backends also support an "online" node which, if left set to 1 when
setting the backend state to 5" for a graceful shutdown, causes the
backend to detach but remain active (as opposed to self destructing) in
the expectation of a frontend reconnecting again later -- this is used
for example when kexecing a PV domain.

In no case should the toolstack be messing with the frontend state,
although obviously in the destroy case it is at liberty shortly
afterwards to also nuke the frontend directory.

Ian.



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

On Wed, 2011-12-14 at 12:18 +0000, Roger Pau Monné wrote:
>
> No luck, setting backend state to 5 did not make the kernel detach the
> device. It seems like the kernel is only watching frontend xenstore
> entries.

Does hot removal of devices work? This uses the same mechanism.

Ian.


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

2011/12/14 Ian Campbell <Ian.Campbell@citrix.com>:
> On Wed, 2011-12-14 at 12:18 +0000, Roger Pau Monné wrote:
>>
>> No luck, setting backend state to 5 did not make the kernel detach the
>> device. It seems like the kernel is only watching frontend xenstore
>> entries.
>
> Does hot removal of devices work? This uses the same mechanism.

Attaching of device doesn't work very well because of kernel problems,
and detaching sometimes makes the kernel crash.

I've tried the following procedure for domain destruction, and it works ok:

1. remove frontend.
2. wait for backend to switch to disconnected state.
3. execute hotplug scripts.
4. remove backend.

Is this acceptable?

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

I have been thinking about this whole area.

Originally my opinion was that the block and network setup scripts
(eg, setting up loopback devices or iscsi or bridging whatever) should
be executed directly by xl. This naturally gives the best error
handling and makes logging easiest.

However, if we are serious about supporting driver domains, or indeed
any kind of backend not running in the same domain as libxl, then
something in the driver domain needs to be responsible for executing
these scripts (or equivalent).

The obvious way to communicate this information to the driver domain
is via xenstore.

What we should be discussing is exactly how the driver domain
translates that into script execution. Currently on Linux this is
mostly done with udev, and AIUI on BSD using xenbackendd.

So sorry for leading this discussion in what I now think may be a
wrong direction.

Ian.

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

On Thu, 2011-12-15 at 17:44 +0000, Ian Jackson wrote:
> I have been thinking about this whole area.
>
> Originally my opinion was that the block and network setup scripts
> (eg, setting up loopback devices or iscsi or bridging whatever) should
> be executed directly by xl. This naturally gives the best error
> handling and makes logging easiest.
>
> However, if we are serious about supporting driver domains, or indeed
> any kind of backend not running in the same domain as libxl, then
> something in the driver domain needs to be responsible for executing
> these scripts (or equivalent).
>
> The obvious way to communicate this information to the driver domain
> is via xenstore.
>
> What we should be discussing is exactly how the driver domain
> translates that into script execution. Currently on Linux this is
> mostly done with udev, and AIUI on BSD using xenbackendd.

xenbackendd is (AFAIK) watching for events (e.g. creation and deletion
of backend state nodes) in xenstore so at least in concept it is
portable to all OSes, whereas udev is pretty Linux specific.

One nice effect of the udev approach is that you get an explicit event
e.g. when a block device is torn down. This makes it trivial to avoid
problems like racing to teardown a loopback device.

Since xenbackendd is mostly inferring things by watching the backend
nodes used by the kernel side drivers it struggles due to the model
where we rm the backend's xenstore directory on destroy which nukes
state required by xenbackendd.
The xenbackendd model seems slightly preferable to me, it's simpler to
setup and more portable. Doing things differently on different OSes
doesn't help with the confusion here!

Perhaps the core functionality could be in libxl such that a toolstack
can choose to integrate the functionality or run it as a separate daemon
as necessary?

The main issue with the xenbackendd model is the manner in which it has
to guess what is going on and try to synchronise with what the drivers
are going. This does also effect the udev driven way of doing things too
since the scripts often want to look in xenstore for parameters and on
destroy they are often missing.

We currently get this wrong under Linux at the minute and the network
teardown hotplug script doesn't work right because the necessary bits
are gone from xenstore. We mostly get away with this for bridging since
the device is automatically remove from the bridge but for vswitch we do
need to actually do some reconfiguration at this point. We also appear
to leak iptables rules under some circumstances.

Perhaps we would be better off splitting the hotplug stuff into its own
place in xenstore and have the toolstack explicitly trigger events at
the right time by writing to it? This could be compatible with existing
scripts since they use an environment variable to find their xenstore
base path.

We need to be aware that the script models (or at least the sequencing
wrt the xenstore state transitions) vary slightly with the device type
since for block devices you typically need to run the hotplug script
before creating the backend whereas with network devices you create the
device first and then run the script to configure it. vice versa for
destroy.

We also need to consider Network tap devices. Not all tap devices are
part of Xen's world which is a wrinkle which needs thought.

I tried to write down my understanding of the events and sequencing
under Linux but that mostly showed the gaps in my understanding...

AIUI XCP does a lot more of this stuff via xenstored and have been
(successfully) playing with driver domains -- we should ask for their
input.

> So sorry for leading this discussion in what I now think may be a
> wrong direction.
>
> Ian.



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

2011/12/16 Ian Campbell <Ian.Campbell@citrix.com>:
> On Thu, 2011-12-15 at 17:44 +0000, Ian Jackson wrote:
>> I have been thinking about this whole area.
>>
>> Originally my opinion was that the block and network setup scripts
>> (eg, setting up loopback devices or iscsi or bridging whatever) should
>> be executed directly by xl.  This naturally gives the best error
>> handling and makes logging easiest.
>>
>> However, if we are serious about supporting driver domains, or indeed
>> any kind of backend not running in the same domain as libxl, then
>> something in the driver domain needs to be responsible for executing
>> these scripts (or equivalent).
>>
>> The obvious way to communicate this information to the driver domain
>> is via xenstore.
>>
>> What we should be discussing is exactly how the driver domain
>> translates that into script execution.  Currently on Linux this is
>> mostly done with udev, and AIUI on BSD using xenbackendd.
>
> xenbackendd is (AFAIK) watching for events (e.g. creation and deletion
> of backend state nodes) in xenstore so at least in concept it is
> portable to all OSes, whereas udev is pretty Linux specific.
>
> One nice effect of the udev approach is that you get an explicit event
> e.g. when a block device is torn down. This makes it trivial to avoid
> problems like racing to teardown a loopback device.

I agree that executing scripts from xl is much more comfortable, and
it would be good to do it that way whenever possible. It allows easier
error detection and control of when hotplug scripts are executed.

> Since xenbackendd is mostly inferring things by watching the backend
> nodes used by the kernel side drivers it struggles due to the model
> where we rm the backend's xenstore directory on destroy which nukes
> state required by xenbackendd.
> The xenbackendd model seems slightly preferable to me, it's simpler to
> setup and more portable. Doing things differently on different OSes
> doesn't help with the confusion here!

xenbackend is a quite simple implementation, it only watches backend
changes and reacts upon them. It is easy to implement, but it is
difficult to debug, since hotplug execution is tied to xenstore
events, and right now there's no way to synchronize the toolstack with
xenbackend (xenbackend is only synchronized with the kernel).

> Perhaps the core functionality could be in libxl such that a toolstack
> can choose to integrate the functionality or run it as a separate daemon
> as necessary?

It would be interesting to implement all hotplug call functions into
libxl, and have a configuration option at xl.conf that specifies if
hotplug scripts should be executed from xl directly or delegate the
execution to xenbackend, that should be rewritten to use the same
libxl functions, to avoid having duplicate code.

> The main issue with the xenbackendd model is the manner in which it has
> to guess what is going on and try to synchronise with what the drivers
> are going. This does also effect the udev driven way of doing things too
> since the scripts often want to look in xenstore for parameters and on
> destroy they are often missing.
>
> We currently get this wrong under Linux at the minute and the network
> teardown hotplug script doesn't work right because the necessary bits
> are gone from xenstore. We mostly get away with this for bridging since
> the device is automatically remove from the bridge but for vswitch we do
> need to actually do some reconfiguration at this point. We also appear
> to leak iptables rules under some circumstances.
>
> Perhaps we would be better off splitting the hotplug stuff into its own
> place in xenstore and have the toolstack explicitly trigger events at
> the right time by writing to it? This could be compatible with existing
> scripts since they use an environment variable to find their xenstore
> base path.

Currently the only possible way to synchronize xenbackend and the
toolstack is to watch the hotplug-status xenbackend entry, I've posted
a patch a long time ago, that tried to synchronize xl and xenbackend
using the hotplug-status xenstore entry.

> We need to be aware that the script models (or at least the sequencing
> wrt the xenstore state transitions) vary slightly with the device type
> since for block devices you typically need to run the hotplug script
> before creating the backend whereas with network devices you create the
> device first and then run the script to configure it. vice versa for
> destroy.

I think that the easier way to deal with hotplug scripts is to execute
them when backend state is 2, that is true for both network and block
scripts (at least on NetBSD).

> We also need to consider Network tap devices. Not all tap devices are
> part of Xen's world which is a wrinkle which needs thought.
>
> I tried to write down my understanding of the events and sequencing
> under Linux but that mostly showed the gaps in my understanding...
>
> AIUI XCP does a lot more of this stuff via xenstored and have been
> (successfully) playing with driver domains -- we should ask for their
> input.
>

After all this, what seems most suitable to me is to have hotplug
script calling functions inside libxl, modify xenbackend to use libxl
API, and give the user the option to execute hotplug scripts directly
from xl (calling libxl hotplug functions) or delegate the work to
xenbackend (writing a value to xenstore that xenbackend can use to
synchronize and triggers execution).

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