[Top][All Lists]

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

[Qemu-commits] [qemu/qemu] bcb1e0: virtio-net: correctly report maximum

From: Klaus Jensen
Subject: [Qemu-commits] [qemu/qemu] bcb1e0: virtio-net: correctly report maximum tx_queue_size...
Date: Thu, 20 Jul 2023 04:43:52 -0700

  Branch: refs/heads/staging-8.0
  Home:   https://github.com/qemu/qemu
  Commit: bcb1e0522e77b49cf8a75c631fa8fe5b4b76202e
  Author: Laurent Vivier <lvivier@redhat.com>
  Date:   2023-07-09 (Sun, 09 Jul 2023)

  Changed paths:
    M hw/net/virtio-net.c

  Log Message:
  virtio-net: correctly report maximum tx_queue_size value

Maximum value for tx_queue_size depends on the backend type.
1024 for vDPA/vhost-user, 256 for all the others.

The value is returned by virtio_net_max_tx_queue_size() to set the

    n->net_conf.tx_queue_size = MIN(virtio_net_max_tx_queue_size(n),

But the parameter checking uses VIRTQUEUE_MAX_SIZE (1024).

So the parameter is silently ignored and ethtool reports a different
value than the one provided by the user.

   ... -netdev tap,... -device virtio-net,tx_queue_size=1024

    # ethtool -g enp0s2
    Ring parameters for enp0s2:
    Pre-set maximums:
    RX:         256
    RX Mini:    n/a
    RX Jumbo:   n/a
    TX:         256
    Current hardware settings:
    RX:         256
    RX Mini:    n/a
    RX Jumbo:   n/a
    TX:         256

   ... -netdev vhost-user,... -device virtio-net,tx_queue_size=2048

    Invalid tx_queue_size (= 2048), must be a power of 2 between 256 and 1024

With this patch the correct maximum value is checked and displayed.

For vDPA/vhost-user:

    Invalid tx_queue_size (= 2048), must be a power of 2 between 256 and 1024

For all the others:

    Invalid tx_queue_size (= 512), must be a power of 2 between 256 and 256

Fixes: 2eef278b9e63 ("virtio-net: fix tx queue size for !vhost-user")
Cc: mst@redhat.com
Cc: qemu-stable@nongnu.org
Signed-off-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 4271f4038372f174dbafffacca1a748d058a03ba)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

  Commit: 720db12b8b08874fb2e83f6c039b72cad1f11b16
  Author: Fiona Ebner <f.ebner@proxmox.com>
  Date:   2023-07-09 (Sun, 09 Jul 2023)

  Changed paths:
    M softmmu/runstate.c

  Log Message:
  qemu_cleanup: begin drained section after vm_shutdown()

in order to avoid requests being stuck in a BlockBackend's request
queue during cleanup. Having such requests can lead to a deadlock [0]
with a virtio-scsi-pci device using iothread that's busy with IO when
initiating a shutdown with QMP 'quit'.

There is a race where such a queued request can continue sometime
(maybe after bdrv_child_free()?) during bdrv_root_unref_child() [1].
The completion will hold the AioContext lock and wait for the BQL
during SCSI completion, but the main thread will hold the BQL and
wait for the AioContext as part of bdrv_root_unref_child(), leading to
the deadlock [0].


