From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60703) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tsa9r-0000O8-Hh for qemu-devel@nongnu.org; Tue, 08 Jan 2013 09:28:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tsa9m-0004Jf-0M for qemu-devel@nongnu.org; Tue, 08 Jan 2013 09:28:03 -0500 Received: from greensocs.com ([87.106.252.221]:59629 helo=s15328186.onlinehome-server.info) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tsa9l-0004JN-MA for qemu-devel@nongnu.org; Tue, 08 Jan 2013 09:27:57 -0500 Message-ID: <50EC2CE7.5090702@greensocs.com> Date: Tue, 08 Jan 2013 15:27:51 +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> <20121218110153.GC22586@redhat.com> <50D053CC.9040203@greensocs.com> <20130107195843.GC8679@redhat.com> <50EBED66.6080606@greensocs.com> <20130108140205.GB23732@redhat.com> In-Reply-To: <20130108140205.GB23732@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: "Michael S. Tsirkin" Cc: Peter Maydell , 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 08/01/2013 15:02, Michael S. Tsirkin wrote: > On Tue, Jan 08, 2013 at 10:56:54AM +0100, KONRAD Fr=E9d=E9ric wrote: >> On 07/01/2013 20:58, Michael S. Tsirkin wrote: >>> On Tue, Dec 18, 2012 at 12:30:20PM +0100, KONRAD Fr=E9d=E9ric wrote: >>>> On 18/12/2012 12:01, Michael S. Tsirkin wrote: >>>>> On Tue, Dec 18, 2012 at 10:33:37AM +0000, Peter Maydell wrote: >>>>>> On 17 December 2012 15:45, Michael S. Tsirkin wro= te: >>>>>>> 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? >>>>>> (a) the current code is really not very nice because it's not >>>>>> actually a proper set of QOM/qdev devices >>>>>> (b) unlike PCI, you can't create sysbus devices on the >>>>>> command line, because they don't correspond to a user >>>>>> pluggable bit of hardware. We don't want users to have to know >>>>>> an address and IRQ number for each virtio-mmio device (especially >>>>>> since these are board specific); instead the board can create >>>>>> and wire up transport devices wherever is suitable, and the >>>>>> user just creates the backend (which is plugged into the virtio bu= s). >>>>>> >>>>>> -- PMM >>>>> This is what I am saying: create your own bus and put >>>>> your devices there. Allocate resources when you init >>>>> a device. >>>>> >>>>> Instead you seem to want to expose a virtio device as two devices t= o >>>>> user - if true this is not reasonable. >>>>> >>>> The modifications will be transparent to the user, as we will keep >>>> virtio-x-pci devices. >>> Then what's the point of all this? >>> >>> -device virtio-pci,id=3Dtransport1 -device virtio-net,bus=3Dtransport= 1 >>> >>> or >>> >>> -device virtio-mmio,id=3Dtransport1 -device virtio-net,bus=3Dtranspor= t1 >>> >>> Is simply an insane way to create a network device. >>> >> To recap : >> >> The idea is to have a virtio-bus between the transport device >> (like pci, mmio,... ). >> >> Then we can have a platform with several virtio-mmio and then >> virtio-bus slot. >> >> At the end user can add a virtio-device in the command line with -devi= ce >> parameter without recompiling the platform. That is not possible with = just >> creating the virtio-x-mmio devices. The bus=3D option can be used to >> select the bus slot, but I'm not sure it is usefull. > pci uses addr option for this, I am guessing mmio can do the same. > >> The series keep the virtio-x-pci devices : >> eg : step 11/61 for virtio-blk >> So -device virtio-blk-pci or -device virtio-blk-s390 works as before. >> >> Of course -device virtio-pci,id=3Dtransport1 -device >> virtio-net,bus=3Dtransport1 is >> possible but why using this command line when we could simply do : >> -device virtio-net-pci ? >> >> Fred > Adding multiple ways to do one thing is a bad idea. > I'm fine with modeling virtio by multiple devices > internally, but exposing this to user is a mistake, > we might rework this even more and command line > has to be supported indefinitely. > for the moment all virtio-x-pci devices extend virtio-pci. So why not abstracting virtio-pci ? Then there is only one way to add a virtio-x-pci device.