From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:35643) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsKBK-0002Ma-MP for qemu-devel@nongnu.org; Mon, 07 Jan 2013 16:24:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TsKBJ-0001Kr-Fk for qemu-devel@nongnu.org; Mon, 07 Jan 2013 16:24:30 -0500 Received: from e33.co.us.ibm.com ([32.97.110.151]:43544) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsKBJ-0001Km-91 for qemu-devel@nongnu.org; Mon, 07 Jan 2013 16:24:29 -0500 Received: from /spool/local by e33.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 7 Jan 2013 14:24:28 -0700 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 4BD8019D803E for ; Mon, 7 Jan 2013 14:24:25 -0700 (MST) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r07LOOaU261252 for ; Mon, 7 Jan 2013 14:24:24 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r07LOMXv021191 for ; Mon, 7 Jan 2013 14:24:24 -0700 From: Anthony Liguori In-Reply-To: <20130107205950.GD10575@redhat.com> References: <1354887155-32281-1-git-send-email-fred.konrad@greensocs.com> <20121217154508.GA28712@redhat.com> <20121218110153.GC22586@redhat.com> <50D053CC.9040203@greensocs.com> <20121218132152.GB26110@redhat.com> <87vcb8g3bs.fsf@codemonkey.ws> <20130107205950.GD10575@redhat.com> Date: Mon, 07 Jan 2013 15:24:14 -0600 Message-ID: <878v841ybl.fsf@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 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 , e.voevodin@samsung.com, mark.burton@greensocs.com, qemu-devel@nongnu.org, stefanha@redhat.com, cornelia.huck@de.ibm.com, afaerber@suse.de, KONRAD =?utf-8?B?RnLDqWTDqXJpYw==?= "Michael S. Tsirkin" writes: > On Mon, Jan 07, 2013 at 02:12:23PM -0600, Anthony Liguori wrote: >> "Michael S. Tsirkin" writes: >>=20 >> > On Tue, Dec 18, 2012 at 12:30:20PM +0100, KONRAD Fr=C3=A9d=C3=A9ric wr= ote: >> >> 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 wrot= e: >> >> >>>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 bus= ). >> >> >> >> >> >>-- 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 to >> >> >user - if true this is not reasonable. >> >> > >> >> The modifications will be transparent to the user, as we will keep >> >> virtio-x-pci devices. >> > >> > So there are three ways to add virtio pci devices now. >> > Legacy -device virtio-net-pci, legacy legacy -net nic.model=3Dvirtio >> > and the new one with two devices. >> > If yes it's not transparent, it's user visible. >> > Or did I misunderstand? >> > >> > Look we can have a virtio network device on a PCI bus. >> > A very similar device can be created on XXX bus, and >> > we can and do share a lot of code. >> > This makes it two devices? Why not 4? >> > One for TX one for RX one for control one for PCI. >> > I hope I'm not giving anyone ideas ... >>=20 >> Devices !=3D things users need to worry about. >>=20 >> The documented way to create network devices is completely different >> than any possible syntax you can conjure up with -device. >>=20 >> Really, -device is not something users should have to deal with--ever. >> It's a low level API, not a UI. >>=20 >> Regards, >>=20 >> Anthony Liguori > > Interesting. > Let's assume I want to put a device behind a pci bridge > (for example I want more than 32 of these). You don't want to put a device behind a PCI bridge, you want to have more than 32 devices. '-net nic' should do the Right Thing when presented with more than 32 devices. > It's impossible without -device, isn't it? Think of -device like an API and -net as our UI. Management tools want to use an API, because it provides low level control and generally has limited side effects. Users want a UI that makes sense. Trying to make both things satisfy both audiences will almost certainly fail. If a common use case cannot be done without resorting to using our API, then we ought to improve our UI. Regards, Anthony Liguori > >> > >> > --=20 >> > MST