Re: [PATCH 6/7] target/i386: Add new CPU model EmeraldRapids

[Igor Mammedov]

On Tue, 27 Jun 2023 13:54:23 +0800
Xiaoyao Li <xiaoyao.li@intel.com> wrote:

> On 6/26/2023 8:56 PM, Igor Mammedov wrote:
> > On Fri, 16 Jun 2023 11:23:10 +0800
> > Tao Su<tao1.su@linux.intel.com>  wrote:
> >   
> >> From: Qian Wen<qian.wen@intel.com>
> >>
> >> Emerald Rapids (EMR) is the next generation of Xeon server processor
> >> after Sapphire Rapids (SPR).
> >>
> >> Currently, regarding the feature set that can be exposed to guest, there
> >> isn't any one new comparing with SPR cpu model, except that EMR has a
> >> different model number.
> >>
> >> Though it's practicable to define EMR as an alias of a new version of
> >> SPR by only updating the model number and model name, it loses the
> >> flexibility when new version of EMR cpu model are needed for adding new
> >> features (that hasn't virtalized/supported by KVM yet).  
> > Which begs a question, why do we need EMR model (or alias) at all
> > if it's the same as SPR at the moment.
> > 
> > Make new features supported 1st and only then introduce a new CPU model.
> >   
> 
> Even if no new feature (that can be virtualized and exposed to guest) in 
> EMR compared to SPR in the end, I think it still makes sense to provide 
> a dedicated EMR CPU model in QEMU. Because
> 1) User will know EMR, Intel's next generation of Xeon after SRP, is 
> supported by QEMU, via -cpu ?/ -cpu help;

I don't see any benefits in misleading user by showing EMR model which is
nothing else but SPR one.
On negative side you would increase maintenance burden by introducing
extra versions of CPU model later. Which by itself is abusing versioning,
mainly used for fixing CPU bugs, by using it for adding new features.

> 2) It's convenient for user to create an EMR VM. People may not care 
> that much what the difference between "-cpu SapphireRapids" with "-cpu 
> EmeraldRapids", while they do want to create an VM which shows the CPU 
> is EmeraldRapids.
>
My guess would be is that you need guest to show EMR for developing EMR
features/guest bringup, in that case do it in your fork, and once
support is actually ready publish completed patches for it.

To exaggerate you reasoning further, we should create CPU models for
all future planned Intel/AMD CPU as a one of currently existing in
QEMU right now and then sometime in future implement features that
actually make those models what they should be.

It's downright confusing for user, so I'd object to this approach.