On Tue, 15 Sep 2020 at 17:33, Grant Likely <grant.lik...@arm.com> wrote: > > > > On 15/09/2020 15:16, Ard Biesheuvel wrote: > > On Tue, 15 Sep 2020 at 17:05, Grant Likely <grant.lik...@arm.com> wrote: > >> > >> > >> > >> On 15/09/2020 14:46, Leif Lindholm wrote: > >>> On Tue, Sep 15, 2020 at 14:14:30 +0100, Grant Likely wrote: > >>>>> The EFI stub in Linux removes /memreserve/ entries from the DT before > >>>>> handing it to the kernel proper. > >>>>> > >>>>> commit 0ceac9e094b065fe3fec19669740f338d3480498 > >>>>> Author: Mark Salter <msal...@redhat.com> > >>>>> Date: Mon Sep 8 13:01:08 2014 -0400 > >>>>> > >>>>> efi/arm64: Fix fdt-related memory reservation > >>>> > >>>> Does that still make sense? I understand why it was done, but is it > >>>> right to ignore those reservations outright? > >>> > >>> Yes. It is duplication of (sources of) information, forcing the > >>> operating system to make runtime, or compile time, judgement calls of > >>> which source(s) of information to respect. > >> > >> Not quite that simple. We're not talking about a clean cut-over from > >> non-UEFI to UEFI platforms, but rather a phased transition where with a > >> given DT, both the non-UEFI and UEFI boot paths need to work. e.g., > >> U-Boot platforms where most people are using 'bootm', but want to start > >> encouraging them to use the UEFI infrastructure. > >> > >> Or in other words, the master source of information is the .dts file, > >> not the firmware itself. > >> > >> The other issue is that the reserved memory region may not be about > >> firmware at all, but rather a memory layout that is wanted only by the > >> OS. Regardless of the approach we take here, those regions must be > >> respected. > >> > >>>> As more U-Boot platforms > >>>> turn on UEFI there could be unexpected consequences if the memory > >>>> reservation block are silently ignored. I'm think that on the U-Boot > >>>> platforms it is more likely that /memreserve/ is in use. > >>> > >>> That should also make it easy to intercept? Like putting a hook in the > >>> DT update code that triggers build error/warning (or even update the > >>> UEFI memory map) if someone is trying to memreserve with the UEFI > >>> interface enabled. > >> > >> It should not be an error to use /memreserve/. That creates a hard break > >> between UEFI and non-UEFI boot paths for /memreserve/. Updating the > >> memory map is fine, which leads to the question of what memory type > >> should be used? > >> > >> EfiBootServicesData: Memory still gets mapped in the linear map, but > >> nothing protects it after ExitBootServices (would require leaving > >> /memreserve/ intact so the OS knows to protect them). > >> > >> EfiReservedMemory: (As I understand it) Doesn't need /memreserve/, but > >> causes a change in behaviour. The memory will not appear in the linear > >> map. This will possibly cause problems with existing drivers > >> > > > > I wouldn't expect so. Unlike /reserved-memory nodes, which can be > > referenced by other nodes and explicitly tagged as reusable, > > /memreserve/s are anonymous holes that are punched into the memory > > map, so I don't see how a driver would be able to get a reference to > > that memory (and gets its linear address if it _happens_ to be in > > lowmem in the first place.) > > In the typical use case, the driver doesn't directly use the > /memreserve/ entry, but rather knowledge of the hole is implicit; the > driver expects it to exist via some other mechanism. E.g., a property in > the device node. If /memreserve/ gets cleared out, the device node will > probably still try to use the region as if it had been reserved. > > e.g.: > powerpc/boot/dts/akebono.dts: <0x1f00000 0x100000> is reserved, and then > used in the cpu-release-address property. This is a case where the > memory should still be in the linear map. >
That depends on how the boot CPU accesses this memory - a quick scan shows that many drivers ioremap() this address rather than access it via the linear mapping. > These are old use cases, and /memreserve/ is definitely deprecated in > favour of the /reserved-memory node, but it has users and I absolutely > do not want to create barriers to adopting the UEFI boot flow. > > >> EfiRuntimeServicesData: Keeps the region protected and in the linear > >> map, but feels 'wrong'. An OS might decide to reclaim it anyway if it > >> doesn't use runtime services (against spec?). > >> > > > > EfiRuntimeServicesData is not covered by the linear map, but will map > > it in the EFI page tables for access by the firmware itself at > > runtime, so it is not an option here. > > Ah, right. So that isn't right either. > > g. > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
