Branch: refs/heads/staging
  Home:   https://github.com/qemu/qemu
  Commit: e14236b30bc5c65ccf37daa63b8258ebb9a839f9
      
https://github.com/qemu/qemu/commit/e14236b30bc5c65ccf37daa63b8258ebb9a839f9
  Author: Richard Henderson <richard.hender...@linaro.org>
  Date:   2025-06-23 (Mon, 23 Jun 2025)

  Changed paths:
    M tcg/tcg-op-gvec.c

  Log Message:
  -----------
  tcg: Add dbase argument to do_dup_store

Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
Signed-off-by: Richard Henderson <richard.hender...@linaro.org>


  Commit: 731422ebbdaebd4a88c9df4072e19dee2ead70fe
      
https://github.com/qemu/qemu/commit/731422ebbdaebd4a88c9df4072e19dee2ead70fe
  Author: Richard Henderson <richard.hender...@linaro.org>
  Date:   2025-06-23 (Mon, 23 Jun 2025)

  Changed paths:
    M tcg/tcg-op-gvec.c

  Log Message:
  -----------
  tcg: Add dbase argument to do_dup

Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
Signed-off-by: Richard Henderson <richard.hender...@linaro.org>


  Commit: ca09b6b5e556f343b8a7bfd8913c51786844830e
      
https://github.com/qemu/qemu/commit/ca09b6b5e556f343b8a7bfd8913c51786844830e
  Author: Richard Henderson <richard.hender...@linaro.org>
  Date:   2025-06-23 (Mon, 23 Jun 2025)

  Changed paths:
    M tcg/tcg-op-gvec.c

  Log Message:
  -----------
  tcg: Add dbase argument to expand_clr

Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
Signed-off-by: Richard Henderson <richard.hender...@linaro.org>


  Commit: 872dab5b7ec4722aaa7791820425e460466ddf71
      
https://github.com/qemu/qemu/commit/872dab5b7ec4722aaa7791820425e460466ddf71
  Author: Richard Henderson <richard.hender...@linaro.org>
  Date:   2025-06-23 (Mon, 23 Jun 2025)

  Changed paths:
    M tcg/tcg-op-gvec.c

  Log Message:
  -----------
  tcg: Add base arguments to check_overlap_[234]

Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
Signed-off-by: Richard Henderson <richard.hender...@linaro.org>


  Commit: 7a74c13468e71a56147b75c2881ce3edaf7fbc19
      
https://github.com/qemu/qemu/commit/7a74c13468e71a56147b75c2881ce3edaf7fbc19
  Author: Richard Henderson <richard.hender...@linaro.org>
  Date:   2025-06-23 (Mon, 23 Jun 2025)

  Changed paths:
    M include/tcg/tcg-op-gvec-common.h
    M tcg/tcg-op-gvec.c

  Log Message:
  -----------
  tcg: Split out tcg_gen_gvec_2_var

Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
Signed-off-by: Richard Henderson <richard.hender...@linaro.org>


  Commit: 465b21ffbef3de1888d535b37a2ad0b27438580e
      
https://github.com/qemu/qemu/commit/465b21ffbef3de1888d535b37a2ad0b27438580e
  Author: Richard Henderson <richard.hender...@linaro.org>
  Date:   2025-06-23 (Mon, 23 Jun 2025)

  Changed paths:
    M include/tcg/tcg-op-gvec-common.h
    M tcg/tcg-op-gvec.c

  Log Message:
  -----------
  tcg: Split out tcg_gen_gvec_3_var

Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
Signed-off-by: Richard Henderson <richard.hender...@linaro.org>


  Commit: ebba58c44db127d676b4ab2d00e7ad1aba9f6bc4
      
https://github.com/qemu/qemu/commit/ebba58c44db127d676b4ab2d00e7ad1aba9f6bc4
  Author: Richard Henderson <richard.hender...@linaro.org>
  Date:   2025-06-23 (Mon, 23 Jun 2025)

  Changed paths:
    M include/tcg/tcg-op-gvec-common.h
    M tcg/tcg-op-gvec.c

  Log Message:
  -----------
  tcg: Split out tcg_gen_gvec_mov_var

Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
Signed-off-by: Richard Henderson <richard.hender...@linaro.org>


  Commit: 4474051821c994ca905b56ae1276bcc3ba14ccda
      
https://github.com/qemu/qemu/commit/4474051821c994ca905b56ae1276bcc3ba14ccda
  Author: Richard Henderson <richard.hender...@linaro.org>
  Date:   2025-06-23 (Mon, 23 Jun 2025)

  Changed paths:
    M include/tcg/tcg-op-gvec-common.h
    M tcg/tcg-op-gvec.c

  Log Message:
  -----------
  tcg: Split out tcg_gen_gvec_{add,sub}_var

Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
Signed-off-by: Richard Henderson <richard.hender...@linaro.org>


  Commit: aa1cc0d74dc48da3b90476fbcc7fa339c61c8045
      
