Branch: refs/heads/staging-9.1
Home: https://github.com/qemu/qemu
Commit: ae2dc2a27acf7115b886c9e1b7138ed4ef025160
https://github.com/qemu/qemu/commit/ae2dc2a27acf7115b886c9e1b7138ed4ef025160
Author: Tiago Pasqualini <tiago.pasqual...@canonical.com>
Date: 2024-09-25 (Wed, 25 Sep 2024)
Changed paths:
M crypto/pbkdf.c
Log Message:
-----------
crypto: run qcrypto_pbkdf2_count_iters in a new thread
CPU time accounting in the kernel has been demonstrated to have a
sawtooth pattern[1][2]. This can cause the getrusage system call to
not be as accurate as we are expecting, which can cause this calculation
to stall.
The kernel discussions shows that this inaccuracy happens when CPU time
gets big enough, so this patch changes qcrypto_pbkdf2_count_iters to run
in a fresh thread to avoid this inaccuracy. It also adds a sanity check
to fail the process if CPU time is not accounted.
[1]
https://lore.kernel.org/lkml/159231011694.16989.16351419333851309713.tip-bot2@tip-bot2/
[2]
https://lore.kernel.org/lkml/20221226031010.4079885-1-maxing....@bytedance.com/t/#m1c7f2fdc0ea742776a70fd1aa2a2e414c437f534
Resolves: #2398
Signed-off-by: Tiago Pasqualini <tiago.pasqual...@canonical.com>
Signed-off-by: Daniel P. Berrangé <berra...@redhat.com>
(cherry picked from commit c72cab5ad9f849bbcfcf4be7952b8b8946cc626e)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 0e8f3eb43ff4fa7d2ef7a79c943e412b812987f9
https://github.com/qemu/qemu/commit/0e8f3eb43ff4fa7d2ef7a79c943e412b812987f9
Author: Daniel P. Berrangé <berra...@redhat.com>
Date: 2024-09-25 (Wed, 25 Sep 2024)
Changed paths:
M crypto/pbkdf-gcrypt.c
M crypto/pbkdf-gnutls.c
Log Message:
-----------
crypto: check gnutls & gcrypt support the requested pbkdf hash
Both gnutls and gcrypt can be configured to exclude support for certain
algorithms via a runtime check against system crypto policies. Thus it
is not sufficient to have a compile time test for hash support in their
pbkdf implementations.
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Signed-off-by: Daniel P. Berrangé <berra...@redhat.com>
(cherry picked from commit e6c09ea4f9e5f8af92a6453642b84b9efd52892f)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 3148a16b306485c5b6fb30c06f369b4bba476030
https://github.com/qemu/qemu/commit/3148a16b306485c5b6fb30c06f369b4bba476030
Author: Daniel P. Berrangé <berra...@redhat.com>
Date: 2024-09-25 (Wed, 25 Sep 2024)
Changed paths:
M crypto/cipher-nettle.c.inc
Log Message:
-----------
crypto: avoid leak of ctx when bad cipher mode is given
Fixes: Coverity CID 1546884
Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Signed-off-by: Daniel P. Berrangé <berra...@redhat.com>
(cherry picked from commit 586ac2c67d707c2588766c5195d94fa553cc25af)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: a160fa0fc3bad5c7fca4b8a332a799b5b9222a8c
https://github.com/qemu/qemu/commit/a160fa0fc3bad5c7fca4b8a332a799b5b9222a8c
Author: Alex Bennée <alex.ben...@linaro.org>
Date: 2024-09-25 (Wed, 25 Sep 2024)
Changed paths:
M .gitlab-ci.d/container-cross.yml
M .gitlab-ci.d/crossbuilds.yml
R tests/docker/dockerfiles/debian-armel-cross.docker
M tests/lcitool/refresh
Log Message:
-----------
tests/docker: remove debian-armel-cross
As debian-11 transitions to LTS we are starting to have problems
building the image. While we could update to a later Debian building a
32 bit QEMU without modern floating point is niche host amongst the
few remaining 32 bit hosts we regularly build for. For now we still
have armhf-debian-cross-container which is currently built from the
more recent debian-12.
Reviewed-by: Pierrick Bouvier <pierrick.bouv...@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Reviewed-by: Richard Henderson <richard.hender...@linaro.org>
Signed-off-by: Alex Bennée <alex.ben...@linaro.org>
Message-Id: <20240910173900.4154726-2-alex.ben...@linaro.org>
(cherry picked from commit d0068b746a0a8cd4bb148527a0d199b130cd5288)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 27a15a2a32a1ce3aec30d6ed181d0de7a0e271c2
https://github.com/qemu/qemu/commit/27a15a2a32a1ce3aec30d6ed181d0de7a0e271c2
Author: Alex Bennée <alex.ben...@linaro.org>
Date: 2024-09-25 (Wed, 25 Sep 2024)
Changed paths:
M tests/docker/dockerfiles/debian-i686-cross.docker
M tests/docker/dockerfiles/debian-mipsel-cross.docker
M tests/lcitool/refresh
Log Message:
-----------
tests/docker: update debian i686 and mipsel images to bookworm
Whatever issues there were which stopped these being updates when the
rest were have now been resolved. However mips64el continues to be
broken so don't update it here.
Reviewed-by: Pierrick Bouvier <pierrick.bouv...@linaro.org>
Reviewed-by: Richard Henderson <richard.hender...@linaro.org>
Signed-off-by: Alex Bennée <alex.ben...@linaro.org>
Message-Id: <20240910173900.4154726-3-alex.ben...@linaro.org>
(cherry picked from commit 19d2111059c87d3f58349f27b9be9dee81fc1681)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: cd320c8a82773b8219e58d5e949db419f51b00f3
https://github.com/qemu/qemu/commit/cd320c8a82773b8219e58d5e949db419f51b00f3
Author: Thomas Huth <th...@redhat.com>
Date: 2024-09-25 (Wed, 25 Sep 2024)
Changed paths:
M .gitlab-ci.d/buildtest.yml
M contrib/plugins/Makefile
Log Message:
-----------
contrib/plugins/Makefile: Add a 'distclean' target
Running "make distclean" in the build tree currently fails since this
tries to run the "distclean" target in the contrib/plugins/ folder, too,
but the Makefile there is missing this target. Thus add 'distclean' there
to fix this issue.
And to avoid regressions with "make distclean", add this command to one
of the build jobs, too.
Message-ID: <20240902154749.73876-1-th...@redhat.com>
Reviewed-by: Pierrick Bouvier <pierrick.bouv...@linaro.org>
Signed-off-by: Thomas Huth <th...@redhat.com>
(cherry picked from commit 1231bc7d12c373e445171dda9e7e5146eee7da55)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: df9aa3dd8c05e1ee58cf38ecf3e2bd5994dbc9ea
https://github.com/qemu/qemu/commit/df9aa3dd8c05e1ee58cf38ecf3e2bd5994dbc9ea
Author: Volker Rümelin <vr_q...@t-online.de>
Date: 2024-09-25 (Wed, 25 Sep 2024)
Changed paths:
M hw/audio/trace-events
M hw/audio/virtio-snd.c
Log Message:
-----------
hw/audio/virtio-sound: fix heap buffer overflow
Currently, the guest may write to the device configuration space,
whereas the virtio sound device specification in chapter 5.14.4
clearly states that the fields in the device configuration space
are driver-read-only.
Remove the set_config function from the virtio_snd class.
This also prevents a heap buffer overflow. See QEMU issue #2296.
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2296
Signed-off-by: Volker Rümelin <vr_q...@t-online.de>
Message-Id: <20240901130112.8242-1-vr_q...@t-online.de>
Reviewed-by: Michael S. Tsirkin <m...@redhat.com>
Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
(cherry picked from commit 7fc6611cad3e9627b23ce83e550b668abba6c886)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: bec9a96934539cf4d808cc328aa9c6fa9d36274d
https://github.com/qemu/qemu/commit/bec9a96934539cf4d808cc328aa9c6fa9d36274d
Author: Jan Klötzke <jan.kloet...@kernkonzept.com>
Date: 2024-09-25 (Wed, 25 Sep 2024)
Changed paths:
M hw/intc/arm_gic.c
Log Message:
-----------
hw/intc/arm_gic: fix spurious level triggered interrupts
On GICv2 and later, level triggered interrupts are pending when either
the interrupt line is asserted or the interrupt was made pending by a
GICD_ISPENDRn write. Making a level triggered interrupt pending by
software persists until either the interrupt is acknowledged or cleared
by writing GICD_ICPENDRn. As long as the interrupt line is asserted,
the interrupt is pending in any case.
This logic is transparently implemented in gic_test_pending() for
GICv1 and GICv2. The function combines the "pending" irq_state flag
(used for edge triggered interrupts and software requests) and the
line status (tracked in the "level" field). However, we also
incorrectly set the pending flag on a guest write to GICD_ISENABLERn
if the line of a level triggered interrupt was asserted. This keeps
the interrupt pending even if the line is de-asserted after some
time.
This incorrect logic is a leftover of the initial 11MPCore GIC
implementation. That handles things slightly differently to the
architected GICv1 and GICv2. The 11MPCore TRM does not give a lot of
detail on the corner cases of its GIC's behaviour, and historically
we have not wanted to investigate exactly what it does in reality, so
QEMU's GIC model takes the approach of "retain our existing behaviour
for 11MPCore, and implement the architectural standard for later GIC
revisions".
On that basis, commit 8d999995e45c10 in 2013 is where we added the
"level-triggered interrupt with the line asserted" handling to
gic_test_pending(), and we deliberately kept the old behaviour of
gic_test_pending() for REV_11MPCORE. That commit should have added
the "only if 11MPCore" condition to the setting of the pending bit on
writes to GICD_ISENABLERn, but forgot it.
Add the missing "if REV_11MPCORE" condition, so that our behaviour
on GICv1 and GICv2 matches the GIC architecture requirements.
Cc: qemu-sta...@nongnu.org
Fixes: 8d999995e45c10 ("arm_gic: Fix GIC pending behavior")
Signed-off-by: Jan Klötzke <jan.kloet...@kernkonzept.com>
Message-id: 20240911114826.3558302-1-jan.kloet...@kernkonzept.com
Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
[PMM: expanded comment a little and converted to coding-style form;
expanded commit message with the historical backstory]
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
(cherry picked from commit 110684c9a69a02cbabfbddcd3afa921826ad565c)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: b95002f47a4da76f98f62e7dcc8e5eed9a83436a
https://github.com/qemu/qemu/commit/b95002f47a4da76f98f62e7dcc8e5eed9a83436a
Author: Gert Wollny <gert.wol...@collabora.com>
Date: 2024-09-25 (Wed, 25 Sep 2024)
Changed paths:
M ui/sdl2.c
Log Message:
-----------
ui/sdl2: set swap interval explicitly when OpenGL is enabled
Before 176e3783f2ab (ui/sdl2: OpenGL window context)
SDL_CreateRenderer was called unconditionally setting
the swap interval to 0. Since SDL_CreateRenderer is now no
longer called when OpenGL is enabled, the swap interval is
no longer set explicitly and vsync handling depends on
the environment settings which may lead to a performance
regression with virgl as reported in
https://gitlab.com/qemu-project/qemu/-/issues/2565
Restore the old vsync handling by explicitly calling
SDL_GL_SetSwapInterval if OpenGL is enabled.
Fixes: 176e3783f2ab (ui/sdl2: OpenGL window context)
Closes: https://gitlab.com/qemu-project/qemu/-/issues/2565
Signed-off-by: Gert Wollny <gert.wol...@collabora.com>
Acked-by: Marc-André Lureau <marcandre.lur...@redhat.com>
Message-ID:
<01020191e05ce6df-84da6386-62c2-4ce8-840e-ad216ac253dd-000...@eu-west-1.amazonses.com>
Signed-off-by: Philippe Mathieu-Daudé <phi...@linaro.org>
(cherry picked from commit ae23cd00170baaa2777eb1ee87b70f472dbb3c44)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 02833b07b6718e0c7c10e8cd600d917a866da5aa
https://github.com/qemu/qemu/commit/02833b07b6718e0c7c10e8cd600d917a866da5aa
Author: Daniel P. Berrangé <berra...@redhat.com>
Date: 2024-09-25 (Wed, 25 Sep 2024)
Changed paths:
M .gitlab-ci.d/base.yml
Log Message:
-----------
gitlab: fix logic for changing docker tag on stable branches
This fixes:
commit e28112d00703abd136e2411d23931f4f891c9244
Author: Daniel P. Berrangé <berra...@redhat.com>
Date: Thu Jun 8 17:40:16 2023 +0100
gitlab: stable staging branches publish containers in a separate tag
Due to a copy+paste mistake, that commit included "QEMU_JOB_SKIPPED"
in the final rule that was meant to be a 'catch all' for staging
branches.
As a result stable branches are still splattering dockers from the
primary development branch.
Signed-off-by: Daniel P. Berrangé <berra...@redhat.com>
Reviewed-by: Michael Tokarev <m...@tls.msk.ru>
Tested-by: Michael Tokarev <m...@tls.msk.ru>
Message-ID: <20240906140958.84755-1-berra...@redhat.com>
Signed-off-by: Thomas Huth <th...@redhat.com>
(cherry picked from commit 8d5ab746b1e6668ffb0378820b25665b385c8573)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 0d889c5c86d0c5acbcd218c3dc5130c170f74361
https://github.com/qemu/qemu/commit/0d889c5c86d0c5acbcd218c3dc5130c170f74361
Author: Mattias Nissler <mniss...@rivosinc.com>
Date: 2024-09-25 (Wed, 25 Sep 2024)
Changed paths:
M hw/pci/pci.c
M include/exec/memory.h
M include/hw/pci/pci_device.h
M system/memory.c
M system/physmem.c
Log Message:
-----------
softmmu: Support concurrent bounce buffers
When DMA memory can't be directly accessed, as is the case when
running the device model in a separate process without shareable DMA
file descriptors, bounce buffering is used.
It is not uncommon for device models to request mapping of several DMA
regions at the same time. Examples include:
* net devices, e.g. when transmitting a packet that is split across
several TX descriptors (observed with igb)
* USB host controllers, when handling a packet with multiple data TRBs
(observed with xhci)
Previously, qemu only provided a single bounce buffer per AddressSpace
and would fail DMA map requests while the buffer was already in use. In
turn, this would cause DMA failures that ultimately manifest as hardware
errors from the guest perspective.
This change allocates DMA bounce buffers dynamically instead of
supporting only a single buffer. Thus, multiple DMA mappings work
correctly also when RAM can't be mmap()-ed.
The total bounce buffer allocation size is limited individually for each
AddressSpace. The default limit is 4096 bytes, matching the previous
maximum buffer size. A new x-max-bounce-buffer-size parameter is
provided to configure the limit for PCI devices.
Signed-off-by: Mattias Nissler <mniss...@rivosinc.com>
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Acked-by: Peter Xu <pet...@redhat.com>
Link: https://lore.kernel.org/r/20240819135455.2957406-1-mniss...@rivosinc.com
Signed-off-by: Peter Xu <pet...@redhat.com>
(cherry picked from commit 637b0aa139565cb82a7b9269e62214f87082635c)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 659eeb16b35839a0ea683a82a3896e7344d12319
https://github.com/qemu/qemu/commit/659eeb16b35839a0ea683a82a3896e7344d12319
Author: David Hildenbrand <da...@redhat.com>
Date: 2024-09-25 (Wed, 25 Sep 2024)
Changed paths:
M include/exec/ramlist.h
M system/physmem.c
Log Message:
-----------
softmmu/physmem: fix memory leak in dirty_memory_extend()
As reported by Peter, we might be leaking memory when removing the
highest RAMBlock (in the weird ram_addr_t space), and adding a new one.
We will fail to realize that we already allocated bitmaps for more
dirty memory blocks, and effectively discard the pointers to them.
Fix it by getting rid of last_ram_page() and by remembering the number
of dirty memory blocks that have been allocated already.
While at it, let's use "unsigned int" for the number of blocks, which
should be sufficient until we reach ~32 exabytes.
Looks like this leak was introduced as we switched from using a single
bitmap_zero_extend() to allocating multiple bitmaps:
bitmap_zero_extend() relies on g_renew() which should have taken care of
this.
Resolves:
https://lkml.kernel.org/r/CAFEAcA-k7a+VObGAfCFNygQNfCKL=AfX6A4kScq=vssk0pe...@mail.gmail.com
Reported-by: Peter Maydell <peter.mayd...@linaro.org>
Fixes: 5b82b703b69a ("memory: RCU ram_list.dirty_memory[] for safe RAM hotplug")
Reviewed-by: Stefan Hajnoczi <stefa...@redhat.com>
Reviewed-by: Peter Xu <pet...@redhat.com>
Tested-by: Peter Maydell <peter.mayd...@linaro.org>
Cc: qemu-sta...@nongnu.org
Cc: Stefan Hajnoczi <stefa...@redhat.com>
Cc: Paolo Bonzini <pbonz...@redhat.com>
Cc: Peter Xu <pet...@redhat.com>
Cc: Philippe Mathieu-Daudé <phi...@linaro.org>
Signed-off-by: David Hildenbrand <da...@redhat.com>
Link: https://lore.kernel.org/r/20240828090743.128647-1-da...@redhat.com
Signed-off-by: Peter Xu <pet...@redhat.com>
(cherry picked from commit b84f06c2bee727b3870b4eeccbe3a45c5aea14c1)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 97fa3d7fccb1975a33caf011dfd83aba437608d9
https://github.com/qemu/qemu/commit/97fa3d7fccb1975a33caf011dfd83aba437608d9
Author: Fea.Wang <fea.w...@sifive.com>
Date: 2024-09-25 (Wed, 25 Sep 2024)
Changed paths:
M system/physmem.c
Log Message:
-----------
softmmu/physmem.c: Keep transaction attribute in address_space_map()
The follow-up transactions may use the data in the attribution, so keep
the value of attribution from the function parameter just as
flatview_translate() above.
Signed-off-by: Fea.Wang <fea.w...@sifive.com>
Cc: qemu-sta...@nongnu.org
Fixes: f26404fbee ("Make address_space_map() take a MemTxAttrs argument")
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Link: https://lore.kernel.org/r/20240912070404.2993976-2-fea.w...@sifive.com
Signed-off-by: Peter Xu <pet...@redhat.com>
(cherry picked from commit d8d5ca40048b04750de5a0ae0b2b9f153a391951)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 73f5d5bfb7b1f53c830bdd41cc20aefe12ab4827
https://github.com/qemu/qemu/commit/73f5d5bfb7b1f53c830bdd41cc20aefe12ab4827
Author: Mattias Nissler <mniss...@rivosinc.com>
Date: 2024-09-25 (Wed, 25 Sep 2024)
Changed paths:
M hw/ide/macio.c
M include/hw/ppc/mac_dbdma.h
Log Message:
-----------
mac_dbdma: Remove leftover `dma_memory_unmap` calls
These were passing a NULL buffer pointer unconditionally, which happens
to behave in a mostly benign way (except for the chance of an excess
memory region unref and a bounce buffer leak). Per the function comment,
this was never meant to be accepted though, and triggers an assertion
with the "softmmu: Support concurrent bounce buffers" change.
Given that the code in question never sets up any mappings, just remove
the unnecessary dma_memory_unmap calls along with the DBDMA_io struct
fields that are now entirely unused.
Signed-off-by: Mattias Nissler <mniss...@rivosinc.com>
Message-Id: <20240916175708.1829059-1-mniss...@rivosinc.com>
Fixes: be1e343995 ("macio: switch over to new byte-aligned DMA helpers")
Reviewed-by: Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk>
Tested-by: Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk>
Signed-off-by: Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk>
(cherry picked from commit 2d0a071e625d7234e8c5623b7e7bf445e1bef72c)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 9b42e33bda413faa9d649643548b72a68f203f53
https://github.com/qemu/qemu/commit/9b42e33bda413faa9d649643548b72a68f203f53
Author: Fabiano Rosas <faro...@suse.de>
Date: 2024-09-25 (Wed, 25 Sep 2024)
Changed paths:
M migration/migration.c
M migration/savevm.c
Log Message:
-----------
migration/multifd: Fix rb->receivedmap cleanup race
Fix a segmentation fault in multifd when rb->receivedmap is cleared
too early.
After commit 5ef7e26bdb ("migration/multifd: solve zero page causing
multiple page faults"), multifd started using the rb->receivedmap
bitmap, which belongs to ram.c and is initialized and *freed* from the
ram SaveVMHandlers.
Multifd threads are live until migration_incoming_state_destroy(),
which is called after qemu_loadvm_state_cleanup(), leading to a crash
when accessing rb->receivedmap.
process_incoming_migration_co() ...
qemu_loadvm_state() multifd_nocomp_recv()
qemu_loadvm_state_cleanup() ramblock_recv_bitmap_set_offset()
rb->receivedmap = NULL set_bit_atomic(..., rb->receivedmap)
...
migration_incoming_state_destroy()
multifd_recv_cleanup()
multifd_recv_terminate_threads(NULL)
Move the loadvm cleanup into migration_incoming_state_destroy(), after
multifd_recv_cleanup() to ensure multifd threads have already exited
when rb->receivedmap is cleared.
Adjust the postcopy listen thread comment to indicate that we still
want to skip the cpu synchronization.
CC: qemu-sta...@nongnu.org
Fixes: 5ef7e26bdb ("migration/multifd: solve zero page causing multiple page
faults")
Signed-off-by: Fabiano Rosas <faro...@suse.de>
Link: https://lore.kernel.org/r/20240917185802.15619-3-faro...@suse.de
[peterx: added comment in migration_incoming_state_destroy()]
Signed-off-by: Peter Xu <pet...@redhat.com>
(cherry picked from commit 4ce56229087860805877075ddb29dd44578365a9)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 1faa437db9b5e9217648f1e8db8a03ef93e5aed1
https://github.com/qemu/qemu/commit/1faa437db9b5e9217648f1e8db8a03ef93e5aed1
Author: Jacob Abrams <satur9n...@gmail.com>
Date: 2024-09-25 (Wed, 25 Sep 2024)
Changed paths:
M hw/char/stm32l4x5_usart.c
M tests/qtest/stm32l4x5_usart-test.c
Log Message:
-----------
hw/char/stm32l4x5_usart.c: Enable USART ACK bit response
SW modifying USART_CR1 TE bit should cuase HW to respond by altering
USART_ISR TEACK bit, and likewise for RE and REACK bit.
This resolves some but not all issues necessary for the official STM USART
HAL driver to function as is.
Fixes: 87b77e6e01ca ("hw/char/stm32l4x5_usart: Enable serial read and write")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2540
Signed-off-by: Jacob Abrams <satur9n...@gmail.com>
Message-id: 20240911043255.51966-1-satur9n...@gmail.com
Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
(cherry picked from commit 6cce0dcc6f7aaaeb7f17577776da510b04f67c99)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 03ee5e0c532d24a689b59495a36111a960420723
https://github.com/qemu/qemu/commit/03ee5e0c532d24a689b59495a36111a960420723
Author: Peter Maydell <peter.mayd...@linaro.org>
Date: 2024-09-25 (Wed, 25 Sep 2024)
Changed paths:
M target/arm/tcg/cpu64.c
Log Message:
-----------
target/arm: Correct ID_AA64ISAR1_EL1 value for neoverse-v1
The Neoverse-V1 TRM is a bit confused about the layout of the
ID_AA64ISAR1_EL1 register, and so its table 3-6 has the wrong value
for this ID register. Trust instead section 3.2.74's list of which
fields are set.
This means that we stop incorrectly reporting FEAT_XS as present, and
now report the presence of FEAT_BF16.
Cc: qemu-sta...@nongnu.org
Reported-by: Marcin Juszkiewicz <marcin.juszkiew...@linaro.org>
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
Reviewed-by: Richard Henderson <richard.hender...@linaro.org>
Message-id: 20240917161337.3012188-1-peter.mayd...@linaro.org
(cherry picked from commit 8676007eff04bb4e454bcdf92fab3f855bcc59b3)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: eb40b14740b9507c60805fccb723c3bd8903ab66
https://github.com/qemu/qemu/commit/eb40b14740b9507c60805fccb723c3bd8903ab66
Author: Helge Deller <del...@gmx.de>
Date: 2024-09-25 (Wed, 25 Sep 2024)
Changed paths:
M target/hppa/cpu.h
Log Message:
-----------
target/hppa: Fix random 32-bit linux-user crashes
The linux-user hppa target crashes randomly for me since commit
081a0ed188d8 ("target/hppa: Do not mask in copy_iaoq_entry").
That commit dropped the masking of the IAOQ addresses while copying them
from other registers and instead keeps them with all 64 bits up until
the full gva is formed with the help of hppa_form_gva_psw().
So, when running in linux-user mode on an emulated 64-bit CPU, we need
to mask to a 32-bit address space at the very end in hppa_form_gva_psw()
if the PSW-W flag isn't set (which is the case for linux-user on hppa).
Fixes: 081a0ed188d8 ("target/hppa: Do not mask in copy_iaoq_entry")
Cc: qemu-sta...@nongnu.org # v9.1+
Signed-off-by: Helge Deller <del...@gmx.de>
Reviewed-by: Richard Henderson <richard.hender...@linaro.org>
(cherry picked from commit d33d3adb573794903380e03e767e06470514cefe)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: f84b79a8fcf46d73bc2345cf14ca863fa8e05ea6
https://github.com/qemu/qemu/commit/f84b79a8fcf46d73bc2345cf14ca863fa8e05ea6
Author: Arman Nabiev <nabiev.arma...@gmail.com>
Date: 2024-09-25 (Wed, 25 Sep 2024)
Changed paths:
M target/ppc/machine.c
Log Message:
-----------
target/ppc: Fix migration of CPUs with TLB_EMB TLB type
In vmstate_tlbemb a cut-and-paste error meant we gave
this vmstate subsection the same "cpu/tlb6xx" name as
the vmstate_tlb6xx subsection. This breaks migration load
for any CPU using the TLB_EMB CPU type, because when we
see the "tlb6xx" name in the incoming data we try to
interpret it as a vmstate_tlb6xx subsection, which it
isn't the right format for:
$ qemu-system-ppc -drive
if=none,format=qcow2,file=/home/petmay01/test-images/virt/dummy.qcow2
-monitor stdio -M bamboo
QEMU 9.0.92 monitor - type 'help' for more information
(qemu) savevm foo
(qemu) loadvm foo
Missing section footer for cpu
Error: Error -22 while loading VM state
Correct the incorrect vmstate section name. Since migration
for these CPU types was completely broken before, we don't
need to care that this is a migration compatibility break.
This affects the PPC 405, 440, 460 and e200 CPU families.
Cc: qemu-sta...@nongnu.org
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2522
Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
Signed-off-by: Arman Nabiev <nabiev.arma...@gmail.com>
Signed-off-by: Fabiano Rosas <faro...@suse.de>
(cherry picked from commit 203beb6f047467a4abfc8267c234393cea3f471c)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 9cd1fd4b5025df866eb0bd8a86230e83ae049882
https://github.com/qemu/qemu/commit/9cd1fd4b5025df866eb0bd8a86230e83ae049882
Author: Fabiano Rosas <faro...@suse.de>
Date: 2024-09-25 (Wed, 25 Sep 2024)
Changed paths:
M migration/multifd-uadk.c
Log Message:
-----------
migration/multifd: Fix p->iov leak in multifd-uadk.c
The send_cleanup() hook should free the p->iov that was allocated at
send_setup(). This was missed because the UADK code is conditional on
the presence of the accelerator, so it's not tested by default.
Fixes: 819dd20636 ("migration/multifd: Add UADK initialization")
Reported-by: Peter Xu <pet...@redhat.com>
Reviewed-by: Peter Xu <pet...@redhat.com>
Signed-off-by: Fabiano Rosas <faro...@suse.de>
(cherry picked from commit 405e352d28c24991cacfdebccf67d56c4795cf6e)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 51c943931d75959b787ea72e2cf8e79369ac1cd0
https://github.com/qemu/qemu/commit/51c943931d75959b787ea72e2cf8e79369ac1cd0
Author: Bibo Mao <maob...@loongson.cn>
Date: 2024-09-26 (Thu, 26 Sep 2024)
Changed paths:
M hw/loongarch/virt.c
Log Message:
-----------
hw/loongarch/virt: Add description for virt machine type
The description about virt machine type is removed by mistake, add
new description here. Here is output result with command
"./qemu-system-loongarch64 -M help"
Supported machines are:
none empty machine
virt QEMU LoongArch Virtual Machine (default)
x-remote Experimental remote machine
Without the patch, it shows as follows:
Supported machines are:
none empty machine
virt (null) (default)
x-remote Experimental remote machine
Fixes: ef2f11454c(hw/loongarch/virt: Replace Loongson IPI with LoongArch IPI)
Signed-off-by: Bibo Mao <maob...@loongson.cn>
Reviewed-by: Thomas Huth <th...@redhat.com>
Reviewed-by: Michael Tokarev <m...@tls.msk.ru>
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
(cherry picked from commit 4265b4f358436252ef36164566f316458f1df671)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 4c7c0d2442fbfcbe128198aa5f3613f387f291ac
https://github.com/qemu/qemu/commit/4c7c0d2442fbfcbe128198aa5f3613f387f291ac
Author: TANG Tiancheng <tangtiancheng....@alibaba-inc.com>
Date: 2024-09-28 (Sat, 28 Sep 2024)
Changed paths:
M tcg/tcg-op-gvec.c
Log Message:
-----------
tcg: Fix iteration step in 32-bit gvec operation
The loop in the 32-bit case of the vector compare operation
was incorrectly incrementing by 8 bytes per iteration instead
of 4 bytes. This caused the function to process only half of
the intended elements.
Cc: qemu-sta...@nongnu.org
Fixes: 9622c697d1 (tcg: Add gvec compare with immediate and scalar operand)
Signed-off-by: TANG Tiancheng <tangtiancheng....@alibaba-inc.com>
Reviewed-by: Liu Zhiwei <zhiwei_...@linux.alibaba.com>
Reviewed-by: Richard Henderson <richard.hender...@linaro.org>
Message-ID: <20240904142739.854-2-zhiwei_...@linux.alibaba.com>
Signed-off-by: Richard Henderson <richard.hender...@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
(cherry picked from commit 9d8d5a5b9078a16b4c0862fe54248c5cc8435648)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: f8244f3b8c87bd7483c4cc48f86947993bcf32fa
https://github.com/qemu/qemu/commit/f8244f3b8c87bd7483c4cc48f86947993bcf32fa
Author: Fabiano Rosas <faro...@suse.de>
Date: 2024-09-28 (Sat, 28 Sep 2024)
Changed paths:
M target/ppc/translate/vsx-impl.c.inc
Log Message:
-----------
target/ppc: Fix lxvx/stxvx facility check
The XT check for the lxvx/stxvx instructions is currently
inverted. This was introduced during the move to decodetree.
>From the ISA:
Chapter 7. Vector-Scalar Extension Facility
Load VSX Vector Indexed X-form
lxvx XT,RA,RB
if TX=0 & MSR.VSX=0 then VSX_Unavailable()
if TX=1 & MSR.VEC=0 then Vector_Unavailable()
...
Let XT be the value 32×TX + T.
The code currently does the opposite:
if (paired || a->rt >= 32) {
REQUIRE_VSX(ctx);
} else {
REQUIRE_VECTOR(ctx);
}
This was already fixed for lxv/stxv at commit "2cc0e449d1 (target/ppc:
Fix lxv/stxv MSR facility check)", but the indexed forms were missed.
Cc: qemu-sta...@nongnu.org
Fixes: 70426b5bb7 ("target/ppc: moved stxvx and lxvx from legacy to decodtree")
Signed-off-by: Fabiano Rosas <faro...@suse.de>
Reviewed-by: Claudio Fontana <cfont...@suse.de>
Acked-by: Ilya Leoshkevich <i...@linux.ibm.com>
Reviewed-by: Fabiano Rosas <faro...@suse.de>
Message-ID: <20240911141651.6914-1-faro...@suse.de>
Signed-off-by: Richard Henderson <richard.hender...@linaro.org>
(cherry picked from commit 8bded2e73e80823a67f730140788a3c5e60bf4b5)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 8fc8dd2efdedec96082777dc3065a389a9ecf5d9
https://github.com/qemu/qemu/commit/8fc8dd2efdedec96082777dc3065a389a9ecf5d9
Author: Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk>
Date: 2024-09-28 (Sat, 28 Sep 2024)
Changed paths:
M hw/mips/jazz.c
Log Message:
-----------
hw/mips/jazz: fix typo in in-built NIC alias
Commit e104edbb9d ("hw/mips/jazz: use qemu_find_nic_info()") contained a typo
in the NIC alias which caused initialisation of the in-built dp83932 NIC to fail
when using the normal -nic user,model=dp83932 command line.
Fixes: e104edbb9d ("hw/mips/jazz: use qemu_find_nic_info()")
Signed-off-by: Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk>
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
Reviewed-by: David Woodhouse <d...@amazon.co.uk>
Reviewed-by: Michael Tokarev <m...@tls.msk.ru>
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
(cherry picked from commit 2e4fdf566062c03456230fd8136b88c5c1e5c4bf)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: bb630d92516cb39ee830566b5e0335a4e14b1cc6
https://github.com/qemu/qemu/commit/bb630d92516cb39ee830566b5e0335a4e14b1cc6
Author: Alex Bennée <alex.ben...@linaro.org>
Date: 2024-09-30 (Mon, 30 Sep 2024)
Changed paths:
M util/qemu-timer.c
Log Message:
-----------
util/timer: avoid deadlock when shutting down
When we shut down a guest we disable the timers. However this can
cause deadlock if the guest has queued some async work that is trying
to advance system time and spins forever trying to wind time forward.
Pay attention to the return code and bail early if we can't wind time
forward.
Reported-by: Elisha Hollander <just4now666...@gmail.com>
Signed-off-by: Alex Bennée <alex.ben...@linaro.org>
Reviewed-by: Pierrick Bouvier <pierrick.bouv...@linaro.org>
Message-Id: <20240916085400.1046925-15-alex.ben...@linaro.org>
(cherry picked from commit bc02be4508d8753d1f6071b77d10f4661587df6f)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 7eefbf8bb72c1bec0972ca19901207dc6d2acf5a
https://github.com/qemu/qemu/commit/7eefbf8bb72c1bec0972ca19901207dc6d2acf5a
Author: Fiona Ebner <f.eb...@proxmox.com>
Date: 2024-10-01 (Tue, 01 Oct 2024)
Changed paths:
M block/copy-before-write.c
M block/reqlist.c
Log Message:
-----------
block/reqlist: allow adding overlapping requests
Allow overlapping request by removing the assert that made it
impossible. There are only two callers:
1. block_copy_task_create()
It already asserts the very same condition before calling
reqlist_init_req().
2. cbw_snapshot_read_lock()
There is no need to have read requests be non-overlapping in
copy-before-write when used for snapshot-access. In fact, there was no
protection against two callers of cbw_snapshot_read_lock() calling
reqlist_init_req() with overlapping ranges and this could lead to an
assertion failure [1].
In particular, with the reproducer script below [0], two
cbw_co_snapshot_block_status() callers could race, with the second
calling reqlist_init_req() before the first one finishes and removes
its conflicting request.
[0]:
> #!/bin/bash -e
> dd if=/dev/urandom of=/tmp/disk.raw bs=1M count=1024
> ./qemu-img create /tmp/fleecing.raw -f raw 1G
> (
> ./qemu-system-x86_64 --qmp stdio \
> --blockdev raw,node-name=node0,file.driver=file,file.filename=/tmp/disk.raw \
> --blockdev
> raw,node-name=node1,file.driver=file,file.filename=/tmp/fleecing.raw \
> <<EOF
> {"execute": "qmp_capabilities"}
> {"execute": "blockdev-add", "arguments": { "driver": "copy-before-write",
> "file": "node0", "target": "node1", "node-name": "node3" } }
> {"execute": "blockdev-add", "arguments": { "driver": "snapshot-access",
> "file": "node3", "node-name": "snap0" } }
> {"execute": "nbd-server-start", "arguments": {"addr": { "type": "unix",
> "data": { "path": "/tmp/nbd.socket" } } } }
> {"execute": "block-export-add", "arguments": {"id": "exp0", "node-name":
> "snap0", "type": "nbd", "name": "exp0"}}
> EOF
> ) &
> sleep 5
> while true; do
> ./qemu-nbd -d /dev/nbd0
> ./qemu-nbd -c /dev/nbd0 nbd:unix:/tmp/nbd.socket:exportname=exp0 -f raw -r
> nbdinfo --map 'nbd+unix:///exp0?socket=/tmp/nbd.socket'
> done
[1]:
> #5 0x000071e5f0088eb2 in __GI___assert_fail (...) at ./assert/assert.c:101
> #6 0x0000615285438017 in reqlist_init_req (...) at ../block/reqlist.c:23
> #7 0x00006152853e2d98 in cbw_snapshot_read_lock (...) at
> ../block/copy-before-write.c:237
> #8 0x00006152853e3068 in cbw_co_snapshot_block_status (...) at
> ../block/copy-before-write.c:304
> #9 0x00006152853f4d22 in bdrv_co_snapshot_block_status (...) at
> ../block/io.c:3726
> #10 0x000061528543a63e in snapshot_access_co_block_status (...) at
> ../block/snapshot-access.c:48
> #11 0x00006152853f1a0a in bdrv_co_do_block_status (...) at ../block/io.c:2474
> #12 0x00006152853f2016 in bdrv_co_common_block_status_above (...) at
> ../block/io.c:2652
> #13 0x00006152853f22cf in bdrv_co_block_status_above (...) at
> ../block/io.c:2732
> #14 0x00006152853d9a86 in blk_co_block_status_above (...) at
> ../block/block-backend.c:1473
> #15 0x000061528538da6c in blockstatus_to_extents (...) at ../nbd/server.c:2374
> #16 0x000061528538deb1 in nbd_co_send_block_status (...) at
> ../nbd/server.c:2481
> #17 0x000061528538f424 in nbd_handle_request (...) at ../nbd/server.c:2978
> #18 0x000061528538f906 in nbd_trip (...) at ../nbd/server.c:3121
> #19 0x00006152855a7caf in coroutine_trampoline (...) at
> ../util/coroutine-ucontext.c:175
Cc: qemu-sta...@nongnu.org
Suggested-by: Vladimir Sementsov-Ogievskiy <vsement...@yandex-team.ru>
Signed-off-by: Fiona Ebner <f.eb...@proxmox.com>
Message-Id: <20240712140716.517911-1-f.eb...@proxmox.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsement...@yandex-team.ru>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsement...@yandex-team.ru>
(cherry picked from commit 6475155d519209c80fdda53e05130365aa769838)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 767e7d8ae1aee94e63f3d94a77dc1515a8a16dab
https://github.com/qemu/qemu/commit/767e7d8ae1aee94e63f3d94a77dc1515a8a16dab
Author: Ard Biesheuvel <a...@kernel.org>
Date: 2024-10-02 (Wed, 02 Oct 2024)
Changed paths:
M target/arm/internals.h
M target/arm/ptw.c
Log Message:
-----------
target/arm: Avoid target_ulong for physical address lookups
target_ulong is typedef'ed as a 32-bit integer when building the
qemu-system-arm target, and this is smaller than the size of an
intermediate physical address when LPAE is being used.
Given that Linux may place leaf level user page tables in high memory
when built for LPAE, the kernel will crash with an external abort as
soon as it enters user space when running with more than ~3 GiB of
system RAM.
So replace target_ulong with vaddr in places where it may carry an
address value that is not representable in 32 bits.
Fixes: f3639a64f602ea ("target/arm: Use softmmu tlbs for page table walking")
Cc: qemu-sta...@nongnu.org
Reported-by: Arnd Bergmann <a...@arndb.de>
Tested-by: Arnd Bergmann <a...@arndb.de>
Reviewed-by: Richard Henderson <richard.hender...@linaro.org>
Signed-off-by: Ard Biesheuvel <a...@kernel.org>
Message-id: 20240927071051.1444768-1-ardb+...@google.com
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
(cherry picked from commit 67d762e716a7127ecc114e9708254316dd521911)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: e32ac563b8375ef9dca7b6d02e1cd2feaaab3f58
https://github.com/qemu/qemu/commit/e32ac563b8375ef9dca7b6d02e1cd2feaaab3f58
Author: Jan Luebbe <j...@pengutronix.de>
Date: 2024-10-02 (Wed, 02 Oct 2024)
Changed paths:
M hw/sd/sd.c
Log Message:
-----------
hw/sd/sdcard: Fix handling of disabled boot partitions
The enable bits in the EXT_CSD_PART_CONFIG ext_csd register do *not*
specify whether the boot partitions exist, but whether they are enabled
for booting. Existence of the boot partitions is specified by a
EXT_CSD_BOOT_MULT != 0.
Currently, in the case of boot-partition-size=1M and boot-config=0,
Linux detects boot partitions of 1M. But as sd_bootpart_offset always
returns 0, all reads/writes are mapped to the same offset in the backing
file.
Fix this bug by calculating the offset independent of which partition is
enabled for booting.
This bug is unlikely to affect many users with QEMU's current set of
boards, because only aspeed sets boot-partition-size, and it also
sets boot-config to 8. So to run into this a user would have to
manually mark the boot partition non-booting from within the guest.
Cc: qemu-sta...@nongnu.org
Signed-off-by: Jan Luebbe <j...@pengutronix.de>
Message-id: 20240906164834.130257-1-...@pengutronix.de
Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
[PMM: added note to commit message about effects of bug]
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
(cherry picked from commit 9601076b3b0bced7ed597d1470e3ff2f4e7177d6)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 02ac67c41fbc6c4fe78ccec63dae959f45d13705
https://github.com/qemu/qemu/commit/02ac67c41fbc6c4fe78ccec63dae959f45d13705
Author: Alex Bennée <alex.ben...@linaro.org>
Date: 2024-10-03 (Thu, 03 Oct 2024)
Changed paths:
M tests/docker/dockerfiles/debian-mips64el-cross.docker
M tests/lcitool/mappings.yml
M tests/lcitool/refresh
Log Message:
-----------
testing: bump mips64el cross to bookworm and fix package list
The mips64el cross setup is very broken for bullseye which has now
entered LTS support so is unlikely to be fixed. While we still can't
build the container with all packages for bookworm due to a single
missing dependency that will hopefully get fixed in due course. For
the sake of keeping the CI green we disable the problematic packages
via the lcitool's mappings.yml file.
See also: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1081535
Signed-off-by: Alex Bennée <alex.ben...@linaro.org>
[thuth: Disable the problematic packages via lcitool's mappings.yml]
Message-ID: <20241002080333.127172-1-th...@redhat.com>
Reviewed-by: Daniel P. Berrangé <berra...@redhat.com>
Signed-off-by: Thomas Huth <th...@redhat.com>
(cherry picked from commit c60473d29254b79d9437eface8b342e84663ba66)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Commit: 5762cdaf45b0b75d55d64f3b8f441b140026ccb2
https://github.com/qemu/qemu/commit/5762cdaf45b0b75d55d64f3b8f441b140026ccb2
Author: Marc-André Lureau <marcandre.lur...@redhat.com>
Date: 2024-10-04 (Fri, 04 Oct 2024)
Changed paths:
M ui/vnc.c
Log Message:
-----------
vnc: fix crash when no console attached
Since commit e99441a3793b5 ("ui/curses: Do not use console_select()")
qemu_text_console_put_keysym() no longer checks for NULL console
argument, which leads to a later crash:
Thread 1 "qemu-system-x86" received signal SIGSEGV, Segmentation fault.
0x00005555559ee186 in qemu_text_console_handle_keysym (s=0x0, keysym=31) at
../ui/console-vc.c:332
332 } else if (s->echo && (keysym == '\r' || keysym == '\n')) {
(gdb) bt
#0 0x00005555559ee186 in qemu_text_console_handle_keysym (s=0x0, keysym=31)
at ../ui/console-vc.c:332
#1 0x00005555559e18e5 in qemu_text_console_put_keysym (s=<optimized out>,
keysym=<optimized out>) at ../ui/console.c:303
#2 0x00005555559f2e88 in do_key_event (vs=vs@entry=0x5555579045c0,
down=down@entry=1, keycode=keycode@entry=60, sym=sym@entry=65471) at
../ui/vnc.c:2034
#3 0x00005555559f845c in ext_key_event (vs=0x5555579045c0, down=1, sym=65471,
keycode=<optimized out>) at ../ui/vnc.c:2070
#4 protocol_client_msg (vs=0x5555579045c0, data=<optimized out>,
len=<optimized out>) at ../ui/vnc.c:2514
#5 0x00005555559f515c in vnc_client_read (vs=0x5555579045c0) at
../ui/vnc.c:1607
Fixes: e99441a3793b5 ("ui/curses: Do not use console_select()")
Fixes: https://issues.redhat.com/browse/RHEL-50529
Cc: qemu-sta...@nongnu.org
Signed-off-by: Marc-André Lureau <marcandre.lur...@redhat.com>
Reviewed-by: Akihiko Odaki <akihiko.od...@daynix.com>
Reviewed-by: Michael Tokarev <m...@tls.msk.ru>
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
(cherry picked from commit 0e60fc80938d9ce84274a36ddfaaa640bdef2be8)
Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
Compare: https://github.com/qemu/qemu/compare/9e4712a8c858...5762cdaf45b0
To unsubscribe from these emails, change your notification settings at
https://github.com/qemu/qemu/settings/notifications
