All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCHv5 00/12] mm, x86/cc: Implement support for unaccepted memory
@ 2022-04-25  3:39 Kirill A. Shutemov
  2022-04-25  3:39 ` [PATCHv5 01/12] x86/boot/: Centralize __pa()/__va() definitions Kirill A. Shutemov
                   ` (11 more replies)
  0 siblings, 12 replies; 58+ messages in thread
From: Kirill A. Shutemov @ 2022-04-25  3:39 UTC (permalink / raw)
  To: 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,
	Dave Hansen, Brijesh Singh, Mike Rapoport, David Hildenbrand,
	x86, linux-mm, linux-coco, linux-efi, linux-kernel,
	Kirill A. Shutemov

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.

The kernel needs to know what memory has been accepted. Firmware
communicates this information via memory map: a new memory type --
EFI_UNACCEPTED_MEMORY -- indicates such memory.

Range-based tracking works fine for firmware, but it gets bulky for
the kernel: e820 has to be modified on every page acceptance. It leads
to table fragmentation, but there's a limited number of entries in the
e820 table

Another option is to mark such memory as usable in e820 and track if the
range has been accepted in a bitmap. One bit in the bitmap represents
2MiB in the address space: one 4k page is enough to track 64GiB or
physical address space.

In the worst-case scenario -- a huge hole in the middle of the
address space -- It needs 256MiB to handle 4PiB of the address
space.

Any unaccepted memory that is not aligned to 2M gets accepted upfront.

The approach lowers boot time substantially. Boot to shell is ~2.5x
faster for 4G TDX VM and ~4x faster for 64G.

TDX-specific code isolated from the core of unaccepted memory support. It
supposed to help to plug-in different implementation of unaccepted memory
such as SEV-SNP.

The tree can be found here:

https://github.com/intel/tdx.git guest-unaccepted-memory

v5:
 - Updates comments and commit messages;
   + Explain options for unaccepted memory handling;
 - Expose amount of unaccepted memory in /proc/meminfo
 - Adjust check in page_expected_state();
 - Fix error code handling in allocate_e820();
 - Centralize __pa()/__va() definitions in the boot stub;
 - Avoid includes from the main kernel in the boot stub;
 - Use an existing hole in boot_param for unaccepted_memory, instead of adding
   to the end of the structure;
 - Extract allocate_unaccepted_memory() form allocate_e820();
 - Complain if there's unaccepted memory, but kernel does not support it;
 - Fix vmstat counter;
 - Split up few preparatory patches;
 - Random readability adjustments;
v4:
 - PageBuddyUnaccepted() -> PageUnaccepted;
 - Use separate page_type, not shared with offline;
 - Rework interface between core-mm and arch code;
 - Adjust commit messages;
 - Ack from Mike;

Kirill A. Shutemov (12):
  x86/boot/: Centralize __pa()/__va() definitions
  mm: Add support for unaccepted memory
  efi/x86: Get full memory map in allocate_e820()
  x86/boot: Add infrastructure required for unaccepted memory support
  efi/x86: Implement support for unaccepted memory
  x86/boot/compressed: Handle unaccepted memory
  x86/mm: Reserve unaccepted memory bitmap
  x86/mm: Provide helpers for unaccepted memory
  x86/tdx: Make _tdx_hypercall() and __tdx_module_call() available in
    boot stub
  x86/tdx: Unaccepted memory support
  mm/vmstat: Add counter for memory accepting
  x86/mm: Report unaccepted memory in /proc/meminfo

 Documentation/x86/zero-page.rst          |   1 +
 arch/x86/Kconfig                         |   1 +
 arch/x86/boot/bitops.h                   |  40 ++++++++
 arch/x86/boot/compressed/Makefile        |   1 +
 arch/x86/boot/compressed/align.h         |  14 +++
 arch/x86/boot/compressed/bitmap.c        |  43 +++++++++
 arch/x86/boot/compressed/bitmap.h        |  49 ++++++++++
 arch/x86/boot/compressed/bits.h          |  36 ++++++++
 arch/x86/boot/compressed/compiler.h      |   9 ++
 arch/x86/boot/compressed/find.c          |  54 +++++++++++
 arch/x86/boot/compressed/find.h          |  80 ++++++++++++++++
 arch/x86/boot/compressed/ident_map_64.c  |   8 --
 arch/x86/boot/compressed/kaslr.c         |  14 ++-
 arch/x86/boot/compressed/math.h          |  37 ++++++++
 arch/x86/boot/compressed/mem.c           | 111 +++++++++++++++++++++++
 arch/x86/boot/compressed/minmax.h        |  61 +++++++++++++
 arch/x86/boot/compressed/misc.c          |   9 ++
 arch/x86/boot/compressed/misc.h          |   9 ++
 arch/x86/boot/compressed/sev.c           |   2 -
 arch/x86/boot/compressed/tdx.c           |  85 +++++++++++++++++
 arch/x86/coco/tdx/tdx.c                  |  57 +++++-------
 arch/x86/include/asm/page.h              |   3 +
 arch/x86/include/asm/set_memory.h        |   2 +
 arch/x86/include/asm/shared/tdx.h        |  47 ++++++++++
 arch/x86/include/asm/tdx.h               |  19 ----
 arch/x86/include/asm/unaccepted_memory.h |  25 +++++
 arch/x86/include/uapi/asm/bootparam.h    |   2 +-
 arch/x86/kernel/e820.c                   |  10 ++
 arch/x86/mm/Makefile                     |   2 +
 arch/x86/mm/init.c                       |   8 ++
 arch/x86/mm/pat/set_memory.c             |   2 +-
 arch/x86/mm/unaccepted_memory.c          |  98 ++++++++++++++++++++
 drivers/firmware/efi/Kconfig             |  15 +++
 drivers/firmware/efi/efi.c               |   1 +
 drivers/firmware/efi/libstub/x86-stub.c  |  97 +++++++++++++++++---
 include/linux/efi.h                      |   3 +-
 include/linux/page-flags.h               |  31 +++++++
 include/linux/vm_event_item.h            |   3 +
 mm/internal.h                            |  11 +++
 mm/memblock.c                            |   9 ++
 mm/page_alloc.c                          |  77 +++++++++++++++-
 mm/vmstat.c                              |   3 +
 42 files changed, 1103 insertions(+), 86 deletions(-)
 create mode 100644 arch/x86/boot/compressed/align.h
 create mode 100644 arch/x86/boot/compressed/bitmap.c
 create mode 100644 arch/x86/boot/compressed/bitmap.h
 create mode 100644 arch/x86/boot/compressed/bits.h
 create mode 100644 arch/x86/boot/compressed/compiler.h
 create mode 100644 arch/x86/boot/compressed/find.c
 create mode 100644 arch/x86/boot/compressed/find.h
 create mode 100644 arch/x86/boot/compressed/math.h
 create mode 100644 arch/x86/boot/compressed/mem.c
 create mode 100644 arch/x86/boot/compressed/minmax.h
 create mode 100644 arch/x86/include/asm/unaccepted_memory.h
 create mode 100644 arch/x86/mm/unaccepted_memory.c

-- 
2.35.1


^ permalink raw reply	[flat|nested] 58+ messages in thread

* [PATCHv5 01/12] x86/boot/: Centralize __pa()/__va() definitions
  2022-04-25  3:39 [PATCHv5 00/12] mm, x86/cc: Implement support for unaccepted memory Kirill A. Shutemov
@ 2022-04-25  3:39 ` Kirill A. Shutemov
  2022-04-25  7:37   ` David Hildenbrand
  2022-04-25  7:52   ` Mike Rapoport
  2022-04-25  3:39 ` [PATCHv5 02/12] mm: Add support for unaccepted memory Kirill A. Shutemov
                   ` (10 subsequent siblings)
  11 siblings, 2 replies; 58+ messages in thread
From: Kirill A. Shutemov @ 2022-04-25  3:39 UTC (permalink / raw)
  To: 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,
	Dave Hansen, Brijesh Singh, Mike Rapoport, David Hildenbrand,
	x86, linux-mm, linux-coco, linux-efi, linux-kernel,
	Kirill A. Shutemov

Replace multiple __pa()/__va() definitions with a single one in misc.h.

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
 arch/x86/boot/compressed/ident_map_64.c | 8 --------
 arch/x86/boot/compressed/misc.h         | 9 +++++++++
 arch/x86/boot/compressed/sev.c          | 2 --
 3 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/arch/x86/boot/compressed/ident_map_64.c b/arch/x86/boot/compressed/ident_map_64.c
index f7213d0943b8..fe523ee1a19f 100644
--- a/arch/x86/boot/compressed/ident_map_64.c
+++ b/arch/x86/boot/compressed/ident_map_64.c
@@ -8,14 +8,6 @@
  * Copyright (C)      2016  Kees Cook
  */
 
-/*
- * Since we're dealing with identity mappings, physical and virtual
- * addresses are the same, so override these defines which are ultimately
- * used by the headers in misc.h.
- */
-#define __pa(x)  ((unsigned long)(x))
-#define __va(x)  ((void *)((unsigned long)(x)))
-
 /* No PAGE_TABLE_ISOLATION support needed either: */
 #undef CONFIG_PAGE_TABLE_ISOLATION
 
diff --git a/arch/x86/boot/compressed/misc.h b/arch/x86/boot/compressed/misc.h
index ea71cf3d64e1..9f7154a30d37 100644
--- a/arch/x86/boot/compressed/misc.h
+++ b/arch/x86/boot/compressed/misc.h
@@ -19,6 +19,15 @@
 /* cpu_feature_enabled() cannot be used this early */
 #define USE_EARLY_PGTABLE_L5
 
+/*
+ * Boot stub deals with identity mappings, physical and virtual addresses are
+ * the same, so override these defines.
+ *
+ * <asm/page.h> will not define them if they are already defined.
+ */
+#define __pa(x)  ((unsigned long)(x))
+#define __va(x)  ((void *)((unsigned long)(x)))
+
 #include <linux/linkage.h>
 #include <linux/screen_info.h>
 #include <linux/elf.h>
diff --git a/arch/x86/boot/compressed/sev.c b/arch/x86/boot/compressed/sev.c
index 28bcf04c022e..4dcea0bc4fe4 100644
--- a/arch/x86/boot/compressed/sev.c
+++ b/arch/x86/boot/compressed/sev.c
@@ -106,9 +106,7 @@ static enum es_result vc_read_mem(struct es_em_ctxt *ctxt,
 }
 
 #undef __init
-#undef __pa
 #define __init
-#define __pa(x)	((unsigned long)(x))
 
 #define __BOOT_COMPRESSED
 
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 58+ messages in thread

* [PATCHv5 02/12] mm: Add support for unaccepted memory
  2022-04-25  3:39 [PATCHv5 00/12] mm, x86/cc: Implement support for unaccepted memory Kirill A. Shutemov
  2022-04-25  3:39 ` [PATCHv5 01/12] x86/boot/: Centralize __pa()/__va() definitions Kirill A. Shutemov
