rpms/qemu-kvm
7
0
Fork 0
Code Issues Pull Requests Releases Activity

* Tue Dec 03 2024 Miroslav Rezanina <mrezanin@redhat.com> - 9.1.0-7

Browse Source 
- kvm-virtio-net-Add-queues-before-loading-them.patch [RHEL-58316]
- kvm-docs-system-s390x-bootdevices-Update-loadparm-docume.patch [RHEL-68444]
- kvm-docs-system-bootindex-Make-it-clear-that-s390x-can-a.patch [RHEL-68444]
- kvm-hw-s390x-Restrict-loadparm-property-to-devices-that-.patch [RHEL-68444]
- kvm-hw-Add-loadparm-property-to-scsi-disk-devices-for-bo.patch [RHEL-68444]
- kvm-scsi-fix-allocation-for-s390x-loadparm.patch [RHEL-68444]
- kvm-pc-bios-s390x-Initialize-cdrom-type-to-false-for-eac.patch [RHEL-68444]
- kvm-pc-bios-s390x-Initialize-machine-loadparm-before-pro.patch [RHEL-68444]
- kvm-pc-bios-s390-ccw-Re-initialize-receive-queue-index-b.patch [RHEL-68444]
- Resolves: RHEL-58316
  (qemu crashed when migrate vm with multiqueue from rhel9.4 to rhel10.0)
- Resolves: RHEL-68444
  (The new "boot order" feature is sometimes not working as expected [RHEL 10])
This commit is contained in:
Miroslav Rezanina 2024-12-03 02:51:40 -05:00
parent d67258da44
commit 29ffd0e6d8
10 changed files with 734 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

41
kvm-docs-system-bootindex-Make-it-clear-that-s390x-can-a.patch Normal file
View File

@ -0,0 +1,41 @@
From ba9b7c8375aac784fbe23beaeb91484ddd8e6829 Mon Sep 17 00:00:00 2001
From: Thomas Huth <thuth@redhat.com>
Date: Mon, 11 Nov 2024 11:55:06 +0100
Subject: [PATCH 3/9] docs/system/bootindex: Make it clear that s390x can also
boot from virtio-net
RH-Author: Thomas Huth <thuth@redhat.com>
RH-MergeRequest: 297: [c10s] Fixes for the new s390x "boot order" feature
RH-Jira: RHEL-68444
RH-Acked-by: Miroslav Rezanina <mrezanin@redhat.com>
RH-Commit: [2/8] ae20c66e424d64840012b4725166a1bde2579cbc (thuth/qemu-kvm-cs9)
Let's make it clear that s390x can also boot from virtio-net, to avoid
that people think that s390x can only boot from disk devices.
Reported-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Message-ID: <20241111105506.264640-1-thuth@redhat.com>
Reviewed-by: Prasad Pandit <pjp@fedoraproject.org>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit b8c5fdc6588f82d95807be0eb2215d215a3ba16e)
---
docs/system/bootindex.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/docs/system/bootindex.rst b/docs/system/bootindex.rst
index 988f7b3beb..5e1b33ee22 100644
--- a/docs/system/bootindex.rst
+++ b/docs/system/bootindex.rst
@@ -53,7 +53,7 @@ booting. For instance, the x86 PC BIOS boot specification allows only one
disk to be bootable. If boot from disk fails for some reason, the x86 BIOS
won't retry booting from other disk. It can still try to boot from
floppy or net, though. In the case of s390x BIOS, the BIOS will try up to
-8 total devices, any number of which may be disks.
+8 total devices, any number of which may be disks or virtio-net devices.
Sometimes, firmware cannot map the device path QEMU wants firmware to
boot from to a boot method. It doesn't happen for devices the firmware
--
2.39.3

61
kvm-docs-system-s390x-bootdevices-Update-loadparm-docume.patch Normal file
View File

