Hi Peter, On 11/4/24 17:30, Peter Maydell wrote: > On Mon, 4 Nov 2024 at 15:34, Eric Auger <eric.au...@redhat.com> wrote: >> Hi Kashyap, >> >> On 10/28/24 22:17, Kashyap Chamarthy 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(-) >>>> >>>> diff --git a/docs/system/arm/cpu-features.rst >>>> b/docs/system/arm/cpu-features.rst >>>> index a5fb929243..962a2c6c26 100644 >>>> --- a/docs/system/arm/cpu-features.rst >>>> +++ b/docs/system/arm/cpu-features.rst >>>> @@ -2,7 +2,10 @@ Arm CPU Features >>> [...] >>> >>>> +Using the ``host`` type means the guest is provided all the same CPU >>>> +features as the host CPU type has. And, for this reason, the ``host`` >>>> +CPU type should enable all CPU features that the host has by default. >>>> + >>>> +In case some features need to be hidden to the guest, ``custom`` model >>>> +shall be used instead. This is especially useful for migration purpose. >>>> + >>>> +The ``custom`` CPU model generally is the better choice if you want more >>>> +flexibility or stability across different machines or with different >>>> kernel >>>> +versions. >>> Does "more flexibility or stability across different machines" also >>> imply "live migration compatiblity across host CPUs"? >> yes that's the goal >>>> However, even the ``custom`` CPU model will not allow configuring >>>> +an arbitrary set of features; the ID registers must describe a subset of >>>> the >>>> +host's features, and all differences to the host's configuration must >>>> actually >>>> +be supported by the kernel to be deconfigured. >>> [...] >>> >>>> +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 >>> If possible, it would be really helpful (and user-friendly) to be able >>> to specify the CPU feature names as you see under /proc/cpuinfo, and be >>> able to turn the flags on or off: >>> >>> -M virt -cpu franken,rndr=on,ts=on,fhm=off >>> >>> (... instead of specifying long system register IDs that groups together >>> a bunch of CPU features. If I understand it correctly, the register >>> "ID_AA64ISAR0_EL1" maps to a set of visible features listed here: >>> https://docs.kernel.org/arch/arm64/cpu-feature-registers.html) >> Not all the writable ID regs are visible through the above technique. >> But indeed I think we converged on the idea to use higher level feature >> names than ID reg field values. >> However we need to study the feasibility and mappings between those high >> level features and ID reg field values. >> The cons is that we need to describe this mapping manually. Besides >> being cumbersome this is also error prone. > You might be interested in "Arm Architecture Features" on > https://developer.arm.com/Architectures/A-Profile%20Architecture#Downloads > which includes a 1.8MB Features.json which is a machine > readable version of the "what are the features and their > dependencies and ID registers and so on" information. thank you for the link. > > But note that (a) it is alpha quality and (b) I am not personally > going to try to interpret what might be reasonable to do with it > based on the legal notice attached to it: that's a matter for > you and your lawyer ;-)
Thank you for the notice. This may be similar to the ARM xml mentioned by Marc... Eric > > -- PMM >