@ 2022-04-25  3:39 ` Kirill A. Shutemov
  2022-04-28 10:05   ` Borislav Petkov
  2022-05-03 20:21   ` David Hildenbrand
  2022-04-25  3:39 ` [PATCHv5 03/12] efi/x86: Get full memory map in allocate_e820() Kirill A. Shutemov
                   ` (9 subsequent siblings)
  11 siblings, 2 replies; 58+ messages in thread
From: Kirill A. Shutemov @ 2022-04-25  3:39 UTC (permalink / raw)
  To: 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,
	Dave Hansen, Brijesh Singh, Mike Rapoport, David Hildenbrand,
	x86, linux-mm, linux-coco, linux-efi, linux-kernel,
	Kirill A. Shutemov, Mike Rapoport

UEFI Specification version 2.9 introduces the concept of memory
acceptance. 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. Accepting happens via a protocol specific to the Virtual Machine
platform.

There are several ways kernel can deal with unaccepted memory:

 1. Accept all the memory during the boot. It is easy to implement and
    it doesn't have runtime cost once the system is booted. The downside
    is very long boot time.

    Accept can be parallelized to multiple CPUs to keep it manageable
    (i.e. via DEFERRED_STRUCT_PAGE_INIT), but it tends to saturate
    memory bandwidth and does not scale beyond the point.

 2. Accept a block of memory on the first use. It requires more
    infrastructure and changes in page allocator to make it work, but
    it provides good boot time.

    On-demand memory accept means latency spikes every time kernel steps
    onto a new memory block. The spikes will go away once workload data
    set size gets stabilized or all memory gets accepted.

 3. Accept all memory in background. Introduce a thread (or multiple)
    that gets memory accepted proactively. It will minimize time the
    system experience latency spikes on memory allocation while keeping
    low boot time.

    This approach cannot function on its own. It is an extension of #2:
    background memory acceptance requires functional scheduler, but the
    page allocator may need to tap into unaccepted memory before that.

    The downside of the approach is that these threads also steal CPU
    cycles and memory bandwidth from the user's workload and may hurt
    user experience.

Implement #2 for now. It is a reasonable default. Some workloads may
want to use #1 or #3 and they can be implemented later based on user's
demands.

Support of unaccepted 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.
The new page type (encoded in the _mapcount) -- PageUnaccepted() -- is
used to indicate that the page requires acceptance.

Architecture has to provide two helpers if it wants to support
unaccepted memory:

 - accept_memory() makes a range of physical addresses accepted.

 - memory_is_unaccepted() checks anything within the range of physical
   addresses requires acceptance.

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Mike Rapoport <rppt@linux.ibm.com>	# memblock
---
 include/linux/page-flags.h | 31 +++++++++++++++
 mm/internal.h              | 11 ++++++
 mm/memblock.c              |  9 +++++
 mm/page_alloc.c            | 77 +++++++++++++++++++++++++++++++++++++-
 4 files changed, 126 insertions(+), 2 deletions(-)

diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index 9d8eeaa67d05..7f21267366a9 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -928,6 +928,14 @@ static inline bool is_page_hwpoison(struct page *page)
 #define PG_offline	0x00000100
 #define PG_table	0x00000200
 #define PG_guard	0x00000400
+#define PG_unaccepted	0x00000800
+
+/*
+ * Page types allowed at page_expected_state()
+ *
+ * PageUnaccepted() will get cleared in post_alloc_hook().
+ */
+#define PAGE_TYPES_EXPECTED	PG_unaccepted
 
 #define PageType(page, flag)						\
 	((page->page_type & (PAGE_TYPE_BASE | flag)) == PAGE_TYPE_BASE)
@@ -953,6 +961,18 @@ static __always_inline void __ClearPage##uname(struct page *page)	\
 	page->page_type |= PG_##lname;					\
 }
 
+#define PAGE_TYPE_OPS_FALSE(uname)					\
+static __always_inline int Page##uname(struct page *page)		\
+{									\
+	return false;							\
+}									\
+static __always_inline void __SetPage##uname(struct page *page)		\
+{									\
+}									\
+static __always_inline void __ClearPage##uname(struct page *page)	\
+{									\
+}
+
 /*
  * PageBuddy() indicates that the page is free and in the buddy system
  * (see mm/page_alloc.c).
@@ -983,6 +1003,17 @@ PAGE_TYPE_OPS(Buddy, buddy)
  */
 PAGE_TYPE_OPS(Offline, offline)
 
+/*
+ * PageUnaccepted() indicates that the page has to be "accepted" before it can
+ * be read or written. The page allocator must call accept_page() before
+ * touching the page or returning it to the caller.
+ */
+#ifdef CONFIG_UNACCEPTED_MEMORY
+PAGE_TYPE_OPS(Unaccepted, unaccepted)
+#else
+PAGE_TYPE_OPS_FALSE(Unaccepted)
+#endif
+
 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 cf16280ce132..10302fe857c4 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -758,4 +758,15 @@ struct folio *try_grab_folio(struct page *page, int refs, unsigned int flags);
 
 DECLARE_PER_CPU(struct per_cpu_nodestat, boot_nodestats);
 
+#ifndef CONFIG_UNACCEPTED_MEMORY
+static inline bool memory_is_unaccepted(phys_addr_t start, phys_addr_t end)
+{
+	return false;
+}
+
+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 e4f03a6e8e56..a1f7f8b304d5 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1405,6 +1405,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 6e5b4488a0c5..d38cfb146f11 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -121,6 +121,12 @@ typedef int __bitwise fpi_t;
  */
 #define FPI_SKIP_KASAN_POISON	((__force fpi_t)BIT(2))
 
+/*
+ * Check if the page needs to be marked as PageUnaccepted().
+ * Used for the new pages added to the buddy allocator for the first time.
+ */
+#define FPI_UNACCEPTED_SLOWPATH	((__force fpi_t)BIT(3))
+
 /* prevent >1 _updater_ of zone percpu pageset ->high and ->batch fields */
 static DEFINE_MUTEX(pcp_batch_high_lock);
 #define MIN_PERCPU_PAGELIST_HIGH_FRACTION (8)
@@ -1023,6 +1029,29 @@ buddy_merge_likely(unsigned long pfn, unsigned long buddy_pfn,
 	return page_is_buddy(higher_page, higher_buddy, order + 1);
 }
 
+/*
+ * Page acceptance can be very slow. Do not call under critical locks.
+ */
+static void accept_page(struct page *page, unsigned int order)
+{
+	phys_addr_t start = page_to_phys(page);
+	int i;
+
+	accept_memory(start, start + (PAGE_SIZE << order));
+
+	for (i = 0; i < (1 << order); i++) {
+		if (PageUnaccepted(page + i))
+			__ClearPageUnaccepted(page + i);
+	}
+}
+
+static bool page_is_unaccepted(struct page *page, unsigned int order)
+{
+	phys_addr_t start = page_to_phys(page);
+
+	return memory_is_unaccepted(start, start + (PAGE_SIZE << order));
+}
+
 /*
  * Freeing function for a buddy system allocator.
  *
@@ -1058,6 +1087,7 @@ static inline void __free_one_page(struct page *page,
 	unsigned long combined_pfn;
 	struct page *buddy;
 	bool to_tail;
+	bool page_needs_acceptance = PageUnaccepted(page);
 
 	VM_BUG_ON(!zone_is_initialized(zone));
 	VM_BUG_ON_PAGE(page->flags & PAGE_FLAGS_CHECK_AT_PREP, page);
@@ -1089,6 +1119,11 @@ 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);
+
+		/* Mark page unaccepted if any of merged pages were unaccepted */
+		if (PageUnaccepted(buddy))
+			page_needs_acceptance = true;
+
 		combined_pfn = buddy_pfn & pfn;
 		page = page + (combined_pfn - pfn);
 		pfn = combined_pfn;
@@ -1124,6 +1159,23 @@ static inline void __free_one_page(struct page *page,
 done_merging:
 	set_buddy_order(page, order);
 
+	/*
+	 * The page gets marked as PageUnaccepted() if any of merged-in pages
+	 * is PageUnaccepted().
+	 *
+	 * New pages, just being added to buddy allocator, do not have
+	 * PageUnaccepted() set. FPI_UNACCEPTED_SLOWPATH indicates that the
+	 * page is new and page_is_unaccepted() check is required to
+	 * determinate if accaptance is required.
+	 *
+	 * Avoid calling page_is_unaccepted() if it is known that the page
+	 * needs acceptance. It can be costly.
+	 */
+	if (!page_needs_acceptance && (fpi_flags & FPI_UNACCEPTED_SLOWPATH))
+		page_needs_acceptance = page_is_unaccepted(page, order);
+	if (page_needs_acceptance)
+		__SetPageUnaccepted(page);
+
 	if (fpi_flags & FPI_TO_TAIL)
 		to_tail = true;
 	else if (is_shuffle_order(order))
@@ -1149,7 +1201,13 @@ 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))
+	/*
+	 * The page must not be mapped to userspace and must not have
+	 * a PageType other than listed in PAGE_TYPES_EXPECTED.
+	 *
+	 * Note, bit cleared means the page type is set.
+	 */
+	if (unlikely((atomic_read(&page->_mapcount) | PAGE_TYPES_EXPECTED) != -1))
 		return false;
 
 	if (unlikely((unsigned long)page->mapping |
@@ -1654,7 +1712,9 @@ void __free_pages_core(struct page *page, unsigned int order)
 	 * Bypass PCP and place fresh pages right to the tail, primarily
 	 * relevant for memory onlining.
 	 */
-	__free_pages_ok(page, order, FPI_TO_TAIL | FPI_SKIP_KASAN_POISON);
+	__free_pages_ok(page, order,
+			FPI_TO_TAIL | FPI_SKIP_KASAN_POISON |
+			FPI_UNACCEPTED_SLOWPATH);
 }
 
 #ifdef CONFIG_NUMA
@@ -1807,6 +1867,9 @@ static void __init deferred_free_range(unsigned long pfn,
 		return;
 	}
 
+	/* Accept chunks smaller than page-block upfront */
+	accept_memory(pfn << PAGE_SHIFT, (pfn + nr_pages) << PAGE_SHIFT);
+
 	for (i = 0; i < nr_pages; i++, page++, pfn++) {
 		if ((pfn & (pageblock_nr_pages - 1)) == 0)
 			set_pageblock_migratetype(page, MIGRATE_MOVABLE);
@@ -2266,6 +2329,13 @@ static inline void expand(struct zone *zone, struct page *page,
 		if (set_page_guard(zone, &page[size], high, migratetype))
 			continue;
 
+		/*
+		 * Transfer PageUnaccepted() to the newly split pages so
+		 * they can be accepted after dropping the zone lock.
+		 */
+		if (PageUnaccepted(page))
+			__SetPageUnaccepted(&page[size]);
+
 		add_to_free_list(&page[size], zone, high, migratetype);
 		set_buddy_order(&page[size], high);
 	}
@@ -2396,6 +2466,9 @@ inline void post_alloc_hook(struct page *page, unsigned int order,
 	 */
 	kernel_unpoison_pages(page, 1 << order);
 
+	if (PageUnaccepted(page))
+		accept_page(page, order);
+
 	/*
 	 * As memory initialization might be integrated into KASAN,
 	 * KASAN unpoisoning and memory initializion code must be
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 58+ messages in thread

* [PATCHv5 03/12] efi/x86: Get full memory map in allocate_e820()
  2022-04-25  3:39 [PATCHv5 00/12] mm, x86/cc: Implement support for unaccepted memory Kirill A. Shutemov
  2022-04-25  3:39 ` [PATCHv5 01/12] x86/boot/: Centralize __pa()/__va() definitions Kirill A. Shutemov
  2022-04-25  3:39 ` [PATCHv5 02/12] mm: Add support for unaccepted memory Kirill A. Shutemov
@ 2022-04-25  3:39 ` Kirill A. Shutemov
  2022-04-27 20:25   ` Borislav Petkov
  2022-04-25  3:39 ` [PATCHv5 04/12] x86/boot: Add infrastructure required for unaccepted memory support Kirill A. Shutemov
                   ` (8 subsequent siblings)
  11 siblings, 1 reply; 58+ messages in thread
From: Kirill A. Shutemov @ 2022-04-25  3:39 UTC (permalink / raw)
  To: 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,
	Dave Hansen, Brijesh Singh, Mike Rapoport, David Hildenbrand,
	x86, linux-mm, linux-coco, linux-efi, linux-kernel,
	Kirill A. Shutemov

Currently allocate_e820() only interested in the size of map and size of
memory descriptor to determine how many e820 entries the kernel needs.

UEFI Specification version 2.9 introduces a new memory type --
unaccepted memory. To track unaccepted memory kernel needs to allocate
a bitmap. The size of the bitmap is dependent on the maximum physical
address present in the system. A full memory map is required to find
the maximum address.

Modify allocate_e820() to get a full memory map.

This is preparation for the next patch that implements handling of
unaccepted memory in EFI stub.

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
 drivers/firmware/efi/libstub/x86-stub.c | 30 ++++++++++++-------------
 1 file changed, 14 insertions(+), 16 deletions(-)

diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c
index 01ddd4502e28..5401985901f5 100644
--- a/drivers/firmware/efi/libstub/x86-stub.c
+++ b/drivers/firmware/efi/libstub/x86-stub.c
@@ -569,31 +569,29 @@ static efi_status_t alloc_e820ext(u32 nr_desc, struct setup_data **e820ext,
 }
 
 static efi_status_t allocate_e820(struct boot_params *params,
+				  struct efi_boot_memmap *map,
 				  struct setup_data **e820ext,
 				  u32 *e820ext_size)
 {
-	unsigned long map_size, desc_size, map_key;
 	efi_status_t status;
-	__u32 nr_desc, desc_version;
+	__u32 nr_desc;
 
-	/* Only need the size of the mem map and size of each mem descriptor */
-	map_size = 0;
-	status = efi_bs_call(get_memory_map, &map_size, NULL, &map_key,
-			     &desc_size, &desc_version);
-	if (status != EFI_BUFFER_TOO_SMALL)
-		return (status != EFI_SUCCESS) ? status : EFI_UNSUPPORTED;
-
-	nr_desc = map_size / desc_size + EFI_MMAP_NR_SLACK_SLOTS;
+	status = efi_get_memory_map(map);
+	if (status != EFI_SUCCESS)
+		return status;
 
-	if (nr_desc > ARRAY_SIZE(params->e820_table)) {
-		u32 nr_e820ext = nr_desc - ARRAY_SIZE(params->e820_table);
+	nr_desc = *map->map_size / *map->desc_size;
+	if (nr_desc > ARRAY_SIZE(params->e820_table) - EFI_MMAP_NR_SLACK_SLOTS) {
+		u32 nr_e820ext = nr_desc - ARRAY_SIZE(params->e820_table) +
+			EFI_MMAP_NR_SLACK_SLOTS;
 
 		status = alloc_e820ext(nr_e820ext, e820ext, e820ext_size);
 		if (status != EFI_SUCCESS)
-			return status;
+			goto out;
 	}
-
-	return EFI_SUCCESS;
+out:
+	efi_bs_call(free_pool, *map->map);
+	return status;
 }
 
 struct exit_boot_struct {
@@ -642,7 +640,7 @@ static efi_status_t exit_boot(struct boot_params *boot_params, void *handle)
 	priv.boot_params	= boot_params;
 	priv.efi		= &boot_params->efi_info;
 
-	status = allocate_e820(boot_params, &e820ext, &e820ext_size);
+	status = allocate_e820(boot_params, &map, &e820ext, &e820ext_size);
 	if (status != EFI_SUCCESS)
 		return status;
 
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 58+ messages in thread

* [PATCHv5 04/12] x86/boot: Add infrastructure required for unaccepted memory support
  2022-04-25  3:39 [PATCHv5 00/12] mm, x86/cc: Implement support for unaccepted memory Kirill A. Shutemov
                   ` (2 preceding siblings ...)
  2022-04-25  3:39 ` [PATCHv5 03/12] efi/x86: Get full memory map in allocate_e820() Kirill A. Shutemov
@ 2022-04-25  3:39 ` Kirill A. Shutemov
  2022-04-29 10:58   ` Wander Lairson Costa
  2022-04-25  3:39 ` [PATCHv5 05/12] efi/x86: Implement support for unaccepted memory Kirill A. Shutemov
                   ` (7 subsequent siblings)
  11 siblings, 1 reply; 58+ messages in thread
From: Kirill A. Shutemov @ 2022-04-25  3:39 UTC (permalink / raw)
  To: 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,
	Dave Hansen, Brijesh Singh, Mike Rapoport, David Hildenbrand,
	x86, linux-mm, linux-coco, linux-efi, linux-kernel,
	Kirill A. Shutemov

Pull functionality from the main kernel headers and lib/ that is
required for unaccepted memory support.

This is preparatory patch. The users for the functionality will come in
following patches.

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
 arch/x86/boot/bitops.h              | 40 +++++++++++++++
 arch/x86/boot/compressed/align.h    | 14 +++++
 arch/x86/boot/compressed/bitmap.c   | 43 ++++++++++++++++
 arch/x86/boot/compressed/bitmap.h   | 49 ++++++++++++++++++
 arch/x86/boot/compressed/bits.h     | 36 +++++++++++++
 arch/x86/boot/compressed/compiler.h |  9 ++++
 arch/x86/boot/compressed/find.c     | 54 +++++++++++++++++++
 arch/x86/boot/compressed/find.h     | 80 +++++++++++++++++++++++++++++
 arch/x86/boot/compressed/math.h     | 37 +++++++++++++
 arch/x86/boot/compressed/minmax.h   | 61 ++++++++++++++++++++++
 10 files changed, 423 insertions(+)
 create mode 100644 arch/x86/boot/compressed/align.h
 create mode 100644 arch/x86/boot/compressed/bitmap.c
 create mode 100644 arch/x86/boot/compressed/bitmap.h
 create mode 100644 arch/x86/boot/compressed/bits.h
 create mode 100644 arch/x86/boot/compressed/compiler.h
 create mode 100644 arch/x86/boot/compressed/find.c
 create mode 100644 arch/x86/boot/compressed/find.h
 create mode 100644 arch/x86/boot/compressed/math.h
 create mode 100644 arch/x86/boot/compressed/minmax.h

diff --git a/arch/x86/boot/bitops.h b/arch/x86/boot/bitops.h
index 02e1dea11d94..61eb820ee402 100644
--- a/arch/x86/boot/bitops.h
+++ b/arch/x86/boot/bitops.h
@@ -41,4 +41,44 @@ static inline void set_bit(int nr, void *addr)
 	asm("btsl %1,%0" : "+m" (*(u32 *)addr) : "Ir" (nr));
 }
 
+static __always_inline void __set_bit(long nr, volatile unsigned long *addr)
+{
+	asm volatile(__ASM_SIZE(bts) " %1,%0" : : "m" (*(volatile long *) addr),
+		     "Ir" (nr) : "memory");
+}
+
+static __always_inline void __clear_bit(long nr, volatile unsigned long *addr)
+{
+	asm volatile(__ASM_SIZE(btr) " %1,%0" : : "m" (*(volatile long *) addr),
+		     "Ir" (nr) : "memory");
+}
+
+/**
+ * __ffs - find first set bit in word
+ * @word: The word to search
+ *
+ * Undefined if no bit exists, so code should check against 0 first.
+ */
+static __always_inline unsigned long __ffs(unsigned long word)
+{
+	asm("rep; bsf %1,%0"
+		: "=r" (word)
+		: "rm" (word));
+	return word;
+}
+
+/**
+ * ffz - find first zero bit in word
+ * @word: The word to search
+ *
+ * Undefined if no zero exists, so code should check against ~0UL first.
+ */
+static __always_inline unsigned long ffz(unsigned long word)
+{
+	asm("rep; bsf %1,%0"
+		: "=r" (word)
+		: "r" (~word));
+	return word;
+}
+
 #endif /* BOOT_BITOPS_H */
diff --git a/arch/x86/boot/compressed/align.h b/arch/x86/boot/compressed/align.h
new file mode 100644
index 000000000000..c72ff4e8dd63
--- /dev/null
+++ b/arch/x86/boot/compressed/align.h
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#ifndef BOOT_ALIGN_H
+#define BOOT_ALIGN_H
+#define _LINUX_ALIGN_H /* Inhibit inclusion of <linux/align.h> */
+
+/* @a is a power of 2 value */
+#define ALIGN(x, a)		__ALIGN_KERNEL((x), (a))
+#define ALIGN_DOWN(x, a)	__ALIGN_KERNEL((x) - ((a) - 1), (a))
+#define __ALIGN_MASK(x, mask)	__ALIGN_KERNEL_MASK((x), (mask))
+#define PTR_ALIGN(p, a)		((typeof(p))ALIGN((unsigned long)(p), (a)))
+#define PTR_ALIGN_DOWN(p, a)	((typeof(p))ALIGN_DOWN((unsigned long)(p), (a)))
+#define IS_ALIGNED(x, a)		(((x) & ((typeof(x))(a) - 1)) == 0)
+
+#endif
diff --git a/arch/x86/boot/compressed/bitmap.c b/arch/x86/boot/compressed/bitmap.c
new file mode 100644
index 000000000000..789ecadeb521
--- /dev/null
+++ b/arch/x86/boot/compressed/bitmap.c
@@ -0,0 +1,43 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include "bitmap.h"
+
+void __bitmap_set(unsigned long *map, unsigned int start, int len)
+{
+	unsigned long *p = map + BIT_WORD(start);
+	const unsigned int size = start + len;
+	int bits_to_set = BITS_PER_LONG - (start % BITS_PER_LONG);
+	unsigned long mask_to_set = BITMAP_FIRST_WORD_MASK(start);
+
+	while (len - bits_to_set >= 0) {
+		*p |= mask_to_set;
+		len -= bits_to_set;
+		bits_to_set = BITS_PER_LONG;
+		mask_to_set = ~0UL;
+		p++;
+	}
+	if (len) {
+		mask_to_set &= BITMAP_LAST_WORD_MASK(size);
+		*p |= mask_to_set;
+	}
+}
+
+void __bitmap_clear(unsigned long *map, unsigned int start, int len)
+{
+	unsigned long *p = map + BIT_WORD(start);
+	const unsigned int size = start + len;
+	int bits_to_clear = BITS_PER_LONG - (start % BITS_PER_LONG);
+	unsigned long mask_to_clear = BITMAP_FIRST_WORD_MASK(start);
+
+	while (len - bits_to_clear >= 0) {
+		*p &= ~mask_to_clear;
+		len -= bits_to_clear;
+		bits_to_clear = BITS_PER_LONG;
+		mask_to_clear = ~0UL;
+		p++;
+	}
+	if (len) {
+		mask_to_clear &= BITMAP_LAST_WORD_MASK(size);
+		*p &= ~mask_to_clear;
+	}
+}
diff --git a/arch/x86/boot/compressed/bitmap.h b/arch/x86/boot/compressed/bitmap.h
new file mode 100644
index 000000000000..34cce38d94e9
--- /dev/null
+++ b/arch/x86/boot/compressed/bitmap.h
@@ -0,0 +1,49 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#ifndef BOOT_BITMAP_H
+#define BOOT_BITMAP_H
+#define __LINUX_BITMAP_H /* Inhibit inclusion of <linux/bitmap.h> */
+
+#include "../bitops.h"
+#include "../string.h"
+#include "align.h"
+
+#define BITMAP_MEM_ALIGNMENT 8
+#define BITMAP_MEM_MASK (BITMAP_MEM_ALIGNMENT - 1)
+
+#define BITMAP_FIRST_WORD_MASK(start) (~0UL << ((start) & (BITS_PER_LONG - 1)))
+#define BITMAP_LAST_WORD_MASK(nbits) (~0UL >> (-(nbits) & (BITS_PER_LONG - 1)))
+
+#define BIT_WORD(nr)		((nr) / BITS_PER_LONG)
+
+void __bitmap_set(unsigned long *map, unsigned int start, int len);
+void __bitmap_clear(unsigned long *map, unsigned int start, int len);
+
+static __always_inline void bitmap_set(unsigned long *map, unsigned int start,
+		unsigned int nbits)
+{
+	if (__builtin_constant_p(nbits) && nbits == 1)
+		__set_bit(start, map);
+	else if (__builtin_constant_p(start & BITMAP_MEM_MASK) &&
+		 IS_ALIGNED(start, BITMAP_MEM_ALIGNMENT) &&
+		 __builtin_constant_p(nbits & BITMAP_MEM_MASK) &&
+		 IS_ALIGNED(nbits, BITMAP_MEM_ALIGNMENT))
+		memset((char *)map + start / 8, 0xff, nbits / 8);
+	else
+		__bitmap_set(map, start, nbits);
+}
+
+static __always_inline void bitmap_clear(unsigned long *map, unsigned int start,
+		unsigned int nbits)
+{
+	if (__builtin_constant_p(nbits) && nbits == 1)
+		__clear_bit(start, map);
+	else if (__builtin_constant_p(start & BITMAP_MEM_MASK) &&
+		 IS_ALIGNED(start, BITMAP_MEM_ALIGNMENT) &&
+		 __builtin_constant_p(nbits & BITMAP_MEM_MASK) &&
+		 IS_ALIGNED(nbits, BITMAP_MEM_ALIGNMENT))
+		memset((char *)map + start / 8, 0, nbits / 8);
+	else
+		__bitmap_clear(map, start, nbits);
+}
+
+#endif
diff --git a/arch/x86/boot/compressed/bits.h b/arch/x86/boot/compressed/bits.h
new file mode 100644
index 000000000000..b00cd13c63c8
--- /dev/null
+++ b/arch/x86/boot/compressed/bits.h
@@ -0,0 +1,36 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#ifndef BOOT_BITS_H
+#define BOOT_BITS_H
+#define __LINUX_BITS_H /* Inhibit inclusion of <linux/bits.h> */
+
+#ifdef __ASSEMBLY__
+#define _AC(X,Y)	X
+#define _AT(T,X)	X
+#else
+#define __AC(X,Y)	(X##Y)
+#define _AC(X,Y)	__AC(X,Y)
+#define _AT(T,X)	((T)(X))
+#endif
+
+#define _UL(x)		(_AC(x, UL))
+#define _ULL(x)		(_AC(x, ULL))
+#define UL(x)		(_UL(x))
+#define ULL(x)		(_ULL(x))
+
+#define BIT(nr)			(UL(1) << (nr))
+#define BIT_ULL(nr)		(ULL(1) << (nr))
+#define BIT_MASK(nr)		(UL(1) << ((nr) % BITS_PER_LONG))
+#define BIT_WORD(nr)		((nr) / BITS_PER_LONG)
+#define BIT_ULL_MASK(nr)	(ULL(1) << ((nr) % BITS_PER_LONG_LONG))
+#define BIT_ULL_WORD(nr)	((nr) / BITS_PER_LONG_LONG)
+#define BITS_PER_BYTE		8
+
+#define GENMASK(h, l) \
+	(((~UL(0)) - (UL(1) << (l)) + 1) & \
+	 (~UL(0) >> (BITS_PER_LONG - 1 - (h))))
+
+#define GENMASK_ULL(h, l) \
+	(((~ULL(0)) - (ULL(1) << (l)) + 1) & \
+	 (~ULL(0) >> (BITS_PER_LONG_LONG - 1 - (h))))
+
+#endif
diff --git a/arch/x86/boot/compressed/compiler.h b/arch/x86/boot/compressed/compiler.h
new file mode 100644
index 000000000000..72e20cf01465
--- /dev/null
+++ b/arch/x86/boot/compressed/compiler.h
@@ -0,0 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#ifndef BOOT_COMPILER_H
+#define BOOT_COMPILER_H
+#define __LINUX_COMPILER_H /* Inhibit inclusion of <linux/compiler.h> */
+
+# define likely(x)	__builtin_expect(!!(x), 1)
+# define unlikely(x)	__builtin_expect(!!(x), 0)
+
+#endif
diff --git a/arch/x86/boot/compressed/find.c b/arch/x86/boot/compressed/find.c
new file mode 100644
index 000000000000..839be91aae52
--- /dev/null
+++ b/arch/x86/boot/compressed/find.c
@@ -0,0 +1,54 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#include "bitmap.h"
+#include "find.h"
+#include "math.h"
+#include "minmax.h"
+
+static __always_inline unsigned long swab(const unsigned long y)
+{
+#if __BITS_PER_LONG == 64
+	return __builtin_bswap32(y);
+#else /* __BITS_PER_LONG == 32 */
+	return __builtin_bswap64(y);
+#endif
+}
+
+unsigned long _find_next_bit(const unsigned long *addr1,
+		const unsigned long *addr2, unsigned long nbits,
+		unsigned long start, unsigned long invert, unsigned long le)
+{
+	unsigned long tmp, mask;
+
+	if (unlikely(start >= nbits))
+		return nbits;
+
+	tmp = addr1[start / BITS_PER_LONG];
+	if (addr2)
+		tmp &= addr2[start / BITS_PER_LONG];
+	tmp ^= invert;
+
+	/* Handle 1st word. */
+	mask = BITMAP_FIRST_WORD_MASK(start);
+	if (le)
+		mask = swab(mask);
+
+	tmp &= mask;
+
+	start = round_down(start, BITS_PER_LONG);
+
+	while (!tmp) {
+		start += BITS_PER_LONG;
+		if (start >= nbits)
+			return nbits;
+
+		tmp = addr1[start / BITS_PER_LONG];
+		if (addr2)
+			tmp &= addr2[start / BITS_PER_LONG];
+		tmp ^= invert;
+	}
+
+	if (le)
+		tmp = swab(tmp);
+
+	return min(start + __ffs(tmp), nbits);
+}
diff --git a/arch/x86/boot/compressed/find.h b/arch/x86/boot/compressed/find.h
new file mode 100644
index 000000000000..910d007a7ec5
--- /dev/null
+++ b/arch/x86/boot/compressed/find.h
@@ -0,0 +1,80 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#ifndef BOOT_FIND_H
+#define BOOT_FIND_H
+#define __LINUX_FIND_H /* Inhibit inclusion of <linux/find.h> */
+
+#include "../bitops.h"
+#include "align.h"
+#include "bits.h"
+#include "compiler.h"
+
+unsigned long _find_next_bit(const unsigned long *addr1,
+		const unsigned long *addr2, unsigned long nbits,
+		unsigned long start, unsigned long invert, unsigned long le);
+
+/**
+ * find_next_bit - find the next set bit in a memory region
+ * @addr: The address to base the search on
+ * @offset: The bitnumber to start searching at
+ * @size: The bitmap size in bits
+ *
+ * Returns the bit number for the next set bit
+ * If no bits are set, returns @size.
+ */
+static inline
+unsigned long find_next_bit(const unsigned long *addr, unsigned long size,
+			    unsigned long offset)
+{
+	if (small_const_nbits(size)) {
+		unsigned long val;
+
+		if (unlikely(offset >= size))
+			return size;
+
+		val = *addr & GENMASK(size - 1, offset);
+		return val ? __ffs(val) : size;
+	}
+
+	return _find_next_bit(addr, NULL, size, offset, 0UL, 0);
+}
+
+/**
+ * find_next_zero_bit - find the next cleared bit in a memory region
+ * @addr: The address to base the search on
+ * @offset: The bitnumber to start searching at
+ * @size: The bitmap size in bits
+ *
+ * Returns the bit number of the next zero bit
+ * If no bits are zero, returns @size.
+ */
+static inline
+unsigned long find_next_zero_bit(const unsigned long *addr, unsigned long size,
+				 unsigned long offset)
+{
+	if (small_const_nbits(size)) {
+		unsigned long val;
+
+		if (unlikely(offset >= size))
+			return size;
+
+		val = *addr | ~GENMASK(size - 1, offset);
+		return val == ~0UL ? size : ffz(val);
+	}
+
+	return _find_next_bit(addr, NULL, size, offset, ~0UL, 0);
+}
+
+/**
+ * for_each_set_bitrange_from - iterate over all set bit ranges [b; e)
+ * @b: bit offset of start of current bitrange (first set bit); must be initialized
+ * @e: bit offset of end of current bitrange (first unset bit)
+ * @addr: bitmap address to base the search on
+ * @size: bitmap size in number of bits
+ */
+#define for_each_set_bitrange_from(b, e, addr, size)		\
+	for ((b) = find_next_bit((addr), (size), (b)),		\
+	     (e) = find_next_zero_bit((addr), (size), (b) + 1);	\
+	     (b) < (size);					\
+	     (b) = find_next_bit((addr), (size), (e) + 1),	\
+	     (e) = find_next_zero_bit((addr), (size), (b) + 1))
+#endif
diff --git a/arch/x86/boot/compressed/math.h b/arch/x86/boot/compressed/math.h
new file mode 100644
index 000000000000..b8b9fccb3c03
--- /dev/null
+++ b/arch/x86/boot/compressed/math.h
@@ -0,0 +1,37 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#ifndef BOOT_MATH_H
+#define BOOT_MATH_H
+#define __LINUX_MATH_H /* Inhibit inclusion of <linux/math.h> */
+
+/*
+ *
+ * This looks more complex than it should be. But we need to
+ * get the type for the ~ right in round_down (it needs to be
+ * as wide as the result!), and we want to evaluate the macro
+ * arguments just once each.
+ */
+#define __round_mask(x, y) ((__typeof__(x))((y)-1))
+
+/**
+ * round_up - round up to next specified power of 2
+ * @x: the value to round
+ * @y: multiple to round up to (must be a power of 2)
+ *
+ * Rounds @x up to next multiple of @y (which must be a power of 2).
+ * To perform arbitrary rounding up, use roundup() below.
+ */
+#define round_up(x, y) ((((x)-1) | __round_mask(x, y))+1)
+
+/**
+ * round_down - round down to next specified power of 2
+ * @x: the value to round
+ * @y: multiple to round down to (must be a power of 2)
+ *
+ * Rounds @x down to next multiple of @y (which must be a power of 2).
+ * To perform arbitrary rounding down, use rounddown() below.
+ */
+#define round_down(x, y) ((x) & ~__round_mask(x, y))
+
+#define DIV_ROUND_UP(n, d) (((n) + (d) - 1) / (d))
+
+#endif
diff --git a/arch/x86/boot/compressed/minmax.h b/arch/x86/boot/compressed/minmax.h
new file mode 100644
index 000000000000..fbf640cfce32
--- /dev/null
+++ b/arch/x86/boot/compressed/minmax.h
@@ -0,0 +1,61 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#ifndef BOOT_MINMAX_H
+#define BOOT_MINMAX_H
+#define __LINUX_MINMAX_H /* Inhibit inclusion of <linux/minmax.h> */
+
+/*
+ * This returns a constant expression while determining if an argument is
+ * a constant expression, most importantly without evaluating the argument.
+ * Glory to Martin Uecker <Martin.Uecker@med.uni-goettingen.de>
+ */
+#define __is_constexpr(x) \
+	(sizeof(int) == sizeof(*(8 ? ((void *)((long)(x) * 0l)) : (int *)8)))
+
+/*
+ * min()/max()/clamp() macros must accomplish three things:
+ *
+ * - avoid multiple evaluations of the arguments (so side-effects like
+ *   "x++" happen only once) when non-constant.
+ * - perform strict type-checking (to generate warnings instead of
+ *   nasty runtime surprises). See the "unnecessary" pointer comparison
+ *   in __typecheck().
+ * - retain result as a constant expressions when called with only
+ *   constant expressions (to avoid tripping VLA warnings in stack
+ *   allocation usage).
+ */
+#define __typecheck(x, y) \
+	(!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
+
+#define __no_side_effects(x, y) \
+		(__is_constexpr(x) && __is_constexpr(y))
+
+#define __safe_cmp(x, y) \
+		(__typecheck(x, y) && __no_side_effects(x, y))
+
+#define __cmp(x, y, op)	((x) op (y) ? (x) : (y))
+
+#define __cmp_once(x, y, unique_x, unique_y, op) ({	\
+		typeof(x) unique_x = (x);		\
+		typeof(y) unique_y = (y);		\
+		__cmp(unique_x, unique_y, op); })
+
+#define __careful_cmp(x, y, op) \
+	__builtin_choose_expr(__safe_cmp(x, y), \
+		__cmp(x, y, op), \
+		__cmp_once(x, y, __UNIQUE_ID(__x), __UNIQUE_ID(__y), op))
+
+/**
+ * min - return minimum of two values of the same or compatible types
+ * @x: first value
+ * @y: second value
+ */
+#define min(x, y)	__careful_cmp(x, y, <)
+
+/**
+ * max - return maximum of two values of the same or compatible types
+ * @x: first value
+ * @y: second value
+ */
+#define max(x, y)	__careful_cmp(x, y, >)
+
+#endif
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 58+ messages in thread

* [PATCHv5 05/12] efi/x86: Implement support for unaccepted memory
  2022-04-25  3:39 [PATCHv5 00/12] mm, x86/cc: Implement support for unaccepted memory Kirill A. Shutemov
                   ` (3 preceding siblings ...)
  2022-04-25  3:39 ` [PATCHv5 04/12] x86/boot: Add infrastructure required for unaccepted memory support Kirill A. Shutemov
@ 2022-04-25  3:39 ` Kirill A. Shutemov
  2022-04-29 10:53   ` Borislav Petkov
  2022-04-25  3:39 ` [PATCHv5 06/12] x86/boot/compressed: Handle " Kirill A. Shutemov
                   ` (6 subsequent siblings)
  11 siblings, 1 reply; 58+ messages in thread
From: Kirill A. Shutemov @ 2022-04-25  3:39 UTC (permalink / raw)
  To: 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,
	Dave Hansen, Brijesh Singh, Mike Rapoport, David Hildenbrand,
	x86, linux-mm, linux-coco, linux-efi, linux-kernel,
	Kirill A. Shutemov

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.

The kernel needs to know what memory has been accepted. Firmware
communicates this information via memory map: a new memory type --
EFI_UNACCEPTED_MEMORY -- indicates such memory.

Range-based tracking works fine for firmware, but it gets bulky for
the kernel: e820 has to be modified on every page acceptance. It leads
to table fragmentation, but there's a limited number of entries in the
e820 table

Another option is to mark such memory as usable in e820 and track if the
range has been accepted in a bitmap. One bit in the bitmap represents
2MiB in the address space: one 4k page is enough to track 64GiB or
physical address space.

In the worst-case scenario -- a huge hole in the middle of the
address space -- It needs 256MiB to handle 4PiB of the address
space.

Any unaccepted memory that is not aligned to 2M gets accepted upfront.

The bitmap is allocated and constructed in the EFI stub and passed down
to the kernel via boot_params. allocate_e820() allocates the bitmap if
unaccepted memory is present, according to the maximum address in the
memory map.

The same boot_params.unaccepted_memory can be used to pass the bitmap
between two kernels on kexec, but the use-case is not yet implemented.
Make KEXEC and UNACCEPTED_MEMORY mutually exclusive for now.

The implementation requires some basic helpers in boot stub. They
provided by linux/ includes in the main kernel image, but is not present
in boot stub. Create copy of required functionality in the boot stub.

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
 Documentation/x86/zero-page.rst          |  1 +
 arch/x86/boot/compressed/Makefile        |  1 +
 arch/x86/boot/compressed/mem.c           | 68 +++++++++++++++++++++++
 arch/x86/include/asm/unaccepted_memory.h | 10 ++++
 arch/x86/include/uapi/asm/bootparam.h    |  2 +-
 drivers/firmware/efi/Kconfig             | 15 ++++++
 drivers/firmware/efi/efi.c               |  1 +
 drivers/firmware/efi/libstub/x86-stub.c  | 69 ++++++++++++++++++++++++
 include/linux/efi.h                      |  3 +-
 9 files changed, 168 insertions(+), 2 deletions(-)
 create mode 100644 arch/x86/boot/compressed/mem.c
 create mode 100644 arch/x86/include/asm/unaccepted_memory.h

diff --git a/Documentation/x86/zero-page.rst b/Documentation/x86/zero-page.rst
index f088f5881666..bb8e9cb093cc 100644
--- a/Documentation/x86/zero-page.rst
+++ b/Documentation/x86/zero-page.rst
@@ -19,6 +19,7 @@ Offset/Size	Proto	Name			Meaning
 058/008		ALL	tboot_addr      	Physical address of tboot shared page
 060/010		ALL	ist_info		Intel SpeedStep (IST) BIOS support information
 						(struct ist_info)
+078/008		ALL	unaccepted_memory	Bitmap of unaccepted memory (1bit == 2M)
 080/010		ALL	hd0_info		hd0 disk parameter, OBSOLETE!!
 090/010		ALL	hd1_info		hd1 disk parameter, OBSOLETE!!
 0A0/010		ALL	sys_desc_table		System description table (struct sys_desc_table),
diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
index 8fd0e6ae2e1f..7f672f7e2fea 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -102,6 +102,7 @@ endif
 
 vmlinux-objs-$(CONFIG_ACPI) += $(obj)/acpi.o
 vmlinux-objs-$(CONFIG_INTEL_TDX_GUEST) += $(obj)/tdx.o $(obj)/tdcall.o
+vmlinux-objs-$(CONFIG_UNACCEPTED_MEMORY) += $(obj)/bitmap.o $(obj)/mem.o
 
 vmlinux-objs-$(CONFIG_EFI_MIXED) += $(obj)/efi_thunk_$(BITS).o
 efi-obj-$(CONFIG_EFI_STUB) = $(objtree)/drivers/firmware/efi/libstub/lib.a
diff --git a/arch/x86/boot/compressed/mem.c b/arch/x86/boot/compressed/mem.c
new file mode 100644
index 000000000000..415df0d3bc81
--- /dev/null
+++ b/arch/x86/boot/compressed/mem.c
@@ -0,0 +1,68 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include "../cpuflags.h"
+#include "bitmap.h"
+#include "error.h"
+#include "math.h"
+
+#define PMD_SHIFT	21
+#define PMD_SIZE	(_AC(1, UL) << PMD_SHIFT)
+#define PMD_MASK	(~(PMD_SIZE - 1))
+
+static inline void __accept_memory(phys_addr_t start, phys_addr_t end)
+{
+	/* Platform-specific memory-acceptance call goes here */
+	error("Cannot accept memory");
+}
+
+/*
+ * The accepted memory bitmap only works at PMD_SIZE granularity. If a request
+ * comes in to mark memory as unaccepted which is not PMD_SIZE-aligned, simply
+ * accept the memory now since it can not be *marked* as unaccepted.
+ */
+void process_unaccepted_memory(struct boot_params *params, u64 start, u64 end)
+{
+	/*
+	 * Accept small regions that might not be able to be represented
+	 * in the bitmap.  This is a bit imprecise and may accept some
+	 * areas that could have been represented in the bitmap instead.
+	 *
+	 * Consider case like this:
+	 *
+	 * | 4k | 2044k |    2048k   |
+	 * ^ 0x0        ^ 2MB        ^ 4MB
+	 *
+	 * all memory in the range is unaccepted, except for the first 4k.
+	 * The second 2M can be represented in the bitmap, but kernel accept it
+	 * right away. The imprecision makes the code simpler by ensuring that
+	 * at least one bit will be set int the bitmap below.
+	 */
+	if (end - start < 2 * PMD_SIZE) {
+		__accept_memory(start, end);
+		return;
+	}
+
+	/*
+	 * No matter how the start and end are aligned, at least one unaccepted
+	 * PMD_SIZE area will remain.
+	 */
+
+	/* Immediately accept a <PMD_SIZE piece at the start: */
+	if (start & ~PMD_MASK) {
+		__accept_memory(start, round_up(start, PMD_SIZE));
+		start = round_up(start, PMD_SIZE);
+	}
+
+	/* Immediately accept a <PMD_SIZE piece at the end: */
+	if (end & ~PMD_MASK) {
+		__accept_memory(round_down(end, PMD_SIZE), end);
+		end = round_down(end, PMD_SIZE);
+	}
+
+	/*
+	 * 'start' and 'end' are now both PMD-aligned.
+	 * Record the range as being unaccepted:
+	 */
+	bitmap_set((unsigned long *)params->unaccepted_memory,
+		   start / PMD_SIZE, (end - start) / PMD_SIZE);
+}
diff --git a/arch/x86/include/asm/unaccepted_memory.h b/arch/x86/include/asm/unaccepted_memory.h
new file mode 100644
index 000000000000..df0736d32858
--- /dev/null
+++ b/arch/x86/include/asm/unaccepted_memory.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (C) 2020 Intel Corporation */
+#ifndef _ASM_X86_UNACCEPTED_MEMORY_H
+#define _ASM_X86_UNACCEPTED_MEMORY_H
+
+struct boot_params;
+
+void process_unaccepted_memory(struct boot_params *params, u64 start, u64 num);
+
+#endif
diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h
index b25d3f82c2f3..f7a32176f301 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@ -179,7 +179,7 @@ struct boot_params {
 	__u64  tboot_addr;				/* 0x058 */
 	struct ist_info ist_info;			/* 0x060 */
 	__u64 acpi_rsdp_addr;				/* 0x070 */
-	__u8  _pad3[8];					/* 0x078 */
+	__u64 unaccepted_memory;			/* 0x078 */
 	__u8  hd0_info[16];	/* obsolete! */		/* 0x080 */
 	__u8  hd1_info[16];	/* obsolete! */		/* 0x090 */
 	struct sys_desc_table sys_desc_table; /* obsolete! */	/* 0x0a0 */
diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
index 2c3dac5ecb36..e8048586aefa 100644
--- a/drivers/firmware/efi/Kconfig
+++ b/drivers/firmware/efi/Kconfig
@@ -243,6 +243,21 @@ config EFI_DISABLE_PCI_DMA
 	  options "efi=disable_early_pci_dma" or "efi=no_disable_early_pci_dma"
 	  may be used to override this option.
 
+config UNACCEPTED_MEMORY
+	bool
+	depends on EFI_STUB
+	depends on !KEXEC_CORE
+	help
+	   Some Virtual Machine platforms, such as Intel TDX, require
+	   some memory to be "accepted" by the guest before it can be used.
+	   This mechanism helps prevent malicious hosts from making changes
+	   to guest memory.
+
+	   UEFI specification v2.9 introduced EFI_UNACCEPTED_MEMORY memory type.
+
+	   This option adds support for unaccepted memory and makes such memory
+	   usable by the kernel.
+
 endmenu
 
 config EFI_EMBEDDED_FIRMWARE
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 5502e176d51b..2c055afb1b11 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -747,6 +747,7 @@ static __initdata char memory_type_name[][13] = {
 	"MMIO Port",
 	"PAL Code",
 	"Persistent",
+	"Unaccepted",
 };
 
 char * __init efi_md_typeattr_format(char *buf, size_t size,
diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c
index 5401985901f5..f9b88174209e 100644
--- a/drivers/firmware/efi/libstub/x86-stub.c
+++ b/drivers/firmware/efi/libstub/x86-stub.c
@@ -15,6 +15,7 @@
 #include <asm/setup.h>
 #include <asm/desc.h>
 #include <asm/boot.h>
+#include <asm/unaccepted_memory.h>
 
 #include "efistub.h"
 
@@ -504,6 +505,17 @@ setup_e820(struct boot_params *params, struct setup_data *e820ext, u32 e820ext_s
 			e820_type = E820_TYPE_PMEM;
 			break;
 
+		case EFI_UNACCEPTED_MEMORY:
+			if (!IS_ENABLED(CONFIG_UNACCEPTED_MEMORY)) {
+				efi_warn_once("The system has unaccepted memory,"
+					     " but kernel does not support it\n");
+				efi_warn_once("Consider enabling UNACCEPTED_MEMORY\n");
+				continue;
+			}
+			e820_type = E820_TYPE_RAM;
+			process_unaccepted_memory(params, d->phys_addr,
+					d->phys_addr + PAGE_SIZE * d->num_pages);
+			break;
 		default:
 			continue;
 		}
@@ -568,6 +580,59 @@ static efi_status_t alloc_e820ext(u32 nr_desc, struct setup_data **e820ext,
 	return status;
 }
 
+static efi_status_t allocate_unaccepted_memory(struct boot_params *params,
+					       __u32 nr_desc,
+					       struct efi_boot_memmap *map)
+{
+	unsigned long *mem = NULL;
+	u64 size, max_addr = 0;
+	efi_status_t status;
+	bool found = false;
+	int i;
+
+	/* Check if there's any unaccepted memory and find the max address */
+	for (i = 0; i < nr_desc; i++) {
+		efi_memory_desc_t *d;
+
+		d = efi_early_memdesc_ptr(*map->map, *map->desc_size, i);
+		if (d->type == EFI_UNACCEPTED_MEMORY)
+			found = true;
+		if (d->phys_addr + d->num_pages * PAGE_SIZE > max_addr)
+			max_addr = d->phys_addr + d->num_pages * PAGE_SIZE;
+	}
+
+	if (!found) {
+		params->unaccepted_memory = 0;
+		return EFI_SUCCESS;
+	}
+
+	/*
+	 * If unaccepted memory is present allocate a bitmap to track what
+	 * memory has to be accepted before access.
+	 *
+	 * One bit in the bitmap represents 2MiB in the address space:
+	 * A 4k bitmap can track 64GiB of physical address space.
+	 *
+	 * In the worst case scenario -- a huge hole in the middle of the
+	 * address space -- It needs 256MiB to handle 4PiB of the address
+	 * space.
+	 *
+	 * TODO: handle situation if params->unaccepted_memory has already set.
+	 * It's required to deal with kexec.
+	 *
+	 * The bitmap will be populated in setup_e820() according to the memory
+	 * map after efi_exit_boot_services().
+	 */
+	size = DIV_ROUND_UP(max_addr, PMD_SIZE * BITS_PER_BYTE);
+	status = efi_allocate_pages(size, (unsigned long *)&mem, ULONG_MAX);
+	if (status == EFI_SUCCESS) {
+		memset(mem, 0, size);
+		params->unaccepted_memory = (unsigned long)mem;
+	}
+
+	return status;
+}
+
 static efi_status_t allocate_e820(struct boot_params *params,
 				  struct efi_boot_memmap *map,
 				  struct setup_data **e820ext,
@@ -589,6 +654,10 @@ static efi_status_t allocate_e820(struct boot_params *params,
 		if (status != EFI_SUCCESS)
 			goto out;
 	}
+
+	if (IS_ENABLED(CONFIG_UNACCEPTED_MEMORY))
+		status = allocate_unaccepted_memory(params, nr_desc, map);
+
 out:
 	efi_bs_call(free_pool, *map->map);
 	return status;
diff --git a/include/linux/efi.h b/include/linux/efi.h
index ccd4d3f91c98..b0240fdcaf5b 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -108,7 +108,8 @@ typedef	struct {
 #define EFI_MEMORY_MAPPED_IO_PORT_SPACE	12
 #define EFI_PAL_CODE			13
 #define EFI_PERSISTENT_MEMORY		14
-#define EFI_MAX_MEMORY_TYPE		15
+#define EFI_UNACCEPTED_MEMORY		15
+#define EFI_MAX_MEMORY_TYPE		16
 
 /* Attribute values: */
 #define EFI_MEMORY_UC		((u64)0x0000000000000001ULL)	/* uncached */
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 58+ messages in thread

* [PATCHv5 06/12] x86/boot/compressed: Handle unaccepted memory
  2022-04-25  3:39 [PATCHv5 00/12] mm, x86/cc: Implement support for unaccepted memory Kirill A. Shutemov
                   ` (4 preceding siblings ...)
  2022-04-25  3:39 ` [PATCHv5 05/12] efi/x86: Implement support for unaccepted memory Kirill A. Shutemov
@ 2022-04-25  3:39 ` Kirill A. Shutemov
  2022-04-27  0:17   ` Michael Roth
                     ` (2 more replies)
  2022-04-25  3:39 ` [PATCHv5 07/12] x86/mm: Reserve unaccepted memory bitmap Kirill A. Shutemov
                   ` (5 subsequent siblings)
  11 siblings, 3 replies; 58+ messages in thread
From: Kirill A. Shutemov @ 2022-04-25  3:39 UTC (permalink / raw)
  To: 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,
	Dave Hansen, Brijesh Singh, Mike Rapoport, David Hildenbrand,
	x86, linux-mm, linux-coco, linux-efi, linux-kernel,
	Kirill A. Shutemov

The firmware will pre-accept the memory used to run the stub. But, the
stub is responsible for accepting the memory into which it decompresses
the main kernel. Accept memory just before decompression starts.

The stub is also responsible for choosing a physical address in which to
place the decompressed kernel image. The KASLR mechanism will randomize
this physical address. Since the unaccepted memory region is relatively
small, KASLR would be quite ineffective if it only used the pre-accepted
area (EFI_CONVENTIONAL_MEMORY). Ensure that KASLR randomizes among the
entire physical address space by also including EFI_UNACCEPTED_MEMOR

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
 arch/x86/boot/compressed/Makefile        |  2 +-
 arch/x86/boot/compressed/kaslr.c         | 14 ++++++++++++--
 arch/x86/boot/compressed/mem.c           | 21 +++++++++++++++++++++
 arch/x86/boot/compressed/misc.c          |  9 +++++++++
 arch/x86/include/asm/unaccepted_memory.h |  2 ++
 5 files changed, 45 insertions(+), 3 deletions(-)

diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
index 7f672f7e2fea..b59007e57cbf 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -102,7 +102,7 @@ endif
 
 vmlinux-objs-$(CONFIG_ACPI) += $(obj)/acpi.o
 vmlinux-objs-$(CONFIG_INTEL_TDX_GUEST) += $(obj)/tdx.o $(obj)/tdcall.o
-vmlinux-objs-$(CONFIG_UNACCEPTED_MEMORY) += $(obj)/bitmap.o $(obj)/mem.o
+vmlinux-objs-$(CONFIG_UNACCEPTED_MEMORY) += $(obj)/bitmap.o $(obj)/find.o $(obj)/mem.o
 
 vmlinux-objs-$(CONFIG_EFI_MIXED) += $(obj)/efi_thunk_$(BITS).o
 efi-obj-$(CONFIG_EFI_STUB) = $(objtree)/drivers/firmware/efi/libstub/lib.a
diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 411b268bc0a2..59db90626042 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -725,10 +725,20 @@ process_efi_entries(unsigned long minimum, unsigned long image_size)
 		 * but in practice there's firmware where using that memory leads
 		 * to crashes.
 		 *
-		 * Only EFI_CONVENTIONAL_MEMORY is guaranteed to be free.
+		 * Only EFI_CONVENTIONAL_MEMORY and EFI_UNACCEPTED_MEMORY (if
+		 * supported) are guaranteed to be free.
 		 */
-		if (md->type != EFI_CONVENTIONAL_MEMORY)
+
+		switch (md->type) {
+		case EFI_CONVENTIONAL_MEMORY:
+			break;
+		case EFI_UNACCEPTED_MEMORY:
+			if (IS_ENABLED(CONFIG_UNACCEPTED_MEMORY))
+				break;
 			continue;
+		default:
+			continue;
+		}
 
 		if (efi_soft_reserve_enabled() &&
 		    (md->attribute & EFI_MEMORY_SP))
diff --git a/arch/x86/boot/compressed/mem.c b/arch/x86/boot/compressed/mem.c
index 415df0d3bc81..b5058c975d26 100644
--- a/arch/x86/boot/compressed/mem.c
+++ b/arch/x86/boot/compressed/mem.c
@@ -3,12 +3,15 @@
 #include "../cpuflags.h"
 #include "bitmap.h"
 #include "error.h"
+#include "find.h"
 #include "math.h"
 
 #define PMD_SHIFT	21
 #define PMD_SIZE	(_AC(1, UL) << PMD_SHIFT)
 #define PMD_MASK	(~(PMD_SIZE - 1))
 
+extern struct boot_params *boot_params;
+
 static inline void __accept_memory(phys_addr_t start, phys_addr_t end)
 {
 	/* Platform-specific memory-acceptance call goes here */
@@ -66,3 +69,21 @@ void process_unaccepted_memory(struct boot_params *params, u64 start, u64 end)
 	bitmap_set((unsigned long *)params->unaccepted_memory,
 		   start / PMD_SIZE, (end - start) / PMD_SIZE);
 }
+
+void accept_memory(phys_addr_t start, phys_addr_t end)
+{
+	unsigned long range_start, range_end;
+	unsigned long *unaccepted_memory;
+	unsigned long bitmap_size;
+
+	unaccepted_memory = (unsigned long *)boot_params->unaccepted_memory;
+	range_start = start / PMD_SIZE;
+	bitmap_size = DIV_ROUND_UP(end, PMD_SIZE);
+
+	for_each_set_bitrange_from(range_start, range_end,
+				   unaccepted_memory, bitmap_size) {
+		__accept_memory(range_start * PMD_SIZE, range_end * PMD_SIZE);
+		bitmap_clear(unaccepted_memory,
+			     range_start, range_end - range_start);
+	}
+}
diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
index fa8969fad011..285b37e28074 100644
--- a/arch/x86/boot/compressed/misc.c
+++ b/arch/x86/boot/compressed/misc.c
@@ -18,6 +18,7 @@
 #include "../string.h"
 #include "../voffset.h"
 #include <asm/bootparam_utils.h>
+#include <asm/unaccepted_memory.h>
 
 /*
  * WARNING!!
@@ -451,6 +452,14 @@ asmlinkage __visible void *extract_kernel(void *rmode, memptr heap,
 #endif
 
 	debug_putstr("\nDecompressing Linux... ");
+
+#ifdef CONFIG_UNACCEPTED_MEMORY
+	if (boot_params->unaccepted_memory) {
+		debug_putstr("Accepting memory... ");
+		accept_memory(__pa(output), __pa(output) + needed_size);
+	}
+#endif
+
 	__decompress(input_data, input_len, NULL, NULL, output, output_len,
 			NULL, error);
 	parse_elf(output);
diff --git a/arch/x86/include/asm/unaccepted_memory.h b/arch/x86/include/asm/unaccepted_memory.h
index df0736d32858..41fbfc798100 100644
--- a/arch/x86/include/asm/unaccepted_memory.h
+++ b/arch/x86/include/asm/unaccepted_memory.h
@@ -7,4 +7,6 @@ struct boot_params;
 
 void process_unaccepted_memory(struct boot_params *params, u64 start, u64 num);
 
+void accept_memory(phys_addr_t start, phys_addr_t end);
+
 #endif
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 58+ messages in thread

* [PATCHv5 07/12] x86/mm: Reserve unaccepted memory bitmap
  2022-04-25  3:39 [PATCHv5 00/12] mm, x86/cc: Implement support for unaccepted memory Kirill A. Shutemov
                   ` (5 preceding siblings ...)
  2022-04-25  3:39 ` [PATCHv5 06/12] x86/boot/compressed: Handle " Kirill A. Shutemov
@ 2022-04-25  3:39 ` Kirill A. Shutemov
  2022-04-29 13:19   ` Wander Lairson Costa
  2022-05-04 11:04   ` Borislav Petkov
  2022-04-25  3:39 ` [PATCHv5 08/12] x86/mm: Provide helpers for unaccepted memory Kirill A. Shutemov
                   ` (4 subsequent siblings)
  11 siblings, 2 replies; 58+ messages in thread
From: Kirill A. Shutemov @ 2022-04-25  3:39 UTC (permalink / raw)
  To: 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,
	Dave Hansen, Brijesh Singh, Mike Rapoport, David Hildenbrand,
	x86, linux-mm, linux-coco, linux-efi, linux-kernel,
	Kirill A. Shutemov, Mike Rapoport

A given page of memory can only be accepted once. The kernel has a need
to accept memory both in the early decompression stage and during normal
runtime.

A bitmap used to communicate the acceptance state of each page between the
decompression stage and normal runtime.

boot_params is used to communicate location of the bitmap through out
the boot. The bitmap is allocated and initially populated in EFI stub.
Decompression stage accepts pages required for kernel/initrd and mark
these pages accordingly in the bitmap. The main kernel picks up the
bitmap from the same boot_params and uses it to determinate what has to
be accepted on allocation.

In the runtime kernel, reserve the bitmap's memory to ensure nothing
overwrites it.

The size of bitmap is determinated with e820__end_of_ram_pfn() which
relies on setup_e820() marking unaccepted memory as E820_TYPE_RAM.

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Acked-by: Mike Rapoport <rppt@linux.ibm.com>
---
 arch/x86/kernel/e820.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index f267205f2d5a..22d1fe48dcba 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -1316,6 +1316,16 @@ void __init e820__memblock_setup(void)
 	int i;
 	u64 end;
 
+	/* Mark unaccepted memory bitmap reserved */
+	if (boot_params.unaccepted_memory) {
+		unsigned long size;
+
+		/* One bit per 2MB */
+		size = DIV_ROUND_UP(e820__end_of_ram_pfn() * PAGE_SIZE,
+				    PMD_SIZE * BITS_PER_BYTE);
+		memblock_reserve(boot_params.unaccepted_memory, size);
+	}
+
 	/*
 	 * The bootstrap memblock region count maximum is 128 entries
 	 * (INIT_MEMBLOCK_REGIONS), but EFI might pass us more E820 entries
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 58+ messages in thread

* [PATCHv5 08/12] x86/mm: Provide helpers for unaccepted memory
  2022-04-25  3:39 [PATCHv5 00/12] mm, x86/cc: Implement support for unaccepted memory Kirill A. Shutemov
                   ` (6 preceding siblings ...)
  2022-04-25  3:39 ` [PATCHv5 07/12] x86/mm: Reserve unaccepted memory bitmap Kirill A. Shutemov
@ 2022-04-25  3:39 ` Kirill A. Shutemov
  2022-05-04 11:12   ` Borislav Petkov
  2022-04-25  3:39 ` [PATCHv5 09/12] x86/tdx: Make _tdx_hypercall() and __tdx_module_call() available in boot stub Kirill A. Shutemov
                   ` (3 subsequent siblings)
  11 siblings, 1 reply; 58+ messages in thread
From: Kirill A. Shutemov @ 2022-04-25  3:39 UTC (permalink / raw)
  To: 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,
	Dave Hansen, Brijesh Singh, Mike Rapoport, David Hildenbrand,
	x86, linux-mm, linux-coco, linux-efi, linux-kernel,
	Kirill A. Shutemov

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 <kirill.shutemov@linux.intel.com>
---
 arch/x86/include/asm/page.h              |  3 ++
 arch/x86/include/asm/unaccepted_memory.h |  4 ++
 arch/x86/mm/Makefile                     |  2 +
 arch/x86/mm/unaccepted_memory.c          | 56 ++++++++++++++++++++++++
 4 files changed, 65 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..df4ec3a988dc 100644
--- a/arch/x86/include/asm/page.h
+++ b/arch/x86/include/asm/page.h
@@ -19,6 +19,9 @@
 struct page;
 
 #include <linux/range.h>
+
+#include <asm/unaccepted_memory.h>
+
 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 41fbfc798100..a59264ee0ab3 100644
--- a/arch/x86/include/asm/unaccepted_memory.h
+++ b/arch/x86/include/asm/unaccepted_memory.h
@@ -7,6 +7,10 @@ struct boot_params;
 
 void process_unaccepted_memory(struct boot_params *params, u64 start, u64 num);
 
+#ifdef CONFIG_UNACCEPTED_MEMORY
+
 void accept_memory(phys_addr_t start, phys_addr_t end);
+bool memory_is_unaccepted(phys_addr_t start, phys_addr_t end);
 
 #endif
+#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..1327f64d5205
--- /dev/null
+++ b/arch/x86/mm/unaccepted_memory.c
@@ -0,0 +1,56 @@
+// SPDX-License-Identifier: GPL-2.0-only
+#include <linux/memblock.h>
+#include <linux/mm.h>
+#include <linux/pfn.h>
+#include <linux/spinlock.h>
+
+#include <asm/io.h>
+#include <asm/setup.h>
+#include <asm/unaccepted_memory.h>
+
+/* Protects unaccepted memory bitmap */
+static DEFINE_SPINLOCK(unaccepted_memory_lock);
+
+void accept_memory(phys_addr_t start, phys_addr_t end)
+{
+	unsigned long *unaccepted_memory;
+	unsigned long flags;
+	unsigned long range_start, range_end;
+
+	if (!boot_params.unaccepted_memory)
+		return;
+
+	unaccepted_memory = __va(boot_params.unaccepted_memory);
+	range_start = start / PMD_SIZE;
+
+	spin_lock_irqsave(&unaccepted_memory_lock, flags);
+	for_each_set_bitrange_from(range_start, range_end, unaccepted_memory,
+				   DIV_ROUND_UP(end, PMD_SIZE)) {
+		unsigned long len = range_end - range_start;
+
+		/* Platform-specific memory-acceptance call goes here */
+		panic("Cannot accept memory");
+		bitmap_clear(unaccepted_memory, range_start, len);
+	}
+	spin_unlock_irqrestore(&unaccepted_memory_lock, flags);
+}
+
+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;
+}
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 58+ messages in thread

* [PATCHv5 09/12] x86/tdx: Make _tdx_hypercall() and __tdx_module_call() available in boot stub
  2022-04-25  3:39 [PATCHv5 00/12] mm, x86/cc: Implement support for unaccepted memory Kirill A. Shutemov
                   ` (7 preceding siblings ...)
  2022-04-25  3:39 ` [PATCHv5 08/12] x86/mm: Provide helpers for unaccepted memory Kirill A. Shutemov
@ 2022-04-25  3:39 ` Kirill A. Shutemov
  2022-04-25  3:39 ` [PATCHv5 10/12] x86/tdx: Unaccepted memory support Kirill A. Shutemov
                   ` (2 subsequent siblings)
  11 siblings, 0 replies; 58+ messages in thread
From: Kirill A. Shutemov @ 2022-04-25  3:39 UTC (permalink / raw)
  To: 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,
	Dave Hansen, Brijesh Singh, Mike Rapoport, David Hildenbrand,
	x86, linux-mm, linux-coco, linux-efi, linux-kernel,
	Kirill A. Shutemov

Memory acceptance requires a hypercall and one or multiple module calls.

Make helpers for the calls available in boot stub. It has to accept
memory where kernel image and initrd are placed.

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
 arch/x86/coco/tdx/tdx.c           | 26 ------------------
 arch/x86/include/asm/shared/tdx.h | 45 +++++++++++++++++++++++++++++++
 arch/x86/include/asm/tdx.h        | 19 -------------
 3 files changed, 45 insertions(+), 45 deletions(-)

diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c
index 03deb4d6920d..ddb60a87b426 100644
--- a/arch/x86/coco/tdx/tdx.c
+++ b/arch/x86/coco/tdx/tdx.c
@@ -12,14 +12,6 @@
 #include <asm/insn-eval.h>
 #include <asm/pgtable.h>
 
-/* TDX module Call Leaf IDs */
-#define TDX_GET_INFO			1
-#define TDX_GET_VEINFO			3
-#define TDX_ACCEPT_PAGE			6
-
-/* TDX hypercall Leaf IDs */
-#define TDVMCALL_MAP_GPA		0x10001
-
 /* MMIO direction */
 #define EPT_READ	0
 #define EPT_WRITE	1
@@ -34,24 +26,6 @@
 #define VE_GET_PORT_NUM(e)	((e) >> 16)
 #define VE_IS_IO_STRING(e)	((e) & BIT(4))
 
-/*
- * Wrapper for standard use of __tdx_hypercall with no output aside from
- * return code.
- */
-static inline u64 _tdx_hypercall(u64 fn, u64 r12, u64 r13, u64 r14, u64 r15)
-{
-	struct tdx_hypercall_args args = {
-		.r10 = TDX_HYPERCALL_STANDARD,
-		.r11 = fn,
-		.r12 = r12,
-		.r13 = r13,
-		.r14 = r14,
-		.r15 = r15,
-	};
-
-	return __tdx_hypercall(&args, 0);
-}
-
 /* Called from __tdx_hypercall() for unrecoverable failure */
 void __tdx_hypercall_failed(void)
 {
diff --git a/arch/x86/include/asm/shared/tdx.h b/arch/x86/include/asm/shared/tdx.h
index e53f26228fbb..956ced04c3be 100644
--- a/arch/x86/include/asm/shared/tdx.h
+++ b/arch/x86/include/asm/shared/tdx.h
@@ -13,6 +13,14 @@
 #define TDX_CPUID_LEAF_ID	0x21
 #define TDX_IDENT		"IntelTDX    "
 
+/* TDX module Call Leaf IDs */
+#define TDX_GET_INFO			1
+#define TDX_GET_VEINFO			3
+#define TDX_ACCEPT_PAGE			6
+
+/* TDX hypercall Leaf IDs */
+#define TDVMCALL_MAP_GPA		0x10001
+
 #ifndef __ASSEMBLY__
 
 /*
@@ -33,8 +41,45 @@ struct tdx_hypercall_args {
 /* Used to request services from the VMM */
 u64 __tdx_hypercall(struct tdx_hypercall_args *args, unsigned long flags);
 
+/*
+ * Wrapper for standard use of __tdx_hypercall with no output aside from
+ * return code.
+ */
+static inline u64 _tdx_hypercall(u64 fn, u64 r12, u64 r13, u64 r14, u64 r15)
+{
+	struct tdx_hypercall_args args = {
+		.r10 = TDX_HYPERCALL_STANDARD,
+		.r11 = fn,
+		.r12 = r12,
+		.r13 = r13,
+		.r14 = r14,
+		.r15 = r15,
+	};
+
+	return __tdx_hypercall(&args, 0);
+}
+
+
 /* Called from __tdx_hypercall() for unrecoverable failure */
 void __tdx_hypercall_failed(void);
 
+/*
+ * Used in __tdx_module_call() to gather the output registers' values of the
+ * TDCALL instruction when requesting services from the TDX module. This is a
+ * software only structure and not part of the TDX module/VMM ABI
+ */
+struct tdx_module_output {
+	u64 rcx;
+	u64 rdx;
+	u64 r8;
+	u64 r9;
+	u64 r10;
+	u64 r11;
+};
+
+/* Used to communicate with the TDX module */
+u64 __tdx_module_call(u64 fn, u64 rcx, u64 rdx, u64 r8, u64 r9,
+		      struct tdx_module_output *out);
+
 #endif /* !__ASSEMBLY__ */
 #endif /* _ASM_X86_SHARED_TDX_H */
diff --git a/arch/x86/include/asm/tdx.h b/arch/x86/include/asm/tdx.h
index 020c81a7c729..d9106d3e89f8 100644
--- a/arch/x86/include/asm/tdx.h
+++ b/arch/x86/include/asm/tdx.h
@@ -20,21 +20,6 @@
 
 #ifndef __ASSEMBLY__
 
-/*
- * Used to gather the output registers values of the TDCALL and SEAMCALL
- * instructions when requesting services from the TDX module.
- *
- * This is a software only structure and not part of the TDX module/VMM ABI.
- */
-struct tdx_module_output {
-	u64 rcx;
-	u64 rdx;
-	u64 r8;
-	u64 r9;
-	u64 r10;
-	u64 r11;
-};
-
 /*
  * Used by the #VE exception handler to gather the #VE exception
  * info from the TDX module. This is a software only structure
@@ -55,10 +40,6 @@ struct ve_info {
 
 void __init tdx_early_init(void);
 
-/* Used to communicate with the TDX module */
-u64 __tdx_module_call(u64 fn, u64 rcx, u64 rdx, u64 r8, u64 r9,
-		      struct tdx_module_output *out);
-
 void tdx_get_ve_info(struct ve_info *ve);
 
 bool tdx_handle_virt_exception(struct pt_regs *regs, struct ve_info *ve);
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 58+ messages in thread

* [PATCHv5 10/12] x86/tdx: Unaccepted memory support
  2022-04-25  3:39 [PATCHv5 00/12] mm, x86/cc: Implement support for unaccepted memory Kirill A. Shutemov
                   ` (8 preceding siblings ...)
  2022-04-25  3:39 ` [PATCHv5 09/12] x86/tdx: Make _tdx_hypercall() and __tdx_module_call() available in boot stub Kirill A. Shutemov
@ 2022-04-25  3:39 ` Kirill A. Shutemov
  2022-05-05 10:12   ` Borislav Petkov
  2022-04-25  3:39 ` [PATCHv5 11/12] mm/vmstat: Add counter for memory accepting Kirill A. Shutemov
  2022-04-25  3:39 ` [PATCHv5 12/12] x86/mm: Report unaccepted memory in /proc/meminfo Kirill A. Shutemov
  11 siblings, 1 reply; 58+ messages in thread
From: Kirill A. Shutemov @ 2022-04-25  3:39 UTC (permalink / raw)
  To: 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,
	Dave Hansen, Brijesh Singh, Mike Rapoport, David Hildenbrand,
	x86, linux-mm, linux-coco, linux-efi, linux-kernel,
	Kirill A. Shutemov

All preparations are complete. Hookup TDX-specific code to accept memory.

Accepting the memory is the same process as converting memory from
shared to private: kernel notifies VMM with MAP_GPA hypercall and then
accept pages with ACCEPT_PAGE module call.

The implementation in core kernel uses tdx_enc_status_changed(). It
already used for converting memory to shared and back for I/O
transactions.

Boot stub provides own implementation of tdx_accept_memory(). It is
similar in structure to tdx_enc_status_changed(), but only cares about
converting memory to private.

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
 arch/x86/Kconfig                  |  1 +
 arch/x86/boot/compressed/mem.c    | 24 ++++++++-
 arch/x86/boot/compressed/tdx.c    | 85 +++++++++++++++++++++++++++++++
 arch/x86/coco/tdx/tdx.c           | 31 +++++++----
 arch/x86/include/asm/shared/tdx.h |  2 +
 arch/x86/mm/unaccepted_memory.c   |  9 +++-
 6 files changed, 141 insertions(+), 11 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 7021ec725dd3..e4c31dbea6d7 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -885,6 +885,7 @@ config INTEL_TDX_GUEST
 	select ARCH_HAS_CC_PLATFORM
 	select X86_MEM_ENCRYPT
 	select X86_MCE
+	select UNACCEPTED_MEMORY
 	help
 	  Support running as a guest under Intel TDX.  Without this support,
 	  the guest kernel can not boot or run under TDX.
diff --git a/arch/x86/boot/compressed/mem.c b/arch/x86/boot/compressed/mem.c
index b5058c975d26..539fff27de49 100644
--- a/arch/x86/boot/compressed/mem.c
+++ b/arch/x86/boot/compressed/mem.c
@@ -5,6 +5,8 @@
 #include "error.h"
 #include "find.h"
 #include "math.h"
+#include "tdx.h"
+#include <asm/shared/tdx.h>
 
 #define PMD_SHIFT	21
 #define PMD_SIZE	(_AC(1, UL) << PMD_SHIFT)
@@ -12,10 +14,30 @@
 
 extern struct boot_params *boot_params;
 
+static bool is_tdx_guest(void)
+{
+	static bool once;
+	static bool is_tdx;
+
+	if (!once) {
+		u32 eax, sig[3];
+
+		cpuid_count(TDX_CPUID_LEAF_ID, 0, &eax,
+			    &sig[0], &sig[2],  &sig[1]);
+		is_tdx = !memcmp(TDX_IDENT, sig, sizeof(sig));
+		once = true;
+	}
+
+	return is_tdx;
+}
+
 static inline void __accept_memory(phys_addr_t start, phys_addr_t end)
 {
 	/* Platform-specific memory-acceptance call goes here */
-	error("Cannot accept memory");
+	if (is_tdx_guest())
+		tdx_accept_memory(start, end);
+	else
+		error("Cannot accept memory");
 }
 
 /*
diff --git a/arch/x86/boot/compressed/tdx.c b/arch/x86/boot/compressed/tdx.c
index 918a7606f53c..57fd2bf28484 100644
--- a/arch/x86/boot/compressed/tdx.c
+++ b/arch/x86/boot/compressed/tdx.c
@@ -3,12 +3,14 @@
 #include "../cpuflags.h"
 #include "../string.h"
 #include "../io.h"
+#include "align.h"
 #include "error.h"
 
 #include <vdso/limits.h>
 #include <uapi/asm/vmx.h>
 
 #include <asm/shared/tdx.h>
+#include <asm/page_types.h>
 
 /* Called from __tdx_hypercall() for unrecoverable failure */
 void __tdx_hypercall_failed(void)
@@ -75,3 +77,86 @@ void early_tdx_detect(void)
 	pio_ops.f_outb = tdx_outb;
 	pio_ops.f_outw = tdx_outw;
 }
+
+enum pg_level {
+	PG_LEVEL_4K,
+	PG_LEVEL_2M,
+	PG_LEVEL_1G,
+};
+
+#define PTE_SHIFT 9
+
+static bool try_accept_one(phys_addr_t *start, unsigned long len,
+			  enum pg_level pg_level)
+{
+	unsigned long accept_size = PAGE_SIZE << (pg_level * PTE_SHIFT);
+	u64 tdcall_rcx;
+	u8 page_size;
+
+	if (!IS_ALIGNED(*start, accept_size))
+		return false;
+
+	if (len < accept_size)
+		return false;
+
+	/*
+	 * Pass the page physical address to the TDX module to accept the
+	 * pending, private page.
+	 *
+	 * Bits 2:0 of RCX encode page size: 0 - 4K, 1 - 2M, 2 - 1G.
+	 */
+	switch (pg_level) {
+	case PG_LEVEL_4K:
+		page_size = 0;
+		break;
+	case PG_LEVEL_2M:
+		page_size = 1;
+		break;
+	case PG_LEVEL_1G:
+		page_size = 2;
+		break;
+	default:
+		return false;
+	}
+
+	tdcall_rcx = *start | page_size;
+	if (__tdx_module_call(TDX_ACCEPT_PAGE, tdcall_rcx, 0, 0, 0, NULL))
+		return false;
+
+	*start += accept_size;
+	return true;
+}
+
+void tdx_accept_memory(phys_addr_t start, phys_addr_t end)
+{
+	/*
+	 * Notify the VMM about page mapping conversion. More info about ABI
+	 * can be found in TDX Guest-Host-Communication Interface (GHCI),
+	 * section "TDG.VP.VMCALL<MapGPA>"
+	 */
+	if (_tdx_hypercall(TDVMCALL_MAP_GPA, start, end - start, 0, 0))
+		error("Accepting memory failed\n");
+
+	/*
+	 * For shared->private conversion, accept the page using
+	 * TDX_ACCEPT_PAGE TDX module call.
+	 */
+	while (start < end) {
+		unsigned long len = end - start;
+
+		/*
+		 * Try larger accepts first. It gives chance to VMM to keep
+		 * 1G/2M SEPT entries where possible and speeds up process by
+		 * cutting number of hypercalls (if successful).
+		 */
+
+		if (try_accept_one(&start, len, PG_LEVEL_1G))
+			continue;
+
+		if (try_accept_one(&start, len, PG_LEVEL_2M))
+			continue;
+
+		if (!try_accept_one(&start, len, PG_LEVEL_4K))
+			error("Accepting memory failed\n");
+	}
+}
diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c
index ddb60a87b426..ab4deb897942 100644
--- a/arch/x86/coco/tdx/tdx.c
+++ b/arch/x86/coco/tdx/tdx.c
@@ -580,16 +580,9 @@ static bool try_accept_one(phys_addr_t *start, unsigned long len,
 	return true;
 }
 
-/*
- * Inform the VMM of the guest's intent for this physical page: shared with
- * the VMM or private to the guest.  The VMM is expected to change its mapping
- * of the page in response.
- */
-static bool tdx_enc_status_changed(unsigned long vaddr, int numpages, bool enc)
+static bool tdx_enc_status_changed_phys(phys_addr_t start, phys_addr_t end,
+					bool enc)
 {
-	phys_addr_t start = __pa(vaddr);
-	phys_addr_t end   = __pa(vaddr + numpages * PAGE_SIZE);
-
 	if (!enc) {
 		/* Set the shared (decrypted) bits: */
 		start |= cc_mkdec(0);
@@ -634,6 +627,25 @@ static bool tdx_enc_status_changed(unsigned long vaddr, int numpages, bool enc)
 	return true;
 }
 
+void tdx_accept_memory(phys_addr_t start, phys_addr_t end)
+{
+	if (!tdx_enc_status_changed_phys(start, end, true))
+		panic("Accepting memory failed\n");
+}
+
+/*
+ * Inform the VMM of the guest's intent for this physical page: shared with
+ * the VMM or private to the guest.  The VMM is expected to change its mapping
+ * of the page in response.
+ */
+static bool tdx_enc_status_changed(unsigned long vaddr, int numpages, bool enc)
+{
+	phys_addr_t start = __pa(vaddr);
+	phys_addr_t end = __pa(vaddr + numpages * PAGE_SIZE);
+
+	return tdx_enc_status_changed_phys(start, end, enc);
+}
+
 void __init tdx_early_init(void)
 {
 	u64 cc_mask;
@@ -645,6 +657,7 @@ void __init tdx_early_init(void)
 		return;
 
 	setup_force_cpu_cap(X86_FEATURE_TDX_GUEST);
+	setup_clear_cpu_cap(X86_FEATURE_MCE);
 
 	cc_set_vendor(CC_VENDOR_INTEL);
 	cc_mask = get_cc_mask();
diff --git a/arch/x86/include/asm/shared/tdx.h b/arch/x86/include/asm/shared/tdx.h
index 956ced04c3be..97534c334473 100644
--- a/arch/x86/include/asm/shared/tdx.h
+++ b/arch/x86/include/asm/shared/tdx.h
@@ -81,5 +81,7 @@ struct tdx_module_output {
 u64 __tdx_module_call(u64 fn, u64 rcx, u64 rdx, u64 r8, u64 r9,
 		      struct tdx_module_output *out);
 
+void tdx_accept_memory(phys_addr_t start, phys_addr_t end);
+
 #endif /* !__ASSEMBLY__ */
 #endif /* _ASM_X86_SHARED_TDX_H */
diff --git a/arch/x86/mm/unaccepted_memory.c b/arch/x86/mm/unaccepted_memory.c
index 1327f64d5205..de0790af1824 100644
--- a/arch/x86/mm/unaccepted_memory.c
+++ b/arch/x86/mm/unaccepted_memory.c
@@ -6,6 +6,7 @@
 
 #include <asm/io.h>
 #include <asm/setup.h>
+#include <asm/shared/tdx.h>
 #include <asm/unaccepted_memory.h>
 
 /* Protects unaccepted memory bitmap */
@@ -29,7 +30,13 @@ void accept_memory(phys_addr_t start, phys_addr_t end)
 		unsigned long len = range_end - range_start;
 
 		/* Platform-specific memory-acceptance call goes here */
-		panic("Cannot accept memory");
+		if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST)) {
+			tdx_accept_memory(range_start * PMD_SIZE,
+					  range_end * PMD_SIZE);
+		} else {
+			panic("Cannot accept memory");
+		}
+
 		bitmap_clear(unaccepted_memory, range_start, len);
 	}
 	spin_unlock_irqrestore(&unaccepted_memory_lock, flags);
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 58+ messages in thread

* [PATCHv5 11/12] mm/vmstat: Add counter for memory accepting
  2022-04-25  3:39 [PATCHv5 00/12] mm, x86/cc: Implement support for unaccepted memory Kirill A. Shutemov
                   ` (9 preceding siblings ...)
  2022-04-25  3:39 ` [PATCHv5 10/12] x86/tdx: Unaccepted memory support Kirill A. Shutemov
@ 2022-04-25  3:39 ` Kirill A. Shutemov
  2022-04-25  3:39 ` [PATCHv5 12/12] x86/mm: Report unaccepted memory in /proc/meminfo Kirill A. Shutemov
  11 siblings, 0 replies; 58+ messages in thread
From: Kirill A. Shutemov @ 2022-04-25  3:39 UTC (permalink / raw)
  To: 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,
	Dave Hansen, Brijesh Singh, Mike Rapoport, David Hildenbrand,
	x86, linux-mm, linux-coco, linux-efi, linux-kernel,
	Kirill A. Shutemov

The counter increased every time kernel accepts a memory region.

The counter allows to see if memory acceptation is still ongoing and
contributes to memory allocation latency.

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
 arch/x86/mm/unaccepted_memory.c | 1 +
 include/linux/vm_event_item.h   | 3 +++
 mm/vmstat.c                     | 3 +++
 3 files changed, 7 insertions(+)

diff --git a/arch/x86/mm/unaccepted_memory.c b/arch/x86/mm/unaccepted_memory.c
index de0790af1824..65cd49b93c50 100644
--- a/arch/x86/mm/unaccepted_memory.c
+++ b/arch/x86/mm/unaccepted_memory.c
@@ -38,6 +38,7 @@ void accept_memory(phys_addr_t start, phys_addr_t end)
 		}
 
 		bitmap_clear(unaccepted_memory, range_start, len);
+		count_vm_events(ACCEPT_MEMORY, len * PMD_SIZE / PAGE_SIZE);
 	}
 	spin_unlock_irqrestore(&unaccepted_memory_lock, flags);
 }
diff --git a/include/linux/vm_event_item.h b/include/linux/vm_event_item.h
index 16a0a4fd000b..6a468164a2f9 100644
--- a/include/linux/vm_event_item.h
+++ b/include/linux/vm_event_item.h
@@ -136,6 +136,9 @@ enum vm_event_item { PGPGIN, PGPGOUT, PSWPIN, PSWPOUT,
 #ifdef CONFIG_X86
 		DIRECT_MAP_LEVEL2_SPLIT,
 		DIRECT_MAP_LEVEL3_SPLIT,
+#endif
+#ifdef CONFIG_UNACCEPTED_MEMORY
+		ACCEPT_MEMORY,
 #endif
 		NR_VM_EVENT_ITEMS
 };
diff --git a/mm/vmstat.c b/mm/vmstat.c
index b75b1a64b54c..4c9197f32406 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -1397,6 +1397,9 @@ const char * const vmstat_text[] = {
 	"direct_map_level2_splits",
 	"direct_map_level3_splits",
 #endif
+#ifdef CONFIG_UNACCEPTED_MEMORY
+	"accept_memory",
+#endif
 #endif /* CONFIG_VM_EVENT_COUNTERS || CONFIG_MEMCG */
 };
 #endif /* CONFIG_PROC_FS || CONFIG_SYSFS || CONFIG_NUMA || CONFIG_MEMCG */
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 58+ messages in thread

* [PATCHv5 12/12] x86/mm: Report unaccepted memory in /proc/meminfo
  2022-04-25  3:39 [PATCHv5 00/12] mm, x86/cc: Implement support for unaccepted memory Kirill A. Shutemov
                   ` (10 preceding siblings ...)
  2022-04-25  3:39 ` [PATCHv5 11/12] mm/vmstat: Add counter for memory accepting Kirill A. Shutemov
@ 2022-04-25  3:39 ` Kirill A. Shutemov
  11 siblings, 0 replies; 58+ messages in thread
