qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: thuth@linux.vnet.ibm.com, rusty@rustcorp.com.au,
	qemu-devel@nongnu.org, kvm@vger.kernel.org,
	virtualization@lists.linux-foundation.org
Subject: Re: [Qemu-devel] [PATCH RFC v4 03/16] virtio: support more feature bits
Date: Thu, 27 Nov 2014 17:44:31 +0200	[thread overview]
Message-ID: <20141127154431.GD26747@redhat.com> (raw)
In-Reply-To: <20141127164029.08953e4a.cornelia.huck@de.ibm.com>

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" <mst@redhat.com> 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 <thuth@linux.vnet.ibm.com>
> > > Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
> > > @@ -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

  reply	other threads:[~2014-11-27 15:45 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-27 15:16 [Qemu-devel] [PATCH RFC v4 00/16] qemu: towards virtio-1 host support Cornelia Huck
2014-11-27 15:16 ` [Qemu-devel] [PATCH RFC v4 01/16] linux-headers/virtio_config: Update with VIRTIO_F_VERSION_1 Cornelia Huck
2014-11-27 15:16 ` [Qemu-devel] [PATCH RFC v4 02/16] virtio: cull virtio_bus_set_vdev_features Cornelia Huck
2014-11-27 15:16 ` [Qemu-devel] [PATCH RFC v4 03/16] virtio: support more feature bits Cornelia Huck
2014-11-27 15:34   ` Michael S. Tsirkin
2014-11-27 15:40     ` Cornelia Huck
2014-11-27 15:44       ` Michael S. Tsirkin [this message]
2014-11-27 15:16 ` [Qemu-devel] [PATCH RFC v4 04/16] s390x/virtio-ccw: fix check for WRITE_FEAT Cornelia Huck
2014-11-27 15:16 ` [Qemu-devel] [PATCH RFC v4 05/16] virtio: introduce legacy virtio devices Cornelia Huck
2014-11-27 15:16 ` [Qemu-devel] [PATCH RFC v4 06/16] virtio: allow virtio-1 queue layout Cornelia Huck
2014-11-27 15:16 ` [Qemu-devel] [PATCH RFC v4 07/16] dataplane: allow virtio-1 devices Cornelia Huck
2014-11-27 15:16 ` [Qemu-devel] [PATCH RFC v4 08/16] s390x/css: Add a callback for when subchannel gets disabled Cornelia Huck
2014-11-27 15:16 ` [Qemu-devel] [PATCH RFC v4 09/16] s390x/virtio-ccw: add virtio set-revision call Cornelia Huck
2014-11-27 15:16 ` [Qemu-devel] [PATCH RFC v4 10/16] s390x/virtio-ccw: support virtio-1 set_vq format Cornelia Huck
2014-11-27 15:16 ` [Qemu-devel] [PATCH RFC v4 11/16] virtio: disallow late feature changes for virtio-1 Cornelia Huck
2014-11-27 15:16 ` [Qemu-devel] [PATCH RFC v4 12/16] virtio: allow to fail setting status Cornelia Huck
2014-11-27 15:16 ` [Qemu-devel] [PATCH RFC v4 13/16] s390x/virtio-ccw: enable virtio 1.0 Cornelia Huck
2014-11-27 15:16 ` [Qemu-devel] [PATCH RFC v4 14/16] virtio-net: no writeable mac for virtio-1 Cornelia Huck
2014-11-27 15:16 ` [Qemu-devel] [PATCH RFC v4 15/16] virtio-net: support longer header Cornelia Huck
2014-11-27 15:16 ` [Qemu-devel] [PATCH RFC v4 16/16] virtio-net: enable virtio 1.0 Cornelia Huck
2014-11-27 15:24 ` [Qemu-devel] [PATCH RFC v4 00/16] qemu: towards virtio-1 host support Michael S. Tsirkin
2014-11-27 15:31   ` Cornelia Huck
2014-11-27 15:42     ` Michael S. Tsirkin
2014-11-27 16:06       ` Cornelia Huck
2014-11-27 16:18         ` Michael S. Tsirkin
2014-11-27 16:28           ` Cornelia Huck
2014-11-27 16:35             ` Michael S. Tsirkin
2014-11-28  9:47               ` Cornelia Huck
2014-11-27 16:38             ` Michael S. Tsirkin
2014-11-28  9:50               ` Cornelia Huck
2015-02-25  4:20 ` [Qemu-devel] Qemu and virtio 1.0 Rusty Russell
2015-02-25 11:26   ` Cornelia Huck
2015-03-02 11:43   ` Michael S. Tsirkin
2015-03-02 12:00     ` Cornelia Huck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141127154431.GD26747@redhat.com \
    --to=mst@redhat.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    --cc=rusty@rustcorp.com.au \
    --cc=thuth@linux.vnet.ibm.com \
    --cc=virtualization@lists.linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).