https://github.com/qemu/qemu/commit/aa1cc0d74dc48da3b90476fbcc7fa339c61c8045
  Author: Richard Henderson <richard.hender...@linaro.org>
  Date:   2025-06-23 (Mon, 23 Jun 2025)

  Changed paths:
    M include/tcg/tcg-op-gvec-common.h
    M tcg/tcg-op-gvec.c

  Log Message:
  -----------
  tcg: Split out tcg_gen_gvec_dup_imm_var

Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
Signed-off-by: Richard Henderson <richard.hender...@linaro.org>


  Commit: a9cd024c5822d08656127fde133975fde40f206c
      
https://github.com/qemu/qemu/commit/a9cd024c5822d08656127fde133975fde40f206c
  Author: Richard Henderson <richard.hender...@linaro.org>
  Date:   2025-06-23 (Mon, 23 Jun 2025)

  Changed paths:
    M linux-user/elfload.c

  Log Message:
  -----------
  linux-user/aarch64: Update hwcap bits from 6.14

Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
Signed-off-by: Richard Henderson <richard.hender...@linaro.org>


  Commit: 5171b794d4ac47efd81ef4da54137131e4ea550d
      
https://github.com/qemu/qemu/commit/5171b794d4ac47efd81ef4da54137131e4ea550d
  Author: Daniel P. Berrangé <berra...@redhat.com>
  Date:   2025-06-23 (Mon, 23 Jun 2025)

  Changed paths:
    M linux-user/gen-vdso.c

  Log Message:
  -----------
  linux-user: fix resource leaks in gen-vdso

There are a number of resource leaks in gen-vdso. In theory they are
harmless because this is a short lived process, but when building QEMU
with --extra-cflags="-fsanitize=address" problems ensure. The gen-vdso
program is run as part of the build, and that aborts due to the
sanitizer identifying memory leaks, leaving QEMU unbuildable.

FAILED: libqemu-x86_64-linux-user.a.p/vdso.c.inc
/var/home/berrange/src/virt/qemu/build/linux-user/gen-vdso -o 
libqemu-x86_64-linux-user.a.p/vdso.c.inc ../linux-user/x86_64/vdso.so

=================================================================
==1696332==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 2968 byte(s) in 1 object(s) allocated from:
    #0 0x56495873f1f3  
(/var/home/berrange/src/virt/qemu/build/linux-user/gen-vdso+0xa11f3) (BuildId: 
b69e241ad44719b6f3934f3c71dfc6727e8bdb12)
    #1 0x564958780b90  
(/var/home/berrange/src/virt/qemu/build/linux-user/gen-vdso+0xe2b90) (BuildId: 
b69e241ad44719b6f3934f3c71dfc6727e8bdb12)

This complaint is about the 'buf' variable, however, the FILE objects
are also leaked in some error scenarios, so this fix refactors the
cleanup paths to fix all leaks. For completeness it also reports an
error if fclose() fails on 'inf'.

Signed-off-by: Daniel P. Berrangé <berra...@redhat.com>
Tested-by: Arusekk <fl...@arusekk.pl>
Signed-off-by: Richard Henderson <richard.hender...@linaro.org>
Message-ID: <20250513150346.1328217-1-berra...@redhat.com>


  Commit: fd0377150d5dd4b02b2e7fbe9e8c1ab4dcbd16bb
      
https://github.com/qemu/qemu/commit/fd0377150d5dd4b02b2e7fbe9e8c1ab4dcbd16bb
  Author: Yanfei Xu <yanfei...@bytedance.com>
  Date:   2025-06-23 (Mon, 23 Jun 2025)

  Changed paths:
    M migration/ram.c

  Log Message:
  -----------
  migration/ram: avoid to do log clear in the last round

There won't be any ram sync after the stage of save_complete, therefore
it's unnecessary to do manually protect for dirty pages being sent. Skip
to do this in last round can reduce noticeable downtime.

Signed-off-by: Yanfei Xu <yanfei...@bytedance.com>
Tested-by: Fabiano Rosas <faro...@suse.de>
Reviewed-by: Fabiano Rosas <faro...@suse.de>
Link: https://lore.kernel.org/r/20250514115827.3216082-1-yanfei...@bytedance.com
[peterx: add comments]
Signed-off-by: Peter Xu <pet...@redhat.com>


  Commit: 8120decfb593c386e053a1ac9723e75bd181dbff
      
