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. 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 ;-) -- PMM
