search for: firmware_map_remov

...e > parameter segment of the kernel that should be booted with > kexec. Also, the raw memory map is useful for debugging. For > that reason, /sys/firmware/memmap is an interface that provides > the raw memory map to userspace." [1] > > We don't have to worry about firmware_map_remove() on the removal path. > If there is no entry, it will simply return with -EINVAL. > > [1] > https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap You know what this justification is rubbish, and I have previously explained why it is rubbish. Nacked-by: "Er...

...e > parameter segment of the kernel that should be booted with > kexec. Also, the raw memory map is useful for debugging. For > that reason, /sys/firmware/memmap is an interface that provides > the raw memory map to userspace." [1] > > We don't have to worry about firmware_map_remove() on the removal path. > If there is no entry, it will simply return with -EINVAL. > > [1] > https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap You know what this justification is rubbish, and I have previously explained why it is rubbish. Nacked-by: "Er...

...that should be booted with >>> kexec. Also, the raw memory map is useful for debugging. For >>> that reason, /sys/firmware/memmap is an interface that provides >>> the raw memory map to userspace." [1] >>> >>> We don't have to worry about firmware_map_remove() on the removal path. >>> If there is no entry, it will simply return with -EINVAL. >>> >>> [1] >>> https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap >> >> >> You know what this justification is rubbish, and I have p...

...that should be booted with >>> kexec. Also, the raw memory map is useful for debugging. For >>> that reason, /sys/firmware/memmap is an interface that provides >>> the raw memory map to userspace." [1] >>> >>> We don't have to worry about firmware_map_remove() on the removal path. >>> If there is no entry, it will simply return with -EINVAL. >>> >>> [1] >>> https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap >> >> >> You know what this justification is rubbish, and I have p...

...- e.g., > memory managed by virtio-mem can have holes inside added memory resource, > which should not be touched, especially for writing. > > Let's expose that memory as "System RAM (driver managed)" e.g., via > /pro/iomem. > > We don't have to worry about firmware_map_remove() on the removal path. > If there is no entry, it will simply return with -EINVAL. > > [1] https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap > > Cc: Andrew Morton <akpm at linux-foundation.org> > Cc: Michal Hocko <mhocko at suse.com> > Cc...

...- e.g., > memory managed by virtio-mem can have holes inside added memory resource, > which should not be touched, especially for writing. > > Let's expose that memory as "System RAM (driver managed)" e.g., via > /pro/iomem. > > We don't have to worry about firmware_map_remove() on the removal path. > If there is no entry, it will simply return with -EINVAL. > > [1] https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap > > Cc: Andrew Morton <akpm at linux-foundation.org> > Cc: Michal Hocko <mhocko at suse.com> > Cc...

...ovided memory map to setup the parameter segment of the kernel that should be booted with kexec. Also, the raw memory map is useful for debugging. For that reason, /sys/firmware/memmap is an interface that provides the raw memory map to userspace." [1] We don't have to worry about firmware_map_remove() on the removal path. If there is no entry, it will simply return with -EINVAL. [1] https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap Cc: Andrew Morton <akpm at linux-foundation.org> Cc: Michal Hocko <mhocko at suse.com> Cc: Pankaj Gupta <pankaj.gupta.lin...

...egment of the kernel that should be booted with >> kexec. Also, the raw memory map is useful for debugging. For >> that reason, /sys/firmware/memmap is an interface that provides >> the raw memory map to userspace." [1] >> >> We don't have to worry about firmware_map_remove() on the removal path. >> If there is no entry, it will simply return with -EINVAL. >> >> [1] >> https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap > > > You know what this justification is rubbish, and I have previously > explained why...

...e differently than an ordinary DIMM - e.g., memory managed by virtio-mem can have holes inside added memory resource, which should not be touched, especially for writing. Let's expose that memory as "System RAM (driver managed)" e.g., via /pro/iomem. We don't have to worry about firmware_map_remove() on the removal path. If there is no entry, it will simply return with -EINVAL. [1] https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap Cc: Andrew Morton <akpm at linux-foundation.org> Cc: Michal Hocko <mhocko at suse.com> Cc: Pankaj Gupta <pankaj.gupta.lin...

...ed with >>>> kexec. Also, the raw memory map is useful for debugging. For >>>> that reason, /sys/firmware/memmap is an interface that provides >>>> the raw memory map to userspace." [1] >>>> >>>> We don't have to worry about firmware_map_remove() on the removal path. >>>> If there is no entry, it will simply return with -EINVAL. >>>> >>>> [1] >>>> https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap >>> >>> >>> You know what this justificatio...

...by virtio-mem can have holes inside added memory resource, > > which should not be touched, especially for writing. > > > > Let's expose that memory as "System RAM (driver managed)" e.g., via > > /pro/iomem. > > > > We don't have to worry about firmware_map_remove() on the removal path. > > If there is no entry, it will simply return with -EINVAL. > > > > [1] https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap > > > > Cc: Andrew Morton <akpm at linux-foundation.org> > > Cc: Michal Hocko <mh...

This is the follow up of [1]: [PATCH v1 0/3] mm/memory_hotplug: Make virtio-mem play nicely with kexec-tools I realized that this is not only helpful for virtio-mem, but also for dax/kmem - it's a fix for that use case (see patch #3) of persistent memory. Also, while testing, I discovered that kexec-tools will *not* add dax/kmem memory (anything not directly under the root when parsing

This series is based on [1]: [PATCH v2 00/10] virtio-mem: paravirtualized memory That will hopefull get picked up soon, rebased to -next. The following patches were reverted from -next [2]: [PATCH 0/3] kexec/memory_hotplug: Prevent removal and accidental use As discussed in that thread, they should be reverted from -next already. In theory, if people agree, we could take the first two patches

...have holes inside added memory resource, >>> which should not be touched, especially for writing. >>> >>> Let's expose that memory as "System RAM (driver managed)" e.g., via >>> /pro/iomem. >>> >>> We don't have to worry about firmware_map_remove() on the removal path. >>> If there is no entry, it will simply return with -EINVAL. >>> >>> [1] https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap >>> >>> Cc: Andrew Morton <akpm at linux-foundation.org> >>> Cc: M...

...>> kexec. Also, the raw memory map is useful for debugging. For >>>>> that reason, /sys/firmware/memmap is an interface that provides >>>>> the raw memory map to userspace." [1] >>>>> >>>>> We don't have to worry about firmware_map_remove() on the removal path. >>>>> If there is no entry, it will simply return with -EINVAL. >>>>> >>>>> [1] >>>>> https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap >>>> >>>> >>>> You...

...>> kexec. Also, the raw memory map is useful for debugging. For >>>>> that reason, /sys/firmware/memmap is an interface that provides >>>>> the raw memory map to userspace." [1] >>>>> >>>>> We don't have to worry about firmware_map_remove() on the removal path. >>>>> If there is no entry, it will simply return with -EINVAL. >>>>> >>>>> [1] >>>>> https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-firmware-memmap >>>> >>>> >>>> You...