On Mon, 28 Oct 2024 at 16:35, Daniel P. Berrangé <berra...@redhat.com> wrote: > > On Mon, Oct 28, 2024 at 04:16:31PM +0000, Peter Maydell wrote: > > On Fri, 25 Oct 2024 at 14:24, Daniel P. Berrangé <berra...@redhat.com> > > wrote: > > > On Fri, Oct 25, 2024 at 03:18:25PM +0200, Eric Auger wrote: > > > > On 10/25/24 15:06, Daniel P. Berrangé wrote: > > > > > Also, is this naming convention really the same one that users > > > > > will see when they look at /proc/cpuinfo to view features ? It > > > > No it is not. I do agree that the custom cpu model is very low level. It > > > > is very well suited to test all series turning ID regs as writable but > > > > this would require an extra layer that adapts /proc/cpuinfo feature > > > > level to this regid/field abstraction. > > > > > > > > In /cpu/proc you will see somethink like: > > > > Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp > > > > asimdhp cpuid asimdrdm lrcpc dcpop asimddp > > > > > > Right, IMHO, this is the terminology that QEMU must use in user > > > facing APIs. > > > > /proc/cpuinfo's naming is rather weird for historical > > reasons (for instance there is only one FEAT_FP16 feature > > but cpuinfo lists "fphp" and "asimdhp" separately). > > There's plenty of wierd history in x86 too. In this > case I might suggest just picking one of the two > common names, and ignoring the other. > > If we really wanted to, we could alias the 2nd name > to the first, but its likely not worth the bother.
Or we could use the standard set of architectural feature names, and not have the problem at all, and not have to document what we mean by our nonstandard names. (cpuinfo names do actually mostly line up with the standard names, just not 100%. Similarly gcc/clang command line options are mostly the architectural feature name.) thanks -- PMM
