[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] virtio-net: count VIRTIO_NET_F_MAC when calcula
From: |
Cornelia Huck |
Subject: |
Re: [Qemu-devel] [PATCH] virtio-net: count VIRTIO_NET_F_MAC when calculating config_len |
Date: |
Thu, 2 May 2013 11:02:37 +0200 |
On Tue, 30 Apr 2013 12:02:12 +0300
"Michael S. Tsirkin" <address@hidden> wrote:
> On Tue, Apr 30, 2013 at 10:47:34AM +0200, KONRAD Frédéric wrote:
> > >>Then compute the last one directly in the init function which is the
> > >>harder:
> > >>
> > >> virtio_net_get_features
> > >The real fix is to set features in init.
> > >
> > >Can we move host_features to struct VirtIODevice, and
> > >init to the device init function?
> > >
> > >The reason we didn't do this initially is exactly
> > >because we need to specify them in -device flag,
> > >and there was no way to do this for VirtIODevice,
> > >since it's the proxy that is instanciated.
> > >Does the new bus infrastructure allow this?
> >
> > Yes, I think it's possible for PCI and S390, but it seems more
> > difficult for CCW.
>
> Can you send the patch for pci to let everyone see what
> you have in mind? The main issue is passing properties
> from proxy to the device.
Should probably not be hard to adapt to ccw.
>
> > I don't really understand how it's working with CCW devices, there is an
> > array of host_features?
>
> In practice the array is of size 1. I'd suggest just assuming that for now.
> When we extend features (which will happen pretty soon)
> we'll do this for all transports and change features to uint64_t
> everywhere.
> After that, we'll have a bit of breathing space.
Yes, the idea was to keep features easily extendable. Going 64 bit will
work fine; the transport should be able to handle even larger features.