Add Arm CCA support #2

ianm-nv · 2025-10-08T16:10:35Z

This pull request contains the latest ARM CCA changes for QEMU. Most of the patches are clean cherry-picks. There are two patches that needed adjustment. The Linaro branch is based off of a 10.1 staging branch and there is a patch that came in after that affected two of the patches. At this time, testing is somewhat difficult, I have tested these successfully in our environment.

Patches that needed adjustment:
"a6b38db7cf - NVIDIA: SAUCE: hw/arm/virt: Add measurement log for confidential boot"
"565d5cd2fd - NVIDIA: SAUCE: target/arm/cpu: Set number of breakpoints and watchpoints in KVM"

Patch that triggered adjustments:
"def3f1c102 - arm/cpu: Store aa64dfr0/1 into the idregs array"

The following patches are devel patches from our team for enabling Device Assignment support.
"3e1ffee9ca - NVIDIA: SAUCE: hw/arm/virt: Define MEC as shared or private"
"2817954d38 NVIDIA: SAUCE: vfio/pci: Register BDF with kernel"

References:
Building an RME stack for QEMU
Linaro Repo

debian/changelog: - Updated version to 10.1.0+nvidia1 debian/control: debian/control-in: - Added dependency support for meson-1.5 (required by v10.1) - Added NVIDIA as maintainer debian/rules: - Removed pvrdma and cris/nios2 architectures (removed since v8.2) - Disabled firmware builds debian/qemu-system-common.install: - Remove obsolete files (removed since v8.2) - Added hw-uefi-vars.so (added since v8.2) debian/rules: - Removed pvrdma and cris/nios2 architectures (removed since v8.2) - Disabled firmware builds Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>

Add -unstable to version string. Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>

Copy the KVM definitions for Arm RME from the development branch. Don't merge, they will be added from the periodic Linux header sync. Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> (cherry picked from commit 963d576c9bfe96c0a31b0313f47dc62fc993e92d https://git.codelinaro.org/linaro/dcap/qemu.git) [ianm: context adjustment for kpset 6.16 commit 052233c47d66f0 - value change of KVM_CAP_ARM_RME commit] Signed-off-by: Ian May <ianm@nvidia.com>

