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 X-Spam-Level: X-Spam-Status: No, score=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C88F5C48BDF for ; Thu, 24 Jun 2021 10:17:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B348E613FB for ; Thu, 24 Jun 2021 10:17:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232215AbhFXKUJ (ORCPT ); Thu, 24 Jun 2021 06:20:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43060 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232111AbhFXKUH (ORCPT ); Thu, 24 Jun 2021 06:20:07 -0400 Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E5891C061574; Thu, 24 Jun 2021 03:17:48 -0700 (PDT) Received: by mail-pj1-x102c.google.com with SMTP id bb20so3183730pjb.3; Thu, 24 Jun 2021 03:17:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:subject:to:cc:references:in-reply-to:mime-version :message-id:content-transfer-encoding; bh=ufPcep0sp8fFam4s8EQWkn+673yXecgGkFHNTHQONWw=; b=sFF5ZYvJivSW9geCDpAWHQIXJqy0TaWKJDeCWyf+SN8sC0zvAWOqxE0kDzVGrlqH0T tmnXDqy/vMEUI/QT1fg3tuAhH6y/WaFDv0bhKrmNY65hIUEPGulyXJKnytExJVEwigXZ EEgjb92CecGE/1ZNSefvvxGTeh5Bu3j4pd19HStH0J6gJv+4gmTPMVXvpU/FEf57f6Z1 yZZLHMoK9YK0EH+XiEgmNblrEYdl95qc0I5aDyKhqYAvytW6+/07zmQXw9lEc1D57uv2 sPH/vR/v0oM7LuQHI7hajV/RDoziumHUY8ZgFdgAAJLR7DiFovRTgo8M2LsLunQ7LnIe UNoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:cc:references:in-reply-to :mime-version:message-id:content-transfer-encoding; bh=ufPcep0sp8fFam4s8EQWkn+673yXecgGkFHNTHQONWw=; b=aS4wwhJvFaUFn1MsoE7emCf6T3BPewsDquwyDWjz/J+NRe5hMNKkj1Aljz2Ecau/6o NtcLlZNgPkgqdfbcHC6TVEajAYSfy/mjGHddIXWFPj7gF0JJtYu/ONbVbtSbYt0+w+yj G7rAdFNbHSgL66Og7y1N0Bwt7SIlAeUsOb/kZjcxJCCArcCvfdcw1jxqJAdbR3PD04F7 2mgPmVbmrjvIlaQfUFe2Ioau0LS2Ipyjl4wuguEZ+EunSb6xZYbjUW73hI5Zfc0F2N+s zy8XDR5lGlapmye5SxnTbZF4b850jgbtXcUs+eDhht7xH64xuiZqwXn5/721xM71I0kk 4yMA== X-Gm-Message-State: AOAM530byPkbedOQkTcbexzeHypJpzrl6qUbpXF6/nyvKyPIOaD2EVGw K7LiZoqxL3LZatqq77gNaq8= X-Google-Smtp-Source: ABdhPJzBDdHKwzOfU1IGTH+/PPCRK2jVsTxYoY95EuRzqDADJIdiFOBloV8Ki52/MFkR99nX/DL1Xg== X-Received: by 2002:a17:90a:7401:: with SMTP id a1mr14554343pjg.57.1624529868549; Thu, 24 Jun 2021 03:17:48 -0700 (PDT) Received: from localhost (60-242-147-73.tpgi.com.au. [60.242.147.73]) by smtp.gmail.com with ESMTPSA id o20sm2094410pjq.57.2021.06.24.03.17.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Jun 2021 03:17:48 -0700 (PDT) Date: Thu, 24 Jun 2021 20:17:42 +1000 From: Nicholas Piggin Subject: Re: [PATCH 2/6] KVM: mmu: also return page from gfn_to_pfn To: Aleksandar Markovic , Huacai Chen , Marc Zyngier , Paul Mackerras , Paolo Bonzini , David Stevens , Zhenyu Wang , Zhi Wang Cc: Alexandru Elisei , dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, intel-gvt-dev@lists.freedesktop.org, James Morse , Jim Mattson , Joerg Roedel , kvmarm@lists.cs.columbia.edu, kvm-ppc@vger.kernel.org, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Sean Christopherson , Suzuki K Poulose , Vitaly Kuznetsov , Wanpeng Li , Will Deacon References: <20210624035749.4054934-1-stevensd@google.com> <20210624035749.4054934-3-stevensd@google.com> <1624524331.zsin3qejl9.astroid@bobo.none> <201b68a7-10ea-d656-0c1e-5511b1f22674@redhat.com> <1624528342.s2ezcyp90x.astroid@bobo.none> In-Reply-To: <1624528342.s2ezcyp90x.astroid@bobo.none> MIME-Version: 1.0 Message-Id: <1624529635.75a1ann91v.astroid@bobo.none> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Excerpts from Nicholas Piggin's message of June 24, 2021 7:57 pm: > Excerpts from Paolo Bonzini's message of June 24, 2021 7:42 pm: >> On 24/06/21 10:52, Nicholas Piggin wrote: >>>> For now, wrap all calls to gfn_to_pfn functions in the new helper >>>> function. Callers which don't need the page struct will be updated in >>>> follow-up patches. >>> Hmm. You mean callers that do need the page will be updated? Normally >>> if there will be leftover users that don't need the struct page then >>> you would go the other way and keep the old call the same, and add a ne= w >>> one (gfn_to_pfn_page) just for those that need it. >>=20 >> Needing kvm_pfn_page_unwrap is a sign that something might be buggy, so=20 >> it's a good idea to move the short name to the common case and the ugly=20 >> kvm_pfn_page_unwrap(gfn_to_pfn(...)) for the weird one. In fact I'm not= =20 >> sure there should be any kvm_pfn_page_unwrap in the end. >=20 > If all callers were updated that is one thing, but from the changelog > it sounds like that would not happen and there would be some gfn_to_pfn > users left over. >=20 > But yes in the end you would either need to make gfn_to_pfn never return > a page found via follow_pte, or change all callers to the new way. If=20 > the plan is for the latter then I guess that's fine. Actually in that case anyway I don't see the need -- the existence of gfn_to_pfn is enough to know it might be buggy. It can just as easily be grepped for as kvm_pfn_page_unwrap. And are gfn_to_page cases also vulernable to the same issue? So I think it could be marked deprecated or something if not everything=20 will be converted in the one series, and don't need to touch all that=20 arch code with this patch. Thanks, Nick 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 X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 77F6FC48BDF for ; Thu, 24 Jun 2021 10:18:36 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id E3343613FB for ; Thu, 24 Jun 2021 10:18:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E3343613FB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4G9bgv3YDyz3c3V for ; Thu, 24 Jun 2021 20:18:35 +1000 (AEST) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20161025 header.b=sFF5ZYvJ; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gmail.com (client-ip=2607:f8b0:4864:20::102a; helo=mail-pj1-x102a.google.com; envelope-from=npiggin@gmail.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20161025 header.b=sFF5ZYvJ; dkim-atps=neutral Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (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 4G9bg44NWgz309F for ; Thu, 24 Jun 2021 20:17:51 +1000 (AEST) Received: by mail-pj1-x102a.google.com with SMTP id b5-20020a17090a9905b029016fc06f6c5bso3162265pjp.5 for ; Thu, 24 Jun 2021 03:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:subject:to:cc:references:in-reply-to:mime-version :message-id:content-transfer-encoding; bh=ufPcep0sp8fFam4s8EQWkn+673yXecgGkFHNTHQONWw=; b=sFF5ZYvJivSW9geCDpAWHQIXJqy0TaWKJDeCWyf+SN8sC0zvAWOqxE0kDzVGrlqH0T tmnXDqy/vMEUI/QT1fg3tuAhH6y/WaFDv0bhKrmNY65hIUEPGulyXJKnytExJVEwigXZ EEgjb92CecGE/1ZNSefvvxGTeh5Bu3j4pd19HStH0J6gJv+4gmTPMVXvpU/FEf57f6Z1 yZZLHMoK9YK0EH+XiEgmNblrEYdl95qc0I5aDyKhqYAvytW6+/07zmQXw9lEc1D57uv2 sPH/vR/v0oM7LuQHI7hajV/RDoziumHUY8ZgFdgAAJLR7DiFovRTgo8M2LsLunQ7LnIe UNoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:cc:references:in-reply-to :mime-version:message-id:content-transfer-encoding; bh=ufPcep0sp8fFam4s8EQWkn+673yXecgGkFHNTHQONWw=; b=FB3MYpd9pN/2xaSs2+2hcyzoAI+C6tEmXeXPSWt38zlnzP0vaZxdh95TFFdB0lpSus yBNlCtwCN+O9+BlBxNmhPG3Mla83u0NfQMfxeI4XATL4aOd+cfO8Ae+H9fI5hYhm8Aiy /fMVZSZzDssSg5b1PI83GUm7fedsVJt1dHZXfiF7ZPoQz1p8XgtBsIaRhyz9AKKjw28Z xM4wkuTfdlw2KdR20ZCKgj+h/z/UYrxcowphksnS1Ncwzl3Ay7FCH/tN7HPe9NQVTJ+N h67RbkDQbtODozUAmRS2C/2F3y4DyiwfTTBN9rmLUEt+QZwIyE+8PtyFbluQSdLQ7s7W j4Yg== X-Gm-Message-State: AOAM533L0ZevenSbvROI09+G5d8X5AeZF38P3GRTjuIyYcDiOSfe8YZ7 wnjQo3bg7NXV1B3Ny5bB7dQ= X-Google-Smtp-Source: ABdhPJzBDdHKwzOfU1IGTH+/PPCRK2jVsTxYoY95EuRzqDADJIdiFOBloV8Ki52/MFkR99nX/DL1Xg== X-Received: by 2002:a17:90a:7401:: with SMTP id a1mr14554343pjg.57.1624529868549; Thu, 24 Jun 2021 03:17:48 -0700 (PDT) Received: from localhost (60-242-147-73.tpgi.com.au. [60.242.147.73]) by smtp.gmail.com with ESMTPSA id o20sm2094410pjq.57.2021.06.24.03.17.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Jun 2021 03:17:48 -0700 (PDT) Date: Thu, 24 Jun 2021 20:17:42 +1000 From: Nicholas Piggin Subject: Re: [PATCH 2/6] KVM: mmu: also return page from gfn_to_pfn To: Aleksandar Markovic , Huacai Chen , Marc Zyngier , Paul Mackerras , Paolo Bonzini , David Stevens , Zhenyu Wang , Zhi Wang References: <20210624035749.4054934-1-stevensd@google.com> <20210624035749.4054934-3-stevensd@google.com> <1624524331.zsin3qejl9.astroid@bobo.none> <201b68a7-10ea-d656-0c1e-5511b1f22674@redhat.com> <1624528342.s2ezcyp90x.astroid@bobo.none> In-Reply-To: <1624528342.s2ezcyp90x.astroid@bobo.none> MIME-Version: 1.0 Message-Id: <1624529635.75a1ann91v.astroid@bobo.none> 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: Wanpeng Li , kvm@vger.kernel.org, Suzuki K Poulose , Alexandru Elisei , intel-gfx@lists.freedesktop.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, kvmarm@lists.cs.columbia.edu, Will Deacon , James Morse , kvm-ppc@vger.kernel.org, Sean Christopherson , Vitaly Kuznetsov , linux-mips@vger.kernel.org, intel-gvt-dev@lists.freedesktop.org, Joerg Roedel , linux-arm-kernel@lists.infradead.org, Jim Mattson Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Excerpts from Nicholas Piggin's message of June 24, 2021 7:57 pm: > Excerpts from Paolo Bonzini's message of June 24, 2021 7:42 pm: >> On 24/06/21 10:52, Nicholas Piggin wrote: >>>> For now, wrap all calls to gfn_to_pfn functions in the new helper >>>> function. Callers which don't need the page struct will be updated in >>>> follow-up patches. >>> Hmm. You mean callers that do need the page will be updated? Normally >>> if there will be leftover users that don't need the struct page then >>> you would go the other way and keep the old call the same, and add a ne= w >>> one (gfn_to_pfn_page) just for those that need it. >>=20 >> Needing kvm_pfn_page_unwrap is a sign that something might be buggy, so=20 >> it's a good idea to move the short name to the common case and the ugly=20 >> kvm_pfn_page_unwrap(gfn_to_pfn(...)) for the weird one. In fact I'm not= =20 >> sure there should be any kvm_pfn_page_unwrap in the end. >=20 > If all callers were updated that is one thing, but from the changelog > it sounds like that would not happen and there would be some gfn_to_pfn > users left over. >=20 > But yes in the end you would either need to make gfn_to_pfn never return > a page found via follow_pte, or change all callers to the new way. If=20 > the plan is for the latter then I guess that's fine. Actually in that case anyway I don't see the need -- the existence of gfn_to_pfn is enough to know it might be buggy. It can just as easily be grepped for as kvm_pfn_page_unwrap. And are gfn_to_page cases also vulernable to the same issue? So I think it could be marked deprecated or something if not everything=20 will be converted in the one series, and don't need to touch all that=20 arch code with this patch. Thanks, Nick 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 X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7E092C49EA7 for ; Thu, 24 Jun 2021 14:03:58 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 142866140A for ; Thu, 24 Jun 2021 14:03:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 142866140A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id A3DC04B1D4; Thu, 24 Jun 2021 10:03:57 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@gmail.com Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hH9mEt6xKYJ; Thu, 24 Jun 2021 10:03:56 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 403A14B154; Thu, 24 Jun 2021 10:03:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id C3EEA4B26E for ; Thu, 24 Jun 2021 06:17:50 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdxqEcpWByKH for ; Thu, 24 Jun 2021 06:17:49 -0400 (EDT) Received: from mail-pj1-f47.google.com (mail-pj1-f47.google.com [209.85.216.47]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id 6F02C4B26D for ; Thu, 24 Jun 2021 06:17:49 -0400 (EDT) Received: by mail-pj1-f47.google.com with SMTP id bb10-20020a17090b008ab029016eef083425so5582874pjb.5 for ; Thu, 24 Jun 2021 03:17:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:subject:to:cc:references:in-reply-to:mime-version :message-id:content-transfer-encoding; bh=ufPcep0sp8fFam4s8EQWkn+673yXecgGkFHNTHQONWw=; b=sFF5ZYvJivSW9geCDpAWHQIXJqy0TaWKJDeCWyf+SN8sC0zvAWOqxE0kDzVGrlqH0T tmnXDqy/vMEUI/QT1fg3tuAhH6y/WaFDv0bhKrmNY65hIUEPGulyXJKnytExJVEwigXZ EEgjb92CecGE/1ZNSefvvxGTeh5Bu3j4pd19HStH0J6gJv+4gmTPMVXvpU/FEf57f6Z1 yZZLHMoK9YK0EH+XiEgmNblrEYdl95qc0I5aDyKhqYAvytW6+/07zmQXw9lEc1D57uv2 sPH/vR/v0oM7LuQHI7hajV/RDoziumHUY8ZgFdgAAJLR7DiFovRTgo8M2LsLunQ7LnIe UNoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:cc:references:in-reply-to :mime-version:message-id:content-transfer-encoding; bh=ufPcep0sp8fFam4s8EQWkn+673yXecgGkFHNTHQONWw=; b=fildmnEdS+NTjspY11XTgi+gVlpnZ9fDE93U21hCCCiviGoKOBQP1tCtlcDmY+cz6l amQ5Atsbn/iAH9t5E5Ss6Tn/8JjM/sara0HLl73YeB9eMj6bjonyTwWykrTPZ/OHBVlB YNlsWcL4ajYp9OA7r+YmFFe22APzC9EsmaFKDUnoeqP3ohmAaawiQ0m8NYt7UNJsvtr8 29tmjQmvRkXrHtoD/yAofBhJPumKOTky5AdRmJmwzBW9d8ms7dsptfy7SBFiC2/1H6Sj v/bcuFP5bzVtfWwMTexvYM9pL9EQ8E/46+xwc+V2hk01a1ur+yZSD452Y8aJUx5eIS1b 2iaw== X-Gm-Message-State: AOAM531W9/ejJubYNM1JTGOv5W9quEr6NLG2ND9AYLTQsuhxY9sd7p9B jZnHTHq3/UYn0Cfx9sMKI6c= X-Google-Smtp-Source: ABdhPJzBDdHKwzOfU1IGTH+/PPCRK2jVsTxYoY95EuRzqDADJIdiFOBloV8Ki52/MFkR99nX/DL1Xg== X-Received: by 2002:a17:90a:7401:: with SMTP id a1mr14554343pjg.57.1624529868549; Thu, 24 Jun 2021 03:17:48 -0700 (PDT) Received: from localhost (60-242-147-73.tpgi.com.au. [60.242.147.73]) by smtp.gmail.com with ESMTPSA id o20sm2094410pjq.57.2021.06.24.03.17.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Jun 2021 03:17:48 -0700 (PDT) Date: Thu, 24 Jun 2021 20:17:42 +1000 From: Nicholas Piggin Subject: Re: [PATCH 2/6] KVM: mmu: also return page from gfn_to_pfn To: Aleksandar Markovic , Huacai Chen , Marc Zyngier , Paul Mackerras , Paolo Bonzini , David Stevens , Zhenyu Wang , Zhi Wang References: <20210624035749.4054934-1-stevensd@google.com> <20210624035749.4054934-3-stevensd@google.com> <1624524331.zsin3qejl9.astroid@bobo.none> <201b68a7-10ea-d656-0c1e-5511b1f22674@redhat.com> <1624528342.s2ezcyp90x.astroid@bobo.none> In-Reply-To: <1624528342.s2ezcyp90x.astroid@bobo.none> MIME-Version: 1.0 Message-Id: <1624529635.75a1ann91v.astroid@bobo.none> X-Mailman-Approved-At: Thu, 24 Jun 2021 10:03:53 -0400 Cc: Wanpeng Li , kvm@vger.kernel.org, intel-gfx@lists.freedesktop.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, kvmarm@lists.cs.columbia.edu, Will Deacon , kvm-ppc@vger.kernel.org, Sean Christopherson , Vitaly Kuznetsov , linux-mips@vger.kernel.org, intel-gvt-dev@lists.freedesktop.org, Joerg Roedel , linux-arm-kernel@lists.infradead.org, Jim Mattson X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu Excerpts from Nicholas Piggin's message of June 24, 2021 7:57 pm: > Excerpts from Paolo Bonzini's message of June 24, 2021 7:42 pm: >> On 24/06/21 10:52, Nicholas Piggin wrote: >>>> For now, wrap all calls to gfn_to_pfn functions in the new helper >>>> function. Callers which don't need the page struct will be updated in >>>> follow-up patches. >>> Hmm. You mean callers that do need the page will be updated? Normally >>> if there will be leftover users that don't need the struct page then >>> you would go the other way and keep the old call the same, and add a new >>> one (gfn_to_pfn_page) just for those that need it. >> >> Needing kvm_pfn_page_unwrap is a sign that something might be buggy, so >> it's a good idea to move the short name to the common case and the ugly >> kvm_pfn_page_unwrap(gfn_to_pfn(...)) for the weird one. In fact I'm not >> sure there should be any kvm_pfn_page_unwrap in the end. > > If all callers were updated that is one thing, but from the changelog > it sounds like that would not happen and there would be some gfn_to_pfn > users left over. > > But yes in the end you would either need to make gfn_to_pfn never return > a page found via follow_pte, or change all callers to the new way. If > the plan is for the latter then I guess that's fine. Actually in that case anyway I don't see the need -- the existence of gfn_to_pfn is enough to know it might be buggy. It can just as easily be grepped for as kvm_pfn_page_unwrap. And are gfn_to_page cases also vulernable to the same issue? So I think it could be marked deprecated or something if not everything will be converted in the one series, and don't need to touch all that arch code with this patch. Thanks, Nick _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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 X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 00B6DC48BDF for ; Thu, 24 Jun 2021 10:19:57 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id C73B2613FB for ; Thu, 24 Jun 2021 10:19:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C73B2613FB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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:Message-Id:MIME-Version:In-Reply-To: References:Cc:To:Subject:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=k4ESe2fjrKiSBeHHXi5DhW4KNMG/TPLXDcAgSlAsHTs=; b=Q6/m+erNNLMTsF znnq2arWL370AXL2lfoWJ+WOsDz3MDlARyv8UkqSFKCWjeQi49HLXlzerKaXC6ZkoP/trR4MRBrin 54Hi9iq/lUPG6XwqFH+eILSLfoHh82+1TdvliSF278lrNr3+hRC/GumY2X3TrCWRd3b97U8b+C0zb M38Lhr0n6gjHj0dhwH024pdTxhCk0NuZ/r0wpBs+v3zKM/xQuGfNdHvdiFumvGs1ZKihRnflZf356 X+RQ/5ZvXSn/BNWvWls9RBK64NkJ5+W1k4TBnyrq77JuCEH2s7OU2wHSrWNCeSwa1wOS6YIvzfGQJ y8wsj+xSWrNS2pha5QoQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lwMRE-00E1LM-Mn; Thu, 24 Jun 2021 10:18:26 +0000 Received: from mail-pj1-x102f.google.com ([2607:f8b0:4864:20::102f]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lwMQf-00E1CF-JW for linux-arm-kernel@lists.infradead.org; Thu, 24 Jun 2021 10:17:53 +0000 Received: by mail-pj1-x102f.google.com with SMTP id s17-20020a17090a8811b029016e89654f93so5609580pjn.1 for ; Thu, 24 Jun 2021 03:17:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:subject:to:cc:references:in-reply-to:mime-version :message-id:content-transfer-encoding; bh=ufPcep0sp8fFam4s8EQWkn+673yXecgGkFHNTHQONWw=; b=sFF5ZYvJivSW9geCDpAWHQIXJqy0TaWKJDeCWyf+SN8sC0zvAWOqxE0kDzVGrlqH0T tmnXDqy/vMEUI/QT1fg3tuAhH6y/WaFDv0bhKrmNY65hIUEPGulyXJKnytExJVEwigXZ EEgjb92CecGE/1ZNSefvvxGTeh5Bu3j4pd19HStH0J6gJv+4gmTPMVXvpU/FEf57f6Z1 yZZLHMoK9YK0EH+XiEgmNblrEYdl95qc0I5aDyKhqYAvytW6+/07zmQXw9lEc1D57uv2 sPH/vR/v0oM7LuQHI7hajV/RDoziumHUY8ZgFdgAAJLR7DiFovRTgo8M2LsLunQ7LnIe UNoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:cc:references:in-reply-to :mime-version:message-id:content-transfer-encoding; bh=ufPcep0sp8fFam4s8EQWkn+673yXecgGkFHNTHQONWw=; b=I2/df6jU7cr3AH+kysdwrs/BBxJzaxHnij5sEhxzz77F87ukFV9PJLh10R9DzNh+Gv vtcb7BosMWbkCm+kjvuPewG9RFDILuFeQapsuTRUg+Ev6tIc3MfFpi+OkXP2UbA5Fc1t RTdJL0MTkpePcXlbx+Pdgg81YfeGsjcmPUZmxNZbv6pRQ0funRr6XAb48EPgH0ozJP8o HLFsIVozD/CQAvhi2iG/p0mCRT+jP6AGMGS80fxQ2Awd8V1epLZmwpNBBWR01YvO6nSQ VTwvNOEecWqW5olLf6D/IkeBOTaQ2HuwPNo1gbAil0FLiDbmIMlehFIdFJAGynwvLal5 RkEw== X-Gm-Message-State: AOAM532PJCb1I/aWqRBIbhlMb9Xt/FuszQfseo4G0/JQN6iGGATDAMJt pkEioAx7LCamWDYZD10uWK0= X-Google-Smtp-Source: ABdhPJzBDdHKwzOfU1IGTH+/PPCRK2jVsTxYoY95EuRzqDADJIdiFOBloV8Ki52/MFkR99nX/DL1Xg== X-Received: by 2002:a17:90a:7401:: with SMTP id a1mr14554343pjg.57.1624529868549; Thu, 24 Jun 2021 03:17:48 -0700 (PDT) Received: from localhost (60-242-147-73.tpgi.com.au. [60.242.147.73]) by smtp.gmail.com with ESMTPSA id o20sm2094410pjq.57.2021.06.24.03.17.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Jun 2021 03:17:48 -0700 (PDT) Date: Thu, 24 Jun 2021 20:17:42 +1000 From: Nicholas Piggin Subject: Re: [PATCH 2/6] KVM: mmu: also return page from gfn_to_pfn To: Aleksandar Markovic , Huacai Chen , Marc Zyngier , Paul Mackerras , Paolo Bonzini , David Stevens , Zhenyu Wang , Zhi Wang Cc: Alexandru Elisei , dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, intel-gvt-dev@lists.freedesktop.org, James Morse , Jim Mattson , Joerg Roedel , kvmarm@lists.cs.columbia.edu, kvm-ppc@vger.kernel.org, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Sean Christopherson , Suzuki K Poulose , Vitaly Kuznetsov , Wanpeng Li , Will Deacon References: <20210624035749.4054934-1-stevensd@google.com> <20210624035749.4054934-3-stevensd@google.com> <1624524331.zsin3qejl9.astroid@bobo.none> <201b68a7-10ea-d656-0c1e-5511b1f22674@redhat.com> <1624528342.s2ezcyp90x.astroid@bobo.none> In-Reply-To: <1624528342.s2ezcyp90x.astroid@bobo.none> MIME-Version: 1.0 Message-Id: <1624529635.75a1ann91v.astroid@bobo.none> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210624_031749_747937_C0E11189 X-CRM114-Status: GOOD ( 19.24 ) 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="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Excerpts from Nicholas Piggin's message of June 24, 2021 7:57 pm: > Excerpts from Paolo Bonzini's message of June 24, 2021 7:42 pm: >> On 24/06/21 10:52, Nicholas Piggin wrote: >>>> For now, wrap all calls to gfn_to_pfn functions in the new helper >>>> function. Callers which don't need the page struct will be updated in >>>> follow-up patches. >>> Hmm. You mean callers that do need the page will be updated? Normally >>> if there will be leftover users that don't need the struct page then >>> you would go the other way and keep the old call the same, and add a new >>> one (gfn_to_pfn_page) just for those that need it. >> >> Needing kvm_pfn_page_unwrap is a sign that something might be buggy, so >> it's a good idea to move the short name to the common case and the ugly >> kvm_pfn_page_unwrap(gfn_to_pfn(...)) for the weird one. In fact I'm not >> sure there should be any kvm_pfn_page_unwrap in the end. > > If all callers were updated that is one thing, but from the changelog > it sounds like that would not happen and there would be some gfn_to_pfn > users left over. > > But yes in the end you would either need to make gfn_to_pfn never return > a page found via follow_pte, or change all callers to the new way. If > the plan is for the latter then I guess that's fine. Actually in that case anyway I don't see the need -- the existence of gfn_to_pfn is enough to know it might be buggy. It can just as easily be grepped for as kvm_pfn_page_unwrap. And are gfn_to_page cases also vulernable to the same issue? So I think it could be marked deprecated or something if not everything will be converted in the one series, and don't need to touch all that arch code with this patch. Thanks, Nick _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D1817C48BDF for ; Thu, 24 Jun 2021 10:17:49 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9FCC6613B9 for ; Thu, 24 Jun 2021 10:17:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9FCC6613B9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 5299B6EB4D; Thu, 24 Jun 2021 10:17:49 +0000 (UTC) Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) by gabe.freedesktop.org (Postfix) with ESMTPS id CEEC16EB4D; Thu, 24 Jun 2021 10:17:48 +0000 (UTC) Received: by mail-pj1-x102c.google.com with SMTP id 13-20020a17090a08cdb029016eed209ca4so3184001pjn.1; Thu, 24 Jun 2021 03:17:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:subject:to:cc:references:in-reply-to:mime-version :message-id:content-transfer-encoding; bh=ufPcep0sp8fFam4s8EQWkn+673yXecgGkFHNTHQONWw=; b=sFF5ZYvJivSW9geCDpAWHQIXJqy0TaWKJDeCWyf+SN8sC0zvAWOqxE0kDzVGrlqH0T tmnXDqy/vMEUI/QT1fg3tuAhH6y/WaFDv0bhKrmNY65hIUEPGulyXJKnytExJVEwigXZ EEgjb92CecGE/1ZNSefvvxGTeh5Bu3j4pd19HStH0J6gJv+4gmTPMVXvpU/FEf57f6Z1 yZZLHMoK9YK0EH+XiEgmNblrEYdl95qc0I5aDyKhqYAvytW6+/07zmQXw9lEc1D57uv2 sPH/vR/v0oM7LuQHI7hajV/RDoziumHUY8ZgFdgAAJLR7DiFovRTgo8M2LsLunQ7LnIe UNoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:cc:references:in-reply-to :mime-version:message-id:content-transfer-encoding; bh=ufPcep0sp8fFam4s8EQWkn+673yXecgGkFHNTHQONWw=; b=SjJEqpT7lgjVivevf9UyEKsnYWJj241+n/iN547BdcOL7qyMo59Zg23F2xnIbus3ha 7Qa4t49cR2pAgG8EWnpvP1ddskCfD0hF24ZpxyZThhaJG/wauIbrcXz97+Am39NyQ8kC Fsw0gz0gzV4kiR56LDL6PLIHJEwpmCEBAj0anl+Xtge6vm8yLpiFlXU+Y8A2HFdh/Rrb OgUD220jxJ/XFRLDjCTJeJ7YHvsCakxByM4RugZh7Q0XoPe92s8BDqkrSox7/18Zvhax GtyMQ3nLGy8ZCcvPQMIalfetf0nMG5tJZDOdV5D8bBiosGbweFK+DkqxIq1uWyGsQ1hv 67UA== X-Gm-Message-State: AOAM531nsUuzCEYeV483CDgnllOSP+Ccip5HAy+7Aq0NR63dRztvbysE rs7oKTMMgsx68szSPzNpnRk= X-Google-Smtp-Source: ABdhPJzBDdHKwzOfU1IGTH+/PPCRK2jVsTxYoY95EuRzqDADJIdiFOBloV8Ki52/MFkR99nX/DL1Xg== X-Received: by 2002:a17:90a:7401:: with SMTP id a1mr14554343pjg.57.1624529868549; Thu, 24 Jun 2021 03:17:48 -0700 (PDT) Received: from localhost (60-242-147-73.tpgi.com.au. [60.242.147.73]) by smtp.gmail.com with ESMTPSA id o20sm2094410pjq.57.2021.06.24.03.17.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Jun 2021 03:17:48 -0700 (PDT) Date: Thu, 24 Jun 2021 20:17:42 +1000 From: Nicholas Piggin To: Aleksandar Markovic , Huacai Chen , Marc Zyngier , Paul Mackerras , Paolo Bonzini , David Stevens , Zhenyu Wang , Zhi Wang References: <20210624035749.4054934-1-stevensd@google.com> <20210624035749.4054934-3-stevensd@google.com> <1624524331.zsin3qejl9.astroid@bobo.none> <201b68a7-10ea-d656-0c1e-5511b1f22674@redhat.com> <1624528342.s2ezcyp90x.astroid@bobo.none> In-Reply-To: <1624528342.s2ezcyp90x.astroid@bobo.none> MIME-Version: 1.0 Message-Id: <1624529635.75a1ann91v.astroid@bobo.none> Subject: Re: [Intel-gfx] [PATCH 2/6] KVM: mmu: also return page from gfn_to_pfn X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Wanpeng Li , kvm@vger.kernel.org, Suzuki K Poulose , Alexandru Elisei , intel-gfx@lists.freedesktop.org, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, kvmarm@lists.cs.columbia.edu, Will Deacon , James Morse , kvm-ppc@vger.kernel.org, Sean Christopherson , Vitaly Kuznetsov , linux-mips@vger.kernel.org, intel-gvt-dev@lists.freedesktop.org, Joerg Roedel , linux-arm-kernel@lists.infradead.org, Jim Mattson Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" Excerpts from Nicholas Piggin's message of June 24, 2021 7:57 pm: > Excerpts from Paolo Bonzini's message of June 24, 2021 7:42 pm: >> On 24/06/21 10:52, Nicholas Piggin wrote: >>>> For now, wrap all calls to gfn_to_pfn functions in the new helper >>>> function. Callers which don't need the page struct will be updated in >>>> follow-up patches. >>> Hmm. You mean callers that do need the page will be updated? Normally >>> if there will be leftover users that don't need the struct page then >>> you would go the other way and keep the old call the same, and add a new >>> one (gfn_to_pfn_page) just for those that need it. >> >> Needing kvm_pfn_page_unwrap is a sign that something might be buggy, so >> it's a good idea to move the short name to the common case and the ugly >> kvm_pfn_page_unwrap(gfn_to_pfn(...)) for the weird one. In fact I'm not >> sure there should be any kvm_pfn_page_unwrap in the end. > > If all callers were updated that is one thing, but from the changelog > it sounds like that would not happen and there would be some gfn_to_pfn > users left over. > > But yes in the end you would either need to make gfn_to_pfn never return > a page found via follow_pte, or change all callers to the new way. If > the plan is for the latter then I guess that's fine. Actually in that case anyway I don't see the need -- the existence of gfn_to_pfn is enough to know it might be buggy. It can just as easily be grepped for as kvm_pfn_page_unwrap. And are gfn_to_page cases also vulernable to the same issue? So I think it could be marked deprecated or something if not everything will be converted in the one series, and don't need to touch all that arch code with this patch. Thanks, Nick _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicholas Piggin Date: Thu, 24 Jun 2021 10:17:42 +0000 Subject: Re: [PATCH 2/6] KVM: mmu: also return page from gfn_to_pfn Message-Id: <1624529635.75a1ann91v.astroid@bobo.none> List-Id: References: <20210624035749.4054934-1-stevensd@google.com> <20210624035749.4054934-3-stevensd@google.com> <1624524331.zsin3qejl9.astroid@bobo.none> <201b68a7-10ea-d656-0c1e-5511b1f22674@redhat.com> <1624528342.s2ezcyp90x.astroid@bobo.none> In-Reply-To: <1624528342.s2ezcyp90x.astroid@bobo.none> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Aleksandar Markovic , Huacai Chen , Marc Zyngier , Paul Mackerras , Paolo Bonzini , David Stevens , Zhenyu Wang , Zhi Wang Cc: Alexandru Elisei , dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org, intel-gvt-dev@lists.freedesktop.org, James Morse , Jim Mattson , Joerg Roedel , kvmarm@lists.cs.columbia.edu, kvm-ppc@vger.kernel.org, kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Sean Christopherson , Suzuki K Poulose , Vitaly Kuznetsov , Wanpeng Li , Will Deacon Excerpts from Nicholas Piggin's message of June 24, 2021 7:57 pm: > Excerpts from Paolo Bonzini's message of June 24, 2021 7:42 pm: >> On 24/06/21 10:52, Nicholas Piggin wrote: >>>> For now, wrap all calls to gfn_to_pfn functions in the new helper >>>> function. Callers which don't need the page struct will be updated in >>>> follow-up patches. >>> Hmm. You mean callers that do need the page will be updated? Normally >>> if there will be leftover users that don't need the struct page then >>> you would go the other way and keep the old call the same, and add a new >>> one (gfn_to_pfn_page) just for those that need it. >> >> Needing kvm_pfn_page_unwrap is a sign that something might be buggy, so >> it's a good idea to move the short name to the common case and the ugly >> kvm_pfn_page_unwrap(gfn_to_pfn(...)) for the weird one. In fact I'm not >> sure there should be any kvm_pfn_page_unwrap in the end. > > If all callers were updated that is one thing, but from the changelog > it sounds like that would not happen and there would be some gfn_to_pfn > users left over. > > But yes in the end you would either need to make gfn_to_pfn never return > a page found via follow_pte, or change all callers to the new way. If > the plan is for the latter then I guess that's fine. Actually in that case anyway I don't see the need -- the existence of gfn_to_pfn is enough to know it might be buggy. It can just as easily be grepped for as kvm_pfn_page_unwrap. And are gfn_to_page cases also vulernable to the same issue? So I think it could be marked deprecated or something if not everything will be converted in the one series, and don't need to touch all that arch code with this patch. Thanks, Nick