On Fri, Oct 25, 2024 at 12:17:40PM +0200, Eric Auger wrote: > From: Cornelia Huck <coh...@redhat.com> > > Add some documentation for the custom model. > > Signed-off-by: Eric Auger <eric.au...@redhat.com> > Signed-off-by: Cornelia Huck <coh...@redhat.com> > --- > docs/system/arm/cpu-features.rst | 55 +++++++++++++++++++++++++++----- > 1 file changed, 47 insertions(+), 8 deletions(-)
> @@ -167,6 +196,16 @@ disabling many SVE vector lengths would be quite > verbose, the ``sve<N>`` CPU > properties have special semantics (see "SVE CPU Property Parsing > Semantics"). > > +The ``custom`` CPU model needs to be configured via individual ID register > +field properties, for example:: > + > + $ qemu-system-aarch64 -M virt -cpu custom,SYSREG_ID_AA64ISAR0_EL1_DP=0x0 > + > +This forces ID_AA64ISAR0_EL1 DP field to 0. What is the "baseline" featureset implied by 'custom' ? On x86 we have the named CPU models each setting a baseline that matches some corresponding real world silicon. Arm has that too, with TCG at least. So that way you know what the baseline is that you're toggling features against. Experiance on x86 was that making arbitrary feature changes on top of the named models could often backfire, as there are too many scenarios where code will check for feature "Y", and assume that existance of "Y" implies existance of "A", "B" and "C" too. So if you invent custom models where Y is set, but B is missing, there's decent risk of things going wrong in horrible to debug ways. With that in mind, best practice is to try to just the vanilla named CPU models to the greatest extent possible, and keep feature toggling to an absolute minimum. This 'custom' model does not seem to give us such ability for arm. 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 :|
