On Mon, Oct 28 2024, Daniel P. Berrangé <berra...@redhat.com> wrote:
> On Mon, Oct 28, 2024 at 05:05:44PM +0100, Cornelia Huck wrote: >> On Fri, Oct 25 2024, Daniel P. Berrangé <berra...@redhat.com> wrote: >> >> > On Fri, Oct 25, 2024 at 03:28:35PM +0200, Eric Auger wrote: >> >> 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. >> > >> > Why do we need to create "custom" at all, as opposed to just letting >> > users toggle features on "-cpu host" ? >> >> We could consolidate that to the current "host" model, once we figure >> out how to handle the currently already existing properties. Models >> based on the different architecture extensions would probably be more >> useable in the long run; maybe "custom" has a place for testing. > > If you can set the features against "host", then any testing could > be done with "host" surely, making 'custom' pointless ? We might differentiate between "do some consistency checks" and "allow a completely weird wolpertinger"; if we agree that we don't need it, then we surely could drop it again.
