Hi Daniel, On 10/25/24 15:13, Daniel P. Berrangé wrote: > 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' ? there is no baseline at the moment. By default this is a host passthrough model. > > 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. Having named models is the next thing. custom vcpu model is not a named model. But we don't want to TCG like CPU model (like A57) because we want to be able to migrate between different machines like Ampere to NVidia or different Ampere systems. So the baseline must be something usable by both hosts. > > 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. The custom model is not yet a named model. This is rather something to start this kind of discussion. The code used by the custom vcpu model allows fine tuning of the ID reg fields. This code could be reused by named models. We can also imagine that libvirt does implement the named models, ie. hardcodes some IDReg fields and thus implement the named model instead. Libvirt could identify what is the baseline source and dest are the closest to, choose this baseline and tune few reg id fields if some additional tuning are needed.
Thanks Eric > > With regards, > Daniel
