Branch: refs/heads/staging-10.0
  Home:   https://github.com/qemu/qemu
  Commit: 21f86e29510a7d8f6daca523ef4d630854c70b4f
      
https://github.com/qemu/qemu/commit/21f86e29510a7d8f6daca523ef4d630854c70b4f
  Author: Huaitong Han <[email protected]>
  Date:   2025-06-02 (Mon, 02 Jun 2025)

  Changed paths:
    M hw/pci/pci.c
    M hw/virtio/virtio-pci.c
    M include/hw/pci/pci.h

  Log Message:
  -----------
  vhost: Don't set vring call if guest notifier is unused

The vring call fd is set even when the guest does not use MSI-X (e.g., in the
case of virtio PMD), leading to unnecessary CPU overhead for processing
interrupts.

The commit 96a3d98d2c("vhost: don't set vring call if no vector") optimized the
case where MSI-X is enabled but the queue vector is unset. However, there's an
additional case where the guest uses INTx and the INTx_DISABLED bit in the PCI
config is set, meaning that no interrupt notifier will actually be used.

In such cases, the vring call fd should also be cleared to avoid redundant
interrupt handling.

Fixes: 96a3d98d2c("vhost: don't set vring call if no vector")

Reported-by: Zhiyuan Yuan <[email protected]>
Signed-off-by: Jidong Xia <[email protected]>
Signed-off-by: Huaitong Han <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit a9403bfcd93025df7b1924d0cf34fbc408955b33)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 325d039d25f3626c0a52075e1d84e504f13e54c2
      
https://github.com/qemu/qemu/commit/325d039d25f3626c0a52075e1d84e504f13e54c2
  Author: Bernhard Beschow <[email protected]>
  Date:   2025-06-02 (Mon, 02 Jun 2025)

  Changed paths:
    M hw/i386/pc_piix.c

  Log Message:
  -----------
  hw/i386/pc_piix: Fix RTC ISA IRQ wiring of isapc machine

Commit 56b1f50e3c10 ("hw/i386/pc: Wire RTC ISA IRQs in south bridges")
attempted to refactor RTC IRQ wiring which was previously done in
pc_basic_device_init() but forgot about the isapc machine. Fix this by
wiring in the code section dedicated exclusively to the isapc machine.

Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2961
Fixes: 56b1f50e3c10 ("hw/i386/pc: Wire RTC ISA IRQs in south bridges")
cc: qemu-stable
Signed-off-by: Bernhard Beschow <[email protected]>
Reviewed-by: Mark Cave-Ayland <[email protected]>
Message-Id: <[email protected]>
Reviewed-by: Michael S. Tsirkin <[email protected]>
Signed-off-by: Michael S. Tsirkin <[email protected]>
(cherry picked from commit 0b006153b7ec66505cb2d231235aa19ca5d2ce37)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 8399ccb48041be54cec39b0c08494ea01ca84e4c
      
https://github.com/qemu/qemu/commit/8399ccb48041be54cec39b0c08494ea01ca84e4c
  Author: Sairaj Kodilkar <[email protected]>
  Date:   2025-06-02 (Mon, 02 Jun 2025)

  Changed paths:
    M hw/i386/amd_iommu.c

  Log Message:
  -----------
  hw/i386/amd_iommu: Fix device setup failure when PT is on.

Commit c1f46999ef506 ("amd_iommu: Add support for pass though mode")
introduces the support for "pt" flag by enabling nodma memory when
"pt=off". This allowed VFIO devices to successfully register notifiers
by using nodma region.

But, This also broke things when guest is booted with the iommu=nopt
because, devices bypass the IOMMU and use untranslated addresses (IOVA) to
perform DMA reads/writes to the nodma memory region, ultimately resulting in
a failure to setup the devices in the guest.

Fix the above issue by always enabling the amdvi_dev_as->iommu memory region.
But this will once again cause VFIO devices to fail while registering the
notifiers with AMD IOMMU memory region.

Fixes: c1f46999ef506 ("amd_iommu: Add support for pass though mode")
Signed-off-by: Sairaj Kodilkar <[email protected]>
Reviewed-by: Vasant Hegde <[email protected]>
Message-Id: <[email protected]>
Fixes: c1f46999ef506 ("amd_iommu: Add support for pass though mode")
Signed-off-by: Sairaj Kodilkar <[email protected]>
Reviewed-by: Vasant Hegde <[email protected]>
(cherry picked from commit 31753d5a336fbb4e9246397f4b90b6f611f27f22)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: c3e1181bafaecbcf9deae6a8bb4ad3586e221a3d
      
