> -----Original Message-----
> From: qemu-devel-bounces+skolothumtho=nvidia.com@nongnu.org <qemu-
> devel-bounces+skolothumtho=nvidia.com@nongnu.org> On Behalf Of
> Khushit Shah
> Sent: 07 September 2026 07:40
> To: Shameer Kolothum <shameerkolothum@gmail.com>
> Cc: qemu-arm@nongnu.org; qemu-devel@nongnu.org;
> eric.auger@redhat.com; peter.maydell@linaro.org; cohuck@redhat.com;
> 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; shameerali.kolothum.thodi@huawei.com; Shaju
> Abraham <shaju.abraham@nutanix.com>; Sandesh Patel
> <sandesh.patel@nutanix.com>
> Subject: Re: [RFC PATCH RESEND 0/4] hw/arm/virt: Add support for Target
> Implementation CPUs
> 
> External email: Use caution opening links or attachments
> 
> 
> > On 1 Aug 2025, at 1:17 PM, 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.)
> >
> > 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”.
> >
> > -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.
> >
> > -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/8f583c76a2a5f60cf0f9616d61d
> 08
> > 63e524ef388
> >
> > 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-cp
> > u-rfcv1
> >
> > Please take a look and let me know.
> >
> 
> Hi Shameer,

Hi Khushit,

> Thanks for putting this series together. I gave a quick look to the patches and
> the overall approach looks solid to me. While this work is orthogonal to the
> "named CPU models on ARM64" series, it is absolutely essential for proper
> guest errata handling during migration.
> 
> I did notice that the patches no longer apply cleanly on top of Eric’s v8. Since
> I'm very interested in seeing this move forward, I would be happy to rebase
> this on top of v8 for you if you're currently tied up.

Right. This was based on a very early version of Eric's work and definitely needs
a rebase. 

> Let me know if you'd like me to send out a rebased version!

Sorry for the delay, it is currently on my ToDo list. I intend to take a look at both
Eric's and your latest series and will respin this soon. That will also give me an
opportunity to go through those series in detail. 

If something else comes up in the meantime that changes my priorities, I will
let you know so that this won't become a blocker.

Thanks,
Shameer