riscv/qemu - qemu - Gitea: Git with a cup of tea

Commit Graph

Author	SHA1	Message	Date
Stefano Garzarella	3e59a2255d	cryptodev/vhost: allocate CryptoDevBackendVhost using g_mem0() The function `vhost_dev_init()` expects the `struct vhost_dev` (passed as a parameter) to be fully initialized. This is important because some parts of the code check whether `vhost_dev->config_ops` is NULL to determine if it has been set (e.g. later via `vhost_dev_set_config_notifier`). To ensure this initialization, it’s better to allocate the entire `CryptoDevBackendVhost` structure (which includes `vhost_dev`) using `g_mem0()`, following the same approach used for other vhost devices, such as in `vhost_net_init()`. Fixes: `042cea274c` ("cryptodev: add vhost-user as a new cryptodev backend") Cc: qemu-stable@nongnu.org Reported-by: myluo24@m.fudan.edu.cn Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Message-Id: <20250211135523.101203-1-sgarzare@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit `83cb18ac45`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Sairaj Kodilkar	d34cd1f2dc	amd_iommu: Use correct bitmask to set capability BAR AMD IOMMU provides the base address of control registers through IVRS table and PCI capability. Since this base address is of 64 bit, use 32 bits mask (instead of 16 bits) to set BAR low and high. Fixes: `d29a09ca68` ("hw/i386: Introduce AMD IOMMU") Signed-off-by: Sairaj Kodilkar <sarunkod@amd.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> Message-Id: <20250207045354.27329-3-sarunkod@amd.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit `3684717b74`) (Mjt: adjust for 7.2.x) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Philippe Mathieu-Daudé	e5cb461073	hw/i386/amd_iommu: Explicit use of AMDVI_BASE_ADDR in amdvi_init By accessing MemoryRegion internals, amdvi_init() gives the false idea that the PCI BAR can be modified. However this isn't true (at least the model isn't ready for that): the device is explicitly maps at the BAR at the fixed AMDVI_BASE_ADDR address in amdvi_sysbus_realize(). Since the SysBus API isn't designed to remap regions, directly use the fixed address in amdvi_init(). Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230313153031.86107-3-philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit `6291a28645`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	3 years ago
Sairaj Kodilkar	307224ae49	amd_iommu: Use correct DTE field for interrupt passthrough Interrupt passthrough is determine by the bits 191,190,187-184. These bits are part of the 3rd quad word (i.e. index 2) in DTE. Hence replace dte[3] by dte[2]. Fixes: `b44159fe0` ("x86_iommu/amd: Add interrupt remap support when VAPIC is not enabled") Signed-off-by: Sairaj Kodilkar <sarunkod@amd.com> Reviewed-by: Vasant Hegde <vasant.hegde@amd.com> Message-Id: <20250207045354.27329-2-sarunkod@amd.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit `63dc0b8647`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Bernhard Beschow	8b7ff3d4b7	Kconfig: Extract CONFIG_USB_CHIPIDEA from CONFIG_IMX TYPE_CHIPIDEA models an IP block which is also used in TYPE_ZYNQ_MACHINE which itself is not an IMX device. CONFIG_ZYNQ selects CONFIG_USB_EHCI_SYSBUS while TYPE_CHIPIDEA is a separate compilation unit, so only works by accident if CONFIG_IMX is given. Fix that by extracting CONFIG_USB_CHIPIDEA from CONFIG_IMX. cc: qemu-stable@nongnu.org Fixes: `616ec12d0f` "hw/arm/xilinx_zynq: Fix USB port instantiation" Signed-off-by: Bernhard Beschow <shentey@gmail.com> Message-id: 20250209103604.29545-1-shentey@gmail.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit `464ce71a96`) (Mjt: context fixup due to missing v8.0.0-1939-gde6cd7599b51 "meson: Replace softmmu_ss -> system_ss", v9.1.0-609-ge02491903d50 "hw/usb: Remove tusb6010 USB controller", v9.2.0-1303-g1b326f278d05 "hw/pci-host/designware: Expose MSI IRQ") Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Peter Maydell	a7e5c52e72	hw/intc/arm_gicv3_cpuif: Don't downgrade monitor traps for AArch32 EL3 In the gicv3_{irq,fiq,irqfiq}_access() functions, there is a check which downgrades a CP_ACCESS_TRAP_EL3 to CP_ACCESS_TRAP if EL3 is not AArch64. This has been there since the GIC was first implemented, but it isn't right: if we are trapping because of SCR.IRQ or SCR.FIQ then we definitely want to be going to EL3 (doing AArch32.TakeMonitorTrapException() in pseudocode terms). We might want to not take a trap at all, but we don't ever want to go to the default target EL, because that would mean, for instance, taking a trap to Hyp mode if the trapped access was made from Hyp mode. (This might have been an attempt to work around our failure to properly implement Monitor Traps.) Remove the bogus check. Cc: qemu-stable@nongnu.org Fixes: `359fbe65e0` ("hw/intc/arm_gicv3: Implement GICv3 CPU interface registers") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20250130182309.717346-7-peter.maydell@linaro.org (cherry picked from commit `d04c6c3c00`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Peter Maydell	8fd043112a	target/arm: Make CP_ACCESS_TRAPs to AArch32 EL3 be Monitor traps In system register access pseudocode the common pattern for AArch32 registers with access traps to EL3 is: at EL1 and EL2: if HaveEL(EL3) && !ELUsingAArch32(EL3) && (SCR_EL3.TERR == 1) then AArch64.AArch32SystemAccessTrap(EL3, 0x03); elsif HaveEL(EL3) && ELUsingAArch32(EL3) && (SCR.TERR == 1) then AArch32.TakeMonitorTrapException(); at EL3: if (PSTATE.M != M32_Monitor) && (SCR.TERR == 1) then AArch32.TakeMonitorTrapException(); (taking as an example the ERRIDR access pseudocode). This implements the behaviour of (in this case) SCR.TERR that "Accesses to the specified registers from modes other than Monitor mode generate a Monitor Trap exception" and of SCR_EL3.TERR that "Accesses of the specified Error Record registers at EL2 and EL1 are trapped to EL3, unless the instruction generates a higher priority exception". In QEMU we don't implement this pattern correctly in two ways: * in access_check_cp_reg() we turn the CP_ACCESS_TRAP_EL3 into an UNDEF, not a trap to Monitor mode * in the access functions, we check trap bits like SCR.TERR only when arm_current_el(env) < 3 -- this is correct for AArch64 EL3, but misses the "trap non-Monitor-mode execution at EL3 into Monitor mode" case for AArch32 EL3 In this commit we fix the first of these two issues, by making access_check_cp_reg() handle CP_ACCESS_TRAP_EL3 as a Monitor trap. This is a kind of exception that we haven't yet implemented(!), so we need a new EXCP_MON_TRAP for it. This diverges from the pseudocode approach, where every access check function explicitly checks for "if EL3 is AArch32" and takes a monitor trap; if we wanted to be closer to the pseudocode we could add a new CP_ACCESS_TRAP_MONITOR and make all the accessfns use it when appropriate. But because there are no non-standard cases in the pseudocode (i.e. where either it raises a Monitor trap that doesn't correspond to an AArch64 SystemAccessTrap or where it raises a SystemAccessTrap that doesn't correspond to a Monitor trap), handling this all in one place seems less likely to result in future bugs where we forgot again about this special case when writing an accessor. (The cc of stable here is because "hw/intc/arm_gicv3_cpuif: Don't downgrade monitor traps for AArch32 EL3" which is also cc:stable will implicitly use the new EXCP_MON_TRAP code path.) Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20250130182309.717346-6-peter.maydell@linaro.org (cherry picked from commit `4cf4948651`) (Mjt: context fix due to missing v9.0.0-151-gb36a32ead159 "target/arm: Add support for Non-maskable Interrupt", v8.0.0-2011-g11b76fda0adc "target/arm: Implement GPC exceptions") Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Peter Maydell	83e270868b	target/arm: Report correct syndrome for UNDEFINED LOR sysregs when NS=0 The pseudocode for the accessors for the LOR sysregs says they are UNDEFINED if SCR_EL3.NS is 0. We were reporting the wrong syndrome value here; use CP_ACCESS_TRAP_UNCATEGORIZED. Cc: qemu-stable@nongnu.org Fixes: `2d7137c10f` ("target/arm: Implement the ARMv8.1-LOR extension") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20250130182309.717346-5-peter.maydell@linaro.org (cherry picked from commit `707d478ed8`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Peter Maydell	d4b92c1914	target/arm: Report correct syndrome for UNDEFINED S1E2 AT ops at EL3 The pseudocode for AT S1E2R and AT S1E2W says that they should be UNDEFINED if executed at EL3 when EL2 is not enabled. We were incorrectly using CP_ACCESS_TRAP and reporting the wrong exception syndrome as a result. Use CP_ACCESS_TRAP_UNCATEGORIZED. Cc: qemu-stable@nongnu.org Fixes: `2a47df9532` ("target-arm: Wire up AArch64 EL2 and EL3 address translation ops") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20250130182309.717346-4-peter.maydell@linaro.org (cherry picked from commit `ccda792945`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Peter Maydell	74726f9129	target/arm: Report correct syndrome for UNDEFINED CNTPS_*_EL1 from EL2 and NS EL1 The access pseudocode for the CNTPS_TVAL_EL1, CNTPS_CTL_EL1 and CNTPS_CVAL_EL1 secure timer registers says that they are UNDEFINED from EL2 or NS EL1. We incorrectly return CP_ACCESS_TRAP from the access function in these cases, which means that we report the wrong syndrome value to the target EL. Use CP_ACCESS_TRAP_UNCATEGORIZED, which reports the correct syndrome value for an UNDEFINED instruction. Cc: qemu-stable@nongnu.org Fixes: `b4d3978c2f` ("target-arm: Add the AArch64 view of the Secure physical timer") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20250130182309.717346-2-peter.maydell@linaro.org (cherry picked from commit `b819fd6994`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Mikael Szreder	3085db5cad	target/sparc: Fix gdbstub incorrectly handling registers f32-f62 The gdbstub implementation for the Sparc architecture would incorrectly calculate the the floating point register offset. This resulted in, for example, registers f32 and f34 to point to the same value. The issue was caused by the confusion between even register numbers and even register indexes. For example, the register index of f32 is 64 and f34 is 65. Cc: qemu-stable@nongnu.org Fixes: `30038fd818` ("target-sparc: Change fpr representation to doubles.") Signed-off-by: Mikael Szreder <git@miszr.win> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-ID: <20250214070343.11501-1-git@miszr.win> (cherry picked from commit `7a74e46808`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Volker Rümelin	9d820b19b1	ui/sdl2: reenable the SDL2 Windows keyboard hook procedure Windows only: The libSDL2 Windows message loop needs the libSDL2 Windows low level keyboard hook procedure to grab the left and right Windows keys correctly. Reenable the SDL2 Windows keyboard hook procedure. Since SDL2 2.30.4 the SDL2 keyboard hook procedure also filters out the special left Control key event for every Alt Gr key event on keyboards with an international layout. This means the QEMU low level keyboard hook procedure is no longer needed. Remove the QEMU Windows keyboard hook procedure. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2139 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2323 Signed-off-by: Volker Rümelin <vr_qemu@t-online.de> Link: https://lore.kernel.org/r/20241231115950.6732-1-vr_qemu@t-online.de Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit `4dafba778a`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: context fix in ui/sdl2.c and adaptation in ui/meson.build)	2 years ago
Khem Raj	0f6b895992	linux-user: Do not define struct sched_attr if libc headers do glibc 2.41+ has added [1] definitions for sched_setattr and sched_getattr functions and struct sched_attr. Therefore, it needs to be checked for here as well before defining sched_attr, to avoid a compilation failure. Define sched_attr conditionally only when SCHED_ATTR_SIZE_VER0 is not defined. [1] https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=21571ca0d70302909cf72707b2a7736cf12190a0;hp=298bc488fdc047da37482f4003023cb9adef78f8 Signed-off-by: Khem Raj <raj.khem@gmail.com> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2799 Cc: qemu-stable@nongnu.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit `27a8d899c7`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Michael Tokarev	044e1dd76b	Update version for 7.2.16 release Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Hongren Zheng	0261682326	hw/usb/canokey: Fix buffer overflow for OUT packet When USBPacket in OUT direction has larger payload than the ep_out_buffer (of size 512), a buffer overflow would occur. It could be fixed by limiting the size of usb_packet_copy to be at most buffer size. Further optimization gets rid of the ep_out_buffer and directly uses ep_out as the target buffer. This is reported by a security researcher who artificially constructed an OUT packet of size 2047. The report has gone through the QEMU security process, and as this device is for testing purpose and no deployment of it in virtualization environment is observed, it is triaged not to be a security bug. Cc: qemu-stable@nongnu.org Fixes: `d7d3491855` ("hw/usb: Add CanoKey Implementation") Reported-by: Juan Jose Lopez Jaimez <thatjiaozi@gmail.com> Signed-off-by: Hongren Zheng <i@zenithal.me> Message-id: Z4TfMOrZz6IQYl_h@Sun Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit `664280abdd`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Peter Maydell	3559e90146	target/arm: arm_reset_sve_state() should set FPSR, not FPCR The pseudocode ResetSVEState() does: FPSR = ZeroExtend(0x0800009f<31:0>, 64); but QEMU's arm_reset_sve_state() called vfp_set_fpcr() by accident. Before the advent of FEAT_AFP, this was only setting a collection of RES0 bits, which vfp_set_fpsr() would then ignore, so the only effect was that we didn't actually set the FPSR the way we are supposed to do. Once FEAT_AFP is implemented, setting the bottom bits of FPSR will change the floating point behaviour. Call vfp_set_fpsr(), as we ought to. (Note for stable backports: commit `7f2a01e736` moved this function from sme_helper.c to helper.c, but it had the same bug before the move too.) Cc: qemu-stable@nongnu.org Fixes: `f84734b874` ("target/arm: Implement SMSTART, SMSTOP") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20250124162836.2332150-4-peter.maydell@linaro.org (cherry picked from commit `1edc3d43f2`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (it is in sme_helper.c in 7.2, not in helper.c)	2 years ago
Igor Mammedov	19bee15f89	tests: acpi: update expected blobs _DSM function 7 AML should have followig change: If ((Arg2 == 0x07)) { - Local0 = Package (0x02) - { - Zero, - "" - } Local2 = AIDX (DerefOf (Arg4 [Zero]), DerefOf (Arg4 [One] )) - Local0 [Zero] = Local2 + Local0 = Package (0x02) {} + If (!((Local2 == Zero) \|\| (Local2 == 0xFFFFFFFF))) + { + Local0 [Zero] = Local2 + Local0 [One] = "" + } + Return (Local0) } } Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20250115125342.3883374-4-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit `9fb1c9a1bb`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Igor Mammedov	89caa45bf3	pci: acpi: Windows 'PCI Label Id' bug workaround Current versions of Windows call _DSM(func=7) regardless of whether it is supported or not. It leads to NICs having bogus 'PCI Label Id = 0', where none should be set at all. Also presence of 'PCI Label Id' triggers another Windows bug on localized versions that leads to hangs. The later bug is fixed in latest updates for 'Windows Server' but not in consumer versions of Windows (and there is no plans to fix it as far as I'm aware). Given it's easy, implement Microsoft suggested workaround (return invalid Package) so that affected Windows versions could boot on QEMU. This would effectvely remove bogus 'PCI Label Id's on NICs, but MS teem confirmed that flipping 'PCI Label Id' should not change 'Network Connection' ennumeration, so it should be safe for QEMU to change _DSM without any compat code. Smoke tested with WinXP and WS2022 Resolves: https://gitlab.com/qemu-project/qemu/-/issues/774 Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20250115125342.3883374-3-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit `0b05339198`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Igor Mammedov	7171f0164c	tests: acpi: whitelist expected blobs Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20250115125342.3883374-2-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit `1ad32644fe`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: drop x86/ subdir and drop a few files not relevant for 7.2)	2 years ago
Nicholas Piggin	eddb763e3b	pci/msix: Fix msix pba read vector poll end calculation The end vector calculation has a bug that results in polling fewer than required vectors when reading at a non-zero offset in PBA memory. Fixes: `bbef882cc1` ("msi: add API to get notified about pending bit poll") Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20241212120402.1475053-1-npiggin@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit `42e2a7a0ab`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Sebastian Ott	6d1a80edaa	pci: ensure valid link status bits for downstream ports PCI hotplug for downstream endpoints on arm fails because Linux' PCIe hotplug driver doesn't like the QEMU provided LNKSTA: pcieport 0000:08:01.0: pciehp: Slot(2): Card present pcieport 0000:08:01.0: pciehp: Slot(2): Link Up pcieport 0000:08:01.0: pciehp: Slot(2): Cannot train link: status 0x2000 There's 2 cases where LNKSTA isn't setup properly: * the downstream device has no express capability * max link width of the bridge is 0 Move the sanity checks added via `88c869198a` ("pci: Sanity test minimum downstream LNKSTA") outside of the branch to make sure downstream ports always have a valid LNKSTA. Signed-off-by: Sebastian Ott <sebott@redhat.com> Tested-by: Zhenyu Zhang <zhenyzha@redhat.com> Message-Id: <20241203121928.14861-1-sebott@redhat.com> Reviewed-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit `694632fd44`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Phil Dennis-Jordan	e0c3f8f82f	hw/usb/hcd-xhci-pci: Use modulo to select MSI vector as per spec QEMU would crash with a failed assertion if the XHCI controller attempted to raise the interrupt on an interrupter corresponding to a MSI vector with a higher index than the highest configured for the device by the guest driver. This behaviour is correct on the MSI/PCI side: per PCI 3.0 spec, devices must ensure they do not send MSI notifications for vectors beyond the range of those allocated by the system/driver software. Unlike MSI-X, there is no generic way for handling aliasing in the case of fewer allocated vectors than requested, so the specifics are up to device implementors. (Section 6.8.3.4. "Sending Messages") It turns out the XHCI spec (Implementation Note in section 4.17, "Interrupters") requires that the host controller signal the MSI vector with the number computed by taking the interrupter number modulo the number of enabled MSI vectors. This change introduces that modulo calculation, fixing the failed assertion. This makes the device work correctly in MSI mode with macOS's XHCI driver, which only allocates a single vector. Signed-off-by: Phil Dennis-Jordan <phil@philjordan.eu> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20250112210056.16658-2-phil@philjordan.eu> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit `bb5b7fced6`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Gabriel Barrantes	42422a98b2	backends/cryptodev-vhost-user: Fix local_error leaks Do not propagate error to the upper, directly output the error to avoid leaks. Fixes: `2fda101de0` ("virtio-crypto: Support asynchronous mode") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2714 Signed-off-by: Gabriel Barrantes <gabriel.barrantes.dev@outlook.com> Reviewed-by: zhenwei pi <pizhenwei@bytedance.com> Message-Id: <DM8PR13MB50781054A4FDACE6F4FB6469B30F2@DM8PR13MB5078.namprd13.prod.outlook.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit `78b0c15a56`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Han Han	677b29c943	target/i386/cpu: Fix notes for CPU models Fixes: `644e3c5d81` ("missing vmx features for Skylake-Server and Cascadelake-Server") Signed-off-by: Han Han <hhan@redhat.com> Reviewed-by: Chenyi Qiang <chenyi.qiang@intel.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit `93dcc9390e`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Philippe Mathieu-Daudé	e2c4f6d292	docs: Correct release of TCG trace-events removal TCG trace-events were deprecated before the v6.2 release, and removed for v7.0. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit `b4859e8f33`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
David Hildenbrand	b5d3dedfc3	s390x/s390-virtio-ccw: don't crash on weird RAM sizes KVM is not happy when starting a VM with weird RAM sizes: # qemu-system-s390x --enable-kvm --nographic -m 1234K qemu-system-s390x: kvm_set_user_memory_region: KVM_SET_USER_MEMORY_REGION failed, slot=0, start=0x0, size=0x244000: Invalid argument kvm_set_phys_mem: error registering slot: Invalid argument Aborted (core dumped) Let's handle that in a better way by rejecting such weird RAM sizes right from the start: # qemu-system-s390x --enable-kvm --nographic -m 1234K qemu-system-s390x: ram size must be multiples of 1 MiB Message-ID: <20241219144115.2820241-2-david@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: David Hildenbrand <david@redhat.com> (cherry picked from commit `14e568ab48`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Thomas Huth	9fbebd5ea4	meson.build: Disallow libnfs v6 to fix the broken macOS build The macOS builds in our CI (and possibly other very recent distros) are currently broken since the update to libnfs version 6 there. That version apparently comes with a big API breakage. v5.0.3 was the final release of the old API (see the libnfs commit here: https://github.com/sahlberg/libnfs/commit/4379837 ). Disallow version 6.x for now to get the broken CI job working again. Once somebody had enough time to adapt our code in block/nfs.c, we can revert this change again. Message-ID: <20241218065157.209020-1-thuth@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit `e2d98f2571`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: context fixup)	2 years ago
Peter Maydell	fd48613a0a	hw/intc/arm_gicv3_its: Zero initialize local DTEntry etc structs In the GICv3 ITS model, we have a common coding pattern which has a local C struct like "DTEntry dte", which is a C representation of an in-guest-memory data structure, and we call a function such as get_dte() to read guest memory and fill in the C struct. These functions to read in the struct sometimes have cases where they will leave early and not fill in the whole struct (for instance get_dte() will set "dte->valid = false" and nothing else for the case where it is passed an entry_addr implying that there is no L2 table entry for the DTE). This then causes potential use of uninitialized memory later, for instance when we call a trace event which prints all the fields of the struct. Sufficiently advanced compilers may produce -Wmaybe-uninitialized warnings about this, especially if LTO is enabled. Rather than trying to carefully separate out these trace events into "only the 'valid' field is initialized" and "all fields can be printed", zero-init all the structs when we define them. None of these structs are large (the biggest is 24 bytes) and having consistent behaviour is less likely to be buggy. Cc: qemu-stable@nongnu.org Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2718 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20241213182337.3343068-1-peter.maydell@linaro.org (cherry picked from commit `9678b9c505`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Gerd Hoffmann	708bb73093	x86/loader: only patch linux kernels If the binary loaded via -kernel is not a linux kernel (in which case protocol == 0), do not patch the linux kernel header fields. It's (a) pointless and (b) might break binaries by random patching and (c) changes the binary hash which in turn breaks secure boot verification. Background: OVMF happily loads and runs not only linux kernels but any efi binary via direct kernel boot. Note: Breaking the secure boot verification is a problem for linux kernels too, but fixed that is left for another day ... Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-ID: <20240905141211.1253307-3-kraxel@redhat.com> (cherry picked from commit `57e2cc9abf`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: it is in hw/i386/x86.c not hw/i386/x86-common.c in 7.2.x)	2 years ago
Alexander Bulekov	2831b489f3	fuzz: specify audiodev for usb-audio Fixes test-failure on Fedora 40 CI. Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-ID: <20240527040711.311865-1-alxndr@bu.edu> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit `e7fca81e17`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Roman Artemev	a6e1da0f5b	tcg/riscv: Fix StoreStore barrier generation On RISC-V to StoreStore barrier corresponds `fence w, w` not `fence r, r` Cc: qemu-stable@nongnu.org Fixes: `efbea94c76` ("tcg/riscv: Add slowpath load and store instructions") Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Denis Tomashev <denis.tomashev@syntacore.com> Signed-off-by: Roman Artemev <roman.artemev@syntacore.com> Message-ID: <e2f2131e294a49e79959d4fa9ec02cf4@syntacore.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit `b438362a14`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Ahmad Fatoum	d0da52dbaa	hw/openrisc/openrisc_sim: keep serial@90000000 as default We used to only have a single UART on the platform and it was located at address 0x90000000. When the number of UARTs was increased to 4, the first UART remained at it's location, but instead of being the first one to be registered, it became the last. This caused QEMU to pick 0x90000300 as the default UART, which broke software that hardcoded the address of 0x90000000 and expected it's output to be visible when the user configured only a single console. This caused regressions[1] in the barebox test suite when updating to a newer QEMU. As there seems to be no good reason to register the UARTs in inverse order, let's register them by ascending address, so existing software can remain oblivious to the additional UART ports. Changing the order of uart registration alone breaks Linux which was choosing the UART at 0x90000300 as the default for ttyS0. To fix Linux we fix three things in the device tree: 1. Define stdout-path only one time for the first registered UART instead of incorrectly defining for each UART. 2. Change the UART alias name from 'uart0' to 'serial0' as almost all Linux tty drivers look for an alias starting with "serial". 3. Add the UART nodes so they appear in the final DTB in the order starting with the lowest address and working upwards. In summary these changes mean that the QEMU default UART (serial_hd(0)) is now setup where: * serial_hd(0) is the lowest-address UART * serial_hd(0) is listed first in the DTB * serial_hd(0) is the /chosen/stdout-path one * the /aliases/serial0 alias points at serial_hd(0) [1]: https://lore.barebox.org/barebox/707e7c50-aad1-4459-8796-0cc54bab32e2@pengutronix.de/T/#m5da26e8a799033301489a938b5d5667b81cef6ad Fixes: `777784bda4` ("hw/openrisc: support 4 serial ports in or1ksim") Cc: qemu-stable@nongnu.org Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> [stafford: Change to serial0 alias and update change message, reverse uart registration order] Signed-off-by: Stafford Horne <shorne@gmail.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit `26dcf2be7e`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Nicholas Piggin	752dfc41e0	target/ppc: Fix non-maskable interrupt while halted The ppc (pnv and spapr) NMI injection code does not go through the asynchronous interrupt path and set a bit in env->pending_interrupts and raise an interrupt request that the cpu_exec() loop can see. Instead it injects the exception directly into registers. This can lead to cpu_exec() missing that the thread has work to do, if a NMI is injected while it was idle. Fix this by clearing halted when injecting the interrupt. Probably NMI injection should be reworked to use the interrupt request interface, but this seems to work as a minimal fix. Fixes: `3431648272` ("spapr: Add support for new NMI interface") Reviewed-by: Glenn Miles <milesg@linux.ibm.com> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> (cherry picked from commit `fa416ae615`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Christian Schoenebeck	873d2616c6	tests/9p: also check 'Tgetattr' in 'use-after-unlink' test This verifies expected behaviour of previous bug fix patch. Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org> Message-Id: <7017658155c517b9665b75333a97c79aa2d4f3df.1732465720.git.qemu_oss@crudebyte.com> (cherry picked from commit `eaab44ccc5`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Christian Schoenebeck	509bce38cb	9pfs: fix 'Tgetattr' after unlink With a valid file ID (FID) of an open file, it should be possible to send a 'Tgettattr' 9p request and successfully receive a 'Rgetattr' response, even if the file has been removed in the meantime. Currently this would fail with ENOENT. I.e. this fixes the following misbehaviour with a 9p Linux client: open("/home/tst/filename", O_RDWR\|O_CREAT\|O_EXCL, 0600) = 3 unlink("/home/tst/filename") = 0 fstat(3, 0x23aa1a8) = -1 ENOENT (No such file or directory) Expected results: open("/home/tst/filename", O_RDWR\|O_CREAT\|O_EXCL, 0600) = 3 unlink("/home/tst/filename") = 0 fstat(3, {st_mode=S_IFREG\|0600, st_size=0, ...}) = 0 This is because 9p server is always using a path name based lstat() call which fails as soon as the file got removed. So to fix this, use fstat() whenever we have an open file descriptor already. Fixes: `00ede4c252` ("virtio-9p: getattr server implementation...") Resolves: https://gitlab.com/qemu-project/qemu/-/issues/103 Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org> Message-Id: <4c41ad47f449a5cc8bfa9285743e029080d5f324.1732465720.git.qemu_oss@crudebyte.com> (cherry picked from commit `c81e7219e0`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Christian Schoenebeck	5f79bf8d62	9pfs: remove obsolete comment in v9fs_getattr() The comment claims that we'd only support basic Tgetattr fields. This is no longer true, so remove this comment. Fixes: `e06a765efb` ("hw/9pfs: Add st_gen support in getattr reply") Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org> Message-Id: <fb364d12045217a4c6ccd0dd6368103ddb80698b.1732465720.git.qemu_oss@crudebyte.com> (cherry picked from commit `3bc4db4443`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Christian Schoenebeck	9229de8619	tests/9p: add 'use-after-unlink' test After removing a file from the file system, we should still be able to work with the file if we already had it open before removal. As a first step we verify that it is possible to write to an unlinked file, as this is what already works. This test is extended later on after having fixed other use cases after unlink that are not working yet. Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org> Message-Id: <3d6449d4df25bcdd3e807eff169f46f1385e5257.1732465720.git.qemu_oss@crudebyte.com> (cherry picked from commit `462db8fb1d`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: context fix, pick it to stable so the next patch in this place applies)	3 years ago
Christian Schoenebeck	9e6f0a2334	tests/9p: add missing Rgetattr response name 'Tgetattr' 9p request and its 'Rgetattr' response types are already used by test client, however this response type is yet missing in function rmessage_name(), so add it. Fixes: `a6821b8284` ("tests/9pfs: compare QIDs in fs_walk_none() test") Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org> Message-Id: <e183da80d390cfd7d55bdbce92f0ff6e3e5cdced.1732465720.git.qemu_oss@crudebyte.com> (cherry picked from commit `4ec9849650`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Christian Schoenebeck	039fdd09b4	tests/9p: fix Rreaddir response name All 9p response types are prefixed with an "R", therefore fix "READDIR" -> "RREADDIR" in function rmessage_name(). Fixes: `4829469fd9` ("tests/virtio-9p: added readdir test") Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Greg Kurz <groug@kaod.org> Message-Id: <daad7af58b403aaa2487c566032beca36664b30e.1732465720.git.qemu_oss@crudebyte.com> (cherry picked from commit `abf0f092c1`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Guenter Roeck	ef780ee765	scsi: megasas: Internal cdbs have 16-byte length Host drivers do not necessarily set cdb_len in megasas io commands. With commits `6d1511cea0` ("scsi: Reject commands if the CDB length exceeds buf_len") and `fe9d8927e2` ("scsi: Add buf_len parameter to scsi_req_new()"), this results in failures to boot Linux from affected SCSI drives because cdb_len is set to 0 by the host driver. Set the cdb length to its actual size to solve the problem. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Fabiano Rosas <farosas@suse.de> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Tested-by: Fiona Ebner <f.ebner@proxmox.com> Link: https://lore.kernel.org/r/20230228171129.4094709-1-linux@roeck-us.net Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit `3abb67323a`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	4 years ago
Jakub Jelen	686ece6ad4	ssh: Do not switch session to non-blocking mode The libssh does not handle non-blocking mode in SFTP correctly. The driver code already changes the mode to blocking for the SFTP initialization, but for some reason changes to non-blocking mode. This used to work accidentally until libssh in 0.11 branch merged the patch to avoid infinite looping in case of network errors: https://gitlab.com/libssh/libssh-mirror/-/merge_requests/498 Since then, the ssh driver in qemu fails to read files over SFTP as the first SFTP messages exchanged after switching the session to non-blocking mode return SSH_AGAIN, but that message is lost int the SFTP internals and interpretted as SSH_ERROR, which is returned to the caller: https://gitlab.com/libssh/libssh-mirror/-/issues/280 This is indeed an issue in libssh that we should address in the long term, but it will require more work on the internals. For now, the SFTP is not supported in non-blocking mode. Fixes: https://gitlab.com/libssh/libssh-mirror/-/issues/280 Signed-off-by: Jakub Jelen <jjelen@redhat.com> Signed-off-by: Richard W.M. Jones <rjones@redhat.com> Message-ID: <20241113125526.2495731-1-rjones@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit `fbdea3d6c1`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Kevin Wolf	ea1f958b4e	qdev: Fix set_pci_devfn() to visit option only once pci_devfn properties accept either a string or an integer as input. To implement this, set_pci_devfn() first tries to visit the option as a string, and if that fails, it visits it as an integer instead. While the QemuOpts visitor happens to accept this, it is invalid according to the visitor interface. QObject input visitors run into an assertion failure when this is done. QObject input visitors are used with the JSON syntax version of -device on the command line: $ ./qemu-system-x86_64 -enable-kvm -M q35 -device pcie-pci-bridge,id=pci.1,bus=pcie.0 -blockdev null-co,node-name=disk -device '{ "driver": "virtio-blk-pci", "drive": "disk", "id": "virtio-disk0", "bus": "pci.1", "addr": 1 }' qemu-system-x86_64: ../qapi/qobject-input-visitor.c:143: QObject qobject_input_try_get_object(QObjectInputVisitor , const char *, _Bool): Assertion `removed' failed. The proper way to accept both strings and integers is using the alternate mechanism, which tells us the type of the input before it's visited. With this information, we can directly visit it as the right type. This fixes set_pci_devfn() by using the alternate mechanism. Cc: qemu-stable@nongnu.org Reported-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <20241119120353.57812-1-kwolf@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit `5102f9df4a`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Akihiko Odaki	acb39d8e6e	virtio-net: Fix size check in dhclient workaround work_around_broken_dhclient() accesses IP and UDP headers to detect relevant packets and to calculate checksums, but it didn't check if the packet has size sufficient to accommodate them, causing out-of-bound access hazards. Fix this by correcting the size requirement. Fixes: `1d41b0c1ec` ("Work around dhclient brokenness") Cc: qemu-stable@nongnu.org Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Signed-off-by: Jason Wang <jasowang@redhat.com> (cherry picked from commit `a8575f7fb2`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Philippe Mathieu-Daudé	f33f326fbd	cirrus-ci: Remove MSYS2 jobs duplicated with gitlab-ci - Various developers are reluctant to git Cirrus-CI the permissions requested to access their GitHub account. - When we use the cirrus-run script to trigger Cirrus-CI job from GitLab-CI, the GitLab-CI job is restricted to a 1h timeout (often not enough). - Although Cirrus-CI VMs are more powerful than GitLab-CI ones, its free plan is limited in 2 concurrent jobs. - The GitLab-CI MSYS2 jobs are a 1:1 mapping with the Cirrus-CI ones (modulo the environment caching). Reduce the maintenance burden by removing the Cirrus-CI config file, keeping the GitLab-CI jobs. Update Yonggang Luo's maintenance file list to the new file, which use the same environment shell. Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20230322135721.61138-3-philmd@linaro.org> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit `da80f11efe`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: ignore previous changes in .cirrus.yml since it is being removed anyway)	3 years ago
Peter Maydell	02774b5861	hw/intc/loongarch_extioi: Use set_bit32() and clear_bit32() for s->isr In extioi_setirq() we try to operate on a bit array stored as an array of uint32_t using the set_bit() and clear_bit() functions by casting the pointer to 'unsigned long '. This has two problems: the alignment of 'uint32_t' is less than that of 'unsigned long' so we pass an insufficiently aligned pointer, which is undefined behaviour * on big-endian hosts the 64-bit 'unsigned long' will have its two halves the wrong way around, and we will produce incorrect results The undefined behaviour is shown by the clang undefined-behaviour sanitizer when running the loongarch64-virt functional test: /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/include/qemu/bitops.h:41:5: runtime error: store to misaligned address 0x555559745d9c for type 'unsigned long', which requires 8 byte alignment 0x555559745d9c: note: pointer points here ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ #0 0x555556fb81c4 in set_bit /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/include/qemu/bitops.h:41:9 #1 0x555556fb81c4 in extioi_setirq /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/clang/../../hw/intc/loongarch_extioi.c:65:9 #2 0x555556fb6e90 in pch_pic_irq_handler /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/clang/../../hw/intc/loongarch_pch_pic.c:75:5 #3 0x555556710265 in serial_ioport_write /mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/clang/../../hw/char/serial.c Fix these problems by using set_bit32() and clear_bit32(), which work with bit arrays stored as an array of uint32_t. Cc: qemu-stable@nongnu.org Fixes: `cbff2db1e9` ("hw/intc: Add LoongArch extioi interrupt controller(EIOINTC)") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Bibo Mao <maobibo@loongson.cn> Message-id: 20241108135514.4006953-4-peter.maydell@linaro.org (cherry picked from commit `335be5bc44`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: drop hunk in hw/intc/loongarch_extioi.c:extioi_update_sw_coremap() due to missing v8.2.0-548-g428a6ef4396a "hw/intc/loongarch_extioi: Add vmstate post_load support")	2 years ago
Peter Maydell	4de86d2b30	bitops.h: Define bit operations on 'uint32_t' arrays Currently bitops.h defines a set of operations that work on arbitrary-length bit arrays. However (largely because they originally came from the Linux kernel) the bit array storage is an array of 'unsigned long'. This is OK for the kernel and even for parts of QEMU where we don't really care about the underlying storage format, but it is not good for devices, where we often want to expose the storage to the guest and so need a type that is not variably-sized between host OSes. We already have a workaround for this in the GICv3 model: arm_gicv3_common.h defines equivalents of the bit operations that work on uint32_t. It turns out that we should also be using something similar in hw/intc/loongarch_extioi.c, which currently casts a pointer to a uint32_t array to 'unsigned long *' in extio_setirq(), which is both undefined behaviour and not correct on a big-endian host. Define equivalents of the set_bit() function family which work with a uint32_t array. (Cc stable because we're about to provide a bugfix to loongarch_extioi which will depend on this commit.) Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-id: 20241108135514.4006953-2-peter.maydell@linaro.org (cherry picked from commit `3d7680fb18`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Peter Maydell	fc4ca539d0	hw/intc/openpic: Avoid taking address of out-of-bounds array index The clang sanitizer complains about the code in the EOI handling of openpic_cpu_write_internal(): UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1 ./build/clang/qemu-system-ppc -M mac99,graphics=off -display none -kernel day15/invaders.elf ../../hw/intc/openpic.c:1034:16: runtime error: index -1 out of bounds for type 'IRQSource[264]' (aka 'struct IRQSource[264]') SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../../hw/intc/openpic.c:1034:16 in This is because we do src = &opp->src[n_IRQ]; when n_IRQ may be -1. This is in practice harmless because if n_IRQ is -1 then we don't do anything with the src pointer, but it is undefined behaviour. (This has been present since this device was first added to QEMU.) Rearrange the code so we only do the array index when n_IRQ is not -1. Cc: qemu-stable@nongnu.org Fixes: `e9df014c0b` ("Implement embedded IRQ controller for PowerPC 6xx/740 & 75") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-id: 20241105180205.3074071-1-peter.maydell@linaro.org (cherry picked from commit `3bf7dcd47a`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Michael Tokarev	8ac75726fc	Update version for 7.2.15 release Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Guenter Roeck	7ffc37b541	usb-hub: Fix handling port power control messages The ClearPortFeature control message fails for PORT_POWER because there is no break; at the end of the case statement, causing it to fall through to the failure handler. Add the missing break; to solve the problem. Fixes: `1cc403eb21` ("usb-hub: emulate per port power switching") Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20241112170152.217664-11-linux@roeck-us.net> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit `b2cc699979`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago
Paolo Bonzini	e0af40f140	hw/audio/hda: fix memory leak on audio setup When SET_STREAM_FORMAT is called, the st->buft timer is overwritten, thus causing a memory leak. This was originally fixed in commit 816139ae6a5 ("hw/audio/hda: fix memory leak on audio setup", 2024-11-14) but that caused the audio to break in SPICE. Fortunately, a simpler fix is possible. The timer only needs to be reset, because the callback is always the same (st->output is set at realize time in hda_audio_init); call to timer_new_ns overkill. Replace it with timer_del and only initialize the timer once; for simplicity, do it even if use_timer is false. An even simpler fix would be to free the old time in hda_audio_setup(). However, it seems better to place the initialization of the timer close to that of st->ouput. Cc: qemu-stable@nongnu.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Message-ID: <20241114125318.1707590-3-pbonzini@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> (cherry picked from commit `626b39006d`) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>	2 years ago

1 2 3 4 5 ...

100482 Commits (3e59a2255d10d21e1900c6e2c10fbb2f99df96f6) All Branches Search

100482 Commits (3e59a2255d10d21e1900c6e2c10fbb2f99df96f6)

All Branches