From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: "Kirill A. Shutemov" <kirill@shutemov.name>,
Borislav Petkov <bp@alien8.de>, Andy Lutomirski <luto@kernel.org>,
Dave Hansen <dave.hansen@intel.com>,
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>,
Dario Faggioli <dfaggioli@suse.com>,
Mike Rapoport <rppt@kernel.org>,
David Hildenbrand <david@redhat.com>,
Mel Gorman <mgorman@techsingularity.net>,
marcelo.cerri@canonical.com, tim.gardner@canonical.com,
khalid.elmously@canonical.com, philip.cox@canonical.com,
aarcange@redhat.com, peterx@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: [PATCHv10 04/11] efi/x86: Implement support for unaccepted memory
Date: Fri, 12 May 2023 13:59:19 +0300 [thread overview]
Message-ID: <20230512105919.lgy3cvio6m2vcygn@box.shutemov.name> (raw)
In-Reply-To: <CAMj1kXHY-uWWgWjv-7wLkKoh9pvgCbEkxHiCBbJa1wt53g5wYg@mail.gmail.com>
On Fri, May 12, 2023 at 09:39:30AM +0200, Ard Biesheuvel wrote:
> Please replace PMD_SIZE with something along the lines of
> EFI_UNACCEPTED_UNIT_SIZE and #define it to PMD_SIZE in
> arch/x86/include/asm/efi.h.
>
> The comment below about the size of the bitmap vs the size of the
> address space should probably move there as well.
Okay, will do.
> > +void accept_memory(phys_addr_t start, phys_addr_t end)
> > +{
> > + unsigned long range_start, range_end;
> > + unsigned long bitmap_size;
> > + u64 unit_size;
> > +
> > + if (!unaccepted_table)
> > + return;
> > +
> > + unit_size = unaccepted_table->unit_size;
> > +
> > + /*
> > + * Only care for the part of the range that is represented
> > + * in the bitmap.
> > + */
> > + if (start < unaccepted_table->phys_base)
> > + start = unaccepted_table->phys_base;
> > + if (end < unaccepted_table->phys_base)
> > + return;
> > +
> > + /* Translate to offsets from the beginning of the bitmap */
> > + start -= unaccepted_table->phys_base;
> > + end -= unaccepted_table->phys_base;
> > +
> > + /* Make sure not to overrun the bitmap */
> > + if (end > unaccepted_table->size * unit_size * BITS_PER_BYTE)
> > + end = unaccepted_table->size * unit_size * BITS_PER_BYTE;
> > +
>
> Should we warn here?
No. accept_memory() is nop for conventional memory (memblock calls it
unconditionally).
With the fixup, we only allocate bitmap for the range of physical address
space where we have unaccepted memory. So if there's conventional memory
after unaccepted, bitmap will not cover it.
--
Kiryl Shutsemau / Kirill A. Shutemov
next prev parent reply other threads:[~2023-05-12 10:59 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-07 23:46 [PATCHv10 00/11] mm, x86/cc: " Kirill A. Shutemov
2023-05-07 23:46 ` [PATCHv10 01/11] mm: Add " Kirill A. Shutemov
2023-05-07 23:46 ` [PATCHv10 02/11] efi/x86: Get full memory map in allocate_e820() Kirill A. Shutemov
2023-05-08 7:19 ` Ard Biesheuvel
2023-05-07 23:46 ` [PATCHv10 03/11] x86/boot: Add infrastructure required for unaccepted memory support Kirill A. Shutemov
2023-05-07 23:46 ` [PATCHv10 04/11] efi/x86: Implement support for unaccepted memory Kirill A. Shutemov
2023-05-08 7:30 ` Ard Biesheuvel
2023-05-08 19:00 ` Kirill A. Shutemov
2023-05-08 22:11 ` Ard Biesheuvel
2023-05-09 0:56 ` Kirill A. Shutemov
2023-05-09 6:47 ` Ard Biesheuvel
2023-05-12 1:59 ` Kirill A. Shutemov
2023-05-12 7:39 ` Ard Biesheuvel
2023-05-12 10:59 ` Kirill A. Shutemov [this message]
2023-05-12 11:01 ` Ard Biesheuvel
2023-05-07 23:46 ` [PATCHv10 05/11] x86/boot/compressed: Handle " Kirill A. Shutemov
2023-05-08 7:31 ` Ard Biesheuvel
2023-05-07 23:46 ` [PATCHv10 06/11] x86/mm: Reserve unaccepted memory bitmap Kirill A. Shutemov
2023-05-07 23:46 ` [PATCHv10 07/11] x86/mm: Provide helpers for unaccepted memory Kirill A. Shutemov
2023-05-07 23:46 ` [PATCHv10 08/11] x86/mm: Avoid load_unaligned_zeropad() stepping into " Kirill A. Shutemov
2023-05-07 23:46 ` [PATCHv10 09/11] x86/tdx: Make _tdx_hypercall() and __tdx_module_call() available in boot stub Kirill A. Shutemov
2023-05-07 23:46 ` [PATCHv10 10/11] x86/tdx: Refactor try_accept_one() Kirill A. Shutemov
2023-05-07 23:46 ` [PATCHv10 11/11] x86/tdx: Add unaccepted memory support 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=20230512105919.lgy3cvio6m2vcygn@box.shutemov.name \
--to=kirill.shutemov@linux.intel.com \
--cc=aarcange@redhat.com \
--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=jroedel@suse.de \
--cc=khalid.elmously@canonical.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=marcelo.cerri@canonical.com \
--cc=mgorman@techsingularity.net \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=peterz@infradead.org \
--cc=philip.cox@canonical.com \
--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=tim.gardner@canonical.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox