On Mon, Oct 28 2024, Oliver Upton <oliver.up...@linux.dev> 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. > > +1 > > There's existing documentation [*] for the standard feature names, which > provides: > > - A short description of what the feature does > - Any dependencies a particular feature has (e.g.FEAT_VHE implies > FEAT_LSE, FEAT_Debugv8p1, and FEAT_AA64EL2) > - The register fields/values that are used to discover the feature. > > This seems like the most user-friendly option... > > [*]: https://developer.arm.com/documentation/109697/2024_09
FEAT_XXX sounds good, would be a different approach than this series obviously, since the user resp. upper software layers would operate on a per-feature basis, and QEMU would translate to and from registers. I'm wondering about the amount of translation that would be needed, and what information would be best exposed via QEMU, given that a feature may or may not be toggable not only because of what the Arm revision specifies, but what registers the host kernel allows to be written. I.e. if we have two cpus that differ in whether FEAT_FOO is provided, would it make sense to have an extra QMP command so that you can find out whether FEAT_FOO can be switched off, with QEMU translating from the set of writable id registers to the set of features that can be changed?
