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

[Eduardo Habkost]

On Fri, Feb 15, 2013 at 08:22:31AM -0600, Anthony Liguori wrote:
> 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).

OK, thanks for the explanation.

> 
> 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.

True, CPU vendor is special. And the tricky part is the "all other
things are equal" clause.

e.g.: we try to keep all guest-visible features the same when using -M
even if the host CPU or the host kernel changes. So the host kernel and
the host CPU aren't included in the "all other things are equal" clause,
but the host CPU vendor is.

In other words: we don't support cross-CPU-vendor migration out of the
box (and if somebody wants to try to make it work, it will require an
explicit CPu vendor to be always set on the command-line).


> 
> > 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.

-cpu "host" is known and expected to _really_ stretch the "all other
things are equal" part of rule (3). Other CPU models are kept compatible
even if the host CPU or host kernel changes (as long as the host CPU has
the same vendor). "host" keeps rule (3) if and only if the host kernel
CPUID capabilities and the host CPU are exactly the same.

I would go further and simply declare -cpu "host" as not following rule
(3) at all, instead of trying to define the specific conditions where it
would follow it.


> 
> 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.

Are you talking about the suggestion of having vendor default to "host",
and having instance_init translate vendor="host" to the host CPU vendor?

My main argument for it was the possibility of not being allowed to
change the defaults based on host CPU. But if we are allowed to change
the default, do we still want to use the vendor="host" solution? (My
opinion is now divided, but I am inclined towards it).

-- 
Eduardo