From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A45601C8632 for ; Tue, 13 May 2025 16:23:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747153424; cv=none; b=Hpiqsjyh5+LN7jy2seh3z4hFCZJTHM2ttMCrnNzWcdFYEBU0pRPmfgUwH5kLpKuh7QiTEj7wMjLtaMYAu0G7LxcZQ+yyliP7nwzoktnCicPVDeutxMxEv+S+EyBOuRzY/djIYXWjjxkOzeART75JU/xD4XdUp0Cm2WWhrX1c2Uw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1747153424; c=relaxed/simple; bh=+yLr/HHiqxHYWRsEMQdxWzCtOF0swat7YMxrTKBB1Gw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=rsgoIki/AnA3FZu3v8OVjYnCSafWj9kLmEO2MpPvzX9jyxVhv4hxGVUaoQSJvHI4r+Q/I18VKPPaPu41OWG89wYjDeffS5/TBkpe79ACM0t1eBLDnmldqsqK+j1C6/ObMs8VS8ij1Ew6xqcWL/jTM0bhN7m8+t6GuetKEVDVvJo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=QIgvwijN; arc=none smtp.client-ip=170.10.129.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="QIgvwijN" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1747153421; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=8/O3L74GuKzo/TjHS1Hrvth01wGf5AOef3YEOHWTqhA=; b=QIgvwijNwP2KM4P0Q/9v7Kv1TNwDLG9Bsj+ISinwNH6J2+B+BG8Xd0OkJSDJEXvOSrEULZ pCmdq/xLJBR1O9q2HyiT7sF25NvR9vZ8vuRCxDpXT6cTHxmvC3Mk2qxpu3DEJvrEtz5iMX mSm43dc2uiSaHyqbd82243hNUV6jZLI= Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-325-cYDl4VDJPni-SiULaYn4YA-1; Tue, 13 May 2025 12:23:38 -0400 X-MC-Unique: cYDl4VDJPni-SiULaYn4YA-1 X-Mimecast-MFC-AGG-ID: cYDl4VDJPni-SiULaYn4YA_1747153416 Received: from mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id B08D31800875; Tue, 13 May 2025 16:23:35 +0000 (UTC) Received: from redhat.com (unknown [10.42.28.110]) by mx-prod-int-02.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 614281945CB4; Tue, 13 May 2025 16:23:30 +0000 (UTC) Date: Tue, 13 May 2025 17:23:27 +0100 From: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= To: Cornelia Huck Cc: eric.auger.pro@gmail.com, eric.auger@redhat.com, qemu-devel@nongnu.org, qemu-arm@nongnu.org, kvmarm@lists.linux.dev, peter.maydell@linaro.org, richard.henderson@linaro.org, alex.bennee@linaro.org, maz@kernel.org, oliver.upton@linux.dev, sebott@redhat.com, shameerali.kolothum.thodi@huawei.com, armbru@redhat.com, abologna@redhat.com, jdenemar@redhat.com, agraf@csgraf.de, shahuang@redhat.com, mark.rutland@arm.com, philmd@linaro.org, pbonzini@redhat.com Subject: Re: [PATCH v3 10/10] arm/cpu-features: document ID reg properties Message-ID: Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= References: <20250414163849.321857-1-cohuck@redhat.com> <20250414163849.321857-11-cohuck@redhat.com> Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20250414163849.321857-11-cohuck@redhat.com> User-Agent: Mutt/2.2.14 (2025-02-20) X-Scanned-By: MIMEDefang 3.0 on 10.30.177.15 On Mon, Apr 14, 2025 at 06:38:49PM +0200, Cornelia Huck wrote: > Add some documentation for how individual ID registers can be > configured with the host cpu model. > > [CH: adapt to removal of the 'custom' model, added some more > explanations about using the ID register props] > Signed-off-by: Eric Auger > Signed-off-by: Cornelia Huck > --- > docs/system/arm/cpu-features.rst | 104 ++++++++++++++++++++++++++++--- > 1 file changed, 96 insertions(+), 8 deletions(-) > > diff --git a/docs/system/arm/cpu-features.rst b/docs/system/arm/cpu-features.rst > index 37d5dfd15b34..22faefd76edd 100644 > --- a/docs/system/arm/cpu-features.rst > +++ b/docs/system/arm/cpu-features.rst > @@ -2,7 +2,10 @@ Arm CPU Features > ================ > > CPU features are optional features that a CPU of supporting type may > -choose to implement or not. In QEMU, optional CPU features have > +choose to implement or not. QEMU provides two different mechanisms > +to configure those features: > + > +1. For most CPU models, optional CPU features may have > corresponding boolean CPU proprieties that, when enabled, indicate > that the feature is implemented, and, conversely, when disabled, > indicate that it is not implemented. An example of an Arm CPU feature > @@ -29,6 +32,16 @@ supports the feature. While ``aarch64`` currently only works with KVM, > it could work with TCG. CPU features that are specific to KVM are > prefixed with "kvm-" and are described in "KVM VCPU Features". > > +2. Additionally, the ``host`` CPU model on KVM allows to configure optional > +CPU features via the corresponding ID registers. The host kernel allows > +to write a subset of ID register fields. The host model exposes > +properties for each writable ID register field. Those options are named > +SYSREG__. IDREG and FIELD names are those used in the > +ARM ARM Reference Manual. They can also be found in the Linux > +arch/arm64/tool/sysreg file which is used to automatically generate the > +description for those registers and fields. This currently only has been > +implemented for KVM. Whereever they are referencing 'host', the docs should also mention 'max' CPU which should be a drop-in functional equivalent. > + > CPU Feature Probing > =================== > > @@ -124,13 +137,20 @@ A note about CPU models and KVM > > Named CPU models generally do not work with KVM. There are a few cases > that do work, e.g. using the named CPU model ``cortex-a57`` with KVM on a > -seattle host, but mostly if KVM is enabled the ``host`` CPU type must be > -used. This 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. Indeed it's even > -a bit strange to allow disabling CPU features that the host has when using > -the ``host`` CPU type, but in the absence of CPU models it's the best we can > -do if we want to launch guests without all the host's CPU features enabled. > +seattle host, but mostly if KVM is enabled, the ``host`` CPU model must be > +used. > + > +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, and the host kernel > +supports it, the ``host`` model can be instructed to disable individual > +ID register values. This is especially useful for migration purposes. > +However, this interface 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. > > Enabling KVM also affects the ``query-cpu-model-expansion`` QMP command. The > affect is not only limited to specific features, as pointed out in example > @@ -167,6 +187,13 @@ disabling many SVE vector lengths would be quite verbose, the ``sve`` CPU > properties have special semantics (see "SVE CPU Property Parsing > Semantics"). > > +Additionally, if supported by KVM on the host kernel, the ``host`` CPU model > +may be configured via individual ID register field properties, for example:: > + > + $ qemu-system-aarch64 -M virt -cpu host,SYSREG_ID_AA64ISAR0_EL1_DP=0x0 > + > +This forces ID_AA64ISAR0_EL1 DP field to 0. > + > KVM VCPU Features > ================= > > @@ -466,3 +493,64 @@ Legal values for ``S`` are 30, 34, 36, and 39; the default is 30. > > As with ``x-rme``, the ``x-l0gptsz`` property may be renamed or > removed in some future QEMU release. > + > +Configuring CPU features via ID register fields > +=============================================== > + > +Note that this is currently only supported under KVM, and with the > +``host`` CPU model. > + > +Querying available ID register fields > +------------------------------------- > + > +QEMU will create properties for all ID register fields that are > +reported as being writable by the kernel, and that are known to the > +QEMU instance. Therefore, the same QEMU binary may expose different > +properties when run under a different kernel. > + > +To find out all available writable ID register fields, use the > +``query-cpu-model-expansion`` QMP command:: > + > + (QEMU) query-cpu-model-expansion type=full model={"name":"host"} > + {"return": { > + "model": {"name": "host", "props": { > + "SYSREG_ID_AA64PFR0_EL1_EL3": 1, "SYSREG_ID_AA64ISAR2_EL1_CLRBHB": 0, > + "SYSREG_CTR_EL0_L1Ip": 3, "SYSREG_CTR_EL0_DminLine": 4, > + "SYSREG_ID_AA64MMFR0_EL1_BIGEND": 1, "SYSREG_ID_AA64MMFR1_EL1_ECBHB": 0, > + "SYSREG_ID_AA64MMFR2_EL1_CnP": 1, "SYSREG_ID_DFR0_EL1_PerfMon": 4, > + "SYSREG_ID_AA64PFR0_EL1_DIT": 0, "SYSREG_ID_AA64MMFR1_EL1_HAFDBS": 2, > + "SYSREG_ID_AA64ISAR0_EL1_FHM": 0, "SYSREG_ID_AA64ISAR2_EL1_CSSC": 0, > + "SYSREG_ID_AA64ISAR0_EL1_DP": 1, (...) > + }}}} > + > +If a certain field in an ID register does not show up in this list, it > +is not writable with the specific host kernel. On x86, "-cpu help" will list all feature names too. It makes the output pretty huge, so not sure if we want to mirror that on arm ? It is at least more useful to humans though, compared to QMP. 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 :|