Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp1201687ybz; Thu, 16 Apr 2020 04:59:46 -0700 (PDT) X-Google-Smtp-Source: APiQypIzur6GaU+MrwkmODcAf3giJUpFVLKfrMcsMJaaw3kZEDNc8agB1aHo95o4QWCNV5lT5uG5 X-Received: by 2002:a17:906:90cc:: with SMTP id v12mr9374678ejw.211.1587038386506; Thu, 16 Apr 2020 04:59:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587038386; cv=none; d=google.com; s=arc-20160816; b=LRbH2lQFZ15hd+cb1SKuIlTijUyspvHezN97oy3bR84cGR8DFTp2l3tT3Z+r08Gvys vApaELRufyEYiJ3Ev5kY4M9oZt+xXP4lBcjrP5eQP+o6kzP3MefPAECldWIE+K7Hgvfw ab345pwg8d1QIQ/uTknkfoOmyeQTqmxkG+vg1OVZ3DBxyfzcf7Tb9DFCmkwAWsAZfB19 qndMste5eK2hVKGZPuOe2cA/khgHTRVBRvbKa02V6XKV/J1ps9YyMa6RNZKc62D+oaCT Gi7ZkrCQt4pl+o4gn9/GR1Clr2djrw1g1+E9+oKNKyq0sMwY/1bHNVUGDKKaQOPmLkCF 5Pvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=AeQKceCFW8piOTFZxep47ycB7mXVhIZIl/Blh9qELPk=; b=0bJChwbagwiLSkdrMprvyHx4Yp8a8YJ9RuIx3p7oOci9JccOM0h4wWT8sp3nxhcURl N9jM5KPeEW/KJoDlRPXvZcbK5Ya1Xy/OhVvH1+otEM4JfLXbir+HYbLYWZ5k/VQiiDl3 18mh25Po9OLJ8JIN01X4gygEGhbWsUGWuhm4faR7Q2xJw4zLyPfQq9MJAS4kbd4chYhX 9whF95HeJnynF5+Xq7rp1XXskZlgktH71tD3Vs7E/cRcHf8CQOmEUW8l+xB5j5MKalRD 70kEiGb+154MlPm2C+WDlsJ648ktlUsT8TPOb29lTgIczjuZLPJ02+CFON/t4kunDIPI AoaA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y16si11914669eje.311.2020.04.16.04.59.23; Thu, 16 Apr 2020 04:59:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2634216AbgDPL5T (ORCPT + 99 others); Thu, 16 Apr 2020 07:57:19 -0400 Received: from 5.mo69.mail-out.ovh.net ([46.105.43.105]:51481 "EHLO 5.mo69.mail-out.ovh.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2634512AbgDPL45 (ORCPT ); Thu, 16 Apr 2020 07:56:57 -0400 Received: from player699.ha.ovh.net (unknown [10.110.208.144]) by mo69.mail-out.ovh.net (Postfix) with ESMTP id F1C938B908 for ; Thu, 16 Apr 2020 10:07:56 +0200 (CEST) Received: from kaod.org (82-64-250-170.subs.proxad.net [82.64.250.170]) (Authenticated sender: clg@kaod.org) by player699.ha.ovh.net (Postfix) with ESMTPSA id 5E029116DD815; Thu, 16 Apr 2020 08:07:49 +0000 (UTC) Subject: Re: [PATCH] KVM: PPC: Book3S HV: Handle non-present PTEs in page fault functions To: Paul Mackerras , kvm@vger.kernel.org, kvm-ppc@vger.kernel.org Cc: linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, groug@kaod.org, David Gibson References: <20200416050335.GB10545@blackberry> From: =?UTF-8?Q?C=c3=a9dric_Le_Goater?= Message-ID: Date: Thu, 16 Apr 2020 10:07:49 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <20200416050335.GB10545@blackberry> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 1322932392823262182 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrfeehucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepuffvfhfhkffffgggjggtgfesthekredttdefjeenucfhrhhomhepveorughrihgtpgfnvggpifhorghtvghruceotghlgheskhgrohgurdhorhhgqeenucffohhmrghinheprhgvughhrghtrdgtohhmnecukfhppedtrddtrddtrddtpdekvddrieegrddvhedtrddujedtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpqdhouhhtpdhhvghlohepphhlrgihvghrieelledrhhgrrdhovhhhrdhnvghtpdhinhgvtheptddrtddrtddrtddpmhgrihhlfhhrohhmpegtlhhgsehkrghougdrohhrghdprhgtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhrgh Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/16/20 7:03 AM, Paul Mackerras wrote: > Since cd758a9b57ee "KVM: PPC: Book3S HV: Use __gfn_to_pfn_memslot in HPT > page fault handler", it's been possible in fairly rare circumstances to > load a non-present PTE in kvmppc_book3s_hv_page_fault() when running a > guest on a POWER8 host. > > Because that case wasn't checked for, we could misinterpret the non-present > PTE as being a cache-inhibited PTE. That could mismatch with the > corresponding hash PTE, which would cause the function to fail with -EFAULT > a little further down. That would propagate up to the KVM_RUN ioctl() > generally causing the KVM userspace (usually qemu) to fall over. > > This addresses the problem by catching that case and returning to the guest > instead, letting it fault again, and retrying the whole page fault from > the beginning. > > For completeness, this fixes the radix page fault handler in the same > way. For radix this didn't cause any obvious misbehaviour, because we > ended up putting the non-present PTE into the guest's partition-scoped > page tables, leading immediately to another hypervisor data/instruction > storage interrupt, which would go through the page fault path again > and fix things up. > > Fixes: cd758a9b57ee "KVM: PPC: Book3S HV: Use __gfn_to_pfn_memslot in HPT page fault handler" > Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1820402 > Reported-by: David Gibson > Signed-off-by: Paul Mackerras I didn't see the reported issue with the current 5.7-rc1. Anyhow I gave this patch a try on a P8 host and a P9 host with a radix guest and a hash guest (using rhel6). Passthrough is fine also. Tested-by: Cédric Le Goater The code looks correct, Reviewed-by: Cédric Le Goater Thanks, C. > --- > This is a reworked version of the patch David Gibson sent recently, > with the fix applied to the radix case as well. The commit message > is mostly stolen from David's patch. > > arch/powerpc/kvm/book3s_64_mmu_hv.c | 9 +++++---- > arch/powerpc/kvm/book3s_64_mmu_radix.c | 9 +++++---- > 2 files changed, 10 insertions(+), 8 deletions(-) > > diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c b/arch/powerpc/kvm/book3s_64_mmu_hv.c > index 3aecec8..20b7dce 100644 > --- a/arch/powerpc/kvm/book3s_64_mmu_hv.c > +++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c > @@ -604,18 +604,19 @@ int kvmppc_book3s_hv_page_fault(struct kvm_run *run, struct kvm_vcpu *vcpu, > */ > local_irq_disable(); > ptep = __find_linux_pte(vcpu->arch.pgdir, hva, NULL, &shift); > + pte = __pte(0); > + if (ptep) > + pte = *ptep; > + local_irq_enable(); > /* > * If the PTE disappeared temporarily due to a THP > * collapse, just return and let the guest try again. > */ > - if (!ptep) { > - local_irq_enable(); > + if (!pte_present(pte)) { > if (page) > put_page(page); > return RESUME_GUEST; > } > - pte = *ptep; > - local_irq_enable(); > hpa = pte_pfn(pte) << PAGE_SHIFT; > pte_size = PAGE_SIZE; > if (shift) > diff --git a/arch/powerpc/kvm/book3s_64_mmu_radix.c b/arch/powerpc/kvm/book3s_64_mmu_radix.c > index 134fbc1..7bf94ba 100644 > --- a/arch/powerpc/kvm/book3s_64_mmu_radix.c > +++ b/arch/powerpc/kvm/book3s_64_mmu_radix.c > @@ -815,18 +815,19 @@ int kvmppc_book3s_instantiate_page(struct kvm_vcpu *vcpu, > */ > local_irq_disable(); > ptep = __find_linux_pte(vcpu->arch.pgdir, hva, NULL, &shift); > + pte = __pte(0); > + if (ptep) > + pte = *ptep; > + local_irq_enable(); > /* > * If the PTE disappeared temporarily due to a THP > * collapse, just return and let the guest try again. > */ > - if (!ptep) { > - local_irq_enable(); > + if (!pte_present(pte)) { > if (page) > put_page(page); > return RESUME_GUEST; > } > - pte = *ptep; > - local_irq_enable(); > > /* If we're logging dirty pages, always map single pages */ > large_enable = !(memslot->flags & KVM_MEM_LOG_DIRTY_PAGES); >