From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60831) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X0RdZ-0002e1-IR for qemu-devel@nongnu.org; Fri, 27 Jun 2014 04:36:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X0RdR-0002ey-LU for qemu-devel@nongnu.org; Fri, 27 Jun 2014 04:36:01 -0400 Received: from cantor2.suse.de ([195.135.220.15]:59389 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X0RdR-0002dB-Fg for qemu-devel@nongnu.org; Fri, 27 Jun 2014 04:35:53 -0400 Message-ID: <53AD2CE7.2000200@suse.de> Date: Fri, 27 Jun 2014 10:35:51 +0200 From: =?ISO-8859-15?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1403788203-9364-1-git-send-email-pbonzini@redhat.com> <87a98y2566.fsf@blackfin.pond.sub.org> In-Reply-To: <87a98y2566.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH for 2.1] qdev: correctly send DEVICE_DELETED for recursively-deleted devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster , Paolo Bonzini Cc: Bandan Das , qemu-devel@nongnu.org Am 27.06.2014 09:16, schrieb Markus Armbruster: > Paolo Bonzini writes: >=20 >> When a device is unparented (i.e. made completely hidden from manageme= nt) >> we want to send a DEVICE_DELETED event only if the device actually was >> realized. This avoids raising DEVICE_DELETED events when device_add >> fails. >> >> However, this does not work right for recursively-deleted >> devices: the whole tree is _first_ unrealized, _then_ unparented. >> Then device_unparent sees realized=3D=3Dfalse and fails to trigger >> the event. The solution is simply to move have_realized into >> the DeviceState struct. If device_add fails, we never set the >> new field to true and DEVICE_DELETED is not sent. >> >> Fixes qemu-iotests testcase 067. >=20 > Suggest to add "Broken in commit 5942a19" here, to make it clear that > it's a recent regression. I vaguely recall that something like this was in Bandan's RFC (that I assume the above commit forward-ported, the subject would be handy to mention too), but once again without any explanation why, so I saw no need to apply that during hardfreeze. Andreas >> Reported-by: Markus Armbruster >> Signed-off-by: Paolo Bonzini > Reviewed-by: Markus Armbruster --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg