From patchwork Wed Jul 3 01:20:20 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Suraj Jitindar Singh X-Patchwork-Id: 1126565 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=kvm-ppc-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="jXj35Caz"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 45djwK1Lkkz9s4Y for ; Wed, 3 Jul 2019 11:20:33 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726635AbfGCBUc (ORCPT ); Tue, 2 Jul 2019 21:20:32 -0400 Received: from mail-pl1-f195.google.com ([209.85.214.195]:34402 "EHLO mail-pl1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726329AbfGCBUc (ORCPT ); Tue, 2 Jul 2019 21:20:32 -0400 Received: by mail-pl1-f195.google.com with SMTP id i2so260404plt.1 for ; Tue, 02 Jul 2019 18:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=PQ4NMu50Y3TCTLANEIOA6X2/IvBk3A44Utjy8py8evs=; b=jXj35CazM3QZbbRCCsaLsfk/Wd3IJLUgBLmEgFQvzQBcgh2GsMNzt97j8wVElT7nKm OC5eJShKiW8ihuZQU8qUEinWGcR6vlE9s9i1V1xoH0voEFAmphXy6htvudMPcMHDIGml YsNMmEEGxAQpsQHenuA0eLjKefX3OB5tuUncJw/g9Ryi/R6IGGD4+rlhp62TM+IF95mb wK4JMRDZ8051Y4qFrDXkFQdqvZbzrQb7qxa1XJ3YhNIkWC1Ctl/HzTEaxeA4EF2moYqT FVMjmwYAFBSJ6QPBaKO1O8WBjgciGjoEvML9O4YQWUiT4TrUC6a/yipM4vhZdgNhYP2b eZHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=PQ4NMu50Y3TCTLANEIOA6X2/IvBk3A44Utjy8py8evs=; b=UE898kNbo2ICWIWI3c2VoHufGAS6WNPiBXBWaaiB+lcxAZzPor/s2yBTDuRC8YUbo0 9KlD1eWo2cIib6WXGT3Pg1kvbnN22MYJxDCMyXEja+gn0pN2HRZTbYJ1MAMzsNcn9LHt IWr56omNNL0+wxXxu7NseZIx2dxdUConCsnXdaV9BZD/rfQH9B3cky3u6OI2jMDB9i2I zY0tBVv1qZwRhNe5LlpwKG7hLGU2tHqWEhrZdqI7gtHhWhxo4RcS/M+w48jfpBT4W4Sd V/CABX8EOL9P6GFNzU5tH+70R6/UH47nBjvj625ULKL5a8QXmXXdwA3Cl48j9y30svtK u7Rw== X-Gm-Message-State: APjAAAW0Uj4VY1n98UGZpljvDLP0mkQpR6/ujwGriDZnzY+encoCj1YS D1vtzscX8l0Qs5CU2JrrfH8= X-Google-Smtp-Source: APXvYqxxCayGdd1EX7v0vzne6JjklaJqMqrDnhmtEzSn0ou/oqvDY7xq7c1vlTGWVEBb67pjYVuzAg== X-Received: by 2002:a17:902:1129:: with SMTP id d38mr39113510pla.220.1562116831564; Tue, 02 Jul 2019 18:20:31 -0700 (PDT) Received: from surajjs2.ozlabs.ibm.com.ozlabs.ibm.com ([122.99.82.10]) by smtp.gmail.com with ESMTPSA id j11sm318058pfa.2.2019.07.02.18.20.29 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 02 Jul 2019 18:20:31 -0700 (PDT) From: Suraj Jitindar Singh To: linuxppc-dev@lists.ozlabs.org Cc: kvm-ppc@vger.kernel.org, mpe@ellerman.id.au, paulus@ozlabs.org, sjitindarsingh@gmail.com Subject: [PATCH 1/3] KVM: PPC: Book3S HV: Always save guest pmu for guest capable of nesting Date: Wed, 3 Jul 2019 11:20:20 +1000 Message-Id: <20190703012022.15644-1-sjitindarsingh@gmail.com> X-Mailer: git-send-email 2.13.6 Sender: kvm-ppc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm-ppc@vger.kernel.org The performance monitoring unit (PMU) registers are saved on guest exit when the guest has set the pmcregs_in_use flag in its lppaca, if it exists, or unconditionally if it doesn't. If a nested guest is being run then the hypervisor doesn't, and in most cases can't, know if the pmu registers are in use since it doesn't know the location of the lppaca for the nested guest, although it may have one for its immediate guest. This results in the values of these registers being lost across nested guest entry and exit in the case where the nested guest was making use of the performance monitoring facility while it's nested guest hypervisor wasn't. Further more the hypervisor could interrupt a guest hypervisor between when it has loaded up the pmu registers and it calling H_ENTER_NESTED or between returning from the nested guest to the guest hypervisor and the guest hypervisor reading the pmu registers, in kvmhv_p9_guest_entry(). This means that it isn't sufficient to just save the pmu registers when entering or exiting a nested guest, but that it is necessary to always save the pmu registers whenever a guest is capable of running nested guests to ensure the register values aren't lost in the context switch. Ensure the pmu register values are preserved by always saving their value into the vcpu struct when a guest is capable of running nested guests. This should have minimal performance impact however any impact can be avoided by booting a guest with "-machine pseries,cap-nested-hv=false" on the qemu commandline. Fixes: 95a6432ce903 "KVM: PPC: Book3S HV: Streamlined guest entry/exit path on P9 for radix guests" Signed-off-by: Suraj Jitindar Singh --- arch/powerpc/kvm/book3s_hv.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c index ec1804f822af..b682a429f3ef 100644 --- a/arch/powerpc/kvm/book3s_hv.c +++ b/arch/powerpc/kvm/book3s_hv.c @@ -3654,6 +3654,8 @@ int kvmhv_p9_guest_entry(struct kvm_vcpu *vcpu, u64 time_limit, vcpu->arch.vpa.dirty = 1; save_pmu = lp->pmcregs_in_use; } + /* Must save pmu if this guest is capable of running nested guests */ + save_pmu |= nesting_enabled(vcpu->kvm); kvmhv_save_guest_pmu(vcpu, save_pmu); From patchwork Wed Jul 3 01:20:21 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Suraj Jitindar Singh X-Patchwork-Id: 1126566 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=kvm-ppc-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="eE9NuW60"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 45djwQ2pMDz9sN4 for ; Wed, 3 Jul 2019 11:20:38 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727092AbfGCBUi (ORCPT ); Tue, 2 Jul 2019 21:20:38 -0400 Received: from mail-pl1-f195.google.com ([209.85.214.195]:42406 "EHLO mail-pl1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726329AbfGCBUi (ORCPT ); Tue, 2 Jul 2019 21:20:38 -0400 Received: by mail-pl1-f195.google.com with SMTP id ay6so239441plb.9 for ; Tue, 02 Jul 2019 18:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=OT+iSlP7qQxjao2KtTY/wuAA4aL+nqDFMX6/v/uNdu4=; b=eE9NuW60m15qwsjWlt+lK0mLNp+ZuO3yidTHutB9QGlwHs815nBPtwK3wKBDLwWOGd Txaa5TVWA64GJHXRg65hvqw14cbZhnm0035A4Vq4XU5pbjM/YYmEBPrzaPnHIARjzHn2 fVilXLh/wJYHl/Zao7bK3hqeSywIeWQJ+CDu0tIM295inos+mE8DuNzyZm4kZ0R3oeFi D2961o3zGGlef3sNPnvL/x0B46zGnfYJ/kr3C7nHBCj1kmc6nEFhHdBY+JMGHu9owJSB N8/pwgcCVBRsZyt3RZwqZq/zEDun9qKdgKigNJt0nv58nVsaCyQSyp3mkMe0bfP2POFw Zp0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=OT+iSlP7qQxjao2KtTY/wuAA4aL+nqDFMX6/v/uNdu4=; b=t/+5gXVASonD+dn4y7EJYwxDmYqA/V3xeq+iHDviuqU70kbGeTOjV2DQW61ZBaF432 ZylRQVjMB2EX28HAxsXFvvRDlTxB1g1MHdOzkYvzPmJWxGXSoN9fD2lC7Y0eJsQZ1L14 2ipa+Zxy4aYaSWl0qoA9i8Ss9o/UDcT+CEj5/4Pk1vic/jVrtLuPZKD0UAd0eYoc19rX IDTTmDVbjNsu8RT+DCyc+4m+7SmQ62QBJ+Fho4PdTujxLO4BbZsOOQeOm5eMk/RahOST fkkXtfwa59YpQzWd4NiQ2thnpBIIrSxkjrZW/dKio8Y0WHLnABhS9NSosIOBEKes43GJ UOGQ== X-Gm-Message-State: APjAAAWF+a9ckZ5d/IYRemLNOO29KZhd1TI6+qbz9EPbpQN2nQl2Jovm T5lSU9Z6dZv+izPtdOL+4hg= X-Google-Smtp-Source: APXvYqxICivvyS9zvkcXp4qDw3wHK9lxCyuN+p62quvHg5No7Hz1ZHyE+PQInv9p7TP3BKnA+kzhSA== X-Received: by 2002:a17:902:8d92:: with SMTP id v18mr39141154plo.211.1562116837371; Tue, 02 Jul 2019 18:20:37 -0700 (PDT) Received: from surajjs2.ozlabs.ibm.com.ozlabs.ibm.com ([122.99.82.10]) by smtp.gmail.com with ESMTPSA id j11sm318058pfa.2.2019.07.02.18.20.31 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 02 Jul 2019 18:20:36 -0700 (PDT) From: Suraj Jitindar Singh To: linuxppc-dev@lists.ozlabs.org Cc: kvm-ppc@vger.kernel.org, mpe@ellerman.id.au, paulus@ozlabs.org, sjitindarsingh@gmail.com Subject: [PATCH 2/3] PPC: PMC: Set pmcregs_in_use in paca when running as LPAR Date: Wed, 3 Jul 2019 11:20:21 +1000 Message-Id: <20190703012022.15644-2-sjitindarsingh@gmail.com> X-Mailer: git-send-email 2.13.6 In-Reply-To: <20190703012022.15644-1-sjitindarsingh@gmail.com> References: <20190703012022.15644-1-sjitindarsingh@gmail.com> Sender: kvm-ppc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm-ppc@vger.kernel.org The ability to run nested guests under KVM means that a guest can also act as a hypervisor for it's own nested guest. Currently ppc_set_pmu_inuse() assumes that either FW_FEATURE_LPAR is set, indicating a guest environment, and so sets the pmcregs_in_use flag in the lppaca, or that it isn't set, indicating a hypervisor environment, and so sets the pmcregs_in_use flag in the paca. The pmcregs_in_use flag in the lppaca is used to communicate this information to a hypervisor and so must be set in a guest environment. The pmcregs_in_use flag in the paca is used by KVM code to determine whether the host state of the performance monitoring unit (PMU) must be saved and restored when running a guest. Thus when a guest also acts as a hypervisor it must set this bit in both places since it needs to ensure both that the real hypervisor saves it's pmu registers when it runs (requires pmcregs_in_use flag in lppaca), and that it saves it's own pmu registers when running a nested guest (requires pmcregs_in_use flag in paca). Modify ppc_set_pmu_inuse() so that the pmcregs_in_use bit is set in both the lppaca and the paca when a guest (LPAR) is running with the capability of running it's own guests (CONFIG_KVM_BOOK3S_HV_POSSIBLE). Fixes: 95a6432ce903 "KVM: PPC: Book3S HV: Streamlined guest entry/exit path on P9 for radix guests" Signed-off-by: Suraj Jitindar Singh --- arch/powerpc/include/asm/pmc.h | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/include/asm/pmc.h b/arch/powerpc/include/asm/pmc.h index dc9a1ca70edf..c6bbe9778d3c 100644 --- a/arch/powerpc/include/asm/pmc.h +++ b/arch/powerpc/include/asm/pmc.h @@ -27,11 +27,10 @@ static inline void ppc_set_pmu_inuse(int inuse) #ifdef CONFIG_PPC_PSERIES get_lppaca()->pmcregs_in_use = inuse; #endif - } else { + } #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE - get_paca()->pmcregs_in_use = inuse; + get_paca()->pmcregs_in_use = inuse; #endif - } #endif } From patchwork Wed Jul 3 01:20:22 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Suraj Jitindar Singh X-Patchwork-Id: 1126567 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=kvm-ppc-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="RH/3iLds"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 45djwW33hPz9sPF for ; Wed, 3 Jul 2019 11:20:43 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727208AbfGCBUm (ORCPT ); Tue, 2 Jul 2019 21:20:42 -0400 Received: from mail-pl1-f196.google.com ([209.85.214.196]:37308 "EHLO mail-pl1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727051AbfGCBUk (ORCPT ); Tue, 2 Jul 2019 21:20:40 -0400 Received: by mail-pl1-f196.google.com with SMTP id bh12so252841plb.4 for ; Tue, 02 Jul 2019 18:20:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=q3fFTelOhqkb1Mwuc5eMY9x9ha5lfJs2EAbdT9hPUxk=; b=RH/3iLdsxo433D8bqQwGL/9FPB5yF+k0fcF0uDWNdIqHFwBKMirdOH4am3QXNHJYSn rY4r/pfbR+HzWOa8YVSKaFR9ZO0LQC9H7zOEQB9tnIzDUuqEI0/DOQsr96nFf1b3qFyb 6cXV24+vc/1EXm/XtkVqszJoIDg37R/TAYjbci2YtuwMMmUMcIx/WTBbAXc0Ia8zjZxb KlYMd6yImr8TLShte/YqPNUQ7PxXlM4kt6sNtxgzIpCoFrcMPe1vGPasbGwY0djwAzlE a+iINADzJwNendu1TCWNzcYc0hmoerC/E8aEh16OQx+UthQ07cWtau49tHUp+PXjmr6E MQ3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=q3fFTelOhqkb1Mwuc5eMY9x9ha5lfJs2EAbdT9hPUxk=; b=dWfg08apRIyjHDCnCC1TZ4wFTPuofCOUmQrEKG+J3AOZDl+0iHpvz0WsRVlIQXY9S9 fwLUXchQW18h1qPst7flZKZBZ4KrdlcJRfe0m6Pz/uqas3wakU3ueU85Mh4WnI/M+8g2 CaVs+4iqbxSBB8w8iGvRBzy4Qar+T5vWolW7iAbqBiXeehjyAW+fKA78ShgAYVDs4xBI 9nSACZTDb5wOJpTi+tX23q0478pwqOD4lBVBJZ3a9nnFP6nMg2Yh25nLvU98znd2xVC7 POvzynUanSePTiJmx4cxmocOwSFphHepv6sltQXC/oqYVhBZ7PbxvNH7HCXDT50W+SqZ X1RQ== X-Gm-Message-State: APjAAAW+CTrS8G415bQhuHklvUzBnX60SmzP+YNrxCOYEiet9pU+x766 8gXng9IQoqoOzNkr2tuw43o= X-Google-Smtp-Source: APXvYqzkt5g7kNg6hKYTqsIuNXDzDhDUtUgqHARyXeeseHu6TWKvRfxy1H2TSr3uJ1aWKFKC5zKorA== X-Received: by 2002:a17:902:684:: with SMTP id 4mr38647623plh.138.1562116840189; Tue, 02 Jul 2019 18:20:40 -0700 (PDT) Received: from surajjs2.ozlabs.ibm.com.ozlabs.ibm.com ([122.99.82.10]) by smtp.gmail.com with ESMTPSA id j11sm318058pfa.2.2019.07.02.18.20.37 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 02 Jul 2019 18:20:39 -0700 (PDT) From: Suraj Jitindar Singh To: linuxppc-dev@lists.ozlabs.org Cc: kvm-ppc@vger.kernel.org, mpe@ellerman.id.au, paulus@ozlabs.org, sjitindarsingh@gmail.com Subject: [PATCH 3/3] KVM: PPC: Book3S HV: Save and restore guest visible PSSCR bits on pseries Date: Wed, 3 Jul 2019 11:20:22 +1000 Message-Id: <20190703012022.15644-3-sjitindarsingh@gmail.com> X-Mailer: git-send-email 2.13.6 In-Reply-To: <20190703012022.15644-1-sjitindarsingh@gmail.com> References: <20190703012022.15644-1-sjitindarsingh@gmail.com> Sender: kvm-ppc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm-ppc@vger.kernel.org The performance stop status and control register (PSSCR) is used to control the power saving facilities of the processor. This register has various fields, some of which can be modified only in hypervisor state, and others which can be modified in both hypervisor and priviledged non-hypervisor state. The bits which can be modified in priviledged non-hypervisor state are referred to as guest visible. Currently the L0 hypervisor saves and restores both it's own host value as well as the guest value of the psscr when context switching between the hypervisor and guest. However a nested hypervisor running it's own nested guests (as indicated by kvmhv_on_pseries()) doesn't context switch the psscr register. This means that if a nested (L2) guest modified the psscr that the L1 guest hypervisor will run with this value, and if the L1 guest hypervisor modified this value and then goes to run the nested (L2) guest again that the L2 psscr value will be lost. Fix this by having the (L1) nested hypervisor save and restore both its host and the guest psscr value when entering and exiting a nested (L2) guest. Note that only the guest visible parts of the psscr are context switched since this is all the L1 nested hypervisor can access, this is fine however as these are the only fields the L0 hypervisor provides guest control of anyway and so all other fields are ignored. This could also have been implemented by adding the psscr register to the hv_regs passed to the L0 hypervisor as input to the H_ENTER_NESTED hcall, however this would have meant updating the structure layout and thus required modifications to both the L0 and L1 kernels. Whereas the approach used doesn't require L0 kernel modifications while achieving the same result. Fixes: 95a6432ce903 "KVM: PPC: Book3S HV: Streamlined guest entry/exit path on P9 for radix guests" Signed-off-by: Suraj Jitindar Singh --- arch/powerpc/kvm/book3s_hv.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c index b682a429f3ef..cde3f5a4b3e4 100644 --- a/arch/powerpc/kvm/book3s_hv.c +++ b/arch/powerpc/kvm/book3s_hv.c @@ -3569,9 +3569,18 @@ int kvmhv_p9_guest_entry(struct kvm_vcpu *vcpu, u64 time_limit, mtspr(SPRN_DEC, vcpu->arch.dec_expires - mftb()); if (kvmhv_on_pseries()) { + /* + * We need to save and restore the guest visible part of the + * psscr (i.e. using SPRN_PSSCR_PR) since the hypervisor + * doesn't do this for us. Note only required if pseries since + * this is done in kvmhv_load_hv_regs_and_go() below otherwise. + */ + unsigned long host_psscr; /* call our hypervisor to load up HV regs and go */ struct hv_guest_state hvregs; + host_psscr = mfspr(SPRN_PSSCR_PR); + mtspr(SPRN_PSSCR_PR, vcpu->arch.psscr); kvmhv_save_hv_regs(vcpu, &hvregs); hvregs.lpcr = lpcr; vcpu->arch.regs.msr = vcpu->arch.shregs.msr; @@ -3590,6 +3599,8 @@ int kvmhv_p9_guest_entry(struct kvm_vcpu *vcpu, u64 time_limit, vcpu->arch.shregs.msr = vcpu->arch.regs.msr; vcpu->arch.shregs.dar = mfspr(SPRN_DAR); vcpu->arch.shregs.dsisr = mfspr(SPRN_DSISR); + vcpu->arch.psscr = mfspr(SPRN_PSSCR_PR); + mtspr(SPRN_PSSCR_PR, host_psscr); /* H_CEDE has to be handled now, not later */ if (trap == BOOK3S_INTERRUPT_SYSCALL && !vcpu->arch.nested &&