From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DEE90C6FD19 for ; Mon, 13 Mar 2023 17:23:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231344AbjCMRXW (ORCPT ); Mon, 13 Mar 2023 13:23:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43298 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231298AbjCMRWx (ORCPT ); Mon, 13 Mar 2023 13:22:53 -0400 Received: from mail-pl1-x649.google.com (mail-pl1-x649.google.com [IPv6:2607:f8b0:4864:20::649]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E5F5A72B0D for ; Mon, 13 Mar 2023 10:22:00 -0700 (PDT) Received: by mail-pl1-x649.google.com with SMTP id s8-20020a170902b18800b0019c92f56a8aso7572519plr.22 for ; Mon, 13 Mar 2023 10:22:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1678728071; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=6T1FQzdq6ySi1rIwhJyo74NnzXWN8IL63XLJcIURd30=; b=NCrllu0cypSlyHtfYfnDii1y8LyzSvcc2SYpEkINqE5iKRucAG5Swb2pBV5/VHDqJp k15ND+xGJzBoEqpqPJnBxygkn2p7oF3VYUZHqjJ+HRSc02ZHRiOrGVZMB9AovrMKQRAw LuE3+eFR/EW9HvUCuLcAvpG1+SK+QPGeNLlNON/OPmFpnL3RViya8NRf3AA/hxxwGwib qgn7TYoyPKMnMc3GfvBgnOW7WnMa2a8PVnjOqJHFbRsXt3WLmXB9O9R6s0O+h2lvGOO7 YDqzbMQf6oBxCMTBVuHREGXQHz3euArR6zCyckO+3M1EmdWnXUKYMa7kheZ4k9cK+yu1 eifg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678728071; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=6T1FQzdq6ySi1rIwhJyo74NnzXWN8IL63XLJcIURd30=; b=Qj5NquSP14QYmRkM3vVbQiWXUkgpeDqy1mdgqyHlyFQ358Q2uzapxweQFLP01sU7pL jxMpyyyJKK0vhEsr1TgWn4sZHGycrJitn8E0gGFDJ4Mj2N7MCXnzUof2r7TzYT85Bw8v ic9Yd4lyPyhgg2fzw+Y9CnTaG7SZeGDFBTSUfn9nOTmrlPJfoaJkhNNpynTHBtjyMcUe m7Oqb1b3By+vOFEgSiE4AJlbe+pcpkqoxYjpSausOgV/JIAOqhCC0N999EUZgyXui3de N0s4Lc0FN+TDwxmGafZ9PTXYzrZMGmrbSd89JKw+HqnlgRtHY3vfQogVQgTzqWMrWjGs L29Q== X-Gm-Message-State: AO0yUKXYb+cifsUEpZM0/ddZcuQciyHt7fel9aggO6LciMsfJLb9rbi4 0GCMU4a5m03ujZzmMbNVDER6GFAtp5Q= X-Google-Smtp-Source: AK7set8B3CeFNCeFlI5qCMlp/uO9ITN1guOuZisHUyY14k69LU+SjjJ6+snECmGiZWES/zdYV86/vdKAdjA= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6a00:2136:b0:590:3182:7ac3 with SMTP id n22-20020a056a00213600b0059031827ac3mr13418688pfj.0.1678728071185; Mon, 13 Mar 2023 10:21:11 -0700 (PDT) Date: Mon, 13 Mar 2023 10:21:09 -0700 In-Reply-To: Mime-Version: 1.0 References: <20230313091425.1962708-1-maz@kernel.org> <20230313091425.1962708-2-maz@kernel.org> Message-ID: Subject: Re: [PATCH 1/2] KVM: arm64: Disable interrupts while walking userspace PTs From: Sean Christopherson To: David Matlack Cc: Marc Zyngier , kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, James Morse , Suzuki K Poulose , Oliver Upton , Zenghui Yu , Ard Biesheuvel , Will Deacon , Quentin Perret , stable@vger.kernel.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org On Mon, Mar 13, 2023, David Matlack wrote: > On Mon, Mar 13, 2023 at 8:53=E2=80=AFAM Sean Christopherson wrote: > > > > +David > > > > On Mon, Mar 13, 2023, Marc Zyngier wrote: > > > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c > > > index 7113587222ff..d7b8b25942df 100644 > > > --- a/arch/arm64/kvm/mmu.c > > > +++ b/arch/arm64/kvm/mmu.c > > > @@ -666,14 +666,23 @@ static int get_user_mapping_size(struct kvm *kv= m, u64 addr) > > > CONFIG_PGTABLE_LEVELS), > > > .mm_ops =3D &kvm_user_mm_ops, > > > }; > > > + unsigned long flags; > > > kvm_pte_t pte =3D 0; /* Keep GCC quiet... */ > > > u32 level =3D ~0; > > > int ret; > > > > > > + /* > > > + * Disable IRQs so that we hazard against a concurrent > > > + * teardown of the userspace page tables (which relies on > > > + * IPI-ing threads). > > > + */ > > > + local_irq_save(flags); > > > ret =3D kvm_pgtable_get_leaf(&pgt, addr, &pte, &level); > > > - VM_BUG_ON(ret); > > > - VM_BUG_ON(level >=3D KVM_PGTABLE_MAX_LEVELS); > > > - VM_BUG_ON(!(pte & PTE_VALID)); > > > + local_irq_restore(flags); > > > + > > > + /* Oops, the userspace PTs are gone... */ > > > + if (ret || level >=3D KVM_PGTABLE_MAX_LEVELS || !(pte & PTE_VAL= ID)) > > > + return -EFAULT; > > > > I don't think this should return -EFAULT all the way out to userspace. = Unless > > arm64 differs from x86 in terms of how the userspace page tables are ma= naged, not > > having a valid translation _right now_ doesn't mean that one can't be c= reated in > > the future, e.g. by way of a subsequent hva_to_pfn(). > > > > FWIW, the approach x86 takes is to install a 4KiB (smallest granuale) t= ranslation, >=20 > If I'm reading the ARM code correctly, returning -EFAULT here will > have that effect. get_user_mapping_size() is only called by > transparent_hugepage_adjust() which returns PAGE_SIZE if > get_user_mapping_size() returns anything less than PMD_SIZE. No, this patch adds + int sz =3D get_user_mapping_size(kvm, hva); + + if (sz < 0) + return sz; + + if (sz < PMD_SIZE) + return PAGE_SIZE; + and=20 vma_pagesize =3D transparent_hugepage_adjust(kvm, m= emslot, hva, &pf= n, &fault_i= pa); + + if (vma_pagesize < 0) { + ret =3D vma_pagesize; + goto out_unlock; + }