| Message ID | 20210312200740.815014-2-danielhb413@gmail.com |
|---|---|
| State | New |
| Headers | show |
| Series | DEVICE_NOT_DELETED/DEVICE_UNPLUG_ERROR QAPI events | expand |
On 3/12/21 2:07 PM, Daniel Henrique Barboza wrote: > This new event informs QAPI listeners that a previously issued > 'device_del' command failed to delete the device from the machine. > > Note that no assertion can be made about the failure reason. The goal of > this event is to inform management that QEMU is not able to assess > whether the hotunplug is taking too long to complete or failed in the > guest and, as result, the device is not removed from QOM. When receiving > this event, users/management must check inside the guest to verify the > result of the hotunplug operation. > > This scenario happens with architectures where the guest does not have > an official way to report the hotunplug error back to the hypervisor, > such as PowerPC and the pseries machine type. > > Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> > --- > qapi/qdev.json | 28 ++++++++++++++++++++++++++++ > 1 file changed, 28 insertions(+) > > diff --git a/qapi/qdev.json b/qapi/qdev.json > index b83178220b..df9a1b9e67 100644 > --- a/qapi/qdev.json > +++ b/qapi/qdev.json > @@ -124,3 +124,31 @@ > ## > { 'event': 'DEVICE_DELETED', > 'data': { '*device': 'str', 'path': 'str' } } > + > +## > +# @DEVICE_NOT_DELETED: > +# > +# Emitted whenever the device removal process expired and the device > +# still exists in QOM. This indicates that the guest took too long > +# to acknowlege the device removal, and we can not be sure of whether acknowledge > +# the process will be completed in the guest later on or a guest > +# side error occurred. > +# > +# It is not safe to reuse the specified device ID. > +# > +# @device: device name > +# > +# @path: device path > +# > +# Since: 6.0 This is a new event, and we've missed feature freeze; is this fixing a bug that was not present in 5.2 (in which case it is fine for -rc1), or is this a long-standing problem where one more release without the mechanism won't make life any worse? > +# > +# Example: > +# > +# <- { "event": "DEVICE_NOT_DELETED", > +# "data": { "device": "core1", > +# "path": "/machine/peripheral/core1" }, > +# "timestamp": { "seconds": 1615570254, "microseconds": 573986 } } > +# > +## > +{ 'event': 'DEVICE_NOT_DELETED', > + 'data': { '*device': 'str', 'path': 'str' } } > \ No newline at end of file You'll want to fix that.
On 3/23/21 3:00 PM, Eric Blake wrote: > On 3/12/21 2:07 PM, Daniel Henrique Barboza wrote: >> This new event informs QAPI listeners that a previously issued >> 'device_del' command failed to delete the device from the machine. >> >> Note that no assertion can be made about the failure reason. The goal of >> this event is to inform management that QEMU is not able to assess >> whether the hotunplug is taking too long to complete or failed in the >> guest and, as result, the device is not removed from QOM. When receiving >> this event, users/management must check inside the guest to verify the >> result of the hotunplug operation. >> >> This scenario happens with architectures where the guest does not have >> an official way to report the hotunplug error back to the hypervisor, >> such as PowerPC and the pseries machine type. >> >> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> >> --- >> qapi/qdev.json | 28 ++++++++++++++++++++++++++++ >> 1 file changed, 28 insertions(+) >> >> diff --git a/qapi/qdev.json b/qapi/qdev.json >> index b83178220b..df9a1b9e67 100644 >> --- a/qapi/qdev.json >> +++ b/qapi/qdev.json >> @@ -124,3 +124,31 @@ >> ## >> { 'event': 'DEVICE_DELETED', >> 'data': { '*device': 'str', 'path': 'str' } } >> + >> +## >> +# @DEVICE_NOT_DELETED: >> +# >> +# Emitted whenever the device removal process expired and the device >> +# still exists in QOM. This indicates that the guest took too long >> +# to acknowlege the device removal, and we can not be sure of whether > > acknowledge > >> +# the process will be completed in the guest later on or a guest >> +# side error occurred. >> +# >> +# It is not safe to reuse the specified device ID. >> +# >> +# @device: device name >> +# >> +# @path: device path >> +# >> +# Since: 6.0 > > This is a new event, and we've missed feature freeze; is this fixing a > bug that was not present in 5.2 (in which case it is fine for -rc1), or > is this a long-standing problem where one more release without the > mechanism won't make life any worse? I believe these events I'm trying to add can be postponed to the next release. > >> +# >> +# Example: >> +# >> +# <- { "event": "DEVICE_NOT_DELETED", >> +# "data": { "device": "core1", >> +# "path": "/machine/peripheral/core1" }, >> +# "timestamp": { "seconds": 1615570254, "microseconds": 573986 } } >> +# >> +## >> +{ 'event': 'DEVICE_NOT_DELETED', >> + 'data': { '*device': 'str', 'path': 'str' } } >> \ No newline at end of file > > You'll want to fix that. Yep, in both patches (1 and 3). Thanks, DHB >
diff --git a/qapi/qdev.json b/qapi/qdev.json index b83178220b..df9a1b9e67 100644 --- a/qapi/qdev.json +++ b/qapi/qdev.json @@ -124,3 +124,31 @@ ## { 'event': 'DEVICE_DELETED', 'data': { '*device': 'str', 'path': 'str' } } + +## +# @DEVICE_NOT_DELETED: +# +# Emitted whenever the device removal process expired and the device +# still exists in QOM. This indicates that the guest took too long +# to acknowlege the device removal, and we can not be sure of whether +# the process will be completed in the guest later on or a guest +# side error occurred. +# +# It is not safe to reuse the specified device ID. +# +# @device: device name +# +# @path: device path +# +# Since: 6.0 +# +# Example: +# +# <- { "event": "DEVICE_NOT_DELETED", +# "data": { "device": "core1", +# "path": "/machine/peripheral/core1" }, +# "timestamp": { "seconds": 1615570254, "microseconds": 573986 } } +# +## +{ 'event': 'DEVICE_NOT_DELETED', + 'data': { '*device': 'str', 'path': 'str' } } \ No newline at end of file
This new event informs QAPI listeners that a previously issued 'device_del' command failed to delete the device from the machine. Note that no assertion can be made about the failure reason. The goal of this event is to inform management that QEMU is not able to assess whether the hotunplug is taking too long to complete or failed in the guest and, as result, the device is not removed from QOM. When receiving this event, users/management must check inside the guest to verify the result of the hotunplug operation. This scenario happens with architectures where the guest does not have an official way to report the hotunplug error back to the hypervisor, such as PowerPC and the pseries machine type. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> --- qapi/qdev.json | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+)