From: Kirill A. Shutemov @ 2022-04-25  3:39 UTC (permalink / raw)
  To: 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,
	Dave Hansen, Brijesh Singh, Mike Rapoport, David Hildenbrand,
	x86, linux-mm, linux-coco, linux-efi, linux-kernel,
	Kirill A. Shutemov

Track amount of unaccepted memory and report it in /proc/meminfo.

Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
 arch/x86/include/asm/set_memory.h        |  2 ++
 arch/x86/include/asm/unaccepted_memory.h |  9 ++++++
 arch/x86/mm/init.c                       |  8 ++++++
 arch/x86/mm/pat/set_memory.c             |  2 +-
 arch/x86/mm/unaccepted_memory.c          | 36 +++++++++++++++++++++++-
 5 files changed, 55 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/set_memory.h b/arch/x86/include/asm/set_memory.h
index 78ca53512486..e467f3941d22 100644
--- a/arch/x86/include/asm/set_memory.h
+++ b/arch/x86/include/asm/set_memory.h
@@ -86,6 +86,8 @@ bool kernel_page_present(struct page *page);
 
 extern int kernel_set_to_readonly;
 
+void direct_map_meminfo(struct seq_file *m);
+
 #ifdef CONFIG_X86_64
 /*
  * Prevent speculative access to the page by either unmapping
diff --git a/arch/x86/include/asm/unaccepted_memory.h b/arch/x86/include/asm/unaccepted_memory.h
index a59264ee0ab3..7c93661152a9 100644
--- a/arch/x86/include/asm/unaccepted_memory.h
+++ b/arch/x86/include/asm/unaccepted_memory.h
@@ -3,7 +3,10 @@
 #ifndef _ASM_X86_UNACCEPTED_MEMORY_H
 #define _ASM_X86_UNACCEPTED_MEMORY_H
 
+#include <linux/types.h>
+
 struct boot_params;
+struct seq_file;
 
 void process_unaccepted_memory(struct boot_params *params, u64 start, u64 num);
 
@@ -12,5 +15,11 @@ void process_unaccepted_memory(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);
 
+void unaccepted_meminfo(struct seq_file *m);
+
+#else
+
+static inline void unaccepted_meminfo(struct seq_file *m) {}
+
 #endif
 #endif
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index d8cfce221275..7e92a9d93994 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -1065,3 +1065,11 @@ unsigned long max_swapfile_size(void)
 	return pages;
 }
 #endif
+
+#ifdef CONFIG_PROC_FS
+void arch_report_meminfo(struct seq_file *m)
+{
+	direct_map_meminfo(m);
+	unaccepted_meminfo(m);
+}
+#endif
diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
index abf5ed76e4b7..2880ba01451c 100644
--- a/arch/x86/mm/pat/set_memory.c
+++ b/arch/x86/mm/pat/set_memory.c
@@ -105,7 +105,7 @@ static void split_page_count(int level)
 	direct_pages_count[level - 1] += PTRS_PER_PTE;
 }
 
-void arch_report_meminfo(struct seq_file *m)
+void direct_map_meminfo(struct seq_file *m)
 {
 	seq_printf(m, "DirectMap4k:    %8lu kB\n",
 			direct_pages_count[PG_LEVEL_4K] << 2);
diff --git a/arch/x86/mm/unaccepted_memory.c b/arch/x86/mm/unaccepted_memory.c
index 65cd49b93c50..66a6c529bf31 100644
--- a/arch/x86/mm/unaccepted_memory.c
+++ b/arch/x86/mm/unaccepted_memory.c
@@ -3,14 +3,17 @@
 #include <linux/mm.h>
 #include <linux/pfn.h>
 #include <linux/spinlock.h>
+#include <linux/seq_file.h>
 
+#include <asm/e820/api.h>
 #include <asm/io.h>
 #include <asm/setup.h>
 #include <asm/shared/tdx.h>
 #include <asm/unaccepted_memory.h>
 
-/* Protects unaccepted memory bitmap */
+/* Protects unaccepted memory bitmap and nr_unaccepted */
 static DEFINE_SPINLOCK(unaccepted_memory_lock);
+static unsigned long nr_unaccepted;
 
 void accept_memory(phys_addr_t start, phys_addr_t end)
 {
@@ -39,6 +42,12 @@ void accept_memory(phys_addr_t start, phys_addr_t end)
 
 		bitmap_clear(unaccepted_memory, range_start, len);
 		count_vm_events(ACCEPT_MEMORY, len * PMD_SIZE / PAGE_SIZE);
+
+		/* In early boot nr_unaccepted is not yet initialized */
+		if (nr_unaccepted) {
+			WARN_ON(nr_unaccepted < len);
+			nr_unaccepted -= len;
+		}
 	}
 	spin_unlock_irqrestore(&unaccepted_memory_lock, flags);
 }
@@ -62,3 +71,28 @@ bool memory_is_unaccepted(phys_addr_t start, phys_addr_t end)
 
 	return ret;
 }
+
+void unaccepted_meminfo(struct seq_file *m)
+{
+	seq_printf(m, "UnacceptedMem:  %8lu kB\n",
+		   (READ_ONCE(nr_unaccepted) * PMD_SIZE) >> 10);
+}
+
+static int __init unaccepted_meminfo_init(void)
+{
+	unsigned long *unaccepted_memory;
+	unsigned long flags, bitmap_size;
+
+	if (!boot_params.unaccepted_memory)
+		return 0;
+
+	bitmap_size = e820__end_of_ram_pfn() * PAGE_SIZE / PMD_SIZE;
+	unaccepted_memory = __va(boot_params.unaccepted_memory);
+
+	spin_lock_irqsave(&unaccepted_memory_lock, flags);
+	nr_unaccepted = bitmap_weight(unaccepted_memory, bitmap_size);
+	spin_unlock_irqrestore(&unaccepted_memory_lock, flags);
+
+	return 0;
+}
+fs_initcall(unaccepted_meminfo_init);
-- 
2.35.1


^ permalink raw reply related	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 01/12] x86/boot/: Centralize __pa()/__va() definitions
  2022-04-25  3:39 ` [PATCHv5 01/12] x86/boot/: Centralize __pa()/__va() definitions Kirill A. Shutemov
@ 2022-04-25  7:37   ` David Hildenbrand
  2022-04-25  7:52   ` Mike Rapoport
  1 sibling, 0 replies; 58+ messages in thread
From: David Hildenbrand @ 2022-04-25  7:37 UTC (permalink / raw)
  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,
	Dave Hansen, Brijesh Singh, Mike Rapoport, x86, linux-mm,
	linux-coco, linux-efi, linux-kernel

On 25.04.22 05:39, Kirill A. Shutemov wrote:
> Replace multiple __pa()/__va() definitions with a single one in misc.h.
> 
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> ---
>

Reviewed-by: David Hildenbrand <david@redhat.com>


-- 
Thanks,

David / dhildenb


^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 01/12] x86/boot/: Centralize __pa()/__va() definitions
  2022-04-25  3:39 ` [PATCHv5 01/12] x86/boot/: Centralize __pa()/__va() definitions Kirill A. Shutemov
  2022-04-25  7:37   ` David Hildenbrand
@ 2022-04-25  7:52   ` Mike Rapoport
  1 sibling, 0 replies; 58+ messages in thread
From: Mike Rapoport @ 2022-04-25  7:52 UTC (permalink / raw)
  To: Kirill A. Shutemov
  Cc: Borislav Petkov, Andy Lutomirski, Sean Christopherson,
	Andrew Morton, Joerg Roedel, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Dave Hansen,
	Brijesh Singh, David Hildenbrand, x86, linux-mm, linux-coco,
	linux-efi, linux-kernel

On Mon, Apr 25, 2022 at 06:39:23AM +0300, Kirill A. Shutemov wrote:
> Replace multiple __pa()/__va() definitions with a single one in misc.h.
> 
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>

Reviewed-by: Mike Rapoport <rppt@linux.ibm.com>

> ---
>  arch/x86/boot/compressed/ident_map_64.c | 8 --------
>  arch/x86/boot/compressed/misc.h         | 9 +++++++++
>  arch/x86/boot/compressed/sev.c          | 2 --
>  3 files changed, 9 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/x86/boot/compressed/ident_map_64.c b/arch/x86/boot/compressed/ident_map_64.c
> index f7213d0943b8..fe523ee1a19f 100644
> --- a/arch/x86/boot/compressed/ident_map_64.c
> +++ b/arch/x86/boot/compressed/ident_map_64.c
> @@ -8,14 +8,6 @@
>   * Copyright (C)      2016  Kees Cook
>   */
>  
> -/*
> - * Since we're dealing with identity mappings, physical and virtual
> - * addresses are the same, so override these defines which are ultimately
> - * used by the headers in misc.h.
> - */
> -#define __pa(x)  ((unsigned long)(x))
> -#define __va(x)  ((void *)((unsigned long)(x)))
> -
>  /* No PAGE_TABLE_ISOLATION support needed either: */
>  #undef CONFIG_PAGE_TABLE_ISOLATION
>  
> diff --git a/arch/x86/boot/compressed/misc.h b/arch/x86/boot/compressed/misc.h
> index ea71cf3d64e1..9f7154a30d37 100644
> --- a/arch/x86/boot/compressed/misc.h
> +++ b/arch/x86/boot/compressed/misc.h
> @@ -19,6 +19,15 @@
>  /* cpu_feature_enabled() cannot be used this early */
>  #define USE_EARLY_PGTABLE_L5
>  
> +/*
> + * Boot stub deals with identity mappings, physical and virtual addresses are
> + * the same, so override these defines.
> + *
> + * <asm/page.h> will not define them if they are already defined.
> + */
> +#define __pa(x)  ((unsigned long)(x))
> +#define __va(x)  ((void *)((unsigned long)(x)))
> +
>  #include <linux/linkage.h>
>  #include <linux/screen_info.h>
>  #include <linux/elf.h>
> diff --git a/arch/x86/boot/compressed/sev.c b/arch/x86/boot/compressed/sev.c
> index 28bcf04c022e..4dcea0bc4fe4 100644
> --- a/arch/x86/boot/compressed/sev.c
> +++ b/arch/x86/boot/compressed/sev.c
> @@ -106,9 +106,7 @@ static enum es_result vc_read_mem(struct es_em_ctxt *ctxt,
>  }
>  
>  #undef __init
> -#undef __pa
>  #define __init
> -#define __pa(x)	((unsigned long)(x))
>  
>  #define __BOOT_COMPRESSED
>  
> -- 
> 2.35.1
> 

-- 
Sincerely yours,
Mike.

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 06/12] x86/boot/compressed: Handle unaccepted memory
  2022-04-25  3:39 ` [PATCHv5 06/12] x86/boot/compressed: Handle " Kirill A. Shutemov
@ 2022-04-27  0:17   ` Michael Roth
  2022-04-27 14:19     ` Kirill A. Shutemov
  2022-04-29 13:10   ` Wander Lairson Costa
  2022-05-03 14:12   ` Borislav Petkov
  2 siblings, 1 reply; 58+ messages in thread
From: Michael Roth @ 2022-04-27  0:17 UTC (permalink / raw)
  To: Kirill A. Shutemov
  Cc: Borislav Petkov, Andy Lutomirski, Sean Christopherson,
	Andrew Morton, Joerg Roedel, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Dave Hansen,
	Brijesh Singh, Mike Rapoport, David Hildenbrand, x86, linux-mm,
	linux-coco, linux-efi, linux-kernel

On Mon, Apr 25, 2022 at 06:39:28AM +0300, Kirill A. Shutemov wrote:
> The firmware will pre-accept the memory used to run the stub. But, the
> stub is responsible for accepting the memory into which it decompresses
> the main kernel. Accept memory just before decompression starts.
> 
> The stub is also responsible for choosing a physical address in which to
> place the decompressed kernel image. The KASLR mechanism will randomize
> this physical address. Since the unaccepted memory region is relatively
> small, KASLR would be quite ineffective if it only used the pre-accepted
> area (EFI_CONVENTIONAL_MEMORY). Ensure that KASLR randomizes among the
> entire physical address space by also including EFI_UNACCEPTED_MEMOR
> 
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> ---
>  arch/x86/boot/compressed/Makefile        |  2 +-
>  arch/x86/boot/compressed/kaslr.c         | 14 ++++++++++++--
>  arch/x86/boot/compressed/mem.c           | 21 +++++++++++++++++++++
>  arch/x86/boot/compressed/misc.c          |  9 +++++++++
>  arch/x86/include/asm/unaccepted_memory.h |  2 ++
>  5 files changed, 45 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
> index 7f672f7e2fea..b59007e57cbf 100644
> --- a/arch/x86/boot/compressed/Makefile
> +++ b/arch/x86/boot/compressed/Makefile
> @@ -102,7 +102,7 @@ endif
>  
>  vmlinux-objs-$(CONFIG_ACPI) += $(obj)/acpi.o
>  vmlinux-objs-$(CONFIG_INTEL_TDX_GUEST) += $(obj)/tdx.o $(obj)/tdcall.o
> -vmlinux-objs-$(CONFIG_UNACCEPTED_MEMORY) += $(obj)/bitmap.o $(obj)/mem.o
> +vmlinux-objs-$(CONFIG_UNACCEPTED_MEMORY) += $(obj)/bitmap.o $(obj)/find.o $(obj)/mem.o

Since it's possible to have CONFIG_UNACCEPTED_MEMORY=y while
CONFIG_INTEL_TDX_GUEST=n (e.g. for SNP-only guest kernels), this can
result in mem.o reporting linker errors due to tdx_accept_memory() not
being defined. I think it needs a stub for !CONFIG_INTEL_TDX_GUEST, or
something along that line.

>  
>  vmlinux-objs-$(CONFIG_EFI_MIXED) += $(obj)/efi_thunk_$(BITS).o
>  efi-obj-$(CONFIG_EFI_STUB) = $(objtree)/drivers/firmware/efi/libstub/lib.a
> diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
> index 411b268bc0a2..59db90626042 100644
> --- a/arch/x86/boot/compressed/kaslr.c
> +++ b/arch/x86/boot/compressed/kaslr.c
> @@ -725,10 +725,20 @@ process_efi_entries(unsigned long minimum, unsigned long image_size)
>  		 * but in practice there's firmware where using that memory leads
>  		 * to crashes.
>  		 *
> -		 * Only EFI_CONVENTIONAL_MEMORY is guaranteed to be free.
> +		 * Only EFI_CONVENTIONAL_MEMORY and EFI_UNACCEPTED_MEMORY (if
> +		 * supported) are guaranteed to be free.
>  		 */
> -		if (md->type != EFI_CONVENTIONAL_MEMORY)
> +
> +		switch (md->type) {
> +		case EFI_CONVENTIONAL_MEMORY:
> +			break;
> +		case EFI_UNACCEPTED_MEMORY:

Just FYI, but with latest tip boot/compressed now relies on a separate header
in arch/x86/boot/compressed/efi.h where this need to be defined again.

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 06/12] x86/boot/compressed: Handle unaccepted memory
  2022-04-27  0:17   ` Michael Roth
@ 2022-04-27 14:19     ` Kirill A. Shutemov
  2022-05-03 14:15       ` Borislav Petkov
  0 siblings, 1 reply; 58+ messages in thread
From: Kirill A. Shutemov @ 2022-04-27 14:19 UTC (permalink / raw)
  To: Michael Roth, Borislav Petkov
  Cc: Kirill A. Shutemov, Andy Lutomirski, Sean Christopherson,
	Andrew Morton, Joerg Roedel, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Dave Hansen,
	Brijesh Singh, Mike Rapoport, David Hildenbrand, x86, linux-mm,
	linux-coco, linux-efi, linux-kernel

On Tue, Apr 26, 2022 at 07:17:56PM -0500, Michael Roth wrote:
> On Mon, Apr 25, 2022 at 06:39:28AM +0300, Kirill A. Shutemov wrote:
> > The firmware will pre-accept the memory used to run the stub. But, the
> > stub is responsible for accepting the memory into which it decompresses
> > the main kernel. Accept memory just before decompression starts.
> > 
> > The stub is also responsible for choosing a physical address in which to
> > place the decompressed kernel image. The KASLR mechanism will randomize
> > this physical address. Since the unaccepted memory region is relatively
> > small, KASLR would be quite ineffective if it only used the pre-accepted
> > area (EFI_CONVENTIONAL_MEMORY). Ensure that KASLR randomizes among the
> > entire physical address space by also including EFI_UNACCEPTED_MEMOR
> > 
> > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> > ---
> >  arch/x86/boot/compressed/Makefile        |  2 +-
> >  arch/x86/boot/compressed/kaslr.c         | 14 ++++++++++++--
> >  arch/x86/boot/compressed/mem.c           | 21 +++++++++++++++++++++
> >  arch/x86/boot/compressed/misc.c          |  9 +++++++++
> >  arch/x86/include/asm/unaccepted_memory.h |  2 ++
> >  5 files changed, 45 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
> > index 7f672f7e2fea..b59007e57cbf 100644
> > --- a/arch/x86/boot/compressed/Makefile
> > +++ b/arch/x86/boot/compressed/Makefile
> > @@ -102,7 +102,7 @@ endif
> >  
> >  vmlinux-objs-$(CONFIG_ACPI) += $(obj)/acpi.o
> >  vmlinux-objs-$(CONFIG_INTEL_TDX_GUEST) += $(obj)/tdx.o $(obj)/tdcall.o
> > -vmlinux-objs-$(CONFIG_UNACCEPTED_MEMORY) += $(obj)/bitmap.o $(obj)/mem.o
> > +vmlinux-objs-$(CONFIG_UNACCEPTED_MEMORY) += $(obj)/bitmap.o $(obj)/find.o $(obj)/mem.o
> 
> Since it's possible to have CONFIG_UNACCEPTED_MEMORY=y while
> CONFIG_INTEL_TDX_GUEST=n (e.g. for SNP-only guest kernels), this can
> result in mem.o reporting linker errors due to tdx_accept_memory() not
> being defined. I think it needs a stub for !CONFIG_INTEL_TDX_GUEST, or
> something along that line.

Fair enough. This would do the trick:

diff --git a/arch/x86/boot/compressed/mem.c b/arch/x86/boot/compressed/mem.c
index 539fff27de49..4a49a2438180 100644
--- a/arch/x86/boot/compressed/mem.c
+++ b/arch/x86/boot/compressed/mem.c
@@ -19,6 +19,9 @@ static bool is_tdx_guest(void)
 	static bool once;
 	static bool is_tdx;

