qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] 357b59: load_elf: fix iterator's type for elf


From: mcayland
Subject: [Qemu-commits] [qemu/qemu] 357b59: load_elf: fix iterator's type for elf file processing
Date: Tue, 23 Jan 2024 00:54:57 -0800

  Branch: refs/heads/staging-8.1
  Home:   https://github.com/qemu/qemu
  Commit: 357b5990284107dfa36d234e3dcbf77e0e1367e0
      
https://github.com/qemu/qemu/commit/357b5990284107dfa36d234e3dcbf77e0e1367e0
  Author: Anastasia Belova <abelova@astralinux.ru>
  Date:   2024-01-19 (Fri, 19 Jan 2024)

  Changed paths:
    M include/hw/elf_ops.h

  Log Message:
  -----------
  load_elf: fix iterator's type for elf file processing

j is used while loading an ELF file to byteswap segments'
data. If data is larger than 2GB an overflow may happen.
So j should be elf_word.

This commit fixes a minor bug: it's unlikely anybody is trying to
load ELF files with 2GB+ segments for wrong-endianness targets,
but if they did, it wouldn't work correctly.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Cc: qemu-stable@nongnu.org
Fixes: 7ef295ea5b ("loader: Add data swap option to load-elf")
Signed-off-by: Anastasia Belova <abelova@astralinux.ru>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 410c2a4d75f52f6a2fe978eda5a9b6f854afe5ea)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 99e32260ac203040ea1f9c1c2930298ab1dee9cf
      
https://github.com/qemu/qemu/commit/99e32260ac203040ea1f9c1c2930298ab1dee9cf
  Author: Richard Henderson <richard.henderson@linaro.org>
  Date:   2024-01-20 (Sat, 20 Jan 2024)

  Changed paths:
    M target/i386/tcg/translate.c

  Log Message:
  -----------
  target/i386: Do not re-compute new pc with CF_PCREL

With PCREL, we have a page-relative view of EIP, and an
approximation of PC = EIP+CSBASE that is good enough to
detect page crossings.  If we try to recompute PC after
masking EIP, we will mess up that approximation and write
a corrupt value to EIP.

We already handled masking properly for PCREL, so the
fix in b5e0d5d2 was only needed for the !PCREL path.

Cc: qemu-stable@nongnu.org
Fixes: b5e0d5d22fbf ("target/i386: Fix 32-bit wrapping of pc/eip computation")
Fixes: 5b2fd6cf3735 (b5e0d5d22fbf in 8.1.4)
Reported-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20240101230617.129349-1-richard.henderson@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit a58506b748b8988a95f4fa1a2420ac5c17038b30)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 57078586026b2ff8c052f909a120118058a7fd57
      
https://github.com/qemu/qemu/commit/57078586026b2ff8c052f909a120118058a7fd57
  Author: guoguangyao <guoguangyao18@mails.ucas.ac.cn>
  Date:   2024-01-20 (Sat, 20 Jan 2024)

  Changed paths:
    M target/i386/tcg/translate.c

  Log Message:
  -----------
  target/i386: fix incorrect EIP in PC-relative translation blocks

The PCREL patches introduced a bug when updating EIP in the !CF_PCREL case.
Using s->pc in func gen_update_eip_next() solves the problem.

Cc: qemu-stable@nongnu.org
Fixes: b5e0d5d22fbf ("target/i386: Fix 32-bit wrapping of pc/eip computation")
Fixes: 5b2fd6cf3735 (b5e0d5d22fbf in 8.1.4)
Signed-off-by: guoguangyao <guoguangyao18@mails.ucas.ac.cn>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20240115020804.30272-1-guoguangyao18@mails.ucas.ac.cn>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 2926eab8969908bc068629e973062a0fb6ff3759)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 7b03b125ee36d0e98f12c80ca8a85d9597a7dc0e
      
