From: Kashyap Chamarthy <kchamart@redhat.com>
To: Eric Auger <eric.auger@redhat.com>
Cc: eric.auger.pro@gmail.com, cohuck@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,
berrange@redhat.com, abologna@redhat.com, jdenemar@redhat.com,
shahuang@redhat.com, mark.rutland@arm.com, philmd@linaro.org,
pbonzini@redhat.com
Subject: Re: [RFC 00/21] kvm/arm: Introduce a customizable aarch64 KVM host model
Date: Fri, 25 Oct 2024 16:51:19 +0200 [thread overview]
Message-ID: <ZxuwZw2plMI6dNyE@pinwheel> (raw)
In-Reply-To: <20241025101959.601048-1-eric.auger@redhat.com>
On Fri, Oct 25, 2024 at 12:17:19PM +0200, Eric Auger wrote:
Hi Eric,
I'm new to Arm, so please bear with my questions :)
> This RFC series introduces a KVM host "custom" model.
(a) On terminology: as we know, in the x86 world, QEMU uses these
terms[1]:
- Host passthrough
- Named CPU models
- Then there's the libvirt abstraction, "host-model", that aims to
provide the best of 'host-passthrough' + named CPU models.
Now I see the term "host 'custom' model" here. Most
management-layer tools and libvirt users are familiar with the
classic terms "host-model" or "custom". If we now say "host
'custom' model", it can create confusion. I hope we can settle on
one of the existing terms, or create a new term if need be.
(I'll share one more thought on how layers above libvirt tend to use
the term "custom", as a reply to patch 21/21, "arm/cpu-features:
Document custom vcpu model".)
(b) The current CPU features doc[2] for Arm doesn't mention "host
passthrough" at all. It is only implied by the last part of this
paragraph, from the section titled "A note about CPU models and
KVM"[3]:
"Named CPU models generally do not work with KVM. There are a few
cases that do work [...] but mostly if KVM is enabled the 'host'
CPU type must be used."
Related: in your reply[4] to Dan in this series, you write: "Having
named models is the next thing". So named CPU models will be a
thing in Arm, too? Then the above statement in the Arm
'cpu-features' will need updating :-)
[...]
> - the QEMU layer does not take care of IDREG field value consistency.
> The kernel neither. I imagine this could be the role of the upper
> layer to implement a vcpu profile that makes sure settings are
> consistent. Here we come to "named" models. What should they look
> like on ARM?
Are there reasons why they can't be similar to how x86 reports in
`qemu-system-x86 -cpu help`?
E.g. If it's an NVIDIA "Grace A02" (Neoverse-V2) host, it can report:
[gracehopper] $> qemu-kvm -cpu help
Available CPUs:
gracehopper-neoverse-v2
cortex-a57 (deprecated)
host
max
Or whatever is the preferred nomenclature for ARM. It also gives users
of both x86 and ARM deployments a consistent expectation.
Currently on a "Grace A02" ("Neoverse-V2") machine, it reports:
[gracehopper] $> qemu-kvm -cpu help
Available CPUs:
cortex-a57 (deprecated)
host
max
I see it's because there are no named models yet on ARM :-)
[...]
[1] https://www.qemu.org/docs/master/system/i386/cpu.html
[2] https://www.qemu.org/docs/master/system/arm/cpu-features.html
[3] https://www.qemu.org/docs/master/system/arm/cpu-features.html#a-note-about-cpu-models-and-kvm
[4] https://lists.nongnu.org/archive/html/qemu-arm/2024-10/msg00891.html
--
/kashyap
next prev parent reply other threads:[~2024-10-25 14:51 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-25 10:17 [RFC 00/21] kvm/arm: Introduce a customizable aarch64 KVM host model Eric Auger
2024-10-25 10:17 ` [RFC 01/21] kvm: kvm_get_writable_id_regs Eric Auger
2024-10-25 10:17 ` [RFC 02/21] arm/cpu: Add sysreg definitions in cpu-sysegs.h Eric Auger
2024-10-25 10:17 ` [RFC 03/21] arm/cpu: Store aa64isar0 into the idregs arrays Eric Auger
2024-10-25 10:17 ` [RFC 04/21] arm/cpu: Store aa64isar1/2 into the idregs array Eric Auger
2024-10-25 10:17 ` [RFC 05/21] arm/cpu: Store aa64drf0/1 " Eric Auger
2024-10-25 10:17 ` [RFC 06/21] arm/cpu: Store aa64mmfr0-3 " Eric Auger
2024-10-25 10:17 ` [RFC 07/21] arm/cpu: Store aa64drf0/1 " Eric Auger
2024-10-25 10:17 ` [RFC 08/21] arm/cpu: Store aa64smfr0 " Eric Auger
2024-10-25 10:17 ` [RFC 09/21] arm/cpu: Store id_isar0-7 " Eric Auger
2024-10-25 10:17 ` [RFC 10/21] arm/cpu: Store id_mfr0/1 " Eric Auger
2024-10-25 10:17 ` [RFC 11/21] arm/cpu: Store id_dfr0/1 " Eric Auger
2024-10-25 10:17 ` [RFC 12/21] arm/cpu: Store id_mmfr0-5 " Eric Auger
2024-10-25 10:17 ` [RFC 13/21] arm/cpu: Add infra to handle generated ID register definitions Eric Auger
2024-10-25 12:55 ` Daniel P. Berrangé
2024-10-25 10:17 ` [RFC 14/21] arm/cpu: Add sysreg generation scripts Eric Auger
2024-10-25 17:05 ` Marc Zyngier
2024-11-04 13:33 ` Eric Auger
2024-10-25 10:17 ` [RFC 15/21] arm/cpu: Add generated files Eric Auger
2024-10-25 10:17 ` [RFC 16/21] arm/kvm: Allow reading all the writable ID registers Eric Auger
2024-10-25 10:17 ` [RFC 17/21] arm/kvm: write back modified ID regs to KVM Eric Auger
2024-10-25 10:17 ` [RFC 18/21] arm/cpu: Introduce a customizable kvm host cpu model Eric Auger
2024-10-25 13:06 ` Daniel P. Berrangé
2024-10-25 13:18 ` Eric Auger
2024-10-25 13:23 ` Daniel P. Berrangé
2024-10-28 16:00 ` Cornelia Huck
2024-10-28 16:15 ` Daniel P. Berrangé
2024-10-28 16:16 ` Peter Maydell
2024-10-28 16:25 ` Cornelia Huck
2024-10-28 16:35 ` Daniel P. Berrangé
2024-10-28 16:48 ` Peter Maydell
2024-10-28 16:56 ` Oliver Upton
2024-10-30 16:15 ` Cornelia Huck
2024-10-30 16:27 ` Daniel P. Berrangé
2024-11-04 17:09 ` Eric Auger
2024-11-04 17:16 ` Peter Maydell
2024-11-04 18:15 ` Eric Auger
2024-10-28 17:04 ` Daniel P. Berrangé
2024-11-04 14:27 ` Eric Auger
2024-11-11 14:29 ` Cornelia Huck
2024-11-12 16:30 ` Cornelia Huck
2024-11-12 18:28 ` Eric Auger
2024-11-29 15:10 ` Cornelia Huck
2024-11-29 15:42 ` Peter Maydell
2024-11-29 15:51 ` Cornelia Huck
2024-11-14 15:44 ` Peter Maydell
2024-10-25 10:17 ` [RFC 19/21] virt: Allow custom vcpu model in arm virt Eric Auger
2024-10-25 10:17 ` [RFC 20/21] arm-qmp-cmds: introspection for custom model Eric Auger
2024-10-25 10:17 ` [RFC 21/21] arm/cpu-features: Document custom vcpu model Eric Auger
2024-10-25 13:13 ` Daniel P. Berrangé
2024-10-25 13:28 ` Eric Auger
2024-10-25 13:31 ` Daniel P. Berrangé
2024-10-28 16:05 ` Cornelia Huck
2024-10-28 16:09 ` Daniel P. Berrangé
2024-10-28 16:29 ` Cornelia Huck
2024-10-31 12:24 ` Kashyap Chamarthy
2024-10-31 12:59 ` Peter Maydell
2024-11-04 14:45 ` Eric Auger
2024-11-04 14:55 ` Daniel P. Berrangé
2024-11-04 15:10 ` Cornelia Huck
2024-11-04 15:24 ` Daniel P. Berrangé
2024-11-04 15:48 ` Cornelia Huck
2024-10-28 21:17 ` Kashyap Chamarthy
2024-11-04 15:34 ` Eric Auger
2024-11-04 16:30 ` Peter Maydell
2024-11-04 17:07 ` Eric Auger
2024-11-04 18:29 ` Kashyap Chamarthy
2024-10-25 12:49 ` [RFC 00/21] kvm/arm: Introduce a customizable aarch64 KVM host model Cornelia Huck
2024-10-25 14:51 ` Kashyap Chamarthy [this message]
2024-10-28 16:20 ` Cornelia Huck
2024-10-28 16:44 ` Peter Maydell
2024-11-04 15:52 ` Eric Auger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZxuwZw2plMI6dNyE@pinwheel \
--to=kchamart@redhat.com \
--cc=abologna@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=armbru@redhat.com \
--cc=berrange@redhat.com \
--cc=cohuck@redhat.com \
--cc=eric.auger.pro@gmail.com \
--cc=eric.auger@redhat.com \
--cc=jdenemar@redhat.com \
--cc=kvmarm@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=sebott@redhat.com \
--cc=shahuang@redhat.com \
--cc=shameerali.kolothum.thodi@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.