RE: [PATCH 2/2] libxl: do not automatically force detach of block devices

[Paul Durrant <xadimgnik@xxxxxxxxx>]

> -----Original Message-----
> From: Ian Jackson <iwj@xxxxxxxxxxxxxx>
> Sent: 28 September 2020 14:44
> To: Wei Liu <wl@xxxxxxx>
> Cc: Roger Pau Monné <roger.pau@xxxxxxxxxx>; Paul Durrant <paul@xxxxxxx>; xen-
> devel@xxxxxxxxxxxxxxxxxxxx; Durrant, Paul <pdurrant@xxxxxxxxxxxx>; Anthony 
> PERARD
> <anthony.perard@xxxxxxxxxx>
> Subject: RE: [EXTERNAL] [PATCH 2/2] libxl: do not automatically force detach 
> of block devices
> 
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open
> attachments unless you can confirm the sender and know the content is safe.
> 
> 
> 
> Wei Liu writes ("Re: [PATCH 2/2] libxl: do not automatically force detach of 
> block devices"):
> > On Mon, Sep 14, 2020 at 12:41:09PM +0200, Roger Pau Monné wrote:
> > > Maybe a new function should be introduced instead, that attempts to
> > > remove a device gracefully and fail otherwise?
> > >
> > > Then none of the current APIs would change, and xl could use this new
> > > function to handle VBD removal?
> >
> > This sounds fine to me.
> 
> I agree.
> 
> If there is going to be different default policy for different devices
> it ought to be in xl, not libxl, but frankly I think this is an
> anomaly.
> 
> I suggest we have a new entrypoint that specifies the fallback
> behaviour explicitly.

Indeed. See v2 of my series, posted a couple of weeks ago, specifically:

https://lists.xenproject.org/archives/html/xen-devel/2020-09/msg01029.html

>  ISTM that there are three possible behaviours:
>  - fail if the guest does not cooperate

That is the newly introduced 'safe_remove'

>  - fall back to force remove

That is the existing 'remove'

>  - rip the device out immediately

That is the existing 'destroy'

> The last of these would be useful only in rare situations.  IDK if the
> length of the timeout (for the first two cases) ought to be a
> parameter too.
> 

I think that would be a worthy enhancement but above and beyond the aim of this 
series.

  Paul