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: <4BA719E3.6070002@redhat.com>
Date:	Mon, 22 Mar 2010 09:18:59 +0200
From:	Avi Kivity <avi@...hat.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Pekka Enberg <penberg@...helsinki.fi>,
	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

On 03/22/2010 12:00 AM, Ingo Molnar wrote:
> * Avi Kivity<avi@...hat.com>  wrote:
>
>    
>>> Consider the _other_ examples that are a lot more clear:
>>>
>>>     ' If you expose paravirt spilocks via KVM please also make sure the KVM
>>>       tooling can make use of it, has an option for it to configure it, and
>>>       that it has sufficient efficiency statistics displayed in the tool for
>>>       admins to monitor.'
>>>
>>>     ' If you create this new paravirt driver then please also make sure it can
>>>       be configured in the tooling. '
>>>
>>>     ' Please also add a testcase for this bug to tools/kvm/testcases/ so we dont
>>>       repeat this same mistake in the future. '
>>>        
>> All three happen quite commonly in qemu/kvm development.  Of course someone
>> who develops a feature also develops a patch that exposes it in qemu.  There
>> are several test cases in qemu-kvm.git/kvm/user/test.
>>      
> If that is the theory then it has failed to trickle through in practice. As
> you know i have reported a long list of usability problems with hardly a look.
> That list could be created by pretty much anyone spending a few minutes of
> getting a first impression with qemu-kvm.
>    

It does happen in practice, just not in the GUI areas, since no one is 
working on them.  I am not going to condition a qcow2 reliability fix to 
a gtk GUI.

> So something is seriously wrong in KVM land, to pretty much anyone trying it
> for the first time. I have explained how i see the root cause of that, while
> you seem to suggest that there's nothing wrong to begin with. I guess we'll
> have to agree to disagree on that.
>    

Not anyone trying it for the first time.  RHEV-M users will see a 
polished GUI that can be used to manage thousands of guests and hosts.  
I presume IBM and Siemens (and all other contributors) users will also 
enjoy a good user experience with their respective products.  Qemu is 
not the only GUI for kvm.

So far only one company was interested in a qemu GUI - the makers of 
virtualbox.  Unfortunately they chose not to contribute that back to 
qemu, and no one was sufficiently motivated to pick out the bits and try 
to merge them.

Again, if you are interested in a qemu GUI, you either have to write it 
yourself or convince someone else to do it.  My own plate is full and my 
priorities are clear.

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

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