All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Shameer Kolothum <shameerkolothum@gmail.com>,
	qemu-arm@nongnu.org, qemu-devel@nongnu.org
Cc: eric.auger@redhat.com, peter.maydell@linaro.org,
	sebott@redhat.com, berrange@redhat.com, maz@kernel.org,
	oliver.upton@linux.dev, armbru@redhat.com, linuxarm@huawei.com,
	wangzhou1@hisilicon.com, jiangkunkun@huawei.com,
	jonathan.cameron@huawei.com, salil.mehta@huawei.com,
	yangjinqian1@huawei.com, shameerkolothum@gmail.com,
	shameerali.kolothum.thodi@huawei.com
Subject: Re: [RFC PATCH RESEND 0/4] hw/arm/virt: Add support for Target Implementation CPUs
Date: Fri, 01 Aug 2025 10:31:51 +0200	[thread overview]
Message-ID: <87freb4f48.fsf@redhat.com> (raw)
In-Reply-To: <20250801074730.28329-1-shameerkolothum@gmail.com>

On Fri, Aug 01 2025, Shameer Kolothum <shameerkolothum@gmail.com> wrote:

> From: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
>
> (This is my third attempt to send this series to qemu-devel / qemu-arm.
> Previous attempts failed with the following errors:
>
> qemu-arm@nongnu.org: connect to eggs.gnu.org[209.51.188.92]:25: Connection timed out  
> qemu-devel@nongnu.org: connect to eggs.gnu.org[209.51.188.92]:25: Connection timed out  
>
> I'm not sure if the issue is related to my setup, so I'm now trying to send the
> patches via my Gmail account.
>
> Apologies if you’ve already received this series individually, and thank you
> for your patience.)

FWIW, all of your mails have made it into my inbox -- let's see if at
least my reply shows up on the lists :/

>
> Hi,
>
> On ARM64 platforms, many errata workarounds are based on CPU identification
> registers, particularly MIDR_EL1 and REVIDR_EL1. Some of these errata
> require corresponding fixes in the guest kernel as well. This becomes a
> challenge during guest migration between hosts with different MIDR/REVIDR
> values, even when the VMM provides a common baseline feature set using
> the recently introduced writable ID register support.
>
> To address this, the Linux kernel now provides:
>
>  -A mechanism to expose implementation CPU data to guests via KVM
>   hypercalls [0]:
>
>   ARM_SMCCC_VENDOR_HYP_KVM_DISCOVER_IMPL_VER_FUNC_ID
>   ARM_SMCCC_VENDOR_HYP_KVM_DISCOVER_IMPL_CPUS_FUNC_ID
>
>  -A way to override implementation ID registers (MIDR, REVIDR, AIDR),
>   which were previously treated as invariant [1].
>
> What this RFC does:
>
> This RFC enables the virt machine to specify Target Implementation CPUs
> via QEMU command-line, exposing them to the guest via KVM hypercalls.
>
> Example use case (hosts with differing MIDRs):
>
> ./qemu-system-aarch64 -machine virt,gic-version=3 \
>   -enable-kvm \
>   -bios QEMU_EFI.fd \
>   -m 1G -smp cpus=4,maxcpus=4 \
>   -cpu host \
>   -M impl-cpu.0.midr=0x481fd010,impl-cpu.0.revidr=0,impl-cpu.0.aidr=0x551,\
>    impl-cpu.1.midr=0x481fd011,impl-cpu.1.revidr=0,impl-cpu.1.aidr=0x551 \
>   -kernel Image-6.16-rc2 \
>   -initrd rootfs-iperf.cpio \
>   -append "rdinit=init console=ttyAMA0 root=/dev/vda rw earlycon=pl011,0x9000000 kpti=off" \
>   -net none \
>   -nographic
>
> Highlights and Notes:
>
>  -This is based on Connie’s series[2] “kvm/arm: Introduce a customizable
>   aarch64 KVM host model”.

Hm, I *really* need to do a respin of that one, at least to bring it up
to date with the code that changed underneath...

