Messages in this thread | | | Date | Mon, 9 Dec 2019 18:17:57 +0100 | From | Roger Pau Monné <> | Subject | Re: [Xen-devel] [PATCH 2/4] xenbus: limit when state is forced to closed |
| |
On Mon, Dec 09, 2019 at 04:26:15PM +0000, Durrant, Paul wrote: > > > If you want unbind to actually do a proper unplug then that's extra work > > and not really something I want to tackle (and re-bind would still need to > > be toolstack initiated as something would have to re-create the xenstore > > area). > > > > Why do you say the xenstore area would need to be recreated? > > > > Setting state to closed shouldn't cause any cleanup of the xenstore > > area, as that should already happen for example when using pvgrub > > since in that case grub itself disconnects and already causes a > > transition to closed and a re-attachment afterwards by the guest > > kernel. > > > > For some reason, when I originally tested, the xenstore area disappeared. I checked again and it did not this time. I just ended up with a frontend stuck in state 5 (because it is the system disk and won't go offline) trying to talk to a non-existent backend. Upon re-bind the backend goes into state 5 (because it sees the 5 in the frontend) and leaves the guest wedged.
Likely blkfront should go back to init state, but anyway, that's not something that needs fixing as part of this series.
Thanks, Roger.
| |