+	if (!IS_ENABLED(CONFIG_INTEL_TDX_GUEST))
+	    return false;
+
 	if (!once) {
 		u32 eax, sig[3];

> >  vmlinux-objs-$(CONFIG_EFI_MIXED) += $(obj)/efi_thunk_$(BITS).o
> >  efi-obj-$(CONFIG_EFI_STUB) = $(objtree)/drivers/firmware/efi/libstub/lib.a
> > diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
> > index 411b268bc0a2..59db90626042 100644
> > --- a/arch/x86/boot/compressed/kaslr.c
> > +++ b/arch/x86/boot/compressed/kaslr.c
> > @@ -725,10 +725,20 @@ process_efi_entries(unsigned long minimum, unsigned long image_size)
> >  		 * but in practice there's firmware where using that memory leads
> >  		 * to crashes.
> >  		 *
> > -		 * Only EFI_CONVENTIONAL_MEMORY is guaranteed to be free.
> > +		 * Only EFI_CONVENTIONAL_MEMORY and EFI_UNACCEPTED_MEMORY (if
> > +		 * supported) are guaranteed to be free.
> >  		 */
> > -		if (md->type != EFI_CONVENTIONAL_MEMORY)
> > +
> > +		switch (md->type) {
> > +		case EFI_CONVENTIONAL_MEMORY:
> > +			break;
> > +		case EFI_UNACCEPTED_MEMORY:
> 
> Just FYI, but with latest tip boot/compressed now relies on a separate header
> in arch/x86/boot/compressed/efi.h where this need to be defined again.

Right.

Borislav, how do you want to handle this? Do you want me to rebase the
tree to a specific branch?

-- 
 Kirill A. Shutemov

^ permalink raw reply related	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 03/12] efi/x86: Get full memory map in allocate_e820()
  2022-04-25  3:39 ` [PATCHv5 03/12] efi/x86: Get full memory map in allocate_e820() Kirill A. Shutemov
@ 2022-04-27 20:25   ` Borislav Petkov
  2022-04-27 23:48     ` Kirill A. Shutemov
  0 siblings, 1 reply; 58+ messages in thread
From: Borislav Petkov @ 2022-04-27 20:25 UTC (permalink / raw)
  To: Kirill A. Shutemov
  Cc: Andy Lutomirski, Sean Christopherson, Andrew Morton,
	Joerg Roedel, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Dave Hansen,
	Brijesh Singh, Mike Rapoport, David Hildenbrand, x86, linux-mm,
	linux-coco, linux-efi, linux-kernel

On Mon, Apr 25, 2022 at 06:39:25AM +0300, Kirill A. Shutemov wrote:
>  static efi_status_t allocate_e820(struct boot_params *params,
> +				  struct efi_boot_memmap *map,
>  				  struct setup_data **e820ext,
>  				  u32 *e820ext_size)
>  {
> -	unsigned long map_size, desc_size, map_key;
>  	efi_status_t status;
> -	__u32 nr_desc, desc_version;
> +	__u32 nr_desc;
>  
> -	/* Only need the size of the mem map and size of each mem descriptor */
> -	map_size = 0;
> -	status = efi_bs_call(get_memory_map, &map_size, NULL, &map_key,
> -			     &desc_size, &desc_version);
> -	if (status != EFI_BUFFER_TOO_SMALL)
> -		return (status != EFI_SUCCESS) ? status : EFI_UNSUPPORTED;
> -
> -	nr_desc = map_size / desc_size + EFI_MMAP_NR_SLACK_SLOTS;
> +	status = efi_get_memory_map(map);
> +	if (status != EFI_SUCCESS)
> +		return status;
>  
> -	if (nr_desc > ARRAY_SIZE(params->e820_table)) {
> -		u32 nr_e820ext = nr_desc - ARRAY_SIZE(params->e820_table);
> +	nr_desc = *map->map_size / *map->desc_size;
> +	if (nr_desc > ARRAY_SIZE(params->e820_table) - EFI_MMAP_NR_SLACK_SLOTS) {
> +		u32 nr_e820ext = nr_desc - ARRAY_SIZE(params->e820_table) +
> +			EFI_MMAP_NR_SLACK_SLOTS;
>  
>  		status = alloc_e820ext(nr_e820ext, e820ext, e820ext_size);
>  		if (status != EFI_SUCCESS)
> -			return status;
> +			goto out;

Still silly, that label is useless then. Pasting the whole, simplified
function below.

It looks like it all boils down to propagating the retval up the chain...

static efi_status_t allocate_e820(struct boot_params *params,
                                  struct efi_boot_memmap *map,
                                  struct setup_data **e820ext,
                                  u32 *e820ext_size)
{
        efi_status_t status;
        __u32 nr_desc;

        status = efi_get_memory_map(map);
        if (status != EFI_SUCCESS)
                return status;

        nr_desc = *map->map_size / *map->desc_size;
        if (nr_desc > ARRAY_SIZE(params->e820_table) - EFI_MMAP_NR_SLACK_SLOTS) {
                u32 nr_e820ext = nr_desc - ARRAY_SIZE(params->e820_table) + EFI_MMAP_NR_SLACK_SLOTS;

                status = alloc_e820ext(nr_e820ext, e820ext, e820ext_size);
        }

        efi_bs_call(free_pool, *map->map);
        return status;
}

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 03/12] efi/x86: Get full memory map in allocate_e820()
  2022-04-27 20:25   ` Borislav Petkov
@ 2022-04-27 23:48     ` Kirill A. Shutemov
  2022-04-28 10:02       ` Borislav Petkov
  0 siblings, 1 reply; 58+ messages in thread
From: Kirill A. Shutemov @ 2022-04-27 23:48 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Kirill A. Shutemov, Andy Lutomirski, Sean Christopherson,
	Andrew Morton, Joerg Roedel, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Dave Hansen,
	Brijesh Singh, Mike Rapoport, David Hildenbrand, x86, linux-mm,
	linux-coco, linux-efi, linux-kernel

On Wed, Apr 27, 2022 at 10:25:11PM +0200, Borislav Petkov wrote:
> On Mon, Apr 25, 2022 at 06:39:25AM +0300, Kirill A. Shutemov wrote:
> >  static efi_status_t allocate_e820(struct boot_params *params,
> > +				  struct efi_boot_memmap *map,
> >  				  struct setup_data **e820ext,
> >  				  u32 *e820ext_size)
> >  {
> > -	unsigned long map_size, desc_size, map_key;
> >  	efi_status_t status;
> > -	__u32 nr_desc, desc_version;
> > +	__u32 nr_desc;
> >  
> > -	/* Only need the size of the mem map and size of each mem descriptor */
> > -	map_size = 0;
> > -	status = efi_bs_call(get_memory_map, &map_size, NULL, &map_key,
> > -			     &desc_size, &desc_version);
> > -	if (status != EFI_BUFFER_TOO_SMALL)
> > -		return (status != EFI_SUCCESS) ? status : EFI_UNSUPPORTED;
> > -
> > -	nr_desc = map_size / desc_size + EFI_MMAP_NR_SLACK_SLOTS;
> > +	status = efi_get_memory_map(map);
> > +	if (status != EFI_SUCCESS)
> > +		return status;
> >  
> > -	if (nr_desc > ARRAY_SIZE(params->e820_table)) {
> > -		u32 nr_e820ext = nr_desc - ARRAY_SIZE(params->e820_table);
> > +	nr_desc = *map->map_size / *map->desc_size;
> > +	if (nr_desc > ARRAY_SIZE(params->e820_table) - EFI_MMAP_NR_SLACK_SLOTS) {
> > +		u32 nr_e820ext = nr_desc - ARRAY_SIZE(params->e820_table) +
> > +			EFI_MMAP_NR_SLACK_SLOTS;
> >  
> >  		status = alloc_e820ext(nr_e820ext, e820ext, e820ext_size);
> >  		if (status != EFI_SUCCESS)
> > -			return status;
> > +			goto out;
> 
> Still silly, that label is useless then. Pasting the whole, simplified
> function below.
> 
> It looks like it all boils down to propagating the retval up the chain...

Right. That's true. But having goto here makes patch 5/12 a bit cleaner.
I will move the goto there. Is that what you want to see?

-- 
 Kirill A. Shutemov

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 03/12] efi/x86: Get full memory map in allocate_e820()
  2022-04-27 23:48     ` Kirill A. Shutemov
@ 2022-04-28 10:02       ` Borislav Petkov
  0 siblings, 0 replies; 58+ messages in thread
From: Borislav Petkov @ 2022-04-28 10:02 UTC (permalink / raw)
  To: Kirill A. Shutemov
  Cc: Kirill A. Shutemov, Andy Lutomirski, Sean Christopherson,
	Andrew Morton, Joerg Roedel, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Dave Hansen,
	Brijesh Singh, Mike Rapoport, David Hildenbrand, x86, linux-mm,
	linux-coco, linux-efi, linux-kernel

On Thu, Apr 28, 2022 at 02:48:53AM +0300, Kirill A. Shutemov wrote:
> Right. That's true. But having goto here makes patch 5/12 a bit cleaner.

Ok, let's take our time machine and go into the future:

This patch is in git, there's no concept of "next patch" anymore - and
someone is staring at it for whatever reason.

Someone is wondering: why the hell was this done this way? And which
is that "next patch"? Someone probably needs to sort them in the
application order to figure out which next patch the author is talking
about...

See what I mean?

Also, if this hunk

+
+       if (IS_ENABLED(CONFIG_UNACCEPTED_MEMORY))
+               status = allocate_unaccepted_memory(params, nr_desc, map);
+

is what this is all about, then no, this confusion is not even worth it
- please make sure your patches make sense on their own.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 02/12] mm: Add support for unaccepted memory
  2022-04-25  3:39 ` [PATCHv5 02/12] mm: Add support for unaccepted memory Kirill A. Shutemov
@ 2022-04-28 10:05   ` Borislav Petkov
  2022-05-03 20:21   ` David Hildenbrand
  1 sibling, 0 replies; 58+ messages in thread
From: Borislav Petkov @ 2022-04-28 10:05 UTC (permalink / raw)
  To: Kirill A. Shutemov
  Cc: Andy Lutomirski, Sean Christopherson, Andrew Morton,
	Joerg Roedel, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Dave Hansen,
	Brijesh Singh, Mike Rapoport, David Hildenbrand, x86, linux-mm,
	linux-coco, linux-efi, linux-kernel, Mike Rapoport

On Mon, Apr 25, 2022 at 06:39:24AM +0300, Kirill A. Shutemov wrote:
> @@ -1124,6 +1159,23 @@ static inline void __free_one_page(struct page *page,
>  done_merging:
>  	set_buddy_order(page, order);
>  
> +	/*
> +	 * The page gets marked as PageUnaccepted() if any of merged-in pages
> +	 * is PageUnaccepted().
> +	 *
> +	 * New pages, just being added to buddy allocator, do not have
> +	 * PageUnaccepted() set. FPI_UNACCEPTED_SLOWPATH indicates that the
> +	 * page is new and page_is_unaccepted() check is required to
> +	 * determinate if accaptance is required.

Unknown word [accaptance] in comment.
Suggestions: ['acceptance', ...

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 05/12] efi/x86: Implement support for unaccepted memory
  2022-04-25  3:39 ` [PATCHv5 05/12] efi/x86: Implement support for unaccepted memory Kirill A. Shutemov
@ 2022-04-29 10:53   ` Borislav Petkov
  2022-05-02 13:40     ` Kirill A. Shutemov
  0 siblings, 1 reply; 58+ messages in thread
From: Borislav Petkov @ 2022-04-29 10:53 UTC (permalink / raw)
  To: Kirill A. Shutemov
  Cc: Andy Lutomirski, Sean Christopherson, Andrew Morton,
	Joerg Roedel, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Dave Hansen,
	Brijesh Singh, Mike Rapoport, David Hildenbrand, x86, linux-mm,
	linux-coco, linux-efi, linux-kernel

On Mon, Apr 25, 2022 at 06:39:27AM +0300, Kirill A. Shutemov wrote:
> diff --git a/drivers/firmware/efi/libstub/x86-stub.c b/drivers/firmware/efi/libstub/x86-stub.c
> index 5401985901f5..f9b88174209e 100644
> --- a/drivers/firmware/efi/libstub/x86-stub.c
> +++ b/drivers/firmware/efi/libstub/x86-stub.c
> @@ -15,6 +15,7 @@
>  #include <asm/setup.h>
>  #include <asm/desc.h>
>  #include <asm/boot.h>
> +#include <asm/unaccepted_memory.h>
>  
>  #include "efistub.h"
>  
> @@ -504,6 +505,17 @@ setup_e820(struct boot_params *params, struct setup_data *e820ext, u32 e820ext_s
>  			e820_type = E820_TYPE_PMEM;
>  			break;
>  
> +		case EFI_UNACCEPTED_MEMORY:
> +			if (!IS_ENABLED(CONFIG_UNACCEPTED_MEMORY)) {
> +				efi_warn_once("The system has unaccepted memory,"
> +					     " but kernel does not support it\n");
> +				efi_warn_once("Consider enabling UNACCEPTED_MEMORY\n");

CONFIG_UNACCEPTED_MEMORY

> +				continue;
> +			}
> +			e820_type = E820_TYPE_RAM;
> +			process_unaccepted_memory(params, d->phys_addr,
> +					d->phys_addr + PAGE_SIZE * d->num_pages);

Align arguments on the opening brace.

> +			break;
>  		default:
>  			continue;
>  		}
> @@ -568,6 +580,59 @@ static efi_status_t alloc_e820ext(u32 nr_desc, struct setup_data **e820ext,
>  	return status;
>  }
>  
> +static efi_status_t allocate_unaccepted_memory(struct boot_params *params,
> +					       __u32 nr_desc,
> +					       struct efi_boot_memmap *map)
> +{
> +	unsigned long *mem = NULL;
> +	u64 size, max_addr = 0;
> +	efi_status_t status;
> +	bool found = false;
> +	int i;
> +
> +	/* Check if there's any unaccepted memory and find the max address */
> +	for (i = 0; i < nr_desc; i++) {
> +		efi_memory_desc_t *d;
> +
> +		d = efi_early_memdesc_ptr(*map->map, *map->desc_size, i);
> +		if (d->type == EFI_UNACCEPTED_MEMORY)
> +			found = true;
> +		if (d->phys_addr + d->num_pages * PAGE_SIZE > max_addr)
> +			max_addr = d->phys_addr + d->num_pages * PAGE_SIZE;
> +	}
> +
> +	if (!found) {
> +		params->unaccepted_memory = 0;
> +		return EFI_SUCCESS;
> +	}
> +
> +	/*
> +	 * If unaccepted memory is present allocate a bitmap to track what
> +	 * memory has to be accepted before access.
> +	 *
> +	 * One bit in the bitmap represents 2MiB in the address space:
> +	 * A 4k bitmap can track 64GiB of physical address space.
> +	 *
> +	 * In the worst case scenario -- a huge hole in the middle of the
> +	 * address space -- It needs 256MiB to handle 4PiB of the address
> +	 * space.
> +	 *
> +	 * TODO: handle situation if params->unaccepted_memory has already set.

"... is already set."

And when is that TODO taken care of? Later patch or patchset?

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 04/12] x86/boot: Add infrastructure required for unaccepted memory support
  2022-04-25  3:39 ` [PATCHv5 04/12] x86/boot: Add infrastructure required for unaccepted memory support Kirill A. Shutemov
@ 2022-04-29 10:58   ` Wander Lairson Costa
  2022-05-02 13:38     ` Kirill A. Shutemov
  0 siblings, 1 reply; 58+ messages in thread
From: Wander Lairson Costa @ 2022-04-29 10:58 UTC (permalink / raw)
  To: Kirill A. Shutemov
  Cc: Borislav Petkov, Andy Lutomirski, Sean Christopherson,
	Andrew Morton, Joerg Roedel, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Dave Hansen,
	Brijesh Singh, Mike Rapoport, David Hildenbrand, x86, linux-mm,
	linux-coco, linux-efi, linux-kernel

On Mon, Apr 25, 2022 at 06:39:26AM +0300, Kirill A. Shutemov wrote:

[snip]

>  
> +static __always_inline void __set_bit(long nr, volatile unsigned long *addr)

Can't we update the existing set_bit function?

> +{
> +	asm volatile(__ASM_SIZE(bts) " %1,%0" : : "m" (*(volatile long *) addr),

Why do we need the cast here?

> +		     "Ir" (nr) : "memory");

Shouldn't we add "cc" to the clobber list?

> +}
> +
> +static __always_inline void __clear_bit(long nr, volatile unsigned long *addr)
> +{
> +	asm volatile(__ASM_SIZE(btr) " %1,%0" : : "m" (*(volatile long *) addr),
> +		     "Ir" (nr) : "memory");
> +}

Same comments of __set_bit apply here (except there is no clear_bit function)

[snip]

> +
> +static __always_inline unsigned long swab(const unsigned long y)
> +{
> +#if __BITS_PER_LONG == 64
> +	return __builtin_bswap32(y);
> +#else /* __BITS_PER_LONG == 32 */
> +	return __builtin_bswap64(y);

Suppose y = 0x11223344UL, then, the compiler to cast it to a 64 bits
value yielding 0x0000000011223344ULL, __builtin_bswap64 will then
return 0x4433221100000000, and the return value will be casted back
to 32 bits, so swapb will always return 0, won't it?

> +#endif
> +}
> +
> +unsigned long _find_next_bit(const unsigned long *addr1,
> +		const unsigned long *addr2, unsigned long nbits,

The addr2 name seems a bit misleading, it seems to act as some kind of mask,
is that right?

> +		unsigned long start, unsigned long invert, unsigned long le)
> +{
> +	unsigned long tmp, mask;
> +
> +	if (unlikely(start >= nbits))
> +		return nbits;
> +
> +	tmp = addr1[start / BITS_PER_LONG];
> +	if (addr2)
> +		tmp &= addr2[start / BITS_PER_LONG];
> +	tmp ^= invert;
> +
> +	/* Handle 1st word. */
> +	mask = BITMAP_FIRST_WORD_MASK(start);
> +	if (le)
> +		mask = swab(mask);
> +
> +	tmp &= mask;
> +
> +	start = round_down(start, BITS_PER_LONG);
> +
> +	while (!tmp) {
> +		start += BITS_PER_LONG;
> +		if (start >= nbits)
> +			return nbits;
> +
> +		tmp = addr1[start / BITS_PER_LONG];
> +		if (addr2)
> +			tmp &= addr2[start / BITS_PER_LONG];
> +		tmp ^= invert;
> +	}

Isn't better to divide start by BITS_PER_LONG in the beginning of the fuction,
and then multiply it by BITS_PER_LONG when necessary, saving the division operations
in the while loop?

[snip]


^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 06/12] x86/boot/compressed: Handle unaccepted memory
  2022-04-25  3:39 ` [PATCHv5 06/12] x86/boot/compressed: Handle " Kirill A. Shutemov
  2022-04-27  0:17   ` Michael Roth
@ 2022-04-29 13:10   ` Wander Lairson Costa
  2022-05-03 14:12   ` Borislav Petkov
  2 siblings, 0 replies; 58+ messages in thread
From: Wander Lairson Costa @ 2022-04-29 13:10 UTC (permalink / raw)
  To: Kirill A. Shutemov
  Cc: Borislav Petkov, Andy Lutomirski, Sean Christopherson,
	Andrew Morton, Joerg Roedel, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Dave Hansen,
	Brijesh Singh, Mike Rapoport, David Hildenbrand, x86, linux-mm,
	linux-coco, linux-efi, linux-kernel

On Mon, Apr 25, 2022 at 06:39:28AM +0300, Kirill A. Shutemov wrote:
> The firmware will pre-accept the memory used to run the stub. But, the
> stub is responsible for accepting the memory into which it decompresses
> the main kernel. Accept memory just before decompression starts.
> 
> The stub is also responsible for choosing a physical address in which to
> place the decompressed kernel image. The KASLR mechanism will randomize
> this physical address. Since the unaccepted memory region is relatively
> small, KASLR would be quite ineffective if it only used the pre-accepted
> area (EFI_CONVENTIONAL_MEMORY). Ensure that KASLR randomizes among the
> entire physical address space by also including EFI_UNACCEPTED_MEMOR

nit: s/EFI_UNACCEPTED_MEMOR/EFI_UNACCEPTED_MEMORY./

[snip]


^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 07/12] x86/mm: Reserve unaccepted memory bitmap
  2022-04-25  3:39 ` [PATCHv5 07/12] x86/mm: Reserve unaccepted memory bitmap Kirill A. Shutemov
@ 2022-04-29 13:19   ` Wander Lairson Costa
  2022-05-04 11:04   ` Borislav Petkov
  1 sibling, 0 replies; 58+ messages in thread
From: Wander Lairson Costa @ 2022-04-29 13:19 UTC (permalink / raw)
  To: Kirill A. Shutemov
  Cc: Borislav Petkov, Andy Lutomirski, Sean Christopherson,
	Andrew Morton, Joerg Roedel, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Dave Hansen,
	Brijesh Singh, Mike Rapoport, David Hildenbrand, x86, linux-mm,
	linux-coco, linux-efi, linux-kernel, Mike Rapoport

On Mon, Apr 25, 2022 at 06:39:29AM +0300, Kirill A. Shutemov wrote:
> A given page of memory can only be accepted once. The kernel has a need
> to accept memory both in the early decompression stage and during normal
> runtime.
> 
> A bitmap used to communicate the acceptance state of each page between the

nit: s/bitmap used/bitmap is used/

[snip]


^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 04/12] x86/boot: Add infrastructure required for unaccepted memory support
  2022-04-29 10:58   ` Wander Lairson Costa
@ 2022-05-02 13:38     ` Kirill A. Shutemov
  0 siblings, 0 replies; 58+ messages in thread
From: Kirill A. Shutemov @ 2022-05-02 13:38 UTC (permalink / raw)
  To: Wander Lairson Costa
  Cc: Kirill A. Shutemov, Borislav Petkov, Andy Lutomirski,
	Sean Christopherson, Andrew Morton, Joerg Roedel, Ard Biesheuvel,
	Andi Kleen, Kuppuswamy Sathyanarayanan, David Rientjes,
	Vlastimil Babka, Tom Lendacky, Thomas Gleixner, Peter Zijlstra,
	Paolo Bonzini, Ingo Molnar, Varad Gautam, Dario Faggioli,
	Dave Hansen, Brijesh Singh, Mike Rapoport, David Hildenbrand,
	x86, linux-mm, linux-coco, linux-efi, linux-kernel

On Fri, Apr 29, 2022 at 07:58:14AM -0300, Wander Lairson Costa wrote:
> On Mon, Apr 25, 2022 at 06:39:26AM +0300, Kirill A. Shutemov wrote:
> 
> [snip]

As I said in the commit message, all that code added by the patch is copy
of the battle-tested code from the main kernel. I'm not sure what the
value of these review comment. Hm?

-- 
 Kirill A. Shutemov

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 05/12] efi/x86: Implement support for unaccepted memory
  2022-04-29 10:53   ` Borislav Petkov
@ 2022-05-02 13:40     ` Kirill A. Shutemov
  0 siblings, 0 replies; 58+ messages in thread
From: Kirill A. Shutemov @ 2022-05-02 13:40 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Kirill A. Shutemov, Andy Lutomirski, Sean Christopherson,
	Andrew Morton, Joerg Roedel, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Dave Hansen,
	Brijesh Singh, Mike Rapoport, David Hildenbrand, x86, linux-mm,
	linux-coco, linux-efi, linux-kernel

On Fri, Apr 29, 2022 at 12:53:30PM +0200, Borislav Petkov wrote:
> > +	/*
> > +	 * If unaccepted memory is present allocate a bitmap to track what
> > +	 * memory has to be accepted before access.
> > +	 *
> > +	 * One bit in the bitmap represents 2MiB in the address space:
> > +	 * A 4k bitmap can track 64GiB of physical address space.
> > +	 *
> > +	 * In the worst case scenario -- a huge hole in the middle of the
> > +	 * address space -- It needs 256MiB to handle 4PiB of the address
> > +	 * space.
> > +	 *
> > +	 * TODO: handle situation if params->unaccepted_memory has already set.
> 
> "... is already set."
> 
> And when is that TODO taken care of? Later patch or patchset?

No, not yet. kexec is not a priority at the moment. It will come later.

-- 
 Kirill A. Shutemov

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 06/12] x86/boot/compressed: Handle unaccepted memory
  2022-04-25  3:39 ` [PATCHv5 06/12] x86/boot/compressed: Handle " Kirill A. Shutemov
  2022-04-27  0:17   ` Michael Roth
  2022-04-29 13:10   ` Wander Lairson Costa
@ 2022-05-03 14:12   ` Borislav Petkov
  2022-05-06 15:30     ` Kirill A. Shutemov
  2 siblings, 1 reply; 58+ messages in thread
From: Borislav Petkov @ 2022-05-03 14:12 UTC (permalink / raw)
  To: Kirill A. Shutemov
  Cc: Andy Lutomirski, Sean Christopherson, Andrew Morton,
	Joerg Roedel, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Dave Hansen,
	Brijesh Singh, Mike Rapoport, David Hildenbrand, x86, linux-mm,
	linux-coco, linux-efi, linux-kernel

On Mon, Apr 25, 2022 at 06:39:28AM +0300, Kirill A. Shutemov wrote:
> diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
> index 411b268bc0a2..59db90626042 100644
> --- a/arch/x86/boot/compressed/kaslr.c
> +++ b/arch/x86/boot/compressed/kaslr.c
> @@ -725,10 +725,20 @@ process_efi_entries(unsigned long minimum, unsigned long image_size)
>  		 * but in practice there's firmware where using that memory leads
>  		 * to crashes.
>  		 *
> -		 * Only EFI_CONVENTIONAL_MEMORY is guaranteed to be free.
> +		 * Only EFI_CONVENTIONAL_MEMORY and EFI_UNACCEPTED_MEMORY (if
> +		 * supported) are guaranteed to be free.
>  		 */
> -		if (md->type != EFI_CONVENTIONAL_MEMORY)
> +
> +		switch (md->type) {
> +		case EFI_CONVENTIONAL_MEMORY:
> +			break;
> +		case EFI_UNACCEPTED_MEMORY:
> +			if (IS_ENABLED(CONFIG_UNACCEPTED_MEMORY))
> +				break;
>  			continue;
> +		default:
> +			continue;
> +		}

Is there any special reason for this to be a switch-case or can it
simply be a compound conditional if (bla...) ?

> @@ -66,3 +69,21 @@ void process_unaccepted_memory(struct boot_params *params, u64 start, u64 end)
>  	bitmap_set((unsigned long *)params->unaccepted_memory,
>  		   start / PMD_SIZE, (end - start) / PMD_SIZE);
>  }
> +
> +void accept_memory(phys_addr_t start, phys_addr_t end)
> +{
> +	unsigned long range_start, range_end;
> +	unsigned long *unaccepted_memory;

Please shorten that name so that you don't have to break the lines below.

> +	unsigned long bitmap_size;
> +
> +	unaccepted_memory = (unsigned long *)boot_params->unaccepted_memory;
> +	range_start = start / PMD_SIZE;
> +	bitmap_size = DIV_ROUND_UP(end, PMD_SIZE);
> +
> +	for_each_set_bitrange_from(range_start, range_end,
> +				   unaccepted_memory, bitmap_size) {
> +		__accept_memory(range_start * PMD_SIZE, range_end * PMD_SIZE);
> +		bitmap_clear(unaccepted_memory,
> +			     range_start, range_end - range_start);
> +	}
> +}
> diff --git a/arch/x86/boot/compressed/misc.c b/arch/x86/boot/compressed/misc.c
> index fa8969fad011..285b37e28074 100644
> --- a/arch/x86/boot/compressed/misc.c
> +++ b/arch/x86/boot/compressed/misc.c
> @@ -18,6 +18,7 @@
>  #include "../string.h"
>  #include "../voffset.h"
>  #include <asm/bootparam_utils.h>
> +#include <asm/unaccepted_memory.h>
>  
>  /*
>   * WARNING!!
> @@ -451,6 +452,14 @@ asmlinkage __visible void *extract_kernel(void *rmode, memptr heap,
>  #endif
>  
>  	debug_putstr("\nDecompressing Linux... ");
> +
> +#ifdef CONFIG_UNACCEPTED_MEMORY

IS_ENABLED() perhaps?

> +	if (boot_params->unaccepted_memory) {

Also, that ->unaccepted_memory will be set only when
ACONFIG_UNACCEPTED_MEMORY is set, FAICT.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 06/12] x86/boot/compressed: Handle unaccepted memory
  2022-04-27 14:19     ` Kirill A. Shutemov
@ 2022-05-03 14:15       ` Borislav Petkov
  0 siblings, 0 replies; 58+ messages in thread
From: Borislav Petkov @ 2022-05-03 14:15 UTC (permalink / raw)
  To: Kirill A. Shutemov
  Cc: Michael Roth, Kirill A. Shutemov, Andy Lutomirski,
	Sean Christopherson, Andrew Morton, Joerg Roedel, Ard Biesheuvel,
	Andi Kleen, Kuppuswamy Sathyanarayanan, David Rientjes,
	Vlastimil Babka, Tom Lendacky, Thomas Gleixner, Peter Zijlstra,
	Paolo Bonzini, Ingo Molnar, Varad Gautam, Dario Faggioli,
	Dave Hansen, Brijesh Singh, Mike Rapoport, David Hildenbrand,
	x86, linux-mm, linux-coco, linux-efi, linux-kernel

On Wed, Apr 27, 2022 at 05:19:14PM +0300, Kirill A. Shutemov wrote:
> Borislav, how do you want to handle this? Do you want me to rebase the
> tree to a specific branch?

All patchsets for tip should usually be based ontop of current
tip/master.

The compressed/efi.h change is ontop of tip:x86/sev so we might have to
do some patch tetris...

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 02/12] mm: Add support for unaccepted memory
  2022-04-25  3:39 ` [PATCHv5 02/12] mm: Add support for unaccepted memory Kirill A. Shutemov
  2022-04-28 10:05   ` Borislav Petkov
@ 2022-05-03 20:21   ` David Hildenbrand
  2022-05-06  0:54     ` Kirill A. Shutemov
  1 sibling, 1 reply; 58+ messages in thread
From: David Hildenbrand @ 2022-05-03 20:21 UTC (permalink / raw)
  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,
	Dave Hansen, Brijesh Singh, Mike Rapoport, x86, linux-mm,
	linux-coco, linux-efi, linux-kernel, Mike Rapoport


>  
> +/*
> + * Page acceptance can be very slow. Do not call under critical locks.
> + */
> +static void accept_page(struct page *page, unsigned int order)
> +{
> +	phys_addr_t start = page_to_phys(page);
> +	int i;
> +
> +	accept_memory(start, start + (PAGE_SIZE << order));
> +
> +	for (i = 0; i < (1 << order); i++) {
> +		if (PageUnaccepted(page + i))
> +			__ClearPageUnaccepted(page + i);
> +	}
> +}

What was the rationale of leaving PageUnaccepted() set on sub-pages when
merging pages?

I'd just clear the flag when merging and avoid the loop here. You could
even assert here that we don't have any PageUnaccepted() on tail pages.

-- 
Thanks,

David / dhildenb


^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 07/12] x86/mm: Reserve unaccepted memory bitmap
  2022-04-25  3:39 ` [PATCHv5 07/12] x86/mm: Reserve unaccepted memory bitmap Kirill A. Shutemov
  2022-04-29 13:19   ` Wander Lairson Costa
@ 2022-05-04 11:04   ` Borislav Petkov
  1 sibling, 0 replies; 58+ messages in thread
From: Borislav Petkov @ 2022-05-04 11:04 UTC (permalink / raw)
  To: Kirill A. Shutemov
  Cc: Andy Lutomirski, Sean Christopherson, Andrew Morton,
	Joerg Roedel, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Dave Hansen,
	Brijesh Singh, Mike Rapoport, David Hildenbrand, x86, linux-mm,
	linux-coco, linux-efi, linux-kernel, Mike Rapoport

On Mon, Apr 25, 2022 at 06:39:29AM +0300, Kirill A. Shutemov wrote:
> A given page of memory can only be accepted once. The kernel has a need

s/has a need to/has to/

> to accept memory both in the early decompression stage and during normal
> runtime.
> 
> A bitmap used to communicate the acceptance state of each page between the
	  ^
	  is

> decompression stage and normal runtime.
> 
> boot_params is used to communicate location of the bitmap through out

throughout

> the boot. The bitmap is allocated and initially populated in EFI stub.
> Decompression stage accepts pages required for kernel/initrd and mark

marks

> these pages accordingly in the bitmap. The main kernel picks up the
> bitmap from the same boot_params and uses it to determinate what has to

determine

> be accepted on allocation.
> 
> In the runtime kernel, reserve the bitmap's memory to ensure nothing
> overwrites it.
> 
> The size of bitmap is determinated with e820__end_of_ram_pfn() which

Unknown word [determinated] in commit message.
Suggestions: ['determinate', 'determined', 'terminated', 'determinant']

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 08/12] x86/mm: Provide helpers for unaccepted memory
  2022-04-25  3:39 ` [PATCHv5 08/12] x86/mm: Provide helpers for unaccepted memory Kirill A. Shutemov
@ 2022-05-04 11:12   ` Borislav Petkov
  2022-05-06 16:13     ` Kirill A. Shutemov
  0 siblings, 1 reply; 58+ messages in thread
From: Borislav Petkov @ 2022-05-04 11:12 UTC (permalink / raw)
  To: Kirill A. Shutemov
  Cc: Andy Lutomirski, Sean Christopherson, Andrew Morton,
	Joerg Roedel, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Dave Hansen,
	Brijesh Singh, Mike Rapoport, David Hildenbrand, x86, linux-mm,
	linux-coco, linux-efi, linux-kernel

On Mon, Apr 25, 2022 at 06:39:30AM +0300, Kirill A. Shutemov wrote:
> +/* Protects unaccepted memory bitmap */
> +static DEFINE_SPINLOCK(unaccepted_memory_lock);
> +
> +void accept_memory(phys_addr_t start, phys_addr_t end)
> +{
> +	unsigned long *unaccepted_memory;

shorten that name.

> +	unsigned long flags;
> +	unsigned long range_start, range_end;

The tip-tree preferred ordering of variable declarations at the
beginning of a function is reverse fir tree order::

	struct long_struct_name *descriptive_name;
	unsigned long foo, bar;
	unsigned int tmp;
	int ret;

The above is faster to parse than the reverse ordering::

	int ret;
	unsigned int tmp;
	unsigned long foo, bar;
	struct long_struct_name *descriptive_name;

And even more so than random ordering::

	unsigned long foo, bar;
	int ret;
	struct long_struct_name *descriptive_name;
	unsigned int tmp;

> +
> +	if (!boot_params.unaccepted_memory)
> +		return;
> +
> +	unaccepted_memory = __va(boot_params.unaccepted_memory);
> +	range_start = start / PMD_SIZE;
> +
> +	spin_lock_irqsave(&unaccepted_memory_lock, flags);
> +	for_each_set_bitrange_from(range_start, range_end, unaccepted_memory,
> +				   DIV_ROUND_UP(end, PMD_SIZE)) {
> +		unsigned long len = range_end - range_start;
> +
> +		/* Platform-specific memory-acceptance call goes here */
> +		panic("Cannot accept memory");

Yeah, no, WARN_ON_ONCE() pls.

> +		bitmap_clear(unaccepted_memory, range_start, len);
> +	}
> +	spin_unlock_irqrestore(&unaccepted_memory_lock, flags);
> +}
> +
> +bool memory_is_unaccepted(phys_addr_t start, phys_addr_t end)
> +{
> +	unsigned long *unaccepted_memory = __va(boot_params.unaccepted_memory);

As above, shorten that one.

> +	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;

Wait, what?

That thing is lying: it'll return true for *some* PMD which is accepted
but not the whole range of [start, end].

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 10/12] x86/tdx: Unaccepted memory support
  2022-04-25  3:39 ` [PATCHv5 10/12] x86/tdx: Unaccepted memory support Kirill A. Shutemov
@ 2022-05-05 10:12   ` Borislav Petkov
  2022-05-06 20:44     ` Kirill A. Shutemov
  0 siblings, 1 reply; 58+ messages in thread
From: Borislav Petkov @ 2022-05-05 10:12 UTC (permalink / raw)
  To: Kirill A. Shutemov
  Cc: Andy Lutomirski, Sean Christopherson, Andrew Morton,
	Joerg Roedel, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Dave Hansen,
	Brijesh Singh, Mike Rapoport, David Hildenbrand, x86, linux-mm,
	linux-coco, linux-efi, linux-kernel

On Mon, Apr 25, 2022 at 06:39:32AM +0300, Kirill A. Shutemov wrote:
> Subject: [PATCHv5 10/12] x86/tdx: Unaccepted memory support

Patch subject needs a verb:

"Add ... "

> All preparations are complete.

Drop this sentence.

> Hookup TDX-specific code to accept memory.
> 
> Accepting the memory is the same process as converting memory from
> shared to private: kernel notifies VMM with MAP_GPA hypercall and then
> accept pages with ACCEPT_PAGE module call.
> 
> The implementation in core kernel uses tdx_enc_status_changed(). It
> already used for converting memory to shared and back for I/O
> transactions.
> 
> Boot stub provides own implementation of tdx_accept_memory(). It is
> similar in structure to tdx_enc_status_changed(), but only cares about
> converting memory to private.
> 
> Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> ---
>  arch/x86/Kconfig                  |  1 +
>  arch/x86/boot/compressed/mem.c    | 24 ++++++++-
>  arch/x86/boot/compressed/tdx.c    | 85 +++++++++++++++++++++++++++++++
>  arch/x86/coco/tdx/tdx.c           | 31 +++++++----
>  arch/x86/include/asm/shared/tdx.h |  2 +
>  arch/x86/mm/unaccepted_memory.c   |  9 +++-
>  6 files changed, 141 insertions(+), 11 deletions(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 7021ec725dd3..e4c31dbea6d7 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -885,6 +885,7 @@ config INTEL_TDX_GUEST
>  	select ARCH_HAS_CC_PLATFORM
>  	select X86_MEM_ENCRYPT
>  	select X86_MCE
> +	select UNACCEPTED_MEMORY

WARNING: unmet direct dependencies detected for UNACCEPTED_MEMORY
  Depends on [n]: EFI [=y] && EFI_STUB [=y] && !KEXEC_CORE [=y]
  Selected by [y]:
  - INTEL_TDX_GUEST [=y] && HYPERVISOR_GUEST [=y] && X86_64 [=y] && CPU_SUP_INTEL [=y] && X86_X2APIC [=y]

WARNING: unmet direct dependencies detected for UNACCEPTED_MEMORY
  Depends on [n]: EFI [=y] && EFI_STUB [=y] && !KEXEC_CORE [=y]
  Selected by [y]:
  - INTEL_TDX_GUEST [=y] && HYPERVISOR_GUEST [=y] && X86_64 [=y] && CPU_SUP_INTEL [=y] && X86_X2APIC [=y]


> diff --git a/arch/x86/boot/compressed/mem.c b/arch/x86/boot/compressed/mem.c
> index b5058c975d26..539fff27de49 100644
> --- a/arch/x86/boot/compressed/mem.c
> +++ b/arch/x86/boot/compressed/mem.c
> @@ -5,6 +5,8 @@
>  #include "error.h"
>  #include "find.h"
>  #include "math.h"
> +#include "tdx.h"
> +#include <asm/shared/tdx.h>
>  
>  #define PMD_SHIFT	21
>  #define PMD_SIZE	(_AC(1, UL) << PMD_SHIFT)
> @@ -12,10 +14,30 @@
>  
>  extern struct boot_params *boot_params;
>  
> +static bool is_tdx_guest(void)

There is arch/x86/boot/compressed/tdx.c which already looks at that leaf
and detects crap. Why is that hastily slapped here too?

> +{
> +	static bool once;
> +	static bool is_tdx;
> +
> +	if (!once) {
> +		u32 eax, sig[3];
> +
> +		cpuid_count(TDX_CPUID_LEAF_ID, 0, &eax,
> +			    &sig[0], &sig[2],  &sig[1]);
> +		is_tdx = !memcmp(TDX_IDENT, sig, sizeof(sig));
> +		once = true;
> +	}
> +
> +	return is_tdx;
> +}
> +
>  static inline void __accept_memory(phys_addr_t start, phys_addr_t end)
>  {
>  	/* Platform-specific memory-acceptance call goes here */
> -	error("Cannot accept memory");
> +	if (is_tdx_guest())
> +		tdx_accept_memory(start, end);
> +	else
> +		error("Cannot accept memory");

What is that supposed to catch?

> diff --git a/arch/x86/boot/compressed/tdx.c b/arch/x86/boot/compressed/tdx.c
> index 918a7606f53c..57fd2bf28484 100644
> --- a/arch/x86/boot/compressed/tdx.c
> +++ b/arch/x86/boot/compressed/tdx.c
> @@ -3,12 +3,14 @@
>  #include "../cpuflags.h"
>  #include "../string.h"
>  #include "../io.h"
> +#include "align.h"
>  #include "error.h"
>  
>  #include <vdso/limits.h>
>  #include <uapi/asm/vmx.h>
>  
>  #include <asm/shared/tdx.h>
> +#include <asm/page_types.h>
>  
>  /* Called from __tdx_hypercall() for unrecoverable failure */
>  void __tdx_hypercall_failed(void)
> @@ -75,3 +77,86 @@ void early_tdx_detect(void)
>  	pio_ops.f_outb = tdx_outb;
>  	pio_ops.f_outw = tdx_outw;
>  }
> +
> +enum pg_level {
> +	PG_LEVEL_4K,
> +	PG_LEVEL_2M,
> +	PG_LEVEL_1G,
> +};
> +
> +#define PTE_SHIFT 9

At least stick those in a header.

> +static bool try_accept_one(phys_addr_t *start, unsigned long len,
> +			  enum pg_level pg_level)

No need to break that line.

Also, it doesn't need to be bool - you can simply return accept_size on
success and 0 on error so that you don't have an I/O argument.

Ditto for the copy in coco/tdx/tdx.c

> +{
> +	unsigned long accept_size = PAGE_SIZE << (pg_level * PTE_SHIFT);
> +	u64 tdcall_rcx;
> +	u8 page_size;
> +
> +	if (!IS_ALIGNED(*start, accept_size))
> +		return false;
> +
> +	if (len < accept_size)
> +		return false;
> +
> +	/*
> +	 * Pass the page physical address to the TDX module to accept the
> +	 * pending, private page.
> +	 *
> +	 * Bits 2:0 of RCX encode page size: 0 - 4K, 1 - 2M, 2 - 1G.
> +	 */
> +	switch (pg_level) {
> +	case PG_LEVEL_4K:
> +		page_size = 0;
> +		break;
> +	case PG_LEVEL_2M:
> +		page_size = 1;
> +		break;
> +	case PG_LEVEL_1G:
> +		page_size = 2;
> +		break;
> +	default:
> +		return false;
> +	}
> +
> +	tdcall_rcx = *start | page_size;
> +	if (__tdx_module_call(TDX_ACCEPT_PAGE, tdcall_rcx, 0, 0, 0, NULL))
> +		return false;
> +
> +	*start += accept_size;
> +	return true;
> +}
> +
> +void tdx_accept_memory(phys_addr_t start, phys_addr_t end)
> +{
> +	/*
> +	 * Notify the VMM about page mapping conversion. More info about ABI
> +	 * can be found in TDX Guest-Host-Communication Interface (GHCI),
> +	 * section "TDG.VP.VMCALL<MapGPA>"
> +	 */
> +	if (_tdx_hypercall(TDVMCALL_MAP_GPA, start, end - start, 0, 0))
> +		error("Accepting memory failed\n");
> +	/*
> +	 * For shared->private conversion, accept the page using
> +	 * TDX_ACCEPT_PAGE TDX module call.
> +	 */
> +	while (start < end) {
> +		unsigned long len = end - start;
> +
> +		/*
> +		 * Try larger accepts first. It gives chance to VMM to keep
> +		 * 1G/2M SEPT entries where possible and speeds up process by

"SEPT"?

> +		 * cutting number of hypercalls (if successful).
> +		 */
> +
> +		if (try_accept_one(&start, len, PG_LEVEL_1G))
> +			continue;
> +
> +		if (try_accept_one(&start, len, PG_LEVEL_2M))
> +			continue;
> +
> +		if (!try_accept_one(&start, len, PG_LEVEL_4K))
> +			error("Accepting memory failed\n");
> +	}
> +}
> diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c
> index ddb60a87b426..ab4deb897942 100644
> --- a/arch/x86/coco/tdx/tdx.c
> +++ b/arch/x86/coco/tdx/tdx.c
> @@ -580,16 +580,9 @@ static bool try_accept_one(phys_addr_t *start, unsigned long len,
>  	return true;
>  }
>  
> -/*
> - * Inform the VMM of the guest's intent for this physical page: shared with
> - * the VMM or private to the guest.  The VMM is expected to change its mapping
> - * of the page in response.
> - */
> -static bool tdx_enc_status_changed(unsigned long vaddr, int numpages, bool enc)
> +static bool tdx_enc_status_changed_phys(phys_addr_t start, phys_addr_t end,

Why? is tdx_enc_status_changed_virt() coming too?

> +					bool enc)
>  {
> -	phys_addr_t start = __pa(vaddr);
> -	phys_addr_t end   = __pa(vaddr + numpages * PAGE_SIZE);
> -
>  	if (!enc) {
>  		/* Set the shared (decrypted) bits: */
>  		start |= cc_mkdec(0);
> @@ -634,6 +627,25 @@ static bool tdx_enc_status_changed(unsigned long vaddr, int numpages, bool enc)
>  	return true;
>  }
>  
> +void tdx_accept_memory(phys_addr_t start, phys_addr_t end)
> +{
> +	if (!tdx_enc_status_changed_phys(start, end, true))
> +		panic("Accepting memory failed\n");
> +}
> +
> +/*
> + * Inform the VMM of the guest's intent for this physical page: shared with
> + * the VMM or private to the guest.  The VMM is expected to change its mapping
> + * of the page in response.
> + */
> +static bool tdx_enc_status_changed(unsigned long vaddr, int numpages, bool enc)
> +{
> +	phys_addr_t start = __pa(vaddr);
> +	phys_addr_t end = __pa(vaddr + numpages * PAGE_SIZE);
> +
> +	return tdx_enc_status_changed_phys(start, end, enc);
> +}
> +
>  void __init tdx_early_init(void)
>  {
>  	u64 cc_mask;
> @@ -645,6 +657,7 @@ void __init tdx_early_init(void)
>  		return;
>  
>  	setup_force_cpu_cap(X86_FEATURE_TDX_GUEST);
> +	setup_clear_cpu_cap(X86_FEATURE_MCE);

What, no comment? Why does TDX need to disable MCE?

>  	cc_set_vendor(CC_VENDOR_INTEL);
>  	cc_mask = get_cc_mask();
> diff --git a/arch/x86/include/asm/shared/tdx.h b/arch/x86/include/asm/shared/tdx.h
> index 956ced04c3be..97534c334473 100644
> --- a/arch/x86/include/asm/shared/tdx.h
> +++ b/arch/x86/include/asm/shared/tdx.h
> @@ -81,5 +81,7 @@ struct tdx_module_output {
>  u64 __tdx_module_call(u64 fn, u64 rcx, u64 rdx, u64 r8, u64 r9,
>  		      struct tdx_module_output *out);
>  
> +void tdx_accept_memory(phys_addr_t start, phys_addr_t end);
> +
>  #endif /* !__ASSEMBLY__ */
>  #endif /* _ASM_X86_SHARED_TDX_H */
> diff --git a/arch/x86/mm/unaccepted_memory.c b/arch/x86/mm/unaccepted_memory.c
> index 1327f64d5205..de0790af1824 100644
> --- a/arch/x86/mm/unaccepted_memory.c
> +++ b/arch/x86/mm/unaccepted_memory.c
> @@ -6,6 +6,7 @@
>  
>  #include <asm/io.h>
>  #include <asm/setup.h>
> +#include <asm/shared/tdx.h>
>  #include <asm/unaccepted_memory.h>
>  
>  /* Protects unaccepted memory bitmap */
> @@ -29,7 +30,13 @@ void accept_memory(phys_addr_t start, phys_addr_t end)
>  		unsigned long len = range_end - range_start;
>  
>  		/* Platform-specific memory-acceptance call goes here */
> -		panic("Cannot accept memory");
> +		if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST)) {
> +			tdx_accept_memory(range_start * PMD_SIZE,
> +					  range_end * PMD_SIZE);
> +		} else {
> +			panic("Cannot accept memory");

Why panic here? A WARN_ONCE() should suffice, methinks.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 02/12] mm: Add support for unaccepted memory
  2022-05-03 20:21   ` David Hildenbrand