> Thread 3 (Thread 0x7f3bbd87b700 (LWP 135952) "qemu-system-x86"):
> #0  __lll_lock_wait (futex=futex@entry=0x564183365f00 <qemu_global_mutex>, 
> private=0) at lowlevellock.c:52
> #1  0x00007f3bc1c0d843 in __GI___pthread_mutex_lock (mutex=0x564183365f00 
> <qemu_global_mutex>) at ../nptl/pthread_mutex_lock.c:80
> #2  0x0000564182939f2e in qemu_mutex_lock_impl (mutex=0x564183365f00 
> <qemu_global_mutex>, file=0x564182b7f774 "../softmmu/physmem.c", line=2593) 
> at ../util/qemu-thread-posix.c:94
> #3  0x000056418247cc2a in qemu_mutex_lock_iothread_impl (file=0x564182b7f774 
> "../softmmu/physmem.c", line=2593) at ../softmmu/cpus.c:504
> #4  0x00005641826d5325 in prepare_mmio_access (mr=0x5641856148a0) at 
> ../softmmu/physmem.c:2593
> #5  0x00005641826d6fe7 in address_space_stl_internal (as=0x56418679b310, 
> addr=4276113408, val=16418, attrs=..., result=0x0, 
> endian=DEVICE_LITTLE_ENDIAN) at /home/febner/repos/qemu/memory_ldst.c.inc:318
> #6  0x00005641826d7154 in address_space_stl_le (as=0x56418679b310, 
> addr=4276113408, val=16418, attrs=..., result=0x0) at 
> /home/febner/repos/qemu/memory_ldst.c.inc:357
> #7  0x0000564182374b07 in pci_msi_trigger (dev=0x56418679b0d0, msg=...) at 
> ../hw/pci/pci.c:359
> #8  0x000056418237118b in msi_send_message (dev=0x56418679b0d0, msg=...) at 
> ../hw/pci/msi.c:379
> #9  0x0000564182372c10 in msix_notify (dev=0x56418679b0d0, vector=8) at 
> ../hw/pci/msix.c:542
> #10 0x000056418243719c in virtio_pci_notify (d=0x56418679b0d0, vector=8) at 
> ../hw/virtio/virtio-pci.c:77
> #11 0x00005641826933b0 in virtio_notify_vector (vdev=0x5641867a34a0, 
> vector=8) at ../hw/virtio/virtio.c:1985
> #12 0x00005641826948d6 in virtio_irq (vq=0x5641867ac078) at 
> ../hw/virtio/virtio.c:2461
> #13 0x0000564182694978 in virtio_notify (vdev=0x5641867a34a0, 
> vq=0x5641867ac078) at ../hw/virtio/virtio.c:2473
> #14 0x0000564182665b83 in virtio_scsi_complete_req (req=0x7f3bb000e5d0) at 
> ../hw/scsi/virtio-scsi.c:115
> #15 0x00005641826670ce in virtio_scsi_complete_cmd_req (req=0x7f3bb000e5d0) 
> at ../hw/scsi/virtio-scsi.c:641
> #16 0x000056418266736b in virtio_scsi_command_complete (r=0x7f3bb0010560, 
> resid=0) at ../hw/scsi/virtio-scsi.c:712
> #17 0x000056418239aac6 in scsi_req_complete (req=0x7f3bb0010560, status=2) at 
> ../hw/scsi/scsi-bus.c:1526
> #18 0x000056418239e090 in scsi_handle_rw_error (r=0x7f3bb0010560, ret=-123, 
> acct_failed=false) at ../hw/scsi/scsi-disk.c:242
> #19 0x000056418239e13f in scsi_disk_req_check_error (r=0x7f3bb0010560, 
> ret=-123, acct_failed=false) at ../hw/scsi/scsi-disk.c:265
> #20 0x000056418239e482 in scsi_dma_complete_noio (r=0x7f3bb0010560, ret=-123) 
> at ../hw/scsi/scsi-disk.c:340
> #21 0x000056418239e5d9 in scsi_dma_complete (opaque=0x7f3bb0010560, ret=-123) 
> at ../hw/scsi/scsi-disk.c:371
> #22 0x00005641824809ad in dma_complete (dbs=0x7f3bb000d9d0, ret=-123) at 
> ../softmmu/dma-helpers.c:107
> #23 0x0000564182480a72 in dma_blk_cb (opaque=0x7f3bb000d9d0, ret=-123) at 
> ../softmmu/dma-helpers.c:127
> #24 0x00005641827bf78a in blk_aio_complete (acb=0x7f3bb00021a0) at 
> ../block/block-backend.c:1563
> #25 0x00005641827bfa5e in blk_aio_write_entry (opaque=0x7f3bb00021a0) at 
> ../block/block-backend.c:1630
> #26 0x000056418295638a in coroutine_trampoline (i0=-1342102448, i1=32571) at 
> ../util/coroutine-ucontext.c:177
> #27 0x00007f3bc0caed40 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #28 0x00007f3bbd8757f0 in ?? ()
> #29 0x0000000000000000 in ?? ()
> Thread 1 (Thread 0x7f3bbe3e9280 (LWP 135944) "qemu-system-x86"):
> #0  __lll_lock_wait (futex=futex@entry=0x5641856f2a00, private=0) at 
> lowlevellock.c:52
> #1  0x00007f3bc1c0d8d1 in __GI___pthread_mutex_lock (mutex=0x5641856f2a00) at 
> ../nptl/pthread_mutex_lock.c:115
> #2  0x0000564182939f2e in qemu_mutex_lock_impl (mutex=0x5641856f2a00, 
> file=0x564182c0e319 "../util/async.c", line=728) at 
> ../util/qemu-thread-posix.c:94
> #3  0x000056418293a140 in qemu_rec_mutex_lock_impl (mutex=0x5641856f2a00, 
> file=0x564182c0e319 "../util/async.c", line=728) at 
> ../util/qemu-thread-posix.c:149
> #4  0x00005641829532d5 in aio_context_acquire (ctx=0x5641856f29a0) at 
> ../util/async.c:728
> #5  0x000056418279d5df in bdrv_set_aio_context_commit (opaque=0x5641856e6e50) 
> at ../block.c:7493
> #6  0x000056418294e288 in tran_commit (tran=0x56418630bfe0) at 
> ../util/transactions.c:87
> #7  0x000056418279d880 in bdrv_try_change_aio_context (bs=0x5641856f7130, 
> ctx=0x56418548f810, ignore_child=0x0, errp=0x0) at ../block.c:7626
> #8  0x0000564182793f39 in bdrv_root_unref_child (child=0x5641856f47d0) at 
> ../block.c:3242
> #9  0x00005641827be137 in blk_remove_bs (blk=0x564185709880) at 
> ../block/block-backend.c:914
> #10 0x00005641827bd689 in blk_remove_all_bs () at ../block/block-backend.c:583
> #11 0x0000564182798699 in bdrv_close_all () at ../block.c:5117
> #12 0x000056418248a5b2 in qemu_cleanup () at ../softmmu/runstate.c:821
> #13 0x0000564182738603 in qemu_default_main () at ../softmmu/main.c:38
> #14 0x0000564182738631 in main (argc=30, argv=0x7ffd675a8a48) at 
> ../softmmu/main.c:48
> (gdb) p *((QemuMutex*)0x5641856f2a00)
> $1 = {lock = {__data = {__lock = 2, __count = 2, __owner = 135952, ...
> (gdb) p *((QemuMutex*)0x564183365f00)
> $2 = {lock = {__data = {__lock = 2, __count = 0, __owner = 135944, ...


> Thread 1 "qemu-system-x86" hit Breakpoint 5, bdrv_drain_all_end () at 
> ../block/io.c:551
> #0  bdrv_drain_all_end () at ../block/io.c:551
> #1  0x00005569810f0376 in bdrv_graph_wrlock (bs=0x0) at 
> ../block/graph-lock.c:156
> #2  0x00005569810bd3e0 in bdrv_replace_child_noperm (child=0x556982e2d7d0, 
> new_bs=0x0) at ../block.c:2897
> #3  0x00005569810bdef2 in bdrv_root_unref_child (child=0x556982e2d7d0) at 
> ../block.c:3227
> #4  0x00005569810e8137 in blk_remove_bs (blk=0x556982e42880) at 
> ../block/block-backend.c:914
> #5  0x00005569810e7689 in blk_remove_all_bs () at ../block/block-backend.c:583
> #6  0x00005569810c2699 in bdrv_close_all () at ../block.c:5117
> #7  0x0000556980db45b2 in qemu_cleanup () at ../softmmu/runstate.c:821
> #8  0x0000556981062603 in qemu_default_main () at ../softmmu/main.c:38
> #9  0x0000556981062631 in main (argc=30, argv=0x7ffd7a82a418) at 
> ../softmmu/main.c:48
> [Switching to Thread 0x7fe76dab2700 (LWP 103649)]
> Thread 3 "qemu-system-x86" hit Breakpoint 4, blk_inc_in_flight 
> (blk=0x556982e42880) at ../block/block-backend.c:1505
> #0  blk_inc_in_flight (blk=0x556982e42880) at ../block/block-backend.c:1505
> #1  0x00005569810e8f36 in blk_wait_while_drained (blk=0x556982e42880) at 
> ../block/block-backend.c:1312
> #2  0x00005569810e9231 in blk_co_do_pwritev_part (blk=0x556982e42880, 
> offset=3422961664, bytes=4096, qiov=0x556983028060, qiov_offset=0, flags=0) 
> at ../block/block-backend.c:1402
> #3  0x00005569810e9a4b in blk_aio_write_entry (opaque=0x556982e2cfa0) at 
> ../block/block-backend.c:1628
> #4  0x000055698128038a in coroutine_trampoline (i0=-2090057872, i1=21865) at 
> ../util/coroutine-ucontext.c:177
> #5  0x00007fe770f50d40 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
> #6  0x00007ffd7a829570 in ?? ()
> #7  0x0000000000000000 in ?? ()

Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Message-ID: <20230706131418.423713-1-f.ebner@proxmox.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit ca2a5e630dc1f569266fb663bf0b65e4eb433fb2)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

  Commit: 73d6ac24c81f1aeae554d469616c9181511e6523
  Author: Nicholas Piggin <npiggin@gmail.com>
  Date:   2023-07-17 (Mon, 17 Jul 2023)

  Changed paths:
    M hw/ppc/ppc.c

  Log Message:
  hw/ppc: Fix clock update drift

The clock update logic reads the clock twice to compute the new clock
value, with a value derived from the later time subtracted from a value
derived from the earlier time. The delta causes time to be lost.

This can ultimately result in time becoming unsynchronized between CPUs
and that can cause OS lockups, timeouts, watchdogs, etc. This can be
seen running a KVM guest (that causes lots of TB updates) on a powernv
SMP machine.

Fix this by reading the clock once.

Cc: qemu-stable@nongnu.org
Fixes: dbdd25065e90 ("Implement time-base start/stop helpers.")
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Reviewed-by: Frederic Barrat <fbarrat@linux.ibm.com>
Message-ID: <20230629020713.327745-1-npiggin@gmail.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
(cherry picked from commit 2ad2e113deb5663e69a05dd6922cbfc6d7ea34d3)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

  Commit: 184ca26d1970ea34a89f0b79a63f6e0d48b672b3
  Author: Helge Deller <deller@gmx.de>
  Date:   2023-07-17 (Mon, 17 Jul 2023)

  Changed paths:
    M linux-user/syscall.c

  Log Message:
  linux-user: Fix accept4(SOCK_NONBLOCK) syscall

The Linux accept4() syscall allows two flags only: SOCK_NONBLOCK and
SOCK_CLOEXEC, and returns -EINVAL if any other bits have been set.

Change the qemu implementation accordingly, which means we can not use
the fcntl_flags_tbl[] translation table which allows too many other

Beside the correction in behaviour, this actually fixes the accept4()
emulation for hppa, mips and alpha targets for which SOCK_NONBLOCK is

The fix can be verified with the testcase of the debian lwt package,
which hangs forever in a read() syscall without this patch.

Signed-off-by: Helge Deller <deller@gmx.de>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit dca4c8384d68bbf5d67f50a5446865d92d61f032)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

  Commit: 7b4f58f4c84c29502f92c3379e86fa2c1a86c6b7
  Author: Avihai Horon <avihaih@nvidia.com>
  Date:   2023-07-17 (Mon, 17 Jul 2023)

  Changed paths:
    M hw/vfio/pci.c

  Log Message:
  vfio: Fix null pointer dereference bug in vfio_bars_finalize()

vfio_realize() has the following flow:
1. vfio_bars_prepare() -- sets VFIOBAR->size.
2. msix_early_setup().
3. vfio_bars_register() -- allocates VFIOBAR->mr.

After vfio_bars_prepare() is called msix_early_setup() can fail. If it
does fail, vfio_bars_register() is never called and VFIOBAR->mr is not

In this case, vfio_bars_finalize() is called as part of the error flow
to free the bars' resources. However, vfio_bars_finalize() calls
object_unparent() for VFIOBAR->mr after checking only VFIOBAR->size, and
thus we get a null pointer dereference.

Fix it by checking VFIOBAR->mr in vfio_bars_finalize().

Fixes: 89d5202edc50 ("vfio/pci: Allow relocating MSI-X MMIO")
Signed-off-by: Avihai Horon <avihaih@nvidia.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Cédric Le Goater <clg@redhat.com>
Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Cédric Le Goater <clg@redhat.com>
(cherry picked from commit 8af87a3ec7e42ff1b9cf75ceee0451c31e34d153)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

  Commit: 8963a406392328fd6d329b71029b0962c318ed9a
  Author: Ilya Leoshkevich <iii@linux.ibm.com>
  Date:   2023-07-17 (Mon, 17 Jul 2023)

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

  Log Message:
  target/s390x: Fix EPSW CC reporting

EPSW should explicitly calculate and insert CC, like IPM does.

Fixes: e30a9d3fea58 ("target-s390: Implement EPSW")
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Cc: qemu-stable@nongnu.org
Message-Id: <20230704081506.276055-3-iii@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 110b1bac2ecd94a78a1d38003e24e37367bf074e)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

  Commit: 1aa3f9bfdac4f110b17ee1ee8ea8216d1531d53a
  Author: Ilya Leoshkevich <iii@linux.ibm.com>
  Date:   2023-07-17 (Mon, 17 Jul 2023)

  Changed paths:
    M target/s390x/tcg/fpu_helper.c
    M target/s390x/tcg/insn-data.h.inc

  Log Message:
  target/s390x: Fix MDEB and MDEBR

These instructions multiply 32 bits by 32 bits, not 32 bits by 64 bits.

Fixes: 83b00736f3d8 ("target-s390: Convert FP MULTIPLY")
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Cc: qemu-stable@nongnu.org
Message-Id: <20230704081506.276055-4-iii@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit fed9a4fe0ce0ec917a6b3a2da0a7ecd3cb9eba56)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

  Commit: fb650a4a525f02c29af78c7202b7d978613b7385
  Author: Ilya Leoshkevich <iii@linux.ibm.com>
  Date:   2023-07-17 (Mon, 17 Jul 2023)

  Changed paths:
    M target/s390x/tcg/mem_helper.c

  Log Message:
  target/s390x: Fix MVCRL with a large value in R0

