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

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

Date:	Thu, 18 Mar 2010 18:16:38 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Avi Kivity <avi@...hat.com>
Cc:	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


* Avi Kivity <avi@...hat.com> wrote:

> On 03/18/2010 04:09 PM, Ingo Molnar wrote:
> >* Avi Kivity<avi@...hat.com>  wrote:
> >
> >>> That is not what i said. I said they are closely related, and where 
> >>> technologies are closely related, project proximity turns into project 
> >>> unification at a certain stage.
> >>
> >> I really don't see how.  So what if both qemu and kvm implement an i8254? 
> >> They can't share any code since the internal APIs are so different. [...]
> >
> > I wouldnt jump to assumptions there. perf shares some facilities with the 
> > kernel on the source code level - they can be built both in the kernel and 
> > in user-space.
> >
> > But my main thought wasnt even to actually share the implementation - but 
> > to actually synchronize when a piece of device emulation moves into the 
> > kernel. It is arguably bad for performance in most cases when Qemu handles 
> > a given device - so all the common devices should be kernel accelerated.
> >
> > The version and testing matrix would be simplified significantly as well: 
> > as kernel and qemu goes hand in hand, they are always on the same version.
> 
> So, you propose to allow running tools/kvm/ only on the kernel it was 
> shipped with?

No, but i propose concentrating on that natural combination.

> Otherwise the testing matrix isn't simplified.

It is, because testing is more focused and more people are testing the 
combination that developers tested as well. (and not some random version 
combination picked by the distributor or the user)

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