From 297ec01f0b9864ea8209ca0ddc6643b4c0574bdb Mon Sep 17 00:00:00 2001 From: Janosch Frank Date: Wed, 23 Aug 2023 16:22:15 +0200 Subject: s390x/ap: fix missing subsystem reset registration A subsystem reset contains a reset of AP resources which has been missing. Adding the AP bridge to the list of device types that need reset fixes this issue. Reviewed-by: Jason J. Herne Reviewed-by: Tony Krowiak Signed-off-by: Janosch Frank Fixes: a51b3153 ("s390x/ap: base Adjunct Processor (AP) object model") Message-ID: <20230823142219.1046522-2-seiden@linux.ibm.com> Signed-off-by: Thomas Huth --- hw/s390x/s390-virtio-ccw.c | 1 + 1 file changed, 1 insertion(+) (limited to 'hw') diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c index bfcf64d..3dd0b23 100644 --- a/hw/s390x/s390-virtio-ccw.c +++ b/hw/s390x/s390-virtio-ccw.c @@ -109,6 +109,7 @@ static const char *const reset_dev_types[] = { "s390-flic", "diag288", TYPE_S390_PCI_HOST_BRIDGE, + TYPE_AP_BRIDGE, }; static void subsystem_reset(void) -- cgit v1.1 From ef1535901a07f2e49fa25c8bcee7f0b73801d824 Mon Sep 17 00:00:00 2001 From: Janosch Frank Date: Fri, 1 Sep 2023 11:48:51 +0000 Subject: s390x: do a subsystem reset before the unprotect on reboot Bound APQNs have to be reset before tearing down the secure config via s390_machine_unprotect(). Otherwise the Ultravisor will return a error code. So let's do a subsystem_reset() which includes a AP reset before the unprotect call. We'll do a full device_reset() afterwards which will reset some devices twice. That's ok since we can't move the device_reset() before the unprotect as it includes a CPU clear reset which the Ultravisor does not expect at that point in time. Signed-off-by: Janosch Frank Message-ID: <20230901114851.154357-1-frankja@linux.ibm.com> Tested-by: Viktor Mihajlovski Acked-by: Christian Borntraeger Signed-off-by: Thomas Huth --- hw/s390x/s390-virtio-ccw.c | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'hw') diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c index 3dd0b23..2d75f21 100644 --- a/hw/s390x/s390-virtio-ccw.c +++ b/hw/s390x/s390-virtio-ccw.c @@ -438,10 +438,20 @@ static void s390_machine_reset(MachineState *machine, ShutdownCause reason) switch (reset_type) { case S390_RESET_EXTERNAL: case S390_RESET_REIPL: + /* + * Reset the subsystem which includes a AP reset. If a PV + * guest had APQNs attached the AP reset is a prerequisite to + * unprotecting since the UV checks if all APQNs are reset. + */ + subsystem_reset(); if (s390_is_pv()) { s390_machine_unprotect(ms); } + /* + * Device reset includes CPU clear resets so this has to be + * done AFTER the unprotect call above. + */ qemu_devices_reset(reason); s390_crypto_reset(); -- cgit v1.1 From 4ddf7728fb2f395341f050bccf9c46386fd0cea3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= Date: Mon, 28 Aug 2023 17:01:48 +0200 Subject: kconfig: Add NVME to s390x machines MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit We recently had issues with nvme devices on big endian platforms. Include their compilation on s390x to ease tests. Signed-off-by: Cédric Le Goater Message-ID: <20230828150148.120031-1-clg@kaod.org> Reviewed-by: Thomas Huth Acked-by: Klaus Jensen Signed-off-by: Thomas Huth --- hw/nvme/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'hw') diff --git a/hw/nvme/Kconfig b/hw/nvme/Kconfig index 8ac9094..cfa2ab0 100644 --- a/hw/nvme/Kconfig +++ b/hw/nvme/Kconfig @@ -1,4 +1,4 @@ config NVME_PCI bool - default y if PCI_DEVICES + default y if PCI_DEVICES || PCIE_DEVICES depends on PCI -- cgit v1.1