linux-kernel - Re: [ANNOUNCE] Native Linux KVM tool

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 08 Apr 2011 12:42:40 +0200
From:	Jan Kiszka <jan.kiszka@...mens.com>
To:	Cyrill Gorcunov <gorcunov@...il.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 2011-04-08 11:32, Cyrill Gorcunov wrote:
> 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.

I think your core team may have this vision, but my impression is that
some people here think much further.

Also note that even for guest debugging some fairly essential features
are missing yet. The gdbstub is among them and the most prominent one.

> 
> 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.

For me the separate tree thing is not that important as long as KVM
developers continue to hack on both sides (which most of us do).

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

Long-term, IMHO, kvm-tool either has to cover at least one use case qemu
is not interested in or it has to be noticeably better in one domain.
Just being a small demo that has to be maintained _in_addition_ to qemu
/wrt KVM ABI changes will make it suffer quickly. Right now x86 has
reached a rather calm period in this regard, but PPC e.g. is about to
enter the same stormy times we had with x86 in the past years. We've
been through duplicate userland maintenance phase with qemu-kvm vs.
upstream qemu for far too long, and it was a real pain (it still is, but
the last duplicate bits should disappear before qemu-0.15).

> 
> 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 ;)

One big advantage of qemu is that it can nicely reproduce tricky
concurrency issues (not all but many) as it provides true SMP support.
We've successfully used this several times for debugging weird kernel
and driver issues in the past 4 years.

So I personally have no use case for kvm-tool that qemu(-kvm) wouldn't
already solve, generally in a more advance way. That may explain my
skepticism. :)

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
--
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/