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 E0883C433F5 for ; Fri, 8 Apr 2022 18:15:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6BB418D0001; Fri, 8 Apr 2022 14:15:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 66B016B0075; Fri, 8 Apr 2022 14:15:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 50B5B8D0001; Fri, 8 Apr 2022 14:15:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0018.hostedemail.com [216.40.44.18]) by kanga.kvack.org (Postfix) with ESMTP id 410796B0074 for ; Fri, 8 Apr 2022 14:15:12 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id E9DDC183F79AD for ; Fri, 8 Apr 2022 18:15:11 +0000 (UTC) X-FDA: 79334513622.21.3183975 Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by imf08.hostedemail.com (Postfix) with ESMTP id E25C1160002 for ; Fri, 8 Apr 2022 18:15:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1649441711; x=1680977711; h=message-id:date:mime-version:to:cc:references:from: subject:in-reply-to:content-transfer-encoding; bh=NnDC/o/erWxIX6n6pVBFyGcg9uFsnyn/XQ+IyXjB/lw=; b=EnE/Nn9v+Tsep2aljSwpdmkWdTNF9SaA2y2UmB44iWB9Qeik1ZgbNbAg 0P8ymajNzPZF3azSZYCYkWuqH8A0Apnf0XFKb0SyT9xM+hfgoLhFzYfWk OXeIC9mAnBWJfwxGnZDAwDn1+9uO2xtCzuYMvo26Kci3TCUrnPoFi+fBI bDBHDc76ONV+kWhJfDc8sWOViTMHe2gO4JgpONjZllP0RR9swPuKTElI+ jqKpESd3ytwI2JazKwGybsIBfqWK0sJJHuQAWdyxFxl4bfhubIBwhnIHM +YudIG3eteQp64ZzCHhww0FYQUMARDW4evkG6O56Eci7aFIydniDvBjrI g==; X-IronPort-AV: E=McAfee;i="6400,9594,10311"; a="322349123" X-IronPort-AV: E=Sophos;i="5.90,245,1643702400"; d="scan'208";a="322349123" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Apr 2022 11:15:09 -0700 X-IronPort-AV: E=Sophos;i="5.90,245,1643702400"; d="scan'208";a="525475880" Received: from tsungtae-mobl.amr.corp.intel.com (HELO [10.134.43.198]) ([10.134.43.198]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Apr 2022 11:15:07 -0700 Message-ID: Date: Fri, 8 Apr 2022 11:15:11 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US To: "Kirill A. Shutemov" , Borislav Petkov , Andy Lutomirski , Sean Christopherson , Andrew Morton , Joerg Roedel , Ard Biesheuvel Cc: Andi Kleen , Kuppuswamy Sathyanarayanan , David Rientjes , Vlastimil Babka , Tom Lendacky , Thomas Gleixner , Peter Zijlstra , Paolo Bonzini , Ingo Molnar , Varad Gautam , Dario Faggioli , Brijesh Singh , Mike Rapoport , David Hildenbrand , x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org References: <20220405234343.74045-1-kirill.shutemov@linux.intel.com> <20220405234343.74045-7-kirill.shutemov@linux.intel.com> From: Dave Hansen Subject: Re: [PATCHv4 6/8] x86/mm: Provide helpers for unaccepted memory In-Reply-To: <20220405234343.74045-7-kirill.shutemov@linux.intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="EnE/Nn9v"; spf=none (imf08.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 134.134.136.31) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com X-Stat-Signature: ei1hfjaa7jxd8ih4da5gcyofz479q9zu X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: E25C1160002 X-HE-Tag: 1649441710-928528 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: On 4/5/22 16:43, Kirill A. Shutemov wrote: > Core-mm requires few helpers to support unaccepted memory: > > - accept_memory() checks the range of addresses against the bitmap and > accept memory if needed. > > - memory_is_unaccepted() check if anything within the range requires > acceptance. > > Signed-off-by: Kirill A. Shutemov > --- > arch/x86/include/asm/page.h | 5 +++ > arch/x86/include/asm/unaccepted_memory.h | 1 + > arch/x86/mm/Makefile | 2 + > arch/x86/mm/unaccepted_memory.c | 53 ++++++++++++++++++++++++ > 4 files changed, 61 insertions(+) > create mode 100644 arch/x86/mm/unaccepted_memory.c > > diff --git a/arch/x86/include/asm/page.h b/arch/x86/include/asm/page.h > index 9cc82f305f4b..9ae0064f97e5 100644 > --- a/arch/x86/include/asm/page.h > +++ b/arch/x86/include/asm/page.h > @@ -19,6 +19,11 @@ > struct page; > > #include > + > +#ifdef CONFIG_UNACCEPTED_MEMORY > +#include > +#endif It's a lot nicer to just to the #ifdefs inside the header. Is there a specific reason to do it this way? > extern struct range pfn_mapped[]; > extern int nr_pfn_mapped; > > diff --git a/arch/x86/include/asm/unaccepted_memory.h b/arch/x86/include/asm/unaccepted_memory.h > index f1f835d3cd78..a8d12ef1bda8 100644 > --- a/arch/x86/include/asm/unaccepted_memory.h > +++ b/arch/x86/include/asm/unaccepted_memory.h > @@ -10,5 +10,6 @@ struct boot_params; > void mark_unaccepted(struct boot_params *params, u64 start, u64 num); > > void accept_memory(phys_addr_t start, phys_addr_t end); > +bool memory_is_unaccepted(phys_addr_t start, phys_addr_t end); > > #endif > diff --git a/arch/x86/mm/Makefile b/arch/x86/mm/Makefile > index fe3d3061fc11..e327f83e6bbf 100644 > --- a/arch/x86/mm/Makefile > +++ b/arch/x86/mm/Makefile > @@ -60,3 +60,5 @@ obj-$(CONFIG_AMD_MEM_ENCRYPT) += mem_encrypt_amd.o > > obj-$(CONFIG_AMD_MEM_ENCRYPT) += mem_encrypt_identity.o > obj-$(CONFIG_AMD_MEM_ENCRYPT) += mem_encrypt_boot.o > + > +obj-$(CONFIG_UNACCEPTED_MEMORY) += unaccepted_memory.o > diff --git a/arch/x86/mm/unaccepted_memory.c b/arch/x86/mm/unaccepted_memory.c > new file mode 100644 > index 000000000000..3588a7cb954c > --- /dev/null > +++ b/arch/x86/mm/unaccepted_memory.c > @@ -0,0 +1,53 @@ > +// SPDX-License-Identifier: GPL-2.0-only > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > + > +static DEFINE_SPINLOCK(unaccepted_memory_lock); We need some documentation on what the lock does, either here or in the changelog. > +void accept_memory(phys_addr_t start, phys_addr_t end) > +{ > + unsigned long *unaccepted_memory; > + unsigned long flags; > + unsigned int rs, re; > + > + if (!boot_params.unaccepted_memory) > + return; > + > + unaccepted_memory = __va(boot_params.unaccepted_memory); > + rs = start / PMD_SIZE; > + > + spin_lock_irqsave(&unaccepted_memory_lock, flags); > + for_each_set_bitrange_from(rs, re, unaccepted_memory, > + DIV_ROUND_UP(end, PMD_SIZE)) { > + /* Platform-specific memory-acceptance call goes here */ > + panic("Cannot accept memory"); > + bitmap_clear(unaccepted_memory, rs, re - rs); > + } > + spin_unlock_irqrestore(&unaccepted_memory_lock, flags); > +} That panic() is making me nervous. Is this bisect-safe? Is it safe because there are no callers of this function yet? > +bool memory_is_unaccepted(phys_addr_t start, phys_addr_t end) > +{ > + unsigned long *unaccepted_memory = __va(boot_params.unaccepted_memory); > + unsigned long flags; > + bool ret = false; > + > + spin_lock_irqsave(&unaccepted_memory_lock, flags); > + while (start < end) { > + if (test_bit(start / PMD_SIZE, unaccepted_memory)) { > + ret = true; > + break; > + } > + > + start += PMD_SIZE; > + } > + spin_unlock_irqrestore(&unaccepted_memory_lock, flags); > + > + return ret; > +}