Re: [Qemu-devel] [libvirt] Modern CPU models cannot be used with libvirt

[Avi Kivity]

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