From nobody Fri May 3 22:08:23 2024 Delivered-To: importer@patchew.org Received-SPF: temperror (zoho.com: Error in retrieving data from DNS) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; dkim=fail; spf=temperror (zoho.com: Error in retrieving data from DNS) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (208.118.235.17 [208.118.235.17]) by mx.zohomail.com with SMTPS id 1511326223573707.3195049526851; Tue, 21 Nov 2017 20:50:23 -0800 (PST) Received: from localhost ([::1]:37833 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eHMz8-0007OW-7x for importer@patchew.org; Tue, 21 Nov 2017 23:50:06 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60346) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eHMxU-0005vZ-3v for qemu-devel@nongnu.org; Tue, 21 Nov 2017 23:48:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eHMxT-000384-4j for qemu-devel@nongnu.org; Tue, 21 Nov 2017 23:48:24 -0500 Received: from ozlabs.org ([2401:3900:2:1::2]:46287) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eHMxS-000364-CB; Tue, 21 Nov 2017 23:48:22 -0500 Received: by ozlabs.org (Postfix, from userid 1007) id 3yhVMP2Nyhz9s9Y; Wed, 22 Nov 2017 15:48:17 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gibson.dropbear.id.au; s=201602; t=1511326097; bh=3nmjfYOSFQDOaJtlNHHmpAfsHPOteULI6dcTlmIohAs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=A6gmTm2gWsmq9BdjiTJEtTnTVed4+TeTbj+HVIwmGeI0ys6uzO6LxW9wv+vgYu4IC Ss+rg6z3RJMaxYQzUFpilQM0tb9EfbAHK3fkeLEZpfwJVmkBne424t9kOLrVmRb9l/ mpBeNlocVTj/zLfUnuUauvjSOOVwDVGTk3/kD5t0= From: David Gibson To: peter.maydell@linaro.org Date: Wed, 22 Nov 2017 15:48:12 +1100 Message-Id: <20171122044814.3001-2-david@gibson.dropbear.id.au> X-Mailer: git-send-email 2.14.3 In-Reply-To: <20171122044814.3001-1-david@gibson.dropbear.id.au> References: <20171122044814.3001-1-david@gibson.dropbear.id.au> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2401:3900:2:1::2 Subject: [Qemu-devel] [PULL 1/3] hw/ppc/spapr: Fix virtio-scsi bootindex handling for LUNs >= 256 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: lvivier@redhat.com, Thomas Huth , qemu-devel@nongnu.org, agraf@suse.de, groug@kaod.org, qemu-ppc@nongnu.org, David Gibson Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: fail (Header signature does not verify) X-ZohoMail: RDKM_2 RSF_6 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" From: Thomas Huth LUNs >=3D 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=3DSLOF.git;a=3Dcommitdiff;h=3Df72a37713fea47da (see https://bugzilla.redhat.com/show_bug.cgi?id=3D1431584 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 >=3D 256 in the right boot order. Fix it by using the bit to indicate the "flat space addressing method" for LUNs >=3D 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 6285f7211f..4d0a84f3ec 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 =3D 0x1000000 | (d->id << 16) | d->lun; + if (d->lun >=3D 256) { + /* Use the LUN "flat space addressing method" */ + id |=3D 0x4000; + } return g_strdup_printf("%s@%"PRIX64, qdev_fw_name(dev), (uint64_t)id << 32); } else if (usb) { --=20 2.14.3 From nobody Fri May 3 22:08:23 2024 Delivered-To: importer@patchew.org Received-SPF: temperror (zoho.com: Error in retrieving data from DNS) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; dkim=fail; spf=temperror (zoho.com: Error in retrieving data from DNS) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (208.118.235.17 [208.118.235.17]) by mx.zohomail.com with SMTPS id 1511326223573909.1867890825928; Tue, 21 Nov 2017 20:50:23 -0800 (PST) Received: from localhost ([::1]:37835 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eHMzF-0007Uy-9Y for importer@patchew.org; Tue, 21 Nov 2017 23:50:13 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60382) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eHMxW-0005wl-46 for qemu-devel@nongnu.org; Tue, 21 Nov 2017 23:48:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eHMxT-00037t-2E for qemu-devel@nongnu.org; Tue, 21 Nov 2017 23:48:26 -0500 Received: from ozlabs.org ([103.22.144.67]:52801) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eHMxS-000365-9j; Tue, 21 Nov 2017 23:48:22 -0500 Received: by ozlabs.org (Postfix, from userid 1007) id 3yhVMP1kvpz9sBZ; Wed, 22 Nov 2017 15:48:17 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gibson.dropbear.id.au; s=201602; t=1511326097; bh=2N5x1LDOs04EGaCFdwl+G+0g+ewme+f9L+XYhJs9Wo8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kRniz3uF5bXyyhzVwNuKA2oXvrj6BJof/iLzRqUSBwpaojjkfLiQtC1BdecU8+3rx 0/Z6JgI54XoD5WxEXZ/z4+mQw+yGp5F0QVGKY05MfQ1wgkvhM0epwpYK6m197NBoa4 btO/PAFFvJzmk2+KSZXvYs82FPQ+BD7QLZ5ODuBk= From: David Gibson To: peter.maydell@linaro.org Date: Wed, 22 Nov 2017 15:48:13 +1100 Message-Id: <20171122044814.3001-3-david@gibson.dropbear.id.au> X-Mailer: git-send-email 2.14.3 In-Reply-To: <20171122044814.3001-1-david@gibson.dropbear.id.au> References: <20171122044814.3001-1-david@gibson.dropbear.id.au> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 103.22.144.67 Subject: [Qemu-devel] [PULL 2/3] spapr: Implement bug in spapr-vty device to be compatible with PowerVM X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: lvivier@redhat.com, qemu-devel@nongnu.org, agraf@suse.de, groug@kaod.org, qemu-ppc@nongnu.org, David Gibson Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: fail (Header signature does not verify) X-ZohoMail: RDKM_2 RSF_6 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" 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 0fa416ca6b..6748334ded 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 *b= uf, int max) =20 while ((n < max) && (dev->out !=3D dev->in)) { buf[n++] =3D 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] =3D=3D '\r') { + if (n < max) { + buf[n++] =3D '\0'; + } else { + /* No room for the extra \0, roll back and try again + * next time */ + dev->out--; + n--; + break; + } + } } =20 qemu_chr_fe_accept_input(&dev->chardev); --=20 2.14.3 From nobody Fri May 3 22:08:23 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (208.118.235.17 [208.118.235.17]) by mx.zohomail.com with SMTPS id 1511326312527408.21284192048165; Tue, 21 Nov 2017 20:51:52 -0800 (PST) Received: from localhost ([::1]:37845 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eHN0k-0000I9-UH for importer@patchew.org; Tue, 21 Nov 2017 23:51:46 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60343) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eHMxU-0005vS-1R for qemu-devel@nongnu.org; Tue, 21 Nov 2017 23:48:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eHMxT-00038A-3p for qemu-devel@nongnu.org; Tue, 21 Nov 2017 23:48:24 -0500 Received: from ozlabs.org ([2401:3900:2:1::2]:34049) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eHMxS-000363-CI; Tue, 21 Nov 2017 23:48:22 -0500 Received: by ozlabs.org (Postfix, from userid 1007) id 3yhVMP0wpRz9s1h; Wed, 22 Nov 2017 15:48:17 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gibson.dropbear.id.au; s=201602; t=1511326097; bh=qQlepJEM+GBW2holShDqfC7t/cG2e7LcsVCIUbr63cg=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=cMJAQ9cKhsPgprfqjVUq0gph06iwnKb8xww30xPOmwrn3kUX/tYD1IstM9/zdQIZ9 ERj2WKGQYILeZpijDwwkOrb6w0zQRzDwRzN+qsKZFhqYxwvDjyteySqGljtk+058nx vRMUfwnkHYCiFDcD2cGwGNkTJhhG0EbP8cnejPhU= From: David Gibson To: peter.maydell@linaro.org Date: Wed, 22 Nov 2017 15:48:14 +1100 Message-Id: <20171122044814.3001-4-david@gibson.dropbear.id.au> X-Mailer: git-send-email 2.14.3 In-Reply-To: <20171122044814.3001-1-david@gibson.dropbear.id.au> References: <20171122044814.3001-1-david@gibson.dropbear.id.au> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2401:3900:2:1::2 Subject: [Qemu-devel] [PULL 3/3] ppc: fix VTB migration X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: lvivier@redhat.com, qemu-devel@nongnu.org, agraf@suse.de, groug@kaod.org, qemu-ppc@nongnu.org, David Gibson Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail-DKIM: fail (Header signature does not verify) X-ZohoMail: RDKM_2 RSF_0 Z_629925259 SPT_0 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" From: Laurent Vivier 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 b9c49c22f2..4e11e6f489 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); } =20 static void gen_spr_power8_fscr(CPUPPCState *env) --=20 2.14.3