From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57164) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tj4Ys-00031w-BV for qemu-devel@nongnu.org; Thu, 13 Dec 2012 03:54:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tj4Yl-0005Bf-MP for qemu-devel@nongnu.org; Thu, 13 Dec 2012 03:54:34 -0500 Received: from mx1.redhat.com ([209.132.183.28]:29528) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tj4Yl-0005BK-E5 for qemu-devel@nongnu.org; Thu, 13 Dec 2012 03:54:27 -0500 Message-ID: <50C997BF.80200@redhat.com> Date: Thu, 13 Dec 2012 09:54:23 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1355322396-32026-1-git-send-email-pbonzini@redhat.com> <20121212153821.GA17446@redhat.com> <50C8B2FD.5030200@redhat.com> <20121212171847.GC18597@redhat.com> <50C8BF83.4010307@redhat.com> <20121212212720.GC23087@redhat.com> In-Reply-To: <20121212212720.GC23087@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/2] virtio: reset all qbuses too when writing to the status field List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: agraf@suse.de, qemu-devel Il 12/12/2012 22:27, Michael S. Tsirkin ha scritto: >>> Maybe it's obvious to you that qdev_reset_all(x) >>> does a soft reset and what soft reset means >>> for each bus type >> >> We can define soft reset to be *independent* of the bus type. As you >> said, you access it with a device register. > > I think qemu has one type of reset ATM which is the hard reset. A hard reset would kill BARs and configuration space too. qdev_reset_all doesn't. Ergo, it is not a hard reset. But hey, I'm not wed to names. Let's call it device-level reset and bus-level reset. Whatever. > Any other kind is device specific now. > The fact that qdev has two APIs which are kind of but not > exactly the same is a bug not a feature. BusState reset and DeviceState reset are not the same because they are triggered differently, one by bus-level functionality (e.g. FLR) and the other by device-level functionality (e.g. a register). That's neither a bug nor a feature. It's just obvious. > And relying on it in generic virtio is just going to > confuse things. It is going to confuse you perhaps, but it will not confuse whoever will write the next virtio device with a bus. Who knows, virtio-i2c. > Further it does not follow that all backends are children > of the frontend. Backends are not children of the frontend. Seriously, this is qdev 101. virtio-scsi has no backend. Frontends (disks) are children of virtio-scsi. Each backend (host block device) is connected to a child of virtio-scsi. virtio-scsi does not need to reset back-ends. It needs to reset front-ends. virtio-serial does not know it needs to reset back-ends. It knows it needs to reset front-ends. Each reset of the front-end will also propagate to a back-end, but virtio-serial need not know that. > So please just fix the virtio-scsi bug for now and we can > address the bigger issue if any later. I'm refusing to fix the bug in virtio-scsi. It is not a virtio-scsi bug, as proved by the virtio-serial bus having to do the same things. Two wrongs do not make a right, and here we have three wrongs already: virtio-pci, virtio-s390, virtio-serial all reinventing the wheel. Paolo