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

[Eduardo Habkost]

On Tue, Sep 15, 2020 at 10:56:06AM +0800, Robert Hoo wrote:
> On Mon, 2020-09-14 at 13:38 +0000, Eduardo Habkost wrote:
> > On Mon, Sep 14, 2020 at 06:50:09PM +0800, Robert Hoo wrote:
[...]
> > > 2) Each x86 cpudef CPU model has 1 unversioned cpu_model_type then
> > > its
> > > versioned cpu_model_types. Refer to code in
> > > x86_register_cpudef_types(). The unversioned model won't be marked
> > > deprecated as it is unkown when registered. In
> > > machine_run_board_init(), the cpu_model being checked is the
> > > unversioned one, if I set -cpu to its general unversioned model.
> > > In short, the unversioned cpudef CPU model would escape the
> > > deprecation
> > > check.
> > 
> > Why is that a problem?  If, for example, Model-v1 is deprecated
> > and Model-v2 is not deprecated, we must never tell the user that
> > "-cpu Model" is deprecated.  
> 
> Yes, that's why I cannot mark the unversioned one deprecated or not in
> its init.
> 
> > Even if some machine types resolve
> > "-cpu Model" to Model-v1.
> > 
> That's what I concerned. Say, if I named "-cpu Icelake-Client" and it's
> resolved to Icelake-CPU-v1 (deprecated), shouldn't we warn user?

For Icelake-Client, we want to make all versions of
Icelake-Client deprecated, so "Icelake-Client" can and should be
marked as deprecated at class_init time.

I don't think we need to support a use case where "Model" is not
deprecated bu "Model-v1" is.

-- 
Eduardo