Re: [Xen-devel] [PATCH 12 of 14 v4] libxl: set frontend status to 6 on domain destroy

[Roger Pau Monnà <roger.pau@xxxxxxxxxxxxx>]

2011/12/14 Ian Campbell <Ian.Campbell@xxxxxxxxxx>:
> On Wed, 2011-12-14 at 11:12 +0000, Roger Pau Monnà wrote:
>> 2011/12/14 Ian Campbell <Ian.Campbell@xxxxxxxxxx>:
>> > 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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel