From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:58833) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsJjw-0004aM-0N for qemu-devel@nongnu.org; Mon, 07 Jan 2013 15:56:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TsJjt-0002hu-DR for qemu-devel@nongnu.org; Mon, 07 Jan 2013 15:56:11 -0500 Received: from mx1.redhat.com ([209.132.183.28]:26253) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TsJjt-0002hn-6B for qemu-devel@nongnu.org; Mon, 07 Jan 2013 15:56:09 -0500 Date: Mon, 7 Jan 2013 22:59:50 +0200 From: "Michael S. Tsirkin" Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <87vcb8g3bs.fsf@codemonkey.ws> 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: Anthony Liguori 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 =?iso-8859-1?Q?Fr=E9d=E9ric?= 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=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. > > > > 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). It's impossible without -device, isn't it? > > > > --=20 > > MST