From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:52867) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TkhWu-0003Bc-JJ for qemu-devel@nongnu.org; Mon, 17 Dec 2012 15:43:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TkhWr-0005XZ-To for qemu-devel@nongnu.org; Mon, 17 Dec 2012 15:43:16 -0500 Received: from mx1.redhat.com ([209.132.183.28]:8752) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TkhWr-0005XQ-Lj for qemu-devel@nongnu.org; Mon, 17 Dec 2012 15:43:13 -0500 Date: Mon, 17 Dec 2012 22:46:16 +0200 From: "Michael S. Tsirkin" Message-ID: <20121217204616.GA30842@redhat.com> References: <1354887155-32281-1-git-send-email-fred.konrad@greensocs.com> <20121217154508.GA28712@redhat.com> <50CF52B8.4000701@greensocs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <50CF52B8.4000701@greensocs.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH v6 0/6] Virtio refactoring. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: KONRAD =?iso-8859-1?Q?Fr=E9d=E9ric?= 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 Mon, Dec 17, 2012 at 06:13:28PM +0100, KONRAD Fr=E9d=E9ric wrote: > On 17/12/2012 16:45, Michael S. Tsirkin wrote: > >On Fri, Dec 07, 2012 at 02:32:29PM +0100, fred.konrad@greensocs.com wr= ote: > >>From: KONRAD Frederic > >> > >>You can clone that from here : > >>git.greensocs.com/home/greensocs/git/qemu_virtio.git virtio_refactori= ng_v6 > >> > >>The problem with the last RFC v5 was that virtio-blk refactoring brok= e > >>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-pc= i-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 o= f > >the previous messages mentioned this is to allow virtio-mmio. > Yes, the main goal is to have the choice of the transport device. >=20 > eg : >=20 > -device virtio-pci,id=3Dtransport1 -device virtio-scsi,bus=3Dtransport1 >=20 > or >=20 > -device virtio-mmio,id=3Dtransport1 -device virtio-scsi,bus=3Dtransport= 1 > That's why anthony suggest to create a virtio-bus to connect > transport to device. If it's an implementation detail, fine. If it's user-visible, I think it's a bad idea. > so all virtio-x devices must be created. And virtio-pci must have a > virtio-bus. >=20 > 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 ? Yes or to be closer to what we do with pci, virtio-x-mmio. > > > >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 br= eaks > virtio-blk-pci and virtio-blk-s390 devices as they didn't use QOM. > But the newer version ( V7 ) didn't break anything. No, my question was why is all this useful? > > > >If this was covered but I missed this I'll be thankful for > >pointers if any. > >Thanks, > >