From nobody Mon May 6 04:22:29 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 (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1511757126437856.9920719175419; Sun, 26 Nov 2017 20:32:06 -0800 (PST) Received: from localhost ([::1]:59123 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eJB5H-000646-IO for importer@patchew.org; Sun, 26 Nov 2017 23:31:55 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42328) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eJB3b-00055P-9v for qemu-devel@nongnu.org; Sun, 26 Nov 2017 23:30:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eJB3a-00026T-DH for qemu-devel@nongnu.org; Sun, 26 Nov 2017 23:30:11 -0500 Received: from ozlabs.org ([2401:3900:2:1::2]:51367) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eJB3Z-00022b-Qp; Sun, 26 Nov 2017 23:30:10 -0500 Received: by ozlabs.org (Postfix, from userid 1007) id 3ylYk72Rmkz9sPm; Mon, 27 Nov 2017 15:30:07 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gibson.dropbear.id.au; s=201602; t=1511757007; bh=j049syCVoXqZzHUzMDK28ssiP04g+rC5o2WfSiDLTM8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lUgMpAXdGjoQHYkSuuj0JoSC+yA9uLOhtWb3EuM+I03iuWJ9JUrPH9bT/LjWBXCL0 ZsNVFV2HNdP9K13v0pKzQSg5t1d6TqhWdVYL+KRN3sRVWcFQAgQFPfPPLfsN9la8g8 zErkEmA1DZ4gMYslPvM2R/p6BaMtjKIPYvQ6d68M= From: David Gibson To: peter.maydell@linaro.org Date: Mon, 27 Nov 2017 15:30:02 +1100 Message-Id: <20171127043003.15034-2-david@gibson.dropbear.id.au> X-Mailer: git-send-email 2.14.3 In-Reply-To: <20171127043003.15034-1-david@gibson.dropbear.id.au> References: <20171127043003.15034-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/2] target/ppc: Move setting of patb_entry on hash table init 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: agraf@suse.de, surajjs@au1.ibm.com, qemu-devel@nongnu.org, groug@kaod.org, qemu-ppc@nongnu.org, Suraj Jitindar Singh , 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: Suraj Jitindar Singh The patb_entry is used to store the location of the process table in guest memory. The msb is also used to indicate the mmu mode of the guest, that is patb_entry & 1 << 63 ? radix_mode : hash_mode. Currently we set this to zero in spapr_setup_hpt_and_vrma() since if this function gets called then we know we're hash. However some code paths, such as setting up the hpt on incoming migration of a hash guest, call spapr_reallocate_hpt() directly bypassing this higher level function. Since we assume radix if the host is capable this results in the msb in patb_entry being left set so in spapr_post_load() we call kvmppc_configure_v3_mmu() and tell the host we're radix which as expected means addresses cannot be translated once we actually run the cpu. To fix this move the zeroing of patb_entry into spapr_reallocate_hpt(). Signed-off-by: Suraj Jitindar Singh Signed-off-by: David Gibson --- hw/ppc/spapr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c index 4d0a84f3ec..9efddeaee5 100644 --- a/hw/ppc/spapr.c +++ b/hw/ppc/spapr.c @@ -1373,6 +1373,8 @@ void spapr_reallocate_hpt(sPAPRMachineState *spapr, i= nt shift, DIRTY_HPTE(HPTE(spapr->htab, i)); } } + /* We're setting up a hash table, so that means we're not radix */ + spapr->patb_entry =3D 0; } =20 void spapr_setup_hpt_and_vrma(sPAPRMachineState *spapr) @@ -1392,8 +1394,6 @@ void spapr_setup_hpt_and_vrma(sPAPRMachineState *spap= r) spapr->rma_size =3D kvmppc_rma_size(spapr_node0_size(MACHINE(spapr= )), spapr->htab_shift); } - /* We're setting up a hash table, so that means we're not radix */ - spapr->patb_entry =3D 0; } =20 static void find_unknown_sysbus_device(SysBusDevice *sbdev, void *opaque) --=20 2.14.3 From nobody Mon May 6 04:22:29 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 (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1511757119680899.0427861881806; Sun, 26 Nov 2017 20:31:59 -0800 (PST) Received: from localhost ([::1]:59124 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eJB5H-000649-W2 for importer@patchew.org; Sun, 26 Nov 2017 23:31:56 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42364) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eJB3d-00057D-I5 for qemu-devel@nongnu.org; Sun, 26 Nov 2017 23:30:14 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eJB3a-00026K-CX for qemu-devel@nongnu.org; Sun, 26 Nov 2017 23:30:13 -0500 Received: from ozlabs.org ([103.22.144.67]:51251) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eJB3Z-00022Y-QK; Sun, 26 Nov 2017 23:30:10 -0500 Received: by ozlabs.org (Postfix, from userid 1007) id 3ylYk71jrKz9s03; Mon, 27 Nov 2017 15:30:07 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gibson.dropbear.id.au; s=201602; t=1511757007; bh=csjaN9W98sYkrPVGm0xBQlzAhbw5m4+If+K0aYMYKn4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=aYsnkleMxAGijUZGoqr0516pQRwFUZ43jpbFyNlLzK+PJ4qK3TN+835maApZJSgVB nY0yPPTkZ2R8stNxhcldSnTYvOMUheQ4AXFHtw0rGbp5z8qsbTtc3uOIviJh+T8Rc9 R5hZnRyDTkyZUmti55AtN4ljBYStFSv4R7wUIR3E= From: David Gibson To: peter.maydell@linaro.org Date: Mon, 27 Nov 2017 15:30:03 +1100 Message-Id: <20171127043003.15034-3-david@gibson.dropbear.id.au> X-Mailer: git-send-email 2.14.3 In-Reply-To: <20171127043003.15034-1-david@gibson.dropbear.id.au> References: <20171127043003.15034-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/2] target/ppc: Fix setting of cpu->compat_pvr on incoming 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: agraf@suse.de, surajjs@au1.ibm.com, qemu-devel@nongnu.org, groug@kaod.org, qemu-ppc@nongnu.org, Suraj Jitindar Singh , 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: Suraj Jitindar Singh cpu->compat_pvr is used to store the current compat mode of the cpu. On the receiving side during incoming migration we check compatibility with the compat mode by calling ppc_set_compat(). However we fail to set the compat mode with the hypervisor since the "new" compat mode doesn't differ from the current (due to a "cpu->compat_pvr !=3D compat_pvr" check). This means that kvm runs the vcpus without a compat mode, which is the incorrect behaviour. The implication being that a compatibility mode will never be in effect after migration. To fix this so that the compat mode is correctly set with the hypervisor, store the desired compat mode and reset cpu->compat_pvr to zero before calling ppc_set_compat(). Fixes: 5dfaa532 ("ppc: fix ppc_set_compat() with KVM PR") Signed-off-by: Suraj Jitindar Singh Signed-off-by: David Gibson --- target/ppc/machine.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/target/ppc/machine.c b/target/ppc/machine.c index 384caee800..24117e8f31 100644 --- a/target/ppc/machine.c +++ b/target/ppc/machine.c @@ -237,9 +237,11 @@ static int cpu_post_load(void *opaque, int version_id) =20 #if defined(TARGET_PPC64) if (cpu->compat_pvr) { + uint32_t compat_pvr =3D cpu->compat_pvr; Error *local_err =3D NULL; =20 - ppc_set_compat(cpu, cpu->compat_pvr, &local_err); + cpu->compat_pvr =3D 0; + ppc_set_compat(cpu, compat_pvr, &local_err); if (local_err) { error_report_err(local_err); return -1; --=20 2.14.3