From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f201.google.com (mail-yw1-f201.google.com [209.85.128.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7667D125A9 for ; Wed, 6 Sep 2023 22:03:26 +0000 (UTC) Received: by mail-yw1-f201.google.com with SMTP id 00721157ae682-58fc448ee4fso3906907b3.2 for ; Wed, 06 Sep 2023 15:03:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1694037805; x=1694642605; darn=lists.linux.dev; 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=jGjz0wwIvGFqvXEmPizGTlbv+e1jyl/6EbitI2f252Y=; b=zJP9Zu2X9qzKcy0Wsuywdnwr+Gu5zA+bTxHqZJ6xYogq38Q2lvST60Fce/BvGaOl9s YPy6gxdMRGiqYC7FdIlmt4+B2nnqZcQnWWLB2aJX73eAjpONx4GNkiFDGiXbO6bt2AyB W5V8DSAtWlbOcDtUZr3tI8sWJponzhike3C0ymLyph9vrxT5T1OiFjwJBF15ajtFy4m8 JOAZBubMIbjmbwIIfGZGseKbpuXdrXf49R+zbW1kveE0LVe6q7lu/6jkVsJCE7k29w1d 8fGP1AtuGyYSlV/Tnu9LhOWzabJyMXOTP3tYkYufvpEy71u66JitjAPL8P8cPhAnzM55 PG5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1694037805; x=1694642605; 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=jGjz0wwIvGFqvXEmPizGTlbv+e1jyl/6EbitI2f252Y=; b=SKZZdkaRzgkQKorTHfXeR3XA1tdqujE4AUUl0qe389ugfEF7ajBI1U9QyJwC4ItLbK js1eIHqUIyvOZknYEdGR+pKwEJNVVYoz0euDPwGxcN83jyUGRxNVKjX3o88ntC4qoBEo sJnz/PSBByP5YWhu9F48uHQBSmR8OJD4utR1RsGFocmA23ZiF/DTWLG5BcGNcaJK7LZB RlDYU1Wm2lAVAut25qp0ShHkDFH5ZC+BXmCj4qxwMqQKogfR04B0Bh8B+czOY5C9Fn9C PrQFt86uUMaCRggxt9Mx0d+8gQOWr+At41Mw94X8/uI5JtQXYrB7ZkFlnwenhhGynUTp 8NKw== X-Gm-Message-State: AOJu0Yw1vyH7j/mBRIA7J/2S1lH50BhOv0nsVW+dGb/Op2P/ebfY/l3O k8n7bQfyDiqhn7r7mxdEeQ3YZFaLZts= X-Google-Smtp-Source: AGHT+IGOMcVTpbC+lxuJRrEEC94mRP+gmjhMRarxpVWopTpRuNtLEn0yjfIpL45dRKz4q3Wh4Fcwje8c9EI= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:40d0:0:b0:d7b:9902:fb3d with SMTP id n199-20020a2540d0000000b00d7b9902fb3dmr421967yba.0.1694037805327; Wed, 06 Sep 2023 15:03:25 -0700 (PDT) Date: Wed, 6 Sep 2023 15:03:23 -0700 In-Reply-To: Precedence: bulk X-Mailing-List: kvmarm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20230704075054.3344915-1-stevensd@google.com> <20230704075054.3344915-4-stevensd@google.com> <20230705161914.00004070.zhi.wang.linux@gmail.com> <20230711203348.00000fb8.zhi.wang.linux@gmail.com> Message-ID: Subject: Re: [PATCH v7 3/8] KVM: Make __kvm_follow_pfn not imply FOLL_GET From: Sean Christopherson To: David Stevens Cc: Zhi Wang , Marc Zyngier , Michael Ellerman , Peter Xu , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 06, 2023, David Stevens wrote: > On Wed, Sep 6, 2023 at 9:45=E2=80=AFAM Sean Christopherson wrote: > > > > On Tue, Sep 05, 2023, David Stevens wrote: > > > For property 2, FOLL_GET is also important. If guarded_by_mmu_notifie= r > > > is set, then we're all good here. If guarded_by_mmu_notifier is not > > > set, then the check in __kvm_follow_pfn guarantees that FOLL_GET is > > > set. For struct page memory, we're safe because KVM will hold a > > > reference as long as it's still using the page. For non struct page > > > memory, we're not safe - this is where the breaking change of > > > allow_unsafe_mappings would go. Note that for non-refcounted struct > > > page, we can't use the allow_unsafe_mappings escape hatch. Since > > > FOLL_GET was requested, if we returned such a page, then the caller > > > would eventually corrupt the page refcount via kvm_release_pfn. > > > > Yes we can. The caller simply needs to be made aware of is_refcounted_= page. I > > didn't include that in the snippet below because I didn't want to write= the entire > > patch. The whole point of adding is_refcounted_page is so that callers= can > > identify exactly what type of page was at the end of the trail that was= followed. >=20 > Are you asking me to completely migrate every caller of any gfn_to_pfn > variant to __kvm_follow_pfn, so that they can respect > is_refcounted_page? That's the only way to make it safe for > allow_unsafe_mappings to apply to non-refcounted pages. That is > decidedly not simple. Or is kvm_vcpu_map the specific call site you > care about? At best, I can try to migrate x86, and then just add some > sort of compatibility shim for other architectures that rejects > non-refcounted pages. Ah, I see your conundrum. No, I don't think it's reasonable to require you= to convert all users in every architecture. I'll still ask, just in case you'= re feeling generous, but it's not a requirement :-) The easiest way forward I can think of is to add yet another flag to kvm_fo= llow_pfn, e.g. allow_non_refcounted_struct_page, to communicate whether or not the ca= ller has been enlightened to play nice with non-refcounted struct page memory. = We'll need that flag no matter what, otherwise we'd have to convert all users in = a single patch (LOL). Then your series can simply stop at a reasonable point, e.g. = convert all x86 usage (including kvm_vcpu_map(), and leave converting everything el= se to future work. E.g. I think this would be the outro of hva_to_pfn_remapped(): if (!page) goto out; if (get_page_unless_zero(page)) WARN_ON_ONCE(kvm_follow_refcounted_pfn(foll, page) !=3D pfn= ); out: pte_unmap_unlock(ptep, ptl); /* * TODO: Drop allow_non_refcounted_struct_page once all callers have * been taught to play nice with non-refcounted tail pages. */ if (page && !foll->is_refcounted_page && !foll->allow_non_refcounted_struct_page) r =3D -EFAULT else if (!foll->is_refcounted_page && !foll->guarded_by_mmu_notifie= r && !allow_unsafe_mappings) r =3D -EFAULT; else *p_pfn =3D pfn; return r; > > > Property 3 would be nice, but we've already concluded that guarding > > > all translations with mmu notifiers is infeasible. So maintaining > > > property 2 is the best we can hope for. > > > > No, #3 is just a variant of #2. Unless you're talking about not making= guarantees > > about guest accesses being ordered with respect to VMA/memslot updates,= but I > > don't think that's the case. >=20 > I'm talking about the fact that kvm_vcpu_map is busted with respect to > updates to VMA updates. It won't corrupt host memory because the > mapping keeps a reference to the page, but it will continue to use > stale translations. True. But barring some crazy paravirt use case, userspace modifying a mapp= ing that is in active use is inherently broken, the guest will have no idea tha= t memory just got yanked away. Hmm, though I suppose userspace could theoretically mprotect() a mapping to= be read-only, which would "work" for mmu_notifier paths but not kvm_vcpu_map()= . But KVM doesn't provide enough information on -EFAULT for userspace to do anyth= ing in response to a write to read-only memory, so in practice that's likely inher= ently broken too. > From [1], it sounds like you've granted that fixing that is not feasible,= so > I just wanted to make sure that this isn't the "unsafe" referred to by > allow_unsafe_mappings. Right, this is not the "unsafe" I'm referring to. > [1] https://lore.kernel.org/all/ZBEEQtmtNPaEqU1i@google.com/ 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 lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3EAFBEE14A9 for ; Wed, 6 Sep 2023 22:04:23 +0000 (UTC) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20221208 header.b=InaBS0MY; dkim-atps=neutral Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4RgxH94nX9z3cD3 for ; Thu, 7 Sep 2023 08:04:21 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20221208 header.b=InaBS0MY; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=flex--seanjc.bounces.google.com (client-ip=2607:f8b0:4864:20::b49; helo=mail-yb1-xb49.google.com; envelope-from=3lff4zaykdc4cokxtmqyyqvo.mywvsxehzzm-nofvscdc.yjvklc.ybq@flex--seanjc.bounces.google.com; receiver=lists.ozlabs.org) Received: from mail-yb1-xb49.google.com (mail-yb1-xb49.google.com [IPv6:2607:f8b0:4864:20::b49]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4RgxGB6nC1z2xdp for ; Thu, 7 Sep 2023 08:03:30 +1000 (AEST) Received: by mail-yb1-xb49.google.com with SMTP id 3f1490d57ef6-d7ec9300c51so328357276.3 for ; Wed, 06 Sep 2023 15:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1694037805; x=1694642605; darn=lists.ozlabs.org; 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=jGjz0wwIvGFqvXEmPizGTlbv+e1jyl/6EbitI2f252Y=; b=InaBS0MYeCDvBqMnUAYSgjZcM5mmZC6LrQ2CH3NI9tDDJ6DTGcyVY2K+VUbJSPe3iw 3S+1nS84SYfHa9thq8ZAZkwcxJ1H7ZNnBvtVsz1jLaLEymgoo/mVY6yyB8GL2T38hHsU HN6A2UAm88My4B3snPzkGxl7MxMvxoM54m7CzOfsqdWlAiFlNAolDCO1KCVkUgQfKyVC fG/sp8AJSaNDifxzeI/ub391LONL+ZrBlsYmxidU1x1jAkfLsV9zOIWd4FIJ1HznloZ0 Ulj7BjFdw0dBEleSIgHvZlq6NZYXWNJOo3fqrXRV6Kdul2MEtpZLd0zjkcqtwKr5Pwf5 orSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1694037805; x=1694642605; 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=jGjz0wwIvGFqvXEmPizGTlbv+e1jyl/6EbitI2f252Y=; b=BuRcZH0Ki2OZq4UOK38yaHgR2GBk9JrLMpFSAxZc1xpxEvQ68vt91lRqfRrV8ljeFA G6KeJMcD7XKwDzIm/PO72TupGIfWYx2lB9UmJFROSkbiuIcXF5/dDALG+BgolzJ56u/6 h2E9ohliGQk3WoAxBEyfQgI6kKAy+zWzvbp3RtjeiuCCPqqJyqXATaubqDY3Uw9XeVZF 8gNdlYjmboXKamhP0gO9u3bIu2NDPBFxPju04tOgpFBR9f2KQDhMninbSm7lFG44/zeT PZc22OSpMZkcByuGmfFgj4Ig4Yyh/U88z/tLj59dcgQMvw0QOyZviaS/bRmPWdYkUb2e JOog== X-Gm-Message-State: AOJu0YylGONSzsMHjwn2MjfnBgg+z0qIvoAgHq8FGZ5gkrdK7l8N6lwm /a7t+bWDUgAwb42MLPBZDWK9zE6kCdc= X-Google-Smtp-Source: AGHT+IGOMcVTpbC+lxuJRrEEC94mRP+gmjhMRarxpVWopTpRuNtLEn0yjfIpL45dRKz4q3Wh4Fcwje8c9EI= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:40d0:0:b0:d7b:9902:fb3d with SMTP id n199-20020a2540d0000000b00d7b9902fb3dmr421967yba.0.1694037805327; Wed, 06 Sep 2023 15:03:25 -0700 (PDT) Date: Wed, 6 Sep 2023 15:03:23 -0700 In-Reply-To: Mime-Version: 1.0 References: <20230704075054.3344915-1-stevensd@google.com> <20230704075054.3344915-4-stevensd@google.com> <20230705161914.00004070.zhi.wang.linux@gmail.com> <20230711203348.00000fb8.zhi.wang.linux@gmail.com> Message-ID: Subject: Re: [PATCH v7 3/8] KVM: Make __kvm_follow_pfn not imply FOLL_GET From: Sean Christopherson To: David Stevens Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Zhi Wang , kvm@vger.kernel.org, Marc Zyngier , linux-kernel@vger.kernel.org, Peter Xu , kvmarm@lists.linux.dev, linuxppc-dev@lists.ozlabs.org, linux-arm-kernel@lists.infradead.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Wed, Sep 06, 2023, David Stevens wrote: > On Wed, Sep 6, 2023 at 9:45=E2=80=AFAM Sean Christopherson wrote: > > > > On Tue, Sep 05, 2023, David Stevens wrote: > > > For property 2, FOLL_GET is also important. If guarded_by_mmu_notifie= r > > > is set, then we're all good here. If guarded_by_mmu_notifier is not > > > set, then the check in __kvm_follow_pfn guarantees that FOLL_GET is > > > set. For struct page memory, we're safe because KVM will hold a > > > reference as long as it's still using the page. For non struct page > > > memory, we're not safe - this is where the breaking change of > > > allow_unsafe_mappings would go. Note that for non-refcounted struct > > > page, we can't use the allow_unsafe_mappings escape hatch. Since > > > FOLL_GET was requested, if we returned such a page, then the caller > > > would eventually corrupt the page refcount via kvm_release_pfn. > > > > Yes we can. The caller simply needs to be made aware of is_refcounted_= page. I > > didn't include that in the snippet below because I didn't want to write= the entire > > patch. The whole point of adding is_refcounted_page is so that callers= can > > identify exactly what type of page was at the end of the trail that was= followed. >=20 > Are you asking me to completely migrate every caller of any gfn_to_pfn > variant to __kvm_follow_pfn, so that they can respect > is_refcounted_page? That's the only way to make it safe for > allow_unsafe_mappings to apply to non-refcounted pages. That is > decidedly not simple. Or is kvm_vcpu_map the specific call site you > care about? At best, I can try to migrate x86, and then just add some > sort of compatibility shim for other architectures that rejects > non-refcounted pages. Ah, I see your conundrum. No, I don't think it's reasonable to require you= to convert all users in every architecture. I'll still ask, just in case you'= re feeling generous, but it's not a requirement :-) The easiest way forward I can think of is to add yet another flag to kvm_fo= llow_pfn, e.g. allow_non_refcounted_struct_page, to communicate whether or not the ca= ller has been enlightened to play nice with non-refcounted struct page memory. = We'll need that flag no matter what, otherwise we'd have to convert all users in = a single patch (LOL). Then your series can simply stop at a reasonable point, e.g. = convert all x86 usage (including kvm_vcpu_map(), and leave converting everything el= se to future work. E.g. I think this would be the outro of hva_to_pfn_remapped(): if (!page) goto out; if (get_page_unless_zero(page)) WARN_ON_ONCE(kvm_follow_refcounted_pfn(foll, page) !=3D pfn= ); out: pte_unmap_unlock(ptep, ptl); /* * TODO: Drop allow_non_refcounted_struct_page once all callers have * been taught to play nice with non-refcounted tail pages. */ if (page && !foll->is_refcounted_page && !foll->allow_non_refcounted_struct_page) r =3D -EFAULT else if (!foll->is_refcounted_page && !foll->guarded_by_mmu_notifie= r && !allow_unsafe_mappings) r =3D -EFAULT; else *p_pfn =3D pfn; return r; > > > Property 3 would be nice, but we've already concluded that guarding > > > all translations with mmu notifiers is infeasible. So maintaining > > > property 2 is the best we can hope for. > > > > No, #3 is just a variant of #2. Unless you're talking about not making= guarantees > > about guest accesses being ordered with respect to VMA/memslot updates,= but I > > don't think that's the case. >=20 > I'm talking about the fact that kvm_vcpu_map is busted with respect to > updates to VMA updates. It won't corrupt host memory because the > mapping keeps a reference to the page, but it will continue to use > stale translations. True. But barring some crazy paravirt use case, userspace modifying a mapp= ing that is in active use is inherently broken, the guest will have no idea tha= t memory just got yanked away. Hmm, though I suppose userspace could theoretically mprotect() a mapping to= be read-only, which would "work" for mmu_notifier paths but not kvm_vcpu_map()= . But KVM doesn't provide enough information on -EFAULT for userspace to do anyth= ing in response to a write to read-only memory, so in practice that's likely inher= ently broken too. > From [1], it sounds like you've granted that fixing that is not feasible,= so > I just wanted to make sure that this isn't the "unsafe" referred to by > allow_unsafe_mappings. Right, this is not the "unsafe" I'm referring to. > [1] https://lore.kernel.org/all/ZBEEQtmtNPaEqU1i@google.com/ 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 7DD15EE14D3 for ; Wed, 6 Sep 2023 22:03:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:From:Subject:Message-ID: References:Mime-Version:In-Reply-To:Date:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=XTA2Q/lELqjZay3EW/eOViyT3su/5EDtqZf7ZDPKP6o=; b=ixBecukJxzXLyV4Is4zx94dzmW B1DHJO1fPErS+4HsSqohasDml4uRciykHer2hjtsFOS5A6Mmj73xGhUhvfIvIGLFfT+vRKMjiyWGX DTJsPJJRbdFGyM4ktWn0SKsM4nuKpiMJR+wdp5ZsVjJN+8qxveWeCdThiV0M3pjTFhHSVArTpWDE0 mcTZe4GVVJw+OteaJxL71+J9MiQBLsq0bIecGlSwtzyQtHsoCLAdoBj/2VvvbfP/jJ9dIePLj1uZc j+PIdw/A+fGV2bd4W6r8SfcuhW/zCrb/4I6VYOFo8tqWH43KgBmAIDSrVIDZoy4eAMFm6hWqYR6ND b/nbR52g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qe0cU-00Ax6V-2p; Wed, 06 Sep 2023 22:03:30 +0000 Received: from mail-yb1-xb4a.google.com ([2607:f8b0:4864:20::b4a]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qe0cR-00Ax5F-31 for linux-arm-kernel@lists.infradead.org; Wed, 06 Sep 2023 22:03:29 +0000 Received: by mail-yb1-xb4a.google.com with SMTP id 3f1490d57ef6-cf4cb742715so329316276.2 for ; Wed, 06 Sep 2023 15:03:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1694037805; x=1694642605; darn=lists.infradead.org; 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=jGjz0wwIvGFqvXEmPizGTlbv+e1jyl/6EbitI2f252Y=; b=5VEyt5E0gE5l0RuxfwGMqqPv3iSJ0vfzb81fj1T57/Bc37sU4vaLnGmJFPLCDNhEDW +I7sj/DZhpviZrqt03Vc8qbB4tit5+cm3SoyDZuG/RPR3hkfbn4myWzSLVVXA72RWzzP 79ljVo8kfLlvZgbEdmQjQmBUM+ngdOtqEn1KFmXhpfKAvMUlzdIQqHKuO34ma+J8s47H echwAAgOclnkjuXqgObZF26Swre8cP5m3rIeW6MPKeQvHCNLhHUgANde8DP80IFRlIpw qbdsaEyvSxHRedA4Ujz4zRzcgsEw0/QDPFiOKKbfK+w/TFcAIS/+EZahhCPBU9OOn3/U QE3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1694037805; x=1694642605; 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=jGjz0wwIvGFqvXEmPizGTlbv+e1jyl/6EbitI2f252Y=; b=RKFYcO5gTcBVCtDUYbKbcKcH+YelgxboUUsIW3qtqFsrk2nce2dEf0SH8SjnLA8AxT J+aYIuBfnkKhTR19bgD5qQptPep6sqrrG/GdbyF6v74gp/FCn6bd9OwqbvFRn4pTUS0Z +yIdKxtINhfFvP8OSpRKmGIpVxEwFZaGoTO4XvrQErD7D3sd4Y2pN+0v48OaQxgyGhac W2nXVi9F9mSsXvBBy1FgnZ8G3eyPH7MaOLUxDoEhiKj8IN+eLgjmNbKRFUVf142XpvKn 0Jm1mP/2CN4tKxJjlNQ1AgQ69g6zBA45VMlzrMQXI6sh9oIWotqYBP0MyD12+cZojnN2 ngbA== X-Gm-Message-State: AOJu0YxjctepSVv/FNjo8Nmi7cf6k7YCTc7l3l3mSfTiZWODLrEJvlqA soJ6UoeuSD4FD9wJ16iLMyDVe+O251c= X-Google-Smtp-Source: AGHT+IGOMcVTpbC+lxuJRrEEC94mRP+gmjhMRarxpVWopTpRuNtLEn0yjfIpL45dRKz4q3Wh4Fcwje8c9EI= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:40d0:0:b0:d7b:9902:fb3d with SMTP id n199-20020a2540d0000000b00d7b9902fb3dmr421967yba.0.1694037805327; Wed, 06 Sep 2023 15:03:25 -0700 (PDT) Date: Wed, 6 Sep 2023 15:03:23 -0700 In-Reply-To: Mime-Version: 1.0 References: <20230704075054.3344915-1-stevensd@google.com> <20230704075054.3344915-4-stevensd@google.com> <20230705161914.00004070.zhi.wang.linux@gmail.com> <20230711203348.00000fb8.zhi.wang.linux@gmail.com> Message-ID: Subject: Re: [PATCH v7 3/8] KVM: Make __kvm_follow_pfn not imply FOLL_GET From: Sean Christopherson To: David Stevens Cc: Zhi Wang , Marc Zyngier , Michael Ellerman , Peter Xu , linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230906_150327_993465_20CD45E3 X-CRM114-Status: GOOD ( 38.07 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org T24gV2VkLCBTZXAgMDYsIDIwMjMsIERhdmlkIFN0ZXZlbnMgd3JvdGU6Cj4gT24gV2VkLCBTZXAg NiwgMjAyMyBhdCA5OjQ14oCvQU0gU2VhbiBDaHJpc3RvcGhlcnNvbiA8c2VhbmpjQGdvb2dsZS5j b20+IHdyb3RlOgo+ID4KPiA+IE9uIFR1ZSwgU2VwIDA1LCAyMDIzLCBEYXZpZCBTdGV2ZW5zIHdy b3RlOgo+ID4gPiBGb3IgcHJvcGVydHkgMiwgRk9MTF9HRVQgaXMgYWxzbyBpbXBvcnRhbnQuIElm IGd1YXJkZWRfYnlfbW11X25vdGlmaWVyCj4gPiA+IGlzIHNldCwgdGhlbiB3ZSdyZSBhbGwgZ29v ZCBoZXJlLiBJZiBndWFyZGVkX2J5X21tdV9ub3RpZmllciBpcyBub3QKPiA+ID4gc2V0LCB0aGVu IHRoZSBjaGVjayBpbiBfX2t2bV9mb2xsb3dfcGZuIGd1YXJhbnRlZXMgdGhhdCBGT0xMX0dFVCBp cwo+ID4gPiBzZXQuIEZvciBzdHJ1Y3QgcGFnZSBtZW1vcnksIHdlJ3JlIHNhZmUgYmVjYXVzZSBL Vk0gd2lsbCBob2xkIGEKPiA+ID4gcmVmZXJlbmNlIGFzIGxvbmcgYXMgaXQncyBzdGlsbCB1c2lu ZyB0aGUgcGFnZS4gRm9yIG5vbiBzdHJ1Y3QgcGFnZQo+ID4gPiBtZW1vcnksIHdlJ3JlIG5vdCBz YWZlIC0gdGhpcyBpcyB3aGVyZSB0aGUgYnJlYWtpbmcgY2hhbmdlIG9mCj4gPiA+IGFsbG93X3Vu c2FmZV9tYXBwaW5ncyB3b3VsZCBnby4gTm90ZSB0aGF0IGZvciBub24tcmVmY291bnRlZCBzdHJ1 Y3QKPiA+ID4gcGFnZSwgd2UgY2FuJ3QgdXNlIHRoZSBhbGxvd191bnNhZmVfbWFwcGluZ3MgZXNj YXBlIGhhdGNoLiBTaW5jZQo+ID4gPiBGT0xMX0dFVCB3YXMgcmVxdWVzdGVkLCBpZiB3ZSByZXR1 cm5lZCBzdWNoIGEgcGFnZSwgdGhlbiB0aGUgY2FsbGVyCj4gPiA+IHdvdWxkIGV2ZW50dWFsbHkg Y29ycnVwdCB0aGUgcGFnZSByZWZjb3VudCB2aWEga3ZtX3JlbGVhc2VfcGZuLgo+ID4KPiA+IFll cyB3ZSBjYW4uICBUaGUgY2FsbGVyIHNpbXBseSBuZWVkcyB0byBiZSBtYWRlIGF3YXJlIG9mIGlz X3JlZmNvdW50ZWRfcGFnZS4gICBJCj4gPiBkaWRuJ3QgaW5jbHVkZSB0aGF0IGluIHRoZSBzbmlw cGV0IGJlbG93IGJlY2F1c2UgSSBkaWRuJ3Qgd2FudCB0byB3cml0ZSB0aGUgZW50aXJlCj4gPiBw YXRjaC4gIFRoZSB3aG9sZSBwb2ludCBvZiBhZGRpbmcgaXNfcmVmY291bnRlZF9wYWdlIGlzIHNv IHRoYXQgY2FsbGVycyBjYW4KPiA+IGlkZW50aWZ5IGV4YWN0bHkgd2hhdCB0eXBlIG9mIHBhZ2Ug d2FzIGF0IHRoZSBlbmQgb2YgdGhlIHRyYWlsIHRoYXQgd2FzIGZvbGxvd2VkLgo+IAo+IEFyZSB5 b3UgYXNraW5nIG1lIHRvIGNvbXBsZXRlbHkgbWlncmF0ZSBldmVyeSBjYWxsZXIgb2YgYW55IGdm bl90b19wZm4KPiB2YXJpYW50IHRvIF9fa3ZtX2ZvbGxvd19wZm4sIHNvIHRoYXQgdGhleSBjYW4g cmVzcGVjdAo+IGlzX3JlZmNvdW50ZWRfcGFnZT8gVGhhdCdzIHRoZSBvbmx5IHdheSB0byBtYWtl IGl0IHNhZmUgZm9yCj4gYWxsb3dfdW5zYWZlX21hcHBpbmdzIHRvIGFwcGx5IHRvIG5vbi1yZWZj b3VudGVkIHBhZ2VzLiBUaGF0IGlzCj4gZGVjaWRlZGx5IG5vdCBzaW1wbGUuIE9yIGlzIGt2bV92 Y3B1X21hcCB0aGUgc3BlY2lmaWMgY2FsbCBzaXRlIHlvdQo+IGNhcmUgYWJvdXQ/IEF0IGJlc3Qs IEkgY2FuIHRyeSB0byBtaWdyYXRlIHg4NiwgYW5kIHRoZW4ganVzdCBhZGQgc29tZQo+IHNvcnQg b2YgY29tcGF0aWJpbGl0eSBzaGltIGZvciBvdGhlciBhcmNoaXRlY3R1cmVzIHRoYXQgcmVqZWN0 cwo+IG5vbi1yZWZjb3VudGVkIHBhZ2VzLgoKQWgsIEkgc2VlIHlvdXIgY29udW5kcnVtLiAgTm8s IEkgZG9uJ3QgdGhpbmsgaXQncyByZWFzb25hYmxlIHRvIHJlcXVpcmUgeW91IHRvCmNvbnZlcnQg YWxsIHVzZXJzIGluIGV2ZXJ5IGFyY2hpdGVjdHVyZS4gIEknbGwgc3RpbGwgYXNrLCBqdXN0IGlu IGNhc2UgeW91J3JlCmZlZWxpbmcgZ2VuZXJvdXMsIGJ1dCBpdCdzIG5vdCBhIHJlcXVpcmVtZW50 IDotKQoKVGhlIGVhc2llc3Qgd2F5IGZvcndhcmQgSSBjYW4gdGhpbmsgb2YgaXMgdG8gYWRkIHll dCBhbm90aGVyIGZsYWcgdG8ga3ZtX2ZvbGxvd19wZm4sCmUuZy4gYWxsb3dfbm9uX3JlZmNvdW50 ZWRfc3RydWN0X3BhZ2UsIHRvIGNvbW11bmljYXRlIHdoZXRoZXIgb3Igbm90IHRoZSBjYWxsZXIK aGFzIGJlZW4gZW5saWdodGVuZWQgdG8gcGxheSBuaWNlIHdpdGggbm9uLXJlZmNvdW50ZWQgc3Ry dWN0IHBhZ2UgbWVtb3J5LiAgV2UnbGwKbmVlZCB0aGF0IGZsYWcgbm8gbWF0dGVyIHdoYXQsIG90 aGVyd2lzZSB3ZSdkIGhhdmUgdG8gY29udmVydCBhbGwgdXNlcnMgaW4gYSBzaW5nbGUKcGF0Y2gg KExPTCkuICBUaGVuIHlvdXIgc2VyaWVzIGNhbiBzaW1wbHkgc3RvcCBhdCBhIHJlYXNvbmFibGUg cG9pbnQsIGUuZy4gY29udmVydAphbGwgeDg2IHVzYWdlIChpbmNsdWRpbmcga3ZtX3ZjcHVfbWFw KCksIGFuZCBsZWF2ZSBjb252ZXJ0aW5nIGV2ZXJ5dGhpbmcgZWxzZSB0bwpmdXR1cmUgd29yay4K CkUuZy4gSSB0aGluayB0aGlzIHdvdWxkIGJlIHRoZSBvdXRybyBvZiBodmFfdG9fcGZuX3JlbWFw cGVkKCk6CgogICAgICAgIGlmICghcGFnZSkKICAgICAgICAgICAgICAgIGdvdG8gb3V0OwoKICAg ICAgICBpZiAoZ2V0X3BhZ2VfdW5sZXNzX3plcm8ocGFnZSkpCiAgICAgICAgICAgICAgICBXQVJO X09OX09OQ0Uoa3ZtX2ZvbGxvd19yZWZjb3VudGVkX3Bmbihmb2xsLCBwYWdlKSAhPSBwZm4pOwog b3V0OgogICAgICAgIHB0ZV91bm1hcF91bmxvY2socHRlcCwgcHRsKTsKCgkvKgoJICogVE9ETzog RHJvcCBhbGxvd19ub25fcmVmY291bnRlZF9zdHJ1Y3RfcGFnZSBvbmNlIGFsbCBjYWxsZXJzIGhh dmUKCSAqIGJlZW4gdGF1Z2h0IHRvIHBsYXkgbmljZSB3aXRoIG5vbi1yZWZjb3VudGVkIHRhaWwg cGFnZXMuCgkgKi8KCWlmIChwYWdlICYmICFmb2xsLT5pc19yZWZjb3VudGVkX3BhZ2UgJiYKCSAg ICAhZm9sbC0+YWxsb3dfbm9uX3JlZmNvdW50ZWRfc3RydWN0X3BhZ2UpCgkJciA9IC1FRkFVTFQK ICAgICAgICBlbHNlIGlmICghZm9sbC0+aXNfcmVmY291bnRlZF9wYWdlICYmICFmb2xsLT5ndWFy ZGVkX2J5X21tdV9ub3RpZmllciAmJgogICAgICAgIAkgIWFsbG93X3Vuc2FmZV9tYXBwaW5ncykK ICAgICAgICAJciA9IC1FRkFVTFQ7CiAgICAgICAgZWxzZQogICAgICAgICAgICAgICAqcF9wZm4g PSBwZm47CgogICAgICAgIHJldHVybiByOwoKPiA+ID4gUHJvcGVydHkgMyB3b3VsZCBiZSBuaWNl LCBidXQgd2UndmUgYWxyZWFkeSBjb25jbHVkZWQgdGhhdCBndWFyZGluZwo+ID4gPiBhbGwgdHJh bnNsYXRpb25zIHdpdGggbW11IG5vdGlmaWVycyBpcyBpbmZlYXNpYmxlLiBTbyBtYWludGFpbmlu Zwo+ID4gPiBwcm9wZXJ0eSAyIGlzIHRoZSBiZXN0IHdlIGNhbiBob3BlIGZvci4KPiA+Cj4gPiBO bywgIzMgaXMganVzdCBhIHZhcmlhbnQgb2YgIzIuICBVbmxlc3MgeW91J3JlIHRhbGtpbmcgYWJv dXQgbm90IG1ha2luZyBndWFyYW50ZWVzCj4gPiBhYm91dCBndWVzdCBhY2Nlc3NlcyBiZWluZyBv cmRlcmVkIHdpdGggcmVzcGVjdCB0byBWTUEvbWVtc2xvdCB1cGRhdGVzLCBidXQgSQo+ID4gZG9u J3QgdGhpbmsgdGhhdCdzIHRoZSBjYXNlLgo+IAo+IEknbSB0YWxraW5nIGFib3V0IHRoZSBmYWN0 IHRoYXQga3ZtX3ZjcHVfbWFwIGlzIGJ1c3RlZCB3aXRoIHJlc3BlY3QgdG8KPiB1cGRhdGVzIHRv IFZNQSB1cGRhdGVzLiBJdCB3b24ndCBjb3JydXB0IGhvc3QgbWVtb3J5IGJlY2F1c2UgdGhlCj4g bWFwcGluZyBrZWVwcyBhIHJlZmVyZW5jZSB0byB0aGUgcGFnZSwgYnV0IGl0IHdpbGwgY29udGlu dWUgdG8gdXNlCj4gc3RhbGUgdHJhbnNsYXRpb25zLgoKVHJ1ZS4gIEJ1dCBiYXJyaW5nIHNvbWUg Y3JhenkgcGFyYXZpcnQgdXNlIGNhc2UsIHVzZXJzcGFjZSBtb2RpZnlpbmcgYSBtYXBwaW5nCnRo YXQgaXMgaW4gYWN0aXZlIHVzZSBpcyBpbmhlcmVudGx5IGJyb2tlbiwgdGhlIGd1ZXN0IHdpbGwg aGF2ZSBubyBpZGVhIHRoYXQgbWVtb3J5Cmp1c3QgZ290IHlhbmtlZCBhd2F5LgoKSG1tLCB0aG91 Z2ggSSBzdXBwb3NlIHVzZXJzcGFjZSBjb3VsZCB0aGVvcmV0aWNhbGx5IG1wcm90ZWN0KCkgYSBt YXBwaW5nIHRvIGJlCnJlYWQtb25seSwgd2hpY2ggd291bGQgIndvcmsiIGZvciBtbXVfbm90aWZp ZXIgcGF0aHMgYnV0IG5vdCBrdm1fdmNwdV9tYXAoKS4gIEJ1dApLVk0gZG9lc24ndCBwcm92aWRl IGVub3VnaCBpbmZvcm1hdGlvbiBvbiAtRUZBVUxUIGZvciB1c2Vyc3BhY2UgdG8gZG8gYW55dGhp bmcgaW4KcmVzcG9uc2UgdG8gYSB3cml0ZSB0byByZWFkLW9ubHkgbWVtb3J5LCBzbyBpbiBwcmFj dGljZSB0aGF0J3MgbGlrZWx5IGluaGVyZW50bHkKYnJva2VuIHRvby4KCj4gRnJvbSBbMV0sIGl0 IHNvdW5kcyBsaWtlIHlvdSd2ZSBncmFudGVkIHRoYXQgZml4aW5nIHRoYXQgaXMgbm90IGZlYXNp YmxlLCBzbwo+IEkganVzdCB3YW50ZWQgdG8gbWFrZSBzdXJlIHRoYXQgdGhpcyBpc24ndCB0aGUg InVuc2FmZSIgcmVmZXJyZWQgdG8gYnkKPiBhbGxvd191bnNhZmVfbWFwcGluZ3MuCgpSaWdodCwg dGhpcyBpcyBub3QgdGhlICJ1bnNhZmUiIEknbSByZWZlcnJpbmcgdG8uCgo+IFsxXSBodHRwczov L2xvcmUua2VybmVsLm9yZy9hbGwvWkJFRVF0bXROUGFFcVUxaUBnb29nbGUuY29tLwoKX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGludXgtYXJtLWtlcm5l bCBtYWlsaW5nIGxpc3QKbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnCmh0dHA6 Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtYXJtLWtlcm5lbAo=