https://github.com/qemu/qemu/commit/8120decfb593c386e053a1ac9723e75bd181dbff
  Author: Fabiano Rosas <faro...@suse.de>
  Date:   2025-06-23 (Mon, 23 Jun 2025)

  Changed paths:
    R tests/qtest/migration-helpers.c

  Log Message:
  -----------
  tests/qtest: Remove migration-helpers.c

Commit 407bc4bf90 ("qapi: Move include/qapi/qmp/ to include/qobject/")
brought the migration-helpers.c back by mistake. This file has been
replaced with migration/migration-qmp.c and
migration/migration-util.c.

Fixes: 407bc4bf90 ("qapi: Move include/qapi/qmp/ to include/qobject/")
Signed-off-by: Fabiano Rosas <faro...@suse.de>
Message-id: 20200310152141.13959-1-peter.mayd...@linaro.org
Reviewed-by: Markus Armbruster <arm...@redhat.com>
Link: https://lore.kernel.org/r/20250523123023.19284-1-faro...@suse.de
Signed-off-by: Peter Xu <pet...@redhat.com>


  Commit: 0310d594d98b39f9dde79b87fd8b0ad16e7c5459
      
https://github.com/qemu/qemu/commit/0310d594d98b39f9dde79b87fd8b0ad16e7c5459
  Author: Juraj Marcin <jmar...@redhat.com>
  Date:   2025-06-23 (Mon, 23 Jun 2025)

  Changed paths:
    M ui/vnc.c
    M ui/vnc.h

  Log Message:
  -----------
  ui/vnc: Update display update interval when VM state changes to RUNNING

If a virtual machine is paused for an extended period time, for example,
due to an incoming migration, there are also no changes on the screen.
VNC in such case increases the display update interval by
VNC_REFRESH_INTERVAL_INC (50 ms). The update interval can then grow up
to VNC_REFRESH_INTERVAL_MAX (3000 ms).

When the machine resumes, it can then take up to 3 seconds for the first
display update. Furthermore, the update interval is then halved with
each display update with changes on the screen. If there are moving
elements on the screen, such as a video, this can be perceived as
freezing and stuttering for few seconds before the movement is smooth
again.

This patch resolves this issue, by adding a listener to VM state changes
and changing the update interval when the VM state changes to RUNNING.
The update_displaychangelistener() function updates the internal timer,
and the display is refreshed immediately if the timer is expired.

Signed-off-by: Juraj Marcin <jmar...@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lur...@redhat.com>
Reviewed-by: Peter Xu <pet...@redhat.com>
Reviewed-by: Daniel P. Berrangé <berra...@redhat.com>
Link: https://lore.kernel.org/r/20250521151616.3951178-1-jmar...@redhat.com
Signed-off-by: Peter Xu <pet...@redhat.com>


  Commit: 8f87c87eca4bc62258251eade7016f8a084b0988
      
https://github.com/qemu/qemu/commit/8f87c87eca4bc62258251eade7016f8a084b0988
  Author: Jaehoon Kim <jh...@linux.ibm.com>
  Date:   2025-06-23 (Mon, 23 Jun 2025)

  Changed paths:
    M migration/cpr-transfer.c

  Log Message:
  -----------
  migration: Support fd-based socket address in cpr_transfer_input

Extend cpr_transfer_input to handle SOCKET_ADDRESS_TYPE_FD alongside
SOCKET_ADDRESS_TYPE_UNIX. This change supports the use of pre-listened
socket file descriptors for cpr migration channels.

This change is particularly useful in qtest environments, where the
socket may be created externally and passed via fd.

Reviewed-by: Jason J. Herne <jjhe...@linux.ibm.com>
Reviewed-by: Steve Sistare <steven.sist...@oracle.com>
Signed-off-by: Jaehoon Kim <jh...@linux.ibm.com>
Link: https://lore.kernel.org/r/20250611205610.147008-3-jh...@linux.ibm.com
Signed-off-by: Peter Xu <pet...@redhat.com>


  Commit: 430671f52669e84c176c4d3b9091b88b51f542fb
      
https://github.com/qemu/qemu/commit/430671f52669e84c176c4d3b9091b88b51f542fb
  Author: Jaehoon Kim <jh...@linux.ibm.com>
  Date:   2025-06-23 (Mon, 23 Jun 2025)

  Changed paths:
    M tests/qtest/migration/cpr-tests.c

  Log Message:
  -----------
  tests/migration: Setup pre-listened cpr.sock to remove race-condition.

When the source VM attempts to connect to the destination VM's Unix
domain socket (cpr.sock) during a cpr-transfer test, race conditions can
occur if the socket file isn't ready. This can lead to connection
failures when running tests.

