lkml.org 
[lkml]   [2020]   [May]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
    From
    Date
    On 01.05.20 00:24, Andrew Morton wrote:
    > On Thu, 30 Apr 2020 20:43:39 +0200 David Hildenbrand <david@redhat.com> wrote:
    >
    >>>
    >>> Why does the firmware map support hotplug entries?
    >>
    >> I assume:
    >>
    >> The firmware memmap was added primarily for x86-64 kexec (and still, is
    >> mostly used on x86-64 only IIRC). There, we had ACPI hotplug. When DIMMs
    >> get hotplugged on real HW, they get added to e820. Same applies to
    >> memory added via HyperV balloon (unless memory is unplugged via
    >> ballooning and you reboot ... the the e820 is changed as well). I assume
    >> we wanted to be able to reflect that, to make kexec look like a real reboot.
    >>
    >> This worked for a while. Then came dax/kmem. Now comes virtio-mem.
    >>
    >>
    >> But I assume only Andrew can enlighten us.
    >>
    >> @Andrew, any guidance here? Should we really add all memory to the
    >> firmware memmap, even if this contradicts with the existing
    >> documentation? (especially, if the actual firmware memmap will *not*
    >> contain that memory after a reboot)
    >
    > For some reason that patch is misattributed - it was authored by
    > Shaohui Zheng <shaohui.zheng@intel.com>, who hasn't been heard from in
    > a decade. I looked through the email discussion from that time and I'm
    > not seeing anything useful. But I wasn't able to locate Dave Hansen's
    > review comments.

    Okay, thanks for checking. I think the documentation from 2008 is pretty
    clear what has to be done here. I will add some of these details to the
    patch description.

    Also, now that I know that esp. kexec-tools already don't consider
    dax/kmem memory properly (memory will not get dumped via kdump) and
    won't really suffer from a name change in /proc/iomem, I will go back to
    the MHP_DRIVER_MANAGED approach and
    1. Don't create firmware memmap entries
    2. Name the resource "System RAM (driver managed)"
    3. Flag the resource via something like IORESOURCE_MEM_DRIVER_MANAGED.

    This way, kernel users and user space can figure out that this memory
    has different semantics and handle it accordingly - I think that was
    what Eric was asking for.

    Of course, open for suggestions.

    --
    Thanks,

    David / dhildenb

    \
     
     \ /
      Last update: 2020-05-01 11:35    [W:3.517 / U:0.240 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site