similar to: [PATCH v1] virtio-mem: add memory via add_memory_driver_managed()

virtio-mem: add memory via add_memory_driver_managed() On Thu, Jun 11, 2020 at 11:35:18AM +0200, David Hildenbrand wrote: > Virtio-mem managed memory is always detected and added by the virtio-mem > driver, never using something like the firmware-provided memory map. > This is the case after an ordinary system reboot, and has to be guaranteed > after kexec. Especially, virtio-mem

Virtio-mem managed memory is always detected and added by the virtio-mem driver, never using something like the firmware-provided memory map. This is the case after an ordinary system reboot, and has to be guaranteed after kexec. Especially, virtio-mem added memory resources can contain inaccessible parts ("unblocked memory blocks"), blindly forwarding them to a kexec kernel is

Virtio-mem managed memory is always detected and added by the virtio-mem driver, never using something like the firmware-provided memory map. This is the case after an ordinary system reboot, and has to be guaranteed after kexec. Especially, virtio-mem added memory resources can contain inaccessible parts ("unblocked memory blocks"), blindly forwarding them to a kexec kernel is

>> I'd like to have this patch in 5.8, with the initial merge of virtio-mem >> if possible (so the user space representation of virtio-mem added memory >> resources won't change anymore). > > So my plan is to rebase on top of -rc1 and merge this for rc2 then. > I don't like rebase on top of tip as the results are sometimes kind of > random. Right, I just

>> I'd like to have this patch in 5.8, with the initial merge of virtio-mem >> if possible (so the user space representation of virtio-mem added memory >> resources won't change anymore). > > So my plan is to rebase on top of -rc1 and merge this for rc2 then. > I don't like rebase on top of tip as the results are sometimes kind of > random. Right, I just

> Am 11.06.2020 um 13:18 schrieb Michael S. Tsirkin <mst at redhat.com>: > > ?On Thu, Jun 11, 2020 at 01:00:24PM +0200, David Hildenbrand wrote: >>>> I'd like to have this patch in 5.8, with the initial merge of virtio-mem >>>> if possible (so the user space representation of virtio-mem added memory >>>> resources won't change anymore).

On Thu, Jun 11, 2020 at 01:00:24PM +0200, David Hildenbrand wrote: > >> I'd like to have this patch in 5.8, with the initial merge of virtio-mem > >> if possible (so the user space representation of virtio-mem added memory > >> resources won't change anymore). > > > > So my plan is to rebase on top of -rc1 and merge this for rc2 then. > > I

On 30.04.20 10:11, Dan Williams wrote: > On Thu, Apr 30, 2020 at 12:20 AM David Hildenbrand <david at redhat.com> wrote: >> >> On 29.04.20 18:08, David Hildenbrand wrote: >>> Some paravirtualized devices that add memory via add_memory() and >>> friends (esp. virtio-mem) don't want to create entries in >>> /sys/firmware/memmap/ - primarily to

Some paravirtualized devices that add memory via add_memory() and friends (esp. virtio-mem) don't want to create entries in /sys/firmware/memmap/ - primarily to hinder kexec from adding this memory to the boot memmap of the kexec kernel. In fact, such memory is never exposed via the firmware (e.g., e820), but only via the device, so exposing this memory via /sys/firmware/memmap/ is wrong:

On Thu, Apr 30, 2020 at 12:20 AM David Hildenbrand <david at redhat.com> wrote: > > On 29.04.20 18:08, David Hildenbrand wrote: > > Some paravirtualized devices that add memory via add_memory() and > > friends (esp. virtio-mem) don't want to create entries in > > /sys/firmware/memmap/ - primarily to hinder kexec from adding this > > memory to the boot memmap

On 29.04.20 18:08, David Hildenbrand wrote: > Some paravirtualized devices that add memory via add_memory() and > friends (esp. virtio-mem) don't want to create entries in > /sys/firmware/memmap/ - primarily to hinder kexec from adding this > memory to the boot memmap of the kexec kernel. > > In fact, such memory is never exposed via the firmware (e.g., e820), but > only

On 29.04.20 18:08, David Hildenbrand wrote: > Some paravirtualized devices that add memory via add_memory() and > friends (esp. virtio-mem) don't want to create entries in > /sys/firmware/memmap/ - primarily to hinder kexec from adding this > memory to the boot memmap of the kexec kernel. > > In fact, such memory is never exposed via the firmware (e.g., e820), but > only

We soon want to pass flags, e.g., to mark added System RAM resources. mergeable. Prepare for that. This patch is based on a similar patch by Oscar Salvador: https://lkml.kernel.org/r/20190625075227.15193-3-osalvador at suse.de Acked-by: Wei Liu <wei.liu at kernel.org> Cc: Andrew Morton <akpm at linux-foundation.org> Cc: Michal Hocko <mhocko at suse.com> Cc: Dan Williams

We soon want to pass flags, e.g., to mark added System RAM resources. mergeable. Prepare for that. This patch is based on a similar patch by Oscar Salvador: https://lkml.kernel.org/r/20190625075227.15193-3-osalvador at suse.de Acked-by: Wei Liu <wei.liu at kernel.org> Reviewed-by: Juergen Gross <jgross at suse.com> # Xen related part Cc: Andrew Morton <akpm at

Some devices/drivers that add memory via add_memory() and friends (e.g., dax/kmem, but also virtio-mem in the future) don't want to create entries in /sys/firmware/memmap/ - primarily to hinder kexec from adding this memory to the boot memmap of the kexec kernel. In fact, such memory is never exposed via the firmware memmap as System RAM (e.g., e820), so exposing this memory via

IORESOURCE_MEM_DRIVER_MANAGED currently uses an unused PnP bit, which is always set to 0 by hardware. This is far from beautiful (and confusing), and the bit only applies to SYSRAM. So let's move it out of the bus-specific (PnP) defined bits. We'll add another SYSRAM specific bit soon. If we ever need more bits for other purposes, we can steal some from "desc", or

David Hildenbrand <david at redhat.com> writes: > Some devices/drivers that add memory via add_memory() and friends (e.g., > dax/kmem, but also virtio-mem in the future) don't want to create entries > in /sys/firmware/memmap/ - primarily to hinder kexec from adding this > memory to the boot memmap of the kexec kernel. > > In fact, such memory is never exposed via the

David Hildenbrand <david at redhat.com> writes: > Some devices/drivers that add memory via add_memory() and friends (e.g., > dax/kmem, but also virtio-mem in the future) don't want to create entries > in /sys/firmware/memmap/ - primarily to hinder kexec from adding this > memory to the boot memmap of the kexec kernel. > > In fact, such memory is never exposed via the

On 02.03.20 14:49, David Hildenbrand wrote: > This series is based on latest linux-next. The patches are located at: > https://github.com/davidhildenbrand/linux.git virtio-mem-v1 > > The basic idea of virtio-mem is to provide a flexible, > cross-architecture memory hot(un)plug solution that avoids many limitations > imposed by existing technologies, architectures, and

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