Message-ID: <BANLkTimuicK-7Og8V+W1Oz6MqL3sa13H4A@mail.gmail.com>
Date:	Fri, 8 Apr 2011 13:32:24 +0400
From:	Cyrill Gorcunov <gorcunov@...il.com>
To:	Jan Kiszka <jan.kiszka@...mens.com>
Cc:	Pekka Enberg <penberg@...nel.org>,
	Anthony Liguori <anthony@...emonkey.ws>,
	Ingo Molnar <mingo@...e.hu>, Avi Kivity <avi@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"aarcange@...hat.com" <aarcange@...hat.com>,
	"mtosatti@...hat.com" <mtosatti@...hat.com>,
	"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"joro@...tes.org" <joro@...tes.org>,
	"asias.hejun@...il.com" <asias.hejun@...il.com>
Subject: Re: [ANNOUNCE] Native Linux KVM tool

On Fri, Apr 8, 2011 at 1:11 PM, Jan Kiszka <jan.kiszka@...mens.com> wrote:
> On 2011-04-08 10:27, Pekka Enberg wrote:
>> Hi Jan,
>>
>> On Fri, 2011-04-08 at 09:39 +0200, Jan Kiszka wrote:
>>> I agree that it's easy to change 2kSomething LOC for this. But if you
>>> now wait too long designing in essential features like SMP, a scalable
>>> execution model, and - very important - portability (*), it can get
>>> fairly painful to fix such architectural deficits later on. How long did
>>> it take for Linux to overcome the BKL? QEMU is in the same unfortunate
>>> position.
>>
>> Yup, and we're taking your feedback seriously (and are thankful for
>> it!). We're hoping to look at SMP in the near future - help is
>> appreciated!
>
> Honestly, I do not yet see a major advantage for us to invest here
> instead of / in addition to continuing to improve QEMU. We've spend
> quite some effort on the latter with IMO noteworthy results. Porting
> over qemu-kvm to upstream was and still is among those efforts. We (*)
> are "almost done". :)
>
> Just one example: Despite QEMU's current deficits, I just have add a
> handful of (ad-hoc) patches to turn it into a (soft) real-time
> hypervisor, and that also for certain non-Linux guests. Your approach is
> yet man years of development and stabilization effort away from getting
> close to such a level.
>
> Don't want to discourage you or other contributors. I wish you that this
> approach can gather the critical mass and momentum to make it a real
> alternative, at least for a subset of use cases. We will surely keep an
> eye on it and re-assess its pros&cons as it progresses.
>
> Jan
>
> (*) the QEMU & KVM community
>
> --
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux
>

It seems there is a misunderstanding. KVM-tool is quite far from been KVM
replacement (if ever). And what we're doing -- extremely tiny/small HV which
would help us to debug/test kernel code.

So I personally think of two scenarios:

1) QEMU eventually get merged upstream and kvm-tool remains small and
tiny example of
how to do /dev/kvm ioctls with some positive (I hope) results. Or
maybe kvm-tool gets dropped
since nobody needs it, this is possible too of course.

2) kvm-tool silently sit in tools/kvm while qemu remains on separated
repo. Both go own
ways. Not a pleasant scenario but still possible.

And we don't consider kvm-tool as a qemu competitor by any means. It
simply different
weight categories.

And of course we're glad to get any feedback (and positive and
especially negative).
Pointing out that SMP might be such a problem made us scratching the head ;)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists