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, 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 4BE14C49EA5 for ; Thu, 24 Jun 2021 08:52:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 32014613D8 for ; Thu, 24 Jun 2021 08:52:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230121AbhFXIyd (ORCPT ); Thu, 24 Jun 2021 04:54:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51816 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229796AbhFXIyc (ORCPT ); Thu, 24 Jun 2021 04:54:32 -0400 Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 13CABC061574; Thu, 24 Jun 2021 01:52:13 -0700 (PDT) Received: by mail-pj1-x1030.google.com with SMTP id z3-20020a17090a3983b029016bc232e40bso3033299pjb.4; Thu, 24 Jun 2021 01:52:13 -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=9iS9TDXjHYeeO4p1tZR6e76NZxX4UTo0tHhJ02Bmyuc=; b=mEGHBnjuh74WaoNyT1eKb/VOfvVFvX3kwUneJ5AncMO10vay7V/YPF/SG5j7p8iYH1 7gxNCDvNzDqb55aG0xXgAC1RA62Wj+bbizWaJDKEr0nn3qnuj2jXLdTdeiyFZgIkzbU6 eUXYZQk6B3lHcCn/C7rK9Hfy2ewbGQ+QcUAXV5aikZlnmoVPOh+oFpMVHi12RR/PQruY Y7ojicHYDpa1rl6bybFrRzQg1WLQ4vvo9pySUIlXsW7HorWi3IZfqYmc1PUso5nJwGuX l372R3hUka0ng8Md0fedsRzdAZ1LxWh9MkI+AQUHTjtMJyFheflEYDzQL0UNZQwWosBs cQQw== 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=9iS9TDXjHYeeO4p1tZR6e76NZxX4UTo0tHhJ02Bmyuc=; b=jQ5rxrGQ13xRJ44e4Xe4rYK1oAHYi/Xfobjw+bM8mBUcGTs5twvnC6JvzhWkXjERSv buj912GQt7b3XWiLxRg9l16uWy06FQ8t2Rqg1EVhM9N4Hvv5zavFcmzhxtbYYjnJ0zZv pVsESHH+ZbzEmGl6ohcrgDuOtY9yUGqizIN1G6l1j8ITBHFCvxyC9Wa0g82JHl4eaVl+ 3f35yyRF/WmKbc7Wm/ZphT7nqV+coy39ZsyZ51Z3Ba6qtpIu4R/k78wCNffEilqQZ7eL 0Gh4SuHEru28JXxzaoMHMAxEIhIgxhzUgTdDYvK1QCl2M7ddHBTG+xXRmzYoEZze0ddK rLtA== X-Gm-Message-State: AOAM533vpUEjshY78dObZ6hzH8E/UyQUT0WMgVRRnqBvFe3iutlDPO+1 jGpDFYMTxaKS5eM24JpmYaU= X-Google-Smtp-Source: ABdhPJxZDp/SyGeLqZPtuw/I81jZ765tjN1eiDWxfb5Gw8s0EqtrDghio6LIVydktk8tQn/Q5HNfVQ== X-Received: by 2002:a17:90a:6fc1:: with SMTP id e59mr4396347pjk.37.1624524732566; Thu, 24 Jun 2021 01:52:12 -0700 (PDT) Received: from localhost (60-242-147-73.tpgi.com.au. [60.242.147.73]) by smtp.gmail.com with ESMTPSA id c5sm2109274pfv.47.2021.06.24.01.52.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Jun 2021 01:52:12 -0700 (PDT) Date: Thu, 24 Jun 2021 18:52:06 +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> In-Reply-To: <20210624035749.4054934-3-stevensd@google.com> MIME-Version: 1.0 Message-Id: <1624524331.zsin3qejl9.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 David Stevens's message of June 24, 2021 1:57 pm: > From: David Stevens >=20 > Return a struct kvm_pfn_page containing both a pfn and an optional > struct page from the gfn_to_pfn family of functions. This differentiates > the gup and follow_fault_pfn cases, which allows callers that only need > a pfn to avoid touching the page struct in the latter case. For callers > that need a struct page, introduce a helper function that unwraps a > struct kvm_pfn_page into a struct page. This helper makes the call to > kvm_get_pfn which had previously been in hva_to_pfn_remapped. >=20 > 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=20 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. Most kernel code I look at passes back multiple values by updating=20 pointers to struct or variables rather than returning a struct, I=20 suppose that's not really a big deal and a matter of taste. 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 DF87BC49EA5 for ; Thu, 24 Jun 2021 08:52:42 +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 6028C613DC for ; Thu, 24 Jun 2021 08:52:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6028C613DC 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 4G9Ymn75g2z3br2 for ; Thu, 24 Jun 2021 18:52:41 +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=mEGHBnju; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gmail.com (client-ip=2607:f8b0:4864:20::631; helo=mail-pl1-x631.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=mEGHBnju; dkim-atps=neutral Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 4G9YmJ5wFpz2xZJ for ; Thu, 24 Jun 2021 18:52:16 +1000 (AEST) Received: by mail-pl1-x631.google.com with SMTP id v13so2593518ple.9 for ; Thu, 24 Jun 2021 01:52:15 -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=9iS9TDXjHYeeO4p1tZR6e76NZxX4UTo0tHhJ02Bmyuc=; b=mEGHBnjuh74WaoNyT1eKb/VOfvVFvX3kwUneJ5AncMO10vay7V/YPF/SG5j7p8iYH1 7gxNCDvNzDqb55aG0xXgAC1RA62Wj+bbizWaJDKEr0nn3qnuj2jXLdTdeiyFZgIkzbU6 eUXYZQk6B3lHcCn/C7rK9Hfy2ewbGQ+QcUAXV5aikZlnmoVPOh+oFpMVHi12RR/PQruY Y7ojicHYDpa1rl6bybFrRzQg1WLQ4vvo9pySUIlXsW7HorWi3IZfqYmc1PUso5nJwGuX l372R3hUka0ng8Md0fedsRzdAZ1LxWh9MkI+AQUHTjtMJyFheflEYDzQL0UNZQwWosBs cQQw== 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=9iS9TDXjHYeeO4p1tZR6e76NZxX4UTo0tHhJ02Bmyuc=; b=UnurgBRd7cXq+uHXZP8CqNwLEi6K0Iaf0iQvwztfxjxUiWldazgEWUtRRlI3J9pZDS CdKwhb9MJbN9Z/BW83JTo+2sieVf60C9z9FWHcfrqwEUkmsFPqJGyUZySw7eOEiuMv24 DemojjUFq8gOppR6tT7/KR+/3qZGTPslSeVcu6J01Fs7r5LBEmUH1f+BIhyVaUJEmHvg RKLWBdJKz3a6eSzEd6XtVlNQPeFxyEGQbRzEoCymERaggnFqFaPeED6Ebk6pxTmwx3Mb hCC8TtL1YvUxU9F+rybx94P+9JnBEaojiEwfz7Kn9kbQ1i4/xUHk5KlOrZ/mHIcAydNh Ig1A== X-Gm-Message-State: AOAM531Q7u1zYp10v4dQ55hV7lOVHm+L26lgJMP2W2RZLD9bBDRL6Zre K9bSCOb4uus7LEoyMc9Iq6c= X-Google-Smtp-Source: ABdhPJxZDp/SyGeLqZPtuw/I81jZ765tjN1eiDWxfb5Gw8s0EqtrDghio6LIVydktk8tQn/Q5HNfVQ== X-Received: by 2002:a17:90a:6fc1:: with SMTP id e59mr4396347pjk.37.1624524732566; Thu, 24 Jun 2021 01:52:12 -0700 (PDT) Received: from localhost (60-242-147-73.tpgi.com.au. [60.242.147.73]) by smtp.gmail.com with ESMTPSA id c5sm2109274pfv.47.2021.06.24.01.52.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Jun 2021 01:52:12 -0700 (PDT) Date: Thu, 24 Jun 2021 18:52:06 +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> In-Reply-To: <20210624035749.4054934-3-stevensd@google.com> MIME-Version: 1.0 Message-Id: <1624524331.zsin3qejl9.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 David Stevens's message of June 24, 2021 1:57 pm: > From: David Stevens >=20 > Return a struct kvm_pfn_page containing both a pfn and an optional > struct page from the gfn_to_pfn family of functions. This differentiates > the gup and follow_fault_pfn cases, which allows callers that only need > a pfn to avoid touching the page struct in the latter case. For callers > that need a struct page, introduce a helper function that unwraps a > struct kvm_pfn_page into a struct page. This helper makes the call to > kvm_get_pfn which had previously been in hva_to_pfn_remapped. >=20 > 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=20 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. Most kernel code I look at passes back multiple values by updating=20 pointers to struct or variables rather than returning a struct, I=20 suppose that's not really a big deal and a matter of taste. 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 87AA1C49EA5 for ; Thu, 24 Jun 2021 08:57:29 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 14B1361248 for ; Thu, 24 Jun 2021 08:57:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 14B1361248 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 AA1F94B245; Thu, 24 Jun 2021 04:57:28 -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 tKxVtafSzW7f; Thu, 24 Jun 2021 04:57:27 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 49BF94B22D; Thu, 24 Jun 2021 04:57:26 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id E84174B1A0 for ; Thu, 24 Jun 2021 04:52:14 -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 KqAn+0+zDuCi for ; Thu, 24 Jun 2021 04:52:13 -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 93F874B226 for ; Thu, 24 Jun 2021 04:52:13 -0400 (EDT) Received: by mail-pj1-f47.google.com with SMTP id x21-20020a17090aa395b029016e25313bfcso3052970pjp.2 for ; Thu, 24 Jun 2021 01:52:13 -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=9iS9TDXjHYeeO4p1tZR6e76NZxX4UTo0tHhJ02Bmyuc=; b=mEGHBnjuh74WaoNyT1eKb/VOfvVFvX3kwUneJ5AncMO10vay7V/YPF/SG5j7p8iYH1 7gxNCDvNzDqb55aG0xXgAC1RA62Wj+bbizWaJDKEr0nn3qnuj2jXLdTdeiyFZgIkzbU6 eUXYZQk6B3lHcCn/C7rK9Hfy2ewbGQ+QcUAXV5aikZlnmoVPOh+oFpMVHi12RR/PQruY Y7ojicHYDpa1rl6bybFrRzQg1WLQ4vvo9pySUIlXsW7HorWi3IZfqYmc1PUso5nJwGuX l372R3hUka0ng8Md0fedsRzdAZ1LxWh9MkI+AQUHTjtMJyFheflEYDzQL0UNZQwWosBs cQQw== 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=9iS9TDXjHYeeO4p1tZR6e76NZxX4UTo0tHhJ02Bmyuc=; b=FfwunJ3NSBhyqVdDH0gCCbZp/eBloXgLYhQdfWdZtnUdjjnTONl4wKVdHzkqOni1O+ ZA/AfZA690ZXJd8X25JsqMB3CxOqDJJWuukj2KYrhBqRUCFq8wX6l9Wun7TWDgc/e8CD iA2qPoNCWaZRshdiA7eya7IVM+rkEPUFL/4Syl/jS3Vtp7HcmLZf7EtKIMwd1iJ1F7NF gobYruONv6Lgd4OtLsC3BkVRqIVtrbKwL1gUMPGlmcEve54Dl5zdwc8aGxbqUST1znW8 XZkNSCy3UVRifTUpuNeSqXzEQQY6d43Qv3sQ3T6LdgWDUZmxzbw9FDxWWM9XLSJDhPKu QU3g== X-Gm-Message-State: AOAM530HwgvWEIuzweEWI7ul3jruLxWeUz7OE2aHqew5WxPBU3S4jAne OdkUoLkc5cvZuMZSwv43f+o= X-Google-Smtp-Source: ABdhPJxZDp/SyGeLqZPtuw/I81jZ765tjN1eiDWxfb5Gw8s0EqtrDghio6LIVydktk8tQn/Q5HNfVQ== X-Received: by 2002:a17:90a:6fc1:: with SMTP id e59mr4396347pjk.37.1624524732566; Thu, 24 Jun 2021 01:52:12 -0700 (PDT) Received: from localhost (60-242-147-73.tpgi.com.au. [60.242.147.73]) by smtp.gmail.com with ESMTPSA id c5sm2109274pfv.47.2021.06.24.01.52.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Jun 2021 01:52:12 -0700 (PDT) Date: Thu, 24 Jun 2021 18:52:06 +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> In-Reply-To: <20210624035749.4054934-3-stevensd@google.com> MIME-Version: 1.0 Message-Id: <1624524331.zsin3qejl9.astroid@bobo.none> X-Mailman-Approved-At: Thu, 24 Jun 2021 04:57:25 -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 David Stevens's message of June 24, 2021 1:57 pm: > From: David Stevens > > Return a struct kvm_pfn_page containing both a pfn and an optional > struct page from the gfn_to_pfn family of functions. This differentiates > the gup and follow_fault_pfn cases, which allows callers that only need > a pfn to avoid touching the page struct in the latter case. For callers > that need a struct page, introduce a helper function that unwraps a > struct kvm_pfn_page into a struct page. This helper makes the call to > kvm_get_pfn which had previously been in hva_to_pfn_remapped. > > 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. Most kernel code I look at passes back multiple values by updating pointers to struct or variables rather than returning a struct, I suppose that's not really a big deal and a matter of taste. 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 03969C48BDF for ; Thu, 24 Jun 2021 08:54:32 +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 B71AD613B9 for ; Thu, 24 Jun 2021 08:54:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B71AD613B9 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=oNcQ/TQtE6EHJfF034e3vpd1JyAktIyaEl5lr7oOA6c=; b=LWm6E+Dv54b0bZ zLWFwOEKB6WBhbgQegL7GgIUHGCZDJLE5orFNgDI8JxDASwuuDrcxBuDux/YqGRPDzL08wAq/OO5b nO61L9rCx/YXctKe3ST7DaSO+EHATvcHXfnS/l+sccRW1BAg/NaPiz4iznhP4Y9wdOo2bm8haoMde NGJVeYBJlKjVd6um6dpA0xWXMqktdcsnpmxjUS1f/as2iICoWJJkwFWy6rF9Oa9zDRDSfJ10BkvIT vVQyo3Iv/RZYIaE6WjaHd8mK8+RG7TFossDU+ILYvSAwewzAI5fbxqpH2NnqpENpaWFVE2h5cCao0 z2UAyCPLqxbHi2m5aJvQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lwL5t-00DXCI-1Z; Thu, 24 Jun 2021 08:52:17 +0000 Received: from mail-pj1-x1029.google.com ([2607:f8b0:4864:20::1029]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lwL5p-00DXB3-A9 for linux-arm-kernel@lists.infradead.org; Thu, 24 Jun 2021 08:52:14 +0000 Received: by mail-pj1-x1029.google.com with SMTP id b5-20020a17090a9905b029016fc06f6c5bso3035617pjp.5 for ; Thu, 24 Jun 2021 01:52:13 -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=9iS9TDXjHYeeO4p1tZR6e76NZxX4UTo0tHhJ02Bmyuc=; b=mEGHBnjuh74WaoNyT1eKb/VOfvVFvX3kwUneJ5AncMO10vay7V/YPF/SG5j7p8iYH1 7gxNCDvNzDqb55aG0xXgAC1RA62Wj+bbizWaJDKEr0nn3qnuj2jXLdTdeiyFZgIkzbU6 eUXYZQk6B3lHcCn/C7rK9Hfy2ewbGQ+QcUAXV5aikZlnmoVPOh+oFpMVHi12RR/PQruY Y7ojicHYDpa1rl6bybFrRzQg1WLQ4vvo9pySUIlXsW7HorWi3IZfqYmc1PUso5nJwGuX l372R3hUka0ng8Md0fedsRzdAZ1LxWh9MkI+AQUHTjtMJyFheflEYDzQL0UNZQwWosBs cQQw== 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=9iS9TDXjHYeeO4p1tZR6e76NZxX4UTo0tHhJ02Bmyuc=; b=No1UK1bP3MKm+s+AUoguhSjRC1fElAxrMsLoI6m6gUo0Hyl0HNqBtxtXkP+syukwWk Dw945H2bs5L1lvtNG7/EEhyXCLQGfGH96ENmk/poRS7K6Xes+03nPcDPQVhctijOgznM Dcap+ytd9WRHWpdk1O7sJUU58WSZY0YOpxasmqQZtVery3S93g3fSNdVr8fIPYfU9Vee EihM2LlWh7qGpj6kKn0VDTjpNMY/yg1ZGKJRqK6k1GruJf7P8Q5wtIOgiHVwu9pLF1ml E/fNi9ulAuq2DI0jYwgA+qoctA423oNGZDMo2jLw2vSqgdbWfwt2TaPgdpk39BlADCtM Es7Q== X-Gm-Message-State: AOAM5319Olr4VEx6m10OSPD30vtrJlDgUQzPtW25j+e2oklXuKF2gO8T TU5YYLMaScPlOQZj6Ob5QWk= X-Google-Smtp-Source: ABdhPJxZDp/SyGeLqZPtuw/I81jZ765tjN1eiDWxfb5Gw8s0EqtrDghio6LIVydktk8tQn/Q5HNfVQ== X-Received: by 2002:a17:90a:6fc1:: with SMTP id e59mr4396347pjk.37.1624524732566; Thu, 24 Jun 2021 01:52:12 -0700 (PDT) Received: from localhost (60-242-147-73.tpgi.com.au. [60.242.147.73]) by smtp.gmail.com with ESMTPSA id c5sm2109274pfv.47.2021.06.24.01.52.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Jun 2021 01:52:12 -0700 (PDT) Date: Thu, 24 Jun 2021 18:52:06 +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> In-Reply-To: <20210624035749.4054934-3-stevensd@google.com> MIME-Version: 1.0 Message-Id: <1624524331.zsin3qejl9.astroid@bobo.none> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210624_015213_410752_2E3E0920 X-CRM114-Status: GOOD ( 13.27 ) 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 David Stevens's message of June 24, 2021 1:57 pm: > From: David Stevens > > Return a struct kvm_pfn_page containing both a pfn and an optional > struct page from the gfn_to_pfn family of functions. This differentiates > the gup and follow_fault_pfn cases, which allows callers that only need > a pfn to avoid touching the page struct in the latter case. For callers > that need a struct page, introduce a helper function that unwraps a > struct kvm_pfn_page into a struct page. This helper makes the call to > kvm_get_pfn which had previously been in hva_to_pfn_remapped. > > 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. Most kernel code I look at passes back multiple values by updating pointers to struct or variables rather than returning a struct, I suppose that's not really a big deal and a matter of taste. 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 D7CE2C48BDF for ; Thu, 24 Jun 2021 08:52:17 +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 A8FBB613D8 for ; Thu, 24 Jun 2021 08:52:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A8FBB613D8 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 589406EB24; Thu, 24 Jun 2021 08:52:17 +0000 (UTC) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) by gabe.freedesktop.org (Postfix) with ESMTPS id F25FB6EB21; Thu, 24 Jun 2021 08:52:12 +0000 (UTC) Received: by mail-pj1-x1036.google.com with SMTP id 13-20020a17090a08cdb029016eed209ca4so3057288pjn.1; Thu, 24 Jun 2021 01:52:12 -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=9iS9TDXjHYeeO4p1tZR6e76NZxX4UTo0tHhJ02Bmyuc=; b=mEGHBnjuh74WaoNyT1eKb/VOfvVFvX3kwUneJ5AncMO10vay7V/YPF/SG5j7p8iYH1 7gxNCDvNzDqb55aG0xXgAC1RA62Wj+bbizWaJDKEr0nn3qnuj2jXLdTdeiyFZgIkzbU6 eUXYZQk6B3lHcCn/C7rK9Hfy2ewbGQ+QcUAXV5aikZlnmoVPOh+oFpMVHi12RR/PQruY Y7ojicHYDpa1rl6bybFrRzQg1WLQ4vvo9pySUIlXsW7HorWi3IZfqYmc1PUso5nJwGuX l372R3hUka0ng8Md0fedsRzdAZ1LxWh9MkI+AQUHTjtMJyFheflEYDzQL0UNZQwWosBs cQQw== 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=9iS9TDXjHYeeO4p1tZR6e76NZxX4UTo0tHhJ02Bmyuc=; b=NVQEAR6gS0yMvZEkOAfgIH7klCMhBXWGGfsfE7oy1Y0AK7Kshr6GJTpy6g/oPIUake IFkpkb+a7o8QywAmYqGAj4Gu+406yaqSyCK9e8tur13EpspL7AjrrzP2IyMQqFEEyiTf fBQPNjYVDyekVN0BDT9BeC6ghpLCDyeljaQzA3ghxqgSfxk7Zc2xLHCYDodiMoH7JIH7 q38mcGkaRW2ESIAqRqXPuPwdHu/yqFxPIu5dphN/lNCttAL7JkIqcv83RaxKDtdNyxaw i3LeYHfBIo0agicw8w384jQERGZd+22CQ+SkIveaeZyrZwdNdak4WXVBDHCEyE6W2u9/ 9mNA== X-Gm-Message-State: AOAM533EfIxBRfpfeaMqm8cNuxPImlGZ9+8afOLKdVhMuh57M9FkkALJ kAeBfQ0G5KyHE2bf7Si4tTHvbQ+70Os= X-Google-Smtp-Source: ABdhPJxZDp/SyGeLqZPtuw/I81jZ765tjN1eiDWxfb5Gw8s0EqtrDghio6LIVydktk8tQn/Q5HNfVQ== X-Received: by 2002:a17:90a:6fc1:: with SMTP id e59mr4396347pjk.37.1624524732566; Thu, 24 Jun 2021 01:52:12 -0700 (PDT) Received: from localhost (60-242-147-73.tpgi.com.au. [60.242.147.73]) by smtp.gmail.com with ESMTPSA id c5sm2109274pfv.47.2021.06.24.01.52.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Jun 2021 01:52:12 -0700 (PDT) Date: Thu, 24 Jun 2021 18:52:06 +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> In-Reply-To: <20210624035749.4054934-3-stevensd@google.com> MIME-Version: 1.0 Message-Id: <1624524331.zsin3qejl9.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 David Stevens's message of June 24, 2021 1:57 pm: > From: David Stevens > > Return a struct kvm_pfn_page containing both a pfn and an optional > struct page from the gfn_to_pfn family of functions. This differentiates > the gup and follow_fault_pfn cases, which allows callers that only need > a pfn to avoid touching the page struct in the latter case. For callers > that need a struct page, introduce a helper function that unwraps a > struct kvm_pfn_page into a struct page. This helper makes the call to > kvm_get_pfn which had previously been in hva_to_pfn_remapped. > > 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. Most kernel code I look at passes back multiple values by updating pointers to struct or variables rather than returning a struct, I suppose that's not really a big deal and a matter of taste. 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 08:52:06 +0000 Subject: Re: [PATCH 2/6] KVM: mmu: also return page from gfn_to_pfn Message-Id: <1624524331.zsin3qejl9.astroid@bobo.none> List-Id: References: <20210624035749.4054934-1-stevensd@google.com> <20210624035749.4054934-3-stevensd@google.com> In-Reply-To: <20210624035749.4054934-3-stevensd@google.com> 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 David Stevens's message of June 24, 2021 1:57 pm: > From: David Stevens > > Return a struct kvm_pfn_page containing both a pfn and an optional > struct page from the gfn_to_pfn family of functions. This differentiates > the gup and follow_fault_pfn cases, which allows callers that only need > a pfn to avoid touching the page struct in the latter case. For callers > that need a struct page, introduce a helper function that unwraps a > struct kvm_pfn_page into a struct page. This helper makes the call to > kvm_get_pfn which had previously been in hva_to_pfn_remapped. > > 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. Most kernel code I look at passes back multiple values by updating pointers to struct or variables rather than returning a struct, I suppose that's not really a big deal and a matter of taste. Thanks, Nick