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
