Re: [RFC] adding a generic QAPI event for failed device hotunplug

[Markus Armbruster]

Cc: ACPI maintainers for additional expertise.

Daniel Henrique Barboza <danielhb413@gmail.com> writes:

> Hi,
>
> Recent changes in pseries code (not yet pushed, available at David's
> ppc-for-6.0) are using the QAPI event MEM_UNPLUG_ERROR to report memory
> hotunplug errors in the pseries machine.
>
> The pseries machine is also using a timeout to cancel CPU hotunplugs that
> takes too long to finish (in which we're assuming a guest side error) and
> it would be desirable to also send a QAPI event for this case as well.
>
> At this moment, there is no "CPU_UNPLUG_ERROR" in QAPI (guess ACPI doesn't
> need it).

I see two interpretations of "ACPI doesn't need":

1. Unplug can't fail, or QEMU can't detect failure.  Michael, Igor?

2. Management applications haven't needed to know badly enough to
implement an event.

>           Before sending patches to implement this new event I had a talk
> with David Gibson and he suggested that, instead of adding a new 
> CPU_UNPLUG_ERROR
> event, we could add a generic event (e.g. DEVICE_UNPLUG_ERROR) that can be
> used by the pseries machine in both error scenarios (MEM and CPU).

Good point.  One general event is better than two special ones that
could easily grow siblings.

> This could also be used by x86 as well, although I believe the use of
> MEM_UNPLUG_ERROR would need to be kept for awhile to avoid breaking ABI.

Yes.  Our rules for interface deprecation apply.

> Any suggestions/comments?

We should document the event's reliability.  Are there unplug operations
where we can't detect failure?  Are there unplug operations where we
could, but haven't implemented the event?

The fewer exceptions, the better, of course.