9:36 a.m.
On 03/25/2012 08:34 AM, Avi Kivity wrote:
On 03/25/2012 03:22 PM, Anthony Liguori wrote:
>>>> In that case
>>>>
>>>> qemu -cpu westmere
>>>>
>>>> is shorthand for -readconfig /usr/share/qemu/cpus/westmere.cfg.
>>>
>>>
>>> This is not a bad suggestion, although it would make -cpu ? a bit
>>> awkward. Do you see an advantage to this over having
>>> /usr/share/qemu/target-x86_64-cpus.cfg that's read early on?
>>
>> Nope. As long as qemu -nodefconfig -cpu westmere works, I'm happy.
>
>
> Why? What's wrong with:
>
> qemu -nodefconfig -readconfig
> /usr/share/qemu/cpus/target-x86_64-cpus.cfg \
> -cpu westmere
>
> And if that's not okay, would:
>
> qemu -nodefconfig -nocpudefconfig -cpu Westmere
>
> Not working be a problem?
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.
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(a)/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.
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(a)/target-x86_64-cpus.cfg
# Load default machines
readconfig = @DATADIR(a)/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.
>> 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.
> -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.
Regards,
Anthony Liguori