qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v4 1/3] qapi/qdev.json: add DEVICE_UNPLUG_ERROR QAPI event


From: David Gibson
Subject: Re: [PATCH v4 1/3] qapi/qdev.json: add DEVICE_UNPLUG_ERROR QAPI event
Date: Mon, 12 Jul 2021 12:26:18 +1000

On Thu, Jul 08, 2021 at 03:01:20PM +0200, Markus Armbruster wrote:
> Daniel Henrique Barboza <danielhb413@gmail.com> writes:
> 
> > At this moment we only provide one event to report a hotunplug error,
> > MEM_UNPLUG_ERROR. As of Linux kernel 5.12 and QEMU 6.0.0, the pseries
> > machine is now able to report unplug errors for other device types, such
> > as CPUs.
> >
> > Instead of creating a (device_type)_UNPLUG_ERROR for each new device,
> > create a generic DEVICE_UNPLUG_ERROR event that can be used by all
> > unplug errors in the future.
> >
> > With this new generic event, MEM_UNPLUG_ERROR is now marked as deprecated.
> >
> > Reviewed-by: David Gibson <david@gibson.dropbear.id.au>
> > Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
> > ---
> >  docs/system/deprecated.rst | 10 ++++++++++
> >  qapi/machine.json          |  6 +++++-
> >  qapi/qdev.json             | 27 ++++++++++++++++++++++++++-
> >  3 files changed, 41 insertions(+), 2 deletions(-)
> >
> > diff --git a/docs/system/deprecated.rst b/docs/system/deprecated.rst
> > index 70e08baff6..ca6c7f9d43 100644
> > --- a/docs/system/deprecated.rst
> > +++ b/docs/system/deprecated.rst
> > @@ -204,6 +204,16 @@ The ``I7200`` guest CPU relies on the nanoMIPS ISA, 
> > which is deprecated
> >  (the ISA has never been upstreamed to a compiler toolchain). Therefore
> >  this CPU is also deprecated.
> >  
> > +
> > +QEMU API (QAPI) events
> > +----------------------
> > +
> > +``MEM_UNPLUG_ERROR`` (since 6.1)
> > +''''''''''''''''''''''''''''''''''''''''''''''''''''''''
> > +
> > +Use the more generic event ``DEVICE_UNPLUG_ERROR`` instead.
> > +
> > +
> >  System emulator machines
> >  ------------------------
> >  
> > diff --git a/qapi/machine.json b/qapi/machine.json
> > index c3210ee1fb..a595c753d2 100644
> > --- a/qapi/machine.json
> > +++ b/qapi/machine.json
> > @@ -1271,6 +1271,9 @@
> >  #
> >  # @msg: Informative message
> >  #
> > +# Features:
> > +# @deprecated: This event is deprecated. Use @DEVICE_UNPLUG_ERROR instead.
> > +#
> >  # Since: 2.4
> >  #
> >  # Example:
> > @@ -1283,7 +1286,8 @@
> >  #
> >  ##
> >  { 'event': 'MEM_UNPLUG_ERROR',
> > -  'data': { 'device': 'str', 'msg': 'str' } }
> > +  'data': { 'device': 'str', 'msg': 'str' },
> > +  'features': ['deprecated'] }
> >  
> >  ##
> >  # @SMPConfiguration:
> > diff --git a/qapi/qdev.json b/qapi/qdev.json
> > index b83178220b..349d7439fa 100644
> > --- a/qapi/qdev.json
> > +++ b/qapi/qdev.json
> > @@ -84,7 +84,9 @@
> >  #        This command merely requests that the guest begin the hot removal
> >  #        process.  Completion of the device removal process is signaled 
> > with a
> >  #        DEVICE_DELETED event. Guest reset will automatically complete 
> > removal
> > -#        for all devices.
> > +#        for all devices. If an error in the hot removal process is 
> > detected,
> > +#        the device will not be removed and a DEVICE_UNPLUG_ERROR event is
> > +#        sent.
> 
> "If an error ... is detected" kind of implies that some errors may go
> undetected.  Let's spell this out more clearly.  Perhaps append "Some
> errors cannot be detected."
> 
> DEVICE_UNPLUG_ERROR's unrelability is awkward.  Best we can do in the
> general case.  Can we do better in special cases, and would it be
> worthwhile?  If yes, it should probably be done on top.

I can't rule out such a special case entirely, but it's pretty hard to
imagine.  If we need any kind of acknowledgement from the guest to
complete the unplug, then the unplug failing but the guest never
reporting anything is going to be indistinguishable from the guest
working on the unplug but being super slow.

-- 
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                                | _way_ _around_!
http://www.ozlabs.org/~dgibson

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]