>   
>  -Currently, no validation is performed on user-specified implementation CPU
>   data. It’s assumed that one of the entries reflects the actual host CPU.
>   If needed, a check can be added to enforce this. All other target CPU
>   definitions are treated as user-driven with no internal verification.

Should that check rather be done by management software on top? Although
I assume that this is the part that in practice will come up with the
list of possible target cpus.

>
>  -For now, only the DISCOVER_IMPL_* hypercalls are supported on the QEMU side.
>   See patches 1 and 3 for implementation details. These are loosely inspired
>   by Salil's vCPU hotplug series patch here [3]. This may require a more
>   generic approach if we have to support other SMCCC hyper calls.
>
>  -This series uses macros and definitions from the kernel's
>   include/linux/arm-smccc.h. I am not sure whether these should be duplicated 
>   in QEMU or moved to a UAPI header in the kernel. For now I am carrying
>   it in the test branch here,
>   https://github.com/hisilicon/qemu/commit/8f583c76a2a5f60cf0f9616d61d0863e524ef388
>
> This is lightly tested on HiSilicon ARM platforms. A complete test branch
> can be found here,
> https://github.com/hisilicon/qemu/tree/arm-cpu-model-rfcv3-tgt-impl-cpu-rfcv1
>
> Please take a look and let me know.
>
> Thanks,
> Shameer
>
> [0] https://lore.kernel.org/all/20250221140229.12588-1-shameerali.kolothum.thodi@huawei.com/
> [1] https://lore.kernel.org/all/20250225005401.679536-1-oliver.upton@linux.dev/
> [2] https://lore.kernel.org/qemu-devel/20250414163849.321857-1-cohuck@redhat.com/
> [3] https://lore.kernel.org/qemu-devel/20240614001510.202991-1-salil.mehta@huawei.com/
>
> Shameer Kolothum (4):
>   target/arm/kvm: Introduce helper to check target impl CPU support
>   target/arm/kvm: Add QAPI struct ArmTargetImplCPU
>   target/arm/kvm: Handle KVM Target Imp CPU hypercalls
>   hw/arm/virt: Add Target Implementation CPU support
>
>  hw/arm/virt.c         |  66 +++++++++++++++
>  include/hw/arm/virt.h |   3 +
>  qapi/machine.json     |  34 ++++++++
>  target/arm/kvm.c      | 187 ++++++++++++++++++++++++++++++++++++++++++
>  target/arm/kvm_arm.h  |  20 +++++
>  5 files changed, 310 insertions(+)
>
> -- 
> 2.34.1



      parent reply	other threads:[~2025-08-01  8:32 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-01  7:47 [RFC PATCH RESEND 0/4] hw/arm/virt: Add support for Target Implementation CPUs Shameer Kolothum
2025-08-01  7:47 ` [RFC PATCH RESEND 1/4] target/arm/kvm: Introduce helper to check target impl CPU support Shameer Kolothum
2025-08-09 16:21   ` Eric Auger
2025-08-01  7:47 ` [RFC PATCH RESEND 2/4] target/arm/kvm: Add QAPI struct ArmTargetImplCPU Shameer Kolothum
2025-08-09 16:23   ` Eric Auger
2025-08-01  7:47 ` [RFC PATCH RESEND 3/4] target/arm/kvm: Handle KVM Target Imp CPU hypercalls Shameer Kolothum
2025-09-19 10:51   ` Sebastian Ott
2025-08-01  7:47 ` [RFC PATCH RESEND 4/4] hw/arm/virt: Add Target Implementation CPU support Shameer Kolothum
2025-08-09 16:21   ` Eric Auger
2025-08-01  8:31 ` Cornelia Huck [this message]

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=87freb4f48.fsf@redhat.com \
    --to=cohuck@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=eric.auger@redhat.com \
    --cc=jiangkunkun@huawei.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=linuxarm@huawei.com \
    --cc=maz@kernel.org \
    --cc=oliver.upton@linux.dev \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=salil.mehta@huawei.com \
    --cc=sebott@redhat.com \
    --cc=shameerali.kolothum.thodi@huawei.com \
    --cc=shameerkolothum@gmail.com \
    --cc=wangzhou1@hisilicon.com \
    --cc=yangjinqian1@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.