Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 12 May 2023 13:59:19 +0300
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
Message-ID: <20230512105919.lgy3cvio6m2vcygn@box.shutemov.name>
References: <20230507234618.18067-1-kirill.shutemov@linux.intel.com>
 <20230507234618.18067-5-kirill.shutemov@linux.intel.com>
 <CAMj1kXE26G=HgqBHoJOWF+FyXs7Ryj7VFFY9A+xG7HmUXnb5bg@mail.gmail.com>
 <20230508190043.ouauzbghn27khdy4@box.shutemov.name>
 <CAMj1kXFxw4+opJuq=g2unocitRyKYz_hfrZb-grsZtPwBOyKgw@mail.gmail.com>
 <20230509005634.qtuiodpirexbxu2k@box.shutemov.name>
 <CAMj1kXGZ4j7nShGPoJzTZNa4NDvHnj_arY8XDXzW8cd6G==8Jg@mail.gmail.com>
 <20230512015909.2fj7bmp3ejc3owhs@box.shutemov.name>
 <CAMj1kXHY-uWWgWjv-7wLkKoh9pvgCbEkxHiCBbJa1wt53g5wYg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAMj1kXHY-uWWgWjv-7wLkKoh9pvgCbEkxHiCBbJa1wt53g5wYg@mail.gmail.com>
Precedence: bulk

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