All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
	Sean Christopherson <seanjc@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Joerg Roedel <jroedel@suse.de>, Andi Kleen <ak@linux.intel.com>,
	Kuppuswamy Sathyanarayanan
	<sathyanarayanan.kuppuswamy@linux.intel.com>,
	David Rientjes <rientjes@google.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Ingo Molnar <mingo@redhat.com>,
	Varad Gautam <varad.gautam@suse.com>,
	Dario Faggioli <dfaggioli@suse.com>,
	x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev,
	linux-kernel@vger.kernel.org,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [PATCH 2/5] efi/x86: Implement support for unaccepted memory
Date: Fri, 13 Aug 2021 00:14:49 +0300	[thread overview]
Message-ID: <20210812211449.5bsblj6lphtu7zsd@box.shutemov.name> (raw)
In-Reply-To: <142bccc6-0e67-dfc1-9069-b773c2bad585@intel.com>

On Tue, Aug 10, 2021 at 10:50:33AM -0700, Dave Hansen wrote:
> ...
> > +void mark_unaccepted(struct boot_params *params, u64 start, u64 num)
> > +{
> 
> Some of these interfaces like accept_memory() take a start/end physical
> address.  Having this take a "num pages" is bound to cause confusion.
> Could you make these all consistently take start/end physical addresses?

Okay.

> 
> > +	u64 end = start + num * PAGE_SIZE;
> > +	unsigned int npages;
> 
> 
> Could you comment those, please?
> 
> 	/*
> 	 * 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.
> 	 */
> 
> Then go on to comment the three cases:
> 
> 	/* Check for ranges which do not span a whole PMD_SIZE area: */

Okay.

> > +	if ((start & PMD_MASK) == (end & PMD_MASK)) {
> > +		npages = (end - start) / PAGE_SIZE;
> > +		__accept_memory(start, start + npages * PAGE_SIZE);
> > +		return;
> > +	}
> 
> Hmm, is it possible to have this case hit, but neither of the two below
> cases?  This seems to be looking for a case where the range is somehow
> entirely contained in one PMD_SIZE area, but where it doesn't consume a
> whole area.
> 
> Wouldn't that mean that 'start' or 'end' must be unaligned?

The problem is that if both of them unaligned round_up() and round_down()
in the cases below would step outside the requested range.

> > +	if (start & ~PMD_MASK) {
> > +		npages = (round_up(start, PMD_SIZE) - start) / PAGE_SIZE;
> > +		__accept_memory(start, start + npages * PAGE_SIZE);
> > +		start = round_up(start, PMD_SIZE);
> > +	}
> > +
> > +	if (end & ~PMD_MASK) {
> > +		npages = (end - round_down(end, PMD_SIZE)) / PAGE_SIZE;
> > +		end = round_down(end, PMD_SIZE);
> > +		__accept_memory(end, end + npages * PAGE_SIZE);
> > +	}
> > +	npages = (end - start) / PMD_SIZE;
> > +	bitmap_set((unsigned long *)params->unaccepted_memory,
> > +		   start / PMD_SIZE, npages);
> > +}
> 
> Even though it's changed right there, it's a bit cruel to change the
> units of 'npages' right in the middle of a function.  It's just asking
> for bugs.
> 
> It would only take a single extra variable declaration to make this
> unambiguous:
> 
> 	u64 nr_unaccepted_bits;
> 
> or something, then you can do:
> 
> 	nr_unaccepted_bits = (end - start) / PMD_SIZE;
> 	bitmap_set((unsigned long *)params->unaccepted_memory,
> 		   start / PMD_SIZE, nr_unaccepted_bits);

Okay.

