[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
- From: Avi Kivity <avi redhat com>
- To: Anthony Liguori <anthony codemonkey ws>
- Cc: libvir-list redhat com, Jiri Denemark <jdenemar redhat com>, Eduardo Habkost <ehabkost redhat com>, qemu-devel nongnu org
- Subject: Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
- Date: Sun, 25 Mar 2012 17:16:23 +0200
On 03/25/2012 04:59 PM, Anthony Liguori wrote:
> On 03/25/2012 09:46 AM, Avi Kivity wrote:
>> On 03/25/2012 04:36 PM, Anthony Liguori wrote:
>>>> Apart from the command line length, it confuses configuration with
>>> There is no distinction with what we have today. Our configuration
>>> file basically corresponds to command line options and as there is no
>>> distinction in command line options, there's no distinction in the
>>> configuration format.
>> We don't have command line options for defining, only configuring.
> That's an oversight. There should be a -cpudef option. It's a
>> Again, defining = #define
> I think -global fits your definition of #define...
Yes (apart from the corner case of modifying a default-instantiated device).
>>> B) A management tool has complete control over cpu definitions without
>>> modifying the underlying filesystem. -nodefconfig will prevent it
>>> from loading and the management tool can explicitly load the QEMU
>>> definition (via -readconfig, potentially using a /dev/fd/N path) or it
>>> can define it's own cpu definitions.
>> Why does -nodefconfig affect anything?
> Because -nodefconfig means "don't load *any* default configuration
Put the emphasis around *configuration*.
"#define westmere blah" is not configuration, otherwise the meaning of
configuration will drift over time.
-cpu blah is, of course.
>> The file defines westmere as an alias for a grab bag of options.
>> Whether it's loaded or not is immaterial, unless someone uses one of the
>> names within.
> But you would agree, a management tool should be able to control
> whether class factories get loaded, right?
No, why? But perhaps I don't entirely get what you mean by "class
Aren't they just implementations of
virtual Device *new_instance(...) = 0?
if so, why not load them?
> So what's the mechanism to do this?
>>> C) This model maps to any other type of class factory. Machines will
>>> eventually be expressed as a class factory. When we implement this,
>>> we would change the default target-x86_64-cpu.cfg to:
>>> # Load default CPU definitions
>>> readconfig = @DATADIR@/target-x86_64-cpus.cfg
>>> # Load default machines
>>> readconfig = @DATADIR@/target-x86_64-machines.cfg
>>> A machine definition would look like:
>>> name = pc-0.15
>>> virtio-blk.class_code = 32
>>> Loading a file based on -cpu doesn't generalize well unless we try to
>>> load a definition for any possible QOM type to find the class factory
>>> for it. I don't think this is a good idea.
>> Why not load all class factories? Just don't instantiate any objects.
> Unless we have two different config syntaxes, I think it will lead to
> a lot of confusion. Having some parts of a config file be parsed and
> others not is fairly strange.
Parse all of them (and make sure all are class factories).
The only real configuration item is that without -nodefconfig, we create
a -M pc-1.1 system. Everything else derives from that.
>> Otherwise, the meaning of -nodefconfig changes as more stuff is moved
>> out of .c and into .cfg.
> What's the problem with this?
The command line becomes unstable if you use -nodefconfig.
>>> In my target-$(ARCH).cfg, I have:
>>> enable-kvm = "on"
>>> Which means I don't have to use -enable-kvm anymore. But if you look
>>> at a tool like libguestfs, start up time is the most important thing
>>> so avoiding unnecessary I/O and processing is critical.
>> So this is definitely configuration (applies to the current instance) as
>> opposed to target-x86_64.cfg, which doesn't.
> I'm not sure which part you're responding to..
I was saying that target-x86_64.cfg appears to be definitions, not
configuration, and was asking about qemu.cfg (which is configuration).
>> As far as I can tell, the only difference is that -nodefconfig -cpu
>> westmere will error out instead of working. But if you don't supply
>> -cpu westmere, the configuration is identical.
> What configuration?
> Let me ask, what do you think the semantics of -nodefconfig should
> be? I'm not sure I understand what you're advocating for.
-nodefconfig = create an empty machine, don't assume anything (=don't
read qemu.cfg) let me build it out of all those lego bricks. Those can
be defined in code or in definition files in /usr/share, I don't care.
Maybe that's -nodevices -vga none. But in this case I don't see the
point in -nodefconfig. Not loading target_x86-64.cfg doesn't buy the
user anything, since it wouldn't affect the guest in any way.
error compiling committee.c: too many arguments to function
[Date Prev][Date Next] [Thread Prev][Thread Next]