aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-10-21migration: Fix analyze-migration read operation signednessFabiano Rosas
The migration code uses unsigned values for 16, 32 and 64-bit operations. Fix the script to do the same. This was causing an issue when parsing the migration stream generated on the ppc64 target because one of instance_ids was larger than the 32bit signed maximum: Traceback (most recent call last): File "/home/fabiano/kvm/qemu/build/scripts/analyze-migration.py", line 658, in <module> dump.read(dump_memory = args.memory) File "/home/fabiano/kvm/qemu/build/scripts/analyze-migration.py", line 592, in read classdesc = self.section_classes[section_key] KeyError: ('spapr_iommu', -2147483648) Signed-off-by: Fabiano Rosas <farosas@suse.de> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <20231009184326.15777-6-farosas@suse.de> (cherry picked from commit caea03279e11dfcb0e5a567b81fe7f02ee80af02) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-10-21hw/pvrdma: Protect against buggy or malicious guest driverYuval Shaia
Guest driver allocates and initialize page tables to be used as a ring of descriptors for CQ and async events. The page table that represents the ring, along with the number of pages in the page table is passed to the device. Currently our device supports only one page table for a ring. Let's make sure that the number of page table entries the driver reports, do not exceeds the one page table size. Reported-by: Soul Chen <soulchen8650@gmail.com> Signed-off-by: Yuval Shaia <yuval.shaia.ml@gmail.com> Fixes: CVE-2023-1544 Message-ID: <20230301142926.18686-1-yuval.shaia.ml@gmail.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 85fc35afa93c7320d1641d344d0c5dfbe341d087) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-10-21disas/riscv: Fix the typo of inverted order of pmpaddr13 and pmpaddr14Alvin Chang
Fix the inverted order of pmpaddr13 and pmpaddr14 in csr_name(). Signed-off-by: Alvin Chang <alvinga@andestech.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230907084500.328-1-alvinga@andestech.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit cffa9954908830276c93b430681f66cc0e599aef) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-10-21hw/audio/es1370: reset current sample counterVolker Rümelin
Reset the current sample counter when writing the Channel Sample Count Register. The Linux ens1370 driver and the AROS sb128 driver expect the current sample counter counts down from sample count to 0 after a write to the Channel Sample Count Register. Currently the current sample counter starts from 0 after a reset or the last count when the counter was stopped. The current sample counter is used to raise an interrupt whenever a complete buffer was transferred. When the counter starts with a value lower than the reload value, the interrupt triggeres before the buffer was completly transferred. This may lead to corrupted audio streams. Tested-by: Rene Engel <ReneEngel80@emailn.de> Signed-off-by: Volker Rümelin <vr_qemu@t-online.de> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Tested-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <20230917065813.6692-1-vr_qemu@t-online.de> (cherry picked from commit 00e3b29d065f3b88bb3726afbd5c73f8b2bff1b4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-10-21migration/qmp: Fix crash on setting tls-authz with nullPeter Xu
QEMU will crash if anyone tries to set tls-authz (which is a type StrOrNull) with 'null' value. Fix it in the easy way by converting it to qstring just like the other two tls parameters. Cc: qemu-stable@nongnu.org # v4.0+ Fixes: d2f1d29b95 ("migration: add support for a "tls-authz" migration parameter") Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Fabiano Rosas <farosas@suse.de> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Message-ID: <20230905162335.235619-2-peterx@redhat.com> (cherry picked from commit 86dec715a7339fc61c3bdb9715993b277b2089db) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: the function is in m/migration.c, not m/option.c; minor context tweak)
2023-10-21amd_iommu: Fix APIC address checkAkihiko Odaki
An MSI from I/O APIC may not exactly equal to APIC_DEFAULT_ADDRESS. In fact, Windows 17763.3650 configures I/O APIC to set the dest_mode bit. Cover the range assigned to APIC. Fixes: 577c470f43 ("x86_iommu/amd: Prepare for interrupt remap support") Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com> Message-Id: <20230921114612.40671-1-akihiko.odaki@daynix.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> (cherry picked from commit 0114c4513095598cdf1cd8d7dacdfff757628121) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-10-21linux-user/hppa: Fix struct target_sigcontext layoutRichard Henderson
Use abi_ullong not uint64_t so that the alignment of the field and therefore the layout of the struct is correct. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 33bc4fa78b06fc4e5fe22e5576811a97707e0cc6) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-10-21chardev/char-pty: Avoid losing bytes when the other side just (re-)connectedThomas Huth
When starting a guest via libvirt with "virsh start --console ...", the first second of the console output is missing. This is especially annoying on s390x that only has a text console by default and no graphical output - if the bios fails to boot here, the information about what went wrong is completely lost. One part of the problem (there is also some things to be done on the libvirt side) is that QEMU only checks with a 1 second timer whether the other side of the pty is already connected, so the first second of the console output is always lost. This likely used to work better in the past, since the code once checked for a re-connection during write, but this has been removed in commit f8278c7d74 ("char-pty: remove the check for connection on write") to avoid some locking. To ease the situation here at least a little bit, let's check with g_poll() whether we could send out the data anyway, even if the connection has not been marked as "connected" yet. The file descriptor is marked as non-blocking anyway since commit fac6688a18 ("Do not hang on full PTY"), so this should not cause any trouble if the other side is not ready for receiving yet. With this patch applied, I can now successfully see the bios output of a s390x guest when running it with "virsh start --console" (with a patched version of virsh that fixes the remaining issues there, too). Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20230816210743.1319018-1-thuth@redhat.com> (cherry picked from commit 4f7689f0817a717d18cc8aca298990760f27a89b) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: use TFR() instead of RETRY_ON_EINTR() before v7.2.0-538-g8b6aa69365)
2023-10-05hw/display/ramfb: plug slight guest-triggerable leak on mode settingLaszlo Ersek
The fw_cfg DMA write callback in ramfb prepares a new display surface in QEMU; this new surface is put to use ("swapped in") upon the next display update. At that time, the old surface (if any) is released. If the guest triggers the fw_cfg DMA write callback at least twice between two adjacent display updates, then the second callback (and further such callbacks) will leak the previously prepared (but not yet swapped in) display surface. The issue can be shown by: (1) starting QEMU with "-trace displaysurface_free", and (2) running the following program in the guest UEFI shell: > #include <Library/ShellCEntryLib.h> // ShellAppMain() > #include <Library/UefiBootServicesTableLib.h> // gBS > #include <Protocol/GraphicsOutput.h> // EFI_GRAPHICS_OUTPUT_PROTOCOL > > INTN > EFIAPI > ShellAppMain ( > IN UINTN Argc, > IN CHAR16 **Argv > ) > { > EFI_STATUS Status; > VOID *Interface; > EFI_GRAPHICS_OUTPUT_PROTOCOL *Gop; > UINT32 Mode; > > Status = gBS->LocateProtocol ( > &gEfiGraphicsOutputProtocolGuid, > NULL, > &Interface > ); > if (EFI_ERROR (Status)) { > return 1; > } > > Gop = Interface; > > Mode = 1; > for ( ; ;) { > Status = Gop->SetMode (Gop, Mode); > if (EFI_ERROR (Status)) { > break; > } > > Mode = 1 - Mode; > } > > return 1; > } The symptom is then that: - only one trace message appears periodically, - the time between adjacent messages keeps increasing -- implying that some list structure (containing the leaked resources) keeps growing, - the "surface" pointer is ever different. > 18566@1695127471.449586:displaysurface_free surface=0x7f2fcc09a7c0 > 18566@1695127471.529559:displaysurface_free surface=0x7f2fcc9dac10 > 18566@1695127471.659812:displaysurface_free surface=0x7f2fcc441dd0 > 18566@1695127471.839669:displaysurface_free surface=0x7f2fcc0363d0 > 18566@1695127472.069674:displaysurface_free surface=0x7f2fcc413a80 > 18566@1695127472.349580:displaysurface_free surface=0x7f2fcc09cd00 > 18566@1695127472.679783:displaysurface_free surface=0x7f2fcc1395f0 > 18566@1695127473.059848:displaysurface_free surface=0x7f2fcc1cae50 > 18566@1695127473.489724:displaysurface_free surface=0x7f2fcc42fc50 > 18566@1695127473.969791:displaysurface_free surface=0x7f2fcc45dcc0 > 18566@1695127474.499708:displaysurface_free surface=0x7f2fcc70b9d0 > 18566@1695127475.079769:displaysurface_free surface=0x7f2fcc82acc0 > 18566@1695127475.709941:displaysurface_free surface=0x7f2fcc369c00 > 18566@1695127476.389619:displaysurface_free surface=0x7f2fcc32b910 > 18566@1695127477.119772:displaysurface_free surface=0x7f2fcc0d5a20 > 18566@1695127477.899517:displaysurface_free surface=0x7f2fcc086c40 > 18566@1695127478.729962:displaysurface_free surface=0x7f2fccc72020 > 18566@1695127479.609839:displaysurface_free surface=0x7f2fcc185160 > 18566@1695127480.539688:displaysurface_free surface=0x7f2fcc23a7e0 > 18566@1695127481.519759:displaysurface_free surface=0x7f2fcc3ec870 > 18566@1695127482.549930:displaysurface_free surface=0x7f2fcc634960 > 18566@1695127483.629661:displaysurface_free surface=0x7f2fcc26b140 > 18566@1695127484.759987:displaysurface_free surface=0x7f2fcc321700 > 18566@1695127485.940289:displaysurface_free surface=0x7f2fccaad100 We figured this wasn't a CVE-worthy problem, as only small amounts of memory were leaked (the framebuffer itself is mapped from guest RAM, QEMU only allocates administrative structures), plus libvirt restricts QEMU memory footprint anyway, thus the guest can only DoS itself. Plug the leak, by releasing the last prepared (not yet swapped in) display surface, if any, in the fw_cfg DMA write callback. Regarding the "reproducer", with the fix in place, the log is flooded with trace messages (one per fw_cfg write), *and* the trace message alternates between just two "surface" pointer values (i.e., nothing is leaked, the allocator flip-flops between two objects in effect). This issue appears to date back to the introducion of ramfb (995b30179bdc, "hw/display: add ramfb, a simple boot framebuffer living in guest ram", 2018-06-18). Cc: Gerd Hoffmann <kraxel@redhat.com> (maintainer:ramfb) Cc: qemu-stable@nongnu.org Fixes: 995b30179bdc Signed-off-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-ID: <20230919131955.27223-1-lersek@redhat.com> (cherry picked from commit e0288a778473ebd35eac6cc1924faca7d477d241) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-10-04target/i386: fix memory operand size for CVTPS2PDPaolo Bonzini
CVTPS2PD only loads a half-register for memory, unlike the other operations under 0x0F 0x5A. "Unpack" the group into separate emission functions instead of using gen_unary_fp_sse. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit abd41884c530aa025ada253bf1a5bd0c2b808219) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-10-04target/i386: generalize operand size "ph" for use in CVTPS2PDPaolo Bonzini
CVTPS2PD only loads a half-register for memory, like CVTPH2PS. It can reuse the "ph" packed half-precision size to load a half-register, but rename it to "xh" because it is now a variation of "x" (it is not used only for half-precision values). Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit a48b26978a090fe1f3f3e54319902d4ab56a6b3a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-10-04target/i386: Fix exception classes for MOVNTPS/MOVNTPD.Ricky Zhou
Before this change, MOVNTPS and MOVNTPD were labeled as Exception Class 4 (only requiring alignment for legacy SSE instructions). This changes them to Exception Class 1 (always requiring memory alignment), as documented in the Intel manual. Message-Id: <20230501111428.95998-3-ricky@rzhou.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 8bf171c2d126aea6b60b818f1cee7e0e9eef0390) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-10-04target/i386: Fix exception classes for SSE/AVX instructions.Ricky Zhou
Fix the exception classes for some SSE/AVX instructions to match what is documented in the Intel manual. These changes are expected to have no functional effect on the behavior that qemu implements (primarily >= 16-byte memory alignment checks). For instance, since qemu does not implement the AC flag, there is no difference in behavior between Exception Classes 4 and 5 for instructions where the SSE version only takes <16 byte memory operands. Message-Id: <20230501111428.95998-2-ricky@rzhou.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit cab529b0dc15746b270e87d77e1dd12c6216807c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-10-04target/i386: Fix and add some comments next to SSE/AVX instructions.Ricky Zhou
Adds some comments describing what instructions correspond to decoding table entries and fixes some existing comments which named the wrong instruction. Message-Id: <20230501111428.95998-1-ricky@rzhou.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit afa94dabc52b17e340975e158d5a816ec2b2de23) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-10-04tests/tcg/i386: correct mask for VPERM2F128/VPERM2I128Paolo Bonzini
The instructions also use bits 3 and 7 of their 8-byte immediate. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 9e65829699f901c62a612316a2897f4ad8a27049) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-10-04target/i386: fix operand size of unary SSE operationsPaolo Bonzini
VRCPSS, VRSQRTSS and VCVTSx2Sx have a 32-bit or 64-bit memory operand, which is represented in the decoding tables by X86_VEX_REPScalar. Add it to the tables, and make validate_vex() handle the case of an instruction that is in exception type 4 without the REP prefix and exception type 5 with it; this is the cas of VRCP and VRSQRT. Reported-by: yongwoo <https://gitlab.com/yongwoo36> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1377 Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 3d304620ec6c95f31db17acc132f42f243369299) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-10-03scsi-disk: ensure that FORMAT UNIT commands are terminatedMark Cave-Ayland
Otherwise when a FORMAT UNIT command is issued, the SCSI layer can become confused because it can find itself in the situation where it thinks there is still data to be transferred which can cause the next emulated SCSI command to fail. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Fixes: 6ab71761 ("scsi-disk: add FORMAT UNIT command") Tested-by: Thomas Huth <thuth@redhat.com> Message-ID: <20230913204410.65650-4-mark.cave-ayland@ilande.co.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit be2b619a17345d007bcf9987a3e4afd1edea3e4f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-10-03esp: restrict non-DMA transfer length to that of available dataMark Cave-Ayland
In the case where a SCSI layer transfer is incorrectly terminated, it is possible for a TI command to cause a SCSI buffer overflow due to the expected transfer data length being less than the available data in the FIFO. When this occurs the unsigned async_len variable underflows and becomes a large offset which writes past the end of the allocated SCSI buffer. Restrict the non-DMA transfer length to be the smallest of the expected transfer length and the available FIFO data to ensure that it is no longer possible for the SCSI buffer overflow to occur. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1810 Reviewed-by: Thomas Huth <thuth@redhat.com> Message-ID: <20230913204410.65650-3-mark.cave-ayland@ilande.co.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 77668e4b9bca03a856c27ba899a2513ddf52bb52) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-10-03esp: use correct type for esp_dma_enable() in sysbus_esp_gpio_demux()Mark Cave-Ayland
The call to esp_dma_enable() was being made with the SYSBUS_ESP type instead of the ESP type. This meant that when GPIO 1 was being used to trigger a DMA request from an external DMA controller, the setting of ESPState's dma_enabled field would clobber unknown memory whilst the dma_cb callback pointer would typically return NULL so the DMA request would never start. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-ID: <20230913204410.65650-2-mark.cave-ayland@ilande.co.uk> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit b86dc5cb0b4105fa8ad29e822ab5d21c589c5ec5) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-10-03optionrom: Remove build-id sectionFabiano Rosas
Our linker script for optionroms specifies only the placement of the .text section, leaving the linker free to place the remaining sections at arbitrary places in the file. Since at least binutils 2.39, the .note.gnu.build-id section is now being placed at the start of the file, which causes label addresses to be shifted. For linuxboot_dma.bin that means that the PnP header (among others) will not be found when determining the type of ROM at optionrom_setup(): (0x1c is the label _pnph, where the magic "PnP" is) $ xxd /usr/share/qemu/linuxboot_dma.bin | grep "PnP" 00000010: 0000 0000 0000 0000 0000 1c00 2450 6e50 ............$PnP $ xxd pc-bios/optionrom/linuxboot_dma.bin | grep "PnP" 00000010: 0000 0000 0000 0000 0000 4c00 2450 6e50 ............$PnP ^bad Using a freshly built linuxboot_dma.bin ROM results in a broken boot: SeaBIOS (version rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org) Booting from Hard Disk... Boot failed: could not read the boot disk Booting from Floppy... Boot failed: could not read the boot disk No bootable device. We're not using the build-id section, so pass the --build-id=none option to the linker to remove it entirely. Note: In theory, this same issue could happen with any other section. The ideal solution would be to have all unused sections discarded in the linker script. However that would be a larger change, specially for the pvh rom which uses the .bss and COMMON sections so I'm addressing only the immediate issue here. Reported-by: Vasiliy Ulyanov <vulyanov@suse.de> Signed-off-by: Fabiano Rosas <farosas@suse.de> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-ID: <20230926192502.15986-1-farosas@suse.de> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 35ed01ba5448208695ada5fa20a13c0a4689a1c1) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (mjt: remove unrelated stable@vger)
2023-09-28ui/vnc: fix handling of VNC_FEATURE_XVPPaolo Bonzini
VNC_FEATURE_XVP was not shifted left before adding it to vs->features, so it was never enabled; but it was also checked the wrong way with a logical AND instead of vnc_has_feature. Fix both places. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 477b301000d665313217f65e3a368d2cb7769c42) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-28ui/vnc: fix debug output for invalid audio messagePaolo Bonzini
The debug message was cut and pasted from the invalid audio format case, but the audio message is at bytes 2-3. Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 0cb9c5880e6b8dedc4e20026ce859dd1ea9aac84) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-28hw/scsi/scsi-disk: Disallow block sizes smaller than 512 [CVE-2023-42467]Thomas Huth
We are doing things like nb_sectors /= (s->qdev.blocksize / BDRV_SECTOR_SIZE); in the code here (e.g. in scsi_disk_emulate_mode_sense()), so if the blocksize is smaller than BDRV_SECTOR_SIZE (=512), this crashes with a division by 0 exception. Thus disallow block sizes of 256 bytes to avoid this situation. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1813 CVE: 2023-42467 Signed-off-by: Thomas Huth <thuth@redhat.com> Message-ID: <20230925091854.49198-1-thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 7cfcc79b0ab800959716738aff9419f53fc68c9c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-27accel/tcg: mttcg remove false-negative halted assertionNicholas Piggin
mttcg asserts that an execution ending with EXCP_HALTED must have cpu->halted. However between the event or instruction that sets cpu->halted and requests exit and the assertion here, an asynchronous event could clear cpu->halted. This leads to crashes running AIX on ppc/pseries because it uses H_CEDE/H_PROD hcalls, where H_CEDE sets self->halted = 1 and H_PROD sets other cpu->halted = 0 and kicks it. H_PROD could be turned into an interrupt to wake, but several other places in ppc, sparc, and semihosting follow what looks like a similar pattern setting halted = 0 directly. So remove this assertion. Reported-by: Ivan Warren <ivan@vmfacility.fr> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20230829010658.8252-1-npiggin@gmail.com> [rth: Keep the case label and adjust the comment.] Signed-off-by: Richard Henderson <richard.henderson@linaro.org> (cherry picked from commit 0e5903436de712844b0e6cdd862b499c767e09e9) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-25target/arm: Don't skip MTE checks for LDRT/STRT at EL0Peter Maydell
The LDRT/STRT "unprivileged load/store" instructions behave like normal ones if executed at EL0. We handle this correctly for the load/store semantics, but get the MTE checking wrong. We always look at s->mte_active[is_unpriv] to see whether we should be doing MTE checks, but in hflags.c when we set the TB flags that will be used to fill the mte_active[] array we only set the MTE0_ACTIVE bit if UNPRIV is true (i.e. we are not at EL0). This means that a LDRT at EL0 will see s->mte_active[1] as 0, and will not do MTE checks even when MTE is enabled. To avoid the translate-time code having to do an explicit check on s->unpriv to see if it is OK to index into the mte_active[] array, duplicate MTE_ACTIVE into MTE0_ACTIVE when UNPRIV is false. (This isn't a very serious bug because generally nobody executes LDRT/STRT at EL0, because they have no use there.) Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20230912140434.1333369-2-peter.maydell@linaro.org (cherry picked from commit 903dbefc2b6918c10d12d9aafa0168cee8d287c7) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: before v7.2.0-1636-g671efad16a this code was in target/arm/helper.c)
2023-09-25hw/cxl: Fix CFMW config memory leakLi Zhijian
Allocate targets and targets[n] resources when all sanity checks are passed to avoid memory leaks. Cc: qemu-stable@nongnu.org Suggested-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by: Fan Ni <fan.ni@samsung.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit 7b165fa164022b756c2b001d0a1525f98199d3ac) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-25linux-user/hppa: lock both words of function descriptorMikulas Patocka
The code in setup_rt_frame reads two words at haddr, but locks only one. This patch fixes it to lock both. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Acked-by: Helge Deller <deller@gmx.de> Cc: qemu-stable@nongnu.org Signed-off-by: Helge Deller <deller@gmx.de> (cherry picked from commit 5b1270ef1477bb7f240c3bfe2cd8b0fe4721fd51) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-25linux-user/hppa: clear the PSW 'N' bit when delivering signalsMikulas Patocka
qemu-hppa may crash when delivering a signal. It can be demonstrated with this program. Compile the program with "hppa-linux-gnu-gcc -O2 signal.c" and run it with "qemu-hppa -one-insn-per-tb a.out". It reports that the address of the flag is 0xb4 and it crashes when attempting to touch it. #include <stdio.h> #include <stdlib.h> #include <sys/time.h> #include <signal.h> sig_atomic_t flag; void sig(int n) { printf("&flag: %p\n", &flag); flag = 1; } int main(void) { struct sigaction sa; struct itimerval it; sa.sa_handler = sig; sigemptyset(&sa.sa_mask); sa.sa_flags = SA_RESTART; if (sigaction(SIGALRM, &sa, NULL)) perror("sigaction"), exit(1); it.it_interval.tv_sec = 0; it.it_interval.tv_usec = 100; it.it_value.tv_sec = it.it_interval.tv_sec; it.it_value.tv_usec = it.it_interval.tv_usec; if (setitimer(ITIMER_REAL, &it, NULL)) perror("setitimer"), exit(1); while (1) { } } The reason for the crash is that the signal handling routine doesn't clear the 'N' flag in the PSW. If the signal interrupts a thread when the 'N' flag is set, the flag remains set at the beginning of the signal handler and the first instruction of the signal handler is skipped. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Acked-by: Helge Deller <deller@gmx.de> Cc: qemu-stable@nongnu.org Signed-off-by: Helge Deller <deller@gmx.de> (cherry picked from commit 2529497cb6b298e732e8dbe5212da7925240b4f4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-25hw/ppc: Always store the decrementer valueNicholas Piggin
When writing a value to the decrementer that raises an exception, the irq is raised, but the value is not stored so the store doesn't appear to have changed the register when it is read again. Always store the write value to the register. Fixes: e81a982aa53 ("PPC: Clean up DECR implementation") Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> (cherry picked from commit febb71d543a8f747b2f8aaf0182d0a385c6a02c3) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-25target/ppc: Decrementer fix BookE semanticsNicholas Piggin
The decrementer store function has logic that short-cuts the timer if a very small value is stored (0, 1, or 2) and raises an interrupt directly. There are two problem with this on BookE. First is that BookE says a decrementer interrupt should not be raised on a store of 0, only of a decrement from 1. Second is that raising the irq directly will bypass the auto-reload logic in the booke decr timer function, breaking autoreload when 1 or 2 is stored. Fix this by removing that small-value special case. It makes this tricky logic even more difficult to reason about, and it hardly matters for performance. Cc: sdicaro@DDCI.com Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Message-Id: <20230530131214.373524-2-npiggin@gmail.com> Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com> (cherry picked from commit 17dd1354c1d1aba9caf4af01e11aa7dbe128474f) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-25target/ppc: Sign-extend large decrementer to 64-bitsNicholas Piggin
When storing a large decrementer value with the most significant implemented bit set, it is to be treated as a negative and sign extended. This isn't hit for book3s DEC because of another bug, fixing it in the next patch exposes this one and can cause additional problems, so fix this first. It can be hit with HDECR and other edge triggered types. Fixes: a8dafa52518 ("target/ppc: Implement large decrementer support for TCG") Signed-off-by: Nicholas Piggin <npiggin@gmail.com> [ clg: removed extra cpu and pcc variables shadowing local variables ] Signed-off-by: Cédric Le Goater <clg@kaod.org> (cherry picked from commit c8fbc6b9f2f3c732ee3307093c1c5c367eaa64ae) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-25hw/ppc: Avoid decrementer rounding errorsNicholas Piggin
The decrementer register contains a relative time in timebase units. When writing to DECR this is converted and stored as an absolute value in nanosecond units, reading DECR converts back to relative timebase. The tb<->ns conversion of the relative part can cause rounding such that a value writen to the decrementer can read back a different, with time held constant. This is a particular problem for a deterministic icount and record-replay trace. Fix this by storing the absolute value in timebase units rather than nanoseconds. The math before: store: decr_next = now_ns + decr * ns_per_sec / tb_per_sec load: decr = (decr_next - now_ns) * tb_per_sec / ns_per_sec load(store): decr = decr * ns_per_sec / tb_per_sec * tb_per_sec / ns_per_sec After: store: decr_next = now_ns * tb_per_sec / ns_per_sec + decr load: decr = decr_next - now_ns * tb_per_sec / ns_per_sec load(store): decr = decr Fixes: 9fddaa0c0cab ("PowerPC merge: real time TB and decrementer - faster and simpler exception handling (Jocelyn Mayer)") Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> (cherry picked from commit 8e0a5ac87800ccc6dd5013f89f27652f4480ab33) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-25hw/ppc: Round up the decrementer interval when converting to nsNicholas Piggin
The rule of timers is typically that they should never expire before the timeout, but some time afterward. Rounding timer intervals up when doing conversion is the right thing to do. Under most circumstances it is impossible observe the decrementer interrupt before the dec register has triggered. However with icount timing, problems can arise. For example setting DEC to 0 can schedule the timer for now, causing it to fire before any more instructions have been executed and DEC is still 0. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> (cherry picked from commit eab0888418ab44344864965193cf6cd194ab6858) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-25host-utils: Add muldiv64_round_upNicholas Piggin
This will be used for converting time intervals in different base units to host units, for the purpose of scheduling timers to emulate target timers. Timers typically must not fire before their requested expiry time but may fire some time afterward, so rounding up is the right way to implement these. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> [ clg: renamed __muldiv64() to muldiv64_rounding() ] Signed-off-by: Cédric Le Goater <clg@kaod.org> (cherry picked from commit 47de6c4c287079744ceb96f606b3c0457addf380) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-25hw/ppc: Introduce functions for conversion between timebase and nanosecondsNicholas Piggin
These calculations are repeated several times, and they will become a little more complicated with subsequent changes. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> (cherry picked from commit 7798f5c576d898e7e10c4a2518f3f16411dedeb9) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-21Update version for 7.2.6 releasev7.2.6Michael Tokarev
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-13tpm: fix crash when FD >= 1024 and unnecessary errors due to EINTRMarc-André Lureau
Replace select() with poll() to fix a crash when QEMU has a large number of FDs. Also use RETRY_ON_EINTR to avoid unnecessary errors due to EINTR. Cc: qemu-stable@nongnu.org Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2020133 Fixes: 56a3c24ffc ("tpm: Probe for connected TPM 1.2 or TPM 2") Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Michael Tokarev <mjt@tls.msk.ru> Reviewed-by: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> (cherry picked from commit 8e32ddff69b6b4547cc00592ad816484e160817a) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: use TFR() instead of RETRY_ON_EINTR() before v7.2.0-538-g8b6aa69365)
2023-09-13s390x/ap: fix missing subsystem reset registrationJanosch Frank
A subsystem reset contains a reset of AP resources which has been missing. Adding the AP bridge to the list of device types that need reset fixes this issue. Reviewed-by: Jason J. Herne <jjherne@linux.ibm.com> Reviewed-by: Tony Krowiak <akrowiak@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Fixes: a51b3153 ("s390x/ap: base Adjunct Processor (AP) object model") Message-ID: <20230823142219.1046522-2-seiden@linux.ibm.com> Signed-off-by: Thomas Huth <thuth@redhat.com> (cherry picked from commit 297ec01f0b9864ea8209ca0ddc6643b4c0574bdb) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-13ui: fix crash when there are no active_consoleMarc-André Lureau
Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault. 0x0000555555888630 in dpy_ui_info_supported (con=0x0) at ../ui/console.c:812 812 return con->hw_ops->ui_info != NULL; (gdb) bt #0 0x0000555555888630 in dpy_ui_info_supported (con=0x0) at ../ui/console.c:812 #1 0x00005555558a44b1 in protocol_client_msg (vs=0x5555578c76c0, data=0x5555581e93f0 <incomplete sequence \373>, len=24) at ../ui/vnc.c:2585 #2 0x00005555558a19ac in vnc_client_read (vs=0x5555578c76c0) at ../ui/vnc.c:1607 #3 0x00005555558a1ac2 in vnc_client_io (ioc=0x5555581eb0e0, condition=G_IO_IN, opaque=0x5555578c76c0) at ../ui/vnc.c:1635 Fixes: https://issues.redhat.com/browse/RHEL-2600 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Albert Esteve <aesteve@redhat.com> (cherry picked from commit 48a35e12faf90a896c5aa4755812201e00d60316) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-13hw/tpm: TIS on sysbus: Remove unsupport ppi command line optionStefan Berger
The ppi command line option for the TIS device on sysbus never worked and caused an immediate segfault. Remove support for it since it also needs support in the firmware and needs testing inside the VM. Reproducer with the ppi=on option passed: qemu-system-aarch64 \ -machine virt,gic-version=3 \ -m 4G \ -nographic -no-acpi \ -chardev socket,id=chrtpm,path=/tmp/mytpm1/swtpm-sock \ -tpmdev emulator,id=tpm0,chardev=chrtpm \ -device tpm-tis-device,tpmdev=tpm0,ppi=on [...] Segmentation fault (core dumped) Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-id: 20230713171955.149236-1-stefanb@linux.ibm.com (cherry picked from commit 4c46fe2ed492f35f411632c8b5a8442f322bc3f0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-13target/riscv/pmp.c: respect mseccfg.RLB for pmpaddrX changesLeon Schuermann
When the rule-lock bypass (RLB) bit is set in the mseccfg CSR, the PMP configuration lock bits must not apply. While this behavior is implemented for the pmpcfgX CSRs, this bit is not respected for changes to the pmpaddrX CSRs. This patch ensures that pmpaddrX CSR writes work even on locked regions when the global rule-lock bypass is enabled. Signed-off-by: Leon Schuermann <leons@opentitan.org> Reviewed-by: Mayuresh Chitale <mchitale@ventanamicro.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230829215046.1430463-1-leon@is.currently.online> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 4e3adce1244e1ca30ec05874c3eca14911dc0825) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-13hw/riscv: virt: Fix riscv,pmu DT node pathConor Dooley
On a dtb dumped from the virt machine, dt-validate complains: soc: pmu: {'riscv,event-to-mhpmcounters': [[1, 1, 524281], [2, 2, 524284], [65561, 65561, 524280], [65563, 65563, 524280], [65569, 65569, 524280]], 'compatible': ['riscv,pmu']} should not be valid under {'type': 'object'} from schema $id: http://devicetree.org/schemas/simple-bus.yaml# That's pretty cryptic, but running the dtb back through dtc produces something a lot more reasonable: Warning (simple_bus_reg): /soc/pmu: missing or empty reg/ranges property Moving the riscv,pmu node out of the soc bus solves the problem. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Message-ID: <20230727-groom-decline-2c57ce42841c@spud> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 9ff31406312500053ecb5f92df01dd9ce52e635d) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: context adjustment due to 568e0614d09 "hw/riscv/virt.c: rename MachineState 'mc' pointers to 'ms'")
2023-09-13linux-user/riscv: Use abi type for target_ucontextLIU Zhiwei
We should not use types dependend on host arch for target_ucontext. This bug is found when run rv32 applications. Signed-off-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-ID: <20230811055438.1945-1-zhiwei_liu@linux.alibaba.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit ae7d4d625cab49657b9fc2be09d895afb9bcdaf0) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-13hw/intc: Make rtc variable names consistentJason Chien
The variables whose values are given by cpu_riscv_read_rtc() should be named "rtc". The variables whose value are given by cpu_riscv_read_rtc_raw() should be named "rtc_r". Signed-off-by: Jason Chien <jason.chien@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230728082502.26439-2-jason.chien@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit 9382a9eafccad8dc6a487ea3a8d2bed03dc35db9) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-13hw/intc: Fix upper/lower mtime write calculationJason Chien
When writing the upper mtime, we should keep the original lower mtime whose value is given by cpu_riscv_read_rtc() instead of cpu_riscv_read_rtc_raw(). The same logic applies to writes to lower mtime. Signed-off-by: Jason Chien <jason.chien@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-ID: <20230728082502.26439-1-jason.chien@sifive.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit e0922b73baf00c4c19d4ad30d09bb94f7ffea0f4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-13hw/char/riscv_htif: Fix printing of console characters on big endian hostsThomas Huth
The character that should be printed is stored in the 64 bit "payload" variable. The code currently tries to print it by taking the address of the variable and passing this pointer to qemu_chr_fe_write(). However, this only works on little endian hosts where the least significant bits are stored on the lowest address. To do this in a portable way, we have to store the value in an uint8_t variable instead. Fixes: 5033606780 ("RISC-V HTIF Console") Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Message-Id: <20230721094720.902454-2-thuth@redhat.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> (cherry picked from commit c255946e3df4d9660e4f468a456633c24393d468) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: edit to compensate for v7.2.0-805-g753ae97abc and v7.2.0-808-gdadee9e3ce)
2023-09-13arm64: Restore trapless ptimer accessColton Lewis
Due to recent KVM changes, QEMU is setting a ptimer offset resulting in unintended trap and emulate access and a consequent performance hit. Filter out the PTIMER_CNT register to restore trapless ptimer access. Quoting Andrew Jones: Simply reading the CNT register and writing back the same value is enough to set an offset, since the timer will have certainly moved past whatever value was read by the time it's written. QEMU frequently saves and restores all registers in the get-reg-list array, unless they've been explicitly filtered out (with Linux commit 680232a94c12, KVM_REG_ARM_PTIMER_CNT is now in the array). So, to restore trapless ptimer accesses, we need a QEMU patch to filter out the register. See https://lore.kernel.org/kvmarm/gsntttsonus5.fsf@coltonlewis-kvm.c.googlers.com/T/#m0770023762a821db2a3f0dd0a7dc6aa54e0d0da9 for additional context. Cc: qemu-stable@nongnu.org Signed-off-by: Andrew Jones <andrew.jones@linux.dev> Signed-off-by: Colton Lewis <coltonlewis@google.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Tested-by: Colton Lewis <coltonlewis@google.com> Message-id: 20230831190052.129045-1-coltonlewis@google.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org> (cherry picked from commit 682814e2a3c883b27f24b9e7cab47313c49acbd4) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-13virtio: Drop out of coroutine context in virtio_load()Kevin Wolf
virtio_load() as a whole should run in coroutine context because it reads from the migration stream and we don't want this to block. However, it calls virtio_set_features_nocheck() and devices don't expect their .set_features callback to run in a coroutine and therefore call functions that may not be called in coroutine context. To fix this, drop out of coroutine context for calling virtio_set_features_nocheck(). Without this fix, the following crash was reported: #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 #1 0x00007efc738c05d3 in __pthread_kill_internal (signo=6, threadid=<optimized out>) at pthread_kill.c:78 #2 0x00007efc73873d26 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007efc738477f3 in __GI_abort () at abort.c:79 #4 0x00007efc7384771b in __assert_fail_base (fmt=0x7efc739dbcb8 "", assertion=assertion@entry=0x560aebfbf5cf "!qemu_in_coroutine()", file=file@entry=0x560aebfcd2d4 "../block/graph-lock.c", line=line@entry=275, function=function@entry=0x560aebfcd34d "void bdrv_graph_rdlock_main_loop(void)") at assert.c:92 #5 0x00007efc7386ccc6 in __assert_fail (assertion=0x560aebfbf5cf "!qemu_in_coroutine()", file=0x560aebfcd2d4 "../block/graph-lock.c", line=275, function=0x560aebfcd34d "void bdrv_graph_rdlock_main_loop(void)") at assert.c:101 #6 0x0000560aebcd8dd6 in bdrv_register_buf () #7 0x0000560aeb97ed97 in ram_block_added.llvm () #8 0x0000560aebb8303f in ram_block_add.llvm () #9 0x0000560aebb834fa in qemu_ram_alloc_internal.llvm () #10 0x0000560aebb2ac98 in vfio_region_mmap () #11 0x0000560aebb3ea0f in vfio_bars_register () #12 0x0000560aebb3c628 in vfio_realize () #13 0x0000560aeb90f0c2 in pci_qdev_realize () #14 0x0000560aebc40305 in device_set_realized () #15 0x0000560aebc48e07 in property_set_bool.llvm () #16 0x0000560aebc46582 in object_property_set () #17 0x0000560aebc4cd58 in object_property_set_qobject () #18 0x0000560aebc46ba7 in object_property_set_bool () #19 0x0000560aeb98b3ca in qdev_device_add_from_qdict () #20 0x0000560aebb1fbaf in virtio_net_set_features () #21 0x0000560aebb46b51 in virtio_set_features_nocheck () #22 0x0000560aebb47107 in virtio_load () #23 0x0000560aeb9ae7ce in vmstate_load_state () #24 0x0000560aeb9d2ee9 in qemu_loadvm_state_main () #25 0x0000560aeb9d45e1 in qemu_loadvm_state () #26 0x0000560aeb9bc32c in process_incoming_migration_co.llvm () #27 0x0000560aebeace56 in coroutine_trampoline.llvm () Cc: qemu-stable@nongnu.org Buglink: https://issues.redhat.com/browse/RHEL-832 Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-ID: <20230905145002.46391-3-kwolf@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> (cherry picked from commit 92e2e6a867334a990f8d29f07ca34e3162fdd6ec) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (Mjt: remove coroutine_mixed_fn markings introduced in v7.2.0-909-g0f3de970fe)
2023-09-11qxl: don't assert() if device isn't yet initializedMarc-André Lureau
If the PCI BAR isn't yet mapped or was unmapped, QXL_IO_SET_MODE will assert(). Instead, report a guest bug and keep going. This can be reproduced with: cat << EOF | ./qemu-system-x86_64 -vga qxl -m 2048 -nodefaults -qtest stdio outl 0xcf8 0x8000101c outl 0xcfc 0xc000 outl 0xcf8 0x80001001 outl 0xcfc 0x01000000 outl 0xc006 0x00 EOF Fixes: https://gitlab.com/qemu-project/qemu/-/issues/1829 Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> (cherry picked from commit 95bef686e490bc3afc3f51f5fc6e20bf260b938c) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2023-09-11hw/net/vmxnet3: Fix guest-triggerable assert()Thomas Huth
The assert() that checks for valid MTU sizes can be triggered by the guest (e.g. with the reproducer code from the bug ticket https://gitlab.com/qemu-project/qemu/-/issues/517 ). Let's avoid this problem by simply logging the error and refusing to activate the device instead. Fixes: d05dcd94ae ("net: vmxnet3: validate configuration values during activate") Signed-off-by: Thomas Huth <thuth@redhat.com> Cc: qemu-stable@nongnu.org Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru> [Mjt: change format specifier from %d to %u for uint32_t argument] (cherry picked from commit 90a0778421acdf4ca903be64c8ed19378183c944) Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-14 18:20:03 +0000