From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53594) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UX6SI-0006O0-LE for qemu-devel@nongnu.org; Tue, 30 Apr 2013 05:02:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UX6SF-00069u-AV for qemu-devel@nongnu.org; Tue, 30 Apr 2013 05:02:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57290) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UX6SF-00069O-2p for qemu-devel@nongnu.org; Tue, 30 Apr 2013 05:02:31 -0400 Date: Tue, 30 Apr 2013 12:02:12 +0300 From: "Michael S. Tsirkin" Message-ID: <20130430090212.GA28253@redhat.com> References: <20130429163055.GA11268@redhat.com> <517EA2A4.2030205@greensocs.com> <20130429170118.GA11497@redhat.com> <517EACA5.3090307@greensocs.com> <20130429175217.GA18172@redhat.com> <517EB590.9090700@greensocs.com> <20130429181533.GA18390@redhat.com> <517EBFDE.5090200@greensocs.com> <20130429200952.GA19286@redhat.com> <517F8526.9070509@greensocs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <517F8526.9070509@greensocs.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] virtio-net: count VIRTIO_NET_F_MAC when calculating config_len List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: KONRAD =?iso-8859-1?Q?Fr=E9d=E9ric?= Cc: agraf@suse.de, aliguori@us.ibm.com, Michael Roth , Jason Wang , qemu-devel@nongnu.org, Jesse Larrew , cornelia.huck@de.ibm.com On Tue, Apr 30, 2013 at 10:47:34AM +0200, KONRAD Fr=E9d=E9ric 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? >=20 > 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 a= n > array of host_features? In practice the array is of size 1. I'd suggest just assuming that for no= w. 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? >=20 > > > >>Note that there is in virtio_net_get_features: > >> > >> features |=3D (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. > > > >