* Tue Nov 25 2025 Miroslav Rezanina <mrezanin@redhat.com> - 10.1.0-6

- kvm-ram-block-attributes-fix-interaction-with-hugetlb-me.patch [RHEL-126708] - kvm-ram-block-attributes-Unify-the-retrieval-of-the-bloc.patch [RHEL-126708] - kvm-hw-s390x-Fix-a-possible-crash-with-passed-through-vi.patch [RHEL-128085] - kvm-Fix-the-typo-of-vfio-pci-device-s-enable-migration-o.patch [RHEL-130704] - Resolves: RHEL-126708 ([RHEL 10]snp guest fail to boot with hugepage) - Resolves: RHEL-128085 (VM crashes during boot when virtio device is attached through vfio_ccw) - Resolves: RHEL-130704 ([rhel10] Fix the typo under vfio-pci device's enable-migration option )
2025-11-25 13:32:52 +01:00 · 2025-11-25 13:32:52 +01:00 · bcf03884b2
commit bcf03884b2
parent 321b8a8d36
5 changed files with 313 additions and 1 deletions
--- a/kvm-Fix-the-typo-of-vfio-pci-device-s-enable-migration-o.patch
+++ b/kvm-Fix-the-typo-of-vfio-pci-device-s-enable-migration-o.patch
@ -0,0 +1,37 @@
+From 0509eb94d2f166cfd3a24aa5fd14e1af76af8dea Mon Sep 17 00:00:00 2001
+From: Yanghang Liu <yanghliu@redhat.com>
+Date: Mon, 24 Nov 2025 23:02:37 +0800
+Subject: [PATCH 4/4] Fix the typo of vfio-pci device's enable-migration option
+
+RH-Author: YangHang Liu <None>
+RH-MergeRequest: 428: RHEL10: Fix the typo of vfio-pci device's enable-migration option
+RH-Jira: RHEL-130704
+RH-Acked-by: Miroslav Rezanina <mrezanin@redhat.com>
+RH-Commit: [1/1] bcf8b2089f687d02b5f0a48dd1e3dfc4664946e0 (yanghliu/qemu-kvm)
+
+Signed-off-by: Yanghang Liu <yanghliu@redhat.com>
+Reported-by: Mario Casquero <mcasquer@redhat.com>
+Reviewed-by: Michael Tokarev <mjt@tls.msk.ru>
+Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
+(cherry picked from commit 5f9ac963735598c1efbdce9c4a09f0a64e13d613)
+Signed-off-by: Yanghang Liu <yanghliu@redhat.com>
+---
+ hw/vfio/pci.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
+index 83ecffb535..7c057ee2f9 100644
+--- a/hw/vfio/pci.c
+++ b/hw/vfio/pci.c
+@@ -3847,7 +3847,7 @@ static void vfio_pci_dev_class_init(ObjectClass *klass, const void *data)
+                                           "(DEBUG)");
+     object_class_property_set_description(klass, /* 5.2, 8.0 non-experimetal */
+                                           "enable-migration",
+-                                          "Enale device migration. Also requires a host VFIO PCI "
+                                          "Enable device migration. Also requires a host VFIO PCI "
+                                           "variant or mdev driver with migration support enabled");
+     object_class_property_set_description(klass, /* 8.1 */
+                                           "vf-token",
+-- 
+2.47.3
+
--- a/kvm-hw-s390x-Fix-a-possible-crash-with-passed-through-vi.patch
+++ b/kvm-hw-s390x-Fix-a-possible-crash-with-passed-through-vi.patch
@ -0,0 +1,83 @@
+From f607a40a84b80b2cb33ef3bb42b60b84af596cc9 Mon Sep 17 00:00:00 2001
+From: Thomas Huth <thuth@redhat.com>
+Date: Tue, 18 Nov 2025 18:40:47 +0100
+Subject: [PATCH 3/4] hw/s390x: Fix a possible crash with passed-through virtio
+ devices
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+RH-Author: Thomas Huth <thuth@redhat.com>
+RH-MergeRequest: 427: s390x: Fix a possible crash with passed-through virtio devices
+RH-Jira: RHEL-128085
+RH-Acked-by: Cornelia Huck <cohuck@redhat.com>
+RH-Acked-by: Cédric Le Goater <clg@redhat.com>
+RH-Commit: [1/1] a368a65a46a8d85f7ae83cfb5af23b1a341ea9d4 (thuth/qemu-kvm-cs)
+
+JIRA: https://issues.redhat.com/browse/RHEL-128085
+
+Consider the following nested setup: An L1 host uses some virtio device
+(e.g. virtio-keyboard) for the L2 guest, and this L2 guest passes this
+device through to the L3 guest. Since the L3 guest sees a virtio device,
+it might send virtio notifications to the QEMU in L2 for that device.
+But since the QEMU in L2 defined this device as vfio-ccw, the function
+handle_virtio_ccw_notify() cannot handle this and crashes: It calls
+virtio_ccw_get_vdev() that casts sch->driver_data into a VirtioCcwDevice,
+but since "sch" belongs to a vfio-ccw device, that driver_data rather
+points to a CcwDevice instead. So as soon as QEMU tries to use some
+VirtioCcwDevice specific data from that device, we've lost.
+
+We must not take virtio notifications for such devices. Thus fix the
+issue by adding a check to the handle_virtio_ccw_notify() handler to
+refuse all devices that are not our own virtio devices. Like in the
+other branches that detect wrong settings, we return -EINVAL from the
+function, which will later be placed in GPR2 to inform the guest about
+the error.
+
+Reviewed-by: Halil Pasic <pasic@linux.ibm.com>
+Reviewed-by: Eric Farman <farman@linux.ibm.com>
+Tested-by: Eric Farman <farman@linux.ibm.com>
+Reviewed-by: Cornelia Huck <cohuck@redhat.com>
+Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com>
+Signed-off-by: Thomas Huth <thuth@redhat.com>
+Message-ID: <20251118174047.73103-1-thuth@redhat.com>
+(cherry picked from commit e5cb62e7b6f99d45a42f0cd358d76d6ee2cef5cd)
+---
+ hw/s390x/s390-hypercall.c | 14 ++++++++++++++
+ 1 file changed, 14 insertions(+)
+
+diff --git a/hw/s390x/s390-hypercall.c b/hw/s390x/s390-hypercall.c
+index ac1b08b2cd..508dd97ca0 100644
+--- a/hw/s390x/s390-hypercall.c
+++ b/hw/s390x/s390-hypercall.c
+@@ -10,6 +10,7 @@
+  */
+ 
+ #include "qemu/osdep.h"
+#include "qemu/error-report.h"
+ #include "cpu.h"
+ #include "hw/s390x/s390-virtio-ccw.h"
+ #include "hw/s390x/s390-hypercall.h"
+@@ -42,6 +43,19 @@ static int handle_virtio_ccw_notify(uint64_t subch_id, uint64_t data)
+     if (!sch || !css_subch_visible(sch)) {
+         return -EINVAL;
+     }
+    if (sch->id.cu_type != VIRTIO_CCW_CU_TYPE) {
+        /*
+         * This might happen in nested setups: If the L1 host defined the
+         * L2 guest with a virtio device (e.g. virtio-keyboard), and the
+         * L2 guest passes this device through to the L3 guest, the L3 guest
+         * might send virtio notifications to the QEMU in L2 for that device.
+         * But since the QEMU in L2 defined this device as vfio-ccw, it's not
+         * a VirtIODevice that we can handle here!
+         */
+        warn_report_once("Got virtio notification for unsupported device "
+                         "on subchannel %02x.%1x.%04x!", cssid, ssid, schid);
+        return -EINVAL;
+    }
+ 
+     vdev = virtio_ccw_get_vdev(sch);
+     if (vq_idx >= VIRTIO_QUEUE_MAX || !virtio_queue_get_num(vdev, vq_idx)) {
+-- 
+2.47.3
+
--- a/kvm-ram-block-attributes-Unify-the-retrieval-of-the-bloc.patch
+++ b/kvm-ram-block-attributes-Unify-the-retrieval-of-the-bloc.patch
@ -0,0 +1,47 @@
+From 0e0b1ba11faad72338036b9dfa97a3a8a8bc56dc Mon Sep 17 00:00:00 2001
+From: Paolo Bonzini <pbonzini@redhat.com>
+Date: Wed, 19 Nov 2025 12:51:32 +0100
+Subject: [PATCH 2/4] ram-block-attributes: Unify the retrieval of the block
+ size
+
+RH-Author: Paolo Bonzini <pbonzini@redhat.com>
+RH-MergeRequest: 426: Fix hugetlb memory backends in confidential VMs
+RH-Jira: RHEL-126708
+RH-Acked-by: Bandan Das <bdas@redhat.com>
+RH-Acked-by: Eric Blake <eblake@redhat.com>
+RH-Acked-by: Peter Xu <peterx@redhat.com>
+RH-Commit: [2/2] 0d6f2045a97f04348c4d07ef331e42f47eaba160 (bonzini/qemu-kvm-centos)
+
+JIRA: https://issues.redhat.com/browse/RHEL-126708
+
+There's an existing helper function designed to obtain the block size.
+Modify ram_block_attribute_create() to use this function for
+consistency.
+
+Tested-by: Farrah Chen <farrah.chen@intel.com>
+Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com>
+Link: https://lore.kernel.org/r/20251023095526.48365-3-chenyi.qiang@intel.com
+[peterx: fix double spaces, per david]
+Signed-off-by: Peter Xu <peterx@redhat.com>
+(cherry picked from commit b2ceb87b1a210d91a29d525590eb164d1121b8a1)
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+---
+ system/ram-block-attributes.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/system/ram-block-attributes.c b/system/ram-block-attributes.c
+index a7579de5b4..fb7c5c2746 100644
+--- a/system/ram-block-attributes.c
+++ b/system/ram-block-attributes.c
+@@ -390,7 +390,7 @@ int ram_block_attributes_state_change(RamBlockAttributes *attr,
+ 
+ RamBlockAttributes *ram_block_attributes_create(RAMBlock *ram_block)
+ {
+-    const int block_size  = qemu_real_host_page_size();
+    const int block_size = ram_block_attributes_get_block_size();
+     RamBlockAttributes *attr;
+     MemoryRegion *mr = ram_block->mr;
+ 
+-- 
+2.47.3
+
--- a/kvm-ram-block-attributes-fix-interaction-with-hugetlb-me.patch
+++ b/kvm-ram-block-attributes-fix-interaction-with-hugetlb-me.patch
@ -0,0 +1,125 @@
+From 6b03dd00ce169886ec7aa866c14daa99209a3137 Mon Sep 17 00:00:00 2001
+From: Paolo Bonzini <pbonzini@redhat.com>
+Date: Wed, 19 Nov 2025 12:51:32 +0100
+Subject: [PATCH 1/4] ram-block-attributes: fix interaction with hugetlb memory
+ backends
+
+RH-Author: Paolo Bonzini <pbonzini@redhat.com>
+RH-MergeRequest: 426: Fix hugetlb memory backends in confidential VMs
+RH-Jira: RHEL-126708
+RH-Acked-by: Bandan Das <bdas@redhat.com>
+RH-Acked-by: Eric Blake <eblake@redhat.com>
+RH-Acked-by: Peter Xu <peterx@redhat.com>
+RH-Commit: [1/2] 050a6c78989db4ba3111fb903647270c7ab12e53 (bonzini/qemu-kvm-centos)
+
+JIRA: https://issues.redhat.com/browse/RHEL-126708
+
+Currently, CoCo VMs can perform conversion at the base page granularity,
+which is the granularity that has to be tracked. In relevant setups, the
+target page size is assumed to be equal to the host page size, thus
+fixing the block size to the host page size.
+
+However, since private memory and shared memory have different backend
+at present, users can specify shared memory with a hugetlbfs backend
+while private memory with guest_memfd backend only supports 4K page
+size. In this scenario, ram_block->page_size is different from the host
+page size which will trigger an assertion when retrieving the block
+size.
+
+To address this, return the host page size directly to relax the
+restriction. This changes fixes a regression of using hugetlbfs backend
+for shared memory within CoCo VMs, with or without VFIO devices' presence.
+
+Acked-by: David Hildenbrand <david@redhat.com>
+Tested-by: Farrah Chen <farrah.chen@intel.com>
+Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com>
+Link: https://lore.kernel.org/r/20251023095526.48365-2-chenyi.qiang@intel.com
+[peterx: fix subject, per david]
+Cc: qemu-stable <qemu-stable@nongnu.org>
+Signed-off-by: Peter Xu <peterx@redhat.com>
+(cherry picked from commit 8922a758b29251d9009ec509e7f580b76509ab3d)
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+---
+ system/ram-block-attributes.c | 18 ++++++++----------
+ 1 file changed, 8 insertions(+), 10 deletions(-)
+
+diff --git a/system/ram-block-attributes.c b/system/ram-block-attributes.c
+index 68e8a02703..a7579de5b4 100644
+--- a/system/ram-block-attributes.c
+++ b/system/ram-block-attributes.c
+@@ -22,16 +22,14 @@ OBJECT_DEFINE_SIMPLE_TYPE_WITH_INTERFACES(RamBlockAttributes,
+                                           { })
+ 
+ static size_t
+-ram_block_attributes_get_block_size(const RamBlockAttributes *attr)
+ram_block_attributes_get_block_size(void)
+ {
+     /*
+      * Because page conversion could be manipulated in the size of at least 4K
+      * or 4K aligned, Use the host page size as the granularity to track the
+      * memory attribute.
+      */
+-    g_assert(attr && attr->ram_block);
+-    g_assert(attr->ram_block->page_size == qemu_real_host_page_size());
+-    return attr->ram_block->page_size;
+    return qemu_real_host_page_size();
+ }
+ 
+ 
+@@ -40,7 +38,7 @@ ram_block_attributes_rdm_is_populated(const RamDiscardManager *rdm,
+                                       const MemoryRegionSection *section)
+ {
+     const RamBlockAttributes *attr = RAM_BLOCK_ATTRIBUTES(rdm);
+-    const size_t block_size = ram_block_attributes_get_block_size(attr);
+    const size_t block_size = ram_block_attributes_get_block_size();
+     const uint64_t first_bit = section->offset_within_region / block_size;
+     const uint64_t last_bit =
+         first_bit + int128_get64(section->size) / block_size - 1;
+@@ -81,7 +79,7 @@ ram_block_attributes_for_each_populated_section(const RamBlockAttributes *attr,
+ {
+     unsigned long first_bit, last_bit;
+     uint64_t offset, size;
+-    const size_t block_size = ram_block_attributes_get_block_size(attr);
+    const size_t block_size = ram_block_attributes_get_block_size();
+     int ret = 0;
+ 
+     first_bit = section->offset_within_region / block_size;
+@@ -122,7 +120,7 @@ ram_block_attributes_for_each_discarded_section(const RamBlockAttributes *attr,
+ {
+     unsigned long first_bit, last_bit;
+     uint64_t offset, size;
+-    const size_t block_size = ram_block_attributes_get_block_size(attr);
+    const size_t block_size = ram_block_attributes_get_block_size();
+     int ret = 0;
+ 
+     first_bit = section->offset_within_region / block_size;
+@@ -163,7 +161,7 @@ ram_block_attributes_rdm_get_min_granularity(const RamDiscardManager *rdm,
+     const RamBlockAttributes *attr = RAM_BLOCK_ATTRIBUTES(rdm);
+ 
+     g_assert(mr == attr->ram_block->mr);
+-    return ram_block_attributes_get_block_size(attr);
+    return ram_block_attributes_get_block_size();
+ }
+ 
+ static void
+@@ -265,7 +263,7 @@ ram_block_attributes_is_valid_range(RamBlockAttributes *attr, uint64_t offset,
+     g_assert(mr);
+ 
+     uint64_t region_size = memory_region_size(mr);
+-    const size_t block_size = ram_block_attributes_get_block_size(attr);
+    const size_t block_size = ram_block_attributes_get_block_size();
+ 
+     if (!QEMU_IS_ALIGNED(offset, block_size) ||
+         !QEMU_IS_ALIGNED(size, block_size)) {
+@@ -322,7 +320,7 @@ int ram_block_attributes_state_change(RamBlockAttributes *attr,
+                                       uint64_t offset, uint64_t size,
+                                       bool to_discard)
+ {
+-    const size_t block_size = ram_block_attributes_get_block_size(attr);
+    const size_t block_size = ram_block_attributes_get_block_size();
+     const unsigned long first_bit = offset / block_size;
+     const unsigned long nbits = size / block_size;
+     const unsigned long last_bit = first_bit + nbits - 1;
+-- 
+2.47.3
+
--- a/qemu-kvm.spec
+++ b/qemu-kvm.spec
@ -143,7 +143,7 @@ Obsoletes: %{name}-block-ssh <= %{epoch}:%{version}                    \
 Summary: QEMU is a machine emulator and virtualizer
 Name: qemu-kvm
 Version: 10.1.0
-Release: 5%{?rcrel}%{?dist}%{?cc_suffix}
+Release: 6%{?rcrel}%{?dist}%{?cc_suffix}
 # Epoch because we pushed a qemu-1.0 package. AIUI this can't ever be dropped
 # Epoch 15 used for RHEL 8
 # Epoch 17 used for RHEL 9 (due to release versioning offset in RHEL 8.5)
@ -257,6 +257,14 @@ Patch50: kvm-qtest-bios-tables-test-Add-tests-for-legacy-smmuv3-a.patch
 # For RHEL-73800 - NVIDIA:Grace-Hopper:Backport support for user-creatable nested SMMUv3 - RHEL 10.1
 Patch51: kvm-qtest-bios-tables-test-Update-tables-for-smmuv3-test.patch
 Patch52: kvm-qtest-Do-not-run-bios-tables-test-on-aarch64.patch
+# For RHEL-126708 - [RHEL 10]snp guest fail to boot with hugepage
+Patch53: kvm-ram-block-attributes-fix-interaction-with-hugetlb-me.patch
+# For RHEL-126708 - [RHEL 10]snp guest fail to boot with hugepage
+Patch54: kvm-ram-block-attributes-Unify-the-retrieval-of-the-bloc.patch
+# For RHEL-128085 - VM crashes during boot when virtio device is attached through vfio_ccw
+Patch55: kvm-hw-s390x-Fix-a-possible-crash-with-passed-through-vi.patch
+# For RHEL-130704 - [rhel10] Fix the typo under vfio-pci device's enable-migration option 
+Patch56: kvm-Fix-the-typo-of-vfio-pci-device-s-enable-migration-o.patch

 %if %{have_clang}
 BuildRequires: clang
@ -1336,6 +1344,18 @@ useradd -r -u 107 -g qemu -G kvm -d / -s /sbin/nologin \
 %endif

 %changelog
+* Tue Nov 25 2025 Miroslav Rezanina <mrezanin@redhat.com> - 10.1.0-6
+- kvm-ram-block-attributes-fix-interaction-with-hugetlb-me.patch [RHEL-126708]
+- kvm-ram-block-attributes-Unify-the-retrieval-of-the-bloc.patch [RHEL-126708]
+- kvm-hw-s390x-Fix-a-possible-crash-with-passed-through-vi.patch [RHEL-128085]
+- kvm-Fix-the-typo-of-vfio-pci-device-s-enable-migration-o.patch [RHEL-130704]
+- Resolves: RHEL-126708
+  ([RHEL 10]snp guest fail to boot with hugepage)
+- Resolves: RHEL-128085
+  (VM crashes during boot when virtio device is attached through vfio_ccw)
+- Resolves: RHEL-130704
+  ([rhel10] Fix the typo under vfio-pci device's enable-migration option )
+
 * Fri Nov 14 2025 Miroslav Rezanina <mrezanin@redhat.com> - 10.1.0-5
 - kvm-io-move-websock-resource-release-to-close-method.patch [RHEL-120116]
 - kvm-io-fix-use-after-free-in-websocket-handshake-code.patch [RHEL-120116]