@ 2022-05-06  0:54     ` Kirill A. Shutemov
  0 siblings, 0 replies; 58+ messages in thread
From: Kirill A. Shutemov @ 2022-05-06  0:54 UTC (permalink / raw)
  To: David Hildenbrand
  Cc: Kirill A. Shutemov, Borislav Petkov, Andy Lutomirski,
	Sean Christopherson, Andrew Morton, Joerg Roedel, Ard Biesheuvel,
	Andi Kleen, Kuppuswamy Sathyanarayanan, David Rientjes,
	Vlastimil Babka, Tom Lendacky, Thomas Gleixner, Peter Zijlstra,
	Paolo Bonzini, Ingo Molnar, Varad Gautam, Dario Faggioli,
	Dave Hansen, Brijesh Singh, Mike Rapoport, x86, linux-mm,
	linux-coco, linux-efi, linux-kernel, Mike Rapoport

On Tue, May 03, 2022 at 10:21:03PM +0200, David Hildenbrand wrote:
> 
> >  
> > +/*
> > + * Page acceptance can be very slow. Do not call under critical locks.
> > + */
> > +static void accept_page(struct page *page, unsigned int order)
> > +{
> > +	phys_addr_t start = page_to_phys(page);
> > +	int i;
> > +
> > +	accept_memory(start, start + (PAGE_SIZE << order));
> > +
> > +	for (i = 0; i < (1 << order); i++) {
> > +		if (PageUnaccepted(page + i))
> > +			__ClearPageUnaccepted(page + i);
> > +	}
> > +}
> 
> What was the rationale of leaving PageUnaccepted() set on sub-pages when
> merging pages?
> 
> I'd just clear the flag when merging and avoid the loop here. You could
> even assert here that we don't have any PageUnaccepted() on tail pages.

Okay, fair enough. I will change the code.

-- 
 Kirill A. Shutemov

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 06/12] x86/boot/compressed: Handle unaccepted memory
  2022-05-03 14:12   ` Borislav Petkov
@ 2022-05-06 15:30     ` Kirill A. Shutemov
  2022-05-10 11:03       ` Borislav Petkov
  0 siblings, 1 reply; 58+ messages in thread
From: Kirill A. Shutemov @ 2022-05-06 15:30 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Kirill A. Shutemov, Andy Lutomirski, Sean Christopherson,
	Andrew Morton, Joerg Roedel, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Dave Hansen,
	Brijesh Singh, Mike Rapoport, David Hildenbrand, x86, linux-mm,
	linux-coco, linux-efi, linux-kernel

On Tue, May 03, 2022 at 04:12:55PM +0200, Borislav Petkov wrote:
> On Mon, Apr 25, 2022 at 06:39:28AM +0300, Kirill A. Shutemov wrote:
> > diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
> > index 411b268bc0a2..59db90626042 100644
> > --- a/arch/x86/boot/compressed/kaslr.c
> > +++ b/arch/x86/boot/compressed/kaslr.c
> > @@ -725,10 +725,20 @@ process_efi_entries(unsigned long minimum, unsigned long image_size)
> >  		 * but in practice there's firmware where using that memory leads
> >  		 * to crashes.
> >  		 *
> > -		 * Only EFI_CONVENTIONAL_MEMORY is guaranteed to be free.
> > +		 * Only EFI_CONVENTIONAL_MEMORY and EFI_UNACCEPTED_MEMORY (if
> > +		 * supported) are guaranteed to be free.
> >  		 */
> > -		if (md->type != EFI_CONVENTIONAL_MEMORY)
> > +
> > +		switch (md->type) {
> > +		case EFI_CONVENTIONAL_MEMORY:
> > +			break;
> > +		case EFI_UNACCEPTED_MEMORY:
> > +			if (IS_ENABLED(CONFIG_UNACCEPTED_MEMORY))
> > +				break;
> >  			continue;
> > +		default:
> > +			continue;
> > +		}
> 
> Is there any special reason for this to be a switch-case or can it
> simply be a compound conditional if (bla...) ?

The equivalent 'if' statement is something like:

		if (md->type != EFI_CONVENTIONAL_MEMORY &&
		    !(md->type == EFI_UNACCEPTED_MEMORY && IS_ENABLED(CONFIG_UNACCEPTED_MEMORY)))
		    continue;

I find it harder to follow.

Do you want me to change to the 'if' anyway?

-- 
 Kirill A. Shutemov

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 08/12] x86/mm: Provide helpers for unaccepted memory
  2022-05-04 11:12   ` Borislav Petkov
@ 2022-05-06 16:13     ` Kirill A. Shutemov
  2022-05-10 18:32       ` Borislav Petkov
  0 siblings, 1 reply; 58+ messages in thread
From: Kirill A. Shutemov @ 2022-05-06 16:13 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Kirill A. Shutemov, Andy Lutomirski, Sean Christopherson,
	Andrew Morton, Joerg Roedel, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Dave Hansen,
	Brijesh Singh, Mike Rapoport, David Hildenbrand, x86, linux-mm,
	linux-coco, linux-efi, linux-kernel

On Wed, May 04, 2022 at 01:12:06PM +0200, Borislav Petkov wrote:
> On Mon, Apr 25, 2022 at 06:39:30AM +0300, Kirill A. Shutemov wrote:
> > +	unaccepted_memory = __va(boot_params.unaccepted_memory);
> > +	range_start = start / PMD_SIZE;
> > +
> > +	spin_lock_irqsave(&unaccepted_memory_lock, flags);
> > +	for_each_set_bitrange_from(range_start, range_end, unaccepted_memory,
> > +				   DIV_ROUND_UP(end, PMD_SIZE)) {
> > +		unsigned long len = range_end - range_start;
> > +
> > +		/* Platform-specific memory-acceptance call goes here */
> > +		panic("Cannot accept memory");
> 
> Yeah, no, WARN_ON_ONCE() pls.

Failure to accept the memory is fatal. Why pretend it is not?

For TDX it will result in a crash on the first access. Prolonging the
suffering just make it harder to understand what happened.

> > +	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;
> 
> Wait, what?
> 
> That thing is lying: it'll return true for *some* PMD which is accepted
> but not the whole range of [start, end].

That's true. Note also that the check is inherently racy. Other CPU can
get the range or subrange accepted just after spin_unlock().

The check indicates that accept_memory() has to be called on the range
before first access.

Do you have problem with a name? Maybe has_unaccepted_memory()?

-- 
 Kirill A. Shutemov

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 10/12] x86/tdx: Unaccepted memory support
  2022-05-05 10:12   ` Borislav Petkov
@ 2022-05-06 20:44     ` Kirill A. Shutemov
  2022-05-11  1:19       ` Kirill A. Shutemov
  0 siblings, 1 reply; 58+ messages in thread
From: Kirill A. Shutemov @ 2022-05-06 20:44 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Kirill A. Shutemov, Andy Lutomirski, Sean Christopherson,
	Andrew Morton, Joerg Roedel, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Dave Hansen,
	Brijesh Singh, Mike Rapoport, David Hildenbrand, x86, linux-mm,
	linux-coco, linux-efi, linux-kernel

On Thu, May 05, 2022 at 12:12:52PM +0200, Borislav Petkov wrote:
> On Mon, Apr 25, 2022 at 06:39:32AM +0300, Kirill A. Shutemov wrote:
> > Subject: [PATCHv5 10/12] x86/tdx: Unaccepted memory support
> 
> Patch subject needs a verb:
> 
> "Add ... "
> 
> > All preparations are complete.
> 
> Drop this sentence.
> 
> > Hookup TDX-specific code to accept memory.
> > 
> > Accepting the memory is the same process as converting memory from
> > shared to private: kernel notifies VMM with MAP_GPA hypercall and then
> > accept pages with ACCEPT_PAGE module call.
> > 
> > The implementation in core kernel uses tdx_enc_status_changed(). It
> > already used for converting memory to shared and back for I/O
> > transactions.
> > 
> > Boot stub provides own implementation of tdx_accept_memory(). It is
> > similar in structure to tdx_enc_status_changed(), but only cares about
> > converting memory to private.
> > 
> > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> > ---
> >  arch/x86/Kconfig                  |  1 +
> >  arch/x86/boot/compressed/mem.c    | 24 ++++++++-
> >  arch/x86/boot/compressed/tdx.c    | 85 +++++++++++++++++++++++++++++++
> >  arch/x86/coco/tdx/tdx.c           | 31 +++++++----
> >  arch/x86/include/asm/shared/tdx.h |  2 +
> >  arch/x86/mm/unaccepted_memory.c   |  9 +++-
> >  6 files changed, 141 insertions(+), 11 deletions(-)
> > 
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index 7021ec725dd3..e4c31dbea6d7 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -885,6 +885,7 @@ config INTEL_TDX_GUEST
> >  	select ARCH_HAS_CC_PLATFORM
> >  	select X86_MEM_ENCRYPT
> >  	select X86_MCE
> > +	select UNACCEPTED_MEMORY
> 
> WARNING: unmet direct dependencies detected for UNACCEPTED_MEMORY
>   Depends on [n]: EFI [=y] && EFI_STUB [=y] && !KEXEC_CORE [=y]
>   Selected by [y]:
>   - INTEL_TDX_GUEST [=y] && HYPERVISOR_GUEST [=y] && X86_64 [=y] && CPU_SUP_INTEL [=y] && X86_X2APIC [=y]
> 
> WARNING: unmet direct dependencies detected for UNACCEPTED_MEMORY
>   Depends on [n]: EFI [=y] && EFI_STUB [=y] && !KEXEC_CORE [=y]
>   Selected by [y]:
>   - INTEL_TDX_GUEST [=y] && HYPERVISOR_GUEST [=y] && X86_64 [=y] && CPU_SUP_INTEL [=y] && X86_X2APIC [=y]

Ughh. Any ideas how to get around it? (Except for implementing kexec
support right away?)
> 
> 
> > diff --git a/arch/x86/boot/compressed/mem.c b/arch/x86/boot/compressed/mem.c
> > index b5058c975d26..539fff27de49 100644
> > --- a/arch/x86/boot/compressed/mem.c
> > +++ b/arch/x86/boot/compressed/mem.c
> > @@ -5,6 +5,8 @@
> >  #include "error.h"
> >  #include "find.h"
> >  #include "math.h"
> > +#include "tdx.h"
> > +#include <asm/shared/tdx.h>
> >  
> >  #define PMD_SHIFT	21
> >  #define PMD_SIZE	(_AC(1, UL) << PMD_SHIFT)
> > @@ -12,10 +14,30 @@
> >  
> >  extern struct boot_params *boot_params;
> >  
> > +static bool is_tdx_guest(void)
> 
> There is arch/x86/boot/compressed/tdx.c which already looks at that leaf
> and detects crap. Why is that hastily slapped here too?

I'm not happhy with this too.

process_unaccepted_memory() called form EFI stub that called before
decompression code.

I'm not sure how to structure code that it makes sense.

Call early_tdx_detect() from efi_main() in libstub/x86-stub.c?
It would require to include tdx.h from decompression code there which is
non-sense.

I would appreciate an idea.

> > +{
> > +	static bool once;
> > +	static bool is_tdx;
> > +
> > +	if (!once) {
> > +		u32 eax, sig[3];
> > +
> > +		cpuid_count(TDX_CPUID_LEAF_ID, 0, &eax,
> > +			    &sig[0], &sig[2],  &sig[1]);
> > +		is_tdx = !memcmp(TDX_IDENT, sig, sizeof(sig));
> > +		once = true;
> > +	}
> > +
> > +	return is_tdx;
> > +}
> > +
> >  static inline void __accept_memory(phys_addr_t start, phys_addr_t end)
> >  {
> >  	/* Platform-specific memory-acceptance call goes here */
> > -	error("Cannot accept memory");
> > +	if (is_tdx_guest())
> > +		tdx_accept_memory(start, end);
> > +	else
> > +		error("Cannot accept memory");
> 
> What is that supposed to catch?

Booting on a platform that uses unaccepted memory, but kernel doesn't not
support it.

> > diff --git a/arch/x86/boot/compressed/tdx.c b/arch/x86/boot/compressed/tdx.c
> > index 918a7606f53c..57fd2bf28484 100644
> > --- a/arch/x86/boot/compressed/tdx.c
> > +++ b/arch/x86/boot/compressed/tdx.c
> > @@ -3,12 +3,14 @@
> >  #include "../cpuflags.h"
> >  #include "../string.h"
> >  #include "../io.h"
> > +#include "align.h"
> >  #include "error.h"
> >  
> >  #include <vdso/limits.h>
> >  #include <uapi/asm/vmx.h>
> >  
> >  #include <asm/shared/tdx.h>
> > +#include <asm/page_types.h>
> >  
> >  /* Called from __tdx_hypercall() for unrecoverable failure */
> >  void __tdx_hypercall_failed(void)
> > @@ -75,3 +77,86 @@ void early_tdx_detect(void)
> >  	pio_ops.f_outb = tdx_outb;
> >  	pio_ops.f_outw = tdx_outw;
> >  }
> > +
> > +enum pg_level {
> > +	PG_LEVEL_4K,
> > +	PG_LEVEL_2M,
> > +	PG_LEVEL_1G,
> > +};
> > +
> > +#define PTE_SHIFT 9
> 
> At least stick those in a header.
> 
> > +static bool try_accept_one(phys_addr_t *start, unsigned long len,
> > +			  enum pg_level pg_level)
> 
> No need to break that line.
> 
> Also, it doesn't need to be bool - you can simply return accept_size on
> success and 0 on error so that you don't have an I/O argument.

So on the calling side it would look like:

	accepted = try_accept_one(start, len, PG_LEVEL_1G)
	if (accepted) {
		start += accepted;
		continue;
	}

And the similar for other levels. Is it really better?

> 
> Ditto for the copy in coco/tdx/tdx.c
> 
> > +{
> > +	unsigned long accept_size = PAGE_SIZE << (pg_level * PTE_SHIFT);
> > +	u64 tdcall_rcx;
> > +	u8 page_size;
> > +
> > +	if (!IS_ALIGNED(*start, accept_size))
> > +		return false;
> > +
> > +	if (len < accept_size)
> > +		return false;
> > +
> > +	/*
> > +	 * Pass the page physical address to the TDX module to accept the
> > +	 * pending, private page.
> > +	 *
> > +	 * Bits 2:0 of RCX encode page size: 0 - 4K, 1 - 2M, 2 - 1G.
> > +	 */
> > +	switch (pg_level) {
> > +	case PG_LEVEL_4K:
> > +		page_size = 0;
> > +		break;
> > +	case PG_LEVEL_2M:
> > +		page_size = 1;
> > +		break;
> > +	case PG_LEVEL_1G:
> > +		page_size = 2;
> > +		break;
> > +	default:
> > +		return false;
> > +	}
> > +
> > +	tdcall_rcx = *start | page_size;
> > +	if (__tdx_module_call(TDX_ACCEPT_PAGE, tdcall_rcx, 0, 0, 0, NULL))
> > +		return false;
> > +
> > +	*start += accept_size;
> > +	return true;
> > +}
> > +
> > +void tdx_accept_memory(phys_addr_t start, phys_addr_t end)
> > +{
> > +	/*
> > +	 * Notify the VMM about page mapping conversion. More info about ABI
> > +	 * can be found in TDX Guest-Host-Communication Interface (GHCI),
> > +	 * section "TDG.VP.VMCALL<MapGPA>"
> > +	 */
> > +	if (_tdx_hypercall(TDVMCALL_MAP_GPA, start, end - start, 0, 0))
> > +		error("Accepting memory failed\n");
> > +	/*
> > +	 * For shared->private conversion, accept the page using
> > +	 * TDX_ACCEPT_PAGE TDX module call.
> > +	 */
> > +	while (start < end) {
> > +		unsigned long len = end - start;
> > +
> > +		/*
> > +		 * Try larger accepts first. It gives chance to VMM to keep
> > +		 * 1G/2M SEPT entries where possible and speeds up process by
> 
> "SEPT"?

Secure EPT. EPT for private memory in TDX.

> > +		 * cutting number of hypercalls (if successful).
> > +		 */
> > +
> > +		if (try_accept_one(&start, len, PG_LEVEL_1G))
> > +			continue;
> > +
> > +		if (try_accept_one(&start, len, PG_LEVEL_2M))
> > +			continue;
> > +
> > +		if (!try_accept_one(&start, len, PG_LEVEL_4K))
> > +			error("Accepting memory failed\n");
> > +	}
> > +}
> > diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c
> > index ddb60a87b426..ab4deb897942 100644
> > --- a/arch/x86/coco/tdx/tdx.c
> > +++ b/arch/x86/coco/tdx/tdx.c
> > @@ -580,16 +580,9 @@ static bool try_accept_one(phys_addr_t *start, unsigned long len,
> >  	return true;
> >  }
> >  
> > -/*
> > - * Inform the VMM of the guest's intent for this physical page: shared with
> > - * the VMM or private to the guest.  The VMM is expected to change its mapping
> > - * of the page in response.
> > - */
> > -static bool tdx_enc_status_changed(unsigned long vaddr, int numpages, bool enc)
> > +static bool tdx_enc_status_changed_phys(phys_addr_t start, phys_addr_t end,
> 
> Why? is tdx_enc_status_changed_virt() coming too?

tdx_enc_status_changed() deals with virtual addresses.

> > +					bool enc)
> >  {
> > -	phys_addr_t start = __pa(vaddr);
> > -	phys_addr_t end   = __pa(vaddr + numpages * PAGE_SIZE);
> > -
> >  	if (!enc) {
> >  		/* Set the shared (decrypted) bits: */
> >  		start |= cc_mkdec(0);
> > @@ -634,6 +627,25 @@ static bool tdx_enc_status_changed(unsigned long vaddr, int numpages, bool enc)
> >  	return true;
> >  }
> >  
> > +void tdx_accept_memory(phys_addr_t start, phys_addr_t end)
> > +{
> > +	if (!tdx_enc_status_changed_phys(start, end, true))
> > +		panic("Accepting memory failed\n");
> > +}
> > +
> > +/*
> > + * Inform the VMM of the guest's intent for this physical page: shared with
> > + * the VMM or private to the guest.  The VMM is expected to change its mapping
> > + * of the page in response.
> > + */
> > +static bool tdx_enc_status_changed(unsigned long vaddr, int numpages, bool enc)
> > +{
> > +	phys_addr_t start = __pa(vaddr);
> > +	phys_addr_t end = __pa(vaddr + numpages * PAGE_SIZE);
> > +
> > +	return tdx_enc_status_changed_phys(start, end, enc);
> > +}
> > +
> >  void __init tdx_early_init(void)
> >  {
> >  	u64 cc_mask;
> > @@ -645,6 +657,7 @@ void __init tdx_early_init(void)
> >  		return;
> >  
> >  	setup_force_cpu_cap(X86_FEATURE_TDX_GUEST);
> > +	setup_clear_cpu_cap(X86_FEATURE_MCE);
> 
> What, no comment? Why does TDX need to disable MCE?

It doesn't not suppose to be here. Sorry.

> 
> >  	cc_set_vendor(CC_VENDOR_INTEL);
> >  	cc_mask = get_cc_mask();
> > diff --git a/arch/x86/include/asm/shared/tdx.h b/arch/x86/include/asm/shared/tdx.h
> > index 956ced04c3be..97534c334473 100644
> > --- a/arch/x86/include/asm/shared/tdx.h
> > +++ b/arch/x86/include/asm/shared/tdx.h
> > @@ -81,5 +81,7 @@ struct tdx_module_output {
> >  u64 __tdx_module_call(u64 fn, u64 rcx, u64 rdx, u64 r8, u64 r9,
> >  		      struct tdx_module_output *out);
> >  
> > +void tdx_accept_memory(phys_addr_t start, phys_addr_t end);
> > +
> >  #endif /* !__ASSEMBLY__ */
> >  #endif /* _ASM_X86_SHARED_TDX_H */
> > diff --git a/arch/x86/mm/unaccepted_memory.c b/arch/x86/mm/unaccepted_memory.c
> > index 1327f64d5205..de0790af1824 100644
> > --- a/arch/x86/mm/unaccepted_memory.c
> > +++ b/arch/x86/mm/unaccepted_memory.c
> > @@ -6,6 +6,7 @@
> >  
> >  #include <asm/io.h>
> >  #include <asm/setup.h>
> > +#include <asm/shared/tdx.h>
> >  #include <asm/unaccepted_memory.h>
> >  
> >  /* Protects unaccepted memory bitmap */
> > @@ -29,7 +30,13 @@ void accept_memory(phys_addr_t start, phys_addr_t end)
> >  		unsigned long len = range_end - range_start;
> >  
> >  		/* Platform-specific memory-acceptance call goes here */
> > -		panic("Cannot accept memory");
> > +		if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST)) {
> > +			tdx_accept_memory(range_start * PMD_SIZE,
> > +					  range_end * PMD_SIZE);
> > +		} else {
> > +			panic("Cannot accept memory");
> 
> Why panic here? A WARN_ONCE() should suffice, methinks.

As I said before, memory accept failure is fatal.

-- 
 Kirill A. Shutemov

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 06/12] x86/boot/compressed: Handle unaccepted memory
  2022-05-06 15:30     ` Kirill A. Shutemov
@ 2022-05-10 11:03       ` Borislav Petkov
  2022-05-13  5:31         ` Dionna Amalie Glaze
  2022-05-13  5:34         ` Dionna Amalie Glaze
  0 siblings, 2 replies; 58+ messages in thread
From: Borislav Petkov @ 2022-05-10 11:03 UTC (permalink / raw)
  To: Kirill A. Shutemov
  Cc: Kirill A. Shutemov, Andy Lutomirski, Sean Christopherson,
	Andrew Morton, Joerg Roedel, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Dave Hansen,
	Brijesh Singh, Mike Rapoport, David Hildenbrand, x86, linux-mm,
	linux-coco, linux-efi, linux-kernel

On Fri, May 06, 2022 at 06:30:13PM +0300, Kirill A. Shutemov wrote:
> I find it harder to follow.

If in doubt, always consider using a helper function:

---

diff --git a/arch/x86/boot/compressed/efi.h b/arch/x86/boot/compressed/efi.h
index 7db2f41b54cd..cf475243b6d5 100644
--- a/arch/x86/boot/compressed/efi.h
+++ b/arch/x86/boot/compressed/efi.h
@@ -32,6 +32,7 @@ typedef	struct {
 } efi_table_hdr_t;
 
 #define EFI_CONVENTIONAL_MEMORY		 7
+#define EFI_UNACCEPTED_MEMORY		15
 
 #define EFI_MEMORY_MORE_RELIABLE \
 				((u64)0x0000000000010000ULL)	/* higher reliability */
diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
index 28b91df9d31e..39bb4c319dfc 100644
--- a/arch/x86/boot/compressed/kaslr.c
+++ b/arch/x86/boot/compressed/kaslr.c
@@ -671,6 +671,23 @@ static bool process_mem_region(struct mem_vector *region,
 }
 
 #ifdef CONFIG_EFI
+
+/*
+ * Only EFI_CONVENTIONAL_MEMORY and EFI_UNACCEPTED_MEMORY (if supported) are guaranteed
+ * to be free.
+ */
+static inline bool memory_type_is_free(efi_memory_desc_t *md)
+{
+	if (md->type == EFI_CONVENTIONAL_MEMORY)
+		return true;
+
+	if (IS_ENABLED(CONFIG_UNACCEPTED_MEMORY))
+		if (md->type == EFI_UNACCEPTED_MEMORY)
+			return true;
+
+	return false;
+}
+
 /*
  * Returns true if we processed the EFI memmap, which we prefer over the E820
  * table if it is available.
@@ -723,21 +740,9 @@ process_efi_entries(unsigned long minimum, unsigned long image_size)
 		 * free memory and thus available to place the kernel image into,
 		 * but in practice there's firmware where using that memory leads
 		 * to crashes.
-		 *
-		 * Only EFI_CONVENTIONAL_MEMORY and EFI_UNACCEPTED_MEMORY (if
-		 * supported) are guaranteed to be free.
 		 */
-
-		switch (md->type) {
-		case EFI_CONVENTIONAL_MEMORY:
-			break;
-		case EFI_UNACCEPTED_MEMORY:
-			if (IS_ENABLED(CONFIG_UNACCEPTED_MEMORY))
-				break;
+		if (!memory_type_is_free(md))
 			continue;
-		default:
-			continue;
-		}
 
 		if (efi_soft_reserve_enabled() &&
 		    (md->attribute & EFI_MEMORY_SP))
-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply related	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 08/12] x86/mm: Provide helpers for unaccepted memory
  2022-05-06 16:13     ` Kirill A. Shutemov
@ 2022-05-10 18:32       ` Borislav Petkov
  2022-05-11  1:15         ` Kirill A. Shutemov
  0 siblings, 1 reply; 58+ messages in thread
From: Borislav Petkov @ 2022-05-10 18:32 UTC (permalink / raw)
  To: Kirill A. Shutemov
  Cc: Kirill A. Shutemov, Andy Lutomirski, Sean Christopherson,
	Andrew Morton, Joerg Roedel, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Dave Hansen,
	Brijesh Singh, Mike Rapoport, David Hildenbrand, x86, linux-mm,
	linux-coco, linux-efi, linux-kernel

On Fri, May 06, 2022 at 07:13:59PM +0300, Kirill A. Shutemov wrote:
> Failure to accept the memory is fatal. Why pretend it is not?
> 
> For TDX it will result in a crash on the first access. Prolonging the
> suffering just make it harder to understand what happened.

Ok then. Does that panic message contain enough info so that the
acceptance failure can be debugged?

Just "Cannot accept memory" doesn't seem very helpful to me...

> That's true. Note also that the check is inherently racy. Other CPU can
> get the range or subrange accepted just after spin_unlock().
> 
> The check indicates that accept_memory() has to be called on the range
> before first access.
> 
> Do you have problem with a name? Maybe has_unaccepted_memory()?

I have a problem with the definition of this function, what it is
supposed to do and how it is supposed to be used.

Right now, it looks weird and strange: is it supposed to check for *all*
in-between (start, end)? It doesn't, atm, so what's the meaning of
@start and @end then at all?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 08/12] x86/mm: Provide helpers for unaccepted memory
  2022-05-10 18:32       ` Borislav Petkov
@ 2022-05-11  1:15         ` Kirill A. Shutemov
  2022-05-11  9:07           ` Borislav Petkov
  0 siblings, 1 reply; 58+ messages in thread
From: Kirill A. Shutemov @ 2022-05-11  1:15 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Kirill A. Shutemov, Andy Lutomirski, Sean Christopherson,
	Andrew Morton, Joerg Roedel, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Dave Hansen,
	Brijesh Singh, Mike Rapoport, David Hildenbrand, x86, linux-mm,
	linux-coco, linux-efi, linux-kernel

