diff --git 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 new file mode 100644 index 0000000..2416ca0 --- /dev/null +++ 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 +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 +RH-MergeRequest: 428: RHEL10: Fix the typo of vfio-pci device's enable-migration option +RH-Jira: RHEL-130704 +RH-Acked-by: Miroslav Rezanina +RH-Commit: [1/1] bcf8b2089f687d02b5f0a48dd1e3dfc4664946e0 (yanghliu/qemu-kvm) + +Signed-off-by: Yanghang Liu +Reported-by: Mario Casquero +Reviewed-by: Michael Tokarev +Signed-off-by: Michael Tokarev +(cherry picked from commit 5f9ac963735598c1efbdce9c4a09f0a64e13d613) +Signed-off-by: Yanghang Liu +--- + 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 + diff --git 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 new file mode 100644 index 0000000..709d857 --- /dev/null +++ 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 +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 +RH-MergeRequest: 427: s390x: Fix a possible crash with passed-through virtio devices +RH-Jira: RHEL-128085 +RH-Acked-by: Cornelia Huck +RH-Acked-by: Cédric Le Goater +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 +Reviewed-by: Eric Farman +Tested-by: Eric Farman +Reviewed-by: Cornelia Huck +Acked-by: Christian Borntraeger +Signed-off-by: Thomas Huth +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 + diff --git a/kvm-ram-block-attributes-Unify-the-retrieval-of-the-bloc.patch b/kvm-ram-block-attributes-Unify-the-retrieval-of-the-bloc.patch new file mode 100644 index 0000000..87c0288 --- /dev/null +++ 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 +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 +RH-MergeRequest: 426: Fix hugetlb memory backends in confidential VMs +RH-Jira: RHEL-126708 +RH-Acked-by: Bandan Das +RH-Acked-by: Eric Blake +RH-Acked-by: Peter Xu +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 +Signed-off-by: Chenyi Qiang +Link: https://lore.kernel.org/r/20251023095526.48365-3-chenyi.qiang@intel.com +[peterx: fix double spaces, per david] +Signed-off-by: Peter Xu +(cherry picked from commit b2ceb87b1a210d91a29d525590eb164d1121b8a1) +Signed-off-by: Paolo Bonzini +--- + 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 + diff --git a/kvm-ram-block-attributes-fix-interaction-with-hugetlb-me.patch b/kvm-ram-block-attributes-fix-interaction-with-hugetlb-me.patch new file mode 100644 index 0000000..5e5f04d --- /dev/null +++ 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 +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 +RH-MergeRequest: 426: Fix hugetlb memory backends in confidential VMs +RH-Jira: RHEL-126708 +RH-Acked-by: Bandan Das +RH-Acked-by: Eric Blake +RH-Acked-by: Peter Xu +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 +Tested-by: Farrah Chen +Signed-off-by: Chenyi Qiang +Link: https://lore.kernel.org/r/20251023095526.48365-2-chenyi.qiang@intel.com +[peterx: fix subject, per david] +Cc: qemu-stable +Signed-off-by: Peter Xu +(cherry picked from commit 8922a758b29251d9009ec509e7f580b76509ab3d) +Signed-off-by: Paolo Bonzini +--- + 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 + diff --git a/qemu-kvm.spec b/qemu-kvm.spec index 9b96db7..508e984 100644 --- 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 - 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 - 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]