From patchwork Thu May 17 04:48:49 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paul Mackerras X-Patchwork-Id: 915069 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=none (p=none dis=none) header.from=ozlabs.org Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; secure) header.d=ozlabs.org header.i=@ozlabs.org header.b="rkqYQyOt"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 40mf2w5VYnz9s3c for ; Thu, 17 May 2018 14:48:56 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750815AbeEQEsz (ORCPT ); Thu, 17 May 2018 00:48:55 -0400 Received: from ozlabs.org ([203.11.71.1]:34055 "EHLO ozlabs.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750801AbeEQEsy (ORCPT ); Thu, 17 May 2018 00:48:54 -0400 Received: by ozlabs.org (Postfix, from userid 1003) id 40mf2r5KyFz9s3B; Thu, 17 May 2018 14:48:52 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ozlabs.org; s=201707; t=1526532532; bh=ImahdHIsEsmoIW3S1KgFa8y2g3PINq0voVQeDGpdlbM=; h=Date:From:To:Subject:From; b=rkqYQyOtJQPq/lJLCQnRMcpec17MvHFVjkJtVcoDFGua3Af6ZY236vz9ttQ50fnVi mLR8INnVwsdeksUqfN3nGNYqLdunbv2ZQy1rYYQeCrhxXA5En2PvCk/K/uX3dvPtrk p3U2hsz2ZpvkXBfQ2C/YRiGaqAY03c3ELTAvNik6RG2VJwBwBqXGxw6ygy7rfEXGUu uqCu//aZa/Ski3GH/XGMzGS0SLb5BFJiHvqiBHGhBrLwjY3KpEzTGx/bf+XyxdQFVc xb4mVc5wI4rm+3FqE3jqSo21uTtBkp4dOVXPhkONKSOCq03Pt83Y+abnXa8WkY+Q09 HQ8vFFJaBZ1XA== Date: Thu, 17 May 2018 14:48:49 +1000 From: Paul Mackerras To: kvm-ppc@vger.kernel.org, kvm@vger.kernel.org Subject: [PATCH] KVM: PPC: Book 3S HV: Do ptesync in radix guest exit path Message-ID: <20180517044849.GB31160@fergus.ozlabs.ibm.com> MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Sender: kvm-ppc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: kvm-ppc@vger.kernel.org A radix guest can execute tlbie instructions to invalidate TLB entries. After a tlbie or a group of tlbies, it must then do the architected sequence eieio; tlbsync; ptesync to ensure that the TLB invalidation has been processed by all CPUs in the system before it can rely on no CPU using any translation that it just invalidated. In fact it is the ptesync which does the actual synchronization in this sequence, and hardware has a requirement that the ptesync must be executed on the same CPU thread as the tlbies which it is expected to order. Thus, if a vCPU gets moved from one physical CPU to another after it has done some tlbies but before it can get to do the ptesync, the ptesync will not have the desired effect when it is executed on the second physical CPU. To fix this, we do a ptesync in the exit path for radix guests. If there are any pending tlbies, this will wait for them to complete. If there aren't, then ptesync will just do the same as sync. Signed-off-by: Paul Mackerras --- arch/powerpc/kvm/book3s_hv_rmhandlers.S | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S index bd63fa8..122726b 100644 --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S @@ -1905,6 +1905,14 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_300) cmpwi cr2, r0, 0 beq cr2, 4f + /* + * Radix: do eieio; tlbsync; ptesync sequence in case we + * interrupted the guest between a tlbie and a ptesync. + */ + eieio + tlbsync + ptesync + /* Radix: Handle the case where the guest used an illegal PID */ LOAD_REG_ADDR(r4, mmu_base_pid) lwz r3, VCPU_GUEST_PID(r9)