qemu-kvm/kvm-spapr-Use-SHUTDOWN_CAUSE_SUBSYSTEM_RESET-for-CAS-reb.patch
Danilo C. L. de Paula 1523562e21 * Mon Sep 09 2019 Danilo Cesar Lemes de Paula <ddepaula@redhat.com> - 4.1.0-8.el8
- kvm-migration-Do-not-re-read-the-clock-on-pre_save-in-ca.patch [bz#1747836]
- kvm-ehci-fix-queue-dev-null-ptr-dereference.patch [bz#1746790]
- kvm-spapr-Use-SHUTDOWN_CAUSE_SUBSYSTEM_RESET-for-CAS-reb.patch [bz#1743477]
- kvm-file-posix-Handle-undetectable-alignment.patch [bz#1749134]
- kvm-block-posix-Always-allocate-the-first-block.patch [bz#1749134]
- kvm-iotests-Test-allocate_first_block-with-O_DIRECT.patch [bz#1749134]
- Resolves: bz#1743477
  (Since bd94bc06479a "spapr: change default interrupt mode to 'dual'", QEMU resets the machine to select the appropriate interrupt controller. And -no-reboot prevents that.)
- Resolves: bz#1746790
  (qemu core dump while migrate from RHEL7.6 to RHEL8.1)
- Resolves: bz#1747836
  (Call traces after guest migration due to incorrect handling of the timebase)
- Resolves: bz#1749134
  (I/O error when virtio-blk disk is backed by a raw image on 4k disk)
2019-09-09 19:17:47 +01:00

61 lines
2.4 KiB
Diff

From c8d3479746b17fcdf56b8afb3eccdba2c14578e8 Mon Sep 17 00:00:00 2001
From: David Gibson <dgibson@redhat.com>
Date: Fri, 6 Sep 2019 03:58:36 +0100
Subject: [PATCH 3/6] spapr: Use SHUTDOWN_CAUSE_SUBSYSTEM_RESET for CAS reboots
RH-Author: David Gibson <dgibson@redhat.com>
Message-id: <20190906035836.23689-1-dgibson@redhat.com>
Patchwork-id: 90293
O-Subject: [RHEL-AV-8.1.0 qemu-kvm PATCH] spapr: Use SHUTDOWN_CAUSE_SUBSYSTEM_RESET for CAS reboots
Bugzilla: 1743477
RH-Acked-by: Laurent Vivier <lvivier@redhat.com>
RH-Acked-by: Thomas Huth <thuth@redhat.com>
RH-Acked-by: Danilo de Paula <ddepaula@redhat.com>
From: David Gibson <david@gibson.dropbear.id.au>
The sPAPR platform includes feature negotiation between the guest and
platform. That sometimes requires reconfiguring the virtual hardware, and
in some cases that is a complex enough process that we trigger a system
reset to handle it. That interacts badly with -no-reboot - we trigger the
reboot, -no-reboot means we exit and so the guest never gets to try again.
Eventually we want to get rid of CAS reboots entirely, since they're odd
and irritating for the user. But in the meantime we can fix the -no-reboot
problem by using SHUTDOWN_CAUSE_SUBSYSTEM_RESET which ignores -no-reboot
and seems to be designed for this sort of faux-reset for internal purposes
only.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
(cherry picked from commit 9146206eb26c1436c80a7c2ca1e4c5f86b27179d)
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1743477
Brew: https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=23395494
Branch: rhel-av-8.1.0/master-4.1.0
Testing: Started a guest and verified that -no-reboot no longer
prevents the CAS reboot to negotiate XIVE support from
completing
Signed-off-by: David Gibson <dgibson@redhat.com>
Signed-off-by: Danilo C. L. de Paula <ddepaula@redhat.com>
---
hw/ppc/spapr_hcall.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/ppc/spapr_hcall.c b/hw/ppc/spapr_hcall.c
index 6808d4c..687bb7b 100644
--- a/hw/ppc/spapr_hcall.c
+++ b/hw/ppc/spapr_hcall.c
@@ -1672,7 +1672,7 @@ static target_ulong h_client_architecture_support(PowerPCCPU *cpu,
spapr_ovec_cleanup(ov5_updates);
if (spapr->cas_reboot) {
- qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET);
+ qemu_system_reset_request(SHUTDOWN_CAUSE_SUBSYSTEM_RESET);
}
return H_SUCCESS;
--
1.8.3.1