This patch creates and listens on the socket in advance, and passes the
pre-listened FD directly. This avoids timing issues and improves the
reliability of CPR tests.

Reviewed-by: Jason J. Herne <jjhe...@linux.ibm.com>
Signed-off-by: Jaehoon Kim <jh...@linux.ibm.com>
Reviewed-by: Steve Sistare <steven.sist...@oracle.com>
Link: https://lore.kernel.org/r/20250611205610.147008-2-jh...@linux.ibm.com
[peterx: null-initialize opts_target, per Steve]
Signed-off-by: Peter Xu <pet...@redhat.com>


  Commit: 983899eab4939dc4dff67fa4d822c5b4df7eae21
      
https://github.com/qemu/qemu/commit/983899eab4939dc4dff67fa4d822c5b4df7eae21
  Author: Chaney, Ben <bcha...@akamai.com>
  Date:   2025-06-23 (Mon, 23 Jun 2025)

  Changed paths:
    M migration/ram.c

  Log Message:
  -----------
  migration: Don't sync volatile memory after migration completes

Syncing volatile memory provides no benefit, instead it can cause
performance issues in some cases.  Only sync memory that is marked as
non-volatile after migration completes on destination.

Signed-off-by: Ben Chaney <bcha...@akamai.com>
Fixes: bd108a44bc29 (migration: ram: Switch to ram block writeback)
Link: https://lore.kernel.org/r/1cc43f59-336f-4a12-84ad-db89e0a17...@akamai.com
Signed-off-by: Peter Xu <pet...@redhat.com>


  Commit: f47a672a72acd6e2712031f0bc4d4f3ae4b6302c
      
https://github.com/qemu/qemu/commit/f47a672a72acd6e2712031f0bc4d4f3ae4b6302c
  Author: Chenyi Qiang <chenyi.qi...@intel.com>
  Date:   2025-06-23 (Mon, 23 Jun 2025)

  Changed paths:
    M hw/virtio/virtio-mem.c
    M include/system/memory.h

  Log Message:
  -----------
  memory: Export a helper to get intersection of a MemoryRegionSection with a 
given range

Rename the helper to memory_region_section_intersect_range() to make it
more generic. Meanwhile, define the @end as Int128 and replace the
related operations with Int128_* format since the helper is exported as
a wider API.

Suggested-by: Alexey Kardashevskiy <a...@amd.com>
Reviewed-by: Alexey Kardashevskiy <a...@amd.com>
Reviewed-by: Pankaj Gupta <pankaj.gu...@amd.com>
Reviewed-by: David Hildenbrand <da...@redhat.com>
Reviewed-by: Zhao Liu <zhao1....@intel.com>
Reviewed-by: Xiaoyao Li <xiaoyao...@intel.com>
Signed-off-by: Chenyi Qiang <chenyi.qi...@intel.com>
Link: https://lore.kernel.org/r/20250612082747.51539-2-chenyi.qi...@intel.com
Signed-off-by: Peter Xu <pet...@redhat.com>


  Commit: ff1211154c45c9f7f82116ae9a8c72a848e4a8b5
      
https://github.com/qemu/qemu/commit/ff1211154c45c9f7f82116ae9a8c72a848e4a8b5
  Author: Chenyi Qiang <chenyi.qi...@intel.com>
  Date:   2025-06-23 (Mon, 23 Jun 2025)

  Changed paths:
    M hw/virtio/virtio-mem.c
    M include/system/memory.h
    M system/memory.c

  Log Message:
  -----------
  memory: Change memory_region_set_ram_discard_manager() to return the result

Modify memory_region_set_ram_discard_manager() to return -EBUSY if a
RamDiscardManager is already set in the MemoryRegion. The caller must
handle this failure, such as having virtio-mem undo its actions and fail
the realize() process. Opportunistically move the call earlier to avoid
complex error handling.

This change is beneficial when introducing a new RamDiscardManager
instance besides virtio-mem. After
ram_block_coordinated_discard_require(true) unlocks all
RamDiscardManager instances, only one instance is allowed to be set for
one MemoryRegion at present.

Suggested-by: David Hildenbrand <da...@redhat.com>
Reviewed-by: David Hildenbrand <da...@redhat.com>
Reviewed-by: Pankaj Gupta <pankaj.gu...@amd.com>
Tested-by: Alexey Kardashevskiy <a...@amd.com>
Reviewed-by: Alexey Kardashevskiy <a...@amd.com>
Reviewed-by: Xiaoyao Li <xiaoyao...@intel.com>
Signed-off-by: Chenyi Qiang <chenyi.qi...@intel.com>
Link: https://lore.kernel.org/r/20250612082747.51539-3-chenyi.qi...@intel.com
Signed-off-by: Peter Xu <pet...@redhat.com>


  Commit: 2205b8466733f8c6e3306c964f31c5a7cac69dfa
      
https://github.com/qemu/qemu/commit/2205b8466733f8c6e3306c964f31c5a7cac69dfa
  Author: Chenyi Qiang <chenyi.qi...@intel.com>
  Date:   2025-06-23 (Mon, 23 Jun 2025)

  Changed paths:
    M hw/virtio/virtio-mem.c
    M include/system/memory.h
    M migration/ram.c
    M system/memory.c

  Log Message:
  -----------
  memory: Unify the definiton of ReplayRamPopulate() and ReplayRamDiscard()

Update ReplayRamDiscard() function to return the result and unify the
ReplayRamPopulate() and ReplayRamDiscard() to ReplayRamDiscardState() at
the same time due to their identical definitions. This unification
simplifies related structures, such as VirtIOMEMReplayData, which makes
it cleaner.

Reviewed-by: David Hildenbrand <da...@redhat.com>
Reviewed-by: Pankaj Gupta <pankaj.gu...@amd.com>
Reviewed-by: Xiaoyao Li <xiaoyao...@intel.com>
Signed-off-by: Chenyi Qiang <chenyi.qi...@intel.com>
Link: https://lore.kernel.org/r/20250612082747.51539-4-chenyi.qi...@intel.com
Signed-off-by: Peter Xu <pet...@redhat.com>


  Commit: 5d6483edaa9232d8f3709f68c8eab4bc2033fb70
      
https://github.com/qemu/qemu/commit/5d6483edaa9232d8f3709f68c8eab4bc2033fb70
  Author: Chenyi Qiang <chenyi.qi...@intel.com>
  Date:   2025-06-23 (Mon, 23 Jun 2025)

  Changed paths:
    M MAINTAINERS
    M include/system/ramblock.h
    M system/meson.build
    A system/ram-block-attributes.c
    M system/trace-events

  Log Message:
  -----------
  ram-block-attributes: Introduce RamBlockAttributes to manage RAMBlock with 
guest_memfd

Commit 852f0048f3 ("RAMBlock: make guest_memfd require uncoordinated
discard") highlighted that subsystems like VFIO may disable RAM block
discard. However, guest_memfd relies on discard operations for page
conversion between private and shared memory, potentially leading to
the stale IOMMU mapping issue when assigning hardware devices to
confidential VMs via shared memory. To address this and allow shared
device assignement, it is crucial to ensure the VFIO system refreshes
its IOMMU mappings.

RamDiscardManager is an existing interface (used by virtio-mem) to
adjust VFIO mappings in relation to VM page assignment. Effectively page
conversion is similar to hot-removing a page in one mode and adding it
back in the other. Therefore, similar actions are required for page
conversion events. Introduce the RamDiscardManager to guest_memfd to
facilitate this process.

Since guest_memfd is not an object, it cannot directly implement the
RamDiscardManager interface. Implementing it in HostMemoryBackend is
not appropriate because guest_memfd is per RAMBlock, and some RAMBlocks
have a memory backend while others do not. Notably, virtual BIOS
RAMBlocks using memory_region_init_ram_guest_memfd() do not have a
backend.

To manage RAMBlocks with guest_memfd, define a new object named
RamBlockAttributes to implement the RamDiscardManager interface. This
object can store the guest_memfd information such as the bitmap for
shared memory and the registered listeners for event notifications. A
new state_change() helper function is provided to notify listeners, such
as VFIO, allowing VFIO to do dynamically DMA map and unmap for the shared
memory according to conversion events. Note that in the current context
of RamDiscardManager for guest_memfd, the shared state is analogous to
being populated, while the private state can be considered discarded for
simplicity. In the future, it would be more complicated if considering
more states like private/shared/discarded at the same time.

In current implementation, memory state tracking is performed at the
host page size granularity, as the minimum conversion size can be one
page per request. Additionally, VFIO expected the DMA mapping for a
specific IOVA to be mapped and unmapped with the same granularity.
Confidential VMs may perform partial conversions, such as conversions on
small regions within a larger one. To prevent such invalid cases and
until support for DMA mapping cut operations is available, all
operations are performed with 4K granularity.

In addition, memory conversion failures cause QEMU to quit rather than
resuming the guest or retrying the operation at present. It would be
future work to add more error handling or rollback mechanisms once
conversion failures are allowed. For example, in-place conversion of
guest_memfd could retry the unmap operation during the conversion from
shared to private. For now, keep the complex error handling out of the
picture as it is not required.

Tested-by: Alexey Kardashevskiy <a...@amd.com>
Reviewed-by: Alexey Kardashevskiy <a...@amd.com>
Reviewed-by: Pankaj Gupta <pankaj.gu...@amd.com>
Signed-off-by: Chenyi Qiang <chenyi.qi...@intel.com>
Link: https://lore.kernel.org/r/20250612082747.51539-5-chenyi.qi...@intel.com
[peterx: squash fixup from Chenyi to fix builds]
Signed-off-by: Peter Xu <pet...@redhat.com>


  Commit: 2fde3fb916079ee0ff0fc26d9446c813b1d5cc28
      
https://github.com/qemu/qemu/commit/2fde3fb916079ee0ff0fc26d9446c813b1d5cc28
  Author: Chenyi Qiang <chenyi.qi...@intel.com>
  Date:   2025-06-23 (Mon, 23 Jun 2025)

  Changed paths:
    M accel/kvm/kvm-all.c
    M include/system/ramblock.h
    M system/physmem.c

  Log Message:
  -----------
  physmem: Support coordinated discarding of RAM with guest_memfd

A new field, attributes, was introduced in RAMBlock to link to a
RamBlockAttributes object, which centralizes all guest_memfd related
information (such as fd and status bitmap) within a RAMBlock.

Create and initialize the RamBlockAttributes object upon ram_block_add().
Meanwhile, register the object in the target RAMBlock's MemoryRegion.
After that, guest_memfd-backed RAMBlock is associated with the
RamDiscardManager interface, and the users can execute RamDiscardManager
specific handling. For example, VFIO will register the
RamDiscardListener and get notifications when the state_change() helper
invokes.

As coordinate discarding of RAM with guest_memfd is now supported, only
block uncoordinated discard.

Tested-by: Alexey Kardashevskiy <a...@amd.com>
Reviewed-by: Alexey Kardashevskiy <a...@amd.com>
Acked-by: David Hildenbrand <da...@redhat.com>
Signed-off-by: Chenyi Qiang <chenyi.qi...@intel.com>
Link: https://lore.kernel.org/r/20250612082747.51539-6-chenyi.qi...@intel.com
Signed-off-by: Peter Xu <pet...@redhat.com>


  Commit: 2b0e4ecd9466d493664317ffcc95275406862390
      
https://github.com/qemu/qemu/commit/2b0e4ecd9466d493664317ffcc95275406862390
  Author: Daniel P. Berrangé <berra...@redhat.com>
  Date:   2025-06-24 (Tue, 24 Jun 2025)

  Changed paths:
    A docs/devel/code-provenance.rst
    M docs/devel/index-process.rst
    M docs/devel/submitting-a-patch.rst

  Log Message:
  -----------
  docs: introduce dedicated page about code provenance / sign-off

Currently we have a short paragraph saying that patches must include
a Signed-off-by line, and merely link to the kernel documentation.
The linked kernel docs have a lot of content beyond the part about
sign-off an thus are misleading/distracting to QEMU contributors.

This introduces a dedicated 'code-provenance' page in QEMU talking
about why we require sign-off, explaining the other tags we commonly
use, and what to do in some edge cases.

Signed-off-by: Daniel P. Berrangé <berra...@redhat.com>
Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
Reviewed-by: Stefan Hajnoczi <stefa...@redhat.com>
Reviewed-by: Alex Bennée <alex.ben...@linaro.org>
Signed-off-by: Markus Armbruster <arm...@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefa...@redhat.com>


  Commit: b5d00557722d46cb845c05e546474284870e440b
      
https://github.com/qemu/qemu/commit/b5d00557722d46cb845c05e546474284870e440b
  Author: Daniel P. Berrangé <berra...@redhat.com>
  Date:   2025-06-24 (Tue, 24 Jun 2025)

  Changed paths:
    M docs/devel/code-provenance.rst

  Log Message:
  -----------
  docs: define policy limiting the inclusion of generated files

Files contributed to QEMU are generally expected to be provided in the
preferred format for manipulation. IOW, we generally don't expect to
have generated / compiled code included in the tree, rather, we expect
to run the code generator / compiler as part of the build process.

There are some obvious exceptions to this seen in our existing tree, the
biggest one being the inclusion of many binary firmware ROMs. A more
niche example is the inclusion of a generated eBPF program. Or the CI
dockerfiles which are mostly auto-generated. In these cases, however,
the preferred format source code is still required to be included,
alongside the generated output.

Tools which perform user defined algorithmic transformations on code are
not considered to be "code generators". ie, we permit use of coccinelle,
spell checkers, and sed/awk/etc to manipulate code. Such use of automated
manipulation should still be declared in the commit message.

One off generators which create a boilerplate file which the author then
fills in, are acceptable if their output has clear copyright and license
status. This could be where a contributor writes a throwaway python
script to automate creation of some mundane piece of code for example.

Signed-off-by: Daniel P. Berrangé <berra...@redhat.com>
Reviewed-by: Alex Bennée <alex.ben...@linaro.org>
Reviewed-by: Stefan Hajnoczi <stefa...@redhat.com>
Signed-off-by: Markus Armbruster <arm...@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefa...@redhat.com>


  Commit: 3d40db0efc22520fa6c399cf73960dced423b048
      
https://github.com/qemu/qemu/commit/3d40db0efc22520fa6c399cf73960dced423b048
  Author: Daniel P. Berrangé <berra...@redhat.com>
  Date:   2025-06-24 (Tue, 24 Jun 2025)

  Changed paths:
    M docs/devel/code-provenance.rst

  Log Message:
  -----------
  docs: define policy forbidding use of AI code generators

There has been an explosion of interest in so called AI code
generators. Thus far though, this is has not been matched by a broadly
accepted legal interpretation of the licensing implications for code
generator outputs. While the vendors may claim there is no problem and
a free choice of license is possible, they have an inherent conflict
of interest in promoting this interpretation. More broadly there is,
as yet, no broad consensus on the licensing implications of code
generators trained on inputs under a wide variety of licenses

The DCO requires contributors to assert they have the right to
contribute under the designated project license. Given the lack of
consensus on the licensing of AI code generator output, it is not
considered credible to assert compliance with the DCO clause (b) or (c)
where a patch includes such generated code.

This patch thus defines a policy that the QEMU project will currently
not accept contributions where use of AI code generators is either
known, or suspected.

These are early days of AI-assisted software development. The legal
questions will be resolved eventually. The tools will mature, and we
can expect some to become safely usable in free software projects.
The policy we set now must be for today, and be open to revision. It's
best to start strict and safe, then relax.

Meanwhile requests for exceptions can also be considered on a case by
case basis.

Signed-off-by: Daniel P. Berrangé <berra...@redhat.com>
Reviewed-by: Kevin Wolf <kw...@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefa...@redhat.com>
Reviewed-by: Alex Bennée <alex.ben...@linaro.org>
Signed-off-by: Markus Armbruster <arm...@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefa...@redhat.com>


  Commit: 24c00b754121f3569ea9e68f5f188747cf5b8439
      
https://github.com/qemu/qemu/commit/24c00b754121f3569ea9e68f5f188747cf5b8439
  Author: Stefan Hajnoczi <stefa...@redhat.com>
  Date:   2025-06-24 (Tue, 24 Jun 2025)

  Changed paths:
    M MAINTAINERS
    M accel/kvm/kvm-all.c
    M hw/virtio/virtio-mem.c
    M include/system/memory.h
    M include/system/ramblock.h
    M migration/cpr-transfer.c
    M migration/ram.c
    M system/memory.c
    M system/meson.build
    M system/physmem.c
    A system/ram-block-attributes.c
    M system/trace-events
    R tests/qtest/migration-helpers.c
    M tests/qtest/migration/cpr-tests.c
    M ui/vnc.c
    M ui/vnc.h

  Log Message:
  -----------
  Merge tag 'migration-staging-pull-request' of https://gitlab.com/peterx/qemu 
into staging

Migration / Memory pull

- Yanfei's optimization to skip log_clear during completion
- Fabiano's cleanup to remove leftover migration-helpers.c file
- Juraj's vnc fix on display pause after migration
- Jaehoon's cpr test fix on possible race of server establishment
- Chenyi's initial support on vfio enablement for guest-memfd

# -----BEGIN PGP SIGNATURE-----
#
# iIgEABYKADAWIQS5GE3CDMRX2s990ak7X8zN86vXBgUCaFmzWhIccGV0ZXJ4QHJl
# ZGhhdC5jb20ACgkQO1/MzfOr1wbWYQD/dz08tyaL2J4EHESfBsW4Z1rEggVOM0cB
# hlXnvzf/Pb4A/0X3Hn18bOxfPAZOr8NggS5AKgzCCYVeQEWQA2Jj8hwC
# =kcTN
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 23 Jun 2025 16:04:42 EDT
# gpg:                using EDDSA key B9184DC20CC457DACF7DD1A93B5FCCCDF3ABD706
# gpg:                issuer "pet...@redhat.com"
# gpg: Good signature from "Peter Xu <xzpe...@gmail.com>" [full]
# gpg:                 aka "Peter Xu <pet...@redhat.com>" [full]
# Primary key fingerprint: B918 4DC2 0CC4 57DA CF7D  D1A9 3B5F CCCD F3AB D706

* tag 'migration-staging-pull-request' of https://gitlab.com/peterx/qemu:
  physmem: Support coordinated discarding of RAM with guest_memfd
  ram-block-attributes: Introduce RamBlockAttributes to manage RAMBlock with 
guest_memfd
  memory: Unify the definiton of ReplayRamPopulate() and ReplayRamDiscard()
  memory: Change memory_region_set_ram_discard_manager() to return the result
  memory: Export a helper to get intersection of a MemoryRegionSection with a 
given range
  migration: Don't sync volatile memory after migration completes
  tests/migration: Setup pre-listened cpr.sock to remove race-condition.
  migration: Support fd-based socket address in cpr_transfer_input
  ui/vnc: Update display update interval when VM state changes to RUNNING
  tests/qtest: Remove migration-helpers.c
  migration/ram: avoid to do log clear in the last round

Signed-off-by: Stefan Hajnoczi <stefa...@redhat.com>


  Commit: f9a3def17b2a57679902c33064cf7853263db0ef
      
https://github.com/qemu/qemu/commit/f9a3def17b2a57679902c33064cf7853263db0ef
  Author: Stefan Hajnoczi <stefa...@redhat.com>
  Date:   2025-06-24 (Tue, 24 Jun 2025)

  Changed paths:
    M include/tcg/tcg-op-gvec-common.h
    M linux-user/elfload.c
    M linux-user/gen-vdso.c
    M tcg/tcg-op-gvec.c

  Log Message:
  -----------
  Merge tag 'pull-tcg-20250623' of https://gitlab.com/rth7680/qemu into staging

linux-user: fix resource leaks in gen-vdso
tcg: Add ptr+ofs alternatives to some gvec functions

# -----BEGIN PGP SIGNATURE-----
#
# iQFRBAABCgA7FiEEekgeeIaLTbaoWgXAZN846K9+IV8FAmhZ/LMdHHJpY2hhcmQu
# aGVuZGVyc29uQGxpbmFyby5vcmcACgkQZN846K9+IV8aCggAtZOamQ0+EMe09u9d
# slaeZDlmxHYfb4RXJQasIBi/uHoWY1bFCEWqLnjU41cpNqI7B3yihbS/YQzyI1i/
# fqjATmuhDzer7rZfdtmRdiLi6kY9SuN9tcSVMVU/kxixByPxdYspQBO8hAAQMM1X
# ZY5MIR/5nEMN/U0QUMuqd3krsxzglGQl9Dn610ddVGfzluSCKLLMS/m92gaJmz0u
# xoLTM29lfdtIA29JPpVY+1X8NJ/vTUeBvy2eXUGHjT11rHsYUzMVGCGbzCLluEzN
# V3L/aSkiwrV+wW5M7R6+hySQl65ZVRV+E9BHuln9aDnG4jdzT3conohg2cY9a5jw
# m3HqnQ==
# =U6ub
# -----END PGP SIGNATURE-----
# gpg: Signature made Mon 23 Jun 2025 21:17:39 EDT
# gpg:                using RSA key 7A481E78868B4DB6A85A05C064DF38E8AF7E215F
# gpg:                issuer "richard.hender...@linaro.org"
# gpg: Good signature from "Richard Henderson <richard.hender...@linaro.org>" 
[full]
# Primary key fingerprint: 7A48 1E78 868B 4DB6 A85A  05C0 64DF 38E8 AF7E 215F

* tag 'pull-tcg-20250623' of https://gitlab.com/rth7680/qemu:
  linux-user: fix resource leaks in gen-vdso
  linux-user/aarch64: Update hwcap bits from 6.14
  tcg: Split out tcg_gen_gvec_dup_imm_var
  tcg: Split out tcg_gen_gvec_{add,sub}_var
  tcg: Split out tcg_gen_gvec_mov_var
  tcg: Split out tcg_gen_gvec_3_var
  tcg: Split out tcg_gen_gvec_2_var
  tcg: Add base arguments to check_overlap_[234]
  tcg: Add dbase argument to expand_clr
  tcg: Add dbase argument to do_dup
  tcg: Add dbase argument to do_dup_store

Signed-off-by: Stefan Hajnoczi <stefa...@redhat.com>


Compare: https://github.com/qemu/qemu/compare/d01d42ccc951...f9a3def17b2a

To unsubscribe from these emails, change your notification settings at 
https://github.com/qemu/qemu/settings/notifications

Reply via email to