On Tue, May 10, 2022 at 08:32:23PM +0200, Borislav Petkov wrote:
> On Fri, May 06, 2022 at 07:13:59PM +0300, Kirill A. Shutemov wrote:
> > Failure to accept the memory is fatal. Why pretend it is not?
> > 
> > For TDX it will result in a crash on the first access. Prolonging the
> > suffering just make it harder to understand what happened.
> 
> Ok then. Does that panic message contain enough info so that the
> acceptance failure can be debugged?
> 
> Just "Cannot accept memory" doesn't seem very helpful to me...

Okay. Fair enough. I will change it to

			panic("Cannot accept memory: unknown platform.");

> 
> > That's true. Note also that the check is inherently racy. Other CPU can
> > get the range or subrange accepted just after spin_unlock().
> > 
> > The check indicates that accept_memory() has to be called on the range
> > before first access.
> > 
> > Do you have problem with a name? Maybe has_unaccepted_memory()?
> 
> I have a problem with the definition of this function, what it is
> supposed to do and how it is supposed to be used.
> 
> Right now, it looks weird and strange: is it supposed to check for *all*
> in-between (start, end)? It doesn't, atm, so what's the meaning of
> @start and @end then at all?

It checks if the range of memory requires accept_memory() call before it
can be accessed.

If any part of the range is not accepted, the call is required.
accept_memory() knows what exactly has to be done. Note that
accept_memory() call is harmless for any valid memory range.
It can be called on already accepted memory.

-- 
 Kirill A. Shutemov

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 10/12] x86/tdx: Unaccepted memory support
  2022-05-06 20:44     ` Kirill A. Shutemov
@ 2022-05-11  1:19       ` Kirill A. Shutemov
  2022-05-11  9:13         ` Borislav Petkov
  0 siblings, 1 reply; 58+ messages in thread
From: Kirill A. Shutemov @ 2022-05-11  1:19 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Kirill A. Shutemov, Andy Lutomirski, Sean Christopherson,
	Andrew Morton, Joerg Roedel, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Dave Hansen,
	Brijesh Singh, Mike Rapoport, David Hildenbrand, x86, linux-mm,
	linux-coco, linux-efi, linux-kernel

On Fri, May 06, 2022 at 11:44:23PM +0300, Kirill A. Shutemov wrote:
> > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > > index 7021ec725dd3..e4c31dbea6d7 100644
> > > --- a/arch/x86/Kconfig
> > > +++ b/arch/x86/Kconfig
> > > @@ -885,6 +885,7 @@ config INTEL_TDX_GUEST
> > >  	select ARCH_HAS_CC_PLATFORM
> > >  	select X86_MEM_ENCRYPT
> > >  	select X86_MCE
> > > +	select UNACCEPTED_MEMORY
> > 
> > WARNING: unmet direct dependencies detected for UNACCEPTED_MEMORY
> >   Depends on [n]: EFI [=y] && EFI_STUB [=y] && !KEXEC_CORE [=y]
> >   Selected by [y]:
> >   - INTEL_TDX_GUEST [=y] && HYPERVISOR_GUEST [=y] && X86_64 [=y] && CPU_SUP_INTEL [=y] && X86_X2APIC [=y]
> > 
> > WARNING: unmet direct dependencies detected for UNACCEPTED_MEMORY
> >   Depends on [n]: EFI [=y] && EFI_STUB [=y] && !KEXEC_CORE [=y]
> >   Selected by [y]:
> >   - INTEL_TDX_GUEST [=y] && HYPERVISOR_GUEST [=y] && X86_64 [=y] && CPU_SUP_INTEL [=y] && X86_X2APIC [=y]
> 
> Ughh. Any ideas how to get around it? (Except for implementing kexec
> support right away?)

I reworked this to boot-time kexec disable.


> > Also, it doesn't need to be bool - you can simply return accept_size on
> > success and 0 on error so that you don't have an I/O argument.
> 
> So on the calling side it would look like:
> 
> 	accepted = try_accept_one(start, len, PG_LEVEL_1G)
> 	if (accepted) {
> 		start += accepted;
> 		continue;
> 	}
> 
> And the similar for other levels. Is it really better?

JFYI, I've reworked it as

		accepted = try_accept_one(start, len, PG_LEVEL_1G);
		if (!accepted)
			accepted = try_accept_one(start, len, PG_LEVEL_2M);
		if (!accepted)
			accepted = try_accept_one(start, len, PG_LEVEL_4K);
		if (!accepted)
			return false;
		start += accepted;

looks good to me.

-- 
 Kirill A. Shutemov

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 08/12] x86/mm: Provide helpers for unaccepted memory
  2022-05-11  1:15         ` Kirill A. Shutemov
@ 2022-05-11  9:07           ` Borislav Petkov
  0 siblings, 0 replies; 58+ messages in thread
From: Borislav Petkov @ 2022-05-11  9:07 UTC (permalink / raw)
  To: Kirill A. Shutemov
  Cc: Kirill A. Shutemov, Andy Lutomirski, Sean Christopherson,
	Andrew Morton, Joerg Roedel, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Dave Hansen,
	Brijesh Singh, Mike Rapoport, David Hildenbrand, x86, linux-mm,
	linux-coco, linux-efi, linux-kernel

On Wed, May 11, 2022 at 04:15:35AM +0300, Kirill A. Shutemov wrote:
> Okay. Fair enough. I will change it to
> 
> 			panic("Cannot accept memory: unknown platform.");

So I haven't went all the way in the patchset but what I see is:

                /* Platform-specific memory-acceptance call goes here */
                if (cpu_feature_enabled(X86_FEATURE_TDX_GUEST)) {
                        tdx_accept_memory(range_start * PMD_SIZE,
                                          range_end * PMD_SIZE);
                } else {
                        panic("Cannot accept memory");
                }

so how would you decide for some other platform that it should panic?

TDX should panic, that I get. But you can just as well WARN_ONCE() here
so that it gets fixed. Panicking is counterproductive.

> It checks if the range of memory requires accept_memory() call before it
> can be accessed.
> 
> If any part of the range is not accepted, the call is required.
> accept_memory() knows what exactly has to be done. Note that
> accept_memory() call is harmless for any valid memory range.
> It can be called on already accepted memory.

Aaah, so that's what I was missing. So this function definitely needs a
comment ontop of it. And a name change to something like

	range_contains_unaccepted_memory()

or so to actually state what it does.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 10/12] x86/tdx: Unaccepted memory support
  2022-05-11  1:19       ` Kirill A. Shutemov
@ 2022-05-11  9:13         ` Borislav Petkov
  0 siblings, 0 replies; 58+ messages in thread
From: Borislav Petkov @ 2022-05-11  9:13 UTC (permalink / raw)
  To: Kirill A. Shutemov
  Cc: Kirill A. Shutemov, Andy Lutomirski, Sean Christopherson,
	Andrew Morton, Joerg Roedel, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Dave Hansen,
	Brijesh Singh, Mike Rapoport, David Hildenbrand, x86, linux-mm,
	linux-coco, linux-efi, linux-kernel

On Wed, May 11, 2022 at 04:19:06AM +0300, Kirill A. Shutemov wrote:
> JFYI, I've reworked it as
> 
> 		accepted = try_accept_one(start, len, PG_LEVEL_1G);
> 		if (!accepted)
> 			accepted = try_accept_one(start, len, PG_LEVEL_2M);
> 		if (!accepted)
> 			accepted = try_accept_one(start, len, PG_LEVEL_4K);
> 		if (!accepted)
> 			return false;
> 		start += accepted;

s/accepted/accpt_size/

and then it is perfectly clear what that variable contains.

But it seems you're preparing a new version so I'll continue looking at
there.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 06/12] x86/boot/compressed: Handle unaccepted memory
  2022-05-10 11:03       ` Borislav Petkov
@ 2022-05-13  5:31         ` Dionna Amalie Glaze
  2022-05-13  5:34         ` Dionna Amalie Glaze
  1 sibling, 0 replies; 58+ messages in thread
From: Dionna Amalie Glaze @ 2022-05-13  5:31 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Kirill A. Shutemov, Kirill A. Shutemov, Andy Lutomirski,
	Sean Christopherson, Andrew Morton, Joerg Roedel, Ard Biesheuvel,
	Andi Kleen, Kuppuswamy Sathyanarayanan, David Rientjes,
	Vlastimil Babka, Tom Lendacky, Thomas Gleixner, Peter Zijlstra,
	Paolo Bonzini, Ingo Molnar, Varad Gautam, Dario Faggioli,
	Dave Hansen, Brijesh Singh, Mike Rapoport, David Hildenbrand,
	x86, linux-mm, linux-coco, linux-efi, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 3440 bytes --]

