linux-kernel - Re: [GIT PULL] Native Linux KVM tool for 3.1

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 for Android: free password hash cracker in your pocket

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

Message-Id: <68C2AB77-AA91-4B21-A321-2DB4EF8121C1@suse.de>
Date:	Mon, 25 Jul 2011 11:42:02 +0200
From:	Alexander Graf <agraf@...e.de>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Pekka Enberg <penberg@...nel.org>, Jan Kiszka <jan.kiszka@....de>,
	torvalds@...ux-foundation.org, avi@...hat.com,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	kvm@...r.kernel.org, gorcunov@...il.com, levinsasha928@...il.com,
	asias.hejun@...il.com, prasadjoshi124@...il.com
Subject: Re: [GIT PULL] Native Linux KVM tool for 3.1

On 25.07.2011, at 11:26, Ingo Molnar wrote:

> 
> * Pekka Enberg <penberg@...nel.org> wrote:
> 
>> [ I thought the 'native Linux' part in 'native Linux KVM tool' was 
>> a dead giveaway, really. ]
>> 
>> Now if people want to support other operating systems, that's cool 
>> and I'm happy to help out where I can. But I don't understand why 
>> people keep bringing non-Linux OSs as an argument for not merging 
>> tools/kvm into the Linux kernel tree. I mean really, did someone 
>> actually expect that a Linux kernel developer spends his weekends 
>> improving the state of Windows virtualization?
>> 
>> And don't get this the wrong way either, I'm not hostile against 
>> other operating systems, but I simply am not interested enough in 
>> them to spend my time improving them.
> 
> In fact one of the problems i see with Qemu is that Qemu had to make 
> many compromises to support Windows and other weird platforms that 
> i'm (and i'd claim most other Linux kernel developers) are personally 
> not interested in.

It's what makes it so powerful. Adding a new architecture for KVM for example is as easy as only implementing the CPU. All device emulation is already there. If you want something Linux only, lguest would've been enough, no?

The only real problem I see with Qemu is that it's been born in a time of uniprocessor systems. Making it fully threaded as an after-thought is insanely hard.

> So here's a 14 KLOC tools/kvm/ that does everything that i need from 
> virtualization (easy testing of a bzImage before rebooting the host 
> system into it), is clean, readable and hackable and is 1.5% of the 
> nearly 1 MLOC Qemu code base.

Sure, we'll talk again when you can run Android for ARM on kvm-tool.

> The whole tools/kvm/ code base is (much) smaller than Qemu's IA64 
> support code for example. The size difference is startling. 

That's the host code compiler. Qemu doesn't have IA64 guest support.

> tools/kvm/ does less and in my experience does it better - is that 
> such a surprising thing?

I already stated in a few mails before and also in the last discussion that I'm in general in favor of having multiple user space targets for KVM. In fact, I wrote 2 backends (both for PPC) myself. Though adding those 2 backends to their respective projects probably provided a lot more value-add (features that qemu didn't already have) than kvm-tool does atm. Kvm-tool really just smells a lot like NIH. Which is fine - that's why we have KDE and Gnome, right? ;)

> So it was a no brainer for me to pull it into -tip.

The thing I don't agree with is that it should live in the kernel tree.

Alex

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