aboutsummaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)AuthorFilesLines
2021-12-17target/ppc: introduce PMUEventType and PMU overflow timersDaniel Henrique Barboza1-0/+1
This patch starts an IBM Power8+ compatible PMU implementation by adding the representation of PMU events that we are going to sample, PMUEventType. This enum represents a Perf event that is being sampled by a specific counter 'sprn'. Events that aren't available (i.e. no event was set in MMCR1) will be of type 'PMU_EVENT_INVALID'. Events that are inactive due to frozen counter bits state are of type 'PMU_EVENT_INACTIVE'. Other types added in this patch are PMU_EVENT_CYCLES and PMU_EVENT_INSTRUCTIONS. More types will be added later on. Let's also add the required PMU cycle overflow timers. They will be used to trigger cycle overflows when cycle events are being sampled. This timer will call cpu_ppc_pmu_timer_cb(), which in turn calls fire_PMC_interrupt(). Both functions are stubs that will be implemented later on when EBB support is added. Two new helper files are created to host this new logic. cpu_ppc_pmu_init() will init all overflow timers during CPU init time. Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20211201151734.654994-2-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/ppc405: Add update of bi_procfreq fieldCédric Le Goater1-4/+5
Adapt the fields offset in the board information for Linux. Since Linux relies on the CPU frequency value, I wonder how it ever worked. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211206103712.1866296-15-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/ppc405: Fix bi_pci_enetaddr2 field in U-Boot board informationCédric Le Goater1-1/+1
The board information for the 405EP first appeared in commit 04f20795ac81 ("Move PowerPC 405 specific definitions into a separate file ...") An Ethernet address is a 6 byte number. Fix that. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20211206103712.1866296-14-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/ppc405: Change default PLL values at resetCédric Le Goater1-3/+3
These values are computed and updated by U-Boot at startup. Use them as defaults to improve direct Linux boot. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211206103712.1866296-13-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/ppc405: Fix boot from kernelCédric Le Goater1-43/+102
The machine can already boot with kernel and initrd U-boot images if a firmware is loaded first. Adapt and improve the load sequence to let the machine boot directly from a Linux kernel ELF image and a usual initrd image if a firmware image is not provided. For that, install a custom CPU reset handler to setup the registers and to start the CPU from the Linux kernel entry point. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211206103712.1866296-12-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/ppc405: Introduce ppc405_set_default_bootinfo()Cédric Le Goater3-29/+42
This routine is a small helper to cleanup the code. The update of the flash fields were removed because there are not of any use when booting from a Linux kernel image. It should be functionally equivalent. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211206103712.1866296-11-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/ppc405: Rework FW loadCédric Le Goater1-25/+20
QEMU installs a custom U-Boot in-memory descriptor to share board information with Linux, which means that the QEMU machine was initially designed to support booting Linux directly without using the loaded FW. But, it's not that simple because the CPU still starts at address 0xfffffffc where nothing is currently mapped. Support must have been broken these last years. Since we can not find a "ppc405_rom.bin" firmware file, request one to be specified on the command line. A consequence of this change is that the machine can be booted directly from Linux without any FW being loaded. This is still broken and the CPU start address will be fixed in the next changes. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211206103712.1866296-10-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/ppc405: Remove flash supportCédric Le Goater1-13/+1
It is currently impossible to find a "ppc405_rom.bin" firmware file or a full flash image for the PPC405EP evalution board. Even if it should be technically possible to recreate such an image, it's unlikely that anyone will do it since the board is obsolete and support in QEMU has been broken for about 10 years. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211206103712.1866296-9-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/ppc405: Add some address space definitionsCédric Le Goater2-9/+14
Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20211206103712.1866296-8-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/ppc405: Change ppc405ep_init() return valueCédric Le Goater3-4/+8
I will be useful to rework the boot from Linux. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211206103712.1866296-7-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/ppc405: Drop flag parameter in ppc405_set_bootinfo()Cédric Le Goater3-8/+5
It was introduced in commit b8d3f5d12642 ("Add flags to support PowerPC 405 bootinfos variations.") but since its value has always been set to '1'. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20211206103712.1866296-6-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/ppc405: Convert printfs to trace-eventsCédric Le Goater2-105/+74
and one error message to a LOG_GUEST_ERROR. Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211206103712.1866296-5-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc: Add trace-events for DCR accessesCédric Le Goater2-0/+5
Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20211206103712.1866296-4-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc: Mark the 'taihu' machine as deprecatedThomas Huth1-0/+1
The PPC 405 CPU is a system-on-a-chip, so all 405 machines are very similar, except for some external periphery. However, the periphery of the 'taihu' machine is hardly emulated at all (e.g. neither the LCD nor the USB part had been implemented), so there is not much value added by this board. The users can use the 'ref405ep' machine to test their PPC405 code instead. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20211203164904.290954-2-thuth@redhat.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211206103712.1866296-3-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/ppc405: Change kernel load addressCédric Le Goater1-1/+1
The default addresses to load the kernel, fdt, initrd of AMCC boards in U-Boot v2015.10 are : "kernel_addr_r=1000000\0" "fdt_addr_r=1800000\0" "ramdisk_addr_r=1900000\0" The taihu is one of these boards, the ref405ep is not but we don't have much information on it and both boards have a very similar address space layout. Also, if loaded at address 0, U-Boot will partially overwrite the uImage because of a bug in get_ram_size() (U-Boot v2015.10) not restoring properly the probed RAM contents and because the exception vectors are installed in the same range. Finally, a gzipped kernel image will be uncompressed at 0x0. These are all good reasons for not mappping a kernel image at this address. Change the kernel load address to match U-Boot expectations and fix loading. Cc: Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <20211202191446.1292125-1-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211206103712.1866296-2-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/pnv.c: fix "system-id" FDT when -uuid is setDaniel Henrique Barboza1-1/+1
Setting -uuid in the pnv machine does not work: ./qemu-system-ppc64 -machine powernv8,accel=tcg -uuid 7ff61ca1-a4a0-4bc1-944c-abd114a35e80 qemu-system-ppc64: error creating device tree: (fdt_property_string(fdt, "system-id", buf)): FDT_ERR_BADSTATE This happens because we're using fdt_property_string(), which is a sequential write function that is supposed to be used when we're building a new FDT, in a case where read/writing into an existing FDT. Fix it by using fdt_setprop_string() instead. Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20211207094858.744386-1-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ppc/pnv.c: add a friendly warning when accel=kvm is usedDaniel Henrique Barboza1-0/+5
If one tries to use -machine powernv9,accel=kvm in a Power9 host, a cryptic error will be shown: qemu-system-ppc64: Register sync failed... If you're using kvm-hv.ko, only "-cpu host" is possible qemu-system-ppc64: kvm_init_vcpu: kvm_arch_init_vcpu failed (0): Invalid argument Appending '-cpu host' will throw another error: qemu-system-ppc64: invalid chip model 'host' for powernv9 machine The root cause is that in IBM PowerPC we have different specs for the bare-metal and the guests. The bare-metal follows OPAL, the guests follow PAPR. The kernel KVM modules presented in the ppc kernels implements PAPR. This means that we can't use KVM accel when using the powernv machine, which is the emulation of the bare-metal host. All that said, let's give a more informative error in this case. Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20211130133153.444601-2-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17pci-host: Allow extended config space access for PowerNV PHB4 modelChristophe Lombard1-0/+1
The PCIe extended configuration space on the device is not currently accessible to the host. if by default, it is still inaccessible for conventional for PCIe buses, add the current flag PCI_BUS_EXTENDED_CONFIG_SPACE on the root bus permits PCI-E extended config space access. Signed-off-by: Christophe Lombard <clombard@linux.vnet.ibm.com> Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211109145053.43524-1-clombard@linux.vnet.ibm.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17ivshmem.c: change endianness to LITTLE_ENDIANDaniel Henrique Barboza1-1/+1
The ivshmem device, as with most PCI devices, uses little endian byte order. However, the endianness of its mmio_ops is marked as DEVICE_NATIVE_ENDIAN. This presents not only the usual problems with big endian hosts but also with PowerPC little endian hosts as well, since the Power architecture in QEMU uses big endian hardware (XIVE controller, PCI Host Bridges, etc) even if the host is in little endian byte order. As it is today, the IVPosition of the device will be byte swapped when running in Power BE and LE. This can be seen by changing the existing qtest 'ivshmem-test' to run in ppc64 hosts and printing the IVPOSITION regs in test_ivshmem_server() right after the VM ids assert. For x86_64 the VM id values read are '0' and '1', for ppc64 (tested in a Power8 RHEL 7.9 BE server) and ppc64le (tested in a Power9 RHEL 8.6 LE server) the ids will be '0' and '0x1000000'. Change this device to LITTLE_ENDIAN fixes the issue for Power hosts of both endianness, and every other big-endian architecture that might use this device, without impacting x86 users. Fixes: cb06608e17f8 ("ivshmem: convert to memory API") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/168 Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20211124092948.335389-2-danielhb413@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17hw/ppc/mac.h: Remove MAX_CPUS macroPeter Maydell3-5/+4
The mac.h header defines a MAX_CPUS macro. This is confusingly named, because it suggests it's a generic setting, but in fact it's used by only the g3beige and mac99 machines. It's also using a single macro for two values which aren't inherently the same -- if one of these two machines was updated to support SMP configurations then it would want a different max_cpus value to the other. Since the macro is used in only two places, just expand it out and get rid of it. If hypothetical future work to support SMP in these boards needs a compile-time-known limit on the number of CPUs, we can give it a suitable name at that point. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20211105184216.120972-1-peter.maydell@linaro.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-12-17hw/virtio/vhost: Fix typo in comment.Leonardo Garcia1-1/+1
Signed-off-by: Leonardo Garcia <lagarcia@br.ibm.com> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <a10a0ddab65b474ebea1e1141abe0f4aa463909b.1637668012.git.lagarcia@br.ibm.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-12-17hw/avr: Realize AVRCPU qdev object using qdev_realize()Philippe Mathieu-Daudé1-1/+1
TYPE_AVR_CPU inherits TYPE_CPU, which itself inherits TYPE_DEVICE. TYPE_DEVICE instances are realized using qdev_realize(), we don't need to access QOM internal values. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Michael Rolnik <mrolnik@gmail.com> Message-Id: <20211205224109.322152-1-f4bug@amsat.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-12-17s390x/pci: add supported DT information to clp responseMatthew Rosato3-0/+3
The DTSM is a mask that specifies which I/O Address Translation designation types are supported. Today QEMU only supports DT=1. Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Message-Id: <20211203142706.427279-5-mjrosato@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-12-17s390x/pci: use the passthrough measurement update intervalMatthew Rosato1-2/+3
We may have gotten a measurement update interval from the underlying host via vfio -- Use it to set the interval via which we update the function measurement block. Fixes: 28dc86a072 ("s390x/pci: use a PCI Group structure") Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Message-Id: <20211203142706.427279-4-mjrosato@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-12-17s390x/pci: don't use hard-coded dma range in reg_ioatMatthew Rosato1-4/+5
Instead use the values from clp info, they will either be the hard-coded values or what came from the host driver via vfio. Fixes: 9670ee752727 ("s390x/pci: use a PCI Function structure") Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Message-Id: <20211203142706.427279-3-mjrosato@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2021-12-16Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into stagingRichard Henderson6-14/+98
* improve compatibility for macOS scripts/entitlement.sh (Evan) * add support for KVM_GUESTDBG_BLOCKIRQ (Maxim) * update linux-headers to Linux 5.16 (myself) * configure cleanups (myself) * lsi53c895a assertion failure fix (Philippe) * fix incorrect description for die-id (Yanan) * support for NUMA in SGX enclave memory (Yang Zhong) # gpg: Signature made Wed 15 Dec 2021 02:49:44 AM PST # gpg: using RSA key F13338574B662389866C7682BFFBD25F78C7AE83 # gpg: issuer "pbonzini@redhat.com" # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [unknown] # gpg: aka "Paolo Bonzini <pbonzini@redhat.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: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * tag 'for-upstream' of https://gitlab.com/bonzini/qemu: configure: remove dead variables doc: Add the SGX numa description numa: Support SGX numa in the monitor and Libvirt interfaces numa: Enable numa for SGX EPC sections kvm: add support for KVM_GUESTDBG_BLOCKIRQ gdbstub, kvm: let KVM report supported singlestep flags gdbstub: reject unsupported flags in handle_set_qemu_sstep linux-headers: update to 5.16-rc1 virtio-gpu: do not byteswap padding scripts/entitlement.sh: Use backward-compatible cp flags qapi/machine.json: Fix incorrect description for die-id tests/qtest: Add fuzz-lsi53c895a-test hw/scsi/lsi53c895a: Do not abort when DMA requested and no data queued Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-12-15Merge tag 'pull-block-2021-12-15' of git://repo.or.cz/qemu/armbru into stagingRichard Henderson24-73/+78
Block device patches patches for 2021-12-15 # gpg: Signature made Wed 15 Dec 2021 05:58:14 AM PST # gpg: using RSA key 354BC8B3D7EB2A6B68674E5F3870B400EB918653 # gpg: issuer "armbru@redhat.com" # gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" [full] # gpg: aka "Markus Armbruster <armbru@pond.sub.org>" [full] * tag 'pull-block-2021-12-15' of git://repo.or.cz/qemu/armbru: blockdev: Drop unused drive_get_next() hw/arm/aspeed: Replace drive_get_next() by drive_get() hw/arm/xilinx_zynq: Replace drive_get_next() by drive_get() hw/arm/xlnx-zcu102: Replace drive_get_next() by drive_get() hw/microblaze: Replace drive_get_next() by drive_get() hw/arm/xlnx-versal-virt: Replace drive_get_next() by drive_get() hw/arm/mcimx7d-sabre: Replace drive_get_next() by drive_get() hw/arm/mcimx6ul-evk: Replace drive_get_next() by drive_get() hw/arm/imx25_pdk: Replace drive_get_next() by drive_get() hw/arm/versatilepb hw/arm/vexpress: Replace drive_get_next() by drive_get() hw/arm/npcm7xx_boards: Replace drive_get_next() by drive_get() hw: Replace trivial drive_get_next() by drive_get() hw/sd/ssi-sd: Do not create SD card within controller's realize Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-12-15Merge tag 'pull-target-arm-20211215' of ↵Richard Henderson19-65/+93
https://git.linaro.org/people/pmaydell/qemu-arm into staging target-arm queue: * ITS: error reporting cleanup * aspeed: improve documentation * Fix STM32F2XX USART data register readout * allow emulated GICv3 to be disabled in non-TCG builds * fix exception priority for singlestep, misaligned PC, bp, etc * Correct calculation of tlb range invalidate length * npcm7xx_emc: fix missing queue_flush * virt: Add VIOT ACPI table for virtio-iommu * target/i386: Use assert() to sanity-check b1 in SSE decode * Don't include qemu-common unnecessarily # gpg: Signature made Wed 15 Dec 2021 02:39:37 AM PST # gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE # gpg: issuer "peter.maydell@linaro.org" # gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [full] # gpg: aka "Peter Maydell <pmaydell@gmail.com>" [full] # gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [full] * tag 'pull-target-arm-20211215' of https://git.linaro.org/people/pmaydell/qemu-arm: (33 commits) tests/acpi: add expected blob for VIOT test on virt machine tests/acpi: add expected blobs for VIOT test on q35 machine tests/acpi: add test case for VIOT tests/acpi: allow updates of VIOT expected data files hw/arm/virt: Use object_property_set instead of qdev_prop_set hw/arm/virt: Reject instantiation of multiple IOMMUs hw/arm/virt: Remove device tree restriction for virtio-iommu hw/arm/virt-acpi-build: Add VIOT table for virtio-iommu hw/net: npcm7xx_emc fix missing queue_flush target/arm: Correct calculation of tlb range invalidate length hw/arm: Don't include qemu-common.h unnecessarily target/rx/cpu.h: Don't include qemu-common.h target/hexagon/cpu.h: don't include qemu-common.h include/hw/i386: Don't include qemu-common.h in .h files target/i386: Use assert() to sanity-check b1 in SSE decode tests/tcg: Add arm and aarch64 pc alignment tests target/arm: Suppress bp for exceptions with more priority target/arm: Assert thumb pc is aligned target/arm: Take an exception if PC is misaligned target/arm: Split compute_fsr_fsc out of arm_deliver_fault ... Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2021-12-15hw/arm/aspeed: Replace drive_get_next() by drive_get()Markus Armbruster1-8/+13
drive_get_next() is basically a bad idea. It returns the "next" block backend of a certain interface type. "Next" means bus=0,unit=N, where subsequent calls count N up from zero, per interface type. This lets you define unit numbers implicitly by execution order. If the order changes, or new calls appear "in the middle", unit numbers change. ABI break. Hard to spot in review. The aspeed machines connects backends with drive_get_next() in several counting loops, one of them in a helper function, and a conditional. Change it to use drive_get() directly. This makes the unit numbers explicit in the code. Cc: "Cédric Le Goater" <clg@kaod.org> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Andrew Jeffery <andrew@aj.id.au> Cc: Joel Stanley <joel@jms.id.au> Cc: qemu-arm@nongnu.org Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20211117163409.3587705-13-armbru@redhat.com> Reviewed-by: Cédric Le Goater <clg@kaod.org>
2021-12-15hw/arm/xilinx_zynq: Replace drive_get_next() by drive_get()Markus Armbruster1-7/+9
drive_get_next() is basically a bad idea. It returns the "next" block backend of a certain interface type. "Next" means bus=0,unit=N, where subsequent calls count N up from zero, per interface type. This lets you define unit numbers implicitly by execution order. If the order changes, or new calls appear "in the middle", unit numbers change. ABI break. Hard to spot in review. Machine "xlnx-zcu102" connects backends with drive_get_next() in two counting loops, one of them in a helper function. Change it to use drive_get() directly. This makes the unit numbers explicit in the code. Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com> Cc: Alistair Francis <alistair@alistair23.me> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: qemu-arm@nongnu.org Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20211117163409.3587705-12-armbru@redhat.com> Acked-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
2021-12-15hw/arm/xlnx-zcu102: Replace drive_get_next() by drive_get()Markus Armbruster1-3/+3
drive_get_next() is basically a bad idea. It returns the "next" block backend of a certain interface type. "Next" means bus=0,unit=N, where subsequent calls count N up from zero, per interface type. This lets you define unit numbers implicitly by execution order. If the order changes, or new calls appear "in the middle", unit numbers change. ABI break. Hard to spot in review. Machine "xlnx-zcu102" connects backends with drive_get_next() in several counting loops. Change it to use drive_get() directly. This makes the unit numbers explicit in the code. Cc: Alistair Francis <alistair@alistair23.me> Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: qemu-arm@nongnu.org Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20211117163409.3587705-11-armbru@redhat.com> Acked-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
2021-12-15hw/arm/virt: Use object_property_set instead of qdev_prop_setJean-Philippe Brucker1-2/+3
To propagate errors to the caller of the pre_plug callback, use the object_poperty_set*() functions directly instead of the qdev_prop_set*() helpers. Suggested-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Message-id: 20211210170415.583179-5-jean-philippe@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-12-15hw/arm/virt: Reject instantiation of multiple IOMMUsJean-Philippe Brucker1-0/+5
We do not support instantiating multiple IOMMUs. Before adding a virtio-iommu, check that no other IOMMU is present. This will detect both "iommu=smmuv3" machine parameter and another virtio-iommu instance. Fixes: 70e89132c9 ("hw/arm/virt: Add the virtio-iommu device tree mappings") Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Message-id: 20211210170415.583179-4-jean-philippe@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-12-15hw/arm/virt: Remove device tree restriction for virtio-iommuJean-Philippe Brucker2-18/+4
virtio-iommu is now supported with ACPI VIOT as well as device tree. Remove the restriction that prevents from instantiating a virtio-iommu device under ACPI. Acked-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Message-id: 20211210170415.583179-3-jean-philippe@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-12-15hw/arm/virt-acpi-build: Add VIOT table for virtio-iommuJean-Philippe Brucker2-0/+8
When a virtio-iommu is instantiated, describe it using the ACPI VIOT table. Acked-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Message-id: 20211210170415.583179-2-jean-philippe@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-12-15hw/net: npcm7xx_emc fix missing queue_flushPatrick Venture1-10/+8
The rx_active boolean change to true should always trigger a try_read call that flushes the queue. Signed-off-by: Patrick Venture <venture@google.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20211203221002.1719306-1-venture@google.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-12-15hw/arm: Don't include qemu-common.h unnecessarilyPeter Maydell8-8/+0
A lot of C files in hw/arm include qemu-common.h when they don't need anything from it. Drop the include lines. omap1.c, pxa2xx.c and strongarm.c retain the include because they use it for the prototype of qemu_get_timedate(). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Taylor Simpson <tsimpson@quicinc.com> Reviewed-by: Yoshinori Sato <ysato@users.sourceforge.jp> Message-id: 20211129200510.1233037-5-peter.maydell@linaro.org
2021-12-15hw/intc/arm_gicv3: Introduce CONFIG_ARM_GIC_TCG Kconfig selectorPhilippe Mathieu-Daudé3-5/+12
The TYPE_ARM_GICV3 device is an emulated one. When using KVM, it is recommended to use the TYPE_KVM_ARM_GICV3 device (which uses in-kernel support). When using --with-devices-FOO, it is possible to build a binary with a specific set of devices. When this binary is restricted to KVM accelerator, the TYPE_ARM_GICV3 device is irrelevant, and it is desirable to remove it from the binary. Therefore introduce the CONFIG_ARM_GIC_TCG Kconfig selector which select the files required to have the TYPE_ARM_GICV3 device, but also allowing to de-select this device. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20211115223619.2599282-3-philmd@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-12-15hw/intc/arm_gicv3: Extract gicv3_set_gicv3state from arm_gicv3_cpuif.cPhilippe Mathieu-Daudé3-9/+24
gicv3_set_gicv3state() is used by arm_gicv3_common.c in arm_gicv3_common_realize(). Since we want to restrict arm_gicv3_cpuif.c to TCG, extract gicv3_set_gicv3state() to a new file. Add this file to the meson 'specific' source set, since it needs access to "cpu.h". Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20211115223619.2599282-2-philmd@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-12-15Fix STM32F2XX USART data register readoutOlivier Hériveaux1-1/+2
Fix issue where the data register may be overwritten by next character reception before being read and returned. Signed-off-by: Olivier Hériveaux <olivier.heriveaux@ledger.fr> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20211128120723.4053-1-olivier.heriveaux@ledger.fr Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-12-15hw/intc: clean-up error reporting for failed ITS cmdAlex Bennée1-12/+27
While trying to debug a GIC ITS failure I saw some guest errors that had poor formatting as well as leaving me confused as to what failed. As most of the checks aren't possible without a valid dte split that check apart and then check the other conditions in steps. This avoids us relying on undefined data. I still get a failure with the current kvm-unit-tests but at least I know (partially) why now: Exception return from AArch64 EL1 to AArch64 EL1 PC 0x40080588 PASS: gicv3: its-trigger: inv/invall: dev2/eventid=20 now triggers an LPI ITS: MAPD devid=2 size = 0x8 itt=0x40430000 valid=0 INT dev_id=2 event_id=20 process_its_cmd: invalid command attributes: invalid dte: 0 for 2 (MEM_TX: 0) PASS: gicv3: its-trigger: mapd valid=false: no LPI after device unmap SUMMARY: 6 tests, 1 unexpected failures Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20211112170454.3158925-1-alex.bennee@linaro.org Cc: Shashi Mallela <shashi.mallela@linaro.org> Cc: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-12-15hw/microblaze: Replace drive_get_next() by drive_get()Markus Armbruster1-1/+1
drive_get_next() is basically a bad idea. It returns the "next" block backend of a certain interface type. "Next" means bus=0,unit=N, where subsequent calls count N up from zero, per interface type. This lets you define unit numbers implicitly by execution order. If the order changes, or new calls appear "in the middle", unit numbers change. ABI break. Hard to spot in review. Machine "petalogix-ml605" connects backends with drive_get_next() in a counting loop. Change it to use drive_get() directly. This makes the unit numbers explicit in the code. Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20211117163409.3587705-10-armbru@redhat.com> Acked-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
2021-12-15hw/arm/xlnx-versal-virt: Replace drive_get_next() by drive_get()Markus Armbruster1-1/+2
drive_get_next() is basically a bad idea. It returns the "next" block backend of a certain interface type. "Next" means bus=0,unit=N, where subsequent calls count N up from zero, per interface type. This lets you define unit numbers implicitly by execution order. If the order changes, or new calls appear "in the middle", unit numbers change. ABI break. Hard to spot in review. Machine "xlnx-versal-virt" connects backends with drive_get_next() in a counting loop. Change it to use drive_get() directly. This makes the unit numbers explicit in the code. Cc: Alistair Francis <alistair@alistair23.me> Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: qemu-arm@nongnu.org Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20211117163409.3587705-9-armbru@redhat.com> Acked-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com>
2021-12-15hw/arm/mcimx7d-sabre: Replace drive_get_next() by drive_get()Markus Armbruster1-1/+1
drive_get_next() is basically a bad idea. It returns the "next" block backend of a certain interface type. "Next" means bus=0,unit=N, where subsequent calls count N up from zero, per interface type. This lets you define unit numbers implicitly by execution order. If the order changes, or new calls appear "in the middle", unit numbers change. ABI break. Hard to spot in review. Machine "mcimx7d-sabre" connects backends with drive_get_next() in a counting loop. Change it to use drive_get() directly. This makes the unit numbers explicit in the code. Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Andrey Smirnov <andrew.smirnov@gmail.com> Cc: qemu-arm@nongnu.org Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20211117163409.3587705-8-armbru@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
2021-12-15hw/arm/mcimx6ul-evk: Replace drive_get_next() by drive_get()Markus Armbruster1-1/+1
drive_get_next() is basically a bad idea. It returns the "next" block backend of a certain interface type. "Next" means bus=0,unit=N, where subsequent calls count N up from zero, per interface type. This lets you define unit numbers implicitly by execution order. If the order changes, or new calls appear "in the middle", unit numbers change. ABI break. Hard to spot in review. Machine "mcimx6ul-evk" connects backends with drive_get_next() in a counting loop. Change it to use drive_get() directly. This makes the unit numbers explicit in the code. Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Jean-Christophe Dubois <jcd@tribudubois.net> Cc: qemu-arm@nongnu.org Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20211117163409.3587705-7-armbru@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
2021-12-15hw/arm/imx25_pdk: Replace drive_get_next() by drive_get()Markus Armbruster1-1/+1
drive_get_next() is basically a bad idea. It returns the "next" block backend of a certain interface type. "Next" means bus=0,unit=N, where subsequent calls count N up from zero, per interface type. This lets you define unit numbers implicitly by execution order. If the order changes, or new calls appear "in the middle", unit numbers change. ABI break. Hard to spot in review. Machine "imx25-pdk" connects backends with drive_get_next() in a counting loop. Change it to use drive_get() directly. This makes the unit numbers explicit in the code. Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Jean-Christophe Dubois <jcd@tribudubois.net> Cc: qemu-arm@nongnu.org Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20211117163409.3587705-6-armbru@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
2021-12-15hw/arm/versatilepb hw/arm/vexpress: Replace drive_get_next() by drive_get()Markus Armbruster2-5/+5
drive_get_next() is basically a bad idea. It returns the "next" block backend of a certain interface type. "Next" means bus=0,unit=N, where subsequent calls count N up from zero, per interface type. This lets you define unit numbers implicitly by execution order. If the order changes, or new calls appear "in the middle", unit numbers change. ABI break. Hard to spot in review. The versatile and vexpress machines ("versatileab", "versatilepb", "vexpress-a9", "vexpress-a15") connect just one or two backends of a type with drive_get_next(). Change them to use drive_get() directly. This makes the unit numbers explicit in the code. Cc: Peter Maydell <peter.maydell@linaro.org> Cc: qemu-arm@nongnu.org Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20211117163409.3587705-5-armbru@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
2021-12-15hw/arm/npcm7xx_boards: Replace drive_get_next() by drive_get()Markus Armbruster1-3/+3
drive_get_next() is basically a bad idea. It returns the "next" block backend of a certain interface type. "Next" means bus=0,unit=N, where subsequent calls count N up from zero, per interface type. This lets you define unit numbers implicitly by execution order. If the order changes, or new calls appear "in the middle", unit numbers change. ABI break. Hard to spot in review. Machine "quanta-gbs-bmc" connects just one backend with drive_get_next(), but with a helper function. Change it to use drive_get() directly. This makes the unit numbers explicit in the code. Cc: Havard Skinnemoen <hskinnemoen@google.com> Cc: Tyrone Ting <kfting@nuvoton.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: qemu-arm@nongnu.org Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20211117163409.3587705-4-armbru@redhat.com> Reviewed-by: Havard Skinnemoen <hskinnemoen@google.com>
2021-12-15hw: Replace trivial drive_get_next() by drive_get()Markus Armbruster11-12/+12
drive_get_next() is basically a bad idea. It returns the "next" block backend of a certain interface type. "Next" means bus=0,unit=N, where subsequent calls count N up from zero, per interface type. This lets you define unit numbers implicitly by execution order. If the order changes, or new calls appear "in the middle", unit numbers change. ABI break. Hard to spot in review. A number of machines connect just one backend with drive_get_next(). Change them to use drive_get() directly. This makes the (zero) unit number explicit in the code. Cc: Beniamino Galvani <b.galvani@gmail.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Subbaraya Sundeep <sundeep.lkml@gmail.com> Cc: Niek Linnenbank <nieklinnenbank@gmail.com> Cc: Andrew Baumann <Andrew.Baumann@microsoft.com> Cc: "Philippe Mathieu-Daudé" <f4bug@amsat.org> Cc: Jean-Christophe Dubois <jcd@tribudubois.net> Cc: Alistair Francis <Alistair.Francis@wdc.com> Cc: Bin Meng <bin.meng@windriver.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Artyom Tarasenko <atar4qemu@gmail.com> Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Cc: Michael Tokarev <mjt@tls.msk.ru> Cc: Laurent Vivier <laurent@vivier.eu> Cc: qemu-arm@nongnu.org Cc: qemu-riscv@nongnu.org Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20211117163409.3587705-3-armbru@redhat.com>
2021-12-15hw/sd/ssi-sd: Do not create SD card within controller's realizeMarkus Armbruster3-30/+27
ssi_sd_realize() creates an "sd-card" device. This is inappropriate, and marked FIXME. Move it to the boards that create these devices. Prior art: commit eb4f566bbb for device "generic-sdhci", and commit 26c607b86b for device "pl181". The device remains not user-creatable, because its users should (and do) wire up its GPIO chip-select line. Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Alistair Francis <Alistair.Francis@wdc.com> Cc: Bin Meng <bin.meng@windriver.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: "Philippe Mathieu-Daudé" <f4bug@amsat.org> Cc: qemu-arm@nongnu.org Cc: qemu-riscv@nongnu.org Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20211117163409.3587705-2-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
generated by cgit v1.1 at 2025-01-11 15:27:33 +0000