https://github.com/qemu/qemu/commit/7b03b125ee36d0e98f12c80ca8a85d9597a7dc0e
  Author: Paolo Bonzini <pbonzini@redhat.com>
  Date:   2024-01-20 (Sat, 20 Jan 2024)

  Changed paths:
    M target/i386/tcg/tcg-cpu.c
    M target/i386/tcg/translate.c

  Log Message:
  -----------
  target/i386: pcrel: store low bits of physical address in data[0]

For PC-relative translation blocks, env->eip changes during the
execution of a translation block, Therefore, QEMU must be able to
recover an instruction's PC just from the TranslationBlock struct and
the instruction data with.  Because a TB will not span two pages, QEMU
stores all the low bits of EIP in the instruction data and replaces them
in x86_restore_state_to_opc.  Bits 12 and higher (which may vary between
executions of a PCREL TB, since these only use the physical address in
the hash key) are kept unmodified from env->eip.  The assumption is that
these bits of EIP, unlike bits 0-11, will not change as the translation
block executes.

Unfortunately, this is incorrect when the CS base is not aligned to a page.
Then the linear address of the instructions (i.e. the one with the
CS base addred) indeed will never span two pages, but bits 12+ of EIP
can actually change.  For example, if CS base is 0x80262200 and EIP =
0x6FF4, the first instruction in the translation block will be at linear
address 0x802691F4.  Even a very small TB will cross to EIP = 0x7xxx,
while the linear addresses will remain comfortably within a single page.

The fix is simply to use the low bits of the linear address for data[0],
since those don't change.  Then x86_restore_state_to_opc uses tb->cs_base
to compute a temporary linear address (referring to some unknown
instruction in the TB, but with the correct values of bits 12 and higher);
the low bits are replaced with data[0], and EIP is obtained by subtracting
again the CS base.

Huge thanks to Mark Cave-Ayland for the image and initial debugging,
and to Gitlab user @kjliew for help with bisecting another occurrence
of (hopefully!) the same bug.

It should be relatively easy to write a testcase that performs MMIO on
an EIP with different bits 12+ than the first instruction of the translation
block; any help is welcome.

Fixes: e3a79e0e878 ("target/i386: Enable TARGET_TB_PCREL", 2022-10-11)
Cc: qemu-stable@nongnu.org
Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Cc: Richard Henderson <richard.henderson@linaro.org>
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1759
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1964
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2012
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 729ba8e933f8af5800c3a92b37e630e9bdaa9f1e)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: a8988972cd2c724019bbf409f3375eb0f958d020
      
https://github.com/qemu/qemu/commit/a8988972cd2c724019bbf409f3375eb0f958d020
  Author: Philippe Mathieu-Daudé <philmd@linaro.org>
  Date:   2024-01-20 (Sat, 20 Jan 2024)

  Changed paths:
    M backends/cryptodev.c

  Log Message:
  -----------
  backends/cryptodev: Do not ignore throttle/backends Errors

Both cryptodev_backend_set_throttle() and CryptoDevBackendClass::init()
can set their Error** argument. Do not ignore them, return early
on failure. Without that, running into another failure trips
error_setv()'s assertion. Use the ERRP_GUARD() macro as suggested
in commit ae7c80a7bd ("error: New macro ERRP_GUARD()").

Cc: qemu-stable@nongnu.org
Fixes: e7a775fd9f ("cryptodev: Account statistics")
Fixes: 2580b452ff ("cryptodev: support QoS")
Reviewed-by: zhenwei pi <pizhenwei@bytedance.com>
Reviewed-by: Gonglei <arei.gonglei@huawei.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20231120150418.93443-1-philmd@linaro.org>
(cherry picked from commit 484aecf2d3a75251b63481be2a0c3aef635002af)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: d83b0f64aaa366744046db61c9caae9991f64940
      
https://github.com/qemu/qemu/commit/d83b0f64aaa366744046db61c9caae9991f64940
  Author: Gerd Hoffmann <kraxel@redhat.com>
  Date:   2024-01-20 (Sat, 20 Jan 2024)

  Changed paths:
    M hw/block/pflash_cfi01.c

  Log Message:
  -----------
  hw/pflash: refactor pflash_data_write()

