[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH v6 0/6] Virtio refactoring.
From: |
Michael S. Tsirkin |
Subject: |
Re: [Qemu-devel] [RFC PATCH v6 0/6] Virtio refactoring. |
Date: |
Mon, 7 Jan 2013 23:37:29 +0200 |
On Mon, Jan 07, 2013 at 03:24:14PM -0600, Anthony Liguori wrote:
> "Michael S. Tsirkin" <address@hidden> writes:
>
> > On Mon, Jan 07, 2013 at 02:12:23PM -0600, Anthony Liguori wrote:
> >> "Michael S. Tsirkin" <address@hidden> 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 <address@hidden> 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. 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
I guess you are saying we want to add bus= option to -net nic?
> >
> >> >
> >> > --
> >> > MST
- Re: [Qemu-devel] [RFC PATCH v6 0/6] Virtio refactoring., Michael S. Tsirkin, 2013/01/07
- Re: [Qemu-devel] [RFC PATCH v6 0/6] Virtio refactoring., Anthony Liguori, 2013/01/07
- Re: [Qemu-devel] [RFC PATCH v6 0/6] Virtio refactoring., Michael S. Tsirkin, 2013/01/07
- Re: [Qemu-devel] [RFC PATCH v6 0/6] Virtio refactoring., Anthony Liguori, 2013/01/07
- Re: [Qemu-devel] [RFC PATCH v6 0/6] Virtio refactoring.,
Michael S. Tsirkin <=
- Re: [Qemu-devel] [RFC PATCH v6 0/6] Virtio refactoring., Anthony Liguori, 2013/01/07
- Re: [Qemu-devel] [RFC PATCH v6 0/6] Virtio refactoring., Michael S. Tsirkin, 2013/01/07
- Re: [Qemu-devel] [RFC PATCH v6 0/6] Virtio refactoring., Anthony Liguori, 2013/01/07
- Re: [Qemu-devel] [RFC PATCH v6 0/6] Virtio refactoring., Michael S. Tsirkin, 2013/01/08
- Re: [Qemu-devel] [RFC PATCH v6 0/6] Virtio refactoring., Michael S. Tsirkin, 2013/01/07