All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	"open list:virtio-blk" <qemu-block@nongnu.org>,
	qemu-devel@nongnu.org, Amit Shah <amit.shah@redhat.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Cornelia Huck <cornelia.huck@de.ibm.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v2] virtio: make features 64bit wide
Date: Mon, 1 Jun 2015 09:29:55 +0200	[thread overview]
Message-ID: <20150601092825-mutt-send-email-mst@redhat.com> (raw)
In-Reply-To: <1433143408.19671.17.camel@nilsson.home.kraxel.org>

On Mon, Jun 01, 2015 at 09:23:28AM +0200, Gerd Hoffmann wrote:
> On Fr, 2015-05-29 at 16:53 +0200, Michael S. Tsirkin wrote:
> > On Fri, May 29, 2015 at 09:51:20AM +0200, Gerd Hoffmann wrote:
> > > Make features 64bit wide everywhere.  Exception: command line flags
> > > remain 32bit and are copyed into the lower 32 host_features at
> > > initialization time.
> > > 
> > > On migration a full 64bit guest_features field is sent if one of the
> > > high bits is set, additionally to the lower 32bit guest_features field
> > > which must stay for compatibility reasons.  That way we send the lower
> > > 32 feature bits twice, but that way the code is simpler because we don't
> > > have to split and compose the 64bit features into two 32bit fields.
> > > 
> > > This depends on "move host_features" patch by cornelia.
> > > 
> > > Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> > 
> > 
> > Thanks, this is very close to what I had in mind.
> > Question: why do we need the feature_flags field?
> > What's wrong with setting bits in host_features directly?
> 
> DEFINE_PROP_BIT works on uint32_t.
> 
> Alternative approach would be to introduce a DEFINE_PROP_BIT64 and use
> that for DEFINE_VIRTIO_COMMON_FEATURES.
> 
> cheers,
>   Gerd
> 


Yes - previous versions of this patch did exactly that.
Can you do DEFINE_PROP_BIT64 please?
We'll need DEFINE_PROP_BIT64 down the road anyway when
we add properties > 32.

If you prefer, I'm fine with this being a patch on top.

Let me know.


-- 
MST

  reply	other threads:[~2015-06-01  7:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-29  7:51 [Qemu-devel] [PATCH v2] virtio: make features 64bit wide Gerd Hoffmann
2015-05-29 14:53 ` Michael S. Tsirkin
2015-06-01  7:23   ` Gerd Hoffmann
2015-06-01  7:29     ` Michael S. Tsirkin [this message]
2015-05-29 16:46 ` [Qemu-devel] [Qemu-block] " Eric Blake

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=20150601092825-mutt-send-email-mst@redhat.com \
    --to=mst@redhat.com \
    --cc=amit.shah@redhat.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=kraxel@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.