From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57346) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkB3f-0005vc-CG for qemu-devel@nongnu.org; Mon, 20 Apr 2015 08:44:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YkB3c-0008LQ-68 for qemu-devel@nongnu.org; Mon, 20 Apr 2015 08:44:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35052) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YkB3b-0008LK-Ut for qemu-devel@nongnu.org; Mon, 20 Apr 2015 08:44:12 -0400 Date: Mon, 20 Apr 2015 14:43:59 +0200 From: "Michael S. Tsirkin" Message-ID: <20150420141523-mutt-send-email-mst@redhat.com> References: <1429272826-4145-1-git-send-email-shannon.zhao@linaro.org> <20150417154335.7fa224ce.cornelia.huck@de.ibm.com> <20150420105411.75944c6d.cornelia.huck@de.ibm.com> <20150420110736-mutt-send-email-mst@redhat.com> <20150420141430.2f35b3f9.cornelia.huck@de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150420141430.2f35b3f9.cornelia.huck@de.ibm.com> Subject: Re: [Qemu-devel] [PATCH 0/4] virtio: Move host features to backends List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cornelia Huck Cc: Peter Maydell , "Huangpeng (Peter)" , QEMU Developers , Shannon Zhao , Shannon Zhao , Paolo Bonzini , Christoffer Dall On Mon, Apr 20, 2015 at 02:14:30PM +0200, Cornelia Huck wrote: > On Mon, 20 Apr 2015 11:12:37 +0200 > "Michael S. Tsirkin" wrote: > > > On Mon, Apr 20, 2015 at 10:54:11AM +0200, Cornelia Huck wrote: > > > On Fri, 17 Apr 2015 15:00:45 +0100 > > > Peter Maydell wrote: > > > > > > > On 17 April 2015 at 14:43, Cornelia Huck wrote: > > > > > On Fri, 17 Apr 2015 20:13:42 +0800 > > > > > Shannon Zhao wrote: > > > > > > > > > > [Some questions may be silly, but I'm not familiar with the virtio-mmio > > > > > code] > > > > > > > > > >> The reason to do this is that the virtio-net-device can't expose host > > > > >> features to guest while using virtio-mmio. So the performance is low. > > > > > > > > > > So how does virtio-mmio expose any host features? > > > > > > > > The features are properties of the backend, not the transport. > > > > So for devices where we didn't set these up as "properties > > > > exist on the backend and the compatibility transport+backend > > > > wrapper devices just forward those properties to the backend", > > > > you can't set the properties. We got this right for some of > > > > the backends (eg blk) but not all of them, I think. > > > > > > The reason why blk is ok is that it adds the feature bits in its > > > ->get_features() callback. net expects the feature bits already present > > > and removes not supported ones and therefore requires > > > statically-defined bits somewhere. > > > > > > If we move the feature bits to virtio-net and virtio-scsi, it should > > > work for virtio-mmio - but the feature bit propagation from the device > > > into the transport becomes a bit useless. > > > > > > Could net and scsi add the feature bits dynamically in their > > > ->get_features() callback instead? This should work for virtio-mmio as > > > well afaics. > > > > > > In the end, we should probably end up with the same mechanism for all > > > device types. > > > > I think I would also prefer that the host features live in the > > generic virtio device structure. > > You mean in the virtio device instead of the proxy device? Yes. > I think that > makes sense conceptually, provided we get the realize/plug sequence > correct. > > > This would make it possible > > e.g. to validate guest features on vm load in generic code. > > > > Doesn't virtio_load() already do some validation? You are right here. -- MST