> 
> ...
> >  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;
> > -
> > -	/* 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;
> 
> I noticed that there's no reference to EFI_BUFFER_TOO_SMALL in the hunks
> you added back.  That makes me a bit nervous that this is going to
> unintentionally change behavior.
> 
> It might be worth having a preparatory reorganization patch for
> allocate_e820() before this new feature is added to make this more clear.

Okay. Will do.
> 
> > +	__u32 nr_desc;
> > +	bool unaccepted_memory_present = false;
> > +	u64 max_addr = 0;
> > +	int i;
> >  
> > -	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;
> >  	}
> >  
> > +	if (!IS_ENABLED(CONFIG_UNACCEPTED_MEMORY))
> > +		return EFI_SUCCESS;
> > +
> > +	/* 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)
> > +			unaccepted_memory_present = true;
> > +		if (d->phys_addr + d->num_pages * PAGE_SIZE > max_addr)
> > +			max_addr = d->phys_addr + d->num_pages * PAGE_SIZE;
> > +	}
> 
> This 'max_addr' variable looks a bit funky.
> 
> It *seems* like it's related only to EFI_UNACCEPTED_MEMORY, but it's not
> underneath the EFI_UNACCEPTED_MEMORY check.  Is this somehow assuming
> that once unaccepted memory as been found that *all* memory found in
> later descriptors at higher addresses is also going to be unaccepted?

You got it right below :P

> > +	/*
> > +	 * If unaccepted memory 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: 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 -- we would need 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.
> > +	 */
> > +	if (unaccepted_memory_present) {
> > +		unsigned long *unaccepted_memory = NULL;
> > +		u64 size = DIV_ROUND_UP(max_addr, PMD_SIZE * BITS_PER_BYTE);
> 
> Oh, so the bitmap has to be present for *all* memory, not just
> unaccepted memory.  So, we really do need to know the 'max_addr' so that
> we can allocate the bitmap for so that can be marked in the bitmap has
> having been accepted.

Right we need a bit for every 2M. Accepted or not.

> > +		status = efi_allocate_pages(size,
> > +					    (unsigned long *)&unaccepted_memory,
> > +					    ULONG_MAX);
> > +		if (status != EFI_SUCCESS)
> > +			return status;
> > +		memset(unaccepted_memory, 0, size);
> > +		params->unaccepted_memory = (u64)unaccepted_memory;
> > +	}
> 
> It might be nice to refer to setup_e820() here to mention that it is the
> thing that actually fills out the bitmap.

Okay.

-- 
 Kirill A. Shutemov

  reply	other threads:[~2021-08-12 21:14 UTC|newest]

