Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
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