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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list