search for: ioresource_system_ram

...system ram resources to the >> + * parent (besides during boot). >> + * - release_mem_region_adjustable() will split on demand on memory hotunplug >> + */ >> +void merge_system_ram_resources(struct resource *parent) >> +{ >> + const unsigned long flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY; >> + struct resource *cur, *next; >> + >> + write_lock(&resource_lock); >> + >> + cur = parent->child; >> + while (cur && cur->sibling) { >> + next = cur->sibling; >> +...

.../* add this memory to iomem resource */ > -static struct resource *register_memory_resource(u64 start, u64 size) > +static struct resource *register_memory_resource(u64 start, u64 size, > + const char *resource_name) > { > struct resource *res; > unsigned long flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY; > - char *resource_name = "System RAM"; > > /* > * Make sure value parsed from 'mem=' only restricts memory adding > @@ -1058,7 +1058,8 @@ int __ref add_memory_resource(int nid, struct resource *res, > BUG_ON(ret); > > /* cre...

.../* add this memory to iomem resource */ > -static struct resource *register_memory_resource(u64 start, u64 size) > +static struct resource *register_memory_resource(u64 start, u64 size, > + const char *resource_name) > { > struct resource *res; > unsigned long flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY; > - char *resource_name = "System RAM"; > > /* > * Make sure value parsed from 'mem=' only restricts memory adding > @@ -1058,7 +1058,8 @@ int __ref add_memory_resource(int nid, struct resource *res, > BUG_ON(ret); > > /* cre...

...0; if (sz < kbuf->memsz) diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index 4c47b68a9f4b5..8e1cd18b5cf14 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -105,7 +105,7 @@ static struct resource *register_memory_resource(u64 start, u64 size, unsigned long flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY; if (strcmp(resource_name, "System RAM")) - flags |= IORESOURCE_MEM_DRIVER_MANAGED; + flags |= IORESOURCE_SYSRAM_DRIVER_MANAGED; /* * Make sure value parsed from 'mem=' only restricts memory adding @@ -1160,7 +1160,7 @@ EXPORT_SYMBOL_GPL(add_memory);...

...ivers/dax/kmem.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c index e159184e0ba0..929823a79816 100644 --- a/drivers/dax/kmem.c +++ b/drivers/dax/kmem.c @@ -65,7 +65,8 @@ int dev_dax_kmem_probe(struct device *dev) new_res->flags = IORESOURCE_SYSTEM_RAM; new_res->name = dev_name(dev); - rc = add_memory(numa_node, new_res->start, resource_size(new_res), 0); + rc = add_memory(numa_node, new_res->start, resource_size(new_res), + MHP_NO_FIRMWARE_MEMMAP); if (rc) { release_resource(new_res); kfree(new_res); -- 2.25.3

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

...u64 max_mem_size = U64_MAX; /* add this memory to iomem resource */ -static struct resource *register_memory_resource(u64 start, u64 size) +static struct resource *register_memory_resource(u64 start, u64 size, + const char *resource_name) { struct resource *res; unsigned long flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY; - char *resource_name = "System RAM"; /* * Make sure value parsed from 'mem=' only restricts memory adding @@ -1058,7 +1058,8 @@ int __ref add_memory_resource(int nid, struct resource *res, BUG_ON(ret); /* create new memmap entry */ - firmware_map_a...

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

...egister_memory_resource(u64 start, u64 size) > > +static struct resource *register_memory_resource(u64 start, u64 size, > > + const char *resource_name) > > { > > struct resource *res; > > unsigned long flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY; > > - char *resource_name = "System RAM"; > > > > /* > > * Make sure value parsed from 'mem=' only restricts memory adding > > @@ -1058,7 +1058,8 @@ int __ref add_memory_resource(int nid, struct resource *res, >...

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

...resource(u64 start, u64 size) >>> +static struct resource *register_memory_resource(u64 start, u64 size, >>> + const char *resource_name) >>> { >>> struct resource *res; >>> unsigned long flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY; >>> - char *resource_name = "System RAM"; >>> >>> /* >>> * Make sure value parsed from 'mem=' only restricts memory adding >>> @@ -1058,7 +1058,8 @@ int __ref add_memory_resource(int nid, struct resou...

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

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

This series is based on v5.7-rc4. The patches are located at: https://github.com/davidhildenbrand/linux.git virtio-mem-v4 This is basically a resend of v3 [1], now based on v5.7-rc4 and restested. One patch was reshuffled and two ACKs I missed to add were added. The rebase did not require any modifications to patches. Details about virtio-mem can be found in the cover letter of v2 [2]. A

This series is based on latest linux-next. The patches are located at: https://github.com/davidhildenbrand/linux.git virtio-mem-v3 Patch #1 - #10 where contained in v2 and only contain minor modifications (mostly smaller fixes). The remaining patches are new and contain smaller optimizations. Details about virtio-mem can be found in the cover letter of v2 [1]. A basic QEMU implementation was

This series is based on latest linux-next. The patches are located at: https://github.com/davidhildenbrand/linux.git virtio-mem-v3 Patch #1 - #10 where contained in v2 and only contain minor modifications (mostly smaller fixes). The remaining patches are new and contain smaller optimizations. Details about virtio-mem can be found in the cover letter of v2 [1]. A basic QEMU implementation was