From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37267) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TkeGF-0007lQ-9L for qemu-devel@nongnu.org; Mon, 17 Dec 2012 12:13:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TkeGD-0004MJ-Dy for qemu-devel@nongnu.org; Mon, 17 Dec 2012 12:13:51 -0500 Received: from greensocs.com ([87.106.252.221]:57010 helo=s15328186.onlinehome-server.info) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TkeGD-0004M0-0A for qemu-devel@nongnu.org; Mon, 17 Dec 2012 12:13:49 -0500 Message-ID: <50CF52B8.4000701@greensocs.com> Date: Mon, 17 Dec 2012 18:13:28 +0100 From: =?ISO-8859-1?Q?KONRAD_Fr=E9d=E9ric?= MIME-Version: 1.0 References: <1354887155-32281-1-git-send-email-fred.konrad@greensocs.com> <20121217154508.GA28712@redhat.com> In-Reply-To: <20121217154508.GA28712@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH v6 0/6] Virtio refactoring. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: peter.maydell@linaro.org, aliguori@us.ibm.com, e.voevodin@samsung.com, mark.burton@greensocs.com, qemu-devel@nongnu.org, stefanha@redhat.com, cornelia.huck@de.ibm.com, afaerber@suse.de On 17/12/2012 16:45, Michael S. Tsirkin wrote: > On Fri, Dec 07, 2012 at 02:32:29PM +0100, fred.konrad@greensocs.com wrote: >> From: KONRAD Frederic >> >> You can clone that from here : >> git.greensocs.com/home/greensocs/git/qemu_virtio.git virtio_refactoring_v6 >> >> The problem with the last RFC v5 was that virtio-blk refactoring broke >> virtio-blk-pci device ( SEGFAULT ). So I modify this last step to fix that >> issue. >> >> In order to not break anything, I think we have to refactor virtio-pci-blk in a >> next step then add a supplementary step which clean virtio-blk >> ( eg : fix the cast ). >> >> Does it make sense ? > I am yet to go over the patches but I did try to read > previous discussion and I am still puzzled about the motivation. One of > the previous messages mentioned this is to allow virtio-mmio. Yes, the main goal is to have the choice of the transport device. eg : -device virtio-pci,id=transport1 -device virtio-scsi,bus=transport1 or -device virtio-mmio,id=transport1 -device virtio-scsi,bus=transport1 That's why anthony suggest to create a virtio-bus to connect transport to device. so all virtio-x devices must be created. And virtio-pci must have a virtio-bus. Then to keep compability with the older version virtio-x-pci must create virtio-pci and virtio-x. > > Is the point to allow virtio-mmio? Why can't virtio-mmio be just > another bus, like a pci bus, and another binding, like the virtio-pci > binding? Do you mean something like creating all virtio device like virtio-mmio-x ? > > Is the issue that bindings are not devices? > I'm sending a patchset to use DeviceState as binding pointer - > will this address the issue? The issue is that all is linked, and here the virtio-blk refactoring breaks virtio-blk-pci and virtio-blk-s390 devices as they didn't use QOM. But the newer version ( V7 ) didn't break anything. > > If this was covered but I missed this I'll be thankful for > pointers if any. > Thanks, >