From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36539) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XuIBa-0007SY-Tg for qemu-devel@nongnu.org; Fri, 28 Nov 2014 04:50:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XuIBR-0003U8-N6 for qemu-devel@nongnu.org; Fri, 28 Nov 2014 04:49:58 -0500 Received: from e06smtp10.uk.ibm.com ([195.75.94.106]:35305) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XuIBR-0003Tm-Ea for qemu-devel@nongnu.org; Fri, 28 Nov 2014 04:49:49 -0500 Received: from /spool/local by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 28 Nov 2014 09:49:47 -0000 Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id E415E1B0804B for ; Fri, 28 Nov 2014 09:48:00 +0000 (GMT) Received: from d06av08.portsmouth.uk.ibm.com (d06av08.portsmouth.uk.ibm.com [9.149.37.249]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id sAS9ljNV9764886 for ; Fri, 28 Nov 2014 09:47:45 GMT Received: from d06av08.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av08.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id sAS9liLU012029 for ; Fri, 28 Nov 2014 02:47:44 -0700 Date: Fri, 28 Nov 2014 10:47:42 +0100 From: Cornelia Huck Message-ID: <20141128104742.0ac9a9ab.cornelia.huck@de.ibm.com> In-Reply-To: <20141127163540.GC27124@redhat.com> References: <1417101409-29482-1-git-send-email-cornelia.huck@de.ibm.com> <20141127152422.GA26747@redhat.com> <20141127163139.7db48144.cornelia.huck@de.ibm.com> <20141127154211.GC26747@redhat.com> <20141127170651.67f918e2.cornelia.huck@de.ibm.com> <20141127161825.GA27124@redhat.com> <20141127172842.42782626.cornelia.huck@de.ibm.com> <20141127163540.GC27124@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH RFC v4 00/16] qemu: towards virtio-1 host support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: thuth@linux.vnet.ibm.com, rusty@rustcorp.com.au, qemu-devel@nongnu.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org On Thu, 27 Nov 2014 18:35:40 +0200 "Michael S. Tsirkin" wrote: > On Thu, Nov 27, 2014 at 05:28:42PM +0100, Cornelia Huck wrote: > > On Thu, 27 Nov 2014 18:18:25 +0200 > > "Michael S. Tsirkin" wrote: > > > > > On Thu, Nov 27, 2014 at 05:06:51PM +0100, Cornelia Huck wrote: > > > > > > So we should have a per-device callback into the transport layer, say > > > > check_legacy()? > > > > > > I would just have 2 masks: legacy_features and features. > > > > But these belong to the device type and the transport just needs to > > trigger usage of the right one, right? > > Yes. > > > > > > > > For ccw, this would check for the negotiated revision; for mmio, it > > > > could check a device property configured with the device; and for pci, > > > > whatever the mechanism is there :) > > > > > > > > A transport not implementing this callback is simply considered > > > > legacy-only. > > > > > > I dislike callbacks. Let's just give all info to core, > > > and have it DTRT. > > > > > Have a is_legacy flag in the vdev that is initialized to 1, and > > transports can unset it when the revision is negotiated or during init? > > I would say have modern_features, legacy_features, and set host_features > correctly. > Started digging through the code a bit: Currently the only time where the transport is actually mucking with the feature bits is when the device is plugged, when it adds its feature bits and calls virtio_bus_get_vdev_features() to get the device specific bits. Only mmio knows at this point in time whether it has a v1.0 or a legacy device. Other transports will need to call this function again when the guest has actually set the revision. My plan is the following: - have virtio_bus_get_vdev_features_rev() that takes a virtio-rev parameter (0: legacy, 1: v1.0) - unconverted transports keep calling virtio_bus_get_vdev_features() which calls virtio_bus_get_vdev_features_rev(..., 0) - the rev parameter gets passed to the device, which hands over the right feature set (I don't think that we can use static feature tables, as the device may need to calulate the desired feature set dynamically) Sounds reasonable?