[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] 86d7b0: block-migration: Ensure we don't cras
|
From: |
Alex Bennée |
|
Subject: |
[Qemu-commits] [qemu/qemu] 86d7b0: block-migration: Ensure we don't crash during migr... |
|
Date: |
Thu, 21 Sep 2023 09:36:57 -0700 |
Branch: refs/heads/staging-8.1
Home: https://github.com/qemu/qemu
Commit: 86d7b08d712c63430ea327fab1c9a180897a7918
https://github.com/qemu/qemu/commit/86d7b08d712c63430ea327fab1c9a180897a7918
Author: Fabiano Rosas <farosas@suse.de>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M migration/block.c
Log Message:
-----------
block-migration: Ensure we don't crash during migration cleanup
We can fail the blk_insert_bs() at init_blk_migration(), leaving the
BlkMigDevState without a dirty_bitmap and BlockDriverState. Account
for the possibly missing elements when doing cleanup.
Fix the following crashes:
Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
0x0000555555ec83ef in bdrv_release_dirty_bitmap (bitmap=0x0) at
../block/dirty-bitmap.c:359
359 BlockDriverState *bs = bitmap->bs;
#0 0x0000555555ec83ef in bdrv_release_dirty_bitmap (bitmap=0x0) at
../block/dirty-bitmap.c:359
#1 0x0000555555bba331 in unset_dirty_tracking () at ../migration/block.c:371
#2 0x0000555555bbad98 in block_migration_cleanup_bmds () at
../migration/block.c:681
Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
0x0000555555e971ff in bdrv_op_unblock (bs=0x0, op=BLOCK_OP_TYPE_BACKUP_SOURCE,
reason=0x0) at ../block.c:7073
7073 QLIST_FOREACH_SAFE(blocker, &bs->op_blockers[op], list, next) {
#0 0x0000555555e971ff in bdrv_op_unblock (bs=0x0,
op=BLOCK_OP_TYPE_BACKUP_SOURCE, reason=0x0) at ../block.c:7073
#1 0x0000555555e9734a in bdrv_op_unblock_all (bs=0x0, reason=0x0) at
../block.c:7095
#2 0x0000555555bbae13 in block_migration_cleanup_bmds () at
../migration/block.c:690
Signed-off-by: Fabiano Rosas <farosas@suse.de>
Message-id: 20230731203338.27581-1-farosas@suse.de
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit f187609f27b261702a17f79d20bf252ee0d4f9cd)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 645b87f6505b07c5b2082fe12354114bddff6bd4
https://github.com/qemu/qemu/commit/645b87f6505b07c5b2082fe12354114bddff6bd4
Author: Alex Bennée <alex.bennee@linaro.org>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M docs/system/arm/emulation.rst
M target/arm/tcg/cpu64.c
Log Message:
-----------
target/arm: properly document FEAT_CRC32
This is a mandatory feature for Armv8.1 architectures but we don't
state the feature clearly in our emulation list. Also include
FEAT_CRC32 comment in aarch64_max_tcg_initfn for ease of grepping.
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20230824075406.1515566-1-alex.bennee@linaro.org
Cc: qemu-stable@nongnu.org
Message-Id: <20230222110104.3996971-1-alex.bennee@linaro.org>
[PMM: pluralize 'instructions' in docs]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 9e771a2fc68d98c5719b877e008d1dca64e6896e)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: e5e77f256fba11d61ffa237eed0b53a78882b3bb
https://github.com/qemu/qemu/commit/e5e77f256fba11d61ffa237eed0b53a78882b3bb
Author: Richard Henderson <richard.henderson@linaro.org>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M linux-user/elfload.c
Log Message:
-----------
linux-user: Adjust brk for load_bias
PIE executables are usually linked at offset 0 and are
relocated somewhere during load. The hiaddr needs to
be adjusted to keep the brk next to the executable.
Cc: qemu-stable@nongnu.org
Fixes: 1f356e8c013 ("linux-user: Adjust initial brk when interpreter is close
to executable")
Tested-by: Helge Deller <deller@gmx.de>
Reviewed-by: Ilya Leoshkevich <iii@linux.ibm.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
(cherry picked from commit aec338d63bc28f1f13d5e64c561d7f1dd0e4b07e)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: e975434d62c325bdd3bacb030c5a610d095b8909
https://github.com/qemu/qemu/commit/e975434d62c325bdd3bacb030c5a610d095b8909
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M target/i386/tcg/sysemu/fpu_helper.c
M target/i386/tcg/translate.c
Log Message:
-----------
target/i386: raise FERR interrupt with iothread locked
Otherwise tcg_handle_interrupt() triggers an assertion failure:
#5 0x0000555555c97369 in tcg_handle_interrupt (cpu=0x555557434cb0, mask=2)
at ../accel/tcg/tcg-accel-ops.c:83
#6 tcg_handle_interrupt (cpu=0x555557434cb0, mask=2) at
../accel/tcg/tcg-accel-ops.c:81
#7 0x0000555555b4d58b in pic_irq_request (opaque=<optimized out>,
irq=<optimized out>, level=1) at ../hw/i386/x86.c:555
#8 0x0000555555b4f218 in gsi_handler (opaque=0x5555579423d0, n=13, level=1)
at ../hw/i386/x86.c:611
#9 0x00007fffa42bde14 in code_gen_buffer ()
#10 0x0000555555c724bb in cpu_tb_exec (cpu=cpu@entry=0x555557434cb0,
itb=<optimized out>, tb_exit=tb_exit@entry=0x7fffe9bfd658) at
../accel/tcg/cpu-exec.c:457
Cc: qemu-stable@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1808
Reported-by: NyanCatTW1 <https://gitlab.com/a0939712328>
Co-developed-by: Richard Henderson <richard.henderson@linaro.org>'
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit c1f27a0c6ae4059a1d809e9c2bc4d47b823c32a3)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 0175121c6c54ee2cd568594d54001275712f309f
https://github.com/qemu/qemu/commit/0175121c6c54ee2cd568594d54001275712f309f
Author: Bilal Elmoussaoui <belmouss@redhat.com>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M ui/dbus-console.c
Log Message:
-----------
ui/dbus: Properly dispose touch/mouse dbus objects
Fixes: 142ca628a7 ("ui: add a D-Bus display backend")
Fixes: de9f844ce2 ("ui/dbus: Expose a touch device interface")
Signed-off-by: Bilal Elmoussaoui <belmouss@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20230901124507.94087-1-belmouss@redhat.com>
(cherry picked from commit cb6ccdc9ca705cd8c3ef50e51c16a3732c2fa734)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 6864f05cb167e384075488a3d96717b131536d25
https://github.com/qemu/qemu/commit/6864f05cb167e384075488a3d96717b131536d25
Author: Nicholas Piggin <npiggin@gmail.com>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M hw/ppc/vof.c
Log Message:
-----------
ppc/vof: Fix missed fields in VOF cleanup
Failing to reset the of_instance_last makes ihandle allocation continue
to increase, which causes record-replay replay fail to match the
recorded trace.
Not resetting claimed_base makes VOF eventually run out of memory after
some resets.
Cc: Alexey Kardashevskiy <aik@ozlabs.ru>
Fixes: fc8c745d501 ("spapr: Implement Open Firmware client interface")
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
(cherry picked from commit 7b8589d7ce7e23f26ff53338d575a5cbd7818e28)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 5358980d3363079d423f7874d49e01e2024fb524
https://github.com/qemu/qemu/commit/5358980d3363079d423f7874d49e01e2024fb524
Author: Maksim Kostin <maksim.kostin@ispras.ru>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M hw/ppc/e500.c
Log Message:
-----------
hw/ppc/e500: fix broken snapshot replay
ppce500_reset_device_tree is registered for system reset, but after
c4b075318eb1 this function rerandomizes rng-seed via
qemu_guest_getrandom_nofail. And when loading a snapshot, it tries to read
EVENT_RANDOM that doesn't exist, so we have an error:
qemu-system-ppc: Missing random event in the replay log
To fix this, use qemu_register_reset_nosnapshotload instead of
qemu_register_reset.
Reported-by: Vitaly Cheptsov <cheptsov@ispras.ru>
Fixes: c4b075318eb1 ("hw/ppc: pass random seed to fdt ")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1634
Signed-off-by: Maksim Kostin <maksim.kostin@ispras.ru>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
(cherry picked from commit 6ec65b69ba17c954414fa23a397fb8a3fcfb4a43)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 9f54fef2c00f3c710ef277c2dd3813385315afd0
https://github.com/qemu/qemu/commit/9f54fef2c00f3c710ef277c2dd3813385315afd0
Author: Richard Henderson <richard.henderson@linaro.org>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M target/ppc/cpu.c
Log Message:
-----------
target/ppc: Flush inputs to zero with NJ in ppc_store_vscr
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1779
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
(cherry picked from commit af03aeb631eeb81a44d2c0ff5b429cd4b5dc2799)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: f64f1f8704d6db00623b67dd20958e54e18f5336
https://github.com/qemu/qemu/commit/f64f1f8704d6db00623b67dd20958e54e18f5336
Author: Nicholas Piggin <npiggin@gmail.com>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M target/ppc/translate/fixedpoint-impl.c.inc
Log Message:
-----------
target/ppc: Fix LQ, STQ register-pair order for big-endian
LQ, STQ have the same register-pair ordering as LQARX/STQARX., which is
the even (lower) register contains the most significant bits. This is
not implemented correctly for big-endian.
do_ldst_quad() has variables low_addr_gpr and high_addr_gpr which is
confusing because they are low and high addresses, whereas LQARX/STQARX.
and most such things use the low and high values for lo/hi variables.
The conversion to native 128-bit memory access functions missed this
strangeness.
Fix this by changing the if condition, and change the variable names to
hi/lo to match convention.
Cc: qemu-stable@nongnu.org
Reported-by: Ivan Warren <ivan@vmfacility.fr>
Fixes: 57b38ffd0c6f ("target/ppc: Use tcg_gen_qemu_{ld,st}_i128 for LQARX, LQ,
STQ")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1836
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
(cherry picked from commit 718209358f2e4f231cbacf974c3299c4fe7beb83)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: c2e0495e3c49dbd7916e8287699453732722a22b
https://github.com/qemu/qemu/commit/c2e0495e3c49dbd7916e8287699453732722a22b
Author: Niklas Cassel <niklas.cassel@wdc.com>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M hw/ide/core.c
Log Message:
-----------
hw/ide/core: set ERR_STAT in unsupported command completion
Currently, the first time sending an unsupported command
(e.g. READ LOG DMA EXT) will not have ERR_STAT set in the completion.
Sending the unsupported command again, will correctly have ERR_STAT set.
When ide_cmd_permitted() returns false, it calls ide_abort_command().
ide_abort_command() first calls ide_transfer_stop(), which will call
ide_transfer_halt() and ide_cmd_done(), after that ide_abort_command()
sets ERR_STAT in status.
ide_cmd_done() for AHCI will call ahci_write_fis_d2h() which writes the
current status in the FIS, and raises an IRQ. (The status here will not
have ERR_STAT set!).
Thus, we cannot call ide_transfer_stop() before setting ERR_STAT, as
ide_transfer_stop() will result in the FIS being written and an IRQ
being raised.
The reason why it works the second time, is that ERR_STAT will still
be set from the previous command, so when writing the FIS, the
completion will correctly have ERR_STAT set.
Set ERR_STAT before writing the FIS (calling cmd_done), so that we will
raise an error IRQ correctly when receiving an unsupported command.
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20230609140844.202795-3-nks@flawful.org
Signed-off-by: John Snow <jsnow@redhat.com>
(cherry picked from commit c3461c6264a7c8ca15b117e91fe5da786924a784)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 1efefd13ca9365213b5136a1093b479fdf4a0b9e
https://github.com/qemu/qemu/commit/1efefd13ca9365213b5136a1093b479fdf4a0b9e
Author: Niklas Cassel <niklas.cassel@wdc.com>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M hw/ide/ahci.c
Log Message:
-----------
hw/ide/ahci: write D2H FIS when processing NCQ command
The way that BUSY + PxCI is cleared for NCQ (FPDMA QUEUED) commands is
described in SATA 3.5a Gold:
11.15 FPDMA QUEUED command protocol
DFPDMAQ2: ClearInterfaceBsy
"Transmit Register Device to Host FIS with the BSY bit cleared to zero
and the DRQ bit cleared to zero and Interrupt bit cleared to zero to
mark interface ready for the next command."
PxCI is currently cleared by handle_cmd(), but we don't write the D2H
FIS to the FIS Receive Area that actually caused PxCI to be cleared.
Similar to how ahci_pio_transfer() calls ahci_write_fis_pio() with an
additional parameter to write a PIO Setup FIS without raising an IRQ,
add a parameter to ahci_write_fis_d2h() so that ahci_write_fis_d2h()
also can write the FIS to the FIS Receive Area without raising an IRQ.
Change process_ncq_command() to call ahci_write_fis_d2h() without
raising an IRQ (similar to ahci_pio_transfer()), such that the FIS
Receive Area is in sync with the PxTFD shadow register.
E.g. Linux reads status and error fields from the FIS Receive Area
directly, so it is wise to keep the FIS Receive Area and the PxTFD
shadow register in sync.
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Message-id: 20230609140844.202795-4-nks@flawful.org
Signed-off-by: John Snow <jsnow@redhat.com>
(cherry picked from commit 2967dc8209dd27b61a6ab7bad78cf7c6ec58ddb4)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 16cc9594d23d73d4f93614d8e7db931fe3b12f34
https://github.com/qemu/qemu/commit/16cc9594d23d73d4f93614d8e7db931fe3b12f34
Author: Niklas Cassel <niklas.cassel@wdc.com>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M hw/ide/ahci.c
Log Message:
-----------
hw/ide/ahci: simplify and document PxCI handling
The AHCI spec states that:
For NCQ, PxCI is cleared on command queued successfully.
For non-NCQ, PxCI is cleared on command completed successfully.
(A non-NCQ command that completes with error does not clear PxCI.)
The current QEMU implementation either clears PxCI in check_cmd(),
or in ahci_cmd_done().
check_cmd() will clear PxCI for a command if handle_cmd() returns 0.
handle_cmd() will return -1 if BUSY or DRQ is set.
The QEMU implementation for NCQ commands will currently not set BUSY
or DRQ, so they will always have PxCI cleared by handle_cmd().
ahci_cmd_done() will never even get called for NCQ commands.
Non-NCQ commands are executed by ide_bus_exec_cmd().
Non-NCQ commands in QEMU are implemented either in a sync or in an async
way.
For non-NCQ commands implemented in a sync way, the command handler will
return true, and when ide_bus_exec_cmd() sees that a command handler
returns true, it will call ide_cmd_done() (which will call
ahci_cmd_done()). For a command implemented in a sync way,
ahci_cmd_done() will do nothing (since busy_slot is not set). Instead,
after ide_bus_exec_cmd() has finished, check_cmd() will clear PxCI for
these commands.
For non-NCQ commands implemented in an async way (using either aiocb or
pio_aiocb), the command handler will return false, ide_bus_exec_cmd()
will not call ide_cmd_done(), instead it is expected that the async
callback function will call ide_cmd_done() once the async command is
done. handle_cmd() will set busy_slot, if and only if BUSY or DRQ is
set, and this is checked _after_ ide_bus_exec_cmd() has returned.
handle_cmd() will return -1, so check_cmd() will not clear PxCI.
When the async callback calls ide_cmd_done() (which will call
ahci_cmd_done()), it will see that busy_slot is set, and
ahci_cmd_done() will clear PxCI.
This seems racy, since busy_slot is set _after_ ide_bus_exec_cmd() has
returned. The callback might come before busy_slot gets set. And it is
quite confusing that ahci_cmd_done() will be called for all non-NCQ
commands when the command is done, but will only clear PxCI in certain
cases, even though it will always write a D2H FIS and raise an IRQ.
Even worse, in the case where ahci_cmd_done() does not clear PxCI, it
still raises an IRQ. Host software might thus read an old PxCI value,
since PxCI is cleared (by check_cmd()) after the IRQ has been raised.
Try to simplify this by always setting busy_slot for non-NCQ commands,
such that ahci_cmd_done() will always be responsible for clearing PxCI
for non-NCQ commands.
For NCQ commands, clear PxCI when we receive the D2H FIS, but before
raising the IRQ, see AHCI 1.3.1, section 5.3.8, states RegFIS:Entry and
RegFIS:ClearCI.
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Message-id: 20230609140844.202795-5-nks@flawful.org
Signed-off-by: John Snow <jsnow@redhat.com>
(cherry picked from commit e2a5d9b3d9c3d311618160603cc9bc04fbd98796)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 4fbd5a5202c01c8897fc45cbef255a8a0fa4f74e
https://github.com/qemu/qemu/commit/4fbd5a5202c01c8897fc45cbef255a8a0fa4f74e
Author: Niklas Cassel <niklas.cassel@wdc.com>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M hw/ide/ahci.c
Log Message:
-----------
hw/ide/ahci: PxSACT and PxCI is cleared when PxCMD.ST is cleared
According to AHCI 1.3.1 definition of PxSACT:
This field is cleared when PxCMD.ST is written from a '1' to a '0' by
software. This field is not cleared by a COMRESET or a software reset.
According to AHCI 1.3.1 definition of PxCI:
This field is also cleared when PxCMD.ST is written from a '1' to a '0'
by software.
Clearing PxCMD.ST is part of the error recovery procedure, see
AHCI 1.3.1, section "6.2 Error Recovery".
If we don't clear PxCI on error recovery, the previous command will
incorrectly still be marked as pending after error recovery.
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20230609140844.202795-6-nks@flawful.org
Signed-off-by: John Snow <jsnow@redhat.com>
(cherry picked from commit d73b84d0b664e60fffb66f46e84d0db4a8e1c713)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 4448c345bc355feb044ebf7a851275f5b579a419
https://github.com/qemu/qemu/commit/4448c345bc355feb044ebf7a851275f5b579a419
Author: Niklas Cassel <niklas.cassel@wdc.com>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M hw/ide/ahci.c
M tests/qtest/libqos/ahci.c
M tests/qtest/libqos/ahci.h
Log Message:
-----------
hw/ide/ahci: PxCI should not get cleared when ERR_STAT is set
For NCQ, PxCI is cleared on command queued successfully.
For non-NCQ, PxCI is cleared on command completed successfully.
Successfully means ERR_STAT, BUSY and DRQ are all cleared.
A command that has ERR_STAT set, does not get to clear PxCI.
See AHCI 1.3.1, section 5.3.8, states RegFIS:Entry and RegFIS:ClearCI,
and 5.3.16.5 ERR:FatalTaskfile.
In the case of non-NCQ commands, not clearing PxCI is needed in order
for host software to be able to see which command slot that failed.
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Message-id: 20230609140844.202795-7-nks@flawful.org
Signed-off-by: John Snow <jsnow@redhat.com>
(cherry picked from commit 1a16ce64fda11bdf50f0c4ab5d9fdde72c1383a2)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: e8f5ca57e450fb225ad52205536280b6fd9c37d4
https://github.com/qemu/qemu/commit/e8f5ca57e450fb225ad52205536280b6fd9c37d4
Author: Niklas Cassel <niklas.cassel@wdc.com>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M hw/ide/ahci.c
Log Message:
-----------
hw/ide/ahci: fix ahci_write_fis_sdb()
When there is an error, we need to raise a TFES error irq, see AHCI 1.3.1,
5.3.13.1 SDB:Entry.
If ERR_STAT is set, we jump to state ERR:FatalTaskfile, which will raise
a TFES IRQ unconditionally, regardless if the I bit is set in the FIS or
not.
Thus, we should never raise a normal IRQ after having sent an error IRQ.
It is valid to signal successfully completed commands as finished in the
same SDB FIS that generates the error IRQ. The important thing is that
commands that did not complete successfully (e.g. commands that were
aborted, do not get the finished bit set).
Before this commit, there was never a TFES IRQ raised on NCQ error.
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20230609140844.202795-8-nks@flawful.org
Signed-off-by: John Snow <jsnow@redhat.com>
(cherry picked from commit 7e85cb0db4c693b4e084a00e66fe73a22ed1688a)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: d5361580ac60d5d08f30e6ca8a6c68d32eee233f
https://github.com/qemu/qemu/commit/d5361580ac60d5d08f30e6ca8a6c68d32eee233f
Author: Niklas Cassel <niklas.cassel@wdc.com>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M hw/ide/ahci.c
Log Message:
-----------
hw/ide/ahci: fix broken SError handling
When encountering an NCQ error, you should not write the NCQ tag to the
SError register. This is completely wrong.
The SError register has a clear definition, where each bit represents a
different error, see PxSERR definition in AHCI 1.3.1.
If we write a random value (like the NCQ tag) in SError, e.g. Linux will
read SError, and will trigger arbitrary error handling depending on the
NCQ tag that happened to be executing.
In case of success, ncq_cb() will call ncq_finish().
In case of error, ncq_cb() will call ncq_err() (which will clear
ncq_tfs->used), and then call ncq_finish(), thus using ncq_tfs->used is
sufficient to tell if finished should get set or not.
Signed-off-by: Niklas Cassel <niklas.cassel@wdc.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-id: 20230609140844.202795-9-nks@flawful.org
Signed-off-by: John Snow <jsnow@redhat.com>
(cherry picked from commit 9f89423537653de07ca40c18b5ff5b70b104cc93)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 9dc6f05cc82601bc743bbce2404cfcafc1b9484b
https://github.com/qemu/qemu/commit/9dc6f05cc82601bc743bbce2404cfcafc1b9484b
Author: Hang Yu <francis_yuu@stu.pku.edu.cn>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M hw/i2c/aspeed_i2c.c
M include/hw/i2c/aspeed_i2c.h
Log Message:
-----------
hw/i2c/aspeed: Fix Tx count and Rx size error in buffer pool mode
Fixed inconsistency between the regisiter bit field definition header file
and the ast2600 datasheet. The reg name is I2CD1C:Pool Buffer Control
Register in old register mode and I2CC0C: Master/Slave Pool Buffer Control
Register in new register mode. They share bit field
[12:8]:Transmit Data Byte Count and bit field
[29:24]:Actual Received Pool Buffer Size according to the datasheet.
According to the ast2600 datasheet,the actual Tx count is
Transmit Data Byte Count plus 1, and the max Rx size is
Receive Pool Buffer Size plus 1, both in Pool Buffer Control Register.
The version before forgot to plus 1, and mistake Rx count for Rx size.
Signed-off-by: Hang Yu <francis_yuu@stu.pku.edu.cn>
Fixes: 3be3d6ccf2ad ("aspeed: i2c: Migrate to registerfields API")
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
(cherry picked from commit 97b8aa5ae9ff197394395eda5062ea3681e09c28)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 25ec23ab3fbf953fbbb38062042c8da3b00887ee
https://github.com/qemu/qemu/commit/25ec23ab3fbf953fbbb38062042c8da3b00887ee
Author: Hang Yu <francis_yuu@stu.pku.edu.cn>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M hw/i2c/aspeed_i2c.c
Log Message:
-----------
hw/i2c/aspeed: Fix TXBUF transmission start position error
According to the ast2600 datasheet and the linux aspeed i2c driver,
the TXBUF transmission start position should be TXBUF[0] instead
of TXBUF[1],so the arg pool_start is useless,and the address is not
included in TXBUF.So even if Tx Count equals zero,there is at least
1 byte data needs to be transmitted,and M_TX_CMD should not be cleared
at this condition.The driver url is:
https://github.com/AspeedTech-BMC/linux/blob/aspeed-master-v5.15/drivers/i2c/busses/i2c-ast2600.c
Signed-off-by: Hang Yu <francis_yuu@stu.pku.edu.cn>
Fixes: 6054fc73e8f4 ("aspeed/i2c: Add support for pool buffer transfers")
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
(cherry picked from commit 961faf3ddbd8ffcdf776bbcf88af0bc97218114a)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 01bf87c8e33e52f2aad6676c9c434480d7992ab5
https://github.com/qemu/qemu/commit/01bf87c8e33e52f2aad6676c9c434480d7992ab5
Author: Thomas Huth <thuth@redhat.com>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M qemu-options.hx
Log Message:
-----------
qemu-options.hx: Rephrase the descriptions of the -hd* and -cdrom options
The current description says that these options will create a device
on the IDE bus, which is only true on x86. So rephrase these sentences
a little bit to speak of "default bus" instead.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit bcd8e243083c878884e52d609deddbe6be17c730)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 6356785daa8cfab5437b2cc74811807730173b34
https://github.com/qemu/qemu/commit/6356785daa8cfab5437b2cc74811807730173b34
Author: Markus Armbruster <armbru@redhat.com>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M docs/multi-thread-compression.txt
M docs/rdma.txt
M tests/qemu-iotests/181
M tests/qtest/test-hmp.c
Log Message:
-----------
docs tests: Fix use of migrate_set_parameter
docs/multi-thread-compression.txt uses parameter names with
underscores instead of dashes. Wrong since day one.
docs/rdma.txt, tests/qemu-iotests/181, and tests/qtest/test-hmp.c are
wrong the same way since commit cbde7be900d2 (v6.0.0). Hard to see,
as test-hmp doesn't check whether the commands work, and iotest 181
appears to be unaffected.
Fixes: 263170e679df (docs: Add a doc about multiple thread compression)
Fixes: cbde7be900d2 (migrate: remove QMP/HMP commands for speed, downtime and
cache size)
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(cherry picked from commit b21a6e31a182a5ae7436a444f840d49aac07c94f)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 93d4107937dfc846976d64f661ee7cb4f7975f73
https://github.com/qemu/qemu/commit/93d4107937dfc846976d64f661ee7cb4f7975f73
Author: Thomas Huth <thuth@redhat.com>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M hw/net/vmxnet3.c
Log Message:
-----------
hw/net/vmxnet3: Fix guest-triggerable assert()
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>
Commit: eeee989f729b25eccd14563f1d1cea6f0f6f87a4
https://github.com/qemu/qemu/commit/eeee989f729b25eccd14563f1d1cea6f0f6f87a4
Author: Marc-André Lureau <marcandre.lureau@redhat.com>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M hw/display/qxl.c
Log Message:
-----------
qxl: don't assert() if device isn't yet initialized
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>
Commit: df33ce9b6db65fc85a6fd5b7f0d9e772eac37185
https://github.com/qemu/qemu/commit/df33ce9b6db65fc85a6fd5b7f0d9e772eac37185
Author: Kevin Wolf <kwolf@redhat.com>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M hw/virtio/virtio.c
Log Message:
-----------
virtio: Drop out of coroutine context in virtio_load()
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>
Commit: 9832a670b334cffa8b7fc0429c1ca681fe41dd17
https://github.com/qemu/qemu/commit/9832a670b334cffa8b7fc0429c1ca681fe41dd17
Author: Colton Lewis <coltonlewis@google.com>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M target/arm/kvm64.c
Log Message:
-----------
arm64: Restore trapless ptimer access
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>
Commit: 3d6251f416cc12daa01eeacf869b4998464231d6
https://github.com/qemu/qemu/commit/3d6251f416cc12daa01eeacf869b4998464231d6
Author: Thomas Huth <thuth@redhat.com>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M hw/char/riscv_htif.c
Log Message:
-----------
hw/char/riscv_htif: Fix printing of console characters on big endian hosts
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>
Commit: b9f83298b991db28124c7e360952cc2ef24f63d6
https://github.com/qemu/qemu/commit/b9f83298b991db28124c7e360952cc2ef24f63d6
Author: Thomas Huth <thuth@redhat.com>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M hw/char/riscv_htif.c
Log Message:
-----------
hw/char/riscv_htif: Fix the console syscall on big endian hosts
Values that have been read via cpu_physical_memory_read() from the
guest's memory have to be swapped in case the host endianess differs
from the guest.
Fixes: a6e13e31d5 ("riscv_htif: Support console output via proxy syscall")
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>
Message-Id: <20230721094720.902454-3-thuth@redhat.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 058096f1c55ab688db7e1d6814aaefc1bcd87f7a)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 987e90cfd23e44eb601e9557f61f1f6fdcef5e4c
https://github.com/qemu/qemu/commit/987e90cfd23e44eb601e9557f61f1f6fdcef5e4c
Author: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M target/riscv/cpu.c
Log Message:
-----------
target/riscv/cpu.c: add zmmul isa string
zmmul was promoted from experimental to ratified in commit 6d00ffad4e95.
Add a riscv,isa string for it.
Fixes: 6d00ffad4e95 ("target/riscv: move zmmul out of the experimental
properties")
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-Id: <20230720132424.371132-2-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 50f9464962fb41f04fd5f42e7ee2cb60942aba89)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 6c24b6000b5cdf259f1fcdfa19cee397770f0946
https://github.com/qemu/qemu/commit/6c24b6000b5cdf259f1fcdfa19cee397770f0946
Author: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M target/riscv/vector_helper.c
Log Message:
-----------
target/riscv: Fix page_check_range use in fault-only-first
Commit bef6f008b98(accel/tcg: Return bool from page_check_range) converts
integer return value to bool type. However, it wrongly converted the use
of the API in riscv fault-only-first, where page_check_range < = 0, should
be converted to !page_check_range.
Signed-off-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20230729031618.821-1-zhiwei_liu@linux.alibaba.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 4cc9f284d5971ecd8055d26ef74c23ef0be8b8f5)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 8ae20123b6bd525ef46af0260bfa0e36ecfc8449
https://github.com/qemu/qemu/commit/8ae20123b6bd525ef46af0260bfa0e36ecfc8449
Author: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M target/riscv/insn_trans/trans_rvzfa.c.inc
Log Message:
-----------
target/riscv: Fix zfa fleq.d and fltq.d
Commit a47842d ("riscv: Add support for the Zfa extension") implemented the zfa
extension.
However, it has some typos for fleq.d and fltq.d. Both of them misused the
fltq.s
helper function.
Fixes: a47842d ("riscv: Add support for the Zfa extension")
Signed-off-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Weiwei Li <liweiwei@iscas.ac.cn>
Message-ID: <20230728003906.768-1-zhiwei_liu@linux.alibaba.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit eda633a534f8af4abe3a88731bba6dacdb973993)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 566dac7127bfab136236a0f7cbe393a4f9469155
https://github.com/qemu/qemu/commit/566dac7127bfab136236a0f7cbe393a4f9469155
Author: Jason Chien <jason.chien@sifive.com>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M hw/intc/riscv_aclint.c
Log Message:
-----------
hw/intc: Fix upper/lower mtime write calculation
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>
Commit: 60a7f5c8fe9b76e9563d2830936bebfba37c77c5
https://github.com/qemu/qemu/commit/60a7f5c8fe9b76e9563d2830936bebfba37c77c5
Author: Jason Chien <jason.chien@sifive.com>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M hw/intc/riscv_aclint.c
Log Message:
-----------
hw/intc: Make rtc variable names consistent
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>
Commit: 2947da750ec422421e45c442a4013fa7449f3732
https://github.com/qemu/qemu/commit/2947da750ec422421e45c442a4013fa7449f3732
Author: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M linux-user/riscv/signal.c
Log Message:
-----------
linux-user/riscv: Use abi type for target_ucontext
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>
Commit: b822207513ddd9c04247b1cf3be63b5c857421d7
https://github.com/qemu/qemu/commit/b822207513ddd9c04247b1cf3be63b5c857421d7
Author: Conor Dooley <conor.dooley@microchip.com>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M hw/riscv/virt.c
Log Message:
-----------
hw/riscv: virt: Fix riscv,pmu DT node path
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>
Commit: 1d4fb5815c87e6ec48abcc3066378ba383788f4a
https://github.com/qemu/qemu/commit/1d4fb5815c87e6ec48abcc3066378ba383788f4a
Author: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M target/riscv/cpu.c
Log Message:
-----------
target/riscv: fix satp_mode_finalize() when satp_mode.supported = 0
In the same emulated RISC-V host, the 'host' KVM CPU takes 4 times
longer to boot than the 'rv64' KVM CPU.
The reason is an unintended behavior of riscv_cpu_satp_mode_finalize()
when satp_mode.supported = 0, i.e. when cpu_init() does not set
satp_mode_max_supported(). satp_mode_max_from_map(map) does:
31 - __builtin_clz(map)
This means that, if satp_mode.supported = 0, satp_mode_supported_max
wil be '31 - 32'. But this is C, so satp_mode_supported_max will gladly
set it to UINT_MAX (4294967295). After that, if the user didn't set a
satp_mode, set_satp_mode_default_map(cpu) will make
cfg.satp_mode.map = cfg.satp_mode.supported
So satp_mode.map = 0. And then satp_mode_map_max will be set to
satp_mode_max_from_map(cpu->cfg.satp_mode.map), i.e. also UINT_MAX. The
guard "satp_mode_map_max > satp_mode_supported_max" doesn't protect us
here since both are UINT_MAX.
And finally we have 2 loops:
for (int i = satp_mode_map_max - 1; i >= 0; --i) {
Which are, in fact, 2 loops from UINT_MAX -1 to -1. This is where the
extra delay when booting the 'host' CPU is coming from.
Commit 43d1de32f8 already set a precedence for satp_mode.supported = 0
in a different manner. We're doing the same here. If supported == 0,
interpret as 'the CPU wants the OS to handle satp mode alone' and skip
satp_mode_finalize().
We'll also put a guard in satp_mode_max_from_map() to assert out if map
is 0 since the function is not ready to deal with it.
Cc: Alexandre Ghiti <alexghiti@rivosinc.com>
Fixes: 6f23aaeb9b ("riscv: Allow user to set the satp mode")
Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Message-ID: <20230817152903.694926-1-dbarboza@ventanamicro.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit 3a2fc23563885c219c73c8f24318921daf02f3f2)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 7385e00665b66ab9d7180421b1a69c4e4899c6de
https://github.com/qemu/qemu/commit/7385e00665b66ab9d7180421b1a69c4e4899c6de
Author: Leon Schuermann <leons@opentitan.org>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M target/riscv/pmp.c
Log Message:
-----------
target/riscv/pmp.c: respect mseccfg.RLB for pmpaddrX changes
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>
Commit: cae7dc14521f6646bf7f9a6a505b2baf354b3320
https://github.com/qemu/qemu/commit/cae7dc14521f6646bf7f9a6a505b2baf354b3320
Author: Akihiko Odaki <akihiko.odaki@daynix.com>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M target/riscv/cpu.c
M target/riscv/debug.c
M target/riscv/debug.h
Log Message:
-----------
target/riscv: Allocate itrigger timers only once
riscv_trigger_init() had been called on reset events that can happen
several times for a CPU and it allocated timers for itrigger. If old
timers were present, they were simply overwritten by the new timers,
resulting in a memory leak.
Divide riscv_trigger_init() into two functions, namely
riscv_trigger_realize() and riscv_trigger_reset() and call them in
appropriate timing. The timer allocation will happen only once for a
CPU in riscv_trigger_realize().
Fixes: 5a4ae64cac ("target/riscv: Add itrigger support when icount is enabled")
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: LIU Zhiwei <zhiwei_liu@linux.alibaba.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Message-ID: <20230818034059.9146-1-akihiko.odaki@daynix.com>
Signed-off-by: Alistair Francis <alistair.francis@wdc.com>
(cherry picked from commit a7c272df82af11c568ea83921b04334791dccd5e)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: d4919bbcc258d5194a6725fb7af57f09bd71b2ea
https://github.com/qemu/qemu/commit/d4919bbcc258d5194a6725fb7af57f09bd71b2ea
Author: Marc-André Lureau <marcandre.lureau@redhat.com>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M hw/display/virtio-gpu.c
Log Message:
-----------
virtio-gpu/win32: set the destroy function on load
Don't forget to unmap the resource memory.
Fixes: commit 9462ff469 ("virtio-gpu/win32: allocate shareable 2d
resources/images")
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
(cherry picked from commit 04562ee88e99d71f4e6017f64123f726dd8b41e1)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Commit: 8b479229ffc3a5870a0dc4dbe82707c033986f05
https://github.com/qemu/qemu/commit/8b479229ffc3a5870a0dc4dbe82707c033986f05
Author: Marc-André Lureau <marcandre.lureau@redhat.com>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M ui/console.c
Log Message:
-----------
ui: fix crash when there are no active_console
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>
Commit: 60da8301fe87fa481fe77296f8c90a6a205f7a85
https://github.com/qemu/qemu/commit/60da8301fe87fa481fe77296f8c90a6a205f7a85
Author: Janosch Frank <frankja@linux.ibm.com>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M hw/s390x/s390-virtio-ccw.c
Log Message:
-----------
s390x/ap: fix missing subsystem reset registration
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>
Commit: 56270e5d3d956d58de86d4caf7a330b9cd438163
https://github.com/qemu/qemu/commit/56270e5d3d956d58de86d4caf7a330b9cd438163
Author: Jonathan Perkin <jonathan@perkin.org.uk>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M meson.build
Log Message:
-----------
meson: Fix targetos match for illumos and Solaris.
qemu 8.1.0 breaks on illumos platforms due to _XOPEN_SOURCE and others no
longer being set correctly, leading to breakage such as:
https://us-central.manta.mnx.io/pkgsrc/public/reports/trunk/tools/20230908.1404/qemu-8.1.0/build.log
This is a result of meson conversion which incorrectly matches against
'solaris' instead of 'sunos' for uname.
First time submitting a patch here, hope I did it correctly. Thanks.
Signed-off-by: Jonathan Perkin <jonathan@perkin.org.uk>
Message-ID: <ZPtdxtum9UVPy58J@perkin.org.uk>
Cc: qemu-stable@nongnu.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit fb0a8b0e238277296907ffe765bf76874cfc1df6)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: omit net/meson.build change before v8.1.0-279-g73258b3864, adjust context
befor v8.1.0-288-g2fc36530de)
Commit: 045fa847848e84701fab668d49b0c9cdf107b65c
https://github.com/qemu/qemu/commit/045fa847848e84701fab668d49b0c9cdf107b65c
Author: Marc-André Lureau <marcandre.lureau@redhat.com>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M backends/tpm/tpm_util.c
Log Message:
-----------
tpm: fix crash when FD >= 1024 and unnecessary errors due to EINTR
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>
Commit: 6bb4a8a47a43f35a345f107227fcd6abed59e62c
https://github.com/qemu/qemu/commit/6bb4a8a47a43f35a345f107227fcd6abed59e62c
Author: Michael Tokarev <mjt@tls.msk.ru>
Date: 2023-09-21 (Thu, 21 Sep 2023)
Changed paths:
M VERSION
Log Message:
-----------
Update version for 8.1.1 release
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
Compare: https://github.com/qemu/qemu/compare/f2fc49c30203...6bb4a8a47a43
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-commits] [qemu/qemu] 86d7b0: block-migration: Ensure we don't crash during migr...,
Alex Bennée <=