Thread overview: 98+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-10  6:26 [PATCH 0/5] x86: Impplement support for unaccepted memory Kirill A. Shutemov
2021-08-10  6:26 ` Kirill A. Shutemov
2021-08-10  6:26 ` [PATCH 1/5] mm: Add " Kirill A. Shutemov
2021-08-10  6:26   ` Kirill A. Shutemov
2021-08-10  7:48   ` David Hildenbrand
2021-08-10  7:48     ` David Hildenbrand
2021-08-10 15:02     ` Kirill A. Shutemov
2021-08-10 15:02       ` Kirill A. Shutemov
2021-08-10 15:21       ` David Hildenbrand
2021-08-10 15:21         ` David Hildenbrand
2021-08-12 20:34         ` Kirill A. Shutemov
2021-08-12 20:34           ` Kirill A. Shutemov
2021-08-10 18:13   ` Dave Hansen
2021-08-10 18:13     ` Dave Hansen
2021-08-10 18:30     ` Andi Kleen
2021-08-10 18:30       ` Andi Kleen
2021-08-10 18:56       ` Dave Hansen
2021-08-10 18:56         ` Dave Hansen
2021-08-10 19:23         ` Andi Kleen
2021-08-10 19:23           ` Andi Kleen
2021-08-10 19:46           ` Dave Hansen
2021-08-10 19:46             ` Dave Hansen
2021-08-10 21:20             ` Andi Kleen
2021-08-10 21:20               ` Andi Kleen
2021-08-12  8:19               ` Joerg Roedel
2021-08-12  8:19                 ` Joerg Roedel
2021-08-12 14:14                 ` Dave Hansen
2021-08-12 14:14                   ` Dave Hansen
2021-08-12 20:49                   ` Kirill A. Shutemov
2021-08-12 20:49                     ` Kirill A. Shutemov
2021-08-12 20:59                     ` Dave Hansen
2021-08-12 20:59                       ` Dave Hansen
2021-08-12 21:23                       ` Kirill A. Shutemov
2021-08-12 21:23                         ` Kirill A. Shutemov
2021-08-13 14:49                   ` Joerg Roedel
2021-08-13 14:49                     ` Joerg Roedel
2021-08-17 15:00                     ` David Hildenbrand
2021-08-17 15:00                       ` David Hildenbrand
2021-08-19  9:55                       ` Joerg Roedel
2021-08-19  9:55                         ` Joerg Roedel
2021-08-19 10:06                         ` David Hildenbrand
2021-08-19 10:06                           ` David Hildenbrand
2021-08-10 20:50     ` Dave Hansen
2021-08-10 20:50       ` Dave Hansen
2021-08-12 21:08       ` Kirill A. Shutemov
2021-08-12 21:08         ` Kirill A. Shutemov
2021-08-10  6:26 ` [PATCH 2/5] efi/x86: Implement " Kirill A. Shutemov
2021-08-10  6:26   ` Kirill A. Shutemov
2021-08-10 17:50   ` Dave Hansen
2021-08-10 17:50     ` Dave Hansen
2021-08-12 21:14     ` Kirill A. Shutemov [this message]
2021-08-12 21:14       ` Kirill A. Shutemov
2021-08-12 21:43       ` Dave Hansen
2021-08-12 21:43         ` Dave Hansen
2021-08-10 18:30   ` Dave Hansen
2021-08-10 18:30     ` Dave Hansen
2021-08-10 19:08     ` Kirill A. Shutemov
2021-08-10 19:08       ` Kirill A. Shutemov
2021-08-10 19:19       ` Dave Hansen
2021-08-10 19:19         ` Dave Hansen
2021-08-12 21:17         ` Kirill A. Shutemov
2021-08-12 21:17           ` Kirill A. Shutemov
2021-08-10  6:26 ` [PATCH 3/5] x86/boot/compressed: Handle " Kirill A. Shutemov
2021-08-10  6:26   ` Kirill A. Shutemov
2021-08-10  6:26 ` [PATCH 4/5] x86/mm: Provide helpers for " Kirill A. Shutemov
2021-08-10  6:26   ` Kirill A. Shutemov
2021-08-10 18:16   ` Dave Hansen
2021-08-10 18:16     ` Dave Hansen
2021-08-12 20:31     ` Kirill A. Shutemov
2021-08-12 20:31       ` Kirill A. Shutemov
2021-08-10  6:26 ` [PATCH 5/5] x86/tdx: Unaccepted memory support Kirill A. Shutemov
2021-08-10  6:26   ` Kirill A. Shutemov
2021-08-10 14:08 ` [PATCH 0/5] x86: Impplement support for unaccepted memory Dave Hansen
2021-08-10 14:08   ` Dave Hansen
2021-08-10 15:15   ` Kirill A. Shutemov
2021-08-10 15:15     ` Kirill A. Shutemov
2021-08-10 15:51     ` Dave Hansen
2021-08-10 15:51       ` Dave Hansen
2021-08-10 17:31       ` Kirill A. Shutemov
2021-08-10 17:31         ` Kirill A. Shutemov
2021-08-10 17:36         ` Dave Hansen
2021-08-10 17:36           ` Dave Hansen
2021-08-10 17:51           ` Kirill A. Shutemov
2021-08-10 17:51             ` Kirill A. Shutemov
2021-08-10 18:19             ` Dave Hansen
2021-08-10 18:19               ` Dave Hansen
2021-08-10 18:39               ` Kirill A. Shutemov
2021-08-10 18:39                 ` Kirill A. Shutemov
2021-08-12  8:23 ` Joerg Roedel
2021-08-12  8:23   ` Joerg Roedel
2021-08-12 10:10   ` Kirill A. Shutemov
2021-08-12 10:10     ` Kirill A. Shutemov
2021-08-12 19:33     ` Andi Kleen
2021-08-12 19:33       ` Andi Kleen
2021-08-12 20:22       ` Kirill A. Shutemov
2021-08-12 20:22         ` Kirill A. Shutemov
2021-08-13 14:56         ` Joerg Roedel
2021-08-13 14:56           ` Joerg Roedel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210812211449.5bsblj6lphtu7zsd@box.shutemov.name \
    --to=kirill@shutemov.name \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=dfaggioli@suse.com \
    --cc=jroedel@suse.de \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rientjes@google.com \
    --cc=sathyanarayanan.kuppuswamy@linux.intel.com \
    --cc=seanjc@google.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=varad.gautam@suse.com \
    --cc=vbabka@suse.cz \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.