@ -0,0 +1,61 @@
From 3c57b3a6d48d7ddad44b67fdf9ccaebc40e5c125 Mon Sep 17 00:00:00 2001
From: Jared Rossi <jrossi@linux.ibm.com>
Date: Thu, 14 Nov 2024 19:27:42 -0500
Subject: [PATCH 2/9] docs/system/s390x/bootdevices: Update loadparm
documentation
RH-Author: Thomas Huth <thuth@redhat.com>
RH-MergeRequest: 297: [c10s] Fixes for the new s390x "boot order" feature
RH-Jira: RHEL-68444
RH-Acked-by: Miroslav Rezanina <mrezanin@redhat.com>
RH-Commit: [1/8] bd74a0794bf0f2872061850ca410bab819c6a0d6 (thuth/qemu-kvm-cs9)
Update documentation to include per-device loadparm support.
Signed-off-by: Jared Rossi <jrossi@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20241115002742.3576842-1-jrossi@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 0271fdc650b212533b8aeaecbedfe8ccf6bbbef3)
---
docs/system/s390x/bootdevices.rst | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/docs/system/s390x/bootdevices.rst b/docs/system/s390x/bootdevices.rst
index 1a1a764c1c..97b3914785 100644
--- a/docs/system/s390x/bootdevices.rst
+++ b/docs/system/s390x/bootdevices.rst
@@ -79,7 +79,29 @@ The second way to use this parameter is to use a number in the range from 0
to 31. The numbers that can be used here correspond to the numbers that are
shown when using the ``PROMPT`` option, and the s390-ccw bios will then try
to automatically boot the kernel that is associated with the given number.
-Note that ``0`` can be used to boot the default entry.
+Note that ``0`` can be used to boot the default entry. If the machine
+``loadparm`` is not assigned a value, then the default entry is used.
+
+By default, the machine ``loadparm`` applies to all boot devices. If multiple
+devices are assigned a ``bootindex`` and the ``loadparm`` is to be different
+between them, an independent ``loadparm`` may be assigned on a per-device basis.
+
+An example guest using per-device ``loadparm``::
+
+ qemu-system-s390x -drive if=none,id=dr1,file=primary.qcow2 \
+ -device virtio-blk,drive=dr1,bootindex=1 \
+ -drive if=none,id=dr2,file=secondary.qcow2 \
+ -device virtio-blk,drive=dr2,bootindex=2,loadparm=3
+
+In this case, the primary boot device will attempt to IPL using the default
+entry (because no ``loadparm`` is specified for this device or for the
+machine). If that device fails to boot, the secondary device will attempt to
+IPL using entry number 3.
+
+If a ``loadparm`` is specified on both the machine and a device, the per-device
+value will superseded the machine value. Per-device ``loadparm`` values are
+only used for devices with an assigned ``bootindex``. The machine ``loadparm``
+is used when attempting to boot without a ``bootindex``.
Booting from a network device
--
2.39.3

217
kvm-hw-Add-loadparm-property-to-scsi-disk-devices-for-bo.patch Normal file
View File

