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?