Re: [Qemu-devel] [PATCH] virtio-net: count VIRTIO_NET_F_MAC when calculating config_len

[Michael S. Tsirkin]

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.

> 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.

> Cornelia any idea?
> 
> >
> >>Note that there is in virtio_net_get_features:
> >>
> >>                              features |= (1 << VIRTIO_NET_F_MAC);
> >>
> >>Which is exacty the issue the initial patch is solving.
> >>
> >>Fred
> >Yes. the lifetime of host features is as follows:
> >
> >- configured in device by user, mostly set to "on" by default
> >- depending on device specific logic,
> >   override some features - mostly to "off",
> >   but we also force some required features to "on"
> >- Two exceptions (notify on empty+bad) are transport
> >   specific. they are also not user-controllable.
> >
> >