@ -0,0 +1,217 @@
From 4c90ff4c0b48df312c10defba45c9f182b535524 Mon Sep 17 00:00:00 2001
From: Thomas Huth <thuth@redhat.com>
Date: Fri, 15 Nov 2024 15:12:02 +0100
Subject: [PATCH 5/9] hw: Add "loadparm" property to scsi disk devices for
booting on s390x
RH-Author: Thomas Huth <thuth@redhat.com>
RH-MergeRequest: 297: [c10s] Fixes for the new s390x "boot order" feature
RH-Jira: RHEL-68444
RH-Acked-by: Miroslav Rezanina <mrezanin@redhat.com>
RH-Commit: [4/8] 4b5e2afa65f7a529e0bb5509b36c9bf81894caee (thuth/qemu-kvm-cs9)
While adding the new flexible boot order feature on s390x recently,
we missed to add the "loadparm" property to the scsi-hd and scsi-cd
devices. This property is required on s390x to pass the information
to the boot loader about which kernel should be started or whether
the boot menu should be shown. But even more serious: The missing
property is now causing trouble with the corresponding libvirt patches
that assume that the "loadparm" property is either settable for all
bootable devices (when the "boot order" feature is implemented in
QEMU), or none (meaning the behaviour of older QEMUs that only allowed
one "loadparm" at the machine level). To fix this broken situation,
let's implement the "loadparm" property in for the SCSI devices, too.
Message-ID: <20241115141202.1877294-1-thuth@redhat.com>
Acked-by: Eric Farman <farman@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 429442e52d94f890fa194a151e8cd649b04e9e63)
---
hw/core/qdev-properties-system.c | 26 +++++++++++++++++
hw/s390x/ipl.c | 19 ++++---------
hw/scsi/scsi-disk.c | 43 +++++++++++++++++++++++++++++
include/hw/qdev-properties-system.h | 3 ++
4 files changed, 78 insertions(+), 13 deletions(-)
diff --git a/hw/core/qdev-properties-system.c b/hw/core/qdev-properties-system.c
index f13350b4fb..5cd527cdba 100644
--- a/hw/core/qdev-properties-system.c
+++ b/hw/core/qdev-properties-system.c
@@ -58,6 +58,32 @@ static bool check_prop_still_unset(Object *obj, const char *name,
return false;
}
+bool qdev_prop_sanitize_s390x_loadparm(uint8_t *loadparm, const char *str,
+ Error **errp)
+{
+ int i, len;
+
+ len = strlen(str);
+ if (len > 8) {
+ error_setg(errp, "'loadparm' can only contain up to 8 characters");
+ return false;
+ }
+
+ for (i = 0; i < len; i++) {
+ uint8_t c = qemu_toupper(str[i]); /* mimic HMC */
+
+ if (qemu_isalnum(c) || c == '.' || c == ' ') {
+ loadparm[i] = c;
+ } else {
+ error_setg(errp,
+ "invalid character in 'loadparm': '%c' (ASCII 0x%02x)",
+ c, c);
+ return false;
+ }
+ }
+
+ return true;
+}
/* --- drive --- */
diff --git a/hw/s390x/ipl.c b/hw/s390x/ipl.c
index 5fbd43c346..8101825dfe 100644
--- a/hw/s390x/ipl.c
+++ b/hw/s390x/ipl.c
@@ -418,21 +418,9 @@ static uint64_t s390_ipl_map_iplb_chain(IplParameterBlock *iplb_chain)
void s390_ipl_fmt_loadparm(uint8_t *loadparm, char *str, Error **errp)
{
- int i;
-
/* Initialize the loadparm with spaces */
memset(loadparm, ' ', LOADPARM_LEN);
- for (i = 0; i < LOADPARM_LEN && str[i]; i++) {
- uint8_t c = qemu_toupper(str[i]); /* mimic HMC */
-
- if (qemu_isalnum(c) || c == '.' || c == ' ') {
- loadparm[i] = c;
- } else {
- error_setg(errp, "LOADPARM: invalid character '%c' (ASCII 0x%02x)",
- c, c);
- return;
- }
- }
+ qdev_prop_sanitize_s390x_loadparm(loadparm, str, errp);
}
void s390_ipl_convert_loadparm(char *ascii_lp, uint8_t *ebcdic_lp)
@@ -452,6 +440,7 @@ static bool s390_build_iplb(DeviceState *dev_st, IplParameterBlock *iplb)
SCSIDevice *sd;
int devtype;
uint8_t *lp;
+ g_autofree void *scsi_lp = NULL;
/*
* Currently allow IPL only from CCW devices.
@@ -463,6 +452,10 @@ static bool s390_build_iplb(DeviceState *dev_st, IplParameterBlock *iplb)
switch (devtype) {
case CCW_DEVTYPE_SCSI:
sd = SCSI_DEVICE(dev_st);
+ scsi_lp = object_property_get_str(OBJECT(sd), "loadparm", NULL);
+ if (scsi_lp && strlen(scsi_lp) > 0) {
+ lp = scsi_lp;
+ }
iplb->len = cpu_to_be32(S390_IPLB_MIN_QEMU_SCSI_LEN);
iplb->blk0_len =
cpu_to_be32(S390_IPLB_MIN_QEMU_SCSI_LEN - S390_IPLB_HEADER_LEN);
diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
index 4d94b2b816..7566a5f531 100644
--- a/hw/scsi/scsi-disk.c
+++ b/hw/scsi/scsi-disk.c
@@ -32,6 +32,7 @@
#include "migration/vmstate.h"
#include "hw/scsi/emulation.h"
#include "scsi/constants.h"
+#include "sysemu/arch_init.h"
#include "sysemu/block-backend.h"
#include "sysemu/blockdev.h"
#include "hw/block/block.h"
@@ -111,6 +112,7 @@ struct SCSIDiskState {
char *vendor;
char *product;
char *device_id;
+ char *loadparm; /* only for s390x */
bool tray_open;
bool tray_locked;
/*
@@ -3135,6 +3137,43 @@ BlockAIOCB *scsi_dma_writev(int64_t offset, QEMUIOVector *iov,
return blk_aio_pwritev(s->qdev.conf.blk, offset, iov, 0, cb, cb_opaque);
}
+static char *scsi_property_get_loadparm(Object *obj, Error **errp)
+{
+ return g_strdup(SCSI_DISK_BASE(obj)->loadparm);
+}
+
+static void scsi_property_set_loadparm(Object *obj, const char *value,
+ Error **errp)
+{
+ void *lp_str;
+
+ if (object_property_get_int(obj, "bootindex", NULL) < 0) {
+ error_setg(errp, "'loadparm' is only valid for boot devices");
+ return;
+ }
+
+ lp_str = g_malloc0(strlen(value));
+ if (!qdev_prop_sanitize_s390x_loadparm(lp_str, value, errp)) {
+ g_free(lp_str);
+ return;
+ }
+ SCSI_DISK_BASE(obj)->loadparm = lp_str;
+}
+
+static void scsi_property_add_specifics(DeviceClass *dc)
+{
+ ObjectClass *oc = OBJECT_CLASS(dc);
+
+ /* The loadparm property is only supported on s390x */
+ if (arch_type & QEMU_ARCH_S390X) {
+ object_class_property_add_str(oc, "loadparm",
+ scsi_property_get_loadparm,
+ scsi_property_set_loadparm);
+ object_class_property_set_description(oc, "loadparm",
+ "load parameter (s390x only)");
+ }
+}
+
static void scsi_disk_base_class_initfn(ObjectClass *klass, void *data)
{
DeviceClass *dc = DEVICE_CLASS(klass);
@@ -3218,6 +3257,8 @@ static void scsi_hd_class_initfn(ObjectClass *klass, void *data)
dc->desc = "virtual SCSI disk";
device_class_set_props(dc, scsi_hd_properties);
dc->vmsd = &vmstate_scsi_disk_state;
+
+ scsi_property_add_specifics(dc);
}
static const TypeInfo scsi_hd_info = {
@@ -3258,6 +3299,8 @@ static void scsi_cd_class_initfn(ObjectClass *klass, void *data)
dc->desc = "virtual SCSI CD-ROM";
device_class_set_props(dc, scsi_cd_properties);
dc->vmsd = &vmstate_scsi_disk_state;
+
+ scsi_property_add_specifics(dc);
}
static const TypeInfo scsi_cd_info = {
diff --git a/include/hw/qdev-properties-system.h b/include/hw/qdev-properties-system.h
index 438f65389f..88e4257ad0 100644
--- a/include/hw/qdev-properties-system.h
+++ b/include/hw/qdev-properties-system.h
@@ -3,6 +3,9 @@
#include "hw/qdev-properties.h"
+bool qdev_prop_sanitize_s390x_loadparm(uint8_t *loadparm, const char *str,
+ Error **errp);
+
extern const PropertyInfo qdev_prop_chr;
extern const PropertyInfo qdev_prop_macaddr;
extern const PropertyInfo qdev_prop_reserved_region;
--
2.39.3

112
kvm-hw-s390x-Restrict-loadparm-property-to-devices-that-.patch Normal file
View File

@ -0,0 +1,112 @@
From b9950c32c2845c9592650df49183c431a4190e7f Mon Sep 17 00:00:00 2001
From: Thomas Huth <thuth@redhat.com>
Date: Wed, 13 Nov 2024 12:47:41 +0100
Subject: [PATCH 4/9] hw/s390x: Restrict "loadparm" property to devices that
can be used for booting
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
RH-Author: Thomas Huth <thuth@redhat.com>
RH-MergeRequest: 297: [c10s] Fixes for the new s390x "boot order" feature
RH-Jira: RHEL-68444
RH-Acked-by: Miroslav Rezanina <mrezanin@redhat.com>
RH-Commit: [3/8] 7b0fee6a1508649d66b913e6ebf23b4af29628dd (thuth/qemu-kvm-cs9)
Commit bb185de423 ("s390x: Add individual loadparm assignment to
CCW device") added a "loadparm" property to all CCW devices. This
was a little bit unfortunate, since this property is only useful
for devices that can be used for booting, but certainly it is not
useful for devices like virtio-gpu or virtio-tablet.
Thus let's restrict the property to CCW devices that we can boot from
(i.e. virtio-block, virtio-net and vfio-ccw devices).
Message-ID: <20241113114741.681096-1-thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Jared Rossi <jrossi@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 6e7c96ae61e0542e97d385084f1f2281a0331054)
---
hw/s390x/ccw-device.c | 4 +---
hw/s390x/ccw-device.h | 5 +++++
hw/s390x/virtio-ccw-blk.c | 1 +
hw/s390x/virtio-ccw-net.c | 1 +
hw/vfio/ccw.c | 1 +
5 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/hw/s390x/ccw-device.c b/hw/s390x/ccw-device.c
index 4e54f34b1c..d7bb364579 100644
--- a/hw/s390x/ccw-device.c
+++ b/hw/s390x/ccw-device.c
@@ -73,7 +73,7 @@ static void ccw_device_set_loadparm(Object *obj, Visitor *v,
s390_ipl_fmt_loadparm(dev->loadparm, val, errp);
}
-static const PropertyInfo ccw_loadparm = {
+const PropertyInfo ccw_loadparm = {
.name = "ccw_loadparm",
.description = "Up to 8 chars in set of [A-Za-z0-9. ] to pass"
" to the guest loader/kernel",
@@ -85,8 +85,6 @@ static Property ccw_device_properties[] = {
DEFINE_PROP_CSS_DEV_ID("devno", CcwDevice, devno),
DEFINE_PROP_CSS_DEV_ID_RO("dev_id", CcwDevice, dev_id),
DEFINE_PROP_CSS_DEV_ID_RO("subch_id", CcwDevice, subch_id),
- DEFINE_PROP("loadparm", CcwDevice, loadparm, ccw_loadparm,
- typeof(uint8_t[8])),
DEFINE_PROP_END_OF_LIST(),
};
diff --git a/hw/s390x/ccw-device.h b/hw/s390x/ccw-device.h
index 1e1737c0f3..4439feb140 100644
--- a/hw/s390x/ccw-device.h
+++ b/hw/s390x/ccw-device.h
@@ -51,4 +51,9 @@ static inline CcwDevice *to_ccw_dev_fast(DeviceState *d)
OBJECT_DECLARE_TYPE(CcwDevice, CCWDeviceClass, CCW_DEVICE)
+extern const PropertyInfo ccw_loadparm;
+
+#define DEFINE_PROP_CCW_LOADPARM(_n, _s, _f) \
+ DEFINE_PROP(_n, _s, _f, ccw_loadparm, typeof(uint8_t[8]))
+
#endif
diff --git a/hw/s390x/virtio-ccw-blk.c b/hw/s390x/virtio-ccw-blk.c
index 8e0e58b77d..2364432c6e 100644
--- a/hw/s390x/virtio-ccw-blk.c
+++ b/hw/s390x/virtio-ccw-blk.c
@@ -48,6 +48,7 @@ static Property virtio_ccw_blk_properties[] = {
VIRTIO_CCW_FLAG_USE_IOEVENTFD_BIT, true),
DEFINE_PROP_UINT32("max_revision", VirtioCcwDevice, max_rev,
VIRTIO_CCW_MAX_REV),
+ DEFINE_PROP_CCW_LOADPARM("loadparm", CcwDevice, loadparm),
DEFINE_PROP_END_OF_LIST(),
};
diff --git a/hw/s390x/virtio-ccw-net.c b/hw/s390x/virtio-ccw-net.c
index 484e617659..a4a3f65c7e 100644
--- a/hw/s390x/virtio-ccw-net.c
+++ b/hw/s390x/virtio-ccw-net.c
@@ -51,6 +51,7 @@ static Property virtio_ccw_net_properties[] = {
VIRTIO_CCW_FLAG_USE_IOEVENTFD_BIT, true),
DEFINE_PROP_UINT32("max_revision", VirtioCcwDevice, max_rev,
VIRTIO_CCW_MAX_REV),
+ DEFINE_PROP_CCW_LOADPARM("loadparm", CcwDevice, loadparm),
DEFINE_PROP_END_OF_LIST(),
};
diff --git a/hw/vfio/ccw.c b/hw/vfio/ccw.c
index 115862f430..99f16614ad 100644
--- a/hw/vfio/ccw.c
+++ b/hw/vfio/ccw.c
@@ -662,6 +662,7 @@ static Property vfio_ccw_properties[] = {
DEFINE_PROP_LINK("iommufd", VFIOCCWDevice, vdev.iommufd,
TYPE_IOMMUFD_BACKEND, IOMMUFDBackend *),
#endif
+ DEFINE_PROP_CCW_LOADPARM("loadparm", CcwDevice, loadparm),
DEFINE_PROP_END_OF_LIST(),
};
--
2.39.3

41
kvm-pc-bios-s390-ccw-Re-initialize-receive-queue-index-b.patch Normal file
View File

@ -0,0 +1,41 @@
From b2add99e201168c36eed56a3982ab02f63e5717a Mon Sep 17 00:00:00 2001
From: Thomas Huth <thuth@redhat.com>
Date: Mon, 11 Nov 2024 14:11:20 +0100
Subject: [PATCH 9/9] pc-bios/s390-ccw: Re-initialize receive queue index
before each boot attempt
RH-Author: Thomas Huth <thuth@redhat.com>
RH-MergeRequest: 297: [c10s] Fixes for the new s390x "boot order" feature
RH-Jira: RHEL-68444
RH-Acked-by: Miroslav Rezanina <mrezanin@redhat.com>
RH-Commit: [8/8] 8d40508aaf993f2e1b94d471f0e50d0f375e22d2 (thuth/qemu-kvm-cs9)
Now that we can boot from multiple boot devices, we have to make sure
to reinitialize static variables like rx_last_idx to avoid that they
contain garbage data during the second boot attempt (which can lead to
crashes when the code tries to access the wrong ring data).
Message-ID: <20241111131120.317796-1-thuth@redhat.com>
Reviewed-by: Jared Rossi <jrossi@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 6ba1f714c00f8839a8df9f643e0058f00da3fd25)
---
pc-bios/s390-ccw/virtio-net.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/pc-bios/s390-ccw/virtio-net.c b/pc-bios/s390-ccw/virtio-net.c
index f9854a22c3..578c89d0c5 100644
--- a/pc-bios/s390-ccw/virtio-net.c
+++ b/pc-bios/s390-ccw/virtio-net.c
@@ -51,6 +51,8 @@ int virtio_net_init(void *mac_addr)
void *buf;
int i;
+ rx_last_idx = 0;
+
vdev->guest_features[0] = VIRTIO_NET_F_MAC_BIT;
virtio_setup_ccw(vdev);
--
2.39.3

