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

[Anthony Liguori <anthony@codemonkey.ws>]

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

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

Because -nodefconfig means "don't load *any* default configuration files".

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

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

What's the problem with this?

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

I'm not sure which part you're responding to..

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

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.

Regards,

Anthony Liguori