https://github.com/qemu/qemu/commit/c3e1181bafaecbcf9deae6a8bb4ad3586e221a3d
  Author: Vasant Hegde <[email protected]>
  Date:   2025-06-02 (Mon, 02 Jun 2025)

  Changed paths:
    M hw/i386/amd_iommu.c

  Log Message:
  -----------
  hw/i386/amd_iommu: Fix xtsup when vcpus < 255

If vCPUs > 255 then x86 common code (x86_cpus_init()) call kvm_enable_x2apic().
But if vCPUs <= 255 then the common code won't calls kvm_enable_x2apic().

This is because commit 8c6619f3e692 ("hw/i386/amd_iommu: Simplify non-KVM
checks on XTSup feature") removed the call to kvm_enable_x2apic when xtsup
is "on", which break things when guest is booted with x2apic mode and
there are <= 255 vCPUs.

Fix this by adding back kvm_enable_x2apic() call when xtsup=on.

Fixes: 8c6619f3e692 ("hw/i386/amd_iommu: Simplify non-KVM checks on XTSup 
feature")
Reported-by: Alejandro Jimenez <[email protected]>
Tested-by: Tested-by: Alejandro Jimenez <[email protected]>
Cc: Philippe Mathieu-Daudé <[email protected]>
Cc: Joao Martins <[email protected]>
Signed-off-by: Vasant Hegde <[email protected]>
Signed-off-by: Sairaj Kodilkar <[email protected]>
Message-Id: <[email protected]>
Fixes: 8c6619f3e692 ("hw/i386/amd_iommu: Simplify non-KVM checks on XTSup 
feature")
Reported-by: Alejandro Jimenez <[email protected]>
Tested-by: Tested-by: Alejandro Jimenez <[email protected]>
Cc: Philippe Mathieu-Daudé <[email protected]>
Cc: Joao Martins <[email protected]>
Signed-off-by: Vasant Hegde <[email protected]>
Signed-off-by: Sairaj Kodilkar <[email protected]>
(cherry picked from commit 0f178860df3489a9d3c19a5f7f024e6aa6c26515)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 47ddae806b9272959965f05b72187bdc933c7d96
      
https://github.com/qemu/qemu/commit/47ddae806b9272959965f05b72187bdc933c7d96
  Author: Volker Rümelin <[email protected]>
  Date:   2025-06-05 (Thu, 05 Jun 2025)

  Changed paths:
    M audio/audio.c

  Log Message:
  -----------
  audio: fix SIGSEGV in AUD_get_buffer_size_out()

As far as the emulated audio devices are concerned the pointer
returned by AUD_open_out() is an opaque handle. This includes
the NULL pointer. In this case, AUD_get_buffer_size_out() should
return a sensible buffer size instead of triggering a segmentation
fault. All other public AUD_*_out() and audio_*_out() functions
handle this case.

Reviewed-by: Marc-André Lureau <[email protected]>
Signed-off-by: Volker Rümelin <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit 5ddd6c8dc849b4af44bd06840c9133d64e62c27c)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 6b12cb6edc09fa28429e72af12517e45b6c7c734
      
https://github.com/qemu/qemu/commit/6b12cb6edc09fa28429e72af12517e45b6c7c734
  Author: Volker Rümelin <[email protected]>
  Date:   2025-06-05 (Thu, 05 Jun 2025)

  Changed paths:
    M audio/audio.c

  Log Message:
  -----------
  audio: fix size calculation in AUD_get_buffer_size_out()

The buffer size calculated by AUD_get_buffer_size_out() is often
incorrect. sw->hw->samples * sw->hw->info.bytes_per_frame is the
size of the mixing engine buffer in audio frames multiplied by
the size of one frame of the audio backend. Due to resampling or
format conversion, the size of the frontend buffer can differ
significantly.

Return the correct buffer size when the mixing engine is used.

Reviewed-by: Marc-André Lureau <[email protected]>
Signed-off-by: Volker Rümelin <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit ccb4fec0e5f233cb61a83b3af59ae11716ea06c0)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 92d08b3c0d19467e2bb6ea079aba82c1e6ead9f5
      
https://github.com/qemu/qemu/commit/92d08b3c0d19467e2bb6ea079aba82c1e6ead9f5
  Author: Volker Rümelin <[email protected]>
  Date:   2025-06-05 (Thu, 05 Jun 2025)

  Changed paths:
    M hw/audio/asc.c

  Log Message:
  -----------
  hw/audio/asc: fix SIGSEGV in asc_realize()

AUD_open_out() may fail and return NULL. This may then lead to
a segmentation fault in memset() below. The memset() behaviour
is undefined if the pointer to the destination object is a null
pointer.

Add the missing error handling code.

Reviewed-by: Marc-André Lureau <[email protected]>
Signed-off-by: Volker Rümelin <[email protected]>
Reviewed-by: Mark Cave-Ayland <[email protected]>
Message-Id: <[email protected]>
(cherry picked from commit d009f26a54f573468be721590a19350c224bc730)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: 9f80e4707cb05ab356c69ae8fde8537ef0b5810d
      
https://github.com/qemu/qemu/commit/9f80e4707cb05ab356c69ae8fde8537ef0b5810d
  Author: Xin Li (Intel) <[email protected]>
  Date:   2025-06-05 (Thu, 05 Jun 2025)

  Changed paths:
    M target/i386/cpu.c

  Log Message:
  -----------
  target/i386: Remove FRED dependency on WRMSRNS

WRMSRNS doesn't become a required feature for FERD, and Linux has
removed the dependency, as such remove it from Qemu.

Cc: [email protected]
Signed-off-by: Xin Li (Intel) <[email protected]>
Reviewed-by: Xiaoyao Li <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Paolo Bonzini <[email protected]>
(cherry picked from commit 0b901459a87a7fdbed36e574aae33e0635a3e9af)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: d8e6f3f885cc9e72a7c298bd7fb830b6f48051cf
      
https://github.com/qemu/qemu/commit/d8e6f3f885cc9e72a7c298bd7fb830b6f48051cf
  Author: Stefan Hajnoczi <[email protected]>
  Date:   2025-06-05 (Thu, 05 Jun 2025)

  Changed paths:
    M tests/qemu-iotests/240
    M tests/qemu-iotests/240.out

  Log Message:
  -----------
  iotests: fix 240

Commit 2e8e18c2e463 ("virtio-scsi: add iothread-vq-mapping parameter")
removed the limitation that virtio-scsi devices must successfully set
the AioContext on their BlockBackends. This was made possible thanks to
the QEMU multi-queue block layer.

This change broke qemu-iotests 240, which checks that adding a
virtio-scsi device with a drive that is already in another AioContext
will fail.

Update the test to take the relaxed behavior into account. I considered
removing this test case entirely, but the code coverage still seems
valuable.

Fixes: 2e8e18c2e463 ("virtio-scsi: add iothread-vq-mapping parameter")
Reported-by: Thomas Huth <[email protected]>
Signed-off-by: Stefan Hajnoczi <[email protected]>
Reviewed-by: Eric Blake <[email protected]>
Tested-by: Eric Blake <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit 2e887187454e57d04522099d4f04d17137d6e05c)
Signed-off-by: Michael Tokarev <[email protected]>


  Commit: ab96ea4b4d257919f5d0042eedcb1c3cfa1d0a0c
      
