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. 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).
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?
-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?)
files be read by default or just treated as additional configuration files.
If they're read as soon as they're referenced, what's the difference? I think the thread has reduced to: should /usr/share configuration
I suspect libvirt would not be happy with reading configuration files on demand..
Why not?
It implies a bunch of SELinux labeling to make sVirt work. libvirt tries very hard to avoid having QEMU read *any* files at all when it starts up.
The /usr/share/qemu files should be statically labelled to allow qemu to read them, so we can push more code into data files. -- error compiling committee.c: too many arguments to function