Patch Detail
get:
Show a patch.
patch:
Update a patch.
put:
Update a patch.
GET /api/1.2/patches/2232165/?format=api
{ "id": 2232165, "url": "http://patchwork.ozlabs.org/api/1.2/patches/2232165/?format=api", "web_url": "http://patchwork.ozlabs.org/project/qemu-devel/patch/20260503073541.790215-18-eric.auger@redhat.com/", "project": { "id": 14, "url": "http://patchwork.ozlabs.org/api/1.2/projects/14/?format=api", "name": "QEMU Development", "link_name": "qemu-devel", "list_id": "qemu-devel.nongnu.org", "list_email": "qemu-devel@nongnu.org", "web_url": "", "scm_url": "", "webscm_url": "", "list_archive_url": "", "list_archive_url_format": "", "commit_url_format": "" }, "msgid": "<20260503073541.790215-18-eric.auger@redhat.com>", "list_archive_url": null, "date": "2026-05-03T07:33:37", "name": "[v4,17/17] arm/cpu-features: document ID reg properties", "commit_ref": null, "pull_url": null, "state": "new", "archived": false, "hash": "3257f687250215f27d2704f471cc423654c5c942", "submitter": { "id": 69187, "url": "http://patchwork.ozlabs.org/api/1.2/people/69187/?format=api", "name": "Eric Auger", "email": "eric.auger@redhat.com" }, "delegate": null, "mbox": "http://patchwork.ozlabs.org/project/qemu-devel/patch/20260503073541.790215-18-eric.auger@redhat.com/mbox/", "series": [ { "id": 502569, "url": "http://patchwork.ozlabs.org/api/1.2/series/502569/?format=api", "web_url": "http://patchwork.ozlabs.org/project/qemu-devel/list/?series=502569", "date": "2026-05-03T07:33:20", "name": "kvm/arm: Introduce a customizable aarch64 KVM host model", "version": 4, "mbox": "http://patchwork.ozlabs.org/series/502569/mbox/" } ], "comments": "http://patchwork.ozlabs.org/api/patches/2232165/comments/", "check": "pending", "checks": "http://patchwork.ozlabs.org/api/patches/2232165/checks/", "tags": {}, "related": [], "headers": { "Return-Path": "<qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org>", "X-Original-To": "incoming@patchwork.ozlabs.org", "Delivered-To": "patchwork-incoming@legolas.ozlabs.org", "Authentication-Results": [ "legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256\n header.s=mimecast20190719 header.b=YW+KvS+M;\n\tdkim-atps=neutral", "legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=nongnu.org\n (client-ip=209.51.188.17; helo=lists1p.gnu.org;\n envelope-from=qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org;\n receiver=patchwork.ozlabs.org)" ], "Received": [ "from lists1p.gnu.org (lists1p.gnu.org [209.51.188.17])\n\t(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g7c8f1ms6z1yJV\n\tfor <incoming@patchwork.ozlabs.org>; Sun, 03 May 2026 17:38:42 +1000 (AEST)", "from localhost ([::1] helo=lists1p.gnu.org)\n\tby lists1p.gnu.org with esmtp (Exim 4.90_1)\n\t(envelope-from <qemu-devel-bounces@nongnu.org>)\n\tid 1wJROX-0001eP-Dx; Sun, 03 May 2026 03:37:41 -0400", "from eggs.gnu.org ([2001:470:142:3::10])\n by lists1p.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from <eric.auger@redhat.com>)\n id 1wJROV-0001Th-7E\n for qemu-devel@nongnu.org; Sun, 03 May 2026 03:37:39 -0400", "from us-smtp-delivery-124.mimecast.com ([170.10.133.124])\n by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)\n (Exim 4.90_1) (envelope-from <eric.auger@redhat.com>)\n id 1wJROT-0003lS-Cl\n for qemu-devel@nongnu.org; Sun, 03 May 2026 03:37:38 -0400", "from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com\n (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by\n relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3,\n cipher=TLS_AES_256_GCM_SHA384) id us-mta-358-W3fZhLoaPxy9bL9ZH6BPEA-1; Sun,\n 03 May 2026 03:37:31 -0400", "from mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com\n (mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.93])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n (No client certificate requested)\n by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS\n id E6D1918002C5; Sun, 3 May 2026 07:37:29 +0000 (UTC)", "from laptop.redhat.com (unknown [10.44.48.25])\n by mx-prod-int-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP\n id 109991800480; Sun, 3 May 2026 07:37:24 +0000 (UTC)" ], "DKIM-Signature": "v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;\n s=mimecast20190719; t=1777793856;\n h=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n to:to:cc:cc:mime-version:mime-version:\n content-transfer-encoding:content-transfer-encoding:\n in-reply-to:in-reply-to:references:references;\n bh=GV/kEiaZbeyeLmbz2zqvJvkinKvVn6H0CkxzmPwT7e4=;\n b=YW+KvS+M7CTe/UbTXH0UaZScJZDFM1QXGeov3hyyB8YYiN+pN6GcVUWrt+HT++YLt3SI6t\n hMkAAayfmSc42jgGlP7Jt5Rkb/ped7BrRO066alvUSkUzJFXAc41uc0B2N/EJseYPfWdL+\n +icqnVHeMocwCEkRhP1rJ/P1JeSPPJs=", "X-MC-Unique": "W3fZhLoaPxy9bL9ZH6BPEA-1", "X-Mimecast-MFC-AGG-ID": "W3fZhLoaPxy9bL9ZH6BPEA_1777793850", "From": "Eric Auger <eric.auger@redhat.com>", "To": "eric.auger.pro@gmail.com, eric.auger@redhat.com, qemu-devel@nongnu.org,\n qemu-arm@nongnu.org, kvmarm@lists.linux.dev, peter.maydell@linaro.org,\n richard.henderson@linaro.org, cohuck@redhat.com, sebott@redhat.com,\n skolothumtho@nvidia.com, philmd@linaro.org", "Cc": "maz@kernel.org, oliver.upton@linux.dev, pbonzini@redhat.com,\n armbru@redhat.com, berrange@redhat.com, abologna@redhat.com,\n jdenemar@redhat.com", "Subject": "[PATCH v4 17/17] arm/cpu-features: document ID reg properties", "Date": "Sun, 3 May 2026 09:33:37 +0200", "Message-ID": "<20260503073541.790215-18-eric.auger@redhat.com>", "In-Reply-To": "<20260503073541.790215-1-eric.auger@redhat.com>", "References": "<20260503073541.790215-1-eric.auger@redhat.com>", "MIME-Version": "1.0", "Content-Transfer-Encoding": "8bit", "X-Scanned-By": "MIMEDefang 3.4.1 on 10.30.177.93", "Received-SPF": "pass client-ip=170.10.133.124;\n envelope-from=eric.auger@redhat.com; helo=us-smtp-delivery-124.mimecast.com", "X-Spam_score_int": "-20", "X-Spam_score": "-2.1", "X-Spam_bar": "--", "X-Spam_report": "(-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001,\n DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,\n RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001,\n SPF_HELO_PASS=-0.001,\n SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no", "X-Spam_action": "no action", "X-BeenThere": "qemu-devel@nongnu.org", "X-Mailman-Version": "2.1.29", "Precedence": "list", "List-Id": "qemu development <qemu-devel.nongnu.org>", "List-Unsubscribe": "<https://lists.nongnu.org/mailman/options/qemu-devel>,\n <mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>", "List-Archive": "<https://lists.nongnu.org/archive/html/qemu-devel>", "List-Post": "<mailto:qemu-devel@nongnu.org>", "List-Help": "<mailto:qemu-devel-request@nongnu.org?subject=help>", "List-Subscribe": "<https://lists.nongnu.org/mailman/listinfo/qemu-devel>,\n <mailto:qemu-devel-request@nongnu.org?subject=subscribe>", "Errors-To": "qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org", "Sender": "qemu-devel-bounces+incoming=patchwork.ozlabs.org@nongnu.org" }, "content": "From: Cornelia Huck <cohuck@redhat.com>\n\nAdd some documentation for how individual ID registers can be\nconfigured with the host cpu model.\n\n[CH: adapt to removal of the 'custom' model, added some more\n explanations about using the ID register props]\nSigned-off-by: Eric Auger <eric.auger@redhat.com>\nSigned-off-by: Cornelia Huck <cohuck@redhat.com>\n---\n docs/system/arm/cpu-features.rst | 104 ++++++++++++++++++++++++++++---\n 1 file changed, 96 insertions(+), 8 deletions(-)", "diff": "diff --git a/docs/system/arm/cpu-features.rst b/docs/system/arm/cpu-features.rst\nindex 10b0eff27e..22f671b15d 100644\n--- a/docs/system/arm/cpu-features.rst\n+++ b/docs/system/arm/cpu-features.rst\n@@ -2,7 +2,10 @@ Arm CPU Features\n ================\n \n CPU features are optional features that a CPU of supporting type may\n-choose to implement or not. In QEMU, optional CPU features have\n+choose to implement or not. QEMU provides two different mechanisms\n+to configure those features:\n+\n+1. For most CPU models, optional CPU features may have\n corresponding boolean CPU proprieties that, when enabled, indicate\n that the feature is implemented, and, conversely, when disabled,\n indicate that it is not implemented. An example of an Arm CPU feature\n@@ -31,6 +34,16 @@ running guests in AArch32.\n CPU features that are inherently specific to KVM are\n prefixed with \"kvm-\" and are described in \"KVM VCPU Features\".\n \n+2. Additionally, the ``host`` CPU model on KVM allows to configure optional\n+CPU features via the corresponding ID registers. The host kernel allows\n+to write a subset of ID register fields. The host model exposes\n+properties for each writable ID register field. Those options are named\n+SYSREG_<IDREG>_<FIELD>. IDREG and FIELD names are those used in the\n+ARM ARM Reference Manual. They can also be found in the Linux\n+arch/arm64/tool/sysreg file which is used to automatically generate the\n+description for those registers and fields. This currently only has been\n+implemented for KVM.\n+\n CPU Feature Probing\n ===================\n \n@@ -126,13 +139,20 @@ A note about CPU models and KVM\n \n Named CPU models generally do not work with KVM. There are a few cases\n that do work, e.g. using the named CPU model ``cortex-a57`` with KVM on a\n-seattle host, but mostly if KVM is enabled the ``host`` CPU type must be\n-used. This means the guest is provided all the same CPU features as the\n-host CPU type has. And, for this reason, the ``host`` CPU type should\n-enable all CPU features that the host has by default. Indeed it's even\n-a bit strange to allow disabling CPU features that the host has when using\n-the ``host`` CPU type, but in the absence of CPU models it's the best we can\n-do if we want to launch guests without all the host's CPU features enabled.\n+seattle host, but mostly if KVM is enabled, the ``host`` CPU model must be\n+used.\n+\n+Using the ``host`` type means the guest is provided all the same CPU\n+features as the host CPU type has. And, for this reason, the ``host``\n+CPU type should enable all CPU features that the host has by default.\n+\n+In case some features need to be hidden to the guest, and the host kernel\n+supports it, the ``host`` model can be instructed to disable individual\n+ID register values. This is especially useful for migration purposes.\n+However, this interface will not allow configuring an arbitrary set of\n+features; the ID registers must describe a subset of the host's features,\n+and all differences to the host's configuration must actually be supported\n+by the kernel to be deconfigured.\n \n Enabling KVM also affects the ``query-cpu-model-expansion`` QMP command. The\n affect is not only limited to specific features, as pointed out in example\n@@ -169,6 +189,13 @@ disabling many SVE vector lengths would be quite verbose, the ``sve<N>`` CPU\n properties have special semantics (see \"SVE CPU Property Parsing\n Semantics\").\n \n+Additionally, if supported by KVM on the host kernel, the ``host`` CPU model\n+may be configured via individual ID register field properties, for example::\n+\n+ $ qemu-system-aarch64 -M virt -cpu host,SYSREG_ID_AA64ISAR0_EL1_DP=0x0\n+\n+This forces ID_AA64ISAR0_EL1 DP field to 0.\n+\n KVM VCPU Features\n =================\n \n@@ -495,3 +522,64 @@ Legal values for ``S`` are 30, 34, 36, and 39; the default is 30.\n \n As with ``x-rme``, the ``x-l0gptsz`` property may be renamed or\n removed in some future QEMU release.\n+\n+Configuring CPU features via ID register fields\n+===============================================\n+\n+Note that this is currently only supported under KVM, and with the\n+``host`` CPU model.\n+\n+Querying available ID register fields\n+-------------------------------------\n+\n+QEMU will create properties for all ID register fields that are\n+reported as being writable by the kernel, and that are known to the\n+QEMU instance. Therefore, the same QEMU binary may expose different\n+properties when run under a different kernel.\n+\n+To find out all available writable ID register fields, use the\n+``query-cpu-model-expansion`` QMP command::\n+\n+ (QEMU) query-cpu-model-expansion type=full model={\"name\":\"host\"}\n+ {\"return\": {\n+ \"model\": {\"name\": \"host\", \"props\": {\n+ \"SYSREG_ID_AA64PFR0_EL1_EL3\": 1, \"SYSREG_ID_AA64ISAR2_EL1_CLRBHB\": 0,\n+ \"SYSREG_CTR_EL0_L1Ip\": 3, \"SYSREG_CTR_EL0_DminLine\": 4,\n+ \"SYSREG_ID_AA64MMFR0_EL1_BIGEND\": 1, \"SYSREG_ID_AA64MMFR1_EL1_ECBHB\": 0,\n+ \"SYSREG_ID_AA64MMFR2_EL1_CnP\": 1, \"SYSREG_ID_DFR0_EL1_PerfMon\": 4,\n+ \"SYSREG_ID_AA64PFR0_EL1_DIT\": 0, \"SYSREG_ID_AA64MMFR1_EL1_HAFDBS\": 2,\n+ \"SYSREG_ID_AA64ISAR0_EL1_FHM\": 0, \"SYSREG_ID_AA64ISAR2_EL1_CSSC\": 0,\n+ \"SYSREG_ID_AA64ISAR0_EL1_DP\": 1, (...)\n+ }}}}\n+\n+If a certain field in an ID register does not show up in this list, it\n+is not writable with the specific host kernel.\n+\n+A note on compatibility\n+-----------------------\n+\n+A common use case for providing a defined set of ID register values is\n+to be able to present a fixed set of features to a guest, often referred\n+to as \"stable guest ABI\". This may take the form of ironing out differences\n+between two similar CPUs with the intention of being able to migrate\n+between machines with those CPUs, or providing the same CPU across Linux\n+kernel updates on the host.\n+\n+Over the course of time, the Linux kernel is changing the set of ID register\n+fields that are writable by userspace. Newly introduced writable ID\n+registers should be initialized to 0 to ensure compatibility. However, ID\n+registers that have already been introduced that undergo a change as to\n+which fields are writable may introduce incompatibities that need to be\n+addressed on a case-by-case basis for the systems that you wish to migrate\n+inbetween.\n+\n+A note on Arm CPU features (FEAT_xxx)\n+-------------------------------------\n+\n+Configuring CPUs is done on a feature level on other architectures, and this\n+would imply configuring FEAT_xxx values on Arm. However, differences between\n+CPUs may not map to FEAT_xxx, but to differences in other registers in the\n+ID register range; for example, differences in the cache architecture exposed\n+via ``CTR_EL0``. We therefore cannot rely on configuration via FEAT_xxx. A\n+feature-based interface more similar to other architectures may be implemented\n+on top of the ID register interface in the future.\n", "prefixes": [ "v4", "17/17" ] }