From bac658d1a4dc9dd637b2eb5006abda137071f17f Mon Sep 17 00:00:00 2001 From: Thomas Huth Date: Mon, 20 Nov 2017 08:44:38 +0100 Subject: [PATCH 1/3] hw/ppc/spapr: Fix virtio-scsi bootindex handling for LUNs >= 256 LUNs >= 256 have to be encoded with the so-called "flat space addressing method" for virtio-scsi, where an additional bit has to be set. SLOF already took care of this with the following commit: https://git.qemu.org/?p=SLOF.git;a=commitdiff;h=f72a37713fea47da (see https://bugzilla.redhat.com/show_bug.cgi?id=1431584 for details) But QEMU does not use this encoding yet for device tree paths that have to be handed over to SLOF to deal with the "bootindex" property, so SLOF currently fails to boot from virtio-scsi devices with LUNs >= 256 in the right boot order. Fix it by using the bit to indicate the "flat space addressing method" for LUNs >= 256. Signed-off-by: Thomas Huth Signed-off-by: David Gibson --- hw/ppc/spapr.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c index 6285f7211f9a..4d0a84f3ecfc 100644 --- a/hw/ppc/spapr.c +++ b/hw/ppc/spapr.c @@ -2663,6 +2663,10 @@ static char *spapr_get_fw_dev_path(FWPathProvider *p, BusState *bus, * swap 0100 or 10 << or 20 << ( target lun-id -- srplun ) */ unsigned id = 0x1000000 | (d->id << 16) | d->lun; + if (d->lun >= 256) { + /* Use the LUN "flat space addressing method" */ + id |= 0x4000; + } return g_strdup_printf("%s@%"PRIX64, qdev_fw_name(dev), (uint64_t)id << 32); } else if (usb) { From 6c3bc244d3cbdc5545504fda4fae0238ec36a3c0 Mon Sep 17 00:00:00 2001 From: David Gibson Date: Mon, 20 Nov 2017 17:49:25 +1100 Subject: [PATCH 2/3] spapr: Implement bug in spapr-vty device to be compatible with PowerVM The spapr-vty device implements the PAPR defined virtual console, which is also implemented by IBM's proprietary PowerVM hypervisor. PowerVM's implementation has a bug where it inserts an extra \0 after every \r going to the guest. Because of that Linux's guest side driver has a workaround which strips \0 characters that appear immediately after a \r. That means that when running under qemu, sending a binary stream from host to guest via spapr-vty which happens to include a \r\0 sequence will get corrupted by that workaround. To deal with that, this patch duplicates PowerVM's bug, inserting an extra \0 after each \r. Ugly, but the best option available. Signed-off-by: David Gibson Reviewed-by: Thomas Huth Reviewed-by: Greg Kurz --- hw/char/spapr_vty.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/hw/char/spapr_vty.c b/hw/char/spapr_vty.c index 0fa416ca6bf5..6748334ded4c 100644 --- a/hw/char/spapr_vty.c +++ b/hw/char/spapr_vty.c @@ -58,6 +58,24 @@ static int vty_getchars(VIOsPAPRDevice *sdev, uint8_t *buf, int max) while ((n < max) && (dev->out != dev->in)) { buf[n++] = dev->buf[dev->out++ % VTERM_BUFSIZE]; + + /* PowerVM's vty implementation has a bug where it inserts a + * \0 after every \r going to the guest. Existing guests have + * a workaround for this which removes every \0 immediately + * following a \r, so here we make ourselves bug-for-bug + * compatible, so that the guest won't drop a real \0-after-\r + * that happens to occur in a binary stream. */ + if (buf[n - 1] == '\r') { + if (n < max) { + buf[n++] = '\0'; + } else { + /* No room for the extra \0, roll back and try again + * next time */ + dev->out--; + n--; + break; + } + } } qemu_chr_fe_accept_input(&dev->chardev); From 6dd836f5d32b989e18c6dda655a26f4d73a52f6a Mon Sep 17 00:00:00 2001 From: Laurent Vivier Date: Tue, 21 Nov 2017 21:16:43 +0100 Subject: [PATCH 3/3] ppc: fix VTB migration Migration of a system under stress (for example, with "stress-ng --numa 2") triggers on the destination some kernel watchdog messages like: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 3489660870s! NMI watchdog: BUG: soft lockup - CPU#1 stuck for 3489660884s! This problem appears with the changes introduced by 42043e4 spapr: clock should count only if vm is running I think this commit only triggers the problem. Kernel computes the soft lockup duration using the Virtual Timebase register (VTB), not using the Timebase Register (TBR, the one 42043e4 stops). It appears VTB is not migrated, so this patch adds it in the list of the SPRs to migrate, and fixes the problem. For the migration, I've tested a migration from qemu-2.8.0 and pseries-2.8.0 to a patched master (qemu-2.11.0-rc1). The received VTB is 0 (as is it not initialized by qemu-2.8.0), but the value seems to be ignored by KVM and a non zero VTB is used by the kernel. I have no explanation for that, but as the original problem appears only with SMP system under stress I suspect some problems in KVM (I think because VTB is shared by all threads of a core). Signed-off-by: Laurent Vivier Signed-off-by: David Gibson --- target/ppc/translate_init.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/target/ppc/translate_init.c b/target/ppc/translate_init.c index b9c49c22f29f..4e11e6f489f0 100644 --- a/target/ppc/translate_init.c +++ b/target/ppc/translate_init.c @@ -8081,10 +8081,10 @@ static void gen_spr_power8_ebb(CPUPPCState *env) /* Virtual Time Base */ static void gen_spr_vtb(CPUPPCState *env) { - spr_register(env, SPR_VTB, "VTB", + spr_register_kvm(env, SPR_VTB, "VTB", SPR_NOACCESS, SPR_NOACCESS, &spr_read_tbl, SPR_NOACCESS, - 0x00000000); + KVM_REG_PPC_VTB, 0x00000000); } static void gen_spr_power8_fscr(CPUPPCState *env)