Re: [PATCH v3 1/2] Introduce (x86) CPU model deprecation API

[Robert Hoo <robert.hu@linux.intel.com>]

On Mon, 2020-09-21 at 11:37 -0400, Eduardo Habkost wrote:
> > 
...
> > Yes. Trying as less refactor as possible. I think my changes even
> > cannot be called refactor at all. :)
> > My idea is to make unversioned CPU model virtual. I did some patch,
> > doable:
> > 1) in x86_register_cpudef_types(), don't register cpu_model type
> > for
> > the unversioned 'Model'.
> > 2) in x86_cpu_class_by_name(), check passed-in cpu_model param
> > versioned or not, if the virtual unversioned 'Model', parse it to
> > some
> > concrete version by global default_cpu_version designation.
> > 
> > So, user can still use '-cpu Model' as before, no interface
> > changes.
> > And no nature changes:
> > 1) in current code, even legacy 'Model', you have created a v1
> > model
> > for it. i.e., every virtual 'Model' already has at least one
> > concrete
> > versioned one.
> > 2) in current code, x86_cpu_model_resolve_version() is called when
> > x86_cpu_load_model(). x86_cpu_model_resolve_version() actually does
> > kind of work that concreting unversioned Model to its versioned
> > one, by
> > global default_cpu_version designation. Same as my aforementioned
> > above.
> > 
> > Would you like me to integrate this implementation in v4? to have a
> > look.
> 
> I think we might give this a try, but I wouldn't like to have
> your model deprecation series delayed because of this.  Some
> obstacles I expect to see:
> 
> Right now the code assumes a 1:1 mapping between CPU model and
> QOM class.  We even have a `typename` field returned by
> query-cpu-definitions.
> 
> It would also become an obstacle for removing the existing
> arch-specific class_by_name methods and do the model->class
> mapping based solely on a string template.  See this thread for a
> glimpse on what we have been trying to do:
> https://lore.kernel.org/qemu-devel/877eb173a3.fsf@dusky.pond.sub.org/
> 
> I'm not saying we shouldn't do what you suggest, but it would add
> a lot of complexity to your CPU model deprecation work (that's
> very close to be ready to be merged).
> 
OK, I'm going to send v4 without this.
Then send this in a separate patch for discussion.
> > > > 
> > > --
> > > Eduardo
> > > 
> 
>