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

[Eduardo Habkost]

On Fri, Feb 15, 2013 at 02:35:26PM +0100, Igor Mammedov wrote:
> On Fri, 15 Feb 2013 10:50:16 -0200
> Eduardo Habkost <address@hidden> wrote:
> 
> > 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.
> i.e. reflecting actual value of CPUID.vendor of the host.
> 
> alternative proposed by Eduardo:
>  is to abstract default value of "vendor" property to "host" string.
> 

Exactly. Just to be clear: the actual CPUID vendor exposed to the guest
_will_ change depending on the host CPU because we need to keep the
behavior compatible with previous QEMU versions (that already do that).
My question is about how to model that behavior in QOM.

> 
> > 
> > My question is: is that really OK?
> > 
> > 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?
> > 
> 

-- 
Eduardo