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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C8705C3DA79 for ; Mon, 15 Jan 2024 10:00:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F2E5E6B0075; Mon, 15 Jan 2024 05:00:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EB23F6B00A2; Mon, 15 Jan 2024 05:00:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D04BD6B00A3; Mon, 15 Jan 2024 05:00:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id B62496B0075 for ; Mon, 15 Jan 2024 05:00:24 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 8FB50A1303 for ; Mon, 15 Jan 2024 10:00:24 +0000 (UTC) X-FDA: 81681100368.01.6E2F477 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.9]) by imf08.hostedemail.com (Postfix) with ESMTP id EC06D160022 for ; Mon, 15 Jan 2024 10:00:21 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=LSJejvJZ; spf=none (imf08.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 198.175.65.9) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705312822; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=K+DcUhsmE3yzl9AXIdclJlqN2xluup6VicHIXuP3l3g=; b=BDqefB2UUNCVoE0vOpTarFODHmDcdRZBr4oWwedyYGhSs9ovtJaIPOWVbflO5GjfxClqvV fb0EPlxLYcrj2BcGfEygBDz1p5c/ctMTDC9qD86nkc2aWRUZZVZMEI7I5281V1A7Lw1cFM AwOlYLI62Zw6jPM6CLCe/DAW4X+Alu4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705312822; a=rsa-sha256; cv=none; b=wNXCgpZtakl5ALlWuzOYUoDoyyUeeaOVLDWE+FIo699X2HdxwmA4tpr6T0BpCYwNCrxs5k 5fRRNkOnKHGGtFGqHZZ3W/730tWYOVAULH2bf4exOpLN/xBepmSEMVRrFCBVErI0bw7GNA OepVAU9Wbj9zPd7acsPSkO0IvDr6KKE= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=LSJejvJZ; spf=none (imf08.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 198.175.65.9) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1705312822; x=1736848822; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=utTJkdiQ3vnztSPGEHcOmRJIWy6d/oKeObynN8qfOUs=; b=LSJejvJZm+4LsQgmMTArwCaNiP0lJ1NTqwQj9jNFC8FjzLTdFu0DcFp0 ucClMl3pmaJ8Q8F6+1fmJSDYgD1MD2b6LQzdAkWU1Hn9oBZ7PQuMDARFM FyWfe5qcteYR7B2haLKsQ1k6/uULFyuMyKo2aiTOWQXFlurxUTTx4ekBZ udkqrw3L5Q8MFoOY+hQYybAyYfU+oD/TJcbFeOmH1Sbg2Ou5PzjoN1A6X ICu7Bp0CScrT0fIzsBUCbaEYtkr7o7zpl4hwCunobJbhVzeoOsO3xs0u6 7zTrSFoxWVAHe6OKfKIjyEelHIIgTxl0WICgYcl/tPp3vTaIvxdu3pFJP w==; X-IronPort-AV: E=McAfee;i="6600,9927,10953"; a="18182455" X-IronPort-AV: E=Sophos;i="6.04,196,1695711600"; d="scan'208";a="18182455" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Jan 2024 02:00:20 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10953"; a="874059378" X-IronPort-AV: E=Sophos;i="6.04,196,1695711600"; d="scan'208";a="874059378" Received: from jeroenke-mobl.ger.corp.intel.com (HELO box.shutemov.name) ([10.252.55.160]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Jan 2024 02:00:13 -0800 Received: by box.shutemov.name (Postfix, from userid 1000) id 44E2E10A58F; Mon, 15 Jan 2024 13:00:11 +0300 (+03) Date: Mon, 15 Jan 2024 13:00:11 +0300 From: "kirill.shutemov@linux.intel.com" To: Michael Kelley Cc: "Edgecombe, Rick P" , "linux-coco@lists.linux.dev" , "ardb@kernel.org" , "Lutomirski, Andy" , "hch@infradead.org" , "dave.hansen@linux.intel.com" , "thomas.lendacky@amd.com" , "haiyangz@microsoft.com" , "akpm@linux-foundation.org" , "mingo@redhat.com" , "seanjc@google.com" , "linux-kernel@vger.kernel.org" , "tglx@linutronix.de" , "Cui, Dexuan" , "urezki@gmail.com" , "linux-mm@kvack.org" , "linux-hyperv@vger.kernel.org" , "peterz@infradead.org" , "hpa@zytor.com" , "bp@alien8.de" , "wei.liu@kernel.org" , "Rodel, Jorg" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "lstoakes@gmail.com" , "x86@kernel.org" Subject: Re: [PATCH v3 1/3] x86/hyperv: Use slow_virt_to_phys() in page transition hypervisor callback Message-ID: <20240115100011.yvecjjezrkcptnle@box.shutemov.name> References: <20240105183025.225972-1-mhklinux@outlook.com> <20240105183025.225972-2-mhklinux@outlook.com> <9dcdd088494b3fa285781cccfd35cd47a70d69c3.camel@intel.com> <3ddc237d9fbbe0aa8838babf0df790076017e9f7.camel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Stat-Signature: ogsx4xf4j8aaind7gr4earbpfrt3ibnw X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: EC06D160022 X-Rspam-User: X-HE-Tag: 1705312821-46188 X-HE-Meta: U2FsdGVkX1+1O3mFktEqtaAN34vE2WbEDDpE1LsRKBitsxNFeu0bg1G8As21QSMh1Qfm8wiG7wuYOmgHYP3qNOwIqTJ7nsIkzpyOFHWvsaYuVZhi+t0P9rvhSoCUexKR5+r0bwohZ6H39kNZu+lZgSNrlouzBobZjKFFUenYER0p4k1Hm2yABzfwQUZDFeO/iHI1pO1rj7rS/rAp3j4Ail+kVHE/49E0U+4VmjIPD0hMuY9A7nNpvcJoR9KqGDeLEUbET8+96pBjMwMNTLSl/pdi5Fk56WMBsQzZVdP3yilCZGG6hgqf+L7+pM0VyuSJOSvgQXE9KzBqwNyhDJHi+yH0UX/Z+fME0blXHh8Np1tXBUyuUuMUFMM76KyIXP+Xg1/o3EcF5M4IVWZ+wlSULZpruO2bgY0lASm4PfoX195nxWeCaJfkdhTVl4CvSM0L7PaE5yBvngNDRR7KwFvmqeR+7diaGrPY94K7lzYxT3xI0SRQSHaOdSBR6dnIrbyfedX+sZOCapukypArdm6czB3JipCYnNoDEKZWgPObN+WJ9gmW83+ngl50vF2FhsJyfvxRYQnKkjUWrLlrdTcaMV/8LKFXFqX/tQTwdEDA3z++N4p1MnGju2s/8DOBmg60PtUykfWVbonf9RRWdVyU5IgpBF84NET5ObubLMs7dHkaHSMNNzDOP0jHB3b9SRqtGu+CxyN4EZxSJxNvXK5farDVJt28BCQ2s3yJK3QmhPC+p+Z12k4JFSLfUvokwza4UmgO+8Xkovqb6Ft5Pf8UZ0fi30lfbyDbTJW0zuIhmqCBCD+P1z0QBuS/rO4kEfUfLB/b0SrtXtW0bkAp7/FbiigBCGUYojPV4QNU5kIC1AaOm/aAIPR7dgEyhIilI9R9cb4lr6+TOjYZYgdL0+RssrWOsMmlT+FW3X6aSq7wYaOne/n3xhTSoYG4gY+jZNkx3AYh6B6FQd1wL3e8MdE S1W/ZkC9 6pBcDtO3dxN7TxRTBA8ewZx9lZht784EoajiXgHlgUSsZe95FOqP9lAUVHwv8Kael4BpmvKexAUTXUwPV31TPwf4IFIQak8Re81rV9ibKBnh9pvVB6eMCAjd42VoWbEUG0x4kOKxx2a9auW7o2waCy9AOpV4WMh9EEHKmeIFdxEB1ECiVaXBSM+uboehDkay7IhN1dnibo2Ewo9eG6swon9+iYckBufdUoTeh9DLpqJUFxhRFk3kxeXO11SjHN9xal8tT X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Jan 12, 2024 at 07:24:35PM +0000, Michael Kelley wrote: > From: Edgecombe, Rick P Sent: Friday, January 12, 2024 9:17 AM > > > > On Fri, 2024-01-12 at 15:07 +0000, Michael Kelley wrote: > > > The comment is Kirill Shutemov's suggestion based on comments in > > > an earlier version of the patch series.  See [1].   The intent is to > > > prevent > > > some later revision to slow_virt_to_phys() from adding a check for > > > the > > > present bit and breaking the CoCo VM hypervisor callback.  Yes, the > > > comment could get stale, but I'm not sure how else to call out the > > > implicit dependency.  The idea of creating a private version of > > > slow_virt_to_phys() for use only in the CoCo VM hypervisor callback > > > is also discussed in the thread, but that seems worse overall. > > > > Well, it's not a huge deal, but I would have just put a comment at the > > caller like: > > > > /* > > * Use slow_virt_to_phys() instead of vmalloc_to_page(), because it > > * returns the PFN even for NP PTEs. > > */ > > Yes, that comment is added in this patch. > > > > > If someone is changing slow_virt_to_phys() they should check the > > callers to make sure they won't break anything. They can see the > > comment then and have an easy time. > > > > An optional comment at slow_virt_to_phys() could explain how the > > function works in regards to the present bit, but not include details > > about CoCoO VM page transition's usage of the present bit. The proposed > > comment text looks like something more appropriate for a commit log. > > Kirill -- you originally asked for a comment in slow_virt_to_phys(). [1] > Are you OK with Rick's proposal? Yes, sounds sensible. -- Kiryl Shutsemau / Kirill A. Shutemov