From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50852) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZEgFn-0002aS-G1 for qemu-devel@nongnu.org; Mon, 13 Jul 2015 12:06:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZEgFj-0003dd-FM for qemu-devel@nongnu.org; Mon, 13 Jul 2015 12:06:51 -0400 Received: from cantor2.suse.de ([195.135.220.15]:47597 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZEgFj-0003cb-9P for qemu-devel@nongnu.org; Mon, 13 Jul 2015 12:06:47 -0400 Message-ID: <55A3E215.20305@suse.de> Date: Mon, 13 Jul 2015 18:06:45 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1436460692-5142-1-git-send-email-cornelia.huck@de.ibm.com> <1436460692-5142-2-git-send-email-cornelia.huck@de.ibm.com> <55A3AD6D.5010303@de.ibm.com> <20150713161152.3e519fcd.cornelia.huck@de.ibm.com> <55A3C919.1040400@suse.de> <20150713163727.4b18f409.cornelia.huck@de.ibm.com> In-Reply-To: <20150713163727.4b18f409.cornelia.huck@de.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH for-2.4 1/2] core: reset handler for bus-less devices List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cornelia Huck Cc: peter.crosthwaite@xilinx.com, qemu-devel@nongnu.org, agraf@suse.de, Christian Borntraeger , jfrei@linux.vnet.ibm.com, gesaint@linux.vnet.ibm.com Am 13.07.2015 um 16:37 schrieb Cornelia Huck: > On Mon, 13 Jul 2015 16:20:09 +0200 > Andreas F=C3=A4rber wrote: >=20 >> Am 13.07.2015 um 16:11 schrieb Cornelia Huck: >>> On Mon, 13 Jul 2015 14:22:05 +0200 >>> Christian Borntraeger wrote: >>> >>> Any objections against taking this through s390-next? I'd like to fix >>> diag288 reset (+ that annoying migration regession) for 2.4-rc1 and >>> send a pull request soon. >> >> Which device does this fix (only this diag88?), and is it really not >> possible to register a reset handler where it's being created? >=20 > The original patch did this > (<1436259202-20509-2-git-send-email-cornelia.huck@de.ibm.com>). Peter > C. suspected NAND may also be affected > (). Found it. So the problem *is* different from what I understood! It's not directly attached to /machine by s390x code, but rather instantiated via -device by the user. Peter C. suggested you to do it in realize, which affects all devices. The solution would be to instead either do the reset registration in qdev-monitor.c, where it's specific to devices that do not have a bus and on /machine/peripheral or /machine/periph-anon are not managed by a parent, or to add a further check here in realized. Right now I can only think of a hot-plug flag...? Not sure about unrealizing in the qdev-monitor case, but I think we can ignore that in this case? >> Peter C.'s theory does not match practice for x86, and this patch will >> lead to bus-less devices that are properly being reset by their parent >> getting reset twice, potentially causing issues due to qemu_irqs. I'd >> rather avoid that. >=20 > Introducing new bugs is not something I want to do. Are double resets a > problem in practice, though? Not the double part, the relative ordering. Regards, Andreas --=20 SUSE Linux GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Felix Imend=C3=B6rffer, Jane Smithard, Dilip Upmanyu, Graham Norton; = HRB 21284 (AG N=C3=BCrnberg)