[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] virtio: set virtio-net/virtio-mmio host feature
From: |
Mario Smarduch |
Subject: |
Re: [Qemu-devel] [PATCH] virtio: set virtio-net/virtio-mmio host features |
Date: |
Thu, 20 Feb 2014 13:59:59 -0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 |
On 02/20/2014 11:35 AM, Peter Maydell wrote:
> On 20 February 2014 19:09, Mario Smarduch <address@hidden> wrote:
>> host features since you don't know what virtio device will be plugged
>> in later.
>
> I think this function is the right place to set these properties,
> yes. What I'm saying is that I don't see why you're doing it
> this way rather than using the existing per-backend hook.
> Maybe there's a reason not to use that hook, but you don't say.
>
Appears virtio-net beckend hooks are common to several transports,
and would require virtio-mmio exception to set the host_features.
If I'm missing something please recommend.
>> It's virtio_net_properties[] can only set virtio-net
>> properites when it's instantiated. I think the proper way would
>> be to refactor virtio-mmio to similar structure PCI version uses then
>> one virtio_net_properties[] can be used selecting PCI or virtio-mmio at
>> compile time. But right now it's unclear to me how pci and virtio-mmio
>> versions intend to co-exist.
>
> This is the result of a refactoring last year to allow virtio-mmio.
> Basically the underlying structure now is:
>
> [some virtio transport device] <- virtio bus -> [virtio backend]
>
> where the transport could be mmio, PCI, CCW, etc, and the
> backend is net, blk, balloon, etc. We also provide devices
> which are "virtio PCI transport plus a specific backend"
> for (a) user convenience and (b) backwards compatibility, since
> the pre-refactoring structure put the transport and backend
> all in one lump. The all-in-one-lump arrangement is legacy:
> we shouldn't break it, but it's not the model for virtio-mmio
> to follow either.
>
> The transport shouldn't know anything specific about the
> backend it's plugged into (or vice-versa), but it's fine
> for there to be hook functions so the transport and backend
> can call each other at the appropriate times.
>
> thanks
> -- PMM
>
- [Qemu-devel] [PATCH] virtio: set virtio-net/virtio-mmio host features, Mario Smarduch, 2014/02/13
- Re: [Qemu-devel] [PATCH] virtio: set virtio-net/virtio-mmio host features, Peter Maydell, 2014/02/14
- Re: [Qemu-devel] [PATCH] virtio: set virtio-net/virtio-mmio host features, Mario Smarduch, 2014/02/20
- Re: [Qemu-devel] [PATCH] virtio: set virtio-net/virtio-mmio host features, Peter Maydell, 2014/02/20
- Re: [Qemu-devel] [PATCH] virtio: set virtio-net/virtio-mmio host features, Mario Smarduch, 2014/02/20
- Re: [Qemu-devel] [PATCH] virtio: set virtio-net/virtio-mmio host features, Peter Maydell, 2014/02/20
- Re: [Qemu-devel] [PATCH] virtio: set virtio-net/virtio-mmio host features,
Mario Smarduch <=
- Re: [Qemu-devel] [PATCH] virtio: set virtio-net/virtio-mmio host features, Peter Maydell, 2014/02/20
- Re: [Qemu-devel] [PATCH] virtio: set virtio-net/virtio-mmio host features, Mario Smarduch, 2014/02/20
- Re: [Qemu-devel] [PATCH] virtio: set virtio-net/virtio-mmio host features, Peter Maydell, 2014/02/20
- Re: [Qemu-devel] [PATCH] virtio: set virtio-net/virtio-mmio host features, Mario Smarduch, 2014/02/20