aboutsummaryrefslogtreecommitdiff
path: root/hw/arm
AgeCommit message (Collapse)AuthorFilesLines
2024-09-16aspeed: Add tmp105 in i2c bus 0 for AST2700Jamin Lin1-0/+10
ASPEED SDK add lm75 in i2c bus 0 for AST2700. LM75 is compatible with TMP105 driver. Introduce a new i2c init function and add tmp105 device model in i2c bus 0. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com>
2024-09-16aspeed/soc: Support I2C for AST2700Jamin Lin1-0/+24
Add I2C model for AST2700 I2C support. The I2C controller registers base address is start at 0x14C0_F000 and its address space is 0x2000. The AST2700 I2C controller has one source INTC per bus. I2C buses interrupt are connected to GICINT130_INTC from bit 0 to bit 15. I2C bus 0 is connected to GICINT130_INTC at bit 0. I2C bus 15 is connected to GICINT130_INTC at bit 15. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com>
2024-09-16aspeed/soc: Introduce a new API to get the device irqJamin Lin1-0/+21
Currently, users can set the INTC mapping table with enumerated device id and device irq to get the INTC orgate input pins. However, some devices use the continuous source numbers in the same INTC orgate. To reduce the enumerated device id definition, create a new API to get the INTC orgate input pin if users only provide the device id with its bus number index. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com>
2024-09-13hvf: arm: Implement and use hvf_get_physical_address_rangeDanny Canter1-1/+30
This patch's main focus is to use the previously added hvf_get_physical_address_range to inform VM creation about the IPA size we need for the VM, so we can extend the default 36b IPA size and support VMs with 64+GB of RAM. This is done by freezing the memory map, computing the highest GPA and then (depending on if the platform supports an IPA size that large) telling the kernel to use a size >= for the VM. In pursuit of this a couple of things related to how we handle the physical address range we expose to guests were altered, but for an explanation of what we were doing: Today, to get the IPA size we were reading id_aa64mmfr0_el1's PARange field from a newly made vcpu. Unfortunately, HVF just returns the hosts PARange directly for the initial value and not the IPA size that will actually back the VM, so we believe we have much more address space than we actually do today it seems. Starting in macOS 13.0 some APIs were introduced to be able to query the maximum IPA size the kernel supports, and to set the IPA size for a given VM. However, this still has a couple of issues on < macOS 15. Up until macOS 15 (and if the hardware supported it) the max IPA size was 39 bits which is not a valid PARange value, so we can't clamp down what we advertise in the vcpu's id_aa64mmfr0_el1 to our IPA size. Starting in macOS 15 however, the maximum IPA size is 40 bits (if it's supported in the hardware as well) which is also a valid PARange value so we can set our IPA size to the maximum as well as clamp down the PARange we advertise to the guest. This allows VMs with 64+ GB of RAM and should fix the oddness of the PARange situation as well. Signed-off-by: Danny Canter <danny_canter@apple.com> Message-id: 20240828111552.93482-4-danny_canter@apple.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-09-13hw/boards: Add hvf_get_physical_address_range to MachineClassDanny Canter1-1/+8
This addition will be necessary for some HVF related work to follow. For HVF on ARM there exists a set of APIs in macOS 13 to be able to adjust the IPA size for a given VM. This is useful as by default HVF uses 36 bits as the IPA size, so to support guests with > 64GB of RAM we'll need to reach for this. To have all the info necessary to carry this out however, we need some plumbing to be able to grab the memory map and compute the highest GPA prior to creating the VM. This is almost exactly like what kvm_type is used for on ARM today, and is also what this will be used for. We will compute the highest GPA and find what IPA size we'd need to satisfy this, and if it's valid (macOS today caps at 40b) we'll set this to be the IPA size in coming patches. This new method is only needed (today at least) on ARM, and obviously only for HVF/macOS, so admittedly it is much less generic than kvm_type today, but it seemed a somewhat sane way to get the information we need from the memmap at VM creation time. Signed-off-by: Danny Canter <danny_canter@apple.com> Message-id: 20240828111552.93482-2-danny_canter@apple.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [PMM: removed explicit setting of field to NULL on x86] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-09-13hw: Use device_class_set_legacy_reset() instead of opencodingPeter Maydell5-9/+9
Use device_class_set_legacy_reset() instead of opencoding an assignment to DeviceClass::reset. This change was produced with: spatch --macro-file scripts/cocci-macro-file.h \ --sp-file scripts/coccinelle/device-reset.cocci \ --keep-comments --smpl-spacing --in-place --dir hw Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20240830145812.1967042-8-peter.maydell@linaro.org
2024-09-06Merge tag 'pull-target-arm-20240905' of ↵Peter Maydell5-20/+32
https://git.linaro.org/people/pmaydell/qemu-arm into staging target-arm queue: * Implement FEAT_EBF16 emulation * accel/tcg: Remove dead code from rr_cpu_thread_fn() * hw: add compat machines for 9.2 * virt: default to two-stage SMMU from virt-9.2 * sbsa-ref: use two-stage SMMU * hw: Various minor memory leak fixes * target/arm: Correct names of VFP VFNMA and VFNMS insns * hw/arm/xilinx_zynq: Enable Security Extensions * hw/arm/boot: Report error msg if loading elf/dtb failed # -----BEGIN PGP SIGNATURE----- # # iQJNBAABCAA3FiEE4aXFk81BneKOgxXPPCUl7RQ2DN4FAmbZqzEZHHBldGVyLm1h # eWRlbGxAbGluYXJvLm9yZwAKCRA8JSXtFDYM3lJ7D/9s/ZTkiCj/z+caHotwNJVt # ECgEEVinitwZxSMINZd1f6bxTY8hYVjMewj6A6RvHtMJMr7SUOmL8wi0YlbhTm44 # jb8dZVf3pzPaZ399jxOeGnFipGyKmK0XM5rKc7CP6yJUS3B9RkUbLEHng8Q0ZBtl # cnZqI12jJBdtHU8D4JIvBgM2N2ay4bKY8EQEPCv4S7ZTKawWcKgSR5pMd2TBIqIT # 0gaDL3eOgCt2XWIrMzRjvaJK70obN/+n+vZQskJ/sIDsw+Kz8sZGlivdBXLRmQ+A # OUgtdyZoD42Q8KtwM0bjoaoxz6VMNPJp5khB45EPjVgWyeyJ0L6ZcWCX7nT4hZsi # 1C0NJaJU6HQbfsPiMIGxgHYJCbQue/mVBE02MPhmN8fZlsTRKWT9Miu67S0PI5Ib # ZWo88Ew1coucBm25K2NWdoR3dCP8EFnxqL556L8M4iDWYQ/djf8cpFAN9QJBFrNw # CaXS+vxIFUjZ6TSjf8gOYPAONmAg5DsCucgyO4MBKnvlY5h2J+GTq/FC+kWzL9jE # UfhqOWSP34ol2lg319zOtKg4Ga+GOivo2DmgWQhDwZ2rmRR+xgN8rkQjpJKIT5Zj # Ji+ucJrghBZ0sN622QYG0u0Ap9Jy4KCOxcFfS1b4gNhmMDWg27Tx9tIguXmjOE3M # aAs4wmm4Nz4kpsf1KkB11Q== # =gZuf # -----END PGP SIGNATURE----- # gpg: Signature made Thu 05 Sep 2024 13:59:29 BST # gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE # gpg: issuer "peter.maydell@linaro.org" # gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [ultimate] # gpg: aka "Peter Maydell <pmaydell@gmail.com>" [ultimate] # gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [ultimate] # gpg: aka "Peter Maydell <peter@archaic.org.uk>" [ultimate] # Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE * tag 'pull-target-arm-20240905' of https://git.linaro.org/people/pmaydell/qemu-arm: (25 commits) platform-bus: fix refcount leak hw/arm/boot: Explain why load_elf_hdr() error is ignored hw/arm/boot: Report error msg if loading elf/dtb failed hw/arm/xilinx_zynq: Enable Security Extensions target/arm: Correct names of VFP VFNMA and VFNMS insns hw/arm/sbsa-ref: Don't leak string in sbsa_fdt_add_gic_node() hm/nvram/xlnx-versal-efuse-ctrl: Call register_finalize_block hw/misc/xlnx-versal-trng: Call register_finalize_block hw/nvram/xlnx-zynqmp-efuse: Call register_finalize_block hw/nvram/xlnx-bbram: Call register_finalize_block hw/misc/xlnx-versal-trng: Free s->prng in finalize, not unrealize hw/misc/xlnx-versal-cfu: destroy fifo in finalize hw/arm/sbsa-ref: Use two-stage SMMU hw/arm/virt: Default to two-stage SMMU from virt-9.2 hw/arm/smmuv3: Update comment documenting "stage" property hw: add compat machines for 9.2 accel/tcg: Remove dead code from rr_cpu_thread_fn() target/arm: Enable FEAT_EBF16 in the "max" CPU target/arm: Implement FPCR.EBF=1 semantics for bfdotadd() target/arm: Prepare bfdotadd() callers for FEAT_EBF support ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-09-05hw/arm/boot: Explain why load_elf_hdr() error is ignoredPhilippe Mathieu-Daudé1-2/+6
If the file is not an ELF file, arm_setup_direct_kernel_boot() falls back to try it as a uimage or an AArch64 Image file or as last resort a bare raw binary. We can discard load_elf_hdr() error and silently return. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20240903144154.17135-1-philmd@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
2024-09-05hw/arm/boot: Report error msg if loading elf/dtb failedChangbin Du1-0/+2
Print errors before exit. Do not exit silently. Cc: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Changbin Du <changbin.du@huawei.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20240903133940.3447430-1-changbin.du@huawei.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-09-05hw/arm/xilinx_zynq: Enable Security ExtensionsSebastian Huber1-8/+0
The system supports the Security Extensions (core and GIC). This change is necessary to run tests which pass on the real hardware. Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Tested-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Message-id: 20240828005019.57705-1-sebastian.huber@embedded-brains.de Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-09-05hw/arm/sbsa-ref: Don't leak string in sbsa_fdt_add_gic_node()Peter Maydell1-9/+6
In sbsa_fdt_add_gic_node() we g_strdup_printf() two nodename strings, but only free one. Since the string is actually entirely constant and we don't make any use of printf's format-string operations, we can drop the g_strdup_printf() use entirely. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Gavin Shan <gshan@redhat.com> Message-id: 20240822162323.706382-1-peter.maydell@linaro.org
2024-09-05hw/arm/sbsa-ref: Use two-stage SMMUPeter Maydell1-0/+1
Now that our SMMU model supports enabling both stages of translation at once, we can enable this in the sbsa-ref board. Existing guest code that only programs stage 1 and doesn't care about stage 2 should continue to run with the same behaviour, but guests that do want to do nested SMMU configurations can now do so. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org> Message-id: 20240816161350.3706332-5-peter.maydell@linaro.org
2024-09-05hw/arm/virt: Default to two-stage SMMU from virt-9.2Peter Maydell1-0/+8
Now that our SMMU model supports enabling both stages of translation at once, we can enable this in the virt board. This is no change in behaviour for guests, because if they simply ignore stage 2 and never configure it then it has no effect. For the usual backwards compatibility reasons we enable this only for machine types starting with 9.2. (Note that the SMMU is disabled by default on the virt board and is only created if the user passes the 'iommu=smmuv3' machine option.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-id: 20240816161350.3706332-4-peter.maydell@linaro.org
2024-09-05hw/arm/smmuv3: Update comment documenting "stage" propertyPeter Maydell1-0/+1
When we added support for nested (stage 1 + stage 2) translation to the SMMU in commit 58377c363291d we forgot to update the comment that documents the valid values of the "stage" property. Add the new "nested" value to it. Fixes: 58377c363291d ("hw/arm/smmuv3: Support and advertise nesting") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-id: 20240816161350.3706332-3-peter.maydell@linaro.org
2024-09-05hw: add compat machines for 9.2Cornelia Huck1-1/+8
Add 9.2 machine types for arm/i440fx/m68k/q35/s390x/spapr. Signed-off-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20240816161350.3706332-2-peter.maydell@linaro.org Message-id: 20240816103723.2325982-1-cohuck@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-09-04hw/arm: xenpvh: Rename xen_arm.c -> xen-pvh.cEdgar E. Iglesias2-1/+1
Rename xen_arm.c -> xen-pvh.c to better express that this is a PVH machine and to align with x86 HVM and future PVH machine filenames: hw/i386/xen/xen-hvm.c hw/i386/xen/xen-pvh.c (in preparation) No functional changes. Signed-off-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
2024-09-04hw/arm: xenpvh: Break out a common PVH machineEdgar E. Iglesias2-184/+19
Break out a common Xen PVH machine in preparation for adding a x86 Xen PVH machine. Signed-off-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
2024-09-04hw/arm: xenpvh: Move stubbed functions to xen-stubs.cEdgar E. Iglesias3-21/+36
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
2024-09-04hw/arm: xenpvh: Remove double-negation in warningEdgar E. Iglesias1-1/+1
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
2024-09-04hw/arm: xenpvh: Add support for SMP guestsEdgar E. Iglesias1-2/+21
Add SMP support for Xen PVH ARM guests. Create ms->smp.max_cpus ioreq servers to handle hotplug. Note that ms->smp.max_cpus will be passed to us by the user (Xen tools) set to the guests maxvcpus. The value in mc->max_cpus is an absolute maximum for the -smp option and won't be used to setup ioreq servers unless the user explicitly specifies it with -smp. If the user doesn't pass -smp on the command-line, smp.cpus and smp.max_cpus will default to 1. Signed-off-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
2024-09-04hw/arm: xenpvh: Tweak machine descriptionEdgar E. Iglesias1-1/+1
Tweak machine description to better express that this is a Xen PVH machine for ARM. Signed-off-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
2024-09-04hw/arm: xenpvh: Update file header to use SPDXEdgar E. Iglesias1-18/+1
Update file header to use SPDX and remove stray empty comment line. No functional changes. Signed-off-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Acked-by: Stefano Stabellini <sstabellini@kernel.org>
2024-08-16docs: Fix some typos (found by typos) and grammar issuesStefan Weil1-1/+1
Fix the misspellings of "overriden" also in code comments. Signed-off-by: Stefan Weil <sw@weilnetz.de> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20240813125638.395461-1-sw@weilnetz.de> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20240813202329.1237572-20-alex.bennee@linaro.org>
2024-08-12arm/virt: place power button pin number on a defineMauro Carvalho Chehab2-6/+7
Having magic numbers inside the code is not a good idea, as it is error-prone. So, instead, create a macro with the number definition. Link: https://lore.kernel.org/qemu-devel/CAFEAcA-PYnZ-32MRX+PgvzhnoAV80zBKMYg61j2f=oHaGfwSsg@mail.gmail.com/ Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-id: ef0e7f5fca6cd94eda415ecee670c3028c671b74.1723121692.git.mchehab+huawei@kernel.org Suggested-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-08-01hw/arm/mps2-tz.c: fix RX/TX interrupts orderMarco Palumbi1-3/+3
The order of the RX and TX interrupts are swapped. This commit fixes the order as per the following documents: * https://developer.arm.com/documentation/dai0505/latest/ * https://developer.arm.com/documentation/dai0521/latest/ * https://developer.arm.com/documentation/dai0524/latest/ * https://developer.arm.com/documentation/dai0547/latest/ Cc: qemu-stable@nongnu.org Signed-off-by: Marco Palumbi <Marco.Palumbi@tii.ae> Message-id: 20240730073123.72992-1-marco@palumbi.it Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-07-29hw/arm/smmuv3: Assert input to oas2bits() is validMostafa Saleh1-1/+2
Coverity has spotted a possible problem with the OAS handling (CID 1558464), where the error return of oas2bits() -1 is not checked, which can cause an overflow in oas value. oas2bits() is only called with valid inputs, harden the function to assert that. Reported-By: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-id: 20240722103531.2377348-1-smostafa@google.com Link: https://lore.kernel.org/qemu-devel/CAFEAcA-H=n-3mHC+eL6YjfL1m+x+b+Fk3mkgZbN74WNxifFVow@mail.gmail.com/ Signed-off-by: Mostafa Saleh <smostafa@google.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-07-24Merge tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu ↵Richard Henderson1-0/+1
into staging virtio,pci,pc: features,fixes pci: Initial support for SPDM Responders cxl: Add support for scan media, feature commands, device patrol scrub control, DDR5 ECS control, firmware updates virtio: in-order support virtio-net: support for SR-IOV emulation (note: known issues on s390, might get reverted if not fixed) smbios: memory device size is now configurable per Machine cpu: architecture agnostic code to support vCPU Hotplug Fixes, cleanups all over the place. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # -----BEGIN PGP SIGNATURE----- # # iQFDBAABCAAtFiEEXQn9CHHI+FuUyooNKB8NuNKNVGkFAmae9l8PHG1zdEByZWRo # YXQuY29tAAoJECgfDbjSjVRp8fYH/impBH9nViO/WK48io4mLSkl0EUL8Y/xrMvH # zKFCKaXq8D96VTt1Z4EGKYgwG0voBKZaCEKYU/0ARGnSlSwxINQ8ROCnBWMfn2sx # yQt08EXVMznNLtXjc6U5zCoCi6SaV85GH40No3MUFXBQt29ZSlFqO/fuHGZHYBwS # wuVKvTjjNF4EsGt3rS4Qsv6BwZWMM+dE6yXpKWk68kR8IGp+6QGxkMbWt9uEX2Md # VuemKVnFYw0XGCGy5K+ZkvoA2DGpEw0QxVSOMs8CI55Oc9SkTKz5fUSzXXGo1if+ # M1CTjOPJu6pMym6gy6XpFa8/QioDA/jE2vBQvfJ64TwhJDV159s= # =k8e9 # -----END PGP SIGNATURE----- # gpg: Signature made Tue 23 Jul 2024 10:16:31 AM AEST # gpg: using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469 # gpg: issuer "mst@redhat.com" # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [undefined] # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [undefined] # gpg: WARNING: The key's User ID is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67 # Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469 * tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu: (61 commits) hw/nvme: Add SPDM over DOE support backends: Initial support for SPDM socket support hw/pci: Add all Data Object Types defined in PCIe r6.0 tests/acpi: Add expected ACPI AML files for RISC-V tests/qtest/bios-tables-test.c: Enable basic testing for RISC-V tests/acpi: Add empty ACPI data files for RISC-V tests/qtest/bios-tables-test.c: Remove the fall back path tests/acpi: update expected DSDT blob for aarch64 and microvm acpi/gpex: Create PCI link devices outside PCI root bridge tests/acpi: Allow DSDT acpi table changes for aarch64 hw/riscv/virt-acpi-build.c: Update the HID of RISC-V UART hw/riscv/virt-acpi-build.c: Add namespace devices for PLIC and APLIC virtio-iommu: Add trace point on virtio_iommu_detach_endpoint_from_domain hw/vfio/common: Add vfio_listener_region_del_iommu trace event virtio-iommu: Remove the end point on detach virtio-iommu: Free [host_]resv_ranges on unset_iommu_devices virtio-iommu: Remove probe_done Revert "virtio-iommu: Clear IOMMUDevice when VFIO device is unplugged" gdbstub: Add helper function to unregister GDB register space physmem: Add helper function to destroy CPU AddressSpace ... Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2024-07-22smbios: make memory device size configurable per MachineIgor Mammedov1-0/+1
Currently QEMU describes initial[1] RAM* in SMBIOS as a series of virtual DIMMs (capped at 16Gb max) using type 17 structure entries. Which is fine for the most cases. However when starting guest with terabytes of RAM this leads to too many memory device structures, which eventually upsets linux kernel as it reserves only 64K for these entries and when that border is crossed out it runs out of reserved memory. Instead of partitioning initial RAM on 16Gb DIMMs, use maximum possible chunk size that SMBIOS spec allows[2]. Which lets encode RAM in lower 31 bits of 32bit field (which amounts upto 2047Tb per DIMM). As result initial RAM will generate only one type 17 structure until host/guest reach ability to use more RAM in the future. Compat changes: We can't unconditionally change chunk size as it will break QEMU<->guest ABI (and migration). Thus introduce a new machine class field that would let older versioned machines to use legacy 16Gb chunks, while new(er) machine type[s] use maximum possible chunk size. PS: While it might seem to be risky to rise max entry size this large (much beyond of what current physical RAM modules support), I'd not expect it causing much issues, modulo uncovering bugs in software running within guest. And those should be fixed on guest side to handle SMBIOS spec properly, especially if guest is expected to support so huge RAM configs. In worst case, QEMU can reduce chunk size later if we would care enough about introducing a workaround for some 'unfixable' guest OS, either by fixing up the next machine type or giving users a CLI option to customize it. 1) Initial RAM - is RAM configured with help '-m SIZE' CLI option/ implicitly defined by machine. It doesn't include memory configured with help of '-device' option[s] (pcdimm,nvdimm,...) 2) SMBIOS 3.1.0 7.18.5 Memory Device — Extended Size PS: * tested on 8Tb host with RHEL6 guest, which seems to parse type 17 SMBIOS table entries correctly (according to 'dmidecode'). Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20240715122417.4059293-1-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2024-07-21aspeed: fix coding styleJamin Lin1-7/+14
Fix coding style issues from checkpatch.pl Test command: ./scripts/checkpatch.pl --no-tree -f hw/arm/aspeed.c Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com>
2024-07-21aspeed/soc: support ADC for AST2700Jamin Lin1-0/+12
Add ADC model for AST2700 ADC support. The ADC controller registers base address is start at 0x14C0_0000 and its address space is 0x1000. The ADC controller interrupt is connected to GICINT130_INTC group at bit 16. The GIC IRQ is 130. Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Reviewed-by: Cédric Le Goater <clg@redhat.com>
2024-07-21aspeed: Introduce a 'boot-emmc' machine optionCédric Le Goater1-0/+30
The default behavior of some Aspeed machines is to boot from the eMMC device, like the rainier-bmc. Others like ast2600-evb could also boot from eMMC if the HW strapping boot-from-eMMC bit was set. Add a property to set or unset this bit. This is useful to test boot images. For now, only activate this property on the ast2600-evb and rainier-bmc machines for which eMMC images are available or can be built. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Andrew Jeffery <andrew@codeconstruct.com.au> Tested-by: Andrew Jeffery <andrew@codeconstruct.com.au> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-07-21aspeed: Introduce a 'hw_strap1' machine attributeCédric Le Goater1-1/+5
To change default behavior of a machine and boot from eMMC, future changes will add a machine option to let the user configure the boot-from-eMMC HW strapping bit. Add a new machine attribute first. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Andrew Jeffery <andrew@codeconstruct.com.au> Tested-by: Andrew Jeffery <andrew@codeconstruct.com.au> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-07-21aspeed: Add boot-from-eMMC HW strapping bit to rainier-bmc machineCédric Le Goater1-1/+1
This value is taken from a running Rainier machine. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Andrew Jeffery <andrew@codeconstruct.com.au> Tested-by: Andrew Jeffery <andrew@codeconstruct.com.au> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-07-21aspeed: Tune eMMC device properties to reflect HW strappingCédric Le Goater1-4/+13
When the boot-from-eMMC HW strapping bit is set, use the 'boot-config' property to set the boot config register to boot from the first boot area partition of the eMMC device. Also set the boot partition size of the device. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Andrew Jeffery <andrew@codeconstruct.com.au> Tested-by: Andrew Jeffery <andrew@codeconstruct.com.au> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-07-21aspeed: Introduce a AspeedSoCClass 'boot_from_emmc' handlerCédric Le Goater2-0/+15
Report support on the AST2600 SoC if the boot-from-eMMC HW strapping bit is set at the board level. AST2700 also has support but it is not yet ready in QEMU and others SoCs do not have support, so return false always for these. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Andrew Jeffery <andrew@codeconstruct.com.au> Tested-by: Andrew Jeffery <andrew@codeconstruct.com.au> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-07-21aspeed: Load eMMC first boot area as a boot romCédric Le Goater1-3/+5
The first boot area partition (64K) of the eMMC device should contain an initial boot loader (u-boot SPL). Load it as a ROM only if an eMMC device is available to boot from but no flash device is. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Andrew Jeffery <andrew@codeconstruct.com.au> Tested-by: Andrew Jeffery <andrew@codeconstruct.com.au> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-07-21aspeed: Change type of eMMC deviceCédric Le Goater1-4/+5
The QEMU device model representing the eMMC device of the machine is currently created with type SD_CARD. Change the type to EMMC now that it is available. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Andrew Jeffery <andrew@codeconstruct.com.au> Tested-by: Andrew Jeffery <andrew@codeconstruct.com.au> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-07-18hw/arm/smmu: Refactor SMMU OASMostafa Saleh3-23/+32
SMMUv3 OAS is currently hardcoded in the code to 44 bits, for nested configurations that can be a problem, as stage-2 might be shared with the CPU which might have different PARANGE, and according to SMMU manual ARM IHI 0070F.b: 6.3.6 SMMU_IDR5, OAS must match the system physical address size. This patch doesn't change the SMMU OAS, but refactors the code to make it easier to do that: - Rely everywhere on IDR5 for reading OAS instead of using the SMMU_IDR5_OAS macro, so, it is easier just to change IDR5 and it propagages correctly. - Add additional checks when OAS is greater than 48bits. - Remove unused functions/macros: pa_range/MAX_PA. Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20240715084519.1189624-19-smostafa@google.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-07-18hw/arm/smmuv3: Support and advertise nestingMostafa Saleh1-9/+26
Everything is in place, consolidate parsing of STE cfg and setting translation stage. Advertise nesting if stage requested is "nested". Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20240715084519.1189624-18-smostafa@google.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-07-18hw/arm/smmuv3: Handle translation faults according to SMMUPTWEventInfoMostafa Saleh1-7/+8
Previously, to check if faults are enabled, it was sufficient to check the current stage of translation and check the corresponding record_faults flag. However, with nesting, it is possible for stage-1 (nested) translation to trigger a stage-2 fault, so we check SMMUPTWEventInfo as it would have the correct stage set from the page table walk. Signed-off-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20240715084519.1189624-17-smostafa@google.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-07-18hw/arm/smmuv3: Support nested SMMUs in smmuv3_notify_iova()Mostafa Saleh2-15/+26
IOMMUTLBEvent only understands IOVA, for stage-1 or stage-2 SMMU instances we consider the input address as the IOVA, but when nesting is used, we can't mix stage-1 and stage-2 addresses, so for nesting only stage-1 is considered the IOVA and would be notified. Signed-off-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20240715084519.1189624-16-smostafa@google.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-07-18hw/arm/smmu: Support nesting in the rest of commandsMostafa Saleh3-3/+45
Some commands need rework for nesting, as they used to assume S1 and S2 are mutually exclusive: - CMD_TLBI_NH_ASID: Consider VMID if stage-2 is supported - CMD_TLBI_NH_ALL: Consider VMID if stage-2 is supported, otherwise invalidate everything, this required a new vmid invalidation function for stage-1 only (ASID >= 0) Also, rework trace events to reflect the new implementation. Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20240715084519.1189624-15-smostafa@google.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-07-18hw/arm/smmu: Introduce smmu_iotlb_inv_asid_vmidMostafa Saleh3-9/+15
Soon, Instead of doing TLB invalidation by ASID only, VMID will be also required. Add smmu_iotlb_inv_asid_vmid() which invalidates by both ASID and VMID. However, at the moment this function is only used in SMMU_CMD_TLBI_NH_ASID which is a stage-1 command, so passing VMID = -1 keeps the original behaviour. Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20240715084519.1189624-14-smostafa@google.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-07-18hw/arm/smmu: Support nesting in smmuv3_range_inval()Mostafa Saleh3-8/+64
With nesting, we would need to invalidate IPAs without over-invalidating stage-1 IOVAs. This can be done by distinguishing IPAs in the TLBs by having ASID=-1. To achieve that, rework the invalidation for IPAs to have a separate function, while for IOVA invalidation ASID=-1 means invalidate for all ASIDs. Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20240715084519.1189624-13-smostafa@google.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-07-18hw/arm/smmu-common: Support nested translationMostafa Saleh2-10/+78
When nested translation is requested, do the following: - Translate stage-1 table address IPA into PA through stage-2. - Translate stage-1 table walk output (IPA) through stage-2. - Create a single TLB entry from stage-1 and stage-2 translations using logic introduced before. smmu_ptw() has a new argument SMMUState which include the TLB as stage-1 table address can be cached in there. Also in smmu_ptw(), a separate path used for nesting to simplify the code, although some logic can be combined. With nested translation class of translation fault can be different, from the class of the translation, as faults from translating stage-1 tables are considered as CLASS_TT and not CLASS_IN, a new member "is_ipa_descriptor" added to "SMMUPTWEventInfo" to differ faults from walking stage 1 translation table and faults from translating an IPA for a transaction. Signed-off-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20240715084519.1189624-12-smostafa@google.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-07-18hw/arm/smmu-common: Add support for nested TLBMostafa Saleh1-4/+33
This patch adds support for nested (combined) TLB entries. The main function combine_tlb() is not used here but in the next patches, but to simplify the patches it is introduced first. Main changes: 1) New field added in the SMMUTLBEntry struct: parent_perm, for nested TLB, holds the stage-2 permission, this can be used to know the origin of a permission fault from a cached entry as caching the “and” of the permissions loses this information. SMMUPTWEventInfo is used to hold information about PTW faults so the event can be populated, the value of stage used to be set based on the current stage for TLB permission faults, however with the parent_perm, it is now set based on which perm has the missing permission When nesting is not enabled it has the same value as perm which doesn't change the logic. 2) As combined TLB implementation is used, the combination logic chooses: - tg and level from the entry which has the smallest addr_mask. - Based on that the iova that would be cached is recalculated. - Translated_addr is chosen from stage-2. Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Signed-off-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20240715084519.1189624-11-smostafa@google.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-07-18hw/arm/smmu-common: Rework TLB lookup for nestingMostafa Saleh1-21/+43
In the next patch, combine_tlb() will be added which combines 2 TLB entries into one for nested translations, which chooses the granule and level from the smallest entry. This means that with nested translation, an entry can be cached with the granule of stage-2 and not stage-1. However, currently, the lookup for an IOVA is done with input stage granule, which is stage-1 for nested configuration, which will not work with the above logic. This patch reworks lookup in that case, so it falls back to stage-2 granule if no entry is found using stage-1 granule. Also, drop aligning the iova to avoid over-aligning in case the iova is cached with a smaller granule, the TLB lookup will align the iova anyway for each granule and level, and the page table walker doesn't consider the page offset bits. Signed-off-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20240715084519.1189624-10-smostafa@google.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-07-18hw/arm/smmuv3: Translate CD and TT using stage-2 tableMostafa Saleh1-17/+103
According to ARM SMMU architecture specification (ARM IHI 0070 F.b), In "5.2 Stream Table Entry": [51:6] S1ContextPtr If Config[1] == 1 (stage 2 enabled), this pointer is an IPA translated by stage 2 and the programmed value must be within the range of the IAS. In "5.4.1 CD notes": The translation table walks performed from TTB0 or TTB1 are always performed in IPA space if stage 2 translations are enabled. This patch implements translation of the S1 context descriptor pointer and TTBx base addresses through the S2 stage (IPA -> PA) smmuv3_do_translate() is updated to have one arg which is translation class, this is useful to: - Decide wether a translation is stage-2 only or use the STE config. - Populate the class in case of faults, WALK_EABT is left unchanged for stage-1 as it is always IN, while stage-2 would match the used class (TT, IN, CD), this will change slightly when the ptw supports nested translation as it can also issue TT event with class IN. In case for stage-2 only translation, used in the context of nested translation, the stage and asid are saved and restored before and after calling smmu_translate(). Translating CD or TTBx can fail for the following reasons: 1) Large address size: This is described in (3.4.3 Address sizes of SMMU-originated accesses) - For CD ptr larger than IAS, for SMMUv3.1, it can trigger either C_BAD_STE or Translation fault, we implement the latter as it requires no extra code. - For TTBx, if larger than the effective stage 1 output address size, it triggers C_BAD_CD. 2) Faults from PTWs (7.3 Event records) - F_ADDR_SIZE: large address size after first level causes stage 2 Address Size fault (Also in 3.4.3 Address sizes of SMMU-originated accesses) - F_PERMISSION: Same as an address translation. However, when CLASS == CD, the access is implicitly Data and a read. - F_ACCESS: Same as an address translation. - F_TRANSLATION: Same as an address translation. - F_WALK_EABT: Same as an address translation. These are already implemented in the PTW logic, so no extra handling required. As in CD and TTBx translation context, the iova is not known, setting the InputAddr was removed from "smmuv3_do_translate" and set after from "smmuv3_translate" with the new function "smmuv3_fixup_event" Signed-off-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20240715084519.1189624-9-smostafa@google.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-07-18hw/arm/smmu: Introduce CACHED_ENTRY_TO_ADDRMostafa Saleh1-2/+1
Soon, smmuv3_do_translate() will be used to translate the CD and the TTBx, instead of re-writting the same logic to convert the returned cached entry to an address, add a new macro CACHED_ENTRY_TO_ADDR. Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20240715084519.1189624-8-smostafa@google.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-07-18hw/arm/smmu: Consolidate ASID and VMID typesMostafa Saleh3-16/+16
ASID and VMID used to be uint16_t in the translation config, however, in other contexts they can be int as -1 in case of TLB invalidation, to represent all (don’t care). When stage-2 was added asid was set to -1 in stage-2 and vmid to -1 in stage-1 configs. However, that meant they were set as (65536), this was not an issue as nesting was not supported and no commands/lookup uses both. With nesting, it’s critical to get this right as translation must be tagged correctly with ASID/VMID, and with ASID=-1 meaning stage-2. Represent ASID/VMID everywhere as int. Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Mostafa Saleh <smostafa@google.com> Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20240715084519.1189624-7-smostafa@google.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
generated by cgit v1.1 at 2024-12-26 06:25:23 +0000