linux-kernel - Re: [PATCH v4 00/23] device-dax: Support sub-dividing soft-reserved ranges

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 21 Aug 2020 23:33:57 +0200
From:   David Hildenbrand <david@...hat.com>
To:     Dan Williams <dan.j.williams@...el.com>
Cc:     David Hildenbrand <david@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Ira Weiny <ira.weiny@...el.com>,
        Ard Biesheuvel <ardb@...nel.org>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        Borislav Petkov <bp@...en8.de>,
        Vishal Verma <vishal.l.verma@...el.com>,
        David Airlie <airlied@...ux.ie>, Will Deacon <will@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Joao Martins <joao.m.martins@...cle.com>,
        Tom Lendacky <thomas.lendacky@....com>,
        Dave Jiang <dave.jiang@...el.com>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        Jonathan Cameron <jonathan.cameron@...wei.com>,
        Wei Yang <richardw.yang@...ux.intel.com>,
        X86 ML <x86@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Pavel Tatashin <pasha.tatashin@...een.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Ben Skeggs <bskeggs@...hat.com>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Jason Gunthorpe <jgg@...lanox.com>, Jia He <justin.he@....com>,
        Ingo Molnar <mingo@...hat.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Paul Mackerras <paulus@...abs.org>,
        Brice Goglin <Brice.Goglin@...ia.fr>,
        Jeff Moyer <jmoyer@...hat.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Daniel Vetter <daniel@...ll.ch>,
        Andy Lutomirski <luto@...nel.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Linux MM <linux-mm@...ck.org>,
        linux-nvdimm <linux-nvdimm@...ts.01.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux ACPI <linux-acpi@...r.kernel.org>,
        Maling list - DRI developers 
        <dri-devel@...ts.freedesktop.org>
Subject: Re: [PATCH v4 00/23] device-dax: Support sub-dividing soft-reserved ranges



> Am 21.08.2020 um 23:17 schrieb Dan Williams <dan.j.williams@...el.com>:
> 
> On Fri, Aug 21, 2020 at 11:30 AM David Hildenbrand <david@...hat.com> wrote:
>> 
>>> On 21.08.20 20:27, Dan Williams wrote:
>>> On Fri, Aug 21, 2020 at 3:15 AM David Hildenbrand <david@...hat.com> wrote:
>>>> 
>>>>>> 
>>>>>> 1. On x86-64, e820 indicates "soft-reserved" memory. This memory is not
>>>>>> automatically used in the buddy during boot, but remains untouched
>>>>>> (similar to pmem). But as it involves ACPI as well, it could also be
>>>>>> used on arm64 (-e820), correct?
>>>>> 
>>>>> Correct, arm64 also gets the EFI support for enumerating memory this
>>>>> way. However, I would clarify that whether soft-reserved is given to
>>>>> the buddy allocator by default or not is the kernel's policy choice,
>>>>> "buddy-by-default" is ok and is what will happen anyways with older
>>>>> kernels on platforms that enumerate a memory range this way.
>>>> 
>>>> Is "soft-reserved" then the right terminology for that? It sounds very
>>>> x86-64/e820 specific. Maybe a compressed for of "performance
>>>> differentiated memory" might be a better fit to expose to user space, no?
>>> 
>>> No. The EFI "Specific Purpose" bit is an attribute independent of
>>> e820, it's x86-Linux that entangles those together. There is no
>>> requirement for platform firmware to use that designation even for
>>> drastic performance differentiation between ranges, and conversely
>>> there is no requirement that memory *with* that designation has any
>>> performance difference compared to the default memory pool. So it
>>> really is a reservation policy about a memory range to keep out of the
>>> buddy allocator by default.
>> 
>> Okay, still "soft-reserved" is x86-64 specific, no?
> 
> There's nothing preventing other EFI archs, or a similar designation
> in another firmware spec, picking up this policy.
> 
>>  (AFAIK,
>> "soft-reserved" will be visible in /proc/iomem, or am I confusing
>> stuff?)
> 
> No, you're correct.
> 
>> IOW, it "performance differentiated" is not universally
>> applicable, maybe  "specific purpose memory" is ?
> 
> Those bikeshed colors don't seem an improvement to me.
> 
> "Soft-reserved" actually tells you something about the kernel policy
> for the memory. The criticism of "specific purpose" that led to
> calling it "soft-reserved" in Linux is the fact that "specific" is
> undefined as far as the firmware knows, and "specific" may have
> different applications based on the platform user. "Soft-reserved"
> like "Reserved" tells you that a driver policy might be in play for
> that memory.
> 
> Also note that the current color of the bikeshed has already shipped since v5.5:
> 
>   262b45ae3ab4 x86/efi: EFI soft reservation to E820 enumeration
> 

I was asking because I was struggling to even understand what „soft-reserved“ is and I could bet most people have no clue what that is supposed to be.

In contrast „persistent memory“ or „special purpose memory“ in /proc/iomem is something normal (Linux using) human beings can understand.

But anyhow, just details, and you‘re telling me that that ship already sailed. So no further comments from my side.

Thanks for all the info!