diff --git a/libvirt-Set-stubDriverName-from-hostdev-driver-model-attribute-during-pci-device-setup.patch b/libvirt-Set-stubDriverName-from-hostdev-driver-model-attribute-during-pci-device-setup.patch new file mode 100644 index 0000000..d3902f1 --- /dev/null +++ b/libvirt-Set-stubDriverName-from-hostdev-driver-model-attribute-during-pci-device-setup.patch @@ -0,0 +1,44 @@ +From 676946491ea25cacc4f6fd11f27bd9989b84767d Mon Sep 17 00:00:00 2001 +Message-ID: <676946491ea25cacc4f6fd11f27bd9989b84767d.1708614745.git.jdenemar@redhat.com> +From: Laine Stump +Date: Fri, 16 Feb 2024 12:43:59 -0500 +Subject: [PATCH] Set stubDriverName from hostdev driver model attribute during + pci device setup + +commit v9.10.0-129-g8b93d78c83 (first appearing in libvirt-10.0.0) was +supposed to allow forcing a PCI hostdev to be bound to a particular +driver by adding to the XML for the +device. Unfortunately, a single line was missed during the final +changes to the patch prior to pushing, and the result was that the +driver model could be set to *anything* and it would be accepted but +just ignored. + +This patch adds the missing line, which will set the stubDriverName +field of the virPCIDevice object from the hostdev object as the +virPCIDevice is being created. This ends up being used by +virPCIDeviceBindToStub() as the driver that it binds the device to. + +Fixes: 8b93d78c8325f1fba5db98848350f3db43f5e7d5 +Signed-off-by: Laine Stump +Reviewed-by: Reviewed-by: Michal Privoznik +(cherry picked from commit 41fe8524870facae02be067097ea494c475d77f0) + +https://issues.redhat.com/browse/RHEL-25858 [9.4.0] +--- + src/hypervisor/virhostdev.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/src/hypervisor/virhostdev.c b/src/hypervisor/virhostdev.c +index 40f8a4bc2c..185ec2ca50 100644 +--- a/src/hypervisor/virhostdev.c ++++ b/src/hypervisor/virhostdev.c +@@ -242,6 +242,7 @@ virHostdevGetPCIHostDevice(const virDomainHostdevDef *hostdev, + return -1; + + virPCIDeviceSetManaged(actual, hostdev->managed); ++ virPCIDeviceSetStubDriverName(actual, pcisrc->driver.model); + + if (pcisrc->driver.name == VIR_DEVICE_HOSTDEV_PCI_DRIVER_NAME_VFIO) { + virPCIDeviceSetStubDriverType(actual, VIR_PCI_STUB_DRIVER_VFIO); +-- +2.43.2 diff --git a/libvirt-domain_validate-Account-for-NVDIMM-label-size-properly-when-checking-for-memory-conflicts.patch b/libvirt-domain_validate-Account-for-NVDIMM-label-size-properly-when-checking-for-memory-conflicts.patch new file mode 100644 index 0000000..0cf71d0 --- /dev/null +++ b/libvirt-domain_validate-Account-for-NVDIMM-label-size-properly-when-checking-for-memory-conflicts.patch @@ -0,0 +1,123 @@ +From 8d48d5fe02c0afcf5bbe68e0a182ee11f9a108dc Mon Sep 17 00:00:00 2001 +Message-ID: <8d48d5fe02c0afcf5bbe68e0a182ee11f9a108dc.1708614745.git.jdenemar@redhat.com> +From: Michal Privoznik +Date: Mon, 19 Feb 2024 15:37:16 +0100 +Subject: [PATCH] domain_validate: Account for NVDIMM label size properly when + checking for memory conflicts + +As of v9.8.0-rc1~7 we check whether two devices don't +overlap (since we allow setting where a device should +be mapped to). We do this pretty straightforward, by comparing +start and end address of each device combination. +But since only the start address is given (an exposed in the +XML), the end address is computed trivially as: + + start + mem->size * 1024 + +And for majority of memory device types this works. Except for +NVDIMMs. For them the device consists of two separate +regions: 1) actual memory device, and 2) label. + +Label is where NVDIMM stores some additional information like +namespaces partition and so on. But it's not mapped into the +guest the same way as actual memory device. In fact, mem->size is +a sum of both actual memory device and label sizes. And to make +things a bit worse, both sizes are subject to alignment (either +the alignsize value specified in XML, or system page size if not +specified in XML). + +Therefore, to get the size of actual memory device we need to +take mem->size and substract label size rounded up to alignment. + +If we don't do this we report there's an overlap between two +NVDIMMs even when in reality there's none. + +Fixes: 3fd64fb0e236fc80ffa2cc977c0d471f11fc39bf +Fixes: 91f9a9fb4fc0d34ed8d7a869de3d9f87687c3618 +Resolves: https://issues.redhat.com/browse/RHEL-4452?focusedId=23805174#comment-23805174 +Signed-off-by: Michal Privoznik +Reviewed-by: Martin Kletzander +(cherry picked from commit 4545f313c23e7000451d1cec793ebc8da1a2c25f) +Signed-off-by: Michal Privoznik +--- + src/conf/domain_validate.c | 51 ++++++++++++++++++++++++++++++++++++-- + 1 file changed, 49 insertions(+), 2 deletions(-) + +diff --git a/src/conf/domain_validate.c b/src/conf/domain_validate.c +index 46479f10f2..faa7659f07 100644 +--- a/src/conf/domain_validate.c ++++ b/src/conf/domain_validate.c +@@ -2225,6 +2225,53 @@ virDomainHostdevDefValidate(const virDomainHostdevDef *hostdev) + } + + ++/** ++ * virDomainMemoryGetMappedSize: ++ * @mem: memory device definition ++ * ++ * For given memory device definition (@mem) calculate size mapped into ++ * the guest. This is usually mem->size, except for NVDIMM where its ++ * label is mapped elsewhere. ++ * ++ * Returns: Number of bytes a memory device takes when mapped into a ++ * guest. ++ */ ++static unsigned long long ++virDomainMemoryGetMappedSize(const virDomainMemoryDef *mem) ++{ ++ unsigned long long ret = mem->size; ++ ++ if (mem->model == VIR_DOMAIN_MEMORY_MODEL_NVDIMM) { ++ unsigned long long alignsize = mem->source.nvdimm.alignsize; ++ unsigned long long labelsize = 0; ++ ++ /* For NVDIMM the situation is a bit more complicated. Firstly, ++ * its