qemu-commits
[Top][All Lists]
Advanced

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

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


From: mcayland
Subject: [Qemu-commits] [qemu/qemu] 2ad4eb: load_elf: fix iterator's type for elf file processing
Date: Mon, 22 Jan 2024 22:59:10 -0800

  Branch: refs/heads/staging-7.2
  Home:   https://github.com/qemu/qemu
  Commit: 2ad4ebb350fa3340488f2bb9c751726e449597e1
      
https://github.com/qemu/qemu/commit/2ad4ebb350fa3340488f2bb9c751726e449597e1
  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: 15e207b9ed89c843639f8674f318b50569869de7
      
https://github.com/qemu/qemu/commit/15e207b9ed89c843639f8674f318b50569869de7
  Author: Richard Henderson <richard.henderson@linaro.org>
  Date:   2024-01-20 (Sat, 20 Jan 2024)

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

  Log Message:
  -----------
  target/i386: Fix 32-bit wrapping of pc/eip computation

In 32-bit mode, pc = eip + cs_base is also 32-bit, and must wrap.
Failure to do so results in incorrect memory exceptions to the guest.
Before 732d548732ed, this was implicitly done via truncation to
target_ulong but only in qemu-system-i386, not qemu-system-x86_64.

To fix this, we must add conditional zero-extensions.
Since we have to test for 32 vs 64-bit anyway, note that cs_base
is always zero in 64-bit mode.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2022
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20231212172510.103305-1-richard.henderson@linaro.org>
(cherry picked from commit b5e0d5d22fbffc3d8f7d3e86d7a2d05a1a974e27)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: context fix in target/i386/tcg/tcg-cpu.c for v8.1.0-1190-gb77af26e97
 "accel/tcg: Replace CPUState.env_ptr with cpu_env()")
(Mjt: fixup in target/i386/tcg/tcg-cpu.c for v7.2.0-1854-g34a39c2443
 "target/i386: Replace `tb_pc()` with `tb->pc`")


  Commit: 6abbb26bbc8a7779876b70e184a2123f34531f0b
      
https://github.com/qemu/qemu/commit/6abbb26bbc8a7779876b70e184a2123f34531f0b
  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")
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: 7d6aebaec5d6eade830f2d08dc0b2bf7f5eee3b4
      
https://github.com/qemu/qemu/commit/7d6aebaec5d6eade830f2d08dc0b2bf7f5eee3b4
  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")
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: a290e43f5868f1276fdbb4fc66fe49c28fd5fa9a
      
https://github.com/qemu/qemu/commit/a290e43f5868f1276fdbb4fc66fe49c28fd5fa9a
  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>
(Mjt: fixup in target/i386/tcg/tcg-cpu.c target/i386/tcg/translate.c for
 v7.2.0-1839-g2e3afe8e19 "target/i386: Replace `TARGET_TB_PCREL` with 
`CF_PCREL`")


  Commit: 06679ac8b565b4485516336c497089d8ca2496f0
      
https://github.com/qemu/qemu/commit/06679ac8b565b4485516336c497089d8ca2496f0
  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: d56cc9b5e527fcc696616b7bedef24ae924c918c
      
https://github.com/qemu/qemu/commit/d56cc9b5e527fcc696616b7bedef24ae924c918c
  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: 16f6a650a8174f1582c14f00c746483fc9a99f3a
      
https://github.com/qemu/qemu/commit/16f6a650a8174f1582c14f00c746483fc9a99f3a
  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: 528496a5d4a2667869f07bdd1ec46f4d41171975
      
https://github.com/qemu/qemu/commit/528496a5d4a2667869f07bdd1ec46f4d41171975
  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: fd4e677c793855057a6204e1931eb927590f85f3
      
https://github.com/qemu/qemu/commit/fd4e677c793855057a6204e1931eb927590f85f3
  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>
(Mjt: fixup in hw/scsi/esp-pci.c due to v8.0.0-1556-g7d5b0d6864
 "bulk: Remove pointless QOM casts")


  Commit: 5bdc6b957148c96acc3471b22ea6c77f60592e1c
      
https://github.com/qemu/qemu/commit/5bdc6b957148c96acc3471b22ea6c77f60592e1c
  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: 7837d7e31de0603aed429b9bfa0615a71ce135e6
      
https://github.com/qemu/qemu/commit/7837d7e31de0603aed429b9bfa0615a71ce135e6
  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/c59ce9fef694...7837d7e31de0



reply via email to

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