Re: [Qemu-devel] QEMU CPU model versioning/compatibility (was Re: KVM call minutes July 31th)

[Avi Kivity <avi@redhat.com>]

On 07/31/2012 06:14 PM, Eduardo Habkost wrote:
> On Tue, Jul 31, 2012 at 04:32:05PM +0200, Juan Quintela wrote:
>> - 1.2 plans for CPU model versioning/compatibility (eduardo)
>>   (global properties vs QOM vs qdev)
>>   how to do it ?  configuration file?  moving back to the code?
>>   different external interface from internal one
> 
> (CCing libvir-list)
> 
> So, the problem is (please correct me if I am wrong):
> 
> - libvirt expects the CPU models from the current config file to be
>   provided by QEMU. libvirt won't write a cpudef config file.
> - Fixing compatibility problems on the CPU models (even the ones that
>   are in config files) are expected to be QEMU's responsibility.
> 
> Moving the CPU models inside the code is a step backwards, IMO. I don't
> think loading some kind of data from an external file (provided and
> maintained by QEMU itself) should be considered something special and
> magic, and make the data there a second-class citizen (that QEMU refuses
> to give proper support and keep compatibility).

I agree.

> But if it will make us stop running in circles every time something
> related to those files needs to be changed (remember the -no-user-config
> discussion?), I think I will accept that.

The issue is that we have a lot of machinery for backwards compatibility
in the code, and none in cpu definitions parser.  Yes we could mark up
the cpu definitions so it could be text driven, but that's effort that
could be spent elsewhere.  Moving it to a data-driven C implementation
that can rely on the existing backwards compat code is a good tradeoff IMO.

-- 
error compiling committee.c: too many arguments to function