qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Henrique Barboza <danielhb413@gmail.com>
To: Eric Blake <eblake@redhat.com>, qemu-devel@nongnu.org
Cc: david@gibson.dropbear.id.au, qemu-ppc@nongnu.org,
	armbru@redhat.com, groug@kaod.org
Subject: Re: [PATCH 1/4] qapi/qdev.json: add DEVICE_NOT_DELETED event
Date: Tue, 23 Mar 2021 15:12:27 -0300	[thread overview]
Message-ID: <738d6f71-ec0d-8a82-a99c-df3f9e1d5f90@gmail.com> (raw)
In-Reply-To: <02e3226b-647f-2282-d61b-5f571d796471@redhat.com>



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


> 


  reply	other threads:[~2021-03-23 18:59 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-12 20:07 [PATCH 0/4] DEVICE_NOT_DELETED/DEVICE_UNPLUG_ERROR QAPI events Daniel Henrique Barboza
2021-03-12 20:07 ` [PATCH 1/4] qapi/qdev.json: add DEVICE_NOT_DELETED event Daniel Henrique Barboza
2021-03-23 18:00   ` Eric Blake
2021-03-23 18:12     ` Daniel Henrique Barboza [this message]
2021-03-12 20:07 ` [PATCH 2/4] spapr_drc.c: send DEVICE_NOT_DELETED event on unplug timeout Daniel Henrique Barboza
2021-03-12 20:07 ` [PATCH 3/4] qapi/machine.json: add DEVICE_UNPLUG_ERROR QAPI event Daniel Henrique Barboza
2021-03-12 20:07 ` [PATCH 4/4] spapr.c: use DEVICE_UNPLUG_ERROR event in spapr_memory_unplug_rollback() Daniel Henrique Barboza
2021-03-23  1:12 ` [PATCH 0/4] DEVICE_NOT_DELETED/DEVICE_UNPLUG_ERROR QAPI events David Gibson
2021-03-23 17:10   ` Daniel Henrique Barboza
2021-03-24  1:40     ` David Gibson
2021-03-24 19:09       ` Daniel Henrique Barboza
2021-03-25  1:32         ` David Gibson
2021-03-29 23:28         ` Igor Mammedov
2021-03-30 23:46           ` David Gibson
2021-03-31  9:49             ` Igor Mammedov
2021-04-01  1:31               ` David Gibson
2021-03-31 19:47             ` Daniel Henrique Barboza
2021-04-01  1:36               ` David Gibson
2021-03-31 19:40           ` Daniel Henrique Barboza
2021-04-20 17:11 ` Daniel Henrique Barboza

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=738d6f71-ec0d-8a82-a99c-df3f9e1d5f90@gmail.com \
    --to=danielhb413@gmail.com \
    --cc=armbru@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=eblake@redhat.com \
    --cc=groug@kaod.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).