Move the offset calculation, do it once at the start of the function and
let the 'p' variable point directly to the memory location which should
be updated.  This makes it simpler to update other buffers than
pfl->storage in an upcoming patch.  No functional change.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20240108160900.104835-2-kraxel@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 3b14a555fdb627ac091559ef5931c887d06590d8)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: dd25df302e8e3c6a095d70c9e23482683c56a14d
      
https://github.com/qemu/qemu/commit/dd25df302e8e3c6a095d70c9e23482683c56a14d
  Author: Gerd Hoffmann <kraxel@redhat.com>
  Date:   2024-01-20 (Sat, 20 Jan 2024)

  Changed paths:
    M hw/block/pflash_cfi01.c

  Log Message:
  -----------
  hw/pflash: use ldn_{be,le}_p and stn_{be,le}_p

Use the helper functions we have to read/write multi-byte values
in correct byte order.

Suggested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20240108160900.104835-3-kraxel@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 5dd58358a57048e5ceabf5c91c0544f4f56afdcd)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: fcc79f2e09550b0461792491965fe202ed2219ae
      
https://github.com/qemu/qemu/commit/fcc79f2e09550b0461792491965fe202ed2219ae
  Author: Gerd Hoffmann <kraxel@redhat.com>
  Date:   2024-01-20 (Sat, 20 Jan 2024)

  Changed paths:
    M hw/block/pflash_cfi01.c
    M hw/block/pflash_cfi02.c
    M hw/block/trace-events

  Log Message:
  -----------
  hw/pflash: implement update buffer for block writes

Add an update buffer where all block updates are staged.
Flush or discard updates properly, so we should never see
half-completed block writes in pflash storage.

Drop a bunch of FIXME comments ;)

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20240108160900.104835-4-kraxel@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 284a7ee2e290e0c9b8cd3ea6164d92386933054f)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: drop const in hw/block/pflash_cfi01.c for before
 v8.2.0-220-g7d5dc0a367 "hw/block: Constify VMState")


  Commit: 2472f8467d5ca0d7459a4c2ff3a0cbe2240c41ca
      
https://github.com/qemu/qemu/commit/2472f8467d5ca0d7459a4c2ff3a0cbe2240c41ca
  Author: Nick Briggs <nicholas.h.briggs@gmail.com>
  Date:   2024-01-20 (Sat, 20 Jan 2024)

  Changed paths:
    M migration/rdma.c

  Log Message:
  -----------
  migration/rdma: define htonll/ntohll only if not predefined

Solaris has #defines for htonll and ntohll which cause syntax errors
when compiling code that attempts to (re)define these functions..

Signed-off-by: Nick Briggs <nicholas.h.briggs@gmail.com>
Link: https://lore.kernel.org/r/65a04a7d.497ab3.3e7bef1f@gateway.sonic.net
Signed-off-by: Peter Xu <peterx@redhat.com>
(cherry picked from commit 44ce1b5d2fc77343f6a318cb3de613336a240048)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 2cd67d013dab3f7e0482a765acda70edffd8b786
      
https://github.com/qemu/qemu/commit/2cd67d013dab3f7e0482a765acda70edffd8b786
  Author: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Date:   2024-01-20 (Sat, 20 Jan 2024)

  Changed paths:
    M hw/scsi/esp-pci.c

  Log Message:
  -----------
  hw/scsi/esp-pci: use correct address register for PCI DMA transfers

The current code in esp_pci_dma_memory_rw() sets the DMA address to the value
of the DMA_SPA (Starting Physical Address) register which is incorrect: this
means that for each callback from the SCSI layer the DMA address is set back
to the starting address.

In the case where only a single SCSI callback occurs (currently for transfer
lengths < 128kB) this works fine, however for larger transfers the DMA address
wraps back to the initial starting address, corrupting the buffer holding the
data transferred to the guest.

