From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60481) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TkzG3-0004F7-8c for qemu-devel@nongnu.org; Tue, 18 Dec 2012 10:39:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TkzFy-0000Sl-Fp for qemu-devel@nongnu.org; Tue, 18 Dec 2012 10:39:03 -0500 Received: from mx1.redhat.com ([209.132.183.28]:1978) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TkzFy-0000Sc-82 for qemu-devel@nongnu.org; Tue, 18 Dec 2012 10:38:58 -0500 Message-ID: <50D084EF.5030405@redhat.com> Date: Tue, 18 Dec 2012 15:59:59 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <1354887155-32281-1-git-send-email-fred.konrad@greensocs.com> <20121217154508.GA28712@redhat.com> <20121218110153.GC22586@redhat.com> <50D05898.9030506@redhat.com> <20121218131043.GA26110@redhat.com> <50D07F50.6010800@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 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: Peter Maydell Cc: aliguori@us.ibm.com, e.voevodin@samsung.com, "Michael S. Tsirkin" , mark.burton@greensocs.com, qemu-devel@nongnu.org, stefanha@redhat.com, cornelia.huck@de.ibm.com, afaerber@suse.de, fred.konrad@greensocs.com Il 18/12/2012 15:56, Peter Maydell ha scritto: > On 18 December 2012 14:36, Paolo Bonzini wrote: >> Yes, that's true. And you're basically using virtio as the pluggable >> discoverable bus, which is actually a pretty good idea. >> >> However, what you are doing is very similar to what virtio-s390 does, >> and it manages to do it just fine with the existing virtio.c >> infrastructure. The only difference is that you have a 1:1 relationship >> between virtio-mmio "slots" described by the board and virtio-mmio >> devices added by the user. > > Also it looks like the board model and the 'bridge' and the transport > implementation are all collaborating to get the virtio memory sorted > out, rather than it just being "instantiate a bridge here"... But s390 is weird. :) >> True, it is not pure qdev, but it is much simpler and doesn't require >> convincing grumpy maintainers. :) > > I'm not actually personally all that attached to this design -- it's just > trying to implement a suggestion by Anthony. Yes, and I agree FWIW. > It does seem frankly bizarre that adding a new transport requires > knowing about all the backends (notice how s390-virtio-bus.c has > to register types for each backend). The kernel gets the transport > vs backend separation much cleaner and it was much easier to > add the virtio support there. Yes, I agree. However, to some extent it's unavoidable. For example, the PCI transport needs to know the class id for each backend. You may have a single virtio-pci device types, or separate types for virtio-blk/net/scsi-pci, but it's true anyway. Paolo