Re: [Qemu-devel] QOM: stability expectations of introspectable class_init data

[Anthony Liguori]

Eduardo Habkost <address@hidden> writes:

> Hi,
>
> This is an attempt to summarize my main question from the thread:
>   Re: [Qemu-devel] [RFC v5] target-i386: Slim conversion to X86CPU subclasses 
> + KVM subclasses
>
> My main unanswered question is about the "stability" expectations of the
> introspectable class data (especially property defaults).
>
> I am assuming and expecting that the introspectable QOM class data
> (especially property defaults) should simply reflect
> capabilities/behavior of the QEMU binary being queried, and would not
> change depending on the environment QEMU is running (host hardware and
> host kernel). This way, other components can use class introspection to
> probe for QEMU capabilities/behavior, and safely expect that the QEMU
> binary being queried will always have those capabilities/behavior.
>
> What Igor is proposing is to break my assumption, and make the default
> value of the "vendor" property on the X86CPU subclasses be different
> depending on the host CPU where QEMU is running.
>
> My question is: is that really OK?

The rules are:

1) We can add and remove types but we can never change the semantics of
   the type.  If the 'serial' device is an ISA UART16650A, it must stay
   that.

2) We can add and remove properties but never change their semantics.
   Removing properties should be done in a limited fashion of course.

3) Whenever using a '-M' parameter, a given command line syntax must
   produce an identical system from the guest's point of view on a newer
   QEMU version when all other things are equal.

So generally speaking, we can, and do, change default values but we also
have to add compat properties to make sure of (3).

CPU vendor is a special case.  It's not reasonable to expose a general
vendor string when using KVM.  Hence the 'all other things are equal'
clause.

> In another case, we are considering making other properties of a X86CPU
> subclass have different defaults depending on the capabilities of the
> host kernel (the "host" CPU class will have different feature property
> defaults depending on the capabilities reported by GET_SUPPORTED_CPUID).
> Would that be OK, too?

Given 'all other things are equal', yes, it would be.

FWIW, I agree with the suggestion elsewhere in the thread that instead
of changing default values, an "auto detect" value is a more user
friendly way of having this behavior.

Regards,

Anthony Liguori

>
> -- 
> Eduardo