Fix esp_pci_dma_memory_rw() to use the DMA_WAC (Working Address Counter) for
the DMA address which is correctly incremented across multiple SCSI layer
transfers.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Message-ID: <20240112131529.515642-2-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 84a6835e004c257037492167d4f266dbb54dc33e)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: e8cb1260753863fe04c460b949a8d1aec304e3ee
      
https://github.com/qemu/qemu/commit/e8cb1260753863fe04c460b949a8d1aec304e3ee
  Author: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Date:   2024-01-20 (Sat, 20 Jan 2024)

  Changed paths:
    M hw/scsi/esp-pci.c

  Log Message:
  -----------
  hw/scsi/esp-pci: generate PCI interrupt from separate ESP and PCI sources

The am53c974/dc390 PCI interrupt has two separate sources: the first is from the
internal ESP device, and the second is from the PCI DMA transfer logic.

Update the ESP interrupt handler so that it sets DMA_STAT_SCSIINT rather than
driving the PCI IRQ directly, and introduce a new esp_pci_update_irq() function
to generate the correct PCI IRQ level. In particular this fixes spurious 
interrupts
being generated by setting DMA_STAT_DONE at the end of a transfer if 
DMA_CMD_INTE_D
isn't set in the DMA_CMD register.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Message-ID: <20240112131529.515642-3-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 6b41417d934b2640b7ccf893544d656eea92a2e7)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 01db312e3bd4c2a834027dac83ad5a08f3573f6f
      
https://github.com/qemu/qemu/commit/01db312e3bd4c2a834027dac83ad5a08f3573f6f
  Author: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Date:   2024-01-20 (Sat, 20 Jan 2024)

  Changed paths:
    M hw/scsi/esp-pci.c

  Log Message:
  -----------
  hw/scsi/esp-pci: synchronise setting of DMA_STAT_DONE with ESP completion 
interrupt

The setting of DMA_STAT_DONE at the end of a DMA transfer can be configured to
generate an interrupt, however the Linux driver manually checks for 
DMA_STAT_DONE
being set and if it is, considers that a DMA transfer has completed.

If DMA_STAT_DONE is set but the ESP device isn't indicating an interrupt then
the Linux driver considers this to be a spurious interrupt. However this can
occur in QEMU as there is a delay between the end of DMA transfer where
DMA_STAT_DONE is set, and the ESP device raising its completion interrupt.

This appears to be an incorrect assumption in the Linux driver as the ESP and
PCI DMA interrupt sources are separate (and may not be raised exactly
together), however we can work around this by synchronising the setting of
DMA_STAT_DONE at the end of a DMA transfer with the ESP completion interrupt.

In conjunction with the previous commit Linux is now able to correctly boot
from an am53c974 PCI SCSI device on the hppa C3700 machine without emitting
"iget: checksum invalid" and "Spurious irq, sreg=10" errors.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Message-ID: <20240112131529.515642-4-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit 1e8e6644e063b20ad391140fae13d00ad7750b33)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


  Commit: 72694a69c98723f51a0b4ab8113ab0362029c753
      
https://github.com/qemu/qemu/commit/72694a69c98723f51a0b4ab8113ab0362029c753
  Author: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
  Date:   2024-01-20 (Sat, 20 Jan 2024)

  Changed paths:
    M hw/scsi/esp-pci.c

  Log Message:
  -----------
  hw/scsi/esp-pci: set DMA_STAT_BCMBLT when BLAST command issued

Even though the BLAST command isn't fully implemented in QEMU, the 
DMA_STAT_BCMBLT
bit should be set after the command has been issued to indicate that the command
has completed.

This fixes an issue with the DC390 DOS driver which issues the BLAST command as
part of its normal error recovery routine at startup, and otherwise sits in a
tight loop waiting for DMA_STAT_BCMBLT to be set before continuing.

Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Message-ID: <20240112131529.515642-5-mark.cave-ayland@ilande.co.uk>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit c2d7de557d19ec76eb83b87b6bf77c8114e2f183)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>


Compare: https://github.com/qemu/qemu/compare/d6488e518670...72694a69c987



reply via email to

[Prev in Thread] Current Thread [Next in Thread]