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). Currently QEMU only has to care about cpuinfo name tags in linux-user/elfload.c where there's a bunch of data structures for "what hwcaps do we need to advertise given what the CPU has?". I would definitely prefer it if we could use architectural feature names... On other architectures do we do anything to forbid invalid combinations? For Arm there are architectural rules about feature X requiring features Y and Z. Are we going to just let the user create a CPU that the guest OS will barf on if they want to? (The user-experience for that is potentially not very nice, because something like "-cpu cortex-a57,+sve" seems like something you might want to do but isn't actually valid; even listing the direct required dependency of FEAT_SVE like "-cpu cortex-a57,+sve,+fp16" isn't sufficient because SVE is optional-from-v8.2 and so a guest could in theory assume the presence of anything mandatory in v8.1 and v8.2. But even merely diagnosing invalid combinations is a huge pain, and automagically pulling in every mandatory implicit or explicit dependency seems like it might be surprising to users, as well as being annoying to implement. Currently we sidestep all of these problems by (a) only allowing the command line to disable a feature, not to enable it where it didn't previously exist and (b) mostly not providing command line flags for individual features...) thanks -- PMM