Kirill, I've been tracking these changes to see if we can handle the
unaccepted memory type for SEV-SNP, but testing has been an issue. The
proposed patch in Ovmf to introduce unaccepted memory seems to have stalled
out last September (
https://www.mail-archive.com/devel@edk2.groups.io/msg35842.html) and is
particularly difficult to adapt to SEV-SNP since it doesn't follow the TDVF
way of initializing all memory. Is there a different development I might
have missed so that we might test these cases? Without the UEFI introducing
EFI_UNACCEPTED_MEMORY type, any kernel uses are essentially dead code.

Thanks,
-Dionna

On Tue, May 10, 2022 at 4:04 AM Borislav Petkov <bp@alien8.de> wrote:

> On Fri, May 06, 2022 at 06:30:13PM +0300, Kirill A. Shutemov wrote:
> > I find it harder to follow.
>
> If in doubt, always consider using a helper function:
>
> ---
>
> diff --git a/arch/x86/boot/compressed/efi.h
> b/arch/x86/boot/compressed/efi.h
> index 7db2f41b54cd..cf475243b6d5 100644
> --- a/arch/x86/boot/compressed/efi.h
> +++ b/arch/x86/boot/compressed/efi.h
> @@ -32,6 +32,7 @@ typedef       struct {
>  } efi_table_hdr_t;
>
>  #define EFI_CONVENTIONAL_MEMORY                 7
> +#define EFI_UNACCEPTED_MEMORY          15
>
>  #define EFI_MEMORY_MORE_RELIABLE \
>                                 ((u64)0x0000000000010000ULL)    /* higher
> reliability */
> diff --git a/arch/x86/boot/compressed/kaslr.c
> b/arch/x86/boot/compressed/kaslr.c
> index 28b91df9d31e..39bb4c319dfc 100644
> --- a/arch/x86/boot/compressed/kaslr.c
> +++ b/arch/x86/boot/compressed/kaslr.c
> @@ -671,6 +671,23 @@ static bool process_mem_region(struct mem_vector
> *region,
>  }
>
>  #ifdef CONFIG_EFI
> +
> +/*
> + * Only EFI_CONVENTIONAL_MEMORY and EFI_UNACCEPTED_MEMORY (if supported)
> are guaranteed
> + * to be free.
> + */
> +static inline bool memory_type_is_free(efi_memory_desc_t *md)
> +{
> +       if (md->type == EFI_CONVENTIONAL_MEMORY)
> +               return true;
> +
> +       if (IS_ENABLED(CONFIG_UNACCEPTED_MEMORY))
> +               if (md->type == EFI_UNACCEPTED_MEMORY)
> +                       return true;
> +
> +       return false;
> +}
> +
>  /*
>   * Returns true if we processed the EFI memmap, which we prefer over the
> E820
>   * table if it is available.
> @@ -723,21 +740,9 @@ process_efi_entries(unsigned long minimum, unsigned
> long image_size)
>                  * free memory and thus available to place the kernel
> image into,
>                  * but in practice there's firmware where using that
> memory leads
>                  * to crashes.
> -                *
> -                * Only EFI_CONVENTIONAL_MEMORY and EFI_UNACCEPTED_MEMORY
> (if
> -                * supported) are guaranteed to be free.
>                  */
> -
> -               switch (md->type) {
> -               case EFI_CONVENTIONAL_MEMORY:
> -                       break;
> -               case EFI_UNACCEPTED_MEMORY:
> -                       if (IS_ENABLED(CONFIG_UNACCEPTED_MEMORY))
> -                               break;
> +               if (!memory_type_is_free(md))
>                         continue;
> -               default:
> -                       continue;
> -               }
>
>                 if (efi_soft_reserve_enabled() &&
>                     (md->attribute & EFI_MEMORY_SP))
> --
> Regards/Gruss,
>     Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette
>


-- 
-Dionna Glaze, PhD (she/her)

[-- Attachment #2: Type: text/html, Size: 4549 bytes --]

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 06/12] x86/boot/compressed: Handle unaccepted memory
  2022-05-10 11:03       ` Borislav Petkov
  2022-05-13  5:31         ` Dionna Amalie Glaze
@ 2022-05-13  5:34         ` Dionna Amalie Glaze
  2022-05-13  9:01           ` Borislav Petkov
  1 sibling, 1 reply; 58+ messages in thread
From: Dionna Amalie Glaze @ 2022-05-13  5:34 UTC (permalink / raw)
  To: Borislav Petkov
  Cc: Kirill A. Shutemov, Kirill A. Shutemov, Andy Lutomirski,
	Sean Christopherson, Andrew Morton, Joerg Roedel, Ard Biesheuvel,
	Andi Kleen, Kuppuswamy Sathyanarayanan, David Rientjes,
	Vlastimil Babka, Tom Lendacky, Thomas Gleixner, Peter Zijlstra,
	Paolo Bonzini, Ingo Molnar, Varad Gautam, Dario Faggioli,
	Dave Hansen, Brijesh Singh, Mike Rapoport, David Hildenbrand,
	x86, linux-mm, linux-coco, linux-efi, linux-kernel

Kirill, I've been tracking these changes to see if we can handle the
unaccepted memory type for SEV-SNP, but testing has been an issue. The
proposed patch in Ovmf to introduce unaccepted memory seems to have
stalled out last September
(https://www.mail-archive.com/devel@edk2.groups.io/msg35842.html) and
is particularly difficult to adapt to SEV-SNP since it doesn't follow
the TDVF way of initializing all memory. Is there a different
development I might have missed so that we might test these cases?
Without the UEFI introducing EFI_UNACCEPTED_MEMORY type, any kernel
uses are essentially dead code.

Thanks,
-Dionna

(apologies for repost in text mode)

On Tue, May 10, 2022 at 4:04 AM Borislav Petkov <bp@alien8.de> wrote:
>
> On Fri, May 06, 2022 at 06:30:13PM +0300, Kirill A. Shutemov wrote:
> > I find it harder to follow.
>
> If in doubt, always consider using a helper function:
>
> ---
>
> diff --git a/arch/x86/boot/compressed/efi.h b/arch/x86/boot/compressed/efi.h
> index 7db2f41b54cd..cf475243b6d5 100644
> --- a/arch/x86/boot/compressed/efi.h
> +++ b/arch/x86/boot/compressed/efi.h
> @@ -32,6 +32,7 @@ typedef       struct {
>  } efi_table_hdr_t;
>
>  #define EFI_CONVENTIONAL_MEMORY                 7
> +#define EFI_UNACCEPTED_MEMORY          15
>
>  #define EFI_MEMORY_MORE_RELIABLE \
>                                 ((u64)0x0000000000010000ULL)    /* higher reliability */
> diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
> index 28b91df9d31e..39bb4c319dfc 100644
> --- a/arch/x86/boot/compressed/kaslr.c
> +++ b/arch/x86/boot/compressed/kaslr.c
> @@ -671,6 +671,23 @@ static bool process_mem_region(struct mem_vector *region,
>  }
>
>  #ifdef CONFIG_EFI
> +
> +/*
> + * Only EFI_CONVENTIONAL_MEMORY and EFI_UNACCEPTED_MEMORY (if supported) are guaranteed
> + * to be free.
> + */
> +static inline bool memory_type_is_free(efi_memory_desc_t *md)
> +{
> +       if (md->type == EFI_CONVENTIONAL_MEMORY)
> +               return true;
> +
> +       if (IS_ENABLED(CONFIG_UNACCEPTED_MEMORY))
> +               if (md->type == EFI_UNACCEPTED_MEMORY)
> +                       return true;
> +
> +       return false;
> +}
> +
>  /*
>   * Returns true if we processed the EFI memmap, which we prefer over the E820
>   * table if it is available.
> @@ -723,21 +740,9 @@ process_efi_entries(unsigned long minimum, unsigned long image_size)
>                  * free memory and thus available to place the kernel image into,
>                  * but in practice there's firmware where using that memory leads
>                  * to crashes.
> -                *
> -                * Only EFI_CONVENTIONAL_MEMORY and EFI_UNACCEPTED_MEMORY (if
> -                * supported) are guaranteed to be free.
>                  */
> -
> -               switch (md->type) {
> -               case EFI_CONVENTIONAL_MEMORY:
> -                       break;
> -               case EFI_UNACCEPTED_MEMORY:
> -                       if (IS_ENABLED(CONFIG_UNACCEPTED_MEMORY))
> -                               break;
> +               if (!memory_type_is_free(md))
>                         continue;
> -               default:
> -                       continue;
> -               }
>
>                 if (efi_soft_reserve_enabled() &&
>                     (md->attribute & EFI_MEMORY_SP))
> --
> Regards/Gruss,
>     Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette



-- 
-Dionna Glaze, PhD (she/her)

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 06/12] x86/boot/compressed: Handle unaccepted memory
  2022-05-13  5:34         ` Dionna Amalie Glaze
@ 2022-05-13  9:01           ` Borislav Petkov
  2022-05-13 14:45             ` Kirill A. Shutemov
  0 siblings, 1 reply; 58+ messages in thread
From: Borislav Petkov @ 2022-05-13  9:01 UTC (permalink / raw)
  To: Dionna Amalie Glaze, Michael Roth
  Cc: Borislav Petkov, Kirill A. Shutemov, Kirill A. Shutemov,
	Andy Lutomirski, Sean Christopherson, Andrew Morton,
	Joerg Roedel, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Dave Hansen,
	Mike Rapoport, David Hildenbrand, x86, linux-mm, linux-coco,
	linux-efi, linux-kernel

+ mroth
- brijesh

On Thu, May 12, 2022 at 10:34:02PM -0700, Dionna Amalie Glaze wrote:
> Kirill, I've been tracking these changes to see if we can handle the
> unaccepted memory type for SEV-SNP, but testing has been an issue. The
> proposed patch in Ovmf to introduce unaccepted memory seems to have
> stalled out last September
> (https://www.mail-archive.com/devel@edk2.groups.io/msg35842.html) and
> is particularly difficult to adapt to SEV-SNP since it doesn't follow
> the TDVF way of initializing all memory. Is there a different
> development I might have missed so that we might test these cases?
> Without the UEFI introducing EFI_UNACCEPTED_MEMORY type, any kernel
> uses are essentially dead code.
> 
> Thanks,
> -Dionna
> 
> (apologies for repost in text mode)
> 
> On Tue, May 10, 2022 at 4:04 AM Borislav Petkov <bp@alien8.de> wrote:
> >
> > On Fri, May 06, 2022 at 06:30:13PM +0300, Kirill A. Shutemov wrote:
> > > I find it harder to follow.
> >
> > If in doubt, always consider using a helper function:
> >
> > ---
> >
> > diff --git a/arch/x86/boot/compressed/efi.h b/arch/x86/boot/compressed/efi.h
> > index 7db2f41b54cd..cf475243b6d5 100644
> > --- a/arch/x86/boot/compressed/efi.h
> > +++ b/arch/x86/boot/compressed/efi.h
> > @@ -32,6 +32,7 @@ typedef       struct {
> >  } efi_table_hdr_t;
> >
> >  #define EFI_CONVENTIONAL_MEMORY                 7
> > +#define EFI_UNACCEPTED_MEMORY          15
> >
> >  #define EFI_MEMORY_MORE_RELIABLE \
> >                                 ((u64)0x0000000000010000ULL)    /* higher reliability */
> > diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
> > index 28b91df9d31e..39bb4c319dfc 100644
> > --- a/arch/x86/boot/compressed/kaslr.c
> > +++ b/arch/x86/boot/compressed/kaslr.c
> > @@ -671,6 +671,23 @@ static bool process_mem_region(struct mem_vector *region,
> >  }
> >
> >  #ifdef CONFIG_EFI
> > +
> > +/*
> > + * Only EFI_CONVENTIONAL_MEMORY and EFI_UNACCEPTED_MEMORY (if supported) are guaranteed
> > + * to be free.
> > + */
> > +static inline bool memory_type_is_free(efi_memory_desc_t *md)
> > +{
> > +       if (md->type == EFI_CONVENTIONAL_MEMORY)
> > +               return true;
> > +
> > +       if (IS_ENABLED(CONFIG_UNACCEPTED_MEMORY))
> > +               if (md->type == EFI_UNACCEPTED_MEMORY)
> > +                       return true;
> > +
> > +       return false;
> > +}
> > +
> >  /*
> >   * Returns true if we processed the EFI memmap, which we prefer over the E820
> >   * table if it is available.
> > @@ -723,21 +740,9 @@ process_efi_entries(unsigned long minimum, unsigned long image_size)
> >                  * free memory and thus available to place the kernel image into,
> >                  * but in practice there's firmware where using that memory leads
> >                  * to crashes.
> > -                *
> > -                * Only EFI_CONVENTIONAL_MEMORY and EFI_UNACCEPTED_MEMORY (if
> > -                * supported) are guaranteed to be free.
> >                  */
> > -
> > -               switch (md->type) {
> > -               case EFI_CONVENTIONAL_MEMORY:
> > -                       break;
> > -               case EFI_UNACCEPTED_MEMORY:
> > -                       if (IS_ENABLED(CONFIG_UNACCEPTED_MEMORY))
> > -                               break;
> > +               if (!memory_type_is_free(md))
> >                         continue;
> > -               default:
> > -                       continue;
> > -               }
> >
> >                 if (efi_soft_reserve_enabled() &&
> >                     (md->attribute & EFI_MEMORY_SP))
> > --
> > Regards/Gruss,
> >     Boris.
> >
> > https://people.kernel.org/tglx/notes-about-netiquette
> 
> 
> 
> -- 
> -Dionna Glaze, PhD (she/her)
> 

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Ivo Totev, HRB 36809, AG Nürnberg

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 06/12] x86/boot/compressed: Handle unaccepted memory
  2022-05-13  9:01           ` Borislav Petkov
@ 2022-05-13 14:45             ` Kirill A. Shutemov
  2022-05-16  6:46               ` Xu, Min M
  0 siblings, 1 reply; 58+ messages in thread
From: Kirill A. Shutemov @ 2022-05-13 14:45 UTC (permalink / raw)
  To: Borislav Petkov, Min Xu, Jiaqi Gao
  Cc: Dionna Amalie Glaze, Michael Roth, Borislav Petkov,
	Kirill A. Shutemov, Andy Lutomirski, Sean Christopherson,
	Andrew Morton, Joerg Roedel, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Dave Hansen,
	Mike Rapoport, David Hildenbrand, x86, linux-mm, linux-coco,
	linux-efi, linux-kernel

On Fri, May 13, 2022 at 11:01:43AM +0200, Borislav Petkov wrote:
> + mroth
> - brijesh
> 
> On Thu, May 12, 2022 at 10:34:02PM -0700, Dionna Amalie Glaze wrote:
> > Kirill, I've been tracking these changes to see if we can handle the
> > unaccepted memory type for SEV-SNP, but testing has been an issue. The
> > proposed patch in Ovmf to introduce unaccepted memory seems to have
> > stalled out last September
> > (https://www.mail-archive.com/devel@edk2.groups.io/msg35842.html) and
> > is particularly difficult to adapt to SEV-SNP since it doesn't follow
> > the TDVF way of initializing all memory. Is there a different
> > development I might have missed so that we might test these cases?
> > Without the UEFI introducing EFI_UNACCEPTED_MEMORY type, any kernel
> > uses are essentially dead code.

+ Min, Jiaqi.

I don't follow firmware development. Min, Jiaqi, could you comment?

-- 
 Kirill A. Shutemov

^ permalink raw reply	[flat|nested] 58+ messages in thread

* RE: [PATCHv5 06/12] x86/boot/compressed: Handle unaccepted memory
  2022-05-13 14:45             ` Kirill A. Shutemov
@ 2022-05-16  6:46               ` Xu, Min M
  2022-05-31 22:37                 ` Dionna Amalie Glaze
  2022-05-31 22:40                 ` Dionna Amalie Glaze
  0 siblings, 2 replies; 58+ messages in thread
From: Xu, Min M @ 2022-05-16  6:46 UTC (permalink / raw)
  To: Kirill A. Shutemov, Borislav Petkov, Gao, Jiaqi
  Cc: Dionna Amalie Glaze, Michael Roth, Borislav Petkov,
	Kirill A. Shutemov, Lutomirski, Andy, Christopherson,,
	Sean, Andrew Morton, Rodel, Jorg, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Hansen, Dave,
	Mike Rapoport, David Hildenbrand, x86, linux-mm, linux-coco,
	linux-efi, linux-kernel

On May 13, 2022 10:45 PM, Kirill A. Shutemov wrote:
> On Fri, May 13, 2022 at 11:01:43AM +0200, Borislav Petkov wrote:
> > + mroth
> > - brijesh
> >
> > On Thu, May 12, 2022 at 10:34:02PM -0700, Dionna Amalie Glaze wrote:
> > > Kirill, I've been tracking these changes to see if we can handle the
> > > unaccepted memory type for SEV-SNP, but testing has been an issue.
> > > The proposed patch in Ovmf to introduce unaccepted memory seems to
> > > have stalled out last September
> > > (https://www.mail-archive.com/devel@edk2.groups.io/msg35842.html)
> > > and is particularly difficult to adapt to SEV-SNP since it doesn't
> > > follow the TDVF way of initializing all memory. Is there a different
> > > development I might have missed so that we might test these cases?
> > > Without the UEFI introducing EFI_UNACCEPTED_MEMORY type, any
> kernel
> > > uses are essentially dead code.
> 
> + Min, Jiaqi.
> 
> I don't follow firmware development. Min, Jiaqi, could you comment?
> 
We have prepared the patch for unaccepted memory and it is now working in our internal release.
But there is an obstacle to upstream it to edk2 master branch. 
The patch-set depends on the definition of UEFI_RESOURCE_MEMORY_UNACCEPTED in PI spec. This is proposed in https://github.com/microsoft/mu_basecore/pull/66/files#diff-b20a11152d1ce9249c691be5690b4baf52069efadf2e2546cdd2eb663d80c9e4R237, according to UEFI-Code-First. The proposal was approved in 2021 in UEFI Mantis, and will be added to the new PI.next specification. (Till now it has not been added in the latest PI spec.)
So UEFI_RESOURCE_MEMORY_UNACCEPTED cannot be added in MdePkg which make it difficult to submit the patch to edk2 community for review. See this link: https://edk2.groups.io/g/devel/message/87558

Please be noted: UEFI_RESOURCE_MEMORY_UNACCEPTED (defined in PI spec) is different from EFI_UNACCEPTED_MEMORY (defined in UEFI spec)

I will submit the patch-set once the new definition is added in the new PI.next spec.

Thanks
Min

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 06/12] x86/boot/compressed: Handle unaccepted memory
  2022-05-16  6:46               ` Xu, Min M
@ 2022-05-31 22:37                 ` Dionna Amalie Glaze
  2022-05-31 22:40                 ` Dionna Amalie Glaze
  1 sibling, 0 replies; 58+ messages in thread
From: Dionna Amalie Glaze @ 2022-05-31 22:37 UTC (permalink / raw)
  To: Xu, Min M
  Cc: Kirill A. Shutemov, Borislav Petkov, Gao, Jiaqi, Michael Roth,
	Borislav Petkov, Kirill A. Shutemov, Lutomirski, Andy,
	Christopherson,,
	Sean, Andrew Morton, Rodel, Jorg, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Hansen, Dave,
	Mike Rapoport, David Hildenbrand, x86, linux-mm, linux-coco,
	linux-efi, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 2745 bytes --]

Hi y'all, I've made minimal changes to OVMF to prevalidate only up to 4GB
and leave the rest unaccepted, as Thomas Lendacky recommended
https://github.com/AMDESE/ovmf/pull/4#issuecomment-1138606275 and ran a
memtouch test to see if this change behaves as expected. One thing that
struck me is that an 8GB machine reports 2044MB free with this change (free
-k) whereas without it, I see 7089MB free. I think that unaccepted memory
should be classified as free in meminfo, no? I'm not familiar enough with
that code to say what specific change needs to be made.

On Sun, May 15, 2022 at 11:47 PM Xu, Min M <min.m.xu@intel.com> wrote:

> On May 13, 2022 10:45 PM, Kirill A. Shutemov wrote:
> > On Fri, May 13, 2022 at 11:01:43AM +0200, Borislav Petkov wrote:
> > > + mroth
> > > - brijesh
> > >
> > > On Thu, May 12, 2022 at 10:34:02PM -0700, Dionna Amalie Glaze wrote:
> > > > Kirill, I've been tracking these changes to see if we can handle the
> > > > unaccepted memory type for SEV-SNP, but testing has been an issue.
> > > > The proposed patch in Ovmf to introduce unaccepted memory seems to
> > > > have stalled out last September
> > > > (https://www.mail-archive.com/devel@edk2.groups.io/msg35842.html)
> > > > and is particularly difficult to adapt to SEV-SNP since it doesn't
> > > > follow the TDVF way of initializing all memory. Is there a different
> > > > development I might have missed so that we might test these cases?
> > > > Without the UEFI introducing EFI_UNACCEPTED_MEMORY type, any
> > kernel
> > > > uses are essentially dead code.
> >
> > + Min, Jiaqi.
> >
> > I don't follow firmware development. Min, Jiaqi, could you comment?
> >
> We have prepared the patch for unaccepted memory and it is now working in
> our internal release.
> But there is an obstacle to upstream it to edk2 master branch.
> The patch-set depends on the definition of UEFI_RESOURCE_MEMORY_UNACCEPTED
> in PI spec. This is proposed in
> https://github.com/microsoft/mu_basecore/pull/66/files#diff-b20a11152d1ce9249c691be5690b4baf52069efadf2e2546cdd2eb663d80c9e4R237,
> according to UEFI-Code-First. The proposal was approved in 2021 in UEFI
> Mantis, and will be added to the new PI.next specification. (Till now it
> has not been added in the latest PI spec.)
> So UEFI_RESOURCE_MEMORY_UNACCEPTED cannot be added in MdePkg which make it
> difficult to submit the patch to edk2 community for review. See this link:
> https://edk2.groups.io/g/devel/message/87558
>
> Please be noted: UEFI_RESOURCE_MEMORY_UNACCEPTED (defined in PI spec) is
> different from EFI_UNACCEPTED_MEMORY (defined in UEFI spec)
>
> I will submit the patch-set once the new definition is added in the new
> PI.next spec.
>
> Thanks
> Min
>


-- 
-Dionna Glaze, PhD (she/her)

[-- Attachment #2: Type: text/html, Size: 3820 bytes --]

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 06/12] x86/boot/compressed: Handle unaccepted memory
  2022-05-16  6:46               ` Xu, Min M
  2022-05-31 22:37                 ` Dionna Amalie Glaze
@ 2022-05-31 22:40                 ` Dionna Amalie Glaze
  2022-06-01 15:49                   ` Gupta, Pankaj
  1 sibling, 1 reply; 58+ messages in thread
From: Dionna Amalie Glaze @ 2022-05-31 22:40 UTC (permalink / raw)
  To: Xu, Min M
  Cc: Kirill A. Shutemov, Borislav Petkov, Gao, Jiaqi, Michael Roth,
	Borislav Petkov, Kirill A. Shutemov, Lutomirski, Andy,
	Christopherson,,
	Sean, Andrew Morton, Rodel, Jorg, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Hansen, Dave,
	Mike Rapoport, David Hildenbrand, x86, linux-mm, linux-coco,
	linux-efi, linux-kernel

Hi y'all, I've made minimal changes to OVMF to prevalidate only up to
4GB and leave the rest unaccepted, as Thomas Lendacky recommended
https://github.com/AMDESE/ovmf/pull/4#issuecomment-1138606275 and ran
a memtouch test to see if this change behaves as expected. One thing
that struck me is that an 8GB machine reports 2044MB free with this
change (free -k) whereas without it, I see 7089MB free. I think that
unaccepted memory should be classified as free in meminfo, no? I'm not
familiar enough with that code to say what specific change needs to be
made.

(resent in text mode)


On Sun, May 15, 2022 at 11:47 PM Xu, Min M <min.m.xu@intel.com> wrote:
>
> On May 13, 2022 10:45 PM, Kirill A. Shutemov wrote:
> > On Fri, May 13, 2022 at 11:01:43AM +0200, Borislav Petkov wrote:
> > > + mroth
> > > - brijesh
> > >
> > > On Thu, May 12, 2022 at 10:34:02PM -0700, Dionna Amalie Glaze wrote:
> > > > Kirill, I've been tracking these changes to see if we can handle the
> > > > unaccepted memory type for SEV-SNP, but testing has been an issue.
> > > > The proposed patch in Ovmf to introduce unaccepted memory seems to
> > > > have stalled out last September
> > > > (https://www.mail-archive.com/devel@edk2.groups.io/msg35842.html)
> > > > and is particularly difficult to adapt to SEV-SNP since it doesn't
> > > > follow the TDVF way of initializing all memory. Is there a different
> > > > development I might have missed so that we might test these cases?
> > > > Without the UEFI introducing EFI_UNACCEPTED_MEMORY type, any
> > kernel
> > > > uses are essentially dead code.
> >
> > + Min, Jiaqi.
> >
> > I don't follow firmware development. Min, Jiaqi, could you comment?
> >
> We have prepared the patch for unaccepted memory and it is now working in our internal release.
> But there is an obstacle to upstream it to edk2 master branch.
> The patch-set depends on the definition of UEFI_RESOURCE_MEMORY_UNACCEPTED in PI spec. This is proposed in https://github.com/microsoft/mu_basecore/pull/66/files#diff-b20a11152d1ce9249c691be5690b4baf52069efadf2e2546cdd2eb663d80c9e4R237, according to UEFI-Code-First. The proposal was approved in 2021 in UEFI Mantis, and will be added to the new PI.next specification. (Till now it has not been added in the latest PI spec.)
> So UEFI_RESOURCE_MEMORY_UNACCEPTED cannot be added in MdePkg which make it difficult to submit the patch to edk2 community for review. See this link: https://edk2.groups.io/g/devel/message/87558
>
> Please be noted: UEFI_RESOURCE_MEMORY_UNACCEPTED (defined in PI spec) is different from EFI_UNACCEPTED_MEMORY (defined in UEFI spec)
>
> I will submit the patch-set once the new definition is added in the new PI.next spec.
>
> Thanks
> Min



-- 
-Dionna Glaze, PhD (she/her)

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 06/12] x86/boot/compressed: Handle unaccepted memory
  2022-05-31 22:40                 ` Dionna Amalie Glaze
@ 2022-06-01 15:49                   ` Gupta, Pankaj
  2022-06-01 16:20                     ` Dionna Amalie Glaze
  0 siblings, 1 reply; 58+ messages in thread
From: Gupta, Pankaj @ 2022-06-01 15:49 UTC (permalink / raw)
  To: Dionna Amalie Glaze, Xu, Min M
  Cc: Kirill A. Shutemov, Borislav Petkov, Gao, Jiaqi, Michael Roth,
	Borislav Petkov, Kirill A. Shutemov, Lutomirski, Andy,
	Christopherson,,
	Sean, Andrew Morton, Rodel, Jorg, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Hansen, Dave,
	Mike Rapoport, David Hildenbrand, x86, linux-mm, linux-coco,
	linux-efi, linux-kernel


> Hi y'all, I've made minimal changes to OVMF to prevalidate only up to
> 4GB and leave the rest unaccepted, as Thomas Lendacky recommended
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAMDESE%2Fovmf%2Fpull%2F4%23issuecomment-1138606275&amp;data=05%7C01%7Cpankaj.gupta%40amd.com%7Cde8fd09ad93f4420bd7408da43568f68%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637896336342540814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=K93%2F1FrPOo4bIWcssHoisM8vDkOBjWh69bUWosT%2Bt0E%3D&amp;reserved=0 and ran
> a memtouch test to see if this change behaves as expected. One thing
> that struck me is that an 8GB machine reports 2044MB free with this
> change (free -k) whereas without it, I see 7089MB free. I think that
> unaccepted memory should be classified as free in meminfo, no? I'm not
> familiar enough with that code to say what specific change needs to be
> made.
> 

Is it memory accounting issue when accepting all the memory at boot time
compared to 4GB:4GB preboot_acceptance:use_time_acceptance split?

You said you ran memtouch (don't know how it works, assuming it uses 
memory)? Doesn't that mean most of the memory used and hence accepted? 
So, free memory reduced?

Just trying to understand the issue.

Thanks,
Pankaj
> 
> 
> On Sun, May 15, 2022 at 11:47 PM Xu, Min M <min.m.xu@intel.com> wrote:
>>
>> On May 13, 2022 10:45 PM, Kirill A. Shutemov wrote:
>>> On Fri, May 13, 2022 at 11:01:43AM +0200, Borislav Petkov wrote:
>>>> + mroth
>>>> - brijesh
>>>>
>>>> On Thu, May 12, 2022 at 10:34:02PM -0700, Dionna Amalie Glaze wrote:
>>>>> Kirill, I've been tracking these changes to see if we can handle the
>>>>> unaccepted memory type for SEV-SNP, but testing has been an issue.
>>>>> The proposed patch in Ovmf to introduce unaccepted memory seems to
>>>>> have stalled out last September
>>>>> (https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mail-archive.com%2Fdevel%40edk2.groups.io%2Fmsg35842.html&amp;data=05%7C01%7Cpankaj.gupta%40amd.com%7Cde8fd09ad93f4420bd7408da43568f68%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637896336342540814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=Hku8nQJGOg%2FdQqypHxw2eLFG0e%2FE6HoF5VXSIhMpmx0%3D&amp;reserved=0)
>>>>> and is particularly difficult to adapt to SEV-SNP since it doesn't
>>>>> follow the TDVF way of initializing all memory. Is there a different
>>>>> development I might have missed so that we might test these cases?
>>>>> Without the UEFI introducing EFI_UNACCEPTED_MEMORY type, any
>>> kernel
>>>>> uses are essentially dead code.
>>>
>>> + Min, Jiaqi.
>>>
>>> I don't follow firmware development. Min, Jiaqi, could you comment?
>>>
>> We have prepared the patch for unaccepted memory and it is now working in our internal release.
>> But there is an obstacle to upstream it to edk2 master branch.
>> The patch-set depends on the definition of UEFI_RESOURCE_MEMORY_UNACCEPTED in PI spec. This is proposed in https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fmu_basecore%2Fpull%2F66%2Ffiles%23diff-b20a11152d1ce9249c691be5690b4baf52069efadf2e2546cdd2eb663d80c9e4R237&amp;data=05%7C01%7Cpankaj.gupta%40amd.com%7Cde8fd09ad93f4420bd7408da43568f68%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637896336342540814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=v7s68GZWXJfaXB7vfvXjAlTD2KLOSghk%2Bj3GXF3FTVg%3D&amp;reserved=0, according to UEFI-Code-First. The proposal was approved in 2021 in UEFI Mantis, and will be added to the new PI.next specification. (Till now it has not been added in the latest PI spec.)
>> So UEFI_RESOURCE_MEMORY_UNACCEPTED cannot be added in MdePkg which make it difficult to submit the patch to edk2 community for review. See this link: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F87558&amp;data=05%7C01%7Cpankaj.gupta%40amd.com%7Cde8fd09ad93f4420bd7408da43568f68%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637896336342540814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=WVIJ2yRRd2URwIF85Dp0WD4ovibZlsobijIGbN6MWZQ%3D&amp;reserved=0
>>
>> Please be noted: UEFI_RESOURCE_MEMORY_UNACCEPTED (defined in PI spec) is different from EFI_UNACCEPTED_MEMORY (defined in UEFI spec)
>>
>> I will submit the patch-set once the new definition is added in the new PI.next spec.
>>
>> Thanks
>> Min
> 
> 
> 


^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 06/12] x86/boot/compressed: Handle unaccepted memory
  2022-06-01 15:49                   ` Gupta, Pankaj
@ 2022-06-01 16:20                     ` Dionna Amalie Glaze
  2022-06-01 19:34                       ` Randy Dunlap
  2022-06-02 12:51                       ` Gupta, Pankaj
  0 siblings, 2 replies; 58+ messages in thread
From: Dionna Amalie Glaze @ 2022-06-01 16:20 UTC (permalink / raw)
  To: Gupta, Pankaj
  Cc: Xu, Min M, Kirill A. Shutemov, Borislav Petkov, Gao, Jiaqi,
	Michael Roth, Borislav Petkov, Kirill A. Shutemov, Lutomirski,
	Andy, Christopherson,,
	Sean, Andrew Morton, Rodel, Jorg, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Hansen, Dave,
	Mike Rapoport, David Hildenbrand, x86, linux-mm, linux-coco,
	linux-efi, linux-kernel

The memory accounting in Linux is probably the issue. Both times I ran
the test were from a freshly booted VM. The test parses the output of
$(free -k) to determine the amount of free memory it should allocate
and write/read from, with a given stride of pages to skip before
touching the next page.

We grab the third column of numbers from the Mem output that looks like this

               total        used        free      shared  buff/cache   available
Mem:        65856604     4128688    48558952       11208    13168964    60942928
Swap:        1953788      118124     1835664

So my workstation has 48558952 free bytes. We take that, give it to
memtouch to allocate that much anonymous memory rounded down to the
nearest MB with mmap and randomly read/write the buffer.

For an 8GB machine, the UEFI will have the initial 0-0xA000 memory and
0x10_0000 to 0xC00_0000 (beginning of mmio hole) prevalidated. The
next 5GB is classified as the UEFI v2.9 memory type
EFI_RESOURCE_MEMORY_UNACCEPTED, 0x1_4000_000 to 0x2_0000_0000.
The Linux e820 map should see that range as unaccepted rather than
EFI_CONVENTIONAL_MEMORY (i.e., EDK2's EFI_RESOURCE_SYSTEM_MEMORY), but
I think it needs to be accounted as free conventional memory.

So when I see 2044MB free vs 7089MB free in my VMs, the two are
roughly 5GB different.

On Wed, Jun 1, 2022 at 8:49 AM Gupta, Pankaj <pankaj.gupta@amd.com> wrote:
>
>
> > Hi y'all, I've made minimal changes to OVMF to prevalidate only up to
> > 4GB and leave the rest unaccepted, as Thomas Lendacky recommended
> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAMDESE%2Fovmf%2Fpull%2F4%23issuecomment-1138606275&amp;data=05%7C01%7Cpankaj.gupta%40amd.com%7Cde8fd09ad93f4420bd7408da43568f68%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637896336342540814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=K93%2F1FrPOo4bIWcssHoisM8vDkOBjWh69bUWosT%2Bt0E%3D&amp;reserved=0 and ran
> > a memtouch test to see if this change behaves as expected. One thing
> > that struck me is that an 8GB machine reports 2044MB free with this
> > change (free -k) whereas without it, I see 7089MB free. I think that
> > unaccepted memory should be classified as free in meminfo, no? I'm not
> > familiar enough with that code to say what specific change needs to be
> > made.
> >
>
> Is it memory accounting issue when accepting all the memory at boot time
> compared to 4GB:4GB preboot_acceptance:use_time_acceptance split?
>
> You said you ran memtouch (don't know how it works, assuming it uses
> memory)? Doesn't that mean most of the memory used and hence accepted?
> So, free memory reduced?
>
> Just trying to understand the issue.
>
> Thanks,
> Pankaj
> >
> >
> > On Sun, May 15, 2022 at 11:47 PM Xu, Min M <min.m.xu@intel.com> wrote:
> >>
> >> On May 13, 2022 10:45 PM, Kirill A. Shutemov wrote:
> >>> On Fri, May 13, 2022 at 11:01:43AM +0200, Borislav Petkov wrote:
> >>>> + mroth
> >>>> - brijesh
> >>>>
> >>>> On Thu, May 12, 2022 at 10:34:02PM -0700, Dionna Amalie Glaze wrote:
> >>>>> Kirill, I've been tracking these changes to see if we can handle the
> >>>>> unaccepted memory type for SEV-SNP, but testing has been an issue.
> >>>>> The proposed patch in Ovmf to introduce unaccepted memory seems to
> >>>>> have stalled out last September
> >>>>> (https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mail-archive.com%2Fdevel%40edk2.groups.io%2Fmsg35842.html&amp;data=05%7C01%7Cpankaj.gupta%40amd.com%7Cde8fd09ad93f4420bd7408da43568f68%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637896336342540814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=Hku8nQJGOg%2FdQqypHxw2eLFG0e%2FE6HoF5VXSIhMpmx0%3D&amp;reserved=0)
> >>>>> and is particularly difficult to adapt to SEV-SNP since it doesn't
> >>>>> follow the TDVF way of initializing all memory. Is there a different
> >>>>> development I might have missed so that we might test these cases?
> >>>>> Without the UEFI introducing EFI_UNACCEPTED_MEMORY type, any
> >>> kernel
> >>>>> uses are essentially dead code.
> >>>
> >>> + Min, Jiaqi.
> >>>
> >>> I don't follow firmware development. Min, Jiaqi, could you comment?
> >>>
> >> We have prepared the patch for unaccepted memory and it is now working in our internal release.
> >> But there is an obstacle to upstream it to edk2 master branch.
> >> The patch-set depends on the definition of UEFI_RESOURCE_MEMORY_UNACCEPTED in PI spec. This is proposed in https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fmu_basecore%2Fpull%2F66%2Ffiles%23diff-b20a11152d1ce9249c691be5690b4baf52069efadf2e2546cdd2eb663d80c9e4R237&amp;data=05%7C01%7Cpankaj.gupta%40amd.com%7Cde8fd09ad93f4420bd7408da43568f68%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637896336342540814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=v7s68GZWXJfaXB7vfvXjAlTD2KLOSghk%2Bj3GXF3FTVg%3D&amp;reserved=0, according to UEFI-Code-First. The proposal was approved in 2021 in UEFI Mantis, and will be added to the new PI.next specification. (Till now it has not been added in the latest PI spec.)
> >> So UEFI_RESOURCE_MEMORY_UNACCEPTED cannot be added in MdePkg which make it difficult to submit the patch to edk2 community for review. See this link: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Fmessage%2F87558&amp;data=05%7C01%7Cpankaj.gupta%40amd.com%7Cde8fd09ad93f4420bd7408da43568f68%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637896336342540814%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=WVIJ2yRRd2URwIF85Dp0WD4ovibZlsobijIGbN6MWZQ%3D&amp;reserved=0
> >>
> >> Please be noted: UEFI_RESOURCE_MEMORY_UNACCEPTED (defined in PI spec) is different from EFI_UNACCEPTED_MEMORY (defined in UEFI spec)
> >>
> >> I will submit the patch-set once the new definition is added in the new PI.next spec.
> >>
> >> Thanks
> >> Min
> >
> >
> >
>


-- 
-Dionna Glaze, PhD (she/her)

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 06/12] x86/boot/compressed: Handle unaccepted memory
  2022-06-01 16:20                     ` Dionna Amalie Glaze
@ 2022-06-01 19:34                       ` Randy Dunlap
  2022-06-01 21:19                         ` Gupta, Pankaj
  2022-06-02 12:51                       ` Gupta, Pankaj
  1 sibling, 1 reply; 58+ messages in thread
From: Randy Dunlap @ 2022-06-01 19:34 UTC (permalink / raw)
  To: Dionna Amalie Glaze, Gupta, Pankaj
  Cc: Xu, Min M, Kirill A. Shutemov, Borislav Petkov, Gao, Jiaqi,
	Michael Roth, Borislav Petkov, Kirill A. Shutemov, Lutomirski,
	Andy, Christopherson,,
	Sean, Andrew Morton, Rodel, Jorg, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Hansen, Dave,
	Mike Rapoport, David Hildenbrand, x86, linux-mm, linux-coco,
	linux-efi, linux-kernel

Hi--

On 6/1/22 09:20, Dionna Amalie Glaze wrote:
> The memory accounting in Linux is probably the issue. Both times I ran
> the test were from a freshly booted VM. The test parses the output of
> $(free -k) to determine the amount of free memory it should allocate
> and write/read from, with a given stride of pages to skip before
> touching the next page.
> 
> We grab the third column of numbers from the Mem output that looks like this
> 
>                total        used        free      shared  buff/cache   available
> Mem:        65856604     4128688    48558952       11208    13168964    60942928
> Swap:        1953788      118124     1835664
> 
> So my workstation has 48558952 free bytes. We take that, give it to
> memtouch to allocate that much anonymous memory rounded down to the
> nearest MB with mmap and randomly read/write the buffer.
> 
> For an 8GB machine, the UEFI will have the initial 0-0xA000 memory and
> 0x10_0000 to 0xC00_0000 (beginning of mmio hole) prevalidated. The
> next 5GB is classified as the UEFI v2.9 memory type
> EFI_RESOURCE_MEMORY_UNACCEPTED, 0x1_4000_000 to 0x2_0000_0000.
> The Linux e820 map should see that range as unaccepted rather than
> EFI_CONVENTIONAL_MEMORY (i.e., EDK2's EFI_RESOURCE_SYSTEM_MEMORY), but
> I think it needs to be accounted as free conventional memory.
> 
> So when I see 2044MB free vs 7089MB free in my VMs, the two are
> roughly 5GB different.

Please see/read/use
  https://people.kernel.org/tglx/notes-about-netiquette

-- 
~Randy

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 06/12] x86/boot/compressed: Handle unaccepted memory
  2022-06-01 19:34                       ` Randy Dunlap
@ 2022-06-01 21:19                         ` Gupta, Pankaj
  0 siblings, 0 replies; 58+ messages in thread
From: Gupta, Pankaj @ 2022-06-01 21:19 UTC (permalink / raw)
  To: Randy Dunlap, Dionna Amalie Glaze
  Cc: Xu, Min M, Kirill A. Shutemov, Borislav Petkov, Gao, Jiaqi,
	Michael Roth, Borislav Petkov, Kirill A. Shutemov, Lutomirski,
	Andy, Christopherson,,
	Sean, Andrew Morton, Rodel, Jorg, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Hansen, Dave,
	Mike Rapoport, David Hildenbrand, x86, linux-mm, linux-coco,
	linux-efi, linux-kernel


>> The memory accounting in Linux is probably the issue. Both times I ran
>> the test were from a freshly booted VM. The test parses the output of
>> $(free -k) to determine the amount of free memory it should allocate
>> and write/read from, with a given stride of pages to skip before
>> touching the next page.
>>
>> We grab the third column of numbers from the Mem output that looks like this
>>
>>                 total        used        free      shared  buff/cache   available
>> Mem:        65856604     4128688    48558952       11208    13168964    60942928
>> Swap:        1953788      118124     1835664
>>
>> So my workstation has 48558952 free bytes. We take that, give it to
>> memtouch to allocate that much anonymous memory rounded down to the
>> nearest MB with mmap and randomly read/write the buffer.
>>
>> For an 8GB machine, the UEFI will have the initial 0-0xA000 memory and
>> 0x10_0000 to 0xC00_0000 (beginning of mmio hole) prevalidated. The
>> next 5GB is classified as the UEFI v2.9 memory type
>> EFI_RESOURCE_MEMORY_UNACCEPTED, 0x1_4000_000 to 0x2_0000_0000.
>> The Linux e820 map should see that range as unaccepted rather than
>> EFI_CONVENTIONAL_MEMORY (i.e., EDK2's EFI_RESOURCE_SYSTEM_MEMORY), but
>> I think it needs to be accounted as free conventional memory.
>>
>> So when I see 2044MB free vs 7089MB free in my VMs, the two are
>> roughly 5GB different.
> 
> Please see/read/use
...

Apologies, some problem in my email client (appending long characters to 
links), will find and correct.

Thank you for pointing.

Best regards,
Pankaj



^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 06/12] x86/boot/compressed: Handle unaccepted memory
  2022-06-01 16:20                     ` Dionna Amalie Glaze
  2022-06-01 19:34                       ` Randy Dunlap
@ 2022-06-02 12:51                       ` Gupta, Pankaj
  2022-06-02 15:31                         ` Dionna Amalie Glaze
  1 sibling, 1 reply; 58+ messages in thread
From: Gupta, Pankaj @ 2022-06-02 12:51 UTC (permalink / raw)
  To: Dionna Amalie Glaze
  Cc: Xu, Min M, Kirill A. Shutemov, Borislav Petkov, Gao, Jiaqi,
	Michael Roth, Borislav Petkov, Kirill A. Shutemov, Lutomirski,
	Andy, Christopherson,,
	Sean, Andrew Morton, Rodel, Jorg, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Hansen, Dave,
	Mike Rapoport, David Hildenbrand, x86, linux-mm, linux-coco,
	linux-efi, linux-kernel


> The memory accounting in Linux is probably the issue. Both times I ran
> the test were from a freshly booted VM. The test parses the output of
> $(free -k) to determine the amount of free memory it should allocate
> and write/read from, with a given stride of pages to skip before
> touching the next page.
> 
> We grab the third column of numbers from the Mem output that looks like this
> 
>                 total        used        free      shared  buff/cache   available
> Mem:        65856604     4128688    48558952       11208    13168964    60942928
> Swap:        1953788      118124     1835664
> 
> So my workstation has 48558952 free bytes. We take that, give it to
> memtouch to allocate that much anonymous memory rounded down to the
> nearest MB with mmap and randomly read/write the buffer.
> 
> For an 8GB machine, the UEFI will have the initial 0-0xA000 memory and
> 0x10_0000 to 0xC00_0000 (beginning of mmio hole) prevalidated. The
> next 5GB is classified as the UEFI v2.9 memory type
> EFI_RESOURCE_MEMORY_UNACCEPTED, 0x1_4000_000 to 0x2_0000_0000.
> The Linux e820 map should see that range as unaccepted rather than
> EFI_CONVENTIONAL_MEMORY (i.e., EDK2's EFI_RESOURCE_SYSTEM_MEMORY), but
> I think it needs to be accounted as free conventional memory.

AFAIU the unaccepted memory also stays in buddy (first via slow path) 
and should be accounted automatically in free?

> 
> So when I see 2044MB free vs 7089MB free in my VMs, the two are
> roughly 5GB different.

Is it possible all memory got allocated with memblock? Maybe some 
variable tests to validate with '/proc/meminfo | grep UnacceptedMem' 
would give you more clue.

Thanks,
Pankaj

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 06/12] x86/boot/compressed: Handle unaccepted memory
  2022-06-02 12:51                       ` Gupta, Pankaj
@ 2022-06-02 15:31                         ` Dionna Amalie Glaze
  2022-06-07 17:28                           ` Dionna Amalie Glaze
  0 siblings, 1 reply; 58+ messages in thread
From: Dionna Amalie Glaze @ 2022-06-02 15:31 UTC (permalink / raw)
  To: Gupta, Pankaj
  Cc: Xu, Min M, Kirill A. Shutemov, Borislav Petkov, Gao, Jiaqi,
	Michael Roth, Borislav Petkov, Kirill A. Shutemov, Lutomirski,
	Andy, Christopherson,,
	Sean, Andrew Morton, Rodel, Jorg, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Hansen, Dave,
	Mike Rapoport, David Hildenbrand, x86, linux-mm, linux-coco,
	linux-efi, linux-kernel

On Thu, Jun 2, 2022 at 5:51 AM Gupta, Pankaj <pankaj.gupta@amd.com> wrote:
> AFAIU the unaccepted memory also stays in buddy (first via slow path)
> and should be accounted automatically in free?
>

No, the last patch adds unaccepted mem as a differently accounted memory type.

> >
> > So when I see 2044MB free vs 7089MB free in my VMs, the two are
> > roughly 5GB different.
>
> Is it possible all memory got allocated with memblock? Maybe some
> variable tests to validate with '/proc/meminfo | grep UnacceptedMem'
> would give you more clue.
>

free -k parses /proc/meminfo for MemFree and SwapFree in
/proc/meminfo, so it sounds like it should also add in UnacceptedMem.
We'll try that. Thanks.




--
-Dionna Glaze, PhD (she/her)

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 06/12] x86/boot/compressed: Handle unaccepted memory
  2022-06-02 15:31                         ` Dionna Amalie Glaze
@ 2022-06-07 17:28                           ` Dionna Amalie Glaze
  2022-06-07 18:15                             ` Gupta, Pankaj
  0 siblings, 1 reply; 58+ messages in thread
From: Dionna Amalie Glaze @ 2022-06-07 17:28 UTC (permalink / raw)
  To: Gupta, Pankaj
  Cc: Xu, Min M, Kirill A. Shutemov, Borislav Petkov, Gao, Jiaqi,
	Michael Roth, Borislav Petkov, Kirill A. Shutemov, Lutomirski,
	Andy, Christopherson,,
	Sean, Andrew Morton, Rodel, Jorg, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Hansen, Dave,
	Mike Rapoport, David Hildenbrand, x86, linux-mm, linux-coco,
	linux-efi, linux-kernel

> free -k parses /proc/meminfo for MemFree and SwapFree in
> /proc/meminfo, so it sounds like it should also add in UnacceptedMem.
> We'll try that. Thanks.
>

Testing error on my part. Was using an adaptation of an old patch set.
With Brijesh's SEV-SNP support adapted to this version on top of
SEV-SNP guest patch series v12, I have no trouble with passing our
memtouch test.

Reference: https://github.com/deeglaze/amdese-linux/tree/v12unaccepted-v5

-- 
-Dionna Glaze, PhD (she/her)

^ permalink raw reply	[flat|nested] 58+ messages in thread

* Re: [PATCHv5 06/12] x86/boot/compressed: Handle unaccepted memory
  2022-06-07 17:28                           ` Dionna Amalie Glaze
@ 2022-06-07 18:15                             ` Gupta, Pankaj
  0 siblings, 0 replies; 58+ messages in thread
From: Gupta, Pankaj @ 2022-06-07 18:15 UTC (permalink / raw)
  To: Dionna Amalie Glaze
  Cc: Xu, Min M, Kirill A. Shutemov, Borislav Petkov, Gao, Jiaqi,
	Michael Roth, Borislav Petkov, Kirill A. Shutemov, Lutomirski,
	Andy, Christopherson,,
	Sean, Andrew Morton, Rodel, Jorg, Ard Biesheuvel, Andi Kleen,
	Kuppuswamy Sathyanarayanan, David Rientjes, Vlastimil Babka,
	Tom Lendacky, Thomas Gleixner, Peter Zijlstra, Paolo Bonzini,
	Ingo Molnar, Varad Gautam, Dario Faggioli, Hansen, Dave,
	Mike Rapoport, David Hildenbrand, x86, linux-mm, linux-coco,
	linux-efi, linux-kernel


> Testing error on my part. Was using an adaptation of an old patch set.
> With Brijesh's SEV-SNP support adapted to this version on top of
> SEV-SNP guest patch series v12, I have no trouble with passing our
> memtouch test.

Ah Guest unaccepted memory validate patch was missing. Good to know it 
worked for you. Thank you for sharing the result.

Best regards,
Pankaj



^ permalink raw reply	[flat|nested] 58+ messages in thread

end of thread, other threads:[~2022-06-07 18:15 UTC | newest]

Thread overview: 58+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-25  3:39 [PATCHv5 00/12] mm, x86/cc: Implement support for unaccepted memory Kirill A. Shutemov
2022-04-25  3:39 ` [PATCHv5 01/12] x86/boot/: Centralize __pa()/__va() definitions Kirill A. Shutemov
2022-04-25  7:37   ` David Hildenbrand
2022-04-25  7:52   ` Mike Rapoport
2022-04-25  3:39 ` [PATCHv5 02/12] mm: Add support for unaccepted memory Kirill A. Shutemov
2022-04-28 10:05   ` Borislav Petkov
2022-05-03 20:21   ` David Hildenbrand
2022-05-06  0:54     ` Kirill A. Shutemov
2022-04-25  3:39 ` [PATCHv5 03/12] efi/x86: Get full memory map in allocate_e820() Kirill A. Shutemov
2022-04-27 20:25   ` Borislav Petkov
2022-04-27 23:48     ` Kirill A. Shutemov
2022-04-28 10:02       ` Borislav Petkov
2022-04-25  3:39 ` [PATCHv5 04/12] x86/boot: Add infrastructure required for unaccepted memory support Kirill A. Shutemov
2022-04-29 10:58   ` Wander Lairson Costa
2022-05-02 13:38     ` Kirill A. Shutemov
2022-04-25  3:39 ` [PATCHv5 05/12] efi/x86: Implement support for unaccepted memory Kirill A. Shutemov
2022-04-29 10:53   ` Borislav Petkov
2022-05-02 13:40     ` Kirill A. Shutemov
2022-04-25  3:39 ` [PATCHv5 06/12] x86/boot/compressed: Handle " Kirill A. Shutemov
2022-04-27  0:17   ` Michael Roth
2022-04-27 14:19     ` Kirill A. Shutemov
2022-05-03 14:15       ` Borislav Petkov
2022-04-29 13:10   ` Wander Lairson Costa
2022-05-03 14:12   ` Borislav Petkov
2022-05-06 15:30     ` Kirill A. Shutemov
2022-05-10 11:03       ` Borislav Petkov
2022-05-13  5:31         ` Dionna Amalie Glaze
2022-05-13  5:34         ` Dionna Amalie Glaze
2022-05-13  9:01           ` Borislav Petkov
2022-05-13 14:45             ` Kirill A. Shutemov
2022-05-16  6:46               ` Xu, Min M
2022-05-31 22:37                 ` Dionna Amalie Glaze
2022-05-31 22:40                 ` Dionna Amalie Glaze
2022-06-01 15:49                   ` Gupta, Pankaj
2022-06-01 16:20                     ` Dionna Amalie Glaze
2022-06-01 19:34                       ` Randy Dunlap
2022-06-01 21:19                         ` Gupta, Pankaj
2022-06-02 12:51                       ` Gupta, Pankaj
2022-06-02 15:31                         ` Dionna Amalie Glaze
2022-06-07 17:28                           ` Dionna Amalie Glaze
2022-06-07 18:15                             ` Gupta, Pankaj
2022-04-25  3:39 ` [PATCHv5 07/12] x86/mm: Reserve unaccepted memory bitmap Kirill A. Shutemov
2022-04-29 13:19   ` Wander Lairson Costa
2022-05-04 11:04   ` Borislav Petkov
2022-04-25  3:39 ` [PATCHv5 08/12] x86/mm: Provide helpers for unaccepted memory Kirill A. Shutemov
2022-05-04 11:12   ` Borislav Petkov
2022-05-06 16:13     ` Kirill A. Shutemov
2022-05-10 18:32       ` Borislav Petkov
2022-05-11  1:15         ` Kirill A. Shutemov
2022-05-11  9:07           ` Borislav Petkov
2022-04-25  3:39 ` [PATCHv5 09/12] x86/tdx: Make _tdx_hypercall() and __tdx_module_call() available in boot stub Kirill A. Shutemov
2022-04-25  3:39 ` [PATCHv5 10/12] x86/tdx: Unaccepted memory support Kirill A. Shutemov
2022-05-05 10:12   ` Borislav Petkov
2022-05-06 20:44     ` Kirill A. Shutemov
2022-05-11  1:19       ` Kirill A. Shutemov
2022-05-11  9:13         ` Borislav Petkov
2022-04-25  3:39 ` [PATCHv5 11/12] mm/vmstat: Add counter for memory accepting Kirill A. Shutemov
2022-04-25  3:39 ` [PATCHv5 12/12] x86/mm: Report unaccepted memory in /proc/meminfo Kirill A. Shutemov

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.