The Arm KVM code can return different values from KVM_CHECK_EXTENSION depending on the VM type. Use kvm_vm_check_extension() where necessary to ensure we get the right response from KVM. Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> (cherry picked from commit 8fe082b9c572e541d2bd07aa82f4f6684948b913 https://git.codelinaro.org/linaro/dcap/qemu.git) Signed-off-by: Ian May <ianm@nvidia.com>

Add a new RmeGuest object, inheriting from ConfidentialGuestSupport, to support the Arm Realm Management Extension (RME). It is instantiated by passing on the command-line: -M virt,confidential-guest-support=<id> -object rme-guest,id=<id>[,options...] This is only the skeleton. Support will be added in following patches. Cc: Eric Blake <eblake@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Cc: Daniel P. Berrangé <berrange@redhat.com> Cc: Eduardo Habkost <eduardo@habkost.net> Acked-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> (cherry picked from commit 5ecb9f465e30870eb44937851a57ac95e345eba6 https://git.codelinaro.org/linaro/dcap/qemu.git) Signed-off-by: Ian May <ianm@nvidia.com>

…h_init() Returning an error to kvm_init() is fatal anyway, no need to continue the initialization. Leave the `ret` variable in the function scope because it will be reused when adding RME support. Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit c9c713179a95192a9212f06f693f1e34af9822cc https://git.codelinaro.org/linaro/dcap/qemu.git) Signed-off-by: Ian May <ianm@nvidia.com>

The machine code calls kvm_arm_rme_vm_type() to get the VM flag and KVM calls kvm_arm_rme_init() to prepare for launching a Realm. Once VM creation is complete, create the Realm: * Create the realm descriptor, * load images into Realm RAM (in another patch), * finalize the REC (vCPU) after the registers are reset, * activate the realm, at which point the realm is sealed. Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> (cherry picked from commit bc8e78745236a1dfe5a930d1a63ca977baeb9afb https://git.codelinaro.org/linaro/dcap/qemu.git) Signed-off-by: Ian May <ianm@nvidia.com>

The confidential guest support in KVM limits the number of registers that we can read and write. Split the get/put_registers function to prepare for it. Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> (cherry picked from commit 845397aa4e9727845226a13b21eebc5462cabb8e https://git.codelinaro.org/linaro/dcap/qemu.git) Signed-off-by: Ian May <ianm@nvidia.com>

The target code calls kvm_arm_vcpu_init() to mark the vCPU as part of a Realm. For a Realm vCPU, only x0-x7 can be set at runtime. Before boot, the PC can also be set, and is ignored at runtime. KVM also accepts a few system register changes during initial configuration, as returned by KVM_GET_REG_LIST. Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> (cherry picked from commit 0c18ee1e332788d1935c587585bd78dbda2d3fee https://git.codelinaro.org/linaro/dcap/qemu.git) Signed-off-by: Ian May <ianm@nvidia.com>

Some ID registers have a different value for a Realm VM, for example ID_AA64DFR0_EL1 contains the number of breakpoints/watchpoints implemented by RMM instead of the hardware. Even though RMM is in charge of setting up most Realm registers, KVM still provides GET_ONE_REG interface on a Realm VM to probe the VM's capabilities. Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> (cherry picked from commit 35c8e7cb786f3701367fe29dd344c89931bb91d0 https://git.codelinaro.org/linaro/dcap/qemu.git) Signed-off-by: Ian May <ianm@nvidia.com>

Add a function to register a notifier, that is invoked after a ROM gets loaded into guest memory. It will be used by Arm confidential guest support, in order to register all blobs loaded into memory with KVM, so that their content is moved into Realm state and measured into the initial VM state. Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> (cherry picked from commit 5cc4c5416bc95b856b46c65eb1de2587707a333c https://git.codelinaro.org/linaro/dcap/qemu.git) Signed-off-by: Ian May <ianm@nvidia.com>

Initialize the IPA state of RAM. Collect the images copied into guest RAM into a sorted list, and issue POPULATE_REALM KVM ioctls once we've created the Realm Descriptor. The images are part of the Realm Initial Measurement. Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> (cherry picked from commit 337decaf5ea55c00e7354ac01d450a63ae28bc0b https://git.codelinaro.org/linaro/dcap/qemu.git) Signed-off-by: Ian May <ianm@nvidia.com>

…rameter The Realm Personalization Value (RPV) is provided by the user to distinguish Realms that have the same initial measurement. The user provides a base64 string encoding 64 bytes. They are stored into the RPV in the same order. Cc: Eric Blake <eblake@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Cc: Daniel P. Berrangé <berrange@redhat.com> Cc: Eduardo Habkost <eduardo@habkost.net> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> --- v3->v4: switch to base64 (cherry picked from commit 1138f32dea34c9c7360a658d5d7ce25a95d35066 https://git.codelinaro.org/linaro/dcap/qemu.git) Signed-off-by: Ian May <ianm@nvidia.com>

This option selects which measurement algorithm to use for attestation. Supported values are SHA256 and SHA512. Default to SHA512 arbitrarily. SHA512 is generally faster on 64-bit architectures. On a few arm64 CPUs I tested SHA256 is much faster, but that's most likely because they only support acceleration via FEAT_SHA256 (Armv8.0) and not FEAT_SHA512 (Armv8.2). Future CPUs supporting RME are likely to also support FEAT_SHA512. Cc: Eric Blake <eblake@redhat.com> Cc: Markus Armbruster <armbru@redhat.com> Cc: Daniel P. Berrangé <berrange@redhat.com> Cc: Eduardo Habkost <eduardo@habkost.net> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> --- TODO: switch to 256 (cherry picked from commit a9c9c91776ef951bd9b8caac93fad4b2f63c75cb https://git.codelinaro.org/linaro/dcap/qemu.git) Signed-off-by: Ian May <ianm@nvidia.com>

…nts in KVM Add "num-breakpoints" and "num-watchpoints" CPU parameters to configure the debug features that KVM presents to the guest. The KVM vCPU configuration is modified by calling SET_ONE_REG on the ID register. This is needed for Realm VMs, whose parameters include breakpoints and watchpoints, and influence the Realm Initial Measurement. Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> (cherry picked from commit a8ad7f59ebbe12ffd23208a86d17a79b56d5e7d5 https://git.codelinaro.org/linaro/dcap/qemu.git) [ianm: adjustment needed for def3f1c -"arm/cpu: Store aa64dfr0/1 into the idregs array"] Signed-off-by: Ian May <ianm@nvidia.com>

nvmochs

Confirmed these match upstream exactly:
✅ Commit 5fd602b matches upstream exactly
✅ Commit 03622c8 matches upstream exactly
✅ Commit 83ef143 matches upstream exactly
✅ Commit 92d172f matches upstream exactly
✅ Commit 7c73976 matches upstream exactly
✅ Commit cdab8ac matches upstream exactly
✅ Commit e9b49e7 matches upstream exactly
✅ Commit 6bdb598 matches upstream exactly
✅ Commit 4d00a13 matches upstream exactly
✅ Commit 59e752e matches upstream exactly
✅ Commit 56d8756 matches upstream exactly
✅ Commit a34fe44 matches upstream exactly
✅ Commit 70b4635 matches upstream exactly
✅ Commit d005f2a matches upstream exactly
✅ Commit 9d6dd3e matches upstream exactly
✅ Commit 25fd168 matches upstream exactly
✅ Commit 69877fb matches upstream exactly
✅ Commit f393859 matches upstream exactly
✅ Commit 637c6ce matches upstream exactly
✅ Commit a9ad578 matches upstream exactly
✅ Commit 6e91ce1 matches upstream exactly

Several others also matched upstream but had minor context difference that were flagged, but are not part of the changeset.

I did have a few questions about these 3:

eec7964 NVIDIA: SAUCE: target/arm/cpu: Set number of PMU counters in KVM
Just to confirm, this change was not made because KVM_REG_ARM_PMCR_EL0 is not present in 10.1?
ARM64_SYS_REG(3, 3, 9, 12, 0)); -> KVM_REG_ARM_PMCR_EL0);

565d5cd NVIDIA: SAUCE: target/arm/cpu: Set number of breakpoints and watchpoints in KVM
Just to confirm, this change was not made because KVM_REG_ARM_ID_AA64DFR0_EL1 is not present in 10.1?
ARM64_SYS_REG(3, 0, 0, 5, 0)); -> KVM_REG_ARM_ID_AA64DFR0_EL1);

ec4fb68 NVIDIA: SAUCE: NOMERGE: Add KVM Arm RME definitions to Linux headers
Looks like you only took KVM_CAP_ARM_RME from this commit (and changed the value to be compatible with 6.16). Is that correct?

Add a "num-pmu-counters" CPU parameter to configure the number of counters that KVM presents to the guest. This is needed for Realm VMs, whose parameters include the number of PMU counters and influence the Realm Initial Measurement. Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> (cherry picked from commit b50d7cdd7f34e07befa0267f750f99e1c02596df https://git.codelinaro.org/linaro/dcap/qemu.git) Signed-off-by: Ian May <ianm@nvidia.com>

…registers The host cannot access registers of a Realm. Instead of showing all registers as zero in "info registers", display a message about this restriction. Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> (cherry picked from commit ebf1075f11afc6093f37881c7d528b088b87a8a8 https://git.codelinaro.org/linaro/dcap/qemu.git) Signed-off-by: Ian May <ianm@nvidia.com>

When confidential-guest-support is enabled for the virt machine, add the RME flag to the VM type. The HVC conduit for PSCI is not supported for Realms. Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> (cherry picked from commit 41722b7bcce535699c1925b7fbeb22af4dbef565 https://git.codelinaro.org/linaro/dcap/qemu.git) Signed-off-by: Ian May <ianm@nvidia.com>

The dtb-randomness feature, which adds random seeds to the DTB, isn't really compatible with confidential VMs since it randomizes the Realm Initial Measurement. Enabling it is not an error, but it prevents attestation. It also isn't useful to a Realm, which doesn't trust host input. Currently the feature is automatically enabled, unless the user disables it on the command-line. Change it to OnOffAuto, and automatically disable it for confidential VMs, unless the user explicitly enables it. Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit a59b75ce6be0cd86e1e2d5a20dcbc381e791e776 https://git.codelinaro.org/linaro/dcap/qemu.git) Signed-off-by: Ian May <ianm@nvidia.com>

… for RME When RME is enabled, the upper GPA bit is used to distinguish protected from unprotected addresses. Reserve it when setting up the guest memory map. Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> (cherry picked from commit 1368d216fdb9d5055c182f213dfeeebfb293af59 https://git.codelinaro.org/linaro/dcap/qemu.git) Signed-off-by: Ian May <ianm@nvidia.com>

All Realm IPA states are by default RIPAS_EMPTY, and accessing them in that state causes injection of synchronous exception. Either the loader or the guest needs to set IPA state to RIPAS_RAM before accessing it. Since a Linux guest needs all memory ready at boot [1], initialize it here. [1] https://docs.kernel.org/arch/arm64/booting.html https://lore.kernel.org/all/20241004144307.66199-12-steven.price@arm.com/ Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> (cherry picked from commit 41e96f8d1a7727fc9cb4d3a1674b672fc4121942 https://git.codelinaro.org/linaro/dcap/qemu.git) Signed-off-by: Ian May <ianm@nvidia.com>

…emory region In Arm CCA, the guest-physical address space is split in half. The top half represents memory shared between guest and host, and the bottom half is private to the guest. From QEMU's point of view, the two halves are merged into a single region, and pages within this region are either shared or private. Addresses used by device DMA can potentially target both halves. Physical devices assigned to the VM access the top half, until they are authenticated using features like PCIe CMA-SPDM at which point they can also access memory private to the guest. Virtual devices implemented by the host are only allowed to access the top half. For emulated MMIO, KVM strips the GPA before returning to QEMU, so the GPA already belongs to QEMU's merged view of guest memory. However DMA addresses cannot be stripped this way and need special handling by the VMM: * When emulating DMA the VMM needs to translate the addresses into its merged view. Add an IOMMU memory region on the top half, that retargets DMA accesses to the merged sysmem. * when creating IOMMU mappings for (unauthenticated) VFIO devices, the VMM needs to map the top half of guest-physical addresses to the shared pages. Install RAM discard listeners that issue IOMMU map and unmap requests to IOMMU listeners such as VFIO. The resulting mtree looks like this: address-space: vfio-pci 0000000000000000-ffffffffffffffff (prio 0, i/o): bus master container 0000000000000000-000001ffffffffff (prio 0, i/o): alias bus master @realm-dma-region 0000000000000000-000001ffffffffff memory-region: realm-dma-region 0000000000000000-000001ffffffffff (prio 0, i/o): realm-dma-region There are at least two problems with this approach: given that we use the PCI bus master address space, a vIOMMU cannot install its own address space at the moment. And since sysbus devices can't have an IOMMU at the moment, DMA from non-PCI devices isn't supported. Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> (cherry picked from commit b0bbe62ff73bc3be5943fabe01e5dd857bcb6ada https://git.codelinaro.org/linaro/dcap/qemu.git) Signed-off-by: Ian May <ianm@nvidia.com>

For confidential VMs we'll want to skip flash device creation. Unfortunately, in virt_instance_init() the machine->cgs member has not yet been initialized, so we cannot check whether confidential guest is enabled. Move virt_flash_create() to machvirt_init(), where we can access the machine->cgs member. Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> (cherry picked from commit a158ed3493938b9d958dd64d3ee43b03030f0f9b https://git.codelinaro.org/linaro/dcap/qemu.git) Signed-off-by: Ian May <ianm@nvidia.com>

… guest firmware The flash device that holds firmware code relies on read-only stage-2 mappings. Read accesses behave as RAM and write accesses as MMIO. Since the RMM does not support read-only mappings we cannot use the flash device as-is. That isn't a problem because the firmware does not want to disclose any information to the host, hence will not store its variables in clear persistent memory. We can therefore replace the flash device with RAM, and load the firmware there. Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> (cherry picked from commit f00acbc1709d5064dad7a8bc36dffef601dfe699 https://git.codelinaro.org/linaro/dcap/qemu.git) Signed-off-by: Ian May <ianm@nvidia.com>

Some distributions provide packages continaing firmware to be run under QEMU, such as "qemu-efi-aarch64" or "edk2-aarch64". Those packages also contain descriptors in /usr/share/qemu/firmware/*.json listing the firmware features, so that environments like libvirt can figure out which firmware they can load. Define an optional feature for arm64 firmware to indicate that a firmware supports running in a Realm. Firmware implementations need extra support for running in a Realm, in particular to distinguish shared from private guest memory. Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> (cherry picked from commit 248ac3e78c1881453d378a0c08e85267ff1e2e25 https://git.codelinaro.org/linaro/dcap/qemu.git) Signed-off-by: Ian May <ianm@nvidia.com>

For confidential VMs it may be necessary to measure the DTB, to ensure a malicious host does not insert harmful information in there. In case an external tool can generated and measured the DTB, load it as is without patching it. Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> (cherry picked from commit 8d9f6274bbaa65234603277ee5a971e4de660015 https://git.codelinaro.org/linaro/dcap/qemu.git) Signed-off-by: Ian May <ianm@nvidia.com>

An independent verifier needs to reconstruct the content of guest memory in order to attest that it is running trusted code. To avoid having to reconstruct the bootloader generated by QEMU, skip this step and jump directly to the kernel, with the DTB address in x0 as specified by the Linux boot protocol [1]. [1] https://docs.kernel.org/arch/arm64/booting.html Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> (cherry picked from commit 7fd24221e2c996a29eb4665053d38e5fdd5df286 https://git.codelinaro.org/linaro/dcap/qemu.git) Signed-off-by: Ian May <ianm@nvidia.com>

Provide a library allowing the VMM to create an event log that describes what is loaded into memory. During remote attestation in confidential computing this helps an independent verifier reconstruct the initial measurements of a VM, which contain the initial state of memory and CPUs. We provide some definitions and structures described by the Trusted Computing Group (TCG) in "TCG PC Client Platform Firmware Profile Specification" Level 00 Version 1.06 Revision 52 [1]. This is the same format as used by UEFI, and UEFI could reuse this log after finding it in DT or ACPI tables, but can also copy its content into a new one. [1] https://trustedcomputinggroup.org/resource/pc-client-specific-platform-firmware-profile-specification/ Cc: Stefan Berger <stefanb@linux.vnet.ibm.com> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> (cherry picked from commit 8720d1c59bc738711b0e2bc4b656ad9cd0beba44 https://git.codelinaro.org/linaro/dcap/qemu.git) Signed-off-by: Ian May <ianm@nvidia.com>

shamiali2008 · 2025-10-09T11:59:03Z

Looks good to me. Minor comments below:

For eec7964 NVIDIA: SAUCE: target/arm/cpu: Set number of PMU counters in KVM
You could use KVM_REG_ARM_PMCR_EL0 in kvm_arm_get_host_cpu_features(). Though it won't affect anything, will align with original.

Also the last hunk in a6b38db actually belongs to 83ef143 . Right? It may break the compile.

ianm-nv · 2025-10-09T13:39:18Z

Confirmed these match upstream exactly: ✅ Commit 5fd602b matches upstream exactly ✅ Commit 03622c8 matches upstream exactly ✅ Commit 83ef143 matches upstream exactly ✅ Commit 92d172f matches upstream exactly ✅ Commit 7c73976 matches upstream exactly ✅ Commit cdab8ac matches upstream exactly ✅ Commit e9b49e7 matches upstream exactly ✅ Commit 6bdb598 matches upstream exactly ✅ Commit 4d00a13 matches upstream exactly ✅ Commit 59e752e matches upstream exactly ✅ Commit 56d8756 matches upstream exactly ✅ Commit a34fe44 matches upstream exactly ✅ Commit 70b4635 matches upstream exactly ✅ Commit d005f2a matches upstream exactly ✅ Commit 9d6dd3e matches upstream exactly ✅ Commit 25fd168 matches upstream exactly ✅ Commit 69877fb matches upstream exactly ✅ Commit f393859 matches upstream exactly ✅ Commit 637c6ce matches upstream exactly ✅ Commit a9ad578 matches upstream exactly ✅ Commit 6e91ce1 matches upstream exactly

Several others also matched upstream but had minor context difference that were flagged, but are not part of the changeset.

I did have a few questions about these 3:

eec7964 NVIDIA: SAUCE: target/arm/cpu: Set number of PMU counters in KVM Just to confirm, this change was not made because KVM_REG_ARM_PMCR_EL0 is not present in 10.1? ARM64_SYS_REG(3, 3, 9, 12, 0)); -> KVM_REG_ARM_PMCR_EL0);

For this commit, I did miss the change of setting the macro, technically just a cosmetic change, but still one we should grab, so thanks for catching that! I've pushed an update with this adjusted.

565d5cd NVIDIA: SAUCE: target/arm/cpu: Set number of breakpoints and watchpoints in KVM Just to confirm, this change was not made because KVM_REG_ARM_ID_AA64DFR0_EL1 is not present in 10.1? ARM64_SYS_REG(3, 0, 0, 5, 0)); -> KVM_REG_ARM_ID_AA64DFR0_EL1);

Yes, the commit in 10.1 def3f1c102 - arm/cpu: Store aa64dfr0/1 into the idregs array" changed moved the aa64dfr0(_AA64DFR0_EL1) out of this format, so there is no longer a reference to "ARM64_SYS_REG(3, 0, 0, 5, 0)" to replace with the macro.

ec4fb68 NVIDIA: SAUCE: NOMERGE: Add KVM Arm RME definitions to Linux headers Looks like you only took KVM_CAP_ARM_RME from this commit (and changed the value to be compatible with 6.16). Is that correct?

Correct, the 6.16 kernel added
KVM_CAP_ARM_EL2,
KVM_CAP_ARM_EL2_E2H0
KVM_CAP_RISCV_MP_STATE_RESET
The define for 'KVM_CAP_ARM_CACHEABLE_PFNMAP_SUPPORTED' was added in the 6.17 kernel. So we only need to modify KVM_CAP_ARM_RME to reflect what is set in the v9 arm64: Support for Arm CCA in KVM kernel series, which matches our kernel build.

nvmochs

Thanks for the quick turnaround. I confirmed your change to 'NVIDIA: SAUCE: target/arm/cpu: Set number of PMU counters in KVM'. No further comments from me.

Acked-by: Matthew R. Ochs <mochs@nvidia.com>

Create an event log in the format defined by Trusted Computing Group for TPM2. It contains information about the VMM, the Realm parameters, any data loaded into guest memory before boot, and the initial vCPU state. The guest can access this log from RAM and send it to a verifier, to help the verifier independently compute the Realm Initial Measurement, and check that the data we load into guest RAM is known-good images. Without this log, in order to end up with the right Measurement, the verifier needs to guess what is loaded, where and in what order. Cc: Stefan Berger <stefanb@linux.vnet.ibm.com> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> (cherry picked from commit c6f47fcd33cf73d2ba55cb4f4f6eaaedd144b2b7 https://git.codelinaro.org/linaro/dcap/qemu.git) Signed-off-by: Ian May <ianm@nvidia.com>

ianm-nv · 2025-10-09T15:56:06Z

Looks good to me. Minor comments below:

For eec7964 NVIDIA: SAUCE: target/arm/cpu: Set number of PMU counters in KVM You could use KVM_REG_ARM_PMCR_EL0 in kvm_arm_get_host_cpu_features(). Though it won't affect anything, will align with original.

Also the last hunk in a6b38db actually belongs to 83ef143 . Right? It may break the compile.

You are correct, I've adjusted the commits and amended that hunk into the correct commit. Thanks!

Create a measurement log describing operations performed by QEMU to initialize the guest, and load it into guest memory above the DTB. Cc: Stefan Berger <stefanb@linux.vnet.ibm.com> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> (cherry picked from commit 3d45ff0ff24f4713c09d6355cc39689cf46b329a https://git.codelinaro.org/linaro/dcap/qemu.git) Signed-off-by: Ian May <ianm@nvidia.com>

When plugging memory into a confidential guest, it starts as guest-private memory and doesn't need mappings in VFIO or vhost devices. When the guest decides to share this memory, the RAM discard listeners are notified. When the memory is unplugged, the guest first unshares the memory if necessary, again notifying the RAM discard listeners. So we don't need to install our own RAM discard listener. Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> (cherry picked from commit 705dfb84a8ee44042d8682ce2e56289ea8344b81 https://git.codelinaro.org/linaro/dcap/qemu.git) Signed-off-by: Ian May <ianm@nvidia.com>

Add a QMP command to retrieve CCA capabilities; supported on aarch64 platforms only. Signed-off-by: Kazuhiro Abe <fj1078ii@aa.jp.fujitsu.com> (cherry picked from commit ce93295d18cede59d0207b52eadf8c4962755674 https://git.codelinaro.org/linaro/dcap/qemu.git) Signed-off-by: Ian May <ianm@nvidia.com>

RME-DA requires knowledge of the virtual BDF that is assigned to an RME capable device. Register the BDF with kernel: - If the device is attached to the root-bus, register at the time the realm is activated. - If the device is attaches to a bridge, attempt registration when the config space is accessed. If the upstream device has the bus set and the BDF hasn't yet been registered, register the device. Signed-off-by: Arto Merilainen <amerilainen@nvidia.com> Signed-off-by: Ian May <ianm@nvidia.com>

Signed-off-by: Arto Merilainen <amerilainen@nvidia.com> Signed-off-by: Ian May <ianm@nvidia.com>

shamiali2008 · 2025-10-09T19:59:13Z

LGTM, Thanks.

Acked-by: Shameer Kolothum <skolothumtho@nvidia.com>

nvmochs · 2025-10-10T00:29:32Z

Merged, closing PR.

In stm32f250_soc_initfn() we mostly use the standard pattern for child objects of calling object_initialize_child(). However for s->adc_irqs we call object_new() and then later qdev_realize(), and we never unref the object on deinit. This causes a leak, detected by ASAN on the device-introspect-test: Indirect leak of 10 byte(s) in 1 object(s) allocated from: #0 0x5b9fc4789de3 in malloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/qemu-system-arm+0x21f1de3) (BuildId: 267a2619a026ed91c78a07b1eb2ef15381538efe) #1 0x740de3f28b09 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62b09) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75) NVIDIA#2 0x740de3f3e4d8 in g_strdup (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x784d8) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75) NVIDIA#3 0x5b9fc70159e1 in g_strdup_inline /usr/include/glib-2.0/glib/gstrfuncs.h:321:10 NVIDIA#4 0x5b9fc70159e1 in object_property_try_add /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:1276:18 NVIDIA#5 0x5b9fc7015f94 in object_property_add /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:1294:12 NVIDIA#6 0x5b9fc701b900 in object_add_link_prop /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:2021:10 NVIDIA#7 0x5b9fc701b3fc in object_property_add_link /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:2037:12 NVIDIA#8 0x5b9fc4c299fb in qdev_init_gpio_out_named /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/core/gpio.c:90:9 NVIDIA#9 0x5b9fc4c29b26 in qdev_init_gpio_out /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/core/gpio.c:101:5 NVIDIA#10 0x5b9fc4c0f77a in or_irq_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/core/or-irq.c:70:5 NVIDIA#11 0x5b9fc70257e1 in object_init_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:428:9 #12 0x5b9fc700cd4b in object_initialize_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:570:5 #13 0x5b9fc700e66d in object_new_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:774:5 #14 0x5b9fc700e750 in object_new /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:789:12 #15 0x5b9fc68b2162 in stm32f205_soc_initfn /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/arm/stm32f205_soc.c:69:26 Switch to using object_initialize_child() like all our other child objects for this SoC object. Cc: qemu-stable@nongnu.org Fixes: b63041c ("STM32F205: Connect the ADC devices") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20250821154229.2417453-1-peter.maydell@linaro.org (cherry picked from commit 2e27650) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit b6fdef9) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>

In pca9554_set_pin() we have a string property which we parse in order to set some non-string fields in the device state. So we call visit_type_str(), passing it the address of the local variable state_str. visit_type_str() will allocate a new copy of the string; we never free this string, so the result is a memory leak, detected by ASAN during a "make check" run: Direct leak of 5 byte(s) in 1 object(s) allocated from: #0 0x5d605212ede3 in malloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/qemu-system-arm+0x21f1de3) ( BuildId: 3d5373c89317f58bfcd191a33988c7347714be14) #1 0x7f7edea57b09 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62b09) (BuildId: 1eb6131419edb83b2178b68282 9a6913cf682d75) NVIDIA#2 0x7f7edea6d4d8 in g_strdup (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x784d8) (BuildId: 1eb6131419edb83b2178b68282 9a6913cf682d75) NVIDIA#3 0x5d6055289a91 in g_strdup_inline /usr/include/glib-2.0/glib/gstrfuncs.h:321:10 NVIDIA#4 0x5d6055289a91 in qobject_input_type_str /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qapi/qo bject-input-visitor.c:542:12 NVIDIA#5 0x5d605528479c in visit_type_str /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qapi/qapi-visit -core.c:349:10 NVIDIA#6 0x5d60528bdd87 in pca9554_set_pin /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/gpio/pca9554.c:179:10 NVIDIA#7 0x5d60549bcbbb in object_property_set /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:1450:5 NVIDIA#8 0x5d60549d2055 in object_property_set_qobject /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/qom-qobject.c:28:10 NVIDIA#9 0x5d60549bcdf1 in object_property_set_str /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:1458:15 NVIDIA#10 0x5d605439d077 in gb200nvl_bmc_i2c_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/arm/aspeed.c:1267:5 NVIDIA#11 0x5d60543a3bbc in aspeed_machine_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/arm/aspeed.c:493:9 Make the state_str g_autofree, so that we will always free it, on both error-exit and success codepaths. Cc: qemu-stable@nongnu.org Fixes: de0c7d5 ("misc: Add a pca9554 GPIO device model") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Glenn Miles <milesg@linux.ibm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20250821154459.2417976-1-peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 3284d1c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit d1d60d7) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>

In the max78000_uart we create a FIFO in the instance_init function, but we don't destroy it on deinit, so ASAN reports a leak in the device-introspect-test: #0 0x561cc92d5de3 in malloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/qemu-system-arm+0x21f1de3) (BuildId: 98fdf9fc85c3beaeca8eda0be8412f1e11b9c6ad) #1 0x70cbf2afab09 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62b09) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75) NVIDIA#2 0x561ccc4c884d in fifo8_create /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../util/fifo8.c:27:18 NVIDIA#3 0x561cc9744ec9 in max78000_uart_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/char/max78000_uart.c:241:5 Add an instance_finalize method to destroy the FIFO. Cc: qemu-stable@nongnu.org Fixes: d447e4b ("MAX78000: UART Implementation") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20250821154358.2417744-1-peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit ac6b124) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit 7527e29) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>

In the dino PCI host bridge device, we call pci_register_root_bus() in the device's instance_init. This is a problem for two reasons * the PCI bridge is then available to the rest of the simulation (e.g. via pci_qdev_find_device()), even though it hasn't yet been realized * we do not attempt to unregister in an instance_deinit, which means that if you go through an instance_init -> deinit lifecycle the freed memory for the host-bridge device is left on the pci_host_bridges list ASAN reports the resulting use-after-free: ==1771223==ERROR: AddressSanitizer: heap-use-after-free on address 0x527000018f80 at pc 0x5b4b9d3369b5 bp 0x7ffd01929980 sp 0x7ffd01929978 WRITE of size 8 at 0x527000018f80 thread T0 #0 0x5b4b9d3369b4 in pci_host_bus_register /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:608:5 #1 0x5b4b9d321566 in pci_root_bus_internal_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:677:5 NVIDIA#2 0x5b4b9d3215e0 in pci_root_bus_new /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:706:5 NVIDIA#3 0x5b4b9d321fe5 in pci_register_root_bus /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:751:11 NVIDIA#4 0x5b4b9d390521 in dino_pcihost_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci-host/dino.c:473:16 0x527000018f80 is located 1664 bytes inside of 12384-byte region [0x527000018900,0x52700001b960) freed by thread T0 here: #0 0x5b4b9cab185a in free (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/qemu-system-hppa+0x17ad85a) (BuildId: ca496bb2e4fc750ebd289b448bad8d99c0ecd140) #1 0x5b4b9e3ee723 in object_finalize /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:734:9 NVIDIA#2 0x5b4b9e3e69db in object_unref /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:1232:9 NVIDIA#3 0x5b4b9ea6173c in qmp_device_list_properties /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/qom-qmp-cmds.c:237:5 NVIDIA#4 0x5b4b9ec4e0f3 in qmp_marshal_device_list_properties /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/qapi/qapi-commands-qdev.c:65:14 previously allocated by thread T0 here: #0 0x5b4b9cab1af3 in malloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/qemu-system-hppa+0x17adaf3) (BuildId: ca496bb2e4fc750ebd289b448bad8d99c0ecd140) #1 0x799d8270eb09 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62b09) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75) NVIDIA#2 0x5b4b9e3e75fc in object_new_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:767:15 NVIDIA#3 0x5b4b9e3e7409 in object_new_with_class /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:782:12 NVIDIA#4 0x5b4b9ea609a5 in qmp_device_list_properties /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/qom-qmp-cmds.c:206:11 where we allocated one instance of the dino device, put it on the list, freed it, and then trying to allocate a second instance touches the freed memory on the pci_host_bridges list. Fix this by deferring all the setup of memory regions and registering the PCI bridge to the device's realize method. This brings it into line with almost all other PCI host bridges, which call pci_register_root_bus() in realize. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3118 Fixes: 63901b6 ("dino: move PCI bus initialisation to dino_pcihost_init()") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20250918114259.1802337-2-peter.maydell@linaro.org> (cherry picked from commit e4a1b30) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit 975d8f3) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>

In the astro PCI host bridge device, we call pci_register_root_bus() in the device's instance_init. This is a problem for two reasons * the PCI bridge is then available to the rest of the simulation (e.g. via pci_qdev_find_device()), even though it hasn't yet been realized * we do not attempt to unregister in an instance_deinit, which means that if you go through an instance_init -> deinit lifecycle the freed memory for the host-bridge device is left on the pci_host_bridges list ASAN reports the resulting use-after-free: ==1776584==ERROR: AddressSanitizer: heap-use-after-free on address 0x51f00000cb00 at pc 0x5b2d460a89b5 bp 0x7ffef7617f50 sp 0x7ffef7617f48 WRITE of size 8 at 0x51f00000cb00 thread T0 #0 0x5b2d460a89b4 in pci_host_bus_register /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:608:5 #1 0x5b2d46093566 in pci_root_bus_internal_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:677:5 NVIDIA#2 0x5b2d460935e0 in pci_root_bus_new /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:706:5 NVIDIA#3 0x5b2d46093fe5 in pci_register_root_bus /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:751:11 NVIDIA#4 0x5b2d46fe2335 in elroy_pcihost_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci-host/astro.c:455:16 0x51f00000cb00 is located 1664 bytes inside of 3456-byte region [0x51f00000c480,0x51f00000d200) freed by thread T0 here: #0 0x5b2d4582385a in free (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/qemu-system-hppa+0x17ad85a) (BuildId: 692b49eedc6fb0ef618bbb6784a09311b3b7f1e8) #1 0x5b2d47160723 in object_finalize /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:734:9 NVIDIA#2 0x5b2d471589db in object_unref /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:1232:9 NVIDIA#3 0x5b2d477d373c in qmp_device_list_properties /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/qom-qmp-cmds.c:237:5 previously allocated by thread T0 here: #0 0x5b2d45823af3 in malloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/qemu-system-hppa+0x17adaf3) (BuildId: 692b49eedc6fb0ef618bbb6784a09311b3b7f1e8) #1 0x79728fa08b09 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62b09) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75) NVIDIA#2 0x5b2d471595fc in object_new_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:767:15 NVIDIA#3 0x5b2d47159409 in object_new_with_class /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:782:12 NVIDIA#4 0x5b2d477d29a5 in qmp_device_list_properties /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/qom-qmp-cmds.c:206:11 Cc: qemu-stable@nongnu.org Fixes: e029bb0 ("hw/pci-host: Add Astro system bus adapter found on PA-RISC machines") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3118 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20250918114259.1802337-3-peter.maydell@linaro.org> (cherry picked from commit 76d2b8d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit bbb31ac) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>

When we unrealize a CPU object (which happens on vCPU hot-unplug), we should destroy all the AddressSpace objects we created via calls to cpu_address_space_init() when the CPU was realized. Commit 24bec42 added a function to do this for a specific AddressSpace, but did not add any places where the function was called. Since we always want to destroy all the AddressSpaces on unrealize, regardless of the target architecture, we don't need to try to keep track of how many are still undestroyed, or make the target architecture code manually call a destroy function for each AS it created. Instead we can adjust the function to always completely destroy the whole cpu->ases array, and arrange for it to be called during CPU unrealize as part of the common code. Without this fix, AddressSanitizer will report a leak like this from a run where we hot-plugged and then hot-unplugged an x86 KVM vCPU: Direct leak of 416 byte(s) in 1 object(s) allocated from: #0 0x5b638565053d in calloc (/data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/qemu-system-x86_64+0x1ee153d) (BuildId: c1cd6022b195142106e1bffeca23498c2b752bca) #1 0x7c28083f77b1 in g_malloc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x637b1) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75) NVIDIA#2 0x5b6386999c7c in cpu_address_space_init /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../system/physmem.c:797:25 NVIDIA#3 0x5b638727f049 in kvm_cpu_realizefn /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../target/i386/kvm/kvm-cpu.c:102:5 NVIDIA#4 0x5b6385745f40 in accel_cpu_common_realize /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../accel/accel-common.c:101:13 NVIDIA#5 0x5b638568fe3c in cpu_exec_realizefn /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../hw/core/cpu-common.c:232:10 NVIDIA#6 0x5b63874a2cd5 in x86_cpu_realizefn /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../target/i386/cpu.c:9321:5 NVIDIA#7 0x5b6387a0469a in device_set_realized /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../hw/core/qdev.c:494:13 NVIDIA#8 0x5b6387a27d9e in property_set_bool /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../qom/object.c:2375:5 NVIDIA#9 0x5b6387a2090b in object_property_set /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../qom/object.c:1450:5 NVIDIA#10 0x5b6387a35b05 in object_property_set_qobject /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../qom/qom-qobject.c:28:10 NVIDIA#11 0x5b6387a21739 in object_property_set_bool /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../qom/object.c:1520:15 #12 0x5b63879fe510 in qdev_realize /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../hw/core/qdev.c:276:12 Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2517 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: David Hildenbrand <david@redhat.com> Link: https://lore.kernel.org/r/20250929144228.1994037-4-peter.maydell@linaro.org Signed-off-by: Peter Xu <peterx@redhat.com> (cherry picked from commit 300a87c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit 7bd98c6) Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>

In stm32f250_soc_initfn() we mostly use the standard pattern for child objects of calling object_initialize_child(). However for s->adc_irqs we call object_new() and then later qdev_realize(), and we never unref the object on deinit. This causes a leak, detected by ASAN on the device-introspect-test: Indirect leak of 10 byte(s) in 1 object(s) allocated from: #0 0x5b9fc4789de3 in malloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/qemu-system-arm+0x21f1de3) (BuildId: 267a2619a026ed91c78a07b1eb2ef15381538efe) #1 0x740de3f28b09 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62b09) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75) #2 0x740de3f3e4d8 in g_strdup (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x784d8) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75) NVIDIA#3 0x5b9fc70159e1 in g_strdup_inline /usr/include/glib-2.0/glib/gstrfuncs.h:321:10 NVIDIA#4 0x5b9fc70159e1 in object_property_try_add /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:1276:18 NVIDIA#5 0x5b9fc7015f94 in object_property_add /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:1294:12 NVIDIA#6 0x5b9fc701b900 in object_add_link_prop /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:2021:10 NVIDIA#7 0x5b9fc701b3fc in object_property_add_link /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:2037:12 NVIDIA#8 0x5b9fc4c299fb in qdev_init_gpio_out_named /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/core/gpio.c:90:9 NVIDIA#9 0x5b9fc4c29b26 in qdev_init_gpio_out /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/core/gpio.c:101:5 NVIDIA#10 0x5b9fc4c0f77a in or_irq_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/core/or-irq.c:70:5 NVIDIA#11 0x5b9fc70257e1 in object_init_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:428:9 #12 0x5b9fc700cd4b in object_initialize_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:570:5 #13 0x5b9fc700e66d in object_new_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:774:5 #14 0x5b9fc700e750 in object_new /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:789:12 #15 0x5b9fc68b2162 in stm32f205_soc_initfn /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/arm/stm32f205_soc.c:69:26 Switch to using object_initialize_child() like all our other child objects for this SoC object. Cc: qemu-stable@nongnu.org Fixes: b63041c ("STM32F205: Connect the ADC devices") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20250821154229.2417453-1-peter.maydell@linaro.org (cherry picked from commit 2e27650) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

In pca9554_set_pin() we have a string property which we parse in order to set some non-string fields in the device state. So we call visit_type_str(), passing it the address of the local variable state_str. visit_type_str() will allocate a new copy of the string; we never free this string, so the result is a memory leak, detected by ASAN during a "make check" run: Direct leak of 5 byte(s) in 1 object(s) allocated from: #0 0x5d605212ede3 in malloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/qemu-system-arm+0x21f1de3) ( BuildId: 3d5373c89317f58bfcd191a33988c7347714be14) #1 0x7f7edea57b09 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62b09) (BuildId: 1eb6131419edb83b2178b68282 9a6913cf682d75) #2 0x7f7edea6d4d8 in g_strdup (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x784d8) (BuildId: 1eb6131419edb83b2178b68282 9a6913cf682d75) NVIDIA#3 0x5d6055289a91 in g_strdup_inline /usr/include/glib-2.0/glib/gstrfuncs.h:321:10 NVIDIA#4 0x5d6055289a91 in qobject_input_type_str /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qapi/qo bject-input-visitor.c:542:12 NVIDIA#5 0x5d605528479c in visit_type_str /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qapi/qapi-visit -core.c:349:10 NVIDIA#6 0x5d60528bdd87 in pca9554_set_pin /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/gpio/pca9554.c:179:10 NVIDIA#7 0x5d60549bcbbb in object_property_set /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:1450:5 NVIDIA#8 0x5d60549d2055 in object_property_set_qobject /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/qom-qobject.c:28:10 NVIDIA#9 0x5d60549bcdf1 in object_property_set_str /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../qom/object.c:1458:15 NVIDIA#10 0x5d605439d077 in gb200nvl_bmc_i2c_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/arm/aspeed.c:1267:5 NVIDIA#11 0x5d60543a3bbc in aspeed_machine_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/arm/aspeed.c:493:9 Make the state_str g_autofree, so that we will always free it, on both error-exit and success codepaths. Cc: qemu-stable@nongnu.org Fixes: de0c7d5 ("misc: Add a pca9554 GPIO device model") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Glenn Miles <milesg@linux.ibm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20250821154459.2417976-1-peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit 3284d1c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

In the max78000_uart we create a FIFO in the instance_init function, but we don't destroy it on deinit, so ASAN reports a leak in the device-introspect-test: #0 0x561cc92d5de3 in malloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/qemu-system-arm+0x21f1de3) (BuildId: 98fdf9fc85c3beaeca8eda0be8412f1e11b9c6ad) #1 0x70cbf2afab09 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62b09) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75) #2 0x561ccc4c884d in fifo8_create /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../util/fifo8.c:27:18 NVIDIA#3 0x561cc9744ec9 in max78000_uart_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/arm-asan/../../hw/char/max78000_uart.c:241:5 Add an instance_finalize method to destroy the FIFO. Cc: qemu-stable@nongnu.org Fixes: d447e4b ("MAX78000: UART Implementation") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20250821154358.2417744-1-peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit ac6b124) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

In the dino PCI host bridge device, we call pci_register_root_bus() in the device's instance_init. This is a problem for two reasons * the PCI bridge is then available to the rest of the simulation (e.g. via pci_qdev_find_device()), even though it hasn't yet been realized * we do not attempt to unregister in an instance_deinit, which means that if you go through an instance_init -> deinit lifecycle the freed memory for the host-bridge device is left on the pci_host_bridges list ASAN reports the resulting use-after-free: ==1771223==ERROR: AddressSanitizer: heap-use-after-free on address 0x527000018f80 at pc 0x5b4b9d3369b5 bp 0x7ffd01929980 sp 0x7ffd01929978 WRITE of size 8 at 0x527000018f80 thread T0 #0 0x5b4b9d3369b4 in pci_host_bus_register /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:608:5 #1 0x5b4b9d321566 in pci_root_bus_internal_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:677:5 #2 0x5b4b9d3215e0 in pci_root_bus_new /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:706:5 NVIDIA#3 0x5b4b9d321fe5 in pci_register_root_bus /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:751:11 NVIDIA#4 0x5b4b9d390521 in dino_pcihost_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci-host/dino.c:473:16 0x527000018f80 is located 1664 bytes inside of 12384-byte region [0x527000018900,0x52700001b960) freed by thread T0 here: #0 0x5b4b9cab185a in free (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/qemu-system-hppa+0x17ad85a) (BuildId: ca496bb2e4fc750ebd289b448bad8d99c0ecd140) #1 0x5b4b9e3ee723 in object_finalize /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:734:9 #2 0x5b4b9e3e69db in object_unref /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:1232:9 NVIDIA#3 0x5b4b9ea6173c in qmp_device_list_properties /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/qom-qmp-cmds.c:237:5 NVIDIA#4 0x5b4b9ec4e0f3 in qmp_marshal_device_list_properties /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/qapi/qapi-commands-qdev.c:65:14 previously allocated by thread T0 here: #0 0x5b4b9cab1af3 in malloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/qemu-system-hppa+0x17adaf3) (BuildId: ca496bb2e4fc750ebd289b448bad8d99c0ecd140) #1 0x799d8270eb09 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62b09) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75) #2 0x5b4b9e3e75fc in object_new_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:767:15 NVIDIA#3 0x5b4b9e3e7409 in object_new_with_class /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:782:12 NVIDIA#4 0x5b4b9ea609a5 in qmp_device_list_properties /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/qom-qmp-cmds.c:206:11 where we allocated one instance of the dino device, put it on the list, freed it, and then trying to allocate a second instance touches the freed memory on the pci_host_bridges list. Fix this by deferring all the setup of memory regions and registering the PCI bridge to the device's realize method. This brings it into line with almost all other PCI host bridges, which call pci_register_root_bus() in realize. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3118 Fixes: 63901b6 ("dino: move PCI bus initialisation to dino_pcihost_init()") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20250918114259.1802337-2-peter.maydell@linaro.org> (cherry picked from commit e4a1b30) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

In the astro PCI host bridge device, we call pci_register_root_bus() in the device's instance_init. This is a problem for two reasons * the PCI bridge is then available to the rest of the simulation (e.g. via pci_qdev_find_device()), even though it hasn't yet been realized * we do not attempt to unregister in an instance_deinit, which means that if you go through an instance_init -> deinit lifecycle the freed memory for the host-bridge device is left on the pci_host_bridges list ASAN reports the resulting use-after-free: ==1776584==ERROR: AddressSanitizer: heap-use-after-free on address 0x51f00000cb00 at pc 0x5b2d460a89b5 bp 0x7ffef7617f50 sp 0x7ffef7617f48 WRITE of size 8 at 0x51f00000cb00 thread T0 #0 0x5b2d460a89b4 in pci_host_bus_register /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:608:5 #1 0x5b2d46093566 in pci_root_bus_internal_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:677:5 #2 0x5b2d460935e0 in pci_root_bus_new /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:706:5 NVIDIA#3 0x5b2d46093fe5 in pci_register_root_bus /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci/pci.c:751:11 NVIDIA#4 0x5b2d46fe2335 in elroy_pcihost_init /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../hw/pci-host/astro.c:455:16 0x51f00000cb00 is located 1664 bytes inside of 3456-byte region [0x51f00000c480,0x51f00000d200) freed by thread T0 here: #0 0x5b2d4582385a in free (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/qemu-system-hppa+0x17ad85a) (BuildId: 692b49eedc6fb0ef618bbb6784a09311b3b7f1e8) #1 0x5b2d47160723 in object_finalize /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:734:9 #2 0x5b2d471589db in object_unref /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:1232:9 NVIDIA#3 0x5b2d477d373c in qmp_device_list_properties /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/qom-qmp-cmds.c:237:5 previously allocated by thread T0 here: #0 0x5b2d45823af3 in malloc (/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/qemu-system-hppa+0x17adaf3) (BuildId: 692b49eedc6fb0ef618bbb6784a09311b3b7f1e8) #1 0x79728fa08b09 in g_malloc (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x62b09) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75) #2 0x5b2d471595fc in object_new_with_type /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:767:15 NVIDIA#3 0x5b2d47159409 in object_new_with_class /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/object.c:782:12 NVIDIA#4 0x5b2d477d29a5 in qmp_device_list_properties /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/hppa-asan/../../qom/qom-qmp-cmds.c:206:11 Cc: qemu-stable@nongnu.org Fixes: e029bb0 ("hw/pci-host: Add Astro system bus adapter found on PA-RISC machines") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/3118 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20250918114259.1802337-3-peter.maydell@linaro.org> (cherry picked from commit 76d2b8d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

When we unrealize a CPU object (which happens on vCPU hot-unplug), we should destroy all the AddressSpace objects we created via calls to cpu_address_space_init() when the CPU was realized. Commit 24bec42 added a function to do this for a specific AddressSpace, but did not add any places where the function was called. Since we always want to destroy all the AddressSpaces on unrealize, regardless of the target architecture, we don't need to try to keep track of how many are still undestroyed, or make the target architecture code manually call a destroy function for each AS it created. Instead we can adjust the function to always completely destroy the whole cpu->ases array, and arrange for it to be called during CPU unrealize as part of the common code. Without this fix, AddressSanitizer will report a leak like this from a run where we hot-plugged and then hot-unplugged an x86 KVM vCPU: Direct leak of 416 byte(s) in 1 object(s) allocated from: #0 0x5b638565053d in calloc (/data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/qemu-system-x86_64+0x1ee153d) (BuildId: c1cd6022b195142106e1bffeca23498c2b752bca) #1 0x7c28083f77b1 in g_malloc0 (/lib/x86_64-linux-gnu/libglib-2.0.so.0+0x637b1) (BuildId: 1eb6131419edb83b2178b682829a6913cf682d75) #2 0x5b6386999c7c in cpu_address_space_init /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../system/physmem.c:797:25 NVIDIA#3 0x5b638727f049 in kvm_cpu_realizefn /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../target/i386/kvm/kvm-cpu.c:102:5 NVIDIA#4 0x5b6385745f40 in accel_cpu_common_realize /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../accel/accel-common.c:101:13 NVIDIA#5 0x5b638568fe3c in cpu_exec_realizefn /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../hw/core/cpu-common.c:232:10 NVIDIA#6 0x5b63874a2cd5 in x86_cpu_realizefn /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../target/i386/cpu.c:9321:5 NVIDIA#7 0x5b6387a0469a in device_set_realized /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../hw/core/qdev.c:494:13 NVIDIA#8 0x5b6387a27d9e in property_set_bool /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../qom/object.c:2375:5 NVIDIA#9 0x5b6387a2090b in object_property_set /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../qom/object.c:1450:5 NVIDIA#10 0x5b6387a35b05 in object_property_set_qobject /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../qom/qom-qobject.c:28:10 NVIDIA#11 0x5b6387a21739 in object_property_set_bool /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../qom/object.c:1520:15 #12 0x5b63879fe510 in qdev_realize /data_nvme1n1/linaro/qemu-from-laptop/qemu/build/x86-tgts-asan/../../hw/core/qdev.c:276:12 Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2517 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: David Hildenbrand <david@redhat.com> Link: https://lore.kernel.org/r/20250929144228.1994037-4-peter.maydell@linaro.org Signed-off-by: Peter Xu <peterx@redhat.com> (cherry picked from commit 300a87c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

Display the CPU model in 'info cpus'. Example before: $ qemu-system-aarch64 -M xlnx-versal-virt -S -monitor stdio QEMU 10.0.0 monitor - type 'help' for more information (qemu) info cpus * CPU #0: thread_id=42924 CPU NVIDIA#1: thread_id=42924 CPU NVIDIA#2: thread_id=42924 CPU NVIDIA#3: thread_id=42924 (qemu) q and after: $ qemu-system-aarch64 -M xlnx-versal-virt -S -monitor stdio QEMU 10.0.50 monitor - type 'help' for more information (qemu) info cpus * CPU #0: thread_id=42916 model=cortex-a72 CPU NVIDIA#1: thread_id=42916 model=cortex-a72 CPU NVIDIA#2: thread_id=42916 model=cortex-r5f CPU NVIDIA#3: thread_id=42916 model=cortex-r5f (qemu) Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Zhao Liu <zhao1.liu@intel.com> Tested-by: Zhao Liu <zhao1.liu@intel.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Message-Id: <20250715090624.52377-3-philmd@linaro.org>

nvmochs and others added 15 commits October 7, 2025 17:43

NVIDIA: SAUCE: Indicate this is the -unstable branch of NVIDIA QEMU

05c03e7

Add -unstable to version string. Signed-off-by: Matthew R. Ochs <mochs@nvidia.com>

nvmochs self-requested a review October 8, 2025 18:57

nvmochs reviewed Oct 8, 2025

View reviewed changes

jpbrucker added 13 commits October 8, 2025 13:27

ianm-nv force-pushed the nvidia_unstable-10.1+cca/latest branch from 3e1ffee to 894b8fc Compare October 9, 2025 13:44

nvmochs self-requested a review October 9, 2025 14:28

nvmochs approved these changes Oct 9, 2025

View reviewed changes

ianm-nv force-pushed the nvidia_unstable-10.1+cca/latest branch from 894b8fc to 9e1b5fc Compare October 9, 2025 15:39

jpbrucker and others added 5 commits October 9, 2025 11:14

NVIDIA: SAUCE: hw/arm/virt: Define MEC as shared or private

9aff544

Signed-off-by: Arto Merilainen <amerilainen@nvidia.com> Signed-off-by: Ian May <ianm@nvidia.com>

ianm-nv force-pushed the nvidia_unstable-10.1+cca/latest branch from 9e1b5fc to 9aff544 Compare October 9, 2025 18:15

nvmochs closed this Oct 10, 2025

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Add Arm CCA support #2

Add Arm CCA support #2

Uh oh!

ianm-nv commented Oct 8, 2025

Uh oh!

nvmochs left a comment

Uh oh!

shamiali2008 commented Oct 9, 2025

Uh oh!

ianm-nv commented Oct 9, 2025

Uh oh!

nvmochs left a comment

Uh oh!

ianm-nv commented Oct 9, 2025

Uh oh!

shamiali2008 commented Oct 9, 2025

Uh oh!

nvmochs commented Oct 10, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Add Arm CCA support #2

Add Arm CCA support #2

Uh oh!

Conversation

ianm-nv commented Oct 8, 2025

Uh oh!

nvmochs left a comment

Choose a reason for hiding this comment

Uh oh!

shamiali2008 commented Oct 9, 2025

Uh oh!

ianm-nv commented Oct 9, 2025

Uh oh!

nvmochs left a comment

Choose a reason for hiding this comment

Uh oh!

ianm-nv commented Oct 9, 2025

Uh oh!

shamiali2008 commented Oct 9, 2025

Uh oh!

nvmochs commented Oct 10, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants