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:	Tue, 23 Mar 2010 09:09:14 -0500
From:	Anthony Liguori <anthony@...emonkey.ws>
To:	Avi Kivity <avi@...hat.com>
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 04:07 AM, Avi Kivity wrote:
> 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.

The approach I've taken (which I accidentally committed and reverted) 
was to set this up as the default qmp device much like we have a default 
monitor device.  A user is capable of overriding this by manually 
specifying a qmp device or by disabling defaults.

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

I've looked at making default devices globally configurable.  We'll get 
there but I think that's orthogonal to setting up a useful default qmp 
device.

Regards,

Anthony Liguori

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