search for: e820_table_firmware

...> > >> I am no expert on that matter (esp EFI). But looking at the users of > >> firmware_map_add_early(), the single user is in arch/x86/kernel/e820.c > >> . So the single source of /sys/firmware/memmap is (besides hotplug) e820. > >> > >> "'e820_table_firmware': the original firmware version passed to us by > >> the bootloader - not modified by the kernel. ... inform the user about > >> the firmware's notion of memory layout via /sys/firmware/memmap" > >> (arch/x86/kernel/e820.c) > >> > >> How is...

...ase. I'm not sure strict textualism > works for coding decisions. I am no expert on that matter (esp EFI). But looking at the users of firmware_map_add_early(), the single user is in arch/x86/kernel/e820.c . So the single source of /sys/firmware/memmap is (besides hotplug) e820. "'e820_table_firmware': the original firmware version passed to us by the bootloader - not modified by the kernel. ... inform the user about the firmware's notion of memory layout via /sys/firmware/memmap" (arch/x86/kernel/e820.c) How is the EFI Special Purpose (SP) Memory represented in e820? /sys/firmwa...

...ase. I'm not sure strict textualism > works for coding decisions. I am no expert on that matter (esp EFI). But looking at the users of firmware_map_add_early(), the single user is in arch/x86/kernel/e820.c . So the single source of /sys/firmware/memmap is (besides hotplug) e820. "'e820_table_firmware': the original firmware version passed to us by the bootloader - not modified by the kernel. ... inform the user about the firmware's notion of memory layout via /sys/firmware/memmap" (arch/x86/kernel/e820.c) How is the EFI Special Purpose (SP) Memory represented in e820? /sys/firmwa...

...or coding decisions. >> >> I am no expert on that matter (esp EFI). But looking at the users of >> firmware_map_add_early(), the single user is in arch/x86/kernel/e820.c >> . So the single source of /sys/firmware/memmap is (besides hotplug) e820. >> >> "'e820_table_firmware': the original firmware version passed to us by >> the bootloader - not modified by the kernel. ... inform the user about >> the firmware's notion of memory layout via /sys/firmware/memmap" >> (arch/x86/kernel/e820.c) >> >> How is the EFI Special Purpose (...

...or coding decisions. >> >> I am no expert on that matter (esp EFI). But looking at the users of >> firmware_map_add_early(), the single user is in arch/x86/kernel/e820.c >> . So the single source of /sys/firmware/memmap is (besides hotplug) e820. >> >> "'e820_table_firmware': the original firmware version passed to us by >> the bootloader - not modified by the kernel. ... inform the user about >> the firmware's notion of memory layout via /sys/firmware/memmap" >> (arch/x86/kernel/e820.c) >> >> How is the EFI Special Purpose (...

...ualism > > works for coding decisions. > > I am no expert on that matter (esp EFI). But looking at the users of > firmware_map_add_early(), the single user is in arch/x86/kernel/e820.c > . So the single source of /sys/firmware/memmap is (besides hotplug) e820. > > "'e820_table_firmware': the original firmware version passed to us by > the bootloader - not modified by the kernel. ... inform the user about > the firmware's notion of memory layout via /sys/firmware/memmap" > (arch/x86/kernel/e820.c) > > How is the EFI Special Purpose (SP) Memory represent...

On 01.05.20 20:03, Dan Williams wrote: > On Fri, May 1, 2020 at 10:51 AM David Hildenbrand <david at redhat.com> wrote: >> >> On 01.05.20 19:45, David Hildenbrand wrote: >>> On 01.05.20 19:39, Dan Williams wrote: >>>> On Fri, May 1, 2020 at 10:21 AM David Hildenbrand <david at redhat.com> wrote: >>>>> >>>>> On 01.05.20

On 01.05.20 20:03, Dan Williams wrote: > On Fri, May 1, 2020 at 10:51 AM David Hildenbrand <david at redhat.com> wrote: >> >> On 01.05.20 19:45, David Hildenbrand wrote: >>> On 01.05.20 19:39, Dan Williams wrote: >>>> On Fri, May 1, 2020 at 10:21 AM David Hildenbrand <david at redhat.com> wrote: >>>>> >>>>> On 01.05.20