39
kvm-pc-bios-s390x-Initialize-cdrom-type-to-false-for-eac.patch Normal file
View File

@ -0,0 +1,39 @@
From f0e7e2ae018cabdee3a87fa562ad7a4482d235b4 Mon Sep 17 00:00:00 2001
From: Jared Rossi <jrossi@linux.ibm.com>
Date: Fri, 8 Nov 2024 14:41:36 -0500
Subject: [PATCH 7/9] pc-bios/s390x: Initialize cdrom type to false for each
IPL device
RH-Author: Thomas Huth <thuth@redhat.com>
RH-MergeRequest: 297: [c10s] Fixes for the new s390x "boot order" feature
RH-Jira: RHEL-68444
RH-Acked-by: Miroslav Rezanina <mrezanin@redhat.com>
RH-Commit: [6/8] efbe12669e2a20d1c8412edfc5e2350475b84dda (thuth/qemu-kvm-cs9)
Clear information about cdrom type so that current IPL device isn't tainted
by stale data from previous devices.
Signed-off-by: Jared Rossi <jrossi@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20241108194136.2833932-1-jrossi@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 8c797468116d19940fb758efa749eae414616e3a)
---
pc-bios/s390-ccw/main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/pc-bios/s390-ccw/main.c b/pc-bios/s390-ccw/main.c
index a4d1c05aac..7509755e36 100644
--- a/pc-bios/s390-ccw/main.c
+++ b/pc-bios/s390-ccw/main.c
@@ -242,6 +242,7 @@ static bool find_boot_device(void)
static int virtio_setup(void)
{
VDev *vdev = virtio_get_device();
+ vdev->is_cdrom = false;
int ret;
switch (vdev->senseid.cu_model) {
--
2.39.3

51
kvm-pc-bios-s390x-Initialize-machine-loadparm-before-pro.patch Normal file
View File

@ -0,0 +1,51 @@
From 2d9158563e5d34f9147e660f943f631bad80b6dd Mon Sep 17 00:00:00 2001
From: Jared Rossi <jrossi@linux.ibm.com>
Date: Thu, 14 Nov 2024 11:19:52 -0500
Subject: [PATCH 8/9] pc-bios/s390x: Initialize machine loadparm before probing
IPL devices
RH-Author: Thomas Huth <thuth@redhat.com>
RH-MergeRequest: 297: [c10s] Fixes for the new s390x "boot order" feature
RH-Jira: RHEL-68444
RH-Acked-by: Miroslav Rezanina <mrezanin@redhat.com>
RH-Commit: [7/8] 7513fec6ef170ab0c2068a7641a79b77537f1608 (thuth/qemu-kvm-cs9)
Commit bb185de423 ("s390x: Add individual loadparm assignment to
CCW device") allowed boot devices to be assigned a loadparm value independent
of the machine value, however, when no boot devices are defined, the machine
loadparm becomes ignored. Therefore, let's check the machine loadparm
prior to probing the devices.
Signed-off-by: Jared Rossi <jrossi@linux.ibm.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-ID: <20241114161952.3508554-1-jrossi@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
(cherry picked from commit 1056ca1e70dc6e0458238141bcebfb7810cede6d)
---
pc-bios/s390-ccw/main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/pc-bios/s390-ccw/main.c b/pc-bios/s390-ccw/main.c
index 7509755e36..76bf743900 100644
--- a/pc-bios/s390-ccw/main.c
+++ b/pc-bios/s390-ccw/main.c
@@ -191,7 +191,7 @@ static void boot_setup(void)
{
char lpmsg[] = "LOADPARM=[________]\n";
- if (memcmp(iplb.loadparm, NO_LOADPARM, LOADPARM_LEN) != 0) {
+ if (have_iplb && memcmp(iplb.loadparm, NO_LOADPARM, LOADPARM_LEN) != 0) {
ebcdic_to_ascii((char *) iplb.loadparm, loadparm_str, LOADPARM_LEN);
} else {
sclp_get_loadparm_ascii(loadparm_str);
@@ -316,6 +316,7 @@ void main(void)
css_setup();
have_iplb = store_iplb(&iplb);
if (!have_iplb) {
+ boot_setup();
probe_boot_device();
}
--
2.39.3

44
kvm-scsi-fix-allocation-for-s390x-loadparm.patch Normal file
View File

@ -0,0 +1,44 @@
From f03d8c917543a5b92e26fcd8bd7c1cf006ea37df Mon Sep 17 00:00:00 2001
From: Paolo Bonzini <pbonzini@redhat.com>
Date: Tue, 19 Nov 2024 22:31:22 +0100
Subject: [PATCH 6/9] scsi: fix allocation for s390x loadparm
RH-Author: Thomas Huth <thuth@redhat.com>
RH-MergeRequest: 297: [c10s] Fixes for the new s390x "boot order" feature
RH-Jira: RHEL-68444
RH-Acked-by: Miroslav Rezanina <mrezanin@redhat.com>
RH-Commit: [5/8] b5a906d74fb4ad5a89e1880f07447bd3a5b3f2e9 (thuth/qemu-kvm-cs9)
Coverity reports a possible buffer overrun due to a non-NUL-terminated
string in scsi_property_set_loadparm(). While things are not so easy,
because qdev_prop_sanitize_s390x_loadparm is designed to operate on a
buffer that is not NUL-terminated, in this case the string *does* have
to be NUL-terminated because it is read by scsi_property_get_loadparm
and s390_build_iplb.
Reviewed-by: jrossi@linux.ibm.com
Cc: thuth@redhat.com
Fixes: 429442e52d9 ("hw: Add "loadparm" property to scsi disk devices for booting on s390x", 2024-11-18)
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit b73d7eff1eedb2399cd594bc872d5db13506d951)
Signed-off-by: Thomas Huth <thuth@redhat.com>
---
hw/scsi/scsi-disk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
index 7566a5f531..de0c295173 100644
--- a/hw/scsi/scsi-disk.c
+++ b/hw/scsi/scsi-disk.c
@@ -3152,7 +3152,7 @@ static void scsi_property_set_loadparm(Object *obj, const char *value,
return;
}
- lp_str = g_malloc0(strlen(value));
+ lp_str = g_malloc0(strlen(value) + 1);
if (!qdev_prop_sanitize_s390x_loadparm(lp_str, value, errp)) {
g_free(lp_str);
return;
--
2.39.3

94
kvm-virtio-net-Add-queues-before-loading-them.patch Normal file
View File

@ -0,0 +1,94 @@
From cff01d88d59e4227c6801f9f4605f6d1333e0c37 Mon Sep 17 00:00:00 2001
From: Akihiko Odaki <akihiko.odaki@daynix.com>
Date: Tue, 22 Oct 2024 15:49:01 +0900
Subject: [PATCH 1/9] virtio-net: Add queues before loading them
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
RH-Author: 小田喜陽彦 <None>
RH-MergeRequest: 274: virtio-net: Add queues before loading them
RH-Jira: RHEL-58316
RH-Acked-by: Laurent Vivier <lvivier@redhat.com>
RH-Acked-by: Jason Wang <jasowang@redhat.com>
RH-Commit: [1/1] 0cdfea34b1466538abad0d9d216ea6bcfd21ac67 (akihiko.odaki/qemu-kvm)
Call virtio_net_set_multiqueue() to add queues before loading their
states. Otherwise the loaded queues will not have handlers and elements
in them will not be processed.
Cc: qemu-stable@nongnu.org
Fixes: 8c49756825da ("virtio-net: Add only one queue pair when realizing")
Reported-by: Laurent Vivier <lvivier@redhat.com>
Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
(cherry picked from commit 9379ea9db3c0064fa2787db0794a23a30f7b2d2d)
---
hw/net/virtio-net.c | 10 ++++++++++
hw/virtio/virtio.c | 7 +++++++
include/hw/virtio/virtio.h | 2 ++
3 files changed, 19 insertions(+)
diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index ed33a32877..90d05f94d4 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -3032,6 +3032,15 @@ static void virtio_net_set_multiqueue(VirtIONet *n, int multiqueue)
virtio_net_set_queue_pairs(n);
}
+static int virtio_net_pre_load_queues(VirtIODevice *vdev)
+{
+ virtio_net_set_multiqueue(VIRTIO_NET(vdev),
+ virtio_has_feature(vdev->guest_features, VIRTIO_NET_F_RSS) ||
+ virtio_has_feature(vdev->guest_features, VIRTIO_NET_F_MQ));
+
+ return 0;
+}
+
static int virtio_net_post_load_device(void *opaque, int version_id)
{
VirtIONet *n = opaque;
@@ -4010,6 +4019,7 @@ static void virtio_net_class_init(ObjectClass *klass, void *data)
vdc->guest_notifier_mask = virtio_net_guest_notifier_mask;
vdc->guest_notifier_pending = virtio_net_guest_notifier_pending;
vdc->legacy_features |= (0x1 << VIRTIO_NET_F_GSO);
+ vdc->pre_load_queues = virtio_net_pre_load_queues;
vdc->post_load = virtio_net_post_load_virtio;
vdc->vmsd = &vmstate_virtio_net_device;
vdc->primary_unplug_pending = primary_unplug_pending;
diff --git a/hw/virtio/virtio.c b/hw/virtio/virtio.c
index 9e10cbc058..10f24a58dd 100644
--- a/hw/virtio/virtio.c
+++ b/hw/virtio/virtio.c
@@ -3251,6 +3251,13 @@ virtio_load(VirtIODevice *vdev, QEMUFile *f, int version_id)
config_len--;
}
+ if (vdc->pre_load_queues) {
+ ret = vdc->pre_load_queues(vdev);
+ if (ret) {
+ return ret;
+ }
+ }
+
num = qemu_get_be32(f);
if (num > VIRTIO_QUEUE_MAX) {
diff --git a/include/hw/virtio/virtio.h b/include/hw/virtio/virtio.h
index 0fcbc5c0c6..953dfca27c 100644
--- a/include/hw/virtio/virtio.h
+++ b/include/hw/virtio/virtio.h
@@ -210,6 +210,8 @@ struct VirtioDeviceClass {
void (*guest_notifier_mask)(VirtIODevice *vdev, int n, bool mask);
int (*start_ioeventfd)(VirtIODevice *vdev);
void (*stop_ioeventfd)(VirtIODevice *vdev);
+ /* Called before loading queues. Useful to add queues before loading. */
+ int (*pre_load_queues)(VirtIODevice *vdev);
/* Saving and loading of a device; trying to deprecate save/load
* use vmsd for new devices.
*/
--
2.39.3

35
qemu-kvm.spec
View File

@ -143,7 +143,7 @@ Obsoletes: %{name}-block-ssh <= %{epoch}:%{version} \
Summary: QEMU is a machine emulator and virtualizer
Name: qemu-kvm
Version: 9.1.0
Release: 6%{?rcrel}%{?dist}%{?cc_suffix}
Release: 7%{?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)
@ -340,6 +340,24 @@ Patch81: kvm-KVM-Rename-KVMState-nr_slots-to-nr_slots_max.patch
Patch82: kvm-vfio-container-Fix-container-object-destruction.patch
# For RHEL-40950 - [Stable_Guest_ABI][USO]From 10-beta to RHEL.9.5.0 the guest with 9.4 machine type only, the guest crashed with - qemu-kvm: Features 0x1c0010130afffa7 unsupported. Allowed features: 0x10179bfffe7
Patch83: kvm-virtio-net-disable-USO-for-RHEL9.patch
# For RHEL-58316 - qemu crashed when migrate vm with multiqueue from rhel9.4 to rhel10.0
Patch84: kvm-virtio-net-Add-queues-before-loading-them.patch
# For RHEL-68444 - The new "boot order" feature is sometimes not working as expected [RHEL 10]
Patch85: kvm-docs-system-s390x-bootdevices-Update-loadparm-docume.patch
# For RHEL-68444 - The new "boot order" feature is sometimes not working as expected [RHEL 10]
Patch86: kvm-docs-system-bootindex-Make-it-clear-that-s390x-can-a.patch
# For RHEL-68444 - The new "boot order" feature is sometimes not working as expected [RHEL 10]
Patch87: kvm-hw-s390x-Restrict-loadparm-property-to-devices-that-.patch
# For RHEL-68444 - The new "boot order" feature is sometimes not working as expected [RHEL 10]
Patch88: kvm-hw-Add-loadparm-property-to-scsi-disk-devices-for-bo.patch
# For RHEL-68444 - The new "boot order" feature is sometimes not working as expected [RHEL 10]
Patch89: kvm-scsi-fix-allocation-for-s390x-loadparm.patch
# For RHEL-68444 - The new "boot order" feature is sometimes not working as expected [RHEL 10]
Patch90: kvm-pc-bios-s390x-Initialize-cdrom-type-to-false-for-eac.patch
# For RHEL-68444 - The new "boot order" feature is sometimes not working as expected [RHEL 10]
Patch91: kvm-pc-bios-s390x-Initialize-machine-loadparm-before-pro.patch
# For RHEL-68444 - The new "boot order" feature is sometimes not working as expected [RHEL 10]
Patch92: kvm-pc-bios-s390-ccw-Re-initialize-receive-queue-index-b.patch
%if %{have_clang}
BuildRequires: clang
@ -1406,6 +1424,21 @@ useradd -r -u 107 -g qemu -G kvm -d / -s /sbin/nologin \
%endif
%changelog
* Tue Dec 03 2024 Miroslav Rezanina <mrezanin@redhat.com> - 9.1.0-7
- kvm-virtio-net-Add-queues-before-loading-them.patch [RHEL-58316]
- kvm-docs-system-s390x-bootdevices-Update-loadparm-docume.patch [RHEL-68444]
- kvm-docs-system-bootindex-Make-it-clear-that-s390x-can-a.patch [RHEL-68444]
- kvm-hw-s390x-Restrict-loadparm-property-to-devices-that-.patch [RHEL-68444]
- kvm-hw-Add-loadparm-property-to-scsi-disk-devices-for-bo.patch [RHEL-68444]
- kvm-scsi-fix-allocation-for-s390x-loadparm.patch [RHEL-68444]
- kvm-pc-bios-s390x-Initialize-cdrom-type-to-false-for-eac.patch [RHEL-68444]
- kvm-pc-bios-s390x-Initialize-machine-loadparm-before-pro.patch [RHEL-68444]
- kvm-pc-bios-s390-ccw-Re-initialize-receive-queue-index-b.patch [RHEL-68444]
- Resolves: RHEL-58316
(qemu crashed when migrate vm with multiqueue from rhel9.4 to rhel10.0)
- Resolves: RHEL-68444
(The new "boot order" feature is sometimes not working as expected [RHEL 10])
* Mon Nov 25 2024 Miroslav Rezanina <mrezanin@redhat.com> - 9.1.0-6
- kvm-vfio-container-Fix-container-object-destruction.patch [RHEL-67936]
- kvm-virtio-net-disable-USO-for-RHEL9.patch [RHEL-40950]