Hi Daniel, On 10/28/24 18:04, Daniel P. Berrangé wrote: > On Mon, Oct 28, 2024 at 04:48:18PM +0000, Peter Maydell wrote: >> 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.) > Ah, right, yes. Sorry I mis-understood you originally to be suggesting > the same low level names as this patch. If my understanding is correct, Peter suggested to rely on the terminology used in
https://developer.arm.com/documentation/109697/2024_09 the doc pointed to by Oliver. So I think the next step is to understand how those "high level" features do map onto low level ID register field values. I think a high level feature can map onto separate fields in separate ID regs. This may not be the most common case though. Thanks Eric > > With regards, > Daniel
