qemu-devel
[Top][All Lists]
Advanced

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]