From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EB2812C9D for ; Mon, 31 Jan 2022 12:13:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1643631233; h=from:from: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; bh=qY7y58M4Z9dUeNje0RD9EQDvDaWgy0c7Wz/zTz2kkX4=; b=RAhJik0bBdj+IUv4bGSk8quy71Ivc/92emIzsMiiDruqQj7gcYBUtDoUyGnk4q2OLC6d4o 2tyGr/8k35K1DyppizZWgB5I1bt8su/skBU6XSy5vVuB1cye1R7/pQ3OKiJyKNPTToCB8J R3IKIlFCWrmqWWhvRDipBNBs65lQ+aI= Received: from mail-ed1-f72.google.com (mail-ed1-f72.google.com [209.85.208.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-245-D3zgwg4LNm-5Y55-9bz7gA-1; Mon, 31 Jan 2022 07:13:52 -0500 X-MC-Unique: D3zgwg4LNm-5Y55-9bz7gA-1 Received: by mail-ed1-f72.google.com with SMTP id w15-20020a056402268f00b00408234dc1dfso6841411edd.16 for ; Mon, 31 Jan 2022 04:13:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=qY7y58M4Z9dUeNje0RD9EQDvDaWgy0c7Wz/zTz2kkX4=; b=fwAQ/ibKUc/OKxDyNZuWIT/D3Qa/g85dT4MKC2s7sTU6BixaByzr89rdTby8vz3JTX 4i2+tr0R55yzPRBQV4JcZAMLJbGZxN+OYGmAXXp10X/7Kd96K3b5yhjNk3gZR5WiXljK twL4ohltwXC1jOD+Yw3xrNVVqVSGPwpBRzR2J8Y8ocn3KbSjB6Otx3NTGDya9mKknT2H F6uSOpKpH3FzAF2j5C1WYt33PsoIAR9aYlXZVQG1qqx96qO08/3iQ5NMxVYlekpP2tB1 xrw3H2oqxt7DvNB0NZANDS7Febpn/QimqCRgEsmCqUqcOXCGoWFF8AT53B58fEaWA0Q7 0ouw== X-Gm-Message-State: AOAM531MnRyZBKGGnTSRCP8dcsl7VmpEcAAagLFeqS/omcCwikaY/qJt +it5tQx4nuDdwEz/uxZ3WAkIpwyshhRt/JhhIq/mWZhgBaT0T3u8OhmHtJWCcmLhdMq9VWUbplE IYJzF4xScNWVGJGSkt38nzA== X-Received: by 2002:a05:6402:84f:: with SMTP id b15mr13862939edz.206.1643631231508; Mon, 31 Jan 2022 04:13:51 -0800 (PST) X-Google-Smtp-Source: ABdhPJzACLQH+N8dJfW+/bzLKkdD1VbwpDi/uzAqTCLL0kVJw2L9Gr70F8Y3XECH+bTM+vezdbLMGg== X-Received: by 2002:a05:6402:84f:: with SMTP id b15mr13862903edz.206.1643631231261; Mon, 31 Jan 2022 04:13:51 -0800 (PST) Received: from ?IPV6:2003:cb:c709:b200:f007:5a26:32e7:8ef5? (p200300cbc709b200f0075a2632e78ef5.dip0.t-ipconnect.de. [2003:cb:c709:b200:f007:5a26:32e7:8ef5]) by smtp.gmail.com with ESMTPSA id m12sm3786247ejr.218.2022.01.31.04.13.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 31 Jan 2022 04:13:50 -0800 (PST) Message-ID: Date: Mon, 31 Jan 2022 13:13:49 +0100 Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 To: "Kirill A. Shutemov" , rppt@kernel.org Cc: ak@linux.intel.com, akpm@linux-foundation.org, ardb@kernel.org, bp@alien8.de, brijesh.singh@amd.com, dave.hansen@intel.com, dfaggioli@suse.com, jroedel@suse.de, linux-coco@lists.linux.dev, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, luto@kernel.org, mingo@redhat.com, pbonzini@redhat.com, peterz@infradead.org, rientjes@google.com, sathyanarayanan.kuppuswamy@linux.intel.com, seanjc@google.com, tglx@linutronix.de, thomas.lendacky@amd.com, varad.gautam@suse.com, vbabka@suse.cz, x86@kernel.org, Mike Rapoport References: <20220130164548.40417-1-kirill.shutemov@linux.intel.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCHv3.1 1/7] mm: Add support for unaccepted memory In-Reply-To: <20220130164548.40417-1-kirill.shutemov@linux.intel.com> Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=david@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 30.01.22 17:45, Kirill A. Shutemov wrote: > UEFI Specification version 2.9 introduces the concept of memory > acceptance. Some Virtual Machine platforms, such as Intel TDX or AMD > SEV-SNP, requiring memory to be accepted before it can be used by the > guest. Accepting happens via a protocol specific for the Virtual Machine > platform. > > Accepting memory is costly and it makes VMM allocate memory for the > accepted guest physical address range. It's better to postpone memory > acceptance until memory is needed. It lowers boot time and reduces > memory overhead. > > Support of such memory requires a few changes in core-mm code: > > - memblock has to accept memory on allocation; > > - page allocator has to accept memory on the first allocation of the > page; > > Memblock change is trivial. > > The page allocator is modified to accept pages on the first allocation. > PageBuddyUnaccepted() is used to indicate that the page requires acceptance. > > Kernel only need to accept memory once after boot, so during the boot > and warm up phase there will be a lot of memory acceptance. After things > are settled down the only price of the feature if couple of checks for > PageBuddyUnaccepted() in alloc and free paths. The check refers a hot > variable (that also encodes PageBuddy()), so it is cheap and not visible > on profiles. > > Architecture has to provide three helpers if it wants to support > unaccepted memory: > > - accept_memory() makes a range of physical addresses accepted. > > - maybe_mark_page_unaccepted() marks a page PageBuddyUnaccepted() if it > requires acceptance. Used during boot to put pages on free lists. > > - accept_page() makes a page accepted and clears PageBuddyUnaccepted(). > > Signed-off-by: Kirill A. Shutemov > Acked-by: Mike Rapoport # memblock You should somehow document+check+enforce that page poisoning cannot be enabled concurrently, because it cannot possibly work IIUC. [...] > + /* > + * PageBuddyUnaccepted() indicates that the page has to be "accepted" before > + * it can be used. Page allocator has to call accept_page() before returning > + * the page to the caller. > + * > + * PageBuddyUnaccepted() encoded with the same bit as PageOffline(). > + * PageOffline() pages are never on free list of buddy allocator, so there's > + * not conflict. > + */ > +#ifdef CONFIG_UNACCEPTED_MEMORY > +PAGE_TYPE_OPS(BuddyUnaccepted, offline) > +#else > +PAGE_TYPE_OPS_FALSE(BuddyUnaccepted) > +#endif Much better. > + > extern void page_offline_freeze(void); > extern void page_offline_thaw(void); > extern void page_offline_begin(void); > diff --git a/mm/internal.h b/mm/internal.h > index d80300392a19..26e5d7cb6aff 100644 > --- a/mm/internal.h > +++ b/mm/internal.h > @@ -718,4 +718,19 @@ void vunmap_range_noflush(unsigned long start, unsigned long end); > int numa_migrate_prep(struct page *page, struct vm_area_struct *vma, > unsigned long addr, int page_nid, int *flags); > > +#ifndef CONFIG_UNACCEPTED_MEMORY > +static inline void maybe_mark_page_unaccepted(struct page *page, > + unsigned int order) > +{ > +} > + > +static inline void accept_page(struct page *page, unsigned int order) > +{ > +} > + > +static inline void accept_memory(phys_addr_t start, phys_addr_t end) > +{ > +} > +#endif > + > #endif /* __MM_INTERNAL_H */ > diff --git a/mm/memblock.c b/mm/memblock.c > index 1018e50566f3..6c109b3b2a02 100644 > --- a/mm/memblock.c > +++ b/mm/memblock.c > @@ -1400,6 +1400,15 @@ phys_addr_t __init memblock_alloc_range_nid(phys_addr_t size, > */ > kmemleak_alloc_phys(found, size, 0, 0); > > + /* > + * Some Virtual Machine platforms, such as Intel TDX or AMD SEV-SNP, > + * require memory to be accepted before it can be used by the > + * guest. > + * > + * Accept the memory of the allocated buffer. > + */ > + accept_memory(found, found + size); > + > return found; > } > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 3589febc6d31..27b9bd20e675 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -1077,6 +1077,7 @@ static inline void __free_one_page(struct page *page, > unsigned int max_order; > struct page *buddy; > bool to_tail; > + bool unaccepted = PageBuddyUnaccepted(page); > > max_order = min_t(unsigned int, MAX_ORDER - 1, pageblock_order); > > @@ -1110,6 +1111,10 @@ static inline void __free_one_page(struct page *page, > clear_page_guard(zone, buddy, order, migratetype); > else > del_page_from_free_list(buddy, zone, order); > + > + if (PageBuddyUnaccepted(buddy)) > + unaccepted = true; > + > combined_pfn = buddy_pfn & pfn; > page = page + (combined_pfn - pfn); > pfn = combined_pfn; > @@ -1143,6 +1148,10 @@ static inline void __free_one_page(struct page *page, > done_merging: > set_buddy_order(page, order); > > + /* Mark page unaccepted if any of merged pages were unaccepted */ > + if (unaccepted) > + __SetPageBuddyUnaccepted(page); > + > if (fpi_flags & FPI_TO_TAIL) > to_tail = true; > else if (is_shuffle_order(order)) > @@ -1168,7 +1177,8 @@ static inline void __free_one_page(struct page *page, > static inline bool page_expected_state(struct page *page, > unsigned long check_flags) > { > - if (unlikely(atomic_read(&page->_mapcount) != -1)) > + if (unlikely(atomic_read(&page->_mapcount) != -1) && > + !PageBuddyUnaccepted(page)) > return false; > > if (unlikely((unsigned long)page->mapping | > @@ -1749,6 +1759,8 @@ void __init memblock_free_pages(struct page *page, unsigned long pfn, > { > if (early_page_uninitialised(pfn)) > return; > + > + maybe_mark_page_unaccepted(page, order); > __free_pages_core(page, order); You'll be setting the page as unaccepted even before it's actually PageBuddy(). While that works, I wonder why we call maybe_mark_page_unaccepted() at these points. Why are we not moving that deeper into the buddy? __free_pages_core() is used for any fresh pages that enter the buddy, used outside of page_alloc.c only for memory hot(un)plug, so I'd suggest moving it at least into there. But maybe we'd even move it further down, to the place where we actually establish PageBuddy(). One idea would be adding a new FPI_UNACCEPTED flag, passing it from __free_pages_core() only, and calling maybe_mark_page_unaccepted() from __free_one_page() after set_buddy_order(). If in-lining would do its job properly, we'd be left with the FPI_UNACCEPTED checks only when called via __free_pages_core(), and we'd have that call at a single place right where we mess with PageBuddy(). -- Thanks, David / dhildenb