https://github.com/qemu/qemu/commit/ab96ea4b4d257919f5d0042eedcb1c3cfa1d0a0c
  Author: Fiona Ebner <[email protected]>
  Date:   2025-06-05 (Thu, 05 Jun 2025)

  Changed paths:
    M hw/core/qdev-properties-system.c

  Log Message:
  -----------
  hw/core/qdev-properties-system: Add missing return in set_drive_helper()

Currently, changing the 'drive' property of e.g. a scsi-hd object will
result in an assertion failure if the aio context of the block node
it's replaced with doesn't match the current aio context:

> bdrv_replace_child_noperm: Assertion `bdrv_get_aio_context(old_bs) ==
> bdrv_get_aio_context(new_bs)' failed.

The problematic scenario is already detected, but a 'return' statement
was missing.

Cc: [email protected]
Fixes: d1a58c176a ("qdev: allow setting drive property for realized device")
Signed-off-by: Fiona Ebner <[email protected]>
Message-ID: <[email protected]>
Reviewed-by: Daniel P. Berrangé <[email protected]>
Reviewed-by: Kevin Wolf <[email protected]>
Signed-off-by: Kevin Wolf <[email protected]>
(cherry picked from commit eef2dd03f948a512499775043bdc0c5c88d8a2dd)
Signed-off-by: Michael Tokarev <[email protected]>


Compare: https://github.com/qemu/qemu/compare/1702044371d3...ab96ea4b4d25

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

Reply via email to