All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@suse.de>
To: Dionna Amalie Glaze <dionnaglaze@google.com>,
	Michael Roth <michael.roth@amd.com>
Cc: Borislav Petkov <bp@alien8.de>,
	"Kirill A. Shutemov" <kirill@shutemov.name>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Andy Lutomirski <luto@kernel.org>,
	Sean Christopherson <seanjc@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Joerg Roedel <jroedel@suse.de>, Ard Biesheuvel <ardb@kernel.org>,
	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>,
	Dave Hansen <dave.hansen@intel.com>,
	Mike Rapoport <rppt@kernel.org>,
	David Hildenbrand <david@redhat.com>,
	x86@kernel.org, linux-mm@kvack.org, linux-coco@lists.linux.dev,
	linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCHv5 06/12] x86/boot/compressed: Handle unaccepted memory
Date: Fri, 13 May 2022 11:01:43 +0200	[thread overview]
Message-ID: <Yn4ed1gupKmNz2jn@zn.tnic> (raw)
In-Reply-To: <CAAH4kHYRxgUNnGRUO473q02q3akLzgiTvbA2qKEP5jq6jFV-uA@mail.gmail.com>

+ 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

  reply	other threads:[~2022-05-13  9:07 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

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=Yn4ed1gupKmNz2jn@zn.tnic \
    --to=bp@suse.de \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@intel.com \
    --cc=david@redhat.com \
    --cc=dfaggioli@suse.com \
    --cc=dionnaglaze@google.com \
    --cc=jroedel@suse.de \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kirill@shutemov.name \
    --cc=linux-coco@lists.linux.dev \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=michael.roth@amd.com \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rientjes@google.com \
    --cc=rppt@kernel.org \
    --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.