[libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
Anthony Liguori
anthony at codemonkey.ws
Sun Mar 25 14:59:04 UTC 2012
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
More information about the libvir-list
mailing list