From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36765) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xu1FW-0002W4-SF for qemu-devel@nongnu.org; Thu, 27 Nov 2014 10:45:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xu1FN-0000Zj-0G for qemu-devel@nongnu.org; Thu, 27 Nov 2014 10:44:54 -0500 Received: from mx1.redhat.com ([209.132.183.28]:37067) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xu1FM-0000ZF-PS for qemu-devel@nongnu.org; Thu, 27 Nov 2014 10:44:44 -0500 Date: Thu, 27 Nov 2014 17:44:31 +0200 From: "Michael S. Tsirkin" Message-ID: <20141127154431.GD26747@redhat.com> References: <1417101409-29482-1-git-send-email-cornelia.huck@de.ibm.com> <1417101409-29482-4-git-send-email-cornelia.huck@de.ibm.com> <20141127153419.GB26747@redhat.com> <20141127164029.08953e4a.cornelia.huck@de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141127164029.08953e4a.cornelia.huck@de.ibm.com> Subject: Re: [Qemu-devel] [PATCH RFC v4 03/16] virtio: support more feature bits List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cornelia Huck 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, Nov 27, 2014 at 04:40:29PM +0100, Cornelia Huck wrote: > On Thu, 27 Nov 2014 17:34:19 +0200 > "Michael S. Tsirkin" wrote: > > > On Thu, Nov 27, 2014 at 04:16:36PM +0100, Cornelia Huck wrote: > > > With virtio-1, we support more than 32 feature bits. Let's make > > > vdev->guest_features depend on the number of supported feature bits, > > > allowing us to grow the feature bits automatically. > > ^ This was one reason why I did it this way... Then use bitmap.h But I think it's overdesign. > > > > > > We also need to enhance the internal functions dealing with getting > > > and setting features with an additional index field, so that all feature > > > bits may be accessed (in chunks of 32 bits). > > > > > > vhost and migration have been ignored for now. > > > > > > Reviewed-by: Thomas Huth > > > Signed-off-by: Cornelia Huck > > > @@ -117,7 +125,7 @@ struct VirtIODevice > > > uint8_t status; > > > uint8_t isr; > > > uint16_t queue_sel; > > > - uint32_t guest_features; > > > + uint32_t guest_features[NR_VIRTIO_FEATURE_WORDS]; > > > size_t config_len; > > > void *config; > > > uint16_t config_vector; > > > > Ugh. > > > > That's quite tricky to use correctly. > > Why don't we just make it uint64_t? > > ...and another one was that at least virtio-ccw reads/writes in chunks > of 32 bits anyway. It's quite easy to get at the high 32 bit of 64 bit integers. > > > > The only real issue is that DEFINE_PROP_BIT wants > > a uint32_t. > > > > But that's easy to fix: add DEFINE_PROP64_BIT > > that is the same but handles a 64 bit array. > > > Sure, this would not really be a problem to add. But we'll stand before > the same problem again when we want to grow past 64 bits, won't we? It will take years till we run out of bits. We'll handle it then, it's not like it's rocket science. -- MST