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

[Avi Kivity]

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.

Again, defining = #define
Configuring = modifying current instance

>
>> target-x86_64-cpus.cfg does not configure qemu for anything, it's merely
>> the equivalent of
>>
>>    #define westmere (x86_def_t) { ... }
>>    #define nehalem (x86_def_t) { ... }
>>    #define bulldozer (x86_def_t) { ... } // for PC
>>
>> so it should be read at each invocation.  On the other hand, pc.cfg and
>> westmere.cfg (as used previously) are shorthand for
>>
>>     machine = (QEMUMachine) { ... };
>>     cpu = (x86_def_t) { ... };
>>
>> so they should only be read if requested explicitly (or indirectly).
>
> This doesn't make a lot of sense to me.  Here's what I'm proposing:
>
> 1) QEMU would have a target-x86_64-cpu.cfg.in that is installed by
> default in /etc/qemu.  It would contain:
>
> [system]
> # Load default CPU definitions
> readconfig = @DATADIR@/target-x86_64-cpus.cfg
>
> 2) target-x86_64-cpus.cfg would be installed to @DATADIR@ and would
> contain:
>
> [cpudef]
>   name = "Westmere"
>   ...
>
> This has the following properties:
>
> A) QEMU has no builtin notion of CPU definitions.  It just has a "cpu
> factory".  -cpudef will create a new class called Westmere that can
> then be enumerated through qom-type-list and created via qom-create.
>
> 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?

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.

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

Otherwise, the meaning of -nodefconfig changes as more stuff is moved
out of .c and into .cfg.

>
>>>> The reasoning is, loading target-x86_64-cpus.cfg does not alter the
>>>> current instance's configuration, so reading it doesn't violate
>>>> -nodefconfig.
>>>
>>> I think we have a different view of what -nodefconfig does.
>>>
>>> We have a couple options today:
>>>
>>> -nodefconfig
>>>
>>> Don't read the default configuration files.  By default, we read
>>> /etc/qemu/qemu.cfg and /etc/qemu/target-$(ARCH).cfg
>>>
>>
>> The latter seems meaningless to avoid reading.  It's just a set of
>> #defines, what do you get by not reading it?
>
> 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.

>
>>> -nodefaults
>>>
>>> Don't create default devices.
>>>
>>> -vga none
>>>
>>> Don't create the default VGA device (not covered by -nodefaults).
>>>
>>> With these two options, the semantics you get an absolutely
>>> minimalistic instance of QEMU.  Tools like libguestfs really want to
>>> create the simplest guest and do the least amount of processing so the
>>> guest runs as fast as possible.
>>>
>>> It does suck a lot that this isn't a single option.  I would much
>>> prefer -nodefaults to be implied by -nodefconfig.  Likewise, I would
>>> prefer that -nodefaults implied -vga none.
>>
>> I don't have a qemu.cfg so can't comment on it, but in what way does
>> reading target-x86_64.cfg affect the current instance (that is, why is
>> -nodefconfig needed over -nodefaults -vga look-at-the-previous-option?)
>
> It depends on what the user configures it to do.

How?

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.

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