> -----Original Message-----
> From: Ian Jackson <i...@xenproject.org>
> Sent: 28 September 2020 14:44
> To: Wei Liu <w...@xen.org>
> Cc: Roger Pau Monné <roger....@citrix.com>; Paul Durrant <p...@xen.org>; xen-
> de...@lists.xenproject.org; Durrant, Paul <pdurr...@amazon.co.uk>; Anthony
> PERARD
> <anthony.per...@citrix.com>
> 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
