From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38589) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YsBRv-0000kQ-Ac for qemu-devel@nongnu.org; Tue, 12 May 2015 10:46:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YsBRs-0005Km-1t for qemu-devel@nongnu.org; Tue, 12 May 2015 10:46:23 -0400 Received: from e06smtp15.uk.ibm.com ([195.75.94.111]:51342) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YsBRr-0005Kc-QB for qemu-devel@nongnu.org; Tue, 12 May 2015 10:46:20 -0400 Received: from /spool/local by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 12 May 2015 15:46:17 +0100 Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id D14E5219005C for ; Tue, 12 May 2015 15:45:55 +0100 (BST) Received: from d06av06.portsmouth.uk.ibm.com (d06av06.portsmouth.uk.ibm.com [9.149.37.217]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t4CEkEBt23068856 for ; Tue, 12 May 2015 14:46:14 GMT Received: from d06av06.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av06.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t4C9eBh9017137 for ; Tue, 12 May 2015 05:40:11 -0400 Date: Tue, 12 May 2015 16:46:11 +0200 From: Cornelia Huck Message-ID: <20150512164611.46d3e70a.cornelia.huck@de.ibm.com> In-Reply-To: <20150512154446.50c68fc4.cornelia.huck@de.ibm.com> References: <20150506120729.8607.23404.stgit@bahia.huguette.org> <20150506120737.8607.30158.stgit@bahia.huguette.org> <20150512151453.42880d6c.cornelia.huck@de.ibm.com> <20150512153150-mutt-send-email-mst@redhat.com> <20150512154446.50c68fc4.cornelia.huck@de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH RFC 1/7] virtio: relax feature check List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Jason Wang , virtualization@lists.linux-foundation.org, Stefan Hajnoczi , "Michael S. Tsirkin" On Tue, 12 May 2015 15:44:46 +0200 Cornelia Huck wrote: > On Tue, 12 May 2015 15:34:47 +0200 > "Michael S. Tsirkin" wrote: > > > On Tue, May 12, 2015 at 03:14:53PM +0200, Cornelia Huck wrote: > > > On Wed, 06 May 2015 14:07:37 +0200 > > > Greg Kurz wrote: > > > > > > > Unlike with add and clear, there is no valid reason to abort when checking > > > > for a feature. It makes more sense to return false (i.e. the feature bit > > > > isn't set). This is exactly what __virtio_has_feature() does if fbit >= 32. > > > > > > > > This allows to introduce code that is aware about new 64-bit features like > > > > VIRTIO_F_VERSION_1, even if they are still not implemented. > > > > > > > > Signed-off-by: Greg Kurz > > > > --- > > > > include/hw/virtio/virtio.h | 1 - > > > > 1 file changed, 1 deletion(-) > > > > > > > > diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h > > > > index d95f8b6..6ef70f1 100644 > > > > --- a/include/hw/virtio/virtio.h > > > > +++ b/include/hw/virtio/virtio.h > > > > @@ -233,7 +233,6 @@ static inline void virtio_clear_feature(uint32_t *features, unsigned int fbit) > > > > > > > > static inline bool __virtio_has_feature(uint32_t features, unsigned int fbit) > > > > { > > > > - assert(fbit < 32); > > > > return !!(features & (1 << fbit)); > > > > } > > > > > > > > > > > > > > > > > > I must say I'm not very comfortable with knowingly passing out-of-rage > > > values to this function. > > > > > > Can we perhaps apply at least the feature-bit-size extending patches > > > prior to your patchset, if the remainder of the virtio-1 patchset still > > > takes some time? > > > > So the feature-bit-size extending patches currently don't support > > migration correctly, that's why they are not merged. > > > > What I think we need to do for this is move host_features out > > from transports into core virtio device. > > > > Then we can simply check host features >31 and skip > > migrating low guest features is none set. > > > > Thoughts? Any takers? > > > > After we move host_features, put them into an optional vmstate > subsection? > > I think with the recent patchsets, most of the interesting stuff is > already not handled by the transport anymore. There's only > VIRTIO_F_NOTIFY_ON_EMPTY and VIRTIO_F_BAD_FEATURE left (set by pci and > ccw). Thinking a bit more, we probably don't need this move of host_features to get migration right (although it might be a nice cleanup later). Could we - keep migration of bits 0..31 as-is - add a vmstate subsection for bits 32..63 only included if one of those bits is set - have a post handler that performs a validation of the full set of bits 0..63 ? We could do a similar exercise with a subsection containing the addresses for avail and used with a post handler overwriting any addresses set by the old style migration code. Does that make sense?