aboutsummaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)AuthorFilesLines
2024-12-31hw/i386: Mark devices as little-endianPhilippe Mathieu-Daudé5-6/+6
These devices are only used by the X86 targets, which are only built as little-endian. Therefore the DEVICE_NATIVE_ENDIAN definition expand to DEVICE_LITTLE_ENDIAN (besides, the DEVICE_BIG_ENDIAN case isn't tested). Simplify directly using DEVICE_LITTLE_ENDIAN. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Message-Id: <20241106184612.71897-2-philmd@linaro.org>
2024-12-31hw/microblaze: Propagate CPU endianness to microblaze_load_kernel()Philippe Mathieu-Daudé5-9/+9
Pass vCPU endianness as argument so we can load kernels with different endianness (different from the qemu-system-binary builtin one). Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Anton Johansson <anjo@rev.ng> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@amd.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20241107012223.94337-3-philmd@linaro.org>
2024-12-31hw/usb/uhci: Introduce and use register definesGuenter Roeck1-16/+16
Introduce defines for UHCI registers to simplify adding register access in subsequent patches of the series. No functional change. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Cédric Le Goater <clg@redhat.com> Message-ID: <20240906122542.3808997-3-linux@roeck-us.net> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-12-31hw/usb/uhci: checkpatch cleanupGuenter Roeck1-34/+56
Fix reported checkpatch issues to prepare for next patches in the series. No functional change. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Cédric Le Goater <clg@redhat.com> Message-ID: <20240906122542.3808997-2-linux@roeck-us.net> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-12-31hw/misc/ivshmem: Rename ivshmem to ivshmem-pciGustavo Romero2-1/+1
Because now there is also an MMIO ivshmem device (ivshmem-flat.c), and ivshmem.c is a PCI specific implementation, rename it to ivshmem-pci.c. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org> Message-ID: <20241216141818.111255-5-gustavo.romero@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-12-31hw/misc/ivshmem-flat: Add ivshmem-flat deviceGustavo Romero4-0/+482
Add a new device, ivshmem-flat, which is similar to the ivshmem PCI but does not require a PCI bus. It's meant to be used on machines like those with Cortex-M MCUs, which usually lack a PCI/PCIe bus, e.g. lm3s6965evb and mps2-an385. The device currently only supports the sysbus bus. The new device, just like the ivshmem PCI device, supports both peer notification via hardware interrupts and shared memory. The device shared memory size can be set using the 'shmem-size' option and it defaults to 4 MiB, which is the default size of shmem allocated by the ivshmem server. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1134 Signed-off-by: Gustavo Romero <gustavo.romero@linaro.org> [PMD: Rebased updating Property and using DEFINE_TYPES macro] Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20241216141818.111255-2-gustavo.romero@linaro.org>
2024-12-30hw/pci-host/gpex: Allow more than 4 legacy IRQsAlexander Graf10-33/+58
Some boards such as vmapple don't do real legacy PCI IRQ swizzling. Instead, they just keep allocating more board IRQ lines for each new legacy IRQ. Let's support that mode by giving instantiators a new "nr_irqs" property they can use to support more than 4 legacy IRQ lines. In this mode, GPEX will export more IRQ lines, one for each device. Signed-off-by: Alexander Graf <graf@amazon.com> Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu> Reviewed-by: Akihiko Odaki <akihiko.odaki@daynix.com> Tested-by: Akihiko Odaki <akihiko.odaki@daynix.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20241223221645.29911-9-phil@philjordan.eu> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
2024-12-29next-cube: add my copyright to the top of the fileMark Cave-Ayland1-0/+1
This series has involved rewriting and/or updating a considerable part of the next-cube emulation so update the copyright in next-cube.c to reflect this. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20241222130012.1013374-34-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29next-cube: rename old_scr2 and scr2_2 in next_scr2_rtc_update()Mark Cave-Ayland1-7/+7
Rename them to old_scr2_rtc and scr2_rtc to reflect that they contain the previous and current values of the SCR2 RTC bits. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Message-ID: <20241222130012.1013374-33-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29next-cube: move next_rtc_cmd_is_write() and next_rtc_data_in_irq() functionsMark Cave-Ayland1-86/+86
Move these functions in next-cube.c so that they are with the rest of the next-rtc functions. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Message-ID: <20241222130012.1013374-32-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29next-cube: add rtc-power-out named gpio to trigger the NEXT_PWR_I interruptMark Cave-Ayland1-4/+6
This allows us to decouple the next-pc and next-rtc devices from each other in next_rtc_data_in_irq(). Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-ID: <20241222130012.1013374-31-mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29next-cube: add rtc-cmd-reset named gpio to reset the rtc state machineMark Cave-Ayland1-4/+19
This allows us to decouple the next-pc and next-rtc devices from each other in next_scr2_rtc_update(). Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-ID: <20241222130012.1013374-30-mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29next-cube: use named gpio output for next-rtc dataMark Cave-Ayland1-6/+13
Add a named gpio output for the next-rtc data and then update next_rtc_data_in_irq() to drive the IRQ directly. This enables the next-rtc to next-pc data to be wired up using the standard qdev gpio APIs. At the same time rename the pc-rtc-data-in gpio to rtc-data-in which is possible now that the previous rtc-data-in gpio has been moved to the next-rtc device. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-ID: <20241222130012.1013374-29-mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29next-cube: move rtc-data-in gpio from next-pc to next-rtc deviceMark Cave-Ayland1-9/+17
Add a new rtc-data-out gpio to the next-pc device and wire it up to the next-rtc rtc-data-in gpio using the standard qdev gpio APIs. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Message-ID: <20241222130012.1013374-28-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29next-cube: move reset of next-rtc fields from next-pc to next-rtcMark Cave-Ayland1-5/+12
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Message-ID: <20241222130012.1013374-27-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29next-cube: QOMify NeXTRTCMark Cave-Ayland1-21/+50
This is to allow the RTC functionality to be maintained within its own separate device rather than as part of the next-pc device. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-ID: <20241222130012.1013374-26-mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29next-cube: don't use rtc phase value of -1Mark Cave-Ayland1-4/+1
The rtc phase value of -1 is directly equivalent to using a phase value of 0 so simplify the logic to use an initial rtc phase of 0. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Message-ID: <20241222130012.1013374-25-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29next-cube: use named gpio to read RTC data bit in scr2Mark Cave-Ayland1-77/+92
This is in preparation for moving NeXTRTC to its own separate device. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Message-ID: <20241222130012.1013374-24-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29next-cube: use named gpio to set RTC data bit in scr2Mark Cave-Ayland1-4/+21
This is in preparation for moving NeXTRTC to its own separate device. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Message-ID: <20241222130012.1013374-23-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29next-cube: always use retval to return rtc read valuesMark Cave-Ayland1-59/+40
Instead of shifting out rtc read values from individual rtc registers, change the logic so that rtc read commands are executed when the last bit of the rtc command is received and the result stored in retval. This simplifies the rtc read logic such that the shift out logic can be consolidated for rtc phases between 8 and 16. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-ID: <20241222130012.1013374-22-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29next-cube: separate rtc read and write shift logicMark Cave-Ayland1-64/+74
Introduce a new next_rtc_cmd_is_write() function to determine if an rtc command is a read or write, and start by using it to avoid shifting the rtc input value if a rtc read command is executed. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Message-ID: <20241222130012.1013374-21-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29next-cube: use qemu_irq to drive int_status in next_scr2_rtc_update()Mark Cave-Ayland1-1/+4
Rather than directly clear bit 3 in int_status in next_scr2_rtc_update(), use a qemu_irq to drive the equivalent NEXT_PWR_I signal. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Message-ID: <20241222130012.1013374-20-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29next-cube: rename typedef struct NextRtc to NeXTRTCMark Cave-Ayland1-12/+12
This brings the capitalisation in line with the other NeXTCube definitions. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Message-ID: <20241222130012.1013374-19-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29next-cube: convert next-pc device to use Resettable interfaceMark Cave-Ayland1-3/+4
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Acked-by: Thomas Huth <huth@tuxfamily.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20241222130012.1013374-18-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29next-cube: rearrange NeXTState declarations to improve readabilityMark Cave-Ayland1-32/+32
Move the NeXTState, next_dma and TYPE_NEXT_MACHINE definition to the same area at the top of next-cube.c. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20241222130012.1013374-17-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29next-cube: remove unused next.scr memory regionMark Cave-Ayland1-52/+21
Now that the next.scr memory region is unused it can be removed and the next-pc devices mapped directly within the machine init function. This is the last remaining overlapping memory region within the NeXTCube machine. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Message-ID: <20241222130012.1013374-16-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29next-cube: add empty slots for unknown accesses to next.scr memory regionMark Cave-Ayland2-0/+9
The next.scr memory is now effectively unused, however there are 3 separate region accesses still logged that occur when booting a NeXTStep disk image. Use the empty_slot device to capture and ignore memory accesses to these 3 memory regions. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Message-ID: <20241222130012.1013374-15-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29next-cube: move en ethernet MMIO to separate memory region on next-pc deviceMark Cave-Ayland1-8/+40
Move the en ethernet MMIO accesses to a separate memory region on the next-pc device instead of being part of the next.scr MMIO memory region. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Message-ID: <20241222130012.1013374-14-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29next-cube: move timer MMIO to separate memory region on next-pc deviceMark Cave-Ayland1-13/+50
Move the timer MMIO accesses to a separate memory region on the next-pc device instead of being part of the next.scr MMIO memory region. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20241222130012.1013374-13-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29next-cube: move ESCC to be QOM child of next-pc deviceMark Cave-Ayland1-28/+26
Since the ESCC is part of the next-pc device, move the ESCC to be a QOM child of the next-pc device. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20241222130012.1013374-12-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29next-cube: map ESCC registers as a subregion of the next.scr memory regionMark Cave-Ayland1-1/+4
Since the ESCC device exists within the memory range of the next.scr memory region, map the ESCC device registers as a subregion of the next.scr memory region instead of directly to the system address space. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20241222130012.1013374-11-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29next-cube: move floppy disk MMIO to separate memory region in next-pcMark Cave-Ayland1-12/+49
The dummy floppy disk device is part of the next-pc device, and not related to the NeXTCube SCRs. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Message-ID: <20241222130012.1013374-10-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29next-cube: move SCSI 4020/4021 logic from next-pc device to next-scsi deviceMark Cave-Ayland1-77/+62
The SCSI 4020/4021 logic refers to the offset of the SCSI CSRs within the NeXTCube address space. Due to the previously overlapping memory regions, there were duplicate MMIO accessors in the next.scr memory region for these registers but this has now been resolved. Move the remaining SCSI 4020/4021 logic from the next-pc device to the next-scsi device, with the exception that the SCSI 4021 register now returns its previous value like a normal register instead of a hardcoded 0x40 value. This also matches how the registers are implemented in the Previous emulator. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Message-ID: <20241222130012.1013374-9-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29next-cube: move SCSI CSRs from next-pc to the next-scsi deviceMark Cave-Ayland1-10/+78
The SCSI CSRs are located within the SCSI subsystem of the NeXT PC (Peripheral Contoller) which is now modelled as a separate QEMU device. Add a new memory region subregion to contain the SCSI CSRs that simply store and retrieve the register values. Add a new VMStateDescription for the next-scsi device to enable the SCSI CSRs to be migrated. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Message-ID: <20241222130012.1013374-8-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29next-cube: introduce next-scsi deviceMark Cave-Ayland1-19/+74
This device is intended to hold the ESP SCSI controller and the NeXT SCSI CSRs. Start by creating the device and moving the ESP SCSI controller to be an embedded child device. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Message-ID: <20241222130012.1013374-7-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29next-cube: introduce next_pc_init() object init functionMark Cave-Ayland1-6/+11
Move initialisation of the memory regions and GPIOs from next_pc_realize() to the new next_pc_init() function. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Message-ID: <20241222130012.1013374-6-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29next-cube: move next_scsi_init() to next_pc_realize()Mark Cave-Ayland1-2/+3
This reflects that the SCSI interface exists within the NeXT Peripheral Controller (PC). Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Message-ID: <20241222130012.1013374-5-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29next-cube: create new next.scsi container memory regionMark Cave-Ayland1-1/+7
Move the ESP SCSI and SCSI CSR registers to the new next.scsi container memory region. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20241222130012.1013374-4-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29next-cube: remove overlap between next.dma and next.mmio memory regionsMark Cave-Ayland1-14/+14
Change the start of the next.mmio memory region so that it follows on directly after the next.dma memory region. Increase the address offsets in next_mmio_read() and next_mmio_write(), and reduce the size of the next.mmio memory region accordingly. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Message-ID: <20241222130012.1013374-3-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29next-cube: remove 0x14020 dummy value from next_mmio_read()Mark Cave-Ayland1-4/+0
This is a dummy value for the SCSI CSR which appears to have no effect when removed. Eventually the reads/writes to this register will be directed towards the WIP implementations in next_scr_readfn() and next_scr_writefn(). Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Thomas Huth <huth@tuxfamily.org> Message-ID: <20241222130012.1013374-2-mark.cave-ayland@ilande.co.uk> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29hw/m68k/next-cube: Disable the default CD-ROM driveThomas Huth1-0/+1
The NeXT-Cube does not have a CD-ROM drive by default, and the kernel does not seem to deal with the empty drive very well, so let's disable the CD-ROM drive for this machine. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-ID: <20241214091720.49779-1-huth@tuxfamily.org> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-29hw/m68k: Mark devices as big-endianPhilippe Mathieu-Daudé4-6/+6
These devices are only used by the M68K target, which is only built as big-endian. Therefore the DEVICE_NATIVE_ENDIAN definition expand to DEVICE_BIG_ENDIAN (besides, the DEVICE_LITTLE_ENDIAN case isn't tested). Simplify directly using DEVICE_BIG_ENDIAN. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20241106184612.71897-4-philmd@linaro.org> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2024-12-28Merge tag 'pull-trivial-patches' of https://gitlab.com/mjt0k/qemu into stagingStefan Hajnoczi3-2/+8
trivial patches for 2024-12-28 # -----BEGIN PGP SIGNATURE----- # # iQIzBAABCgAdFiEEZKoqtTHVaQM2a/75gqpKJDselHgFAmdv5ucACgkQgqpKJDse # lHhneA//UIqio45IfMUFwlug8b4Cf/PRYU5+lgKh0SUOn4qpWS7IgF+zXWfk9/IF # Qg9NH1TVTbEzAyHBhpSUUHPpxfPctcoDGCFVU6dYbgBmGjvQa/ov9Hl7B3Q28i6+ # 9K2bRWCDLm05RXHIW2BeBSIXjla9AnE+THQa3dTmrKN4s3WP3+dx96k8sLt0DQQB # 5tT0ilnl3kW4Zhc/4NvDZoxam6Uo8U5EC5xwvXqgfZGRKNwhaAHJVRctDIXiD55c # 2kyZBlV5XdIxLsMHRkzu+ArrS5VTslelDsK7spCOJmLdJ56ylXE2sI82PWwh2/Hg # GjQkpqKib4WWmlVmWL7TYupsoHodXSjYGzbv6rz7jk8xWc1tJ5iRmLdK03BWv4KN # G1PkOwiKmZrZtbdY5vz74OhKcqKlijewQJLsUvm7spmr4MqrMn/yEyuAKwyKG3/E # 9KweB5q5KsO0KybCJ4ScMAUCIe5cc7AqSOk3XOKFu+gToccBUG8480UjFldM2Btm # t8O+dvGJC0OyzlHDUEL4JfT155Kk81/zuKuqCi8dPNVy7juSRm8qNFDD+/GRmrXD # RfcXRCY7HKHMHYLHltPxhKQ011NASgxpb8VPi8rD64rR4dZIUWiHibkp+BmzsK8M # 9qvUi+a0qNhUlkLL9cFqUgVl8kUOlNFperBsmdi/qncGNiBwK0U= # =sH6V # -----END PGP SIGNATURE----- # gpg: Signature made Sat 28 Dec 2024 06:54:15 EST # gpg: using RSA key 64AA2AB531D56903366BFEF982AA4A243B1E9478 # gpg: Good signature from "Michael Tokarev <mjt@debian.org>" [unknown] # gpg: aka "Michael Tokarev <mjt@corpit.ru>" [unknown] # gpg: aka "Michael Tokarev <mjt@tls.msk.ru>" [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: 9D8B E14E 3F2A 9DD7 9199 28F1 61AD 3D98 ECDF 2C8E # Subkey fingerprint: 64AA 2AB5 31D5 6903 366B FEF9 82AA 4A24 3B1E 9478 * tag 'pull-trivial-patches' of https://gitlab.com/mjt0k/qemu: qmp: update vhost-user protocol feature maps contrib/plugins/bbv.c: Start bb index from 1 hw/riscv/riscv-iommu-sys.c: fix duplicated 'table_size' target/i386/cpu: Fix notes for CPU models docs: Replace 'since' -> 'removed in' in removed-features.rst docs: Correct release of TCG trace-events removal docs: Correct '-runas' and '-fsdev/-virtfs proxy' indentation vvfat: fix ubsan issue in create_long_filename hw/timer/hpet: Drop the unused macro hw/timer/hpet: Fix comment about capabilities register docs/devel: remove dead video link for sourcehut submit process Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2024-12-28qmp: update vhost-user protocol feature mapsLaurent Vivier1-0/+6
Add VHOST_USER_PROTOCOL_F_SHARED_OBJECT and VHOST_USER_PROTOCOL_F_DEVICE_STATE protocol feature maps to the virtio introspection. Cc: jonah.palmer@oracle.com Fixes: 160947666276 ("vhost-user: add shared_object msg") Cc: aesteve@redhat.com Fixes: cda83adc62b6 ("vhost-user: Interface for migration state transfer") Cc: hreitz@redhat.com Signed-off-by: Laurent Vivier <lvivier@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-12-28hw/riscv/riscv-iommu-sys.c: fix duplicated 'table_size'Daniel Henrique Barboza1-1/+1
Trivial fix for the following ticket: CID 1568580: Incorrect expression (EVALUATION_ORDER) In "table_size = table_size = n_vectors * 16U", "table_size" is written twice with the same value. Cc: qemu-trivial@nongnu.org Cc: Peter Maydell <peter.maydell@linaro.org> Resolves: Coverity CID 1568580 Fixes: 01c1caa9d1 ("hw/riscv/virt.c, riscv-iommu-sys.c: add MSIx support") Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-12-28hw/timer/hpet: Fix comment about capabilities registerZhao Liu1-1/+1
HPETState.capability stores the emulated value for "general capabilities and id register" instead of "main counter register". Fix the comment to accurately reflect this. Signed-off-by: Zhao Liu <zhao1.liu@intel.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2024-12-27hw/loongarch/virt: Improve fdt table creation for CPU objectBibo Mao1-14/+25
For CPU object, possible_cpu_arch_ids() function is used rather than smp.cpus. With command -smp x, -device la464-loongarch-cpu, smp.cpus is not accurate for all possible CPU objects, possible_cpu_arch_ids() is used here. Signed-off-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn>
2024-12-27hw/loongarch/virt: Create fdt table on machine creation done notificationBibo Mao1-46/+57
The same with ACPI table, fdt table is created on machine done notification. Some objects like CPU objects can be created with cold-plug method with command such as -smp x, -device la464-loongarch-cpu, so all objects finish to create when machine is done. Signed-off-by: Bibo Mao <maobibo@loongson.cn> Reviewed-by: Bibo Mao <maobibo@loongson.cn>
2024-12-26vfio/migration: Rename vfio_devices_all_dirty_tracking()Avihai Horon1-2/+2
vfio_devices_all_dirty_tracking() is used to check if dirty page log sync is needed. However, besides checking the dirty page tracking status, it also checks the pre_copy_dirty_page_tracking flag. Rename it to vfio_devices_log_sync_needed() which reflects its purpose more accurately and makes the code clearer as there are already several helpers with similar names. Signed-off-by: Avihai Horon <avihaih@nvidia.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com> Tested-by: Joao Martins <joao.m.martins@oracle.com> Link: https://lore.kernel.org/r/20241218134022.21264-5-avihaih@nvidia.com Signed-off-by: Cédric Le Goater <clg@redhat.com>
2024-12-26vfio/migration: Refactor vfio_devices_all_running_and_mig_active() logicAvihai Horon2-33/+9
During DMA unmap with vIOMMU, vfio_devices_all_running_and_mig_active() is used to check whether a dirty page log sync of the unmapped pages is required. Such log sync is needed during migration pre-copy phase, and the current logic detects it by checking if migration is active and if the VFIO devices are running. However, recently there has been an effort to simplify the migration status API and reduce it to a single migration_is_running() function. To accommodate this, refactor vfio_devices_all_running_and_mig_active() logic so it won't use migration_is_active(). Do it by simply checking if dirty tracking has been started using internal VFIO flags. This should be equivalent to the previous logic as during migration dirty tracking is active and when the guest is stopped there shouldn't be DMA unmaps coming from it. As a side effect, now that migration status is no longer used, DMA unmap log syncs are untied from migration. This will make calc-dirty-rate more accurate as now it will also include VFIO dirty pages that were DMA unmapped. Also rename the function to properly reflect its new logic and extract common code from vfio_devices_all_dirty_tracking(). Signed-off-by: Avihai Horon <avihaih@nvidia.com> Reviewed-by: Joao Martins <joao.m.martins@oracle.com> Tested-by: Joao Martins <joao.m.martins@oracle.com> Link: https://lore.kernel.org/r/20241218134022.21264-4-avihaih@nvidia.com Signed-off-by: Cédric Le Goater <clg@redhat.com>