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]

Date:	Tue, 23 Mar 2010 11:07:48 +0200
From:	Avi Kivity <avi@...hat.com>
To:	Anthony Liguori <anthony@...emonkey.ws>
CC:	Ingo Molnar <mingo@...e.hu>, Pekka Enberg <penberg@...helsinki.fi>,
	"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>,
	Gregory Haskins <ghaskins@...ell.com>
Subject: Re: [RFC] Unify KVM kernel-space and user-space code into a single
 project

On 03/23/2010 12:06 AM, Anthony Liguori wrote:
>> Having qemu enumerate guests one way or another is not a good idea 
>> IMO since it is focused on one guest and doesn't have a system-wide 
>> entity.
>
>
> There always needs to be a system wide entity.  There are two ways to 
> enumerate instances from that system wide entity.  You can centralize 
> the creation of instances and there by maintain an list of current 
> instances.  You can also allow instances to be created in a 
> decentralized manner and provide a standard mechanism for instances to 
> register themselves with the system wide entity.
>
> IOW, it's the difference between asking libvirtd to exec(qemu) vs 
> allowing a user to exec(qemu) and having qemu connect to a well known 
> unix domain socket for libvirt to tell libvirtd that it exists.
>
> The later approach has a number of advantages.  libvirt already 
> supports both models.  The former is the '/system' uri and the later 
> is the '/session' uri.
>
> What I'm proposing, is to use the host file system as the system wide 
> entity instead of libvirtd.  libvirtd can monitor the host file system 
> to participate in these activities but ultimately, moving this 
> functionality out of libvirtd means that it becomes the standard 
> mechanism for all qemu instances regardless of how they're launched.

I don't like dropping sockets into the host filesystem, especially as 
they won't be cleaned up on abnormal exit.  I also think this breaks our 
'mechanism, not policy' policy.  Someone may want to do something weird 
with qemu that doesn't work well with this.

We could allow starting monitors from the global configuration file, so 
a distribution can do this if it wants, but I don't think we should do 
this ourselves by default.

-- 
error compiling committee.c: too many arguments to function

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