From: Rusty Russell <rusty@rustcorp.com.au>
To: Sasha Levin <levinsasha928@gmail.com>, Pekka Enberg <penberg@kernel.org>
Cc: mingo@elte.hu, gorcunov@gmail.com, asias.hejun@gmail.com,
kvm@vger.kernel.org
Subject: Re: [PATCH] kvm tools: Ninja out support for VIRTIO_F_FEATURES_HIGH
Date: Wed, 07 Dec 2011 11:01:28 +1030 [thread overview]
Message-ID: <87d3c1jk7z.fsf@rustcorp.com.au> (raw)
In-Reply-To: <1323165440.3882.25.camel@lappy>
On Tue, 06 Dec 2011 11:57:20 +0200, Sasha Levin <levinsasha928@gmail.com> wrote:
> On Tue, 2011-12-06 at 11:47 +0200, Pekka Enberg wrote:
> > On Tue, Dec 6, 2011 at 10:45 AM, Sasha Levin <levinsasha928@gmail.com> wrote:
> > > Rusty has just removed it out of the spec. Since we probably the only ones
> > > who implemented support for it, we should remove it out of our code as well.
> > >
> > > There is no issue with breaking anything since nothing else worked with it,
> > > so it's fully backwards compatible.
> > >
> > > Cc: Rusty Russell <rusty@rustcorp.com.au>
> > > Signed-off-by: Sasha Levin <levinsasha928@gmail.com>
> >
> > Applied, thanks!
> >
> > How is this going to work going forward? Should I ask Rusty for an ACK
> > before merging code that implements some (new) part of the virtio
> > spec? I like the fact that we're bleeding edge but it's pointless for
> > everyone involved if we implement something that's known to be
> > half-baked in the spec.
>
> There was a little cheating involved here since the spec basically broke
> backwards compatibility by removing 64 bit features, so it's a special
> case and probably won't happen (too many times) again.
>
> Half baked features usually don't go into the spec as well, Rusty
> usually insists on having a working code besides just spec updates, so
> again - this was one of those rare special cases.
>
> If Rusty or Michael could ACK our virtio patches it would be awesome.
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
TLDR version: I shouldn't have put it in the spec until we needed it.
The spec revert broke no guests, because no guest ever implemented high
feature bits (both because it wasn't in the draft spec long, and no
device defined > 32 features yet, so no guest needed to).
It also broke no hosts, since it was up to the host to offer the high
feature bits. No host did, since no device needed those high bits.
kvmtool guys are just enthusiasts, so they put in the infrastructure,
but didn't use it.
If I'm wrong, then when we use bit 31 for something else, a new guest
may break. It may happen, but we're going to 64 bits in a different
manner, so we can avoid using bit 31 for a long time.
It's very unusual for me to un-spec things, but in this very limited
case it fairly safe.
Cheers,
Rusty.
prev parent reply other threads:[~2011-12-07 1:09 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-06 8:45 [PATCH] kvm tools: Ninja out support for VIRTIO_F_FEATURES_HIGH Sasha Levin
2011-12-06 9:47 ` Pekka Enberg
2011-12-06 9:57 ` Sasha Levin
2011-12-07 0:31 ` Rusty Russell [this message]
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=87d3c1jk7z.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=asias.hejun@gmail.com \
--cc=gorcunov@gmail.com \
--cc=kvm@vger.kernel.org \
--cc=levinsasha928@gmail.com \
--cc=mingo@elte.hu \
--cc=penberg@kernel.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).