On 26 February 2018 at 15:06, Tyler Baicar <tbai...@codeaurora.org> wrote: > Hello Ard, > > > On 2/24/2018 3:03 AM, Ard Biesheuvel wrote: >> >> Hi Tyler, >> >> On 23 February 2018 at 19:42, Tyler Baicar <tbai...@codeaurora.org> wrote: >>> >>> The ESRT memory region is being exposed as System RAM in /proc/iomem >>> which is wrong because it cannot be overwritten. This memory is needed >>> for kexec kernels in order to properly initialize ESRT, so if it is >>> overwritten it will cause ESRT failures in the kexec kernel. Mark this >>> region as nomap so that it is not overwritten. >>> >> This is not the right fix. We should only mark regions NOMAP if it is >> uncertain whether the firmware may have a mapping of the same region >> with mismatched attributes. NOMAP regions punch holes in the linear >> region, increasing its TLB footprint significantly, so we should avoid >> them if we can. > > Thanks for the explanation, that makes sense. >> >> This same issue has come up in relation to mapping ACPI tables after >> kexec. This should simply be a matter of ensuring that all >> memblock_reserve()d region appear as such in /proc/iomem rather than >> as 'System RAM' > > Do you know why this memory region would be coming up as System RAM rather > than reserved if we're > calling memblock_reserve() on it in efi_mem_reserve()? >
I don't think there is any special handling of memblock_reserve()'d regions at all at the moment. -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
