On Fri, Oct 25, 2024 at 12:17:37PM +0200, Eric Auger wrote: > This new cpu model takes by default the host cpu values. > However it exposes uint64 SYSREG properties for writable ID reg > fields exposed by the host kernel. Properties are named > SYSREG_<REG>_<FIELD> with REG and FIELD being those used > in linux arch/arm64/tools/sysreg. This done by matching the > writable fields retrieved from the host kernel against the > generated description of sysregs. > > An example of invocation is: > -cpu custom,SYSREG_ID_AA64ISAR0_EL1_DP=0x0 > which sets DP field of ID_AA64ISAR0_EL1 to 0.
"SYSREG_" feels kinda redundant to repeat on every single feature. Also, is this naming convention really the same one that users will see when they look at /proc/cpuinfo to view features ? It feels pretty low level to me ? Naming after the registers & fields, would be like configuring x86 CPU features by asking for "SYSREG_EAX_1_ECX_20" instead of saying "vmx" which is the human friendly name. > Signed-off-by: Eric Auger <eric.au...@redhat.com> > Signed-off-by: Cornelia Huck <coh...@redhat.com> > > --- > > At the moment, the custom model does not support legacy options > of the host cpu model. We need to understand what we do with those > latter (SVE, ...). This means that related KVM ioctl are > not called yet. It will be pretty painful to have to use different feature terminology for different CPU models. Everything in libvirt assuming feature terminology varies per-arch, not per-CPU model. 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 :|
