Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt

[Avi Kivity]

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
>>>> definition.
>>>
>>>
>>> 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
> QemuOptsList.
>
>> 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
> files".

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

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:
>>>
>>> [system]
>>> # 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:
>>>
>>> [machinedef]
>>>   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:
>>>
>>> [machine]
>>> 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