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. > 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...) AFAICT, in x86 world, there's no generally documented dependancies between features. I imagine there might be deps mentioned in an adhoc basis in docs/specs. There are certainly implicit deps though where apps check for X, and blindly assume it means Y+Z also exist. In the QEMU & libvirt world though, there's no deps. This is generally why we discourage apps/users from trying to enable arbitrarily many features. People should stick to the named CPU models, and just use feature enablement as an exception. Enabling individual features *is* certainly a critically important benefit though, even with the risks from implicit undocumented dependencies. Most notably, it has been used to turn on fixes for hardware CVEs, where microcode introduces a new named feature. Your named CPU model may not be updated, but as long as QEMU knows the feature name, you can turn it on. Overall, while it would be desirable to have a way to express feature dependencies, I wouldn't call that a blocker for enabling the ability to turn features on & off. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
