From: Dan Williams <email@example.com> To: Ard Biesheuvel <firstname.lastname@example.org> Cc: linux-nvdimm <email@example.com>, "the arch/x86 maintainers" <firstname.lastname@example.org>, Linux Kernel Mailing List <email@example.com>, Linux-MM <firstname.lastname@example.org>, Ingo Molnar <email@example.com>, Borislav Petkov <firstname.lastname@example.org>, "H. Peter Anvin" <email@example.com>, Darren Hart <firstname.lastname@example.org>, Thomas Gleixner <email@example.com>, Andy Shevchenko <firstname.lastname@example.org> Subject: Re: [RFC PATCH 1/5] efi: Detect UEFI 2.8 Special Purpose Memory Date: Fri, 12 Apr 2019 14:18:03 -0700 Message-ID: <CAPcyv4gtD=h-z_b5k3XTWsiPVv0NY=+Gycr8TJoTMCfcM3RL_A@mail.gmail.com> (raw) In-Reply-To: <CAKv+Gu_gzHH7onY4WUWV8SAYeVXfMK-W3CaxYZ706sPo6ATZpA@mail.gmail.com> On Fri, Apr 12, 2019 at 1:44 PM Ard Biesheuvel <email@example.com> wrote: [..] > > > I don't think this policy should dictate whether we pretend that the > > > attribute doesn't exist in the first place. We should just wire up the > > > bit fully, and only apply this policy at the very end. > > > > The bit is just a policy hint, if the kernel is not implementing any > > of the policy why even check for the bit? > > > > Because I would like things like the EFI memory map dumping code etc > to report the bit regardless of whether we are honoring it or not. Ok, I'll split it out just for reporting purposes, and come up with a different mechanism to indicate whether the OS might not be honoring the expectations of the attribute. [..] > Because not taking a hint is not the same thing as pretending it isn't > there to begin with. True, and I was missing the enabling to go update where the kernel goes to report attributes, but for the applications that care they will still want to debug when the kernel may be placing unwanted allocations in the "special purpose" range. > > > > Moreover, the interface for platform firmware to indicate that a > > > > memory range should never be treated as ordinary memory is simply the > > > > existing "reserved" memory type, not this attribute. That's the > > > > mechanism to use when platform firmware knows that a driver is needed > > > > for a given mmio resource. > > > > > > > > > > Reserved memory is memory that simply should never touched at all by > > > the OS, and on ARM, we take care never to map it anywhere. > > > > That's not a guarantee, at least on x86. Some shipping persistent > > memory platforms describe it as reserved and then the ACPI NFIT > > further describes what that reserved memory contains and how the OS > > can use it. See commit af1996ef59db "ACPI: Change NFIT driver to > > insert new resource". > > The UEFI spec is pretty clear about the fact that reserved memory > shouldn't ever be touched by the OS. The fact that x86 platforms exist > that violate this doesn't mean we should abuse it in other ways as > well. I think we're talking about 2 different "reserved" memory types, and it was my fault for not being precise enough. The e820 reserved memory type has been used for things like PCI memory-mapped I/O or other memory ranges for which the OS should expect a device-driver to claim. So when I said EFI_RESERVED_TYPE is safe to use as driver memory I literally meant this interpretation from do_add_efi_memmap(): default: /* * EFI_RESERVED_TYPE EFI_RUNTIME_SERVICES_CODE * EFI_RUNTIME_SERVICES_DATA EFI_MEMORY_MAPPED_IO * EFI_MEMORY_MAPPED_IO_PORT_SPACE EFI_PAL_CODE */ e820_type = E820_TYPE_RESERVED; break; ...where EFI_RESERVED_TYPE is identical to EFI_MEMORY_MAPPED_IO relative to E820_TYPE_RESERVED. The policy taken by these patches is that EFI_CONVENTIONAL_MEMORY marked with the EFI_MEMORY_SP attribute is treated as E820_TYPE_RESERVED by default and given to the device-dax driver with the option to hotplug it as E820_TYPE_RAM at a later time with its own numa description. I'm generally pushing back on the argument that EFI_MEMORY_SP == EFI_RESERVED_TYPE, especially when the type is explicitly set to EFI_CONVENTIONAL_MEMORY.
next prev parent reply index Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-04-04 19:08 [RFC PATCH 0/5] EFI Special Purpose Memory Support Dan Williams 2019-04-04 19:08 ` [RFC PATCH 1/5] efi: Detect UEFI 2.8 Special Purpose Memory Dan Williams 2019-04-06 4:21 ` Ard Biesheuvel 2019-04-09 16:43 ` Dan Williams 2019-04-09 17:21 ` Ard Biesheuvel 2019-04-10 2:10 ` Dan Williams 2019-04-12 20:43 ` Ard Biesheuvel 2019-04-12 21:18 ` Dan Williams [this message] 2019-04-15 11:43 ` Enrico Weigelt, metux IT consult 2019-04-04 19:08 ` [RFC PATCH 2/5] lib/memregion: Uplevel the pmem "region" ida to a global allocator Dan Williams 2019-04-04 19:32 ` Matthew Wilcox 2019-04-04 21:02 ` Dan Williams 2019-04-04 19:08 ` [RFC PATCH 3/5] acpi/hmat: Track target address ranges Dan Williams 2019-04-04 20:58 ` Keith Busch 2019-04-04 20:58 ` Dan Williams 2019-04-04 19:08 ` [RFC PATCH 4/5] acpi/hmat: Register special purpose memory as a device Dan Williams 2019-04-05 11:18 ` Jonathan Cameron 2019-04-05 15:43 ` Dan Williams 2019-04-05 16:23 ` Jonathan Cameron 2019-04-05 16:56 ` Dan Williams 2019-04-05 17:39 ` Jonathan Cameron 2019-04-09 12:13 ` Christoph Hellwig 2019-04-09 14:49 ` Dan Williams 2019-04-04 19:08 ` [RFC PATCH 5/5] device-dax: Add a driver for "hmem" devices Dan Williams
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='CAPcyv4gtD=h-z_b5k3XTWsiPVv0NY=+Gycr8TJoTMCfcM3RL_A@mail.gmail.com' \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /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
LKML Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/lkml/0 lkml/git/0.git git clone --mirror https://lore.kernel.org/lkml/1 lkml/git/1.git git clone --mirror https://lore.kernel.org/lkml/2 lkml/git/2.git git clone --mirror https://lore.kernel.org/lkml/3 lkml/git/3.git git clone --mirror https://lore.kernel.org/lkml/4 lkml/git/4.git git clone --mirror https://lore.kernel.org/lkml/5 lkml/git/5.git git clone --mirror https://lore.kernel.org/lkml/6 lkml/git/6.git git clone --mirror https://lore.kernel.org/lkml/7 lkml/git/7.git git clone --mirror https://lore.kernel.org/lkml/8 lkml/git/8.git git clone --mirror https://lore.kernel.org/lkml/9 lkml/git/9.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 lkml lkml/ https://lore.kernel.org/lkml \ firstname.lastname@example.org public-inbox-index lkml Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kernel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git