search for: 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 guarant...

...essible parts ("unblocked memory blocks"), blindly forwarding them to a kexec kernel is dangerous, as unplugged memory will get accessed (esp. written). Let's use the new way of adding special driver-managed memory introduced in commit 75ac4c58bc0d ("mm/memory_hotplug: introduce add_memory_driver_managed()"). This will result in no entries in /sys/firmware/memmap ("raw firmware- provided memory map"), the memory resource will be flagged IORESOURCE_MEM_DRIVER_MANAGED (esp., kexec_file_load() will not place kexec images on this memory), and it is exposed as "System RAM (virtio_me...

...essible parts ("unblocked memory blocks"), blindly forwarding them to a kexec kernel is dangerous, as unplugged memory will get accessed (esp. written). Let's use the new way of adding special driver-managed memory introduced in commit 75ac4c58bc0d ("mm/memory_hotplug: introduce add_memory_driver_managed()"). This will result in no entries in /sys/firmware/memmap ("raw firmware- provided memory map"), the memory resource will be flagged IORESOURCE_MEM_DRIVER_MANAGED (esp., kexec_file_load() will not place kexec images on this memory), and it is exposed as "System RAM (virtio_me...

...blindly forwarding them >> to a kexec kernel is dangerous, as unplugged memory will get accessed >> (esp. written). >> >> Let's use the new way of adding special driver-managed memory introduced >> in commit 75ac4c58bc0d ("mm/memory_hotplug: introduce >> add_memory_driver_managed()"). > > Is this commit id correct? Good point, it's the one from next-20200605. 7b7b27214bba Is the correct one. [...] > > Looks good to me. > Reviewed-by: Pankaj Gupta <pankaj.gupta.linux at gmail.com> > Thanks! -- Thanks, David / dhildenb

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

> 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).

>> 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

...per_block, 0); if (ret) goto out; diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c index 7dcb2902e9b1b..8e66b28ef5bc6 100644 --- a/drivers/dax/kmem.c +++ b/drivers/dax/kmem.c @@ -95,7 +95,7 @@ int dev_dax_kmem_probe(struct dev_dax *dev_dax) * this as RAM automatically. */ rc = add_memory_driver_managed(numa_node, range.start, - range_len(&range), kmem_name); + range_len(&range), kmem_name, 0); res->flags |= IORESOURCE_BUSY; if (rc) { diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c index 32e3bc0aa665a..0194bed1a5736 100644 --- a/drivers/hv/hv_balloon.c +++ b...

...MHP_NONE); if (ret) goto out; diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c index 7dcb2902e9b1b..896cb9444e727 100644 --- a/drivers/dax/kmem.c +++ b/drivers/dax/kmem.c @@ -95,7 +95,7 @@ int dev_dax_kmem_probe(struct dev_dax *dev_dax) * this as RAM automatically. */ rc = add_memory_driver_managed(numa_node, range.start, - range_len(&range), kmem_name); + range_len(&range), kmem_name, MHP_NONE); res->flags |= IORESOURCE_BUSY; if (rc) { diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c index 32e3bc0aa665a..3c0d52e244520 100644 --- a/drivers/hv/hv_balloon....

...int nid = vm->nid; + int rc; if (nid == NUMA_NO_NODE) nid = memory_add_physaddr_to_nid(addr); @@ -431,8 +432,17 @@ static int virtio_mem_mb_add(struct virtio_mem *vm, unsigned long mb_id) } dev_dbg(&vm->vdev->dev, "adding memory block: %lu\n", mb_id); - return add_memory_driver_managed(nid, addr, memory_block_size_bytes(), - vm->resource_name); + rc = add_memory_driver_managed(nid, addr, memory_block_size_bytes(), + vm->resource_name); + if (!rc) { + /* + * Try to reduce the number of resources by merging them. The + * memory removal path will properly s...

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

...p are created, * as this memory won't be part of the raw firmware-provided memory map * e.g., after a reboot. Also, the created memory resource is flagged * with IORESOURCE_MEM_DRIVER_MANAGED, so in-kernel users can special- * case this memory (e.g., not place kexec images onto it). */ int add_memory_driver_managed(int nid, u64 start, u64 size, const char *resource_name); If we'd ever have to special case it even more in the kernel, we could allow to specify further resource flags. While passing the driver name instead of the resource_name would be an option, this way we don't have to hand...

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

...ichael S. Tsirkin <mst at redhat.com> ---------------------------------------------------------------- Dan Carpenter (2): vhost_vdpa: Fix potential underflow in vhost_vdpa_mmap() virtio-mem: silence a static checker warning David Hildenbrand (1): virtio-mem: add memory via add_memory_driver_managed() Eugenio P?rez (7): tools/virtio: Add --batch option tools/virtio: Add --batch=random option tools/virtio: Add --reset tools/virtio: Use __vring_new_virtqueue in virtio_test.c tools/virtio: Extract virtqueue initialization in vq_reset tools/virtio: Reset index...

This is the follow-up of "[PATCH RFCv1 0/5] mm/memory_hotplug: selective merging of memory resources" [1] Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant