linux-kernel - Re: [RFC] Unify KVM kernel-space and user-space code into a single project

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]

Message-ID: <4BA215CC.5090801@suse.de>
Date:	Thu, 18 Mar 2010 13:00:12 +0100
From:	Alexander Graf <agraf@...e.de>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Avi Kivity <avi@...hat.com>,
	Anthony Liguori <anthony@...emonkey.ws>,
	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Sheng Yang <sheng@...ux.intel.com>,
	linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
	Marcelo Tosatti <mtosatti@...hat.com>,
	oerg Roedel <joro@...tes.org>,
	Jes Sorensen <Jes.Sorensen@...hat.com>,
	Gleb Natapov <gleb@...hat.com>,
	Zachary Amsden <zamsden@...hat.com>, ziteng.huang@...el.com,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Fr?d?ric Weisbecker <fweisbec@...il.com>
Subject: Re: [RFC] Unify KVM kernel-space and user-space code into a single
 project

Ingo Molnar wrote:
> * Avi Kivity <avi@...hat.com> wrote:
>
>   
>>> Still it's _very_ useful to have a single reference implementation under 
>>> tools/perf/ where we concentrate the best of the code. That is where we 
>>> make sure that each new kernel feature is appropriately implemented in 
>>> user-space as well, that the combination works well together and is 
>>> releasable to users. That is what keeps us all honest: the latency of 
>>> features is much lower, and there's no ping-pong of blame going on between 
>>> the two components in case of bugs or in case of misfeatures.
>>>       
>> That would make sense for a truly minimal userspace for kvm: we once had a 
>> tool called kvmctl which was used to run tests (since folded into qemu).  It 
>> didn't contain a GUI and was unable to run a general purpose guest.  It was 
>> a few hundred lines of code, and indeed patches to kvmctl had a much closer 
>> correspondence to patches with kvm (though still low, as most kvm patches 
>> don't modify the ABI).
>>     
>
> If it's functional to the extent of at least allowing say a serial console via 
> the console (like the UML binary allows) i'd expect the minimal user-space to 
> quickly grow out of this minimal state. The rest will be history.
>
> Maybe this is a better, simpler (and much cleaner and less controversial) 
> approach than moving a 'full' copy of qemu there.
>
> There's certainly no risk: if qemu stays dominant then nothing is lost 
> [tools/kvm/ can be removed after some time], and if this clean base works out 
> fine then the useful qemu technologies will move over to it gradually and 
> without much fuss, and the developers will move with it as well.
>
> If it's just a token effort with near zero utility to begin with it certainly 
> wont take off.
>
> Once it's there in tools/kvm/ and bootable i'd certainly hack up some quick 
> xlib based VGA output capability myself - it's not that hard ;-) It would also 
> allow me to test whether latest-KVM still boots fine in a much simpler way. 
> (most of my testboxes dont have qemu installed)
>
> So you have one user signed up for that already ;-)
>   

Alright, you just volunteered. Just give it a go and try to implement
the "oh so simple" KVM frontend while maintaining compatibility with at
least a few older Linux guests. My guess is that you'll realize it's a
dead end before committing anything to the kernel source tree. But
really, just try it out.


Good Luck

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/