Using a large R0 causes an assertion error:

    qemu-s390x: target/s390x/tcg/mem_helper.c:183: access_prepare_nf: Assertion 
`size > 0 && size <= 4096' failed.

Even though PoP explicitly advises against using more than 8 bits for the
size, an emulator crash is never a good thing.

Fix by truncating the size to 8 bits.

Fixes: ea0a1053e276 ("s390x/tcg: Implement Miscellaneous-Instruction-Extensions 
Facility 3 for the s390x")
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Cc: qemu-stable@nongnu.org
Message-Id: <20230704081506.276055-5-iii@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 92a57534619a4058544ce8f9c0beae3e054f342b)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

  Commit: 6d344ab59175c56d706d3081a3b2565eb6ef2161
  Author: Ilya Leoshkevich <iii@linux.ibm.com>
  Date:   2023-07-17 (Mon, 17 Jul 2023)

  Changed paths:
    M target/s390x/helper.h
    M target/s390x/tcg/mem_helper.c
    M target/s390x/tcg/translate.c

  Log Message:
  target/s390x: Fix LRA overwriting the top 32 bits on DAT error

When a DAT error occurs, LRA is supposed to write the error information
to the bottom 32 bits of R1, and leave the top 32 bits of R1 alone.

Fix by passing the original value of R1 into helper and copying the
top 32 bits to the return value.

Fixes: d8fe4a9c284f ("target-s390: Convert LRA")
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Cc: qemu-stable@nongnu.org
Message-Id: <20230704081506.276055-6-iii@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 6da311a60d58dba27f5f790217d5ebba944e34ab)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

  Commit: 85b919481900a9fed43c6c26fab0e799f9628af9
  Author: Ilya Leoshkevich <iii@linux.ibm.com>
  Date:   2023-07-17 (Mon, 17 Jul 2023)

  Changed paths:
    M target/s390x/mmu_helper.c

  Log Message:
  target/s390x: Fix LRA when DAT is off

LRA should perform DAT regardless of whether it's on or off.
Disable DAT check for MMU_S390_LRA.

Fixes: defb0e3157af ("s390x: Implement opcode helpers")
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Cc: qemu-stable@nongnu.org
Message-Id: <20230704081506.276055-7-iii@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit b0ef81062d2404ccef0289b1cc6e70244901c9be)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

  Commit: 8769dd539d7709ae061a8749a510866b0a2ebca4
  Author: Marcin Nowakowski <marcin.nowakowski@fungible.com>
  Date:   2023-07-17 (Mon, 17 Jul 2023)

  Changed paths:
    M target/mips/cpu-defs.c.inc

  Log Message:
  target/mips: enable GINVx support for I6400 and I6500

GINVI and GINVT operations are supported on MIPS I6400 and I6500 cores,
so indicate that properly in CP0.Config5 register bits [16:15].

Cc: qemu-stable@nongnu.org
Signed-off-by: Marcin Nowakowski <marcin.nowakowski@fungible.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-Id: <20230630072806.3093704-1-marcin.nowakowski@fungible.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
(cherry picked from commit baf21eebc3e1026d21d94fdf8ca470050e49968f)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

  Commit: b6f69fba8b09530c027f69290a35ffe5c24f5568
  Author: Olaf Hering <olaf@aepfle.de>
  Date:   2023-07-17 (Mon, 17 Jul 2023)

  Changed paths:
    M hw/ide/piix.c

  Log Message:
  hw/ide/piix: properly initialize the BMIBA register

According to the 82371FB documentation (82371FB.pdf, 2.3.9. BMIBA-BUS
32bit wide. To properly reset it to default values, all 32bit need to be
cleared. Bit #0 "Resource Type Indicator (RTE)" needs to be enabled.

The initial change wrote just the lower 8 bit, leaving parts of the "Bus
Master Interface Base Address" address at bit 15:4 unchanged.

Fixes: e6a71ae327 ("Add support for 82371FB (Step A1) and Improved support for 
82371SB (Function 1)")

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Reviewed-by: Bernhard Beschow <shentey@gmail.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20230712074721.14728-1-olaf@aepfle.de>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 230dfd9257e92259876c113e58b5f0d22b056d2e)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

  Commit: fb1d3b4dc0dd37c361a9cf3be7e4d707d227a0ea
  Author: Pierrick Bouvier <pierrick.bouvier@linaro.org>
  Date:   2023-07-17 (Mon, 17 Jul 2023)

  Changed paths:
    M linux-user/syscall.c

  Log Message:
  linux-user/syscall: Implement execve without execveat

Support for execveat syscall was implemented in 55bbe4 and is available
since QEMU 8.0.0. It relies on host execveat, which is widely available
on most of Linux kernels today.

However, this change breaks qemu-user self emulation, if "host" qemu
version is less than 8.0.0. Indeed, it does not implement yet execveat.
This strange use case happens with most of distribution today having
binfmt support.

With a concrete failing example:
$ qemu-x86_64-7.2 qemu-x86_64-8.0 /bin/bash -c /bin/ls
/bin/bash: line 1: /bin/ls: Function not implemented
-> not implemented means execve returned ENOSYS

qemu-user-static 7.2 and 8.0 can be conveniently grabbed from debian
packages qemu-user-static* [1].

One usage of this is running wine-arm64 from linux-x64 (details [2]).
This is by updating qemu embedded in docker image that we ran into this

The solution to update host qemu is not always possible. Either it's
complicated or ask you to recompile it, or simply is not accessible
(GitLab CI, GitHub Actions). Thus, it could be worth to implement execve
without relying on execveat, which is the goal of this patch.

This patch was tested with example presented in this commit message.

[1] http://ftp.us.debian.org/debian/pool/main/q/qemu/
[1] https://www.linaro.org/blog/emulate-windows-on-arm/

Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
Message-Id: <20230705121023.973284-1-pierrick.bouvier@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit 7a8d9f3a0e882df50681e40f09c29cfb4966ea2d)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

  Commit: 1dfc8d9e5c377f53f4411d8c389cf71364613464
  Author: Richard Henderson <richard.henderson@linaro.org>
  Date:   2023-07-17 (Mon, 17 Jul 2023)

  Changed paths:
    M tcg/tcg.c

  Log Message:
  tcg: Fix info_in_idx increment in layout_arg_by_ref

Off by one error, failing to take into account that layout_arg_1
already incremented info_in_idx for the first piece.  We only
need care for the n-1 TCG_CALL_ARG_BY_REF_N pieces here.

Cc: qemu-stable@nongnu.org
Fixes: 313bdea84d2 ("tcg: Add TCG_CALL_{RET,ARG}_BY_REF")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1751
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit e18ed26ce785f74a17e6f3a095647e08ba6fc669)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

  Commit: 91e7b5d4f876c8c5d54fe94ce4320d63efd9561a
  Author: Philippe Mathieu-Daudé <philmd@linaro.org>
  Date:   2023-07-18 (Tue, 18 Jul 2023)

  Changed paths:
    M linux-user/elfload.c

  Log Message:
  linux-user/arm: Do not allocate a commpage at all for M-profile CPUs

Since commit fbd3c4cff6 ("linux-user/arm: Mark the commpage
executable") executing bare-metal (linked with rdimon.specs)
cortex-M code fails as:

  $ qemu-arm -cpu cortex-m3 ~/hello.exe.m3
  qemu-arm: ../../accel/tcg/user-exec.c:492: page_set_flags: Assertion `last <= 
  Aborted (core dumped)

