> The worry I have here is that it becomes a maintenance concern having to > update the list of leaves with sub-leaves whenever a new CPUID leaf with > sub-leaves is introduced.
Intel SDM or AMD equivalent "SDM" should not change a CPUID leaf in a way that it does not consume ECX today but consume it tomorrow. This is a non-backward compatible instruction change. With that, it's easy to maintain a list of CPUID leaf that does not have sub-leaf today, or a list of ones that have sub-leaf. It's a feature to help on debuggability, similar to today's StrLen() implementation in BaseLib that avoids reading the memory to no-end. > > > > > Another concern I have if AsmCpuid() zeros ECX is callers would call > AsmCpuid(leaf) instead of AsmCpuidEx (leaf, 0). > > This would cause the caller code a mess. > > I think it's just a mindset that I have from kernel programming. In Linux, > the AsmCpuid() equivalent will explicitly zero the ECX register so that > you get the zero sub-leaf if that leaf has sub-leaves. > > Using AsmCpuid() where ECX is non-zero and possibly random, could make > debugging harder. By zeroing ECX, you will get repeatable return values to > help with debugging when things aren't going right. I agree with your concern. How about having both? I mean not only zeroing out ECX but also rejecting the CPUID leaves which have sub-leaf. It's a lib API. I still don't want AsmCpuid to own the responsibility to call sub-leaf 0. So, in debug build, AsmCpuid() asserts on some calls. In release build, we get fixed behavior. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#114122): https://edk2.groups.io/g/devel/message/114122 Mute This Topic: https://groups.io/mt/102432782/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
