aboutsummaryrefslogtreecommitdiff
path: root/include/hw
AgeCommit message (Collapse)Author
2024-01-15hw/misc: Implement STM32L4x5 EXTIInès Varhol
Although very similar to the STM32F4xx EXTI, STM32L4x5 EXTI generates more than 32 event/interrupt requests and thus uses more registers than STM32F4xx EXTI which generates 23 event/interrupt requests. Acked-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Arnaud Minier <arnaud.minier@telecom-paris.fr> Signed-off-by: Inès Varhol <ines.varhol@telecom-paris.fr> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20240109160658.311932-2-ines.varhol@telecom-paris.fr Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-01-12Merge tag 'pull-request-2024-01-11' of https://gitlab.com/thuth/qemu into ↵Peter Maydell
staging * Fix non-deterministic failures of the 'netdev-socket' qtest * Fix device presence checking in the virtio-ccw qtest * Support codespell checking in checkpatch.pl * Fix emulation of LAE s390x instruction * Work around htags bug when environment is large * Some other small clean-ups here and there # -----BEGIN PGP SIGNATURE----- # # iQJFBAABCAAvFiEEJ7iIR+7gJQEY8+q5LtnXdP5wLbUFAmWgHlgRHHRodXRoQHJl # ZGhhdC5jb20ACgkQLtnXdP5wLbXAnBAAjQve/Jmfp9p8eQmswG7cl/a2TuJ59b9X # SFRja2PprV/Wp4kxxEJX4er9F2+rlMusNL62LBp/QjZi9u4lCvCmuB7sMa0wEkjr # BPPBrkxkAT+/8vhGpYg2GrxZv/UOLkycp3sjEp4v5yXWQw+OEBnkZZ+AuHddpnEr # NKMKss71uQmccvuzD5FMDfbJQcSBD/yGPyFfDrv1RKreYRlbkEDVlcVoZpfoMwQY # Pl167iDdmjVtsT+4wf8vHo5W/AYKDOjlV6AoujCnJVZnGx6BtDLiF/iNJ/VU1Ty5 # cRxySPT64HG+cGrbRqz9IjDvs++WW5EQn1jPY8NO2XFz3sney6Cs/pLKjqJY9S7P # kfOXOBZG3zOI1kgd/CSR5b4szg4XvtTZaupczKiGOpYC9klf0oQNXGU5jXi3Csop # Q332oUgiPeNdOx/4tXobFX6RwVCqLRYZbHx9RRYSxWlqJJPAB74/n+RZsmOtsxuJ # RaiPKDmbVlslkUm78gIa5e6DMwDk2wmlkqa64W7VZxyqfQTRDPiPvfMGePkj6tmZ # h9vUsELwwORlHpZyL08n0fzs3aeIYwzPwhfr+5iQZIawIp4Zqo8i8Lic/WfIlok9 # rmPIA0mjs1VtrUsroItw4NcY04xcVa7hkhz4EbkZROrfGamdkLuvbk2OKuOeoL0U # lpgtQL6jA7E= # =F/j2 # -----END PGP SIGNATURE----- # gpg: Signature made Thu 11 Jan 2024 16:59:04 GMT # gpg: using RSA key 27B88847EEE0250118F3EAB92ED9D774FE702DB5 # gpg: issuer "thuth@redhat.com" # gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [full] # gpg: aka "Thomas Huth <thuth@redhat.com>" [full] # gpg: aka "Thomas Huth <huth@tuxfamily.org>" [full] # gpg: aka "Thomas Huth <th.huth@posteo.de>" [unknown] # Primary key fingerprint: 27B8 8847 EEE0 2501 18F3 EAB9 2ED9 D774 FE70 2DB5 * tag 'pull-request-2024-01-11' of https://gitlab.com/thuth/qemu: .gitlab-ci.d/buildtest.yml: Work around htags bug when environment is large tests/tcg/s390x: Test LOAD ADDRESS EXTENDED target/s390x: Fix LAE setting a wrong access register scripts/checkpatch: Support codespell checking hw/s390x/ccw: Replace dirname() with g_path_get_dirname() hw/s390x/ccw: Replace basename() with g_path_get_basename() target/s390x/kvm/pv: Provide some more useful information if decryption fails gitlab: fix s390x tag for avocado-system-centos tests/qtest/virtio-ccw: Fix device presence checking qtest: ensure netdev-socket tests have non-overlapping names net: handle QIOTask completion to report useful error message net: add explicit info about connecting/listening state Revert "tests/qtest/netdev-socket: Raise connection timeout to 120 seconds" Revert "osdep: add getloadavg" Revert "netdev: set timeout depending on loadavg" qtest: use correct boolean type for failover property q800: move dp8393x_prom memory region to Q800MachineState Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-01-11Merge tag 'pull-loongarch-20240111' of https://gitlab.com/gaosong/qemu into ↵Peter Maydell
staging pull-loongarch-20240111 # -----BEGIN PGP SIGNATURE----- # # iLMEAAEKAB0WIQS4/x2g0v3LLaCcbCxAov/yOSY+3wUCZZ/QKgAKCRBAov/yOSY+ # 34eqBADA48++Z9gETFNheLUHdYEaja2emn+gSaoHLFquyq/l53w8RfrUII+BzV1o # T7D8xjlVQldAYZzqQn2pQe2S7r4ggfeNmxGxwJbCTW9sooGMwBnU8+Ix3ruSet7K # gI+UHLU4oHk6jdrT384tux2EG+qUmlLN1c7j4G/z1OzKEwFv7Q== # =+Pi0 # -----END PGP SIGNATURE----- # gpg: Signature made Thu 11 Jan 2024 11:25:30 GMT # gpg: using RSA key B8FF1DA0D2FDCB2DA09C6C2C40A2FFF239263EDF # gpg: Good signature from "Song Gao <m17746591750@163.com>" [unknown] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: B8FF 1DA0 D2FD CB2D A09C 6C2C 40A2 FFF2 3926 3EDF * tag 'pull-loongarch-20240111' of https://gitlab.com/gaosong/qemu: hw/intc/loongarch_extioi: Add vmstate post_load support hw/intc/loongarch_extioi: Add dynamic cpu number support hw/loongarch/virt: Set iocsr address space per-board rather than percpu hw/intc/loongarch_ipi: Use MemTxAttrs interface for ipi ops target/loongarch: Add loongarch kvm into meson build target/loongarch: Implement set vcpu intr for kvm target/loongarch: Restrict TCG-specific code target/loongarch: Implement kvm_arch_handle_exit target/loongarch: Implement kvm_arch_init_vcpu target/loongarch: Implement kvm_arch_init function target/loongarch: Implement kvm get/set registers target/loongarch: Supplement vcpu env initial when vcpu reset target/loongarch: Define some kvm_arch interfaces linux-headers: Synchronize linux headers from linux v6.7.0-rc8 Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-01-11hw/intc/loongarch_extioi: Add dynamic cpu number supportBibo Mao
On LoongArch physical machine, one extioi interrupt controller only supports 4 cpus. With processor more than 4 cpus, there are multiple extioi interrupt controllers; if interrupts need to be routed to other cpus, they are forwarded from extioi node0 to other extioi nodes. On virt machine model, there is simple extioi interrupt device model. All cpus can access register of extioi interrupt controller, however interrupt can only be route to 4 vcpu for compatible with old kernel. This patch adds dynamic cpu number support about extioi interrupt. With old kernel legacy extioi model is used, however kernel can detect and choose new route method in future, so that interrupt can be routed to all vcpus. Signed-off-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Song Gao <gaosong@loongson.cn> Message-Id: <20231215100333.3933632-4-maobibo@loongson.cn> Signed-off-by: Song Gao <gaosong@loongson.cn>
2024-01-11hw/loongarch/virt: Set iocsr address space per-board rather than percpuBibo Mao
LoongArch system has iocsr address space, most iocsr registers are per-board, however some iocsr register spaces banked for percpu such as ipi mailbox and extioi interrupt status. For banked iocsr space, each cpu has the same iocsr space, but separate data. This patch changes iocsr address space per-board rather percpu, for iocsr registers specified for cpu, MemTxAttrs.requester_id can be parsed for the cpu. With this patches, the total address space on board will be simple, only iocsr address space and system memory, rather than the number of cpu and system memory. Signed-off-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Song Gao <gaosong@loongson.cn> Message-Id: <20231215100333.3933632-3-maobibo@loongson.cn> Signed-off-by: Song Gao <gaosong@loongson.cn>
2024-01-11Merge tag 'pull-target-arm-20240111' of ↵Peter Maydell
https://git.linaro.org/people/pmaydell/qemu-arm into staging target-arm queue: * Emulate FEAT_NV, FEAT_NV2 * add cache controller for Freescale i.MX6 * Add minimal support for the B-L475E-IOT01A board * Allow SoC models to configure M-profile CPUs with correct number of NVIC priority bits * Add missing QOM parent for v7-M SoCs * Set CTR_EL0.{IDC,DIC} for the 'max' CPU * hw/intc/arm_gicv3_cpuif: handle LPIs in in the list registers # -----BEGIN PGP SIGNATURE----- # # iQJNBAABCAA3FiEE4aXFk81BneKOgxXPPCUl7RQ2DN4FAmWfypMZHHBldGVyLm1h # eWRlbGxAbGluYXJvLm9yZwAKCRA8JSXtFDYM3sleD/4tQOMteba5BNMDns6R96E4 # kj5q0Iy9XyzQ486Q4cIZXI5N3BddCp2ks8WeS2W3w4IT/lms0U6UwXV4E98I4I/b # KSfOoUd/cp8IvdvzfpWbmQcPMoauHZdCUN33pYYXOjfi1RkpzgNU5Qgh09Nl/xYU # V3oaEvWhLtepT/fwJLYxoqVHDaEmyW+6zriF0+eGjZvkhgPyhllla9eti7AyHTfH # T3A4Fyx/wudRE3NP6xsLfxldriJTxQeba+TqLSh3IXn/PMtK13/ARsY/hl72Q4ML # Fgad8Zho4eXbuOQ9oiqb7gp4K3IKd9/8FbCzECoIAq7AnLAD4KwpLQR8GULRvYW3 # 0eQq2txTXQWNcmWpIyDRRME+qeNVwWSk+QJDs5WuhVqlVQ4hpqtgFf1EX+7ORdS1 # WG0fb8etvr8oCSkzCmP/o6xYGJ0EyTVMU5DmWviy3bxMrUMcmobjvCQr/n2gC713 # 1NDmEaYPbl+pX8EMu8byst7/No2PXRgIO0UVVb4KZybfhNy+BBs+LiMVlSRS5YH4 # 8NWtoYZlG9RcPnY+8Xrxz9VTi2cNAAcdbf5uK3snJxkFV2SmV3oBoMxWen3mee0f # 2PNVEbt9zvPV8hViBVLsqRhVXd9wMq6motIRlkKge1u1TvwIxO21ibykI3tvYOGv # BffIjhUdnYtX90JAtXtFDw== # =yQwf # -----END PGP SIGNATURE----- # gpg: Signature made Thu 11 Jan 2024 11:01:39 GMT # 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-20240111' of https://git.linaro.org/people/pmaydell/qemu-arm: (41 commits) target/arm: Add FEAT_NV2 to max, neoverse-n2, neoverse-v1 CPUs target/arm: Enhance CPU_LOG_INT to show SPSR on AArch64 exception-entry target/arm: Report HCR_EL2.{NV,NV1,NV2} in cpu dumps hw/intc/arm_gicv3_cpuif: Mark up VNCR offsets for GIC CPU registers target/arm: Mark up VNCR offsets (offsets >= 0x200, except GIC) target/arm: Mark up VNCR offsets (offsets 0x168..0x1f8) target/arm: Mark up VNCR offsets (offsets 0x100..0x160) target/arm: Mark up VNCR offsets (offsets 0x0..0xff) target/arm: Report VNCR_EL2 based faults correctly target/arm: Implement FEAT_NV2 redirection of sysregs to RAM target/arm: Handle FEAT_NV2 redirection of SPSR_EL2, ELR_EL2, ESR_EL2, FAR_EL2 target/arm: Handle FEAT_NV2 changes to when SPSR_EL1.M reports EL2 target/arm: Implement VNCR_EL2 register target/arm: Handle HCR_EL2 accesses for FEAT_NV2 bits target/arm: Add FEAT_NV to max, neoverse-n2, neoverse-v1 CPUs target/arm: Handle FEAT_NV page table attribute changes target/arm: Treat LDTR* and STTR* as LDR/STR when NV, NV1 is 1, 1 target/arm: Don't honour PSTATE.PAN when HCR_EL2.{NV, NV1} == {1, 1} target/arm: Always use arm_pan_enabled() when checking if PAN is enabled target/arm: Trap registers when HCR_EL2.{NV, NV1} == {1, 1} ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-01-11q800: move dp8393x_prom memory region to Q800MachineStateMark Cave-Ayland
There is no need to dynamically allocate the memory region from the heap. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-ID: <20231227210212.245106-1-mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Signed-off-by: Thomas Huth <thuth@redhat.com>
2024-01-10hw/riscv/virt: Update GPEX MMIO related propertiesSunil V L
Update the GPEX host bridge properties related to MMIO ranges with values set for the virt machine. Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231218150247.466427-12-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10hw/pci-host/gpex: Define properties for MMIO rangesSunil V L
ACPI DSDT generator needs information like ECAM range, PIO range, 32-bit and 64-bit PCI MMIO range etc related to the PCI host bridge. Instead of making these values machine specific, create properties for the GPEX host bridge with default value 0. During initialization, the firmware can initialize these properties with correct values for the platform. This basically allows DSDT generator code independent of the machine specific memory map accesses. Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20231218150247.466427-11-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10hw/riscv: virt: Make few IMSIC macros and functions publicSunil V L
Some macros and static function related to IMSIC are defined in virt.c. They are required in virt-acpi-build.c. So, make them public. Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231218150247.466427-5-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10hw/arm/virt-acpi-build.c: Migrate virtio creation to common locationSunil V L
RISC-V also needs to create the virtio in DSDT in the same way as ARM. So, instead of duplicating the code, move this function to the device specific file which is common across architectures. Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231218150247.466427-3-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-10hw/arm/virt-acpi-build.c: Migrate fw_cfg creation to common locationSunil V L
RISC-V also needs to use the same code to create fw_cfg in DSDT. So, avoid code duplication by moving the code in arm and riscv to a device specific file. Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Sunil V L <sunilvl@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-ID: <20231218150247.466427-2-sunilvl@ventanamicro.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
2024-01-09hw/arm/armv7m: alias the NVIC "num-prio-bits" propertySamuel Tardieu
A SoC will not have a direct access to the NVIC embedded in its ARM core. By aliasing the "num-prio-bits" property similarly to what is done for the "num-irq" one, a SoC can easily configure it on its armv7m instance. Signed-off-by: Samuel Tardieu <sam@rfc1149.net> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20240106181503.1746200-3-sam@rfc1149.net Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-01-09hw/arm: Add minimal support for the STM32L4x5 SoCInès Varhol
This patch adds a new STM32L4x5 SoC, it is necessary to add support for the B-L475E-IOT01A board. The implementation is derived from the STM32F405 SoC. The implementation contains no peripherals, only memory regions are implemented. Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Acked-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Arnaud Minier <arnaud.minier@telecom-paris.fr> Signed-off-by: Inès Varhol <ines.varhol@telecom-paris.fr> Message-id: 20240108135849.351719-2-ines.varhol@telecom-paris.fr Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2024-01-05vfio/iommufd: Introduce a VFIOIOMMU iommufd QOM interfaceCédric Le Goater
As previously done for the sPAPR and legacy IOMMU backends, convert the VFIOIOMMUOps struct to a QOM interface. The set of of operations for this backend can be referenced with a literal typename instead of a C struct. Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Tested-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2024-01-05vfio/spapr: Introduce a sPAPR VFIOIOMMU QOM interfaceCédric Le Goater
Move vfio_spapr_container_setup() to a VFIOIOMMUClass::setup handler and convert the sPAPR VFIOIOMMUOps struct to a QOM interface. The sPAPR QOM interface inherits from the legacy QOM interface because because both have the same basic needs. The sPAPR interface is then extended with the handlers specific to the sPAPR IOMMU. This allows reuse and provides better abstraction of the backends. It will be useful to avoid compiling the sPAPR IOMMU backend on targets not supporting it. Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Tested-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2024-01-05vfio/container: Intoduce a new VFIOIOMMUClass::setup handlerCédric Le Goater
This will help in converting the sPAPR IOMMU backend to a QOM interface. Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Tested-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2024-01-05vfio/container: Introduce a VFIOIOMMU legacy QOM interfaceCédric Le Goater
Convert the legacy VFIOIOMMUOps struct to the new VFIOIOMMU QOM interface. The set of of operations for this backend can be referenced with a literal typename instead of a C struct. This will simplify support of multiple backends. Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Tested-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2024-01-05vfio/container: Introduce a VFIOIOMMU QOM interfaceCédric Le Goater
VFIOContainerBase was not introduced as an abstract QOM object because it felt unnecessary to expose all the IOMMU backends to the QEMU machine and human interface. However, we can still abstract the IOMMU backend handlers using a QOM interface class. This provides more flexibility when referencing the various implementations. Simply transform the VFIOIOMMUOps struct in an InterfaceClass and do some initial name replacements. Next changes will start converting VFIOIOMMUOps. Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Tested-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2024-01-05vfio/spapr: Extend VFIOIOMMUOps with a release handlerCédric Le Goater
This allows to abstract a bit more the sPAPR IOMMU support in the legacy IOMMU backend. Reviewed-by: Zhenzhong Duan <zhenzhong.duan@intel.com> Tested-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Cédric Le Goater <clg@redhat.com>
2024-01-05hw/mips: Inline 'bios.h' definitionsPhilippe Mathieu-Daudé
There is no universal BIOS, each machine needs a specific one. Move the machine-specific definitions to each machine code and remove this bogus header. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20231122184334.18201-1-philmd@linaro.org>
2024-01-05hw/ppc/xive2_regs: Remove unnecessary 'cpu.h' inclusionPhilippe Mathieu-Daudé
xive2_regs.h only requires declarations from "qemu/bswap.h". Include it instead of the huge target-specific "cpu.h". Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Cédric Le Goater <clg@redhat.com> Message-Id: <20231122183920.17905-1-philmd@linaro.org>
2024-01-05hw/core/cpu: Update description of CPUState::nodePhilippe Mathieu-Daudé
'next_cpu' was converted to 'node' in commit bdc44640cb ("cpu: Use QTAILQ for CPU list"). Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20231129183243.15859-1-philmd@linaro.org>
2024-01-05hw/core/cpu: Remove final vestiges of dynamic state tracingPhilippe Mathieu-Daudé
The dynamic state tracing was removed in commit d0aaf08bb9. Fixes: d0aaf08bb9 ("tcg: remove the final vestiges of dstate") Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20231129182734.15565-1-philmd@linaro.org>
2024-01-05hw/core: Add machine_class_default_cpu_type()Philippe Mathieu-Daudé
Add a helper to return a machine default CPU type. If this machine is restricted to a single CPU type, use it as default, obviously. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20231116163726.28952-1-philmd@linaro.org>
2024-01-05cpu: Add helper cpu_model_from_type()Gavin Shan
Add helper cpu_model_from_type() to extract the CPU model name from the CPU type name in two circumstances: (1) The CPU type name is the combination of the CPU model name and suffix. (2) The CPU type name is same to the CPU model name. The helper will be used in the subsequent commits to conver the CPU type name to the CPU model name. Suggested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Gavin Shan <gshan@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20231114235628.534334-6-gshan@redhat.com> [PMD: Mention returned string must be released with g_free()] Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2023-12-30hw/pci: Constify VMStateRichard Henderson
Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20231221031652.119827-45-richard.henderson@linaro.org>
2023-12-26vdpa: move memory listener to vhost_vdpa_sharedEugenio Pérez
Next patches will register the vhost_vdpa memory listener while the VM is migrating at the destination, so we can map the memory to the device before stopping the VM at the source. The main goal is to reduce the downtime. However, the destination QEMU is unaware of which vhost_vdpa device will register its memory_listener. If the source guest has CVQ enabled, it will be the CVQ device. Otherwise, it will be the first one. Move the memory listener to a common place rather than always in the first / last vhost_vdpa. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20231221174322.3130442-14-eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-12-26vdpa: use dev_shared in vdpa_iommuEugenio Pérez
The memory listener functions can call these too. Make vdpa_iommu work with VhostVDPAShared. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20231221174322.3130442-13-eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-12-26vdpa: use VhostVDPAShared in vdpa_dma_map and unmapEugenio Pérez
The callers only have the shared information by the end of this series. Start converting this functions. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20231221174322.3130442-12-eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-12-26vdpa: move iommu_list to vhost_vdpa_sharedEugenio Pérez
Next patches will register the vhost_vdpa memory listener while the VM is migrating at the destination, so we can map the memory to the device before stopping the VM at the source. The main goal is to reduce the downtime. However, the destination QEMU is unaware of which vhost_vdpa device will register its memory_listener. If the source guest has CVQ enabled, it will be the CVQ device. Otherwise, it will be the first one. Move the iommu_list member to VhostVDPAShared so all vhost_vdpa can use it, rather than always in the first / last vhost_vdpa. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20231221174322.3130442-11-eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-12-26vdpa: remove msg type of vhost_vdpaEugenio Pérez
It is always VHOST_IOTLB_MSG_V2. We can always make it back per vhost_dev if needed. This change makes easier for vhost_vdpa_map and unmap not to depend on vhost_vdpa but only in VhostVDPAShared. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20231221174322.3130442-10-eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-12-26vdpa: move backend_cap to vhost_vdpa_sharedEugenio Pérez
Next patches will register the vhost_vdpa memory listener while the VM is migrating at the destination, so we can map the memory to the device before stopping the VM at the source. The main goal is to reduce the downtime. However, the destination QEMU is unaware of which vhost_vdpa device will register its memory_listener. If the source guest has CVQ enabled, it will be the CVQ device. Otherwise, it will be the first one. Move the backend_cap member to VhostVDPAShared so all vhost_vdpa can use it, rather than always in the first / last vhost_vdpa. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20231221174322.3130442-9-eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-12-26vdpa: move iotlb_batch_begin_sent to vhost_vdpa_sharedEugenio Pérez
Next patches will register the vhost_vdpa memory listener while the VM is migrating at the destination, so we can map the memory to the device before stopping the VM at the source. The main goal is to reduce the downtime. However, the destination QEMU is unaware of which vhost_vdpa device will register its memory_listener. If the source guest has CVQ enabled, it will be the CVQ device. Otherwise, it will be the first one. Move the iotlb_batch_begin_sent member to VhostVDPAShared so all vhost_vdpa can use it, rather than always in the first / last vhost_vdpa. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20231221174322.3130442-8-eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-12-26vdpa: move file descriptor to vhost_vdpa_sharedEugenio Pérez
Next patches will register the vhost_vdpa memory listener while the VM is migrating at the destination, so we can map the memory to the device before stopping the VM at the source. The main goal is to reduce the downtime. However, the destination QEMU is unaware of which vhost_vdpa device will register its memory_listener. If the source guest has CVQ enabled, it will be the CVQ device. Otherwise, it will be the first one. Move the file descriptor to VhostVDPAShared so all vhost_vdpa can use it, rather than always in the first / last vhost_vdpa. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20231221174322.3130442-7-eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-12-26vdpa: move shadow_data to vhost_vdpa_sharedEugenio Pérez
Next patches will register the vhost_vdpa memory listener while the VM is migrating at the destination, so we can map the memory to the device before stopping the VM at the source. The main goal is to reduce the downtime. However, the destination QEMU is unaware of which vhost_vdpa device will register its memory_listener. If the source guest has CVQ enabled, it will be the CVQ device. Otherwise, it will be the first one. Move the shadow_data member to VhostVDPAShared so all vhost_vdpa can use it, rather than always in the first or last vhost_vdpa. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20231221174322.3130442-5-eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-12-26vdpa: move iova_range to vhost_vdpa_sharedEugenio Pérez
Next patches will register the vhost_vdpa memory listener while the VM is migrating at the destination, so we can map the memory to the device before stopping the VM at the source. The main goal is to reduce the downtime. However, the destination QEMU is unaware of which vhost_vdpa device will register its memory_listener. If the source guest has CVQ enabled, it will be the CVQ device. Otherwise, it will be the first one. Move the iova range to VhostVDPAShared so all vhost_vdpa can use it, rather than always in the first or last vhost_vdpa. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20231221174322.3130442-4-eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-12-26vdpa: move iova tree to the shared structEugenio Pérez
Next patches will register the vhost_vdpa memory listener while the VM is migrating at the destination, so we can map the memory to the device before stopping the VM at the source. The main goal is to reduce the downtime. However, the destination QEMU is unaware of which vhost_vdpa device will register its memory_listener. If the source guest has CVQ enabled, it will be the CVQ device. Otherwise, it will be the first one. Move the iova tree to VhostVDPAShared so all vhost_vdpa can use it, rather than always in the first or last vhost_vdpa. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20231221174322.3130442-3-eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-12-26vdpa: add VhostVDPASharedEugenio Pérez
It will hold properties shared among all vhost_vdpa instances associated with of the same device. For example, we just need one iova_tree or one memory listener for the entire device. Next patches will register the vhost_vdpa memory listener at the beginning of the VM migration at the destination. This enables QEMU to map the memory to the device before stopping the VM at the source, instead of doing while both source and destination are stopped, thus minimizing the downtime. However, the destination QEMU is unaware of which vhost_vdpa struct will register its memory_listener. If the source guest has CVQ enabled, it will be the one associated with the CVQ. Otherwise, it will be the first one. Save the memory operations related members in a common place rather than always in the first / last vhost_vdpa. Signed-off-by: Eugenio Pérez <eperezma@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Message-Id: <20231221174322.3130442-2-eperezma@redhat.com> Tested-by: Lei Yang <leiyang@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-12-25vhost-scsi: Add support for a worker thread per virtqueueMike Christie
This adds support for vhost-scsi to be able to create a worker thread per virtqueue. Right now for vhost-net we get a worker thread per tx/rx virtqueue pair which scales nicely as we add more virtqueues and CPUs, but for scsi we get the single worker thread that's shared by all virtqueues. When trying to send IO to more than 2 virtqueues the single thread becomes a bottlneck. This patch adds a new setting, worker_per_virtqueue, which can be set to: false: Existing behavior where we get the single worker thread. true: Create a worker per IO virtqueue. Signed-off-by: Mike Christie <michael.christie@oracle.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20231204231618.21962-3-michael.christie@oracle.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
2023-12-25vhost: Add worker backend calloutsMike Christie
This adds the vhost backend callouts for the worker ioctls added in the 6.4 linux kernel commit: c1ecd8e95007 ("vhost: allow userspace to create workers") Signed-off-by: Mike Christie <michael.christie@oracle.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20231204231618.21962-2-michael.christie@oracle.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2023-12-21Merge tag 'pull-loongarch-20231221' of https://gitlab.com/gaosong/qemu into ↵Stefan Hajnoczi
staging pull-loongarch-20231221 # -----BEGIN PGP SIGNATURE----- # # iLMEAAEKAB0WIQS4/x2g0v3LLaCcbCxAov/yOSY+3wUCZYPyvQAKCRBAov/yOSY+ # 38/vBADT3b+Wo/2AeXOO3OXOM1VBhIvzDjY1OWytuJpkF3JGW45cMLqgtIgMj8h7 # NtzRS3JbFYbYuxITeeo1Ppl6dAD0pCZjIU6OCBxAJ6ADPsE/xD8nYWrMGqYVXg7E # hN0Cno2sf6dmJ0QxUxn7G+cUuvNtnGaDSZE+RAkjtzq1nvx7CQ== # =mte5 # -----END PGP SIGNATURE----- # gpg: Signature made Thu 21 Dec 2023 03:09:33 EST # gpg: using RSA key B8FF1DA0D2FDCB2DA09C6C2C40A2FFF239263EDF # gpg: Good signature from "Song Gao <m17746591750@163.com>" [unknown] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: B8FF 1DA0 D2FD CB2D A09C 6C2C 40A2 FFF2 3926 3EDF * tag 'pull-loongarch-20231221' of https://gitlab.com/gaosong/qemu: target/loongarch: Add timer information dump support hw/loongarch/virt: Align high memory base address with super page size Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2023-12-21virtio-blk: add iothread-vq-mapping parameterStefan Hajnoczi
Add the iothread-vq-mapping parameter to assign virtqueues to IOThreads. Store the vq:AioContext mapping in the new struct VirtIOBlockDataPlane->vq_aio_context[] field and refactor the code to use the per-vq AioContext instead of the BlockDriverState's AioContext. Reimplement --device virtio-blk-pci,iothread= and non-IOThread mode by assigning all virtqueues to the IOThread and main loop's AioContext in vq_aio_context[], respectively. The comment in struct VirtIOBlockDataPlane about EventNotifiers is stale. Remove it. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20231220134755.814917-5-stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-12-21qdev: add IOThreadVirtQueueMappingList property typeStefan Hajnoczi
virtio-blk and virtio-scsi devices will need a way to specify the mapping between IOThreads and virtqueues. At the moment all virtqueues are assigned to a single IOThread or the main loop. This single thread can be a CPU bottleneck, so it is necessary to allow finer-grained assignment to spread the load. Introduce DEFINE_PROP_IOTHREAD_VQ_MAPPING_LIST() so devices can take a parameter that maps virtqueues to IOThreads. The command-line syntax for this new property is as follows: --device '{"driver":"foo","iothread-vq-mapping":[{"iothread":"iothread0","vqs":[0,1,2]},...]}' IOThreads are specified by name and virtqueues are specified by 0-based index. It will be common to simply assign virtqueues round-robin across a set of IOThreads. A convenient syntax that does not require specifying individual virtqueue indices is available: --device '{"driver":"foo","iothread-vq-mapping":[{"iothread":"iothread0"},{"iothread":"iothread1"},...]}' Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20231220134755.814917-4-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-12-21qdev-properties: alias all object class propertiesStefan Hajnoczi
qdev_alias_all_properties() aliases a DeviceState's qdev properties onto an Object. This is used for VirtioPCIProxy types so that --device virtio-blk-pci has properties of its embedded --device virtio-blk-device object. Currently this function is implemented using qdev properties. Change the function to use QOM object class properties instead. This works because qdev properties create QOM object class properties, but it also catches any QOM object class-only properties that have no qdev properties. This change ensures that properties of devices are shown with --device foo,\? even if they are QOM object class properties. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20231220134755.814917-2-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-12-21scsi: remove AioContext lockingStefan Hajnoczi
The AioContext lock no longer has any effect. Remove it. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-ID: <20231205182011.1976568-9-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-12-21virtio-scsi: replace AioContext lock with tmf_bh_lockStefan Hajnoczi
Protect the Task Management Function BH state with a lock. The TMF BH runs in the main loop thread. An IOThread might process a TMF at the same time as the TMF BH is running. Therefore tmf_bh_list and tmf_bh must be protected by a lock. Run TMF request completion in the IOThread using aio_wait_bh_oneshot(). This avoids more locking to protect the virtqueue and SCSI layer state. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <20231205182011.1976568-2-stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-12-21scsi: only access SCSIDevice->requests from one threadStefan Hajnoczi
Stop depending on the AioContext lock and instead access SCSIDevice->requests from only one thread at a time: - When the VM is running only the BlockBackend's AioContext may access the requests list. - When the VM is stopped only the main loop may access the requests list. These constraints protect the requests list without the need for locking in the I/O code path. Note that multiple IOThreads are not supported yet because the code assumes all SCSIRequests are executed from a single AioContext. Leave that as future work. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-ID: <20231204164259.1515217-2-stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-12-21virtio-blk: add lock to protect s->rqStefan Hajnoczi
s->rq is accessed from IO_CODE and GLOBAL_STATE_CODE. Introduce a lock to protect s->rq and eliminate reliance on the AioContext lock. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-ID: <20230914140101.1065008-3-stefanha@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2023-12-21hw/loongarch/virt: Align high memory base address with super page sizeBibo Mao
With LoongArch virt machine, there is low memory space with region 0--0x10000000, and high memory space with started from 0x90000000. High memory space is aligned with 256M, it will be better if it is aligned with 1G, which is super page aligned for 4K page size. Currently linux kernel and uefi bios has no limitation with high memory base address, it is ok to set high memory base address with 0x80000000. Signed-off-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Song Gao <gaosong@loongson.cn> Message-Id: <20231127040231.4123715-1-maobibo@loongson.cn> Signed-off-by: Song Gao <gaosong@loongson.cn>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-16 18:54:14 +0000