Commit 4f5c67f8df ("linux-user/arm: Take more care allocating
commpage") already took care of not allocating a commpage for
M-profile CPUs, however it had to be reverted as commit 6cda41daa2.

Re-introduce the M-profile fix from commit 4f5c67f8df.

Fixes: fbd3c4cff6 ("linux-user/arm: Mark the commpage executable")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1755
Reported-by: Christophe Lyon <christophe.lyon@linaro.org>
Suggested-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Anton Johansson <anjo@rev.ng>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20230711153408.68389-1-philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit d713cf4d6c71076513a10528303b3e337b4d5998)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

  Commit: 85897a594716617505f953d41638934a2d45d663
  Author: Mauro Matteo Cascella <mcascell@redhat.com>
  Date:   2023-07-18 (Tue, 18 Jul 2023)

  Changed paths:
    M ui/vnc-clipboard.c

  Log Message:
  ui/vnc-clipboard: fix infinite loop in inflate_buffer (CVE-2023-3255)

A wrong exit condition may lead to an infinite loop when inflating a
valid zlib buffer containing some extra bytes in the `inflate_buffer`
function. The bug only occurs post-authentication. Return the buffer
immediately if the end of the compressed data has been reached

Fixes: CVE-2023-3255
Fixes: 0bf41cab ("ui/vnc: clipboard support")
Reported-by: Kevin Denis <kevin.denis@synacktiv.com>
Signed-off-by: Mauro Matteo Cascella <mcascell@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Tested-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-ID: <20230704084210.101822-1-mcascell@redhat.com>
(cherry picked from commit d921fea338c1059a27ce7b75309d7a2e485f710b)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

  Commit: 9de4eebc878845b65cd1096d93d1d285453615ab
  Author: Andreas Schwab <schwab@suse.de>
  Date:   2023-07-19 (Wed, 19 Jul 2023)

  Changed paths:
    M linux-user/syscall.c

  Log Message:
  linux-user: Make sure initial brk(0) is page-aligned

