All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Huang Ying <ying.huang@intel.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	Andi Kleen <andi@firstfloor.org>
Subject: Re: [PATCH -v2] Add MCE support to KVM
Date: Tue, 21 Apr 2009 23:45:01 +0300	[thread overview]
Message-ID: <49EE304D.5060108@redhat.com> (raw)
In-Reply-To: <49EE27C2.3060505@codemonkey.ws>

Anthony Liguori wrote:
> Avi Kivity wrote:
>> No argument.  But some kernel features will require major rework in 
>> qemu before we can support them properly.  We'll still want to bring 
>> them to users quickly so users can enjoy them (and we can enjoy users 
>> testing them).  Waiting for a qemu rework may take a while, and we'll 
>> lose valuable feedback.
>
> Then we're failing.  If a particular implementation of a feature is 
> acceptable for kvm-userspace users, and we don't take it in QEMU 
> without requiring a huge amount of different work, then it suggests 
> something is broken about the QEMU process.
>

Example: SMP.
Example: vlan API.

>> For this kind of work, we can provide kvm-userspace.git as a kind of 
>> playground where these experiments may be made.  kvm-userspace.git 
>> exists to support kvm.git; while qemu.git has a life of its own and 
>> more stringent barriers to acceptance.
>
> As long as people are using kvm-userspace.git instead of qemu.git, 
> we're failing IMHO.  If kvm-userspace.git is basically the equivalent 
> of the x86 git kernel tree, linux-next, or something like that, then 
> that's a good thing.

That's definitely a long term goal, but qemu is not yet at a point where 
it is easy to implement new features efficiently.  Once it reaches that 
state, kvm-userspace will become a simple staging ground (or even 
disappear entirely).

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


  reply	other threads:[~2009-04-21 20:45 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-17  7:29 [PATCH -v2] Add MCE support to KVM Huang Ying
2009-04-18 15:54 ` Anthony Liguori
2009-04-19  8:39   ` Avi Kivity
2009-04-21 16:06     ` Anthony Liguori
2009-04-21 16:19       ` Avi Kivity
2009-04-21 16:12     ` Anthony Liguori
2009-04-21 16:21       ` Avi Kivity
2009-04-21 19:55         ` Anthony Liguori
2009-04-21 20:00           ` Avi Kivity
2009-04-21 20:08             ` Anthony Liguori
2009-04-21 20:45               ` Avi Kivity [this message]
2009-04-21 21:16                 ` Anthony Liguori
2009-04-22  5:57                   ` Avi Kivity
2009-04-22 13:32                     ` Anthony Liguori
2009-04-22 13:58                       ` Avi Kivity
2009-04-22  2:32         ` Huang Ying
2009-04-20  1:19   ` Huang Ying
2009-04-20  3:57     ` Kyle Moffett
2009-04-20  5:04       ` Huang Ying
2009-04-20  5:30       ` Andi Kleen
2009-04-22  2:42       ` Gregory Haskins

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=49EE304D.5060108@redhat.com \
    --to=avi@redhat.com \
    --cc=andi@firstfloor.org \
    --cc=anthony@codemonkey.ws \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ying.huang@intel.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.