On Mon, Jan 07, 2013 at 03:24:14PM -0600, Anthony Liguori wrote: > "Michael S. Tsirkin" <m...@redhat.com> writes: > > > On Mon, Jan 07, 2013 at 02:12:23PM -0600, Anthony Liguori wrote: > >> "Michael S. Tsirkin" <m...@redhat.com> writes: > >> > >> > On Tue, Dec 18, 2012 at 12:30:20PM +0100, KONRAD Frédéric 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 <m...@redhat.com> wrote: > >> >> >>>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=virtio > >> > 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 ... > >> > >> Devices != things users need to worry about. > >> > >> The documented way to create network devices is completely different > >> than any possible syntax you can conjure up with -device. > >> > >> Really, -device is not something users should have to deal with--ever. > >> It's a low level API, not a UI. > >> > >> Regards, > >> > >> 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.
Wait a second, -net implies vlans no? And this means no offloads so performance suffers ... > 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 > > > > >> > > >> > -- > >> > MST