Fixes: 86f04735ac ("linux-user: Fix brk() to release pages")
Signed-off-by: Andreas Schwab <schwab@suse.de>
Message-Id: <mvmpm55qnno.fsf@suse.de>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit d28b3c90cfad1a7e211ae2bce36ecb9071086129)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

  Commit: e25c2a96bb5d40e74b9e0572a1177498ed7d615c
  Author: Klaus Jensen <k.jensen@samsung.com>
  Date:   2023-07-19 (Wed, 19 Jul 2023)

  Changed paths:
    M hw/nvme/ctrl.c

  Log Message:
  hw/nvme: fix endianness issue for shadow doorbells

In commit 2fda0726e514 ("hw/nvme: fix missing endian conversions for
doorbell buffers"), we fixed shadow doorbells for big-endian guests
running on little endian hosts. But I did not fix little-endian guests
on big-endian hosts. Fix this.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1765
Fixes: 3f7fe8de3d49 ("hw/nvme: Implement shadow doorbell buffer support")
Cc: qemu-stable@nongnu.org
Reported-by: Thomas Huth <thuth@redhat.com>
Tested-by: Cédric Le Goater <clg@redhat.com>
Tested-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Keith Busch <kbusch@kernel.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Klaus Jensen <k.jensen@samsung.com>
(cherry picked from commit ea3c76f1494d0c75873c3b470e6e048202661ad8)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

Compare: https://github.com/qemu/qemu/compare/a342ce9dfeed...e25c2a96bb5d

reply via email to

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