[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v3 0/6] Support for new CPU model SapphireRapids
From: |
Robert Hoo |
Subject: |
Re: [PATCH v3 0/6] Support for new CPU model SapphireRapids |
Date: |
Thu, 02 Mar 2023 22:49:29 +0800 |
On Thu, 2023-02-02 at 12:05 +0100, Igor Mammedov wrote:
> MultiBitFeatureInfo looks like an interesting
> idea
Yeah, we can feel how much effort Lei spent on this.
> but among fixing whatever issues this has atm,
> you'd probably need to introduce a new qdev_bitfield property
> infrastructure so that such features could be treated like any
> other qdev properties.
> Also when MultiBitFeatureInfo is added, one should convert all
> other usecases where it's applicable (not only for new code)
> so that we would end up with consolidated approach instead of
> zoo mess.
>
> I'm not sure all MultiBitFeatureInfo complexity is necessary
Kinda ack.
> just for adding a new CPU model, I'd rather use ad hoc approach
> that we were using before for non boolean features.
>
> And then try to develop MultiBitFeatureInfo & co as a separate
> series to demonstrate how much it will improve current
> cpu models definitions.
>
CPUID word isn't always bit wise, i.e. each bit representing a feature,
this isn't new.
e.g.
CPUID.1H.EBX[bit23,16] -- Maximum number of addressable IDs for logical
processors in this physical package
CPUID.04H
etc.
And interestingly, we can see that among so many CPUID leaves (which in
turn contain *words* of EAX, EBX, ECX, EDX), only a few has a
corresponding feature word defined in
typedef enum FeatureWord {
FEAT_1_EDX,
FEAT_1_ECX,
...
}
Why?
Those CPUID returns are not *feature words(names)*, they're numbers to
decode, strings to interpreted, etc. So does this CPUID.1DH/1EH, I
think.
Why cannot handle them like handling CPUID.04H?
- Re: [PATCH v3 0/6] Support for new CPU model SapphireRapids,
Robert Hoo <=