On Mon, Oct 28 2024, Peter Maydell <peter.mayd...@linaro.org> 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). > 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...)
I think s390 does some dependency checking on features, and also rejects features that are "too new".
