* [PATCH v2 0/3] mm/memory_hotplug: Allow to not create firmware memmap entries
From: David Hildenbrand @ 2020-04-30 10:29 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mm, virtio-dev, virtualization, linuxppc-dev, linux-acpi,
linux-nvdimm, linux-hyperv, linux-s390, xen-devel, Michal Hocko,
Andrew Morton, Michael S . Tsirkin, David Hildenbrand, Baoquan He,
Benjamin Herrenschmidt, Boris Ostrovsky, Christian Borntraeger,
Dan Williams, Dave Hansen, Dave Jiang, Eric Biederman,
Greg Kroah-Hartman, Haiyang Zhang, Heiko Carstens, Jason Wang,
Juergen Gross, K. Y. Srinivasan, Len Brown, Leonardo Bras,
Michael Ellerman, Michal Hocko, Nathan Lynch, Oscar Salvador,
Pankaj Gupta, Paul Mackerras, Pavel Tatashin, Pingfan Liu,
Rafael J. Wysocki, Stefano Stabellini, Stephen Hemminger,
Thomas Gleixner, Vasily Gorbik, Vishal Verma, Wei Liu, Wei Yang
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 /proc/iomem) to
the elfcorehdr, so this memory will never get included in a dump. This
probably has to be fixed in kexec-tools - virtio-mem will require this as
well.
v1 -> v2:
- Don't change the resource name
- Rename the flag to MHP_NO_FIRMWARE_MEMMAP to reflect what it is doing
- Rephrase subjects/descriptions
- Use the flag for dax/kmem
I'll have to rebase virtio-mem on these changes, there will be a resend.
[1] https://lkml.kernel.org/r/20200429160803.109056-1-david@redhat.com
David Hildenbrand (3):
mm/memory_hotplug: Prepare passing flags to add_memory() and friends
mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
device-dax: Add system ram (add_memory()) with MHP_NO_FIRMWARE_MEMMAP
arch/powerpc/platforms/powernv/memtrace.c | 2 +-
arch/powerpc/platforms/pseries/hotplug-memory.c | 2 +-
drivers/acpi/acpi_memhotplug.c | 2 +-
drivers/base/memory.c | 2 +-
drivers/dax/kmem.c | 3 ++-
drivers/hv/hv_balloon.c | 2 +-
drivers/s390/char/sclp_cmd.c | 2 +-
drivers/xen/balloon.c | 2 +-
include/linux/memory_hotplug.h | 15 ++++++++++++---
mm/memory_hotplug.c | 14 ++++++++------
10 files changed, 29 insertions(+), 17 deletions(-)
--
2.25.3
^ permalink raw reply
* [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
From: David Hildenbrand @ 2020-04-30 10:29 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mm, virtio-dev, virtualization, linuxppc-dev, linux-acpi,
linux-nvdimm, linux-hyperv, linux-s390, xen-devel, Michal Hocko,
Andrew Morton, Michael S . Tsirkin, David Hildenbrand,
Michal Hocko, Pankaj Gupta, Wei Yang, Baoquan He, Eric Biederman
In-Reply-To: <20200430102908.10107-1-david@redhat.com>
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 /sys/firmware/memmap/ is
wrong:
"kexec needs the raw firmware-provided 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@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
---
include/linux/memory_hotplug.h | 8 ++++++++
mm/memory_hotplug.c | 3 ++-
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index 0151fb935c09..4ca418a731eb 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -68,6 +68,14 @@ struct mhp_params {
pgprot_t pgprot;
};
+/* Flags used for add_memory() and friends. */
+
+/*
+ * Don't create entries in /sys/firmware/memmap/. The memory is detected and
+ * added via a device driver, not via the initial (firmware) memmap.
+ */
+#define MHP_NO_FIRMWARE_MEMMAP 1
+
/*
* Zone resizing functions
*
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index c01be92693e3..e94ede9cad00 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1062,7 +1062,8 @@ int __ref add_memory_resource(int nid, struct resource *res,
BUG_ON(ret);
/* create new memmap entry */
- firmware_map_add_hotplug(start, start + size, "System RAM");
+ if (!(flags & MHP_NO_FIRMWARE_MEMMAP))
+ firmware_map_add_hotplug(start, start + size, "System RAM");
/* device_online() will take the lock when calling online_pages() */
mem_hotplug_done();
--
2.25.3
^ permalink raw reply related
* [PATCH v2 1/3] mm/memory_hotplug: Prepare passing flags to add_memory() and friends
From: David Hildenbrand @ 2020-04-30 10:29 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mm, virtio-dev, virtualization, linuxppc-dev, linux-acpi,
linux-nvdimm, linux-hyperv, linux-s390, xen-devel, Michal Hocko,
Andrew Morton, Michael S . Tsirkin, David Hildenbrand, Wei Liu,
Michael Ellerman, Benjamin Herrenschmidt, Paul Mackerras,
Rafael J. Wysocki, Len Brown, Greg Kroah-Hartman, Dan Williams,
Vishal Verma, Dave Jiang, K. Y. Srinivasan, Haiyang Zhang,
Stephen Hemminger, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Jason Wang, Boris Ostrovsky, Juergen Gross,
Stefano Stabellini, Thomas Gleixner, Pingfan Liu, Leonardo Bras,
Nathan Lynch, Oscar Salvador, Michal Hocko, Baoquan He, Wei Yang,
Pankaj Gupta, Eric Biederman
In-Reply-To: <20200430102908.10107-1-david@redhat.com>
We soon want to pass flags - prepare for that.
This patch is based on a similar patch by Oscar Salvador:
https://lkml.kernel.org/r/20190625075227.15193-3-osalvador@suse.de
Acked-by: Wei Liu <wei.liu@kernel.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: Dave Jiang <dave.jiang@intel.com>
Cc: "K. Y. Srinivasan" <kys@microsoft.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Stephen Hemminger <sthemmin@microsoft.com>
Cc: Wei Liu <wei.liu@kernel.org>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Pingfan Liu <kernelfans@gmail.com>
Cc: Leonardo Bras <leobras.c@gmail.com>
Cc: Nathan Lynch <nathanl@linux.ibm.com>
Cc: Oscar Salvador <osalvador@suse.de>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-acpi@vger.kernel.org
Cc: linux-nvdimm@lists.01.org
Cc: linux-hyperv@vger.kernel.org
Cc: linux-s390@vger.kernel.org
Cc: virtualization@lists.linux-foundation.org
Cc: xen-devel@lists.xenproject.org
Signed-off-by: David Hildenbrand <david@redhat.com>
---
arch/powerpc/platforms/powernv/memtrace.c | 2 +-
arch/powerpc/platforms/pseries/hotplug-memory.c | 2 +-
drivers/acpi/acpi_memhotplug.c | 2 +-
drivers/base/memory.c | 2 +-
drivers/dax/kmem.c | 2 +-
drivers/hv/hv_balloon.c | 2 +-
drivers/s390/char/sclp_cmd.c | 2 +-
drivers/xen/balloon.c | 2 +-
include/linux/memory_hotplug.h | 7 ++++---
mm/memory_hotplug.c | 11 ++++++-----
10 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/memtrace.c b/arch/powerpc/platforms/powernv/memtrace.c
index 13b369d2cc45..a7475d18c671 100644
--- a/arch/powerpc/platforms/powernv/memtrace.c
+++ b/arch/powerpc/platforms/powernv/memtrace.c
@@ -224,7 +224,7 @@ static int memtrace_online(void)
ent->mem = 0;
}
- if (add_memory(ent->nid, ent->start, ent->size)) {
+ if (add_memory(ent->nid, ent->start, ent->size, 0)) {
pr_err("Failed to add trace memory to node %d\n",
ent->nid);
ret += 1;
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
index 5ace2f9a277e..ae44eba46ca0 100644
--- a/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -646,7 +646,7 @@ static int dlpar_add_lmb(struct drmem_lmb *lmb)
block_sz = memory_block_size_bytes();
/* Add the memory */
- rc = __add_memory(lmb->nid, lmb->base_addr, block_sz);
+ rc = __add_memory(lmb->nid, lmb->base_addr, block_sz, 0);
if (rc) {
invalidate_lmb_associativity_index(lmb);
return rc;
diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index e294f44a7850..d91b3584d4b2 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -207,7 +207,7 @@ static int acpi_memory_enable_device(struct acpi_memory_device *mem_device)
if (node < 0)
node = memory_add_physaddr_to_nid(info->start_addr);
- result = __add_memory(node, info->start_addr, info->length);
+ result = __add_memory(node, info->start_addr, info->length, 0);
/*
* If the memory block has been used by the kernel, add_memory()
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index 2b09b68b9f78..c0ef7d9e310a 100644
--- a/drivers/base/memory.c
+++ b/drivers/base/memory.c
@@ -432,7 +432,7 @@ static ssize_t probe_store(struct device *dev, struct device_attribute *attr,
nid = memory_add_physaddr_to_nid(phys_addr);
ret = __add_memory(nid, phys_addr,
- MIN_MEMORY_BLOCK_SIZE * sections_per_block);
+ MIN_MEMORY_BLOCK_SIZE * sections_per_block, 0);
if (ret)
goto out;
diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c
index 3d0a7e702c94..e159184e0ba0 100644
--- a/drivers/dax/kmem.c
+++ b/drivers/dax/kmem.c
@@ -65,7 +65,7 @@ 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));
+ rc = add_memory(numa_node, new_res->start, resource_size(new_res), 0);
if (rc) {
release_resource(new_res);
kfree(new_res);
diff --git a/drivers/hv/hv_balloon.c b/drivers/hv/hv_balloon.c
index 32e3bc0aa665..0194bed1a573 100644
--- a/drivers/hv/hv_balloon.c
+++ b/drivers/hv/hv_balloon.c
@@ -726,7 +726,7 @@ static void hv_mem_hot_add(unsigned long start, unsigned long size,
nid = memory_add_physaddr_to_nid(PFN_PHYS(start_pfn));
ret = add_memory(nid, PFN_PHYS((start_pfn)),
- (HA_CHUNK << PAGE_SHIFT));
+ (HA_CHUNK << PAGE_SHIFT), 0);
if (ret) {
pr_err("hot_add memory failed error is %d\n", ret);
diff --git a/drivers/s390/char/sclp_cmd.c b/drivers/s390/char/sclp_cmd.c
index a864b21af602..a6a908244c74 100644
--- a/drivers/s390/char/sclp_cmd.c
+++ b/drivers/s390/char/sclp_cmd.c
@@ -406,7 +406,7 @@ static void __init add_memory_merged(u16 rn)
if (!size)
goto skip_add;
for (addr = start; addr < start + size; addr += block_size)
- add_memory(0, addr, block_size);
+ add_memory(0, addr, block_size, 0);
skip_add:
first_rn = rn;
num = 1;
diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 0c142bcab79d..6ec0373fa624 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -347,7 +347,7 @@ static enum bp_state reserve_additional_memory(void)
mutex_unlock(&balloon_mutex);
/* add_memory_resource() requires the device_hotplug lock */
lock_device_hotplug();
- rc = add_memory_resource(nid, resource);
+ rc = add_memory_resource(nid, resource, 0);
unlock_device_hotplug();
mutex_lock(&balloon_mutex);
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index 7dca9cd6076b..0151fb935c09 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -339,9 +339,10 @@ extern void set_zone_contiguous(struct zone *zone);
extern void clear_zone_contiguous(struct zone *zone);
extern void __ref free_area_init_core_hotplug(int nid);
-extern int __add_memory(int nid, u64 start, u64 size);
-extern int add_memory(int nid, u64 start, u64 size);
-extern int add_memory_resource(int nid, struct resource *resource);
+extern int __add_memory(int nid, u64 start, u64 size, unsigned long flags);
+extern int add_memory(int nid, u64 start, u64 size, unsigned long flags);
+extern int add_memory_resource(int nid, struct resource *resource,
+ unsigned long flags);
extern void move_pfn_range_to_zone(struct zone *zone, unsigned long start_pfn,
unsigned long nr_pages, struct vmem_altmap *altmap);
extern void remove_pfn_range_from_zone(struct zone *zone,
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 555137bd0882..c01be92693e3 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1004,7 +1004,8 @@ static int online_memory_block(struct memory_block *mem, void *arg)
*
* we are OK calling __meminit stuff here - we have CONFIG_MEMORY_HOTPLUG
*/
-int __ref add_memory_resource(int nid, struct resource *res)
+int __ref add_memory_resource(int nid, struct resource *res,
+ unsigned long flags)
{
struct mhp_params params = { .pgprot = PAGE_KERNEL };
u64 start, size;
@@ -1082,7 +1083,7 @@ int __ref add_memory_resource(int nid, struct resource *res)
}
/* requires device_hotplug_lock, see add_memory_resource() */
-int __ref __add_memory(int nid, u64 start, u64 size)
+int __ref __add_memory(int nid, u64 start, u64 size, unsigned long flags)
{
struct resource *res;
int ret;
@@ -1091,18 +1092,18 @@ int __ref __add_memory(int nid, u64 start, u64 size)
if (IS_ERR(res))
return PTR_ERR(res);
- ret = add_memory_resource(nid, res);
+ ret = add_memory_resource(nid, res, flags);
if (ret < 0)
release_memory_resource(res);
return ret;
}
-int add_memory(int nid, u64 start, u64 size)
+int add_memory(int nid, u64 start, u64 size, unsigned long flags)
{
int rc;
lock_device_hotplug();
- rc = __add_memory(nid, start, size);
+ rc = __add_memory(nid, start, size, flags);
unlock_device_hotplug();
return rc;
--
2.25.3
^ permalink raw reply related
* [PATCH v2 3/3] device-dax: Add system ram (add_memory()) with MHP_NO_FIRMWARE_MEMMAP
From: David Hildenbrand @ 2020-04-30 10:29 UTC (permalink / raw)
To: linux-kernel
Cc: linux-mm, virtio-dev, virtualization, linuxppc-dev, linux-acpi,
linux-nvdimm, linux-hyperv, linux-s390, xen-devel, Michal Hocko,
Andrew Morton, Michael S . Tsirkin, David Hildenbrand,
Michal Hocko, Pankaj Gupta, Wei Yang, Baoquan He, Dave Hansen,
Eric Biederman, Pavel Tatashin, Dan Williams
In-Reply-To: <20200430102908.10107-1-david@redhat.com>
Currently, when adding memory, we create entries in /sys/firmware/memmap/
as "System RAM". This does not reflect the reality and will lead to
kexec-tools to add that memory to the fixed-up initial memmap for a
kexec kernel (loaded via kexec_load()). The memory will be considered
initial System RAM by the kexec kernel.
We should let the kexec kernel decide how to use that memory - just as
we do during an ordinary reboot.
Before configuring the namespace:
[root@localhost ~]# cat /proc/iomem
...
140000000-33fffffff : Persistent Memory
140000000-33fffffff : namespace0.0
3280000000-32ffffffff : PCI Bus 0000:00
After configuring the namespace:
[root@localhost ~]# cat /proc/iomem
...
140000000-33fffffff : Persistent Memory
140000000-1481fffff : namespace0.0
148200000-33fffffff : dax0.0
3280000000-32ffffffff : PCI Bus 0000:00
After loading kmem:
[root@localhost ~]# cat /proc/iomem
...
140000000-33fffffff : Persistent Memory
140000000-1481fffff : namespace0.0
150000000-33fffffff : dax0.0
150000000-33fffffff : System RAM
3280000000-32ffffffff : PCI Bus 0000:00
After a proper reboot:
[root@localhost ~]# cat /proc/iomem
...
140000000-33fffffff : Persistent Memory
140000000-1481fffff : namespace0.0
148200000-33fffffff : dax0.0
3280000000-32ffffffff : PCI Bus 0000:00
Within the kexec kernel before this change:
[root@localhost ~]# cat /proc/iomem
...
140000000-33fffffff : Persistent Memory
140000000-1481fffff : namespace0.0
150000000-33fffffff : System RAM
3280000000-32ffffffff : PCI Bus 0000:00
Within the kexec kernel after this change:
[root@localhost ~]# cat /proc/iomem
...
140000000-33fffffff : Persistent Memory
140000000-1481fffff : namespace0.0
148200000-33fffffff : dax0.0
3280000000-32ffffffff : PCI Bus 0000:00
/sys/firmware/memmap/ before this change:
0000000000000000-000000000009fc00 (System RAM)
000000000009fc00-00000000000a0000 (Reserved)
00000000000f0000-0000000000100000 (Reserved)
0000000000100000-00000000bffdf000 (System RAM)
00000000bffdf000-00000000c0000000 (Reserved)
00000000feffc000-00000000ff000000 (Reserved)
00000000fffc0000-0000000100000000 (Reserved)
0000000100000000-0000000140000000 (System RAM)
0000000150000000-0000000340000000 (System RAM)
/sys/firmware/memmap/ after a proper reboot:
0000000000000000-000000000009fc00 (System RAM)
000000000009fc00-00000000000a0000 (Reserved)
00000000000f0000-0000000000100000 (Reserved)
0000000000100000-00000000bffdf000 (System RAM)
00000000bffdf000-00000000c0000000 (Reserved)
00000000feffc000-00000000ff000000 (Reserved)
00000000fffc0000-0000000100000000 (Reserved)
0000000100000000-0000000140000000 (System RAM)
/sys/firmware/memmap/ after this change:
0000000000000000-000000000009fc00 (System RAM)
000000000009fc00-00000000000a0000 (Reserved)
00000000000f0000-0000000000100000 (Reserved)
0000000000100000-00000000bffdf000 (System RAM)
00000000bffdf000-00000000c0000000 (Reserved)
00000000feffc000-00000000ff000000 (Reserved)
00000000fffc0000-0000000100000000 (Reserved)
0000000100000000-0000000140000000 (System RAM)
kexec-tools already seem to basically ignore any System RAM that's not
on top level when searching for areas to place kexec images - but also
for determining crash areas to dump via kdump. This behavior is not
changed by this patch. kexec-tools probably has to be fixed to also
include this memory in system dumps.
Note: kexec_file_load() does the right thing already within the kernel.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
Cc: Wei Yang <richard.weiyang@gmail.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: David Hildenbrand <david@redhat.com>
---
drivers/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
^ permalink raw reply related
* Re: [PATCH v2 3/3] device-dax: Add system ram (add_memory()) with MHP_NO_FIRMWARE_MEMMAP
From: Dave Hansen @ 2020-04-30 11:23 UTC (permalink / raw)
To: David Hildenbrand, linux-kernel
Cc: linux-mm, virtio-dev, virtualization, linuxppc-dev, linux-acpi,
linux-nvdimm, linux-hyperv, linux-s390, xen-devel, Michal Hocko,
Andrew Morton, Michael S . Tsirkin, Michal Hocko, Pankaj Gupta,
Wei Yang, Baoquan He, Dave Hansen, Eric Biederman, Pavel Tatashin,
Dan Williams
In-Reply-To: <20200430102908.10107-4-david@redhat.com>
On 4/30/20 3:29 AM, David Hildenbrand wrote:
> Currently, when adding memory, we create entries in /sys/firmware/memmap/
> as "System RAM". This does not reflect the reality and will lead to
> kexec-tools to add that memory to the fixed-up initial memmap for a
> kexec kernel (loaded via kexec_load()). The memory will be considered
> initial System RAM by the kexec kernel.
>
> We should let the kexec kernel decide how to use that memory - just as
> we do during an ordinary reboot.
...
> - 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);
Looks fine. But, if you send another revision, could you add a comment
about the actual goal of MHP_NO_FIRMWARE_MEMMAP? Maybe:
/*
* MHP_NO_FIRMWARE_MEMMAP ensures that future
* kexec'd kernels will not treat this as RAM.
*/
Not a biggie, though.
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
^ permalink raw reply
* Re: [PATCH v2 3/3] device-dax: Add system ram (add_memory()) with MHP_NO_FIRMWARE_MEMMAP
From: David Hildenbrand @ 2020-04-30 15:28 UTC (permalink / raw)
To: Dave Hansen, linux-kernel
Cc: linux-mm, virtio-dev, virtualization, linuxppc-dev, linux-acpi,
linux-nvdimm, linux-hyperv, linux-s390, xen-devel, Michal Hocko,
Andrew Morton, Michael S . Tsirkin, Michal Hocko, Pankaj Gupta,
Wei Yang, Baoquan He, Dave Hansen, Eric Biederman, Pavel Tatashin,
Dan Williams
In-Reply-To: <20b86ced-7c47-02ca-0e0e-1bd5d6cc95c1@intel.com>
On 30.04.20 13:23, Dave Hansen wrote:
> On 4/30/20 3:29 AM, David Hildenbrand wrote:
>> Currently, when adding memory, we create entries in /sys/firmware/memmap/
>> as "System RAM". This does not reflect the reality and will lead to
>> kexec-tools to add that memory to the fixed-up initial memmap for a
>> kexec kernel (loaded via kexec_load()). The memory will be considered
>> initial System RAM by the kexec kernel.
>>
>> We should let the kexec kernel decide how to use that memory - just as
>> we do during an ordinary reboot.
> ...
>> - 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);
>
> Looks fine. But, if you send another revision, could you add a comment
> about the actual goal of MHP_NO_FIRMWARE_MEMMAP? Maybe:
>
> /*
> * MHP_NO_FIRMWARE_MEMMAP ensures that future
> * kexec'd kernels will not treat this as RAM.
> */
>
> Not a biggie, though.
Sure, maybe Andrew can fixup when applying (if no resend is necessary).
Thanks Dave!
>
> Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
>
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
From: Eric W. Biederman @ 2020-04-30 15:38 UTC (permalink / raw)
To: David Hildenbrand
Cc: linux-kernel, linux-mm, virtio-dev, virtualization, linuxppc-dev,
linux-acpi, linux-nvdimm, linux-hyperv, linux-s390, xen-devel,
Michal Hocko, Andrew Morton, Michael S . Tsirkin, Michal Hocko,
Pankaj Gupta, Wei Yang, Baoquan He
In-Reply-To: <20200430102908.10107-3-david@redhat.com>
David Hildenbrand <david@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 firmware memmap as System
> RAM (e.g., e820), so exposing this memory via /sys/firmware/memmap/ is
> wrong:
> "kexec needs the raw firmware-provided 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
You know what this justification is rubbish, and I have previously
explained why it is rubbish.
Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
This needs to be based on weather the added memory is ultimately normal
ram or is something special.
At least when we are talking memory resources. Keeping it out of the
firmware map that is fine.
If the hotplugged memory is the result of plugging a stick of ram
into the kernel and can and should used be like any other memory
it should be treated like any normal memory.
If the hotplugged memory is something special it should be treated as
something special.
Justifying behavior by documentation that does not consider memory
hotplug is bad thinking.
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Pankaj Gupta <pankaj.gupta.linux@gmail.com>
> Cc: Wei Yang <richard.weiyang@gmail.com>
> Cc: Baoquan He <bhe@redhat.com>
> Cc: Eric Biederman <ebiederm@xmission.com>
> Signed-off-by: David Hildenbrand <david@redhat.com>
> ---
> include/linux/memory_hotplug.h | 8 ++++++++
> mm/memory_hotplug.c | 3 ++-
> 2 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
> index 0151fb935c09..4ca418a731eb 100644
> --- a/include/linux/memory_hotplug.h
> +++ b/include/linux/memory_hotplug.h
> @@ -68,6 +68,14 @@ struct mhp_params {
> pgprot_t pgprot;
> };
>
> +/* Flags used for add_memory() and friends. */
> +
> +/*
> + * Don't create entries in /sys/firmware/memmap/. The memory is detected and
> + * added via a device driver, not via the initial (firmware) memmap.
> + */
> +#define MHP_NO_FIRMWARE_MEMMAP 1
> +
> /*
> * Zone resizing functions
> *
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index c01be92693e3..e94ede9cad00 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1062,7 +1062,8 @@ int __ref add_memory_resource(int nid, struct resource *res,
> BUG_ON(ret);
>
> /* create new memmap entry */
> - firmware_map_add_hotplug(start, start + size, "System RAM");
> + if (!(flags & MHP_NO_FIRMWARE_MEMMAP))
> + firmware_map_add_hotplug(start, start + size, "System RAM");
>
> /* device_online() will take the lock when calling online_pages() */
> mem_hotplug_done();
^ permalink raw reply
* RE: [PATCH v2] hv_netvsc: Fix netvsc_start_xmit's return type
From: Haiyang Zhang @ 2020-04-30 15:42 UTC (permalink / raw)
To: Nathan Chancellor, Michael Kelley
Cc: KY Srinivasan, Stephen Hemminger, Wei Liu,
linux-hyperv@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, clang-built-linux@googlegroups.com,
Sami Tolvanen
In-Reply-To: <20200430060151.GA3548130@ubuntu-s3-xlarge-x86>
> -----Original Message-----
> From: Nathan Chancellor <natechancellor@gmail.com>
> Sent: Thursday, April 30, 2020 2:02 AM
> To: Michael Kelley <mikelley@microsoft.com>
> Cc: KY Srinivasan <kys@microsoft.com>; Haiyang Zhang
> <haiyangz@microsoft.com>; Stephen Hemminger
> <sthemmin@microsoft.com>; Wei Liu <wei.liu@kernel.org>; linux-
> hyperv@vger.kernel.org; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; clang-built-linux@googlegroups.com; Sami
> Tolvanen <samitolvanen@google.com>
> Subject: Re: [PATCH v2] hv_netvsc: Fix netvsc_start_xmit's return type
>
> Hi Michael,
>
> On Thu, Apr 30, 2020 at 12:06:09AM +0000, Michael Kelley wrote:
> > From: Nathan Chancellor <natechancellor@gmail.com> Sent: Tuesday,
> > April 28, 2020 10:55 AM
> > >
> > > Do note that netvsc_xmit still returns int because netvsc_xmit has a
> > > potential return from netvsc_vf_xmit, which does not return
> > > netdev_tx_t because of the call to dev_queue_xmit.
> > >
> > > I am not sure if that is an oversight that was introduced by commit
> > > 0c195567a8f6e ("netvsc: transparent VF management") or if everything
> > > works properly as it is now.
> > >
> > > My patch is purely concerned with making the definition match the
> > > prototype so it should be NFC aside from avoiding the CFI panic.
> > >
> >
> > While it probably works correctly now, I'm not too keen on just
> > changing the return type for netvsc_start_xmit() and assuming the
> > 'int' that is returned from netvsc_xmit() will be correctly mapped to
> > the netdev_tx_t enum type. While that mapping probably happens
> > correctly at the moment, this really should have a more holistic fix.
>
> While it might work correctly, I am not sure that the mapping is correct,
> hence that comment.
>
> netdev_tx_t is an enum with two acceptable types, 0x00 and 0x10. Up until
> commit 0c195567a8f6e ("netvsc: transparent VF management"), netvsc_xmit
> was guaranteed to return something of type netdev_tx_t.
>
> However, after said commit, we could return anything from netvsc_vf_xmit,
> which in turn calls dev_queue_xmit then __dev_queue_xmit which will
> return either an error code (-ENOMEM or
> -ENETDOWN) or something from __dev_xmit_skb, which appears to be
> NET_XMIT_SUCCESS, NET_XMIT_DROP, or NET_XMIT_CN.
>
> It does not look like netvsc_xmit or netvsc_vf_xmit try to convert those
> returns to netdev_tx_t in some way; netvsc_vf_xmit just passes the return
> value up to netvsc_xmit, which is the part that I am unsure about...
>
> > Nathan -- are you willing to look at doing the more holistic fix? Or
> > should we see about asking Haiyang Zhang to do it?
>
> I would be fine trying to look at a more holistic fix but I know basically nothing
> about this subsystem. I am unsure if something like this would be acceptable
> or if something else needs to happen.
> Otherwise, I'd be fine with you guys taking a look and just giving me
> reported-by credit.
Here is more info regarding Linux network subsystem:
As said in "include/linux/netdevice.h", drivers are allowed to return any codes
from the three different namespaces.
And hv_netvsc needs to support "transparent VF", and calls netvsc_vf_xmit >>
dev_queue_xmit which returns qdisc return codes, and errnos like -ENOMEM,
etc. These are compliant with the guideline below:
79 /*
80 * Transmit return codes: transmit return codes originate from three different
81 * namespaces:
82 *
83 * - qdisc return codes
84 * - driver transmit return codes
85 * - errno values
86 *
87 * Drivers are allowed to return any one of those in their hard_start_xmit()
Also, ndo_start_xmit function pointer is used by upper layer functions which can
handles three types of the return codes.
For example, in the calling stack: ndo_start_xmit << netdev_start_xmit <<
xmit_one << dev_hard_start_xmit():
The function dev_hard_start_xmit() uses dev_xmit_complete() to handle the
return codes. It handles three types of the return codes correctly.
3483 struct sk_buff *dev_hard_start_xmit(struct sk_buff *first, struct net_device *dev,
3484 struct netdev_queue *txq, int *ret)
3485 {
3486 struct sk_buff *skb = first;
3487 int rc = NETDEV_TX_OK;
3488
3489 while (skb) {
3490 struct sk_buff *next = skb->next;
3491
3492 skb_mark_not_on_list(skb);
3493 rc = xmit_one(skb, dev, txq, next != NULL);
3494 if (unlikely(!dev_xmit_complete(rc))) {
3495 skb->next = next;
3496 goto out;
3497 }
3498
3499 skb = next;
3500 if (netif_tx_queue_stopped(txq) && skb) {
3501 rc = NETDEV_TX_BUSY;
3502 break;
3503 }
3504 }
3505
3506 out:
3507 *ret = rc;
3508 return skb;
3509 }
118 /*
119 * Current order: NETDEV_TX_MASK > NET_XMIT_MASK >= 0 is significant;
120 * hard_start_xmit() return < NET_XMIT_MASK means skb was consumed.
121 */
122 static inline bool dev_xmit_complete(int rc)
123 {
124 /*
125 * Positive cases with an skb consumed by a driver:
126 * - successful transmission (rc == NETDEV_TX_OK)
127 * - error while transmitting (rc < 0)
128 * - error while queueing to a different device (rc & NET_XMIT_MASK)
129 */
130 if (likely(rc < NET_XMIT_MASK))
131 return true;
132
133 return false;
134 }
Regarding "a more holistic fix", I believe the return type of ndo_start_xmit should be
int, because of three namespaces of the return codes. This means to change all network
drivers. I'm not proposing to do this big change right now.
So I have no objection of your patch.
Thanks,
- Haiyang
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
^ permalink raw reply
* Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
From: David Hildenbrand @ 2020-04-30 15:52 UTC (permalink / raw)
To: Eric W. Biederman
Cc: linux-kernel, linux-mm, virtio-dev, virtualization, linuxppc-dev,
linux-acpi, linux-nvdimm, linux-hyperv, linux-s390, xen-devel,
Michal Hocko, Andrew Morton, Michael S . Tsirkin, Michal Hocko,
Pankaj Gupta, Wei Yang, Baoquan He
In-Reply-To: <87pnbp2dcz.fsf@x220.int.ebiederm.org>
On 30.04.20 17:38, Eric W. Biederman wrote:
> David Hildenbrand <david@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 firmware memmap as System
>> RAM (e.g., e820), so exposing this memory via /sys/firmware/memmap/ is
>> wrong:
>> "kexec needs the raw firmware-provided 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
>
>
> You know what this justification is rubbish, and I have previously
> explained why it is rubbish.
Actually, no, I don't think it is rubbish. See patch #3 and the cover
letter why this is the right thing to do *for special memory*, *not
ordinary DIMMs*.
And to be quite honest, I think your response is a little harsh. I don't
recall you replying to my virtio-mem-related comments.
>
> Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
>
> This needs to be based on weather the added memory is ultimately normal
> ram or is something special.
Yes, that's what the caller are expected to decide, see patch #3.
kexec should try to be as closely as possible to a real reboot - IMHO.
>
> At least when we are talking memory resources. Keeping it out of the
> firmware map that is fine.
>
> If the hotplugged memory is the result of plugging a stick of ram
> into the kernel and can and should used be like any other memory
> it should be treated like any normal memory.
>
> If the hotplugged memory is something special it should be treated as
> something special.
I am really sorry, I can't make sense of what you are trying to say here.
>
> Justifying behavior by documentation that does not consider memory
> hotplug is bad thinking.
Are you maybe confusing this patch series with the arm64 approach? This
is not about ordinary hotplugged DIMMs.
I'd love to get Dan's, Dave's and Michal's opinion.
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
From: Dave Hansen @ 2020-04-30 16:04 UTC (permalink / raw)
To: David Hildenbrand, Eric W. Biederman
Cc: linux-kernel, linux-mm, virtio-dev, virtualization, linuxppc-dev,
linux-acpi, linux-nvdimm, linux-hyperv, linux-s390, xen-devel,
Michal Hocko, Andrew Morton, Michael S . Tsirkin, Michal Hocko,
Pankaj Gupta, Wei Yang, Baoquan He
In-Reply-To: <1b49c3be-6e2f-57cb-96f7-f66a8f8a9380@redhat.com>
On 4/30/20 8:52 AM, David Hildenbrand wrote:
>> Justifying behavior by documentation that does not consider memory
>> hotplug is bad thinking.
> Are you maybe confusing this patch series with the arm64 approach? This
> is not about ordinary hotplugged DIMMs.
>
> I'd love to get Dan's, Dave's and Michal's opinion.
The impact on kexec from the DAX "kmem" driver's use of hotplug was
inadvertent and unfortunate.
The problem statement and solution seem pretty sane to me.
^ permalink raw reply
* Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
From: Eric W. Biederman @ 2020-04-30 16:33 UTC (permalink / raw)
To: David Hildenbrand
Cc: linux-kernel, linux-mm, virtio-dev, virtualization, linuxppc-dev,
linux-acpi, linux-nvdimm, linux-hyperv, linux-s390, xen-devel,
Michal Hocko, Andrew Morton, Michael S . Tsirkin, Michal Hocko,
Pankaj Gupta, Wei Yang, Baoquan He
In-Reply-To: <1b49c3be-6e2f-57cb-96f7-f66a8f8a9380@redhat.com>
David Hildenbrand <david@redhat.com> writes:
> On 30.04.20 17:38, Eric W. Biederman wrote:
>> David Hildenbrand <david@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 firmware memmap as System
>>> RAM (e.g., e820), so exposing this memory via /sys/firmware/memmap/ is
>>> wrong:
>>> "kexec needs the raw firmware-provided 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
>>
>>
>> You know what this justification is rubbish, and I have previously
>> explained why it is rubbish.
>
> Actually, no, I don't think it is rubbish. See patch #3 and the cover
> letter why this is the right thing to do *for special memory*, *not
> ordinary DIMMs*.
>
> And to be quite honest, I think your response is a little harsh. I don't
> recall you replying to my virtio-mem-related comments.
>
>>
>> Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
>>
>> This needs to be based on weather the added memory is ultimately normal
>> ram or is something special.
>
> Yes, that's what the caller are expected to decide, see patch #3.
>
> kexec should try to be as closely as possible to a real reboot - IMHO.
That is very fuzzy in terms of hotplug memory. The kexec'd kernel
should see the hotplugged memory assuming it is ordinary memory.
But kexec is not a reboot although it is quite similar. Kexec is
swapping one running kernel and it's state for another kernel without
rebooting.
>> Justifying behavior by documentation that does not consider memory
>> hotplug is bad thinking.
>
> Are you maybe confusing this patch series with the arm64 approach? This
> is not about ordinary hotplugged DIMMs.
I think I am.
My challenge is that I don't see anything in the description that says
this isn't about ordinary hotplugged DIMMs. All I saw was hotplug
memory.
If the class of memory is different then please by all means let's mark
it differently in struct resource so everyone knows it is different.
But that difference needs to be more than hotplug.
That difference needs to be the hypervisor loaned us memory and might
take it back at any time, or this memory is persistent and so it has
these different characteristics so don't use it as ordinary ram.
That information is also useful to other people looking at the system
and seeing what is going on.
Just please don't muddle the concepts, or assume that whatever subset of
hotplug memory you are dealing with is the only subset.
I didn't see that flag making the distinction about the kind of memory
it is.
Eric
^ permalink raw reply
* Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
From: David Hildenbrand @ 2020-04-30 16:49 UTC (permalink / raw)
To: Eric W. Biederman
Cc: linux-kernel, linux-mm, virtio-dev, virtualization, linuxppc-dev,
linux-acpi, linux-nvdimm, linux-hyperv, linux-s390, xen-devel,
Michal Hocko, Andrew Morton, Michael S . Tsirkin, Michal Hocko,
Pankaj Gupta, Wei Yang, Baoquan He
In-Reply-To: <871ro52ary.fsf@x220.int.ebiederm.org>
On 30.04.20 18:33, Eric W. Biederman wrote:
> David Hildenbrand <david@redhat.com> writes:
>
>> On 30.04.20 17:38, Eric W. Biederman wrote:
>>> David Hildenbrand <david@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 firmware memmap as System
>>>> RAM (e.g., e820), so exposing this memory via /sys/firmware/memmap/ is
>>>> wrong:
>>>> "kexec needs the raw firmware-provided 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
>>>
>>>
>>> You know what this justification is rubbish, and I have previously
>>> explained why it is rubbish.
>>
>> Actually, no, I don't think it is rubbish. See patch #3 and the cover
>> letter why this is the right thing to do *for special memory*, *not
>> ordinary DIMMs*.
>>
>> And to be quite honest, I think your response is a little harsh. I don't
>> recall you replying to my virtio-mem-related comments.
>>
>>>
>>> Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
>>>
>>> This needs to be based on weather the added memory is ultimately normal
>>> ram or is something special.
>>
>> Yes, that's what the caller are expected to decide, see patch #3.
>>
>> kexec should try to be as closely as possible to a real reboot - IMHO.
>
> That is very fuzzy in terms of hotplug memory. The kexec'd kernel
> should see the hotplugged memory assuming it is ordinary memory.
>
> But kexec is not a reboot although it is quite similar. Kexec is
> swapping one running kernel and it's state for another kernel without
> rebooting.
I agree (especially regarding the arm64 DIMM hotplug discussion).
However, for the two cases
a) dax/kmem
b) virtio-mem
We really want to let the driver take back control and figure out "what
to do with the memory".
>
>>> Justifying behavior by documentation that does not consider memory
>>> hotplug is bad thinking.
>>
>> Are you maybe confusing this patch series with the arm64 approach? This
>> is not about ordinary hotplugged DIMMs.
>
> I think I am.
>
> My challenge is that I don't see anything in the description that says
> this isn't about ordinary hotplugged DIMMs. All I saw was hotplug
> memory.
I'm sorry if that was confusing, I tried to stress that kmem and
virtio-mem is special in the description.
I squeezed a lot of that information into the cover letter and into
patch #3.
>
> If the class of memory is different then please by all means let's mark
> it differently in struct resource so everyone knows it is different.
> But that difference needs to be more than hotplug.
>
> That difference needs to be the hypervisor loaned us memory and might
> take it back at any time, or this memory is persistent and so it has
> these different characteristics so don't use it as ordinary ram.
Yes, and I think kmem took an excellent approach of explicitly putting
that "System RAM" into a resource hierarchy. That "System RAM" won't
show up as a root node under /proc/iomem (see patch #3), which already
results in kexec-tools to treat it in a special way. I am thinking about
doing the same for virtio-mem.
>
> That information is also useful to other people looking at the system
> and seeing what is going on.
>
> Just please don't muddle the concepts, or assume that whatever subset of
> hotplug memory you are dealing with is the only subset.
I can certainly rephrase the subject/description/comment, stating that
this is not to be used for ordinary hotplugged DIMMs - only when the
device driver is under control to decide what to do with that memory -
especially when kexec'ing.
(previously, I called this flag MHP_DRIVER_MANAGED, but I think
MHP_NO_FIRMWARE_MEMMAP is clearer, we just need a better description)
Would that make it clearer?
Thanks!
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
From: Eric W. Biederman @ 2020-04-30 18:06 UTC (permalink / raw)
To: David Hildenbrand
Cc: linux-kernel, linux-mm, virtio-dev, virtualization, linuxppc-dev,
linux-acpi, linux-nvdimm, linux-hyperv, linux-s390, xen-devel,
Michal Hocko, Andrew Morton, Michael S . Tsirkin, Michal Hocko,
Pankaj Gupta, Wei Yang, Baoquan He
In-Reply-To: <373a6898-4020-4af1-5b3d-f827d705dd77@redhat.com>
David Hildenbrand <david@redhat.com> writes:
> On 30.04.20 18:33, Eric W. Biederman wrote:
>> David Hildenbrand <david@redhat.com> writes:
>>
>>> On 30.04.20 17:38, Eric W. Biederman wrote:
>>>> David Hildenbrand <david@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 firmware memmap as System
>>>>> RAM (e.g., e820), so exposing this memory via /sys/firmware/memmap/ is
>>>>> wrong:
>>>>> "kexec needs the raw firmware-provided 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
>>>>
>>>>
>>>> You know what this justification is rubbish, and I have previously
>>>> explained why it is rubbish.
>>>
>>> Actually, no, I don't think it is rubbish. See patch #3 and the cover
>>> letter why this is the right thing to do *for special memory*, *not
>>> ordinary DIMMs*.
>>>
>>> And to be quite honest, I think your response is a little harsh. I don't
>>> recall you replying to my virtio-mem-related comments.
>>>
>>>>
>>>> Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
>>>>
>>>> This needs to be based on weather the added memory is ultimately normal
>>>> ram or is something special.
>>>
>>> Yes, that's what the caller are expected to decide, see patch #3.
>>>
>>> kexec should try to be as closely as possible to a real reboot - IMHO.
>>
>> That is very fuzzy in terms of hotplug memory. The kexec'd kernel
>> should see the hotplugged memory assuming it is ordinary memory.
>>
>> But kexec is not a reboot although it is quite similar. Kexec is
>> swapping one running kernel and it's state for another kernel without
>> rebooting.
>
> I agree (especially regarding the arm64 DIMM hotplug discussion).
> However, for the two cases
>
> a) dax/kmem
> b) virtio-mem
>
> We really want to let the driver take back control and figure out "what
> to do with the memory".
From reading your v1 cover letter (the description appears missing in
v2) I see what you are talking about with respect to virtio-mem.
So I will count virt-io mem as something different.
>>>> Justifying behavior by documentation that does not consider memory
>>>> hotplug is bad thinking.
>>>
>>> Are you maybe confusing this patch series with the arm64 approach? This
>>> is not about ordinary hotplugged DIMMs.
>>
>> I think I am.
>>
>> My challenge is that I don't see anything in the description that says
>> this isn't about ordinary hotplugged DIMMs. All I saw was hotplug
>> memory.
>
> I'm sorry if that was confusing, I tried to stress that kmem and
> virtio-mem is special in the description.
>
> I squeezed a lot of that information into the cover letter and into
> patch #3.
>> If the class of memory is different then please by all means let's mark
>> it differently in struct resource so everyone knows it is different.
>> But that difference needs to be more than hotplug.
>>
>> That difference needs to be the hypervisor loaned us memory and might
>> take it back at any time, or this memory is persistent and so it has
>> these different characteristics so don't use it as ordinary ram.
>
> Yes, and I think kmem took an excellent approach of explicitly putting
> that "System RAM" into a resource hierarchy. That "System RAM" won't
> show up as a root node under /proc/iomem (see patch #3), which already
> results in kexec-tools to treat it in a special way. I am thinking about
> doing the same for virtio-mem.
Reading this and your patch cover letters again my concern is that
the justification seems to be letting the tail wag the dog.
You want kexec-tools to behave in a certain way so you are changing the
kernel.
Rather it should be change the kernel to clearly reflect reality and if
you can get away without a change to kexec-tools that is a bonus.
>> That information is also useful to other people looking at the system
>> and seeing what is going on.
>>
>> Just please don't muddle the concepts, or assume that whatever subset of
>> hotplug memory you are dealing with is the only subset.
>
> I can certainly rephrase the subject/description/comment, stating that
> this is not to be used for ordinary hotplugged DIMMs - only when the
> device driver is under control to decide what to do with that memory -
> especially when kexec'ing.
>
> (previously, I called this flag MHP_DRIVER_MANAGED, but I think
> MHP_NO_FIRMWARE_MEMMAP is clearer, we just need a better description)
>
> Would that make it clearer?
I am not certain, but Andrew Morton deliberately added that
firmware_map_add_hotplug call. Which means that there is a reason
for putting hotplugged memory in the firmware map.
So the justification needs to take that reason into account. The
justification can not be it is hotplugged therefore it should not belong
in the firmware memory map. Unless you can show that
firmware_map_add_hotplug that was actually a bug and should be removed.
But as it has been that way since 2010 that seems like a long shot.
So my question is what is right for the firmware map?
Why does the firmware map support hotplug entries?
Once we have the answers to those questions we can figure out what logic
the special kinds of memory hotplug need.
Ref: d96ae5309165 ("memory-hotplug: create /sys/firmware/memmap entry for new memory")
Eric
^ permalink raw reply
* Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
From: David Hildenbrand @ 2020-04-30 18:43 UTC (permalink / raw)
To: Eric W. Biederman, Andrew Morton
Cc: linux-kernel, linux-mm, virtio-dev, virtualization, linuxppc-dev,
linux-acpi, linux-nvdimm, linux-hyperv, linux-s390, xen-devel,
Michal Hocko, Michael S . Tsirkin, Michal Hocko, Pankaj Gupta,
Wei Yang, Baoquan He
In-Reply-To: <875zdg26hp.fsf@x220.int.ebiederm.org>
>>> If the class of memory is different then please by all means let's mark
>>> it differently in struct resource so everyone knows it is different.
>>> But that difference needs to be more than hotplug.
>>>
>>> That difference needs to be the hypervisor loaned us memory and might
>>> take it back at any time, or this memory is persistent and so it has
>>> these different characteristics so don't use it as ordinary ram.
>>
>> Yes, and I think kmem took an excellent approach of explicitly putting
>> that "System RAM" into a resource hierarchy. That "System RAM" won't
>> show up as a root node under /proc/iomem (see patch #3), which already
>> results in kexec-tools to treat it in a special way. I am thinking about
>> doing the same for virtio-mem.
>
> Reading this and your patch cover letters again my concern is that
> the justification seems to be letting the tail wag the dog.
>
> You want kexec-tools to behave in a certain way so you are changing the
> kernel.
>
> Rather it should be change the kernel to clearly reflect reality and if
> you can get away without a change to kexec-tools that is a bonus.
>
Right, because user space has to have a way to figure out what to do.
But talking about the firmware memmap, indicating something via a "raw
firmware-provided memory map", that is not actually in the "raw
firmware-provided memory map" feels wrong to me. (below)
>>> That information is also useful to other people looking at the system
>>> and seeing what is going on.
>>>
>>> Just please don't muddle the concepts, or assume that whatever subset of
>>> hotplug memory you are dealing with is the only subset.
>>
>> I can certainly rephrase the subject/description/comment, stating that
>> this is not to be used for ordinary hotplugged DIMMs - only when the
>> device driver is under control to decide what to do with that memory -
>> especially when kexec'ing.
>>
>> (previously, I called this flag MHP_DRIVER_MANAGED, but I think
>> MHP_NO_FIRMWARE_MEMMAP is clearer, we just need a better description)
>>
>> Would that make it clearer?
>
> I am not certain, but Andrew Morton deliberately added that
> firmware_map_add_hotplug call. Which means that there is a reason
> for putting hotplugged memory in the firmware map.
>
> So the justification needs to take that reason into account. The
> justification can not be it is hotplugged therefore it should not belong
> in the firmware memory map. Unless you can show that
> firmware_map_add_hotplug that was actually a bug and should be removed.
> But as it has been that way since 2010 that seems like a long shot.
>
> So my question is what is right for the firmware map?
We have documentation for that since 2008. Andrews patch is from 2010.
Documentation/ABI/testing/sysfs-firmware-memmap
It clearly talks about "raw firmware-provided memory map" and why the
interface was introduced at all ("on most architectures that
firmware-provided memory map is modified afterwards by the kernel itself").
>
> 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)
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
From: Dan Williams @ 2020-04-30 18:58 UTC (permalink / raw)
To: David Hildenbrand
Cc: Eric W. Biederman, Andrew Morton, Linux Kernel Mailing List,
Linux MM, virtio-dev, virtualization, linuxppc-dev, Linux ACPI,
linux-nvdimm, linux-hyperv, linux-s390, xen-devel, Michal Hocko,
Michael S . Tsirkin, Michal Hocko, Pankaj Gupta, Wei Yang,
Baoquan He
In-Reply-To: <b28c9e02-8cf2-33ae-646b-fe50a185738e@redhat.com>
On Thu, Apr 30, 2020 at 11:44 AM David Hildenbrand <david@redhat.com> wrote:
>
> >>> If the class of memory is different then please by all means let's mark
> >>> it differently in struct resource so everyone knows it is different.
> >>> But that difference needs to be more than hotplug.
> >>>
> >>> That difference needs to be the hypervisor loaned us memory and might
> >>> take it back at any time, or this memory is persistent and so it has
> >>> these different characteristics so don't use it as ordinary ram.
> >>
> >> Yes, and I think kmem took an excellent approach of explicitly putting
> >> that "System RAM" into a resource hierarchy. That "System RAM" won't
> >> show up as a root node under /proc/iomem (see patch #3), which already
> >> results in kexec-tools to treat it in a special way. I am thinking about
> >> doing the same for virtio-mem.
> >
> > Reading this and your patch cover letters again my concern is that
> > the justification seems to be letting the tail wag the dog.
> >
> > You want kexec-tools to behave in a certain way so you are changing the
> > kernel.
> >
> > Rather it should be change the kernel to clearly reflect reality and if
> > you can get away without a change to kexec-tools that is a bonus.
> >
>
> Right, because user space has to have a way to figure out what to do.
>
> But talking about the firmware memmap, indicating something via a "raw
> firmware-provided memory map", that is not actually in the "raw
> firmware-provided memory map" feels wrong to me. (below)
>
>
> >>> That information is also useful to other people looking at the system
> >>> and seeing what is going on.
> >>>
> >>> Just please don't muddle the concepts, or assume that whatever subset of
> >>> hotplug memory you are dealing with is the only subset.
> >>
> >> I can certainly rephrase the subject/description/comment, stating that
> >> this is not to be used for ordinary hotplugged DIMMs - only when the
> >> device driver is under control to decide what to do with that memory -
> >> especially when kexec'ing.
> >>
> >> (previously, I called this flag MHP_DRIVER_MANAGED, but I think
> >> MHP_NO_FIRMWARE_MEMMAP is clearer, we just need a better description)
> >>
> >> Would that make it clearer?
> >
> > I am not certain, but Andrew Morton deliberately added that
> > firmware_map_add_hotplug call. Which means that there is a reason
> > for putting hotplugged memory in the firmware map.
> >
> > So the justification needs to take that reason into account. The
> > justification can not be it is hotplugged therefore it should not belong
> > in the firmware memory map. Unless you can show that
> > firmware_map_add_hotplug that was actually a bug and should be removed.
> > But as it has been that way since 2010 that seems like a long shot.
> >
> > So my question is what is right for the firmware map?
>
> We have documentation for that since 2008. Andrews patch is from 2010.
>
> Documentation/ABI/testing/sysfs-firmware-memmap
>
> It clearly talks about "raw firmware-provided memory map" and why the
> interface was introduced at all ("on most architectures that
> firmware-provided memory map is modified afterwards by the kernel itself").
>
> >
> > 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.
I can at least say that this breakdown makes sense to me. Traditional
memory hotplug results in permanent change to the raw firmware memory
map reported by the host at next reboot. These device-driver-owned
memory regions really want a hotplug policy per-kernel boot instance
and should fall back to the default reserved state at reboot (kexec or
otherwise). When I say hotplug-policy I mean whether the current
kernel wants to treat the device range as System RAM or leave it as
device-managed. The intent is that the follow-on kernel needs to
re-decide the device policy.
>
> This worked for a while. Then came dax/kmem. Now comes virtio-mem.
>
^ permalink raw reply
* Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
From: Andrew Morton @ 2020-04-30 22:24 UTC (permalink / raw)
To: David Hildenbrand
Cc: Eric W. Biederman, linux-kernel, linux-mm, virtio-dev,
virtualization, linuxppc-dev, linux-acpi, linux-nvdimm,
linux-hyperv, linux-s390, xen-devel, Michal Hocko,
Michael S . Tsirkin, Michal Hocko, Pankaj Gupta, Wei Yang,
Baoquan He
In-Reply-To: <b28c9e02-8cf2-33ae-646b-fe50a185738e@redhat.com>
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.
^ permalink raw reply
* Re: [PATCH 21/29] mm: remove the pgprot argument to __vmalloc
From: John Dorminy @ 2020-05-01 2:38 UTC (permalink / raw)
To: Wei Liu
Cc: Christoph Hellwig, Andrew Morton, K. Y. Srinivasan, Haiyang Zhang,
Stephen Hemminger, x86, David Airlie, Daniel Vetter, Laura Abbott,
Sumit Semwal, Sakari Ailus, Minchan Kim, Nitin Gupta,
Robin Murphy, Christophe Leroy, Peter Zijlstra, linuxppc-dev,
linux-hyperv, dri-devel, linaro-mm-sig, linux-arch, linux-mm,
iommu, linux-arm-kernel, linux-s390, bpf,
Linux Kernel Mailing List, Michael Kelley, Gao Xiang
In-Reply-To: <CAMeeMh8Q3Od76WaTasw+BpYVF58P-HQMaiFKHxXbZ_Q3tQPZ=A@mail.gmail.com>
>> On Tue, Apr 14, 2020 at 03:13:40PM +0200, Christoph Hellwig wrote:
>> > The pgprot argument to __vmalloc is always PROT_KERNEL now, so remove
>> > it.
Greetings;
I recently noticed this change via the linux-next tree.
It may not be possible to edit at this late date, but the change
description refers to PROT_KERNEL, which is a symbol which does not
appear to exist; perhaps PAGE_KERNEL was meant? The mismatch caused me
and a couple other folks some confusion briefly until we decided it
was supposed to be PAGE_KERNEL; if it's not too late, editing the
description to clarify so would be nice.
Many thanks.
John Dorminy
^ permalink raw reply
* [PATCH v2 0/2] Fix PCI HyperV device error handling
From: Wei Hu @ 2020-05-01 5:28 UTC (permalink / raw)
To: kys, haiyangz, sthemmin, wei.liu, lorenzo.pieralisi, robh,
bhelgaas, linux-hyperv, linux-pci, linux-kernel, decui, mikelley
Cc: Wei Hu
This series better handles some PCI HyperV error cases in general and
for kdump case. Some of review comments from previous individual
patch reviews, including splitting into separate patches, have
already been incorporated.
Thanks,
Wei
Wei Hu (2):
PCI: hv: Fix the PCI HyperV probe failure path to release resource
properly
PCI: hv: Retry PCI bus D0 entry when the first attempt failed with
invalid device state
drivers/pci/controller/pci-hyperv.c | 60 ++++++++++++++++++++++++++---
1 file changed, 54 insertions(+), 6 deletions(-)
--
2.20.1
^ permalink raw reply
* [PATCH v2 1/2] PCI: hv: Fix the PCI HyperV probe failure path to release resource properly
From: Wei Hu @ 2020-05-01 5:36 UTC (permalink / raw)
To: kys, haiyangz, sthemmin, wei.liu, lorenzo.pieralisi, robh,
bhelgaas, linux-hyperv, linux-pci, linux-kernel, decui, mikelley
Cc: Wei Hu
Some error cases in hv_pci_probe() were not handled. Fix these error
paths to release the resourses and clean up the state properly.
Signed-off-by: Wei Hu <weh@microsoft.com>
---
drivers/pci/controller/pci-hyperv.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
index e15022ff63e3..e6fac0187722 100644
--- a/drivers/pci/controller/pci-hyperv.c
+++ b/drivers/pci/controller/pci-hyperv.c
@@ -480,6 +480,9 @@ struct hv_pcibus_device {
struct workqueue_struct *wq;
+ /* Highest slot of child device with resources allocated */
+ int wslot_res_allocated;
+
/* hypercall arg, must not cross page boundary */
struct hv_retarget_device_interrupt retarget_msi_interrupt_params;
@@ -2847,7 +2850,7 @@ static int hv_send_resources_allocated(struct hv_device *hdev)
struct hv_pci_dev *hpdev;
struct pci_packet *pkt;
size_t size_res;
- u32 wslot;
+ int wslot;
int ret;
size_res = (hbus->protocol_version < PCI_PROTOCOL_VERSION_1_2)
@@ -2900,6 +2903,8 @@ static int hv_send_resources_allocated(struct hv_device *hdev)
comp_pkt.completion_status);
break;
}
+
+ hbus->wslot_res_allocated = wslot;
}
kfree(pkt);
@@ -2918,10 +2923,10 @@ static int hv_send_resources_released(struct hv_device *hdev)
struct hv_pcibus_device *hbus = hv_get_drvdata(hdev);
struct pci_child_message pkt;
struct hv_pci_dev *hpdev;
- u32 wslot;
+ int wslot;
int ret;
- for (wslot = 0; wslot < 256; wslot++) {
+ for (wslot = hbus->wslot_res_allocated; wslot >= 0; wslot--) {
hpdev = get_pcichild_wslot(hbus, wslot);
if (!hpdev)
continue;
@@ -2936,8 +2941,12 @@ static int hv_send_resources_released(struct hv_device *hdev)
VM_PKT_DATA_INBAND, 0);
if (ret)
return ret;
+
+ hbus->wslot_res_allocated = wslot - 1;
}
+ hbus->wslot_res_allocated = -1;
+
return 0;
}
@@ -3037,6 +3046,7 @@ static int hv_pci_probe(struct hv_device *hdev,
if (!hbus)
return -ENOMEM;
hbus->state = hv_pcibus_init;
+ hbus->wslot_res_allocated = -1;
/*
* The PCI bus "domain" is what is called "segment" in ACPI and other
@@ -3136,7 +3146,7 @@ static int hv_pci_probe(struct hv_device *hdev,
ret = hv_pci_allocate_bridge_windows(hbus);
if (ret)
- goto free_irq_domain;
+ goto exit_d0;
ret = hv_send_resources_allocated(hdev);
if (ret)
@@ -3154,6 +3164,8 @@ static int hv_pci_probe(struct hv_device *hdev,
free_windows:
hv_pci_free_bridge_windows(hbus);
+exit_d0:
+ (void) hv_pci_bus_exit(hdev, true);
free_irq_domain:
irq_domain_remove(hbus->irq_domain);
free_fwnode:
--
2.20.1
^ permalink raw reply related
* [PATCH v2 2/2] PCI: hv: Retry PCI bus D0 entry when the first attempt failed with invalid device state
From: Wei Hu @ 2020-05-01 5:37 UTC (permalink / raw)
To: kys, haiyangz, sthemmin, wei.liu, lorenzo.pieralisi, robh,
bhelgaas, linux-hyperv, linux-pci, linux-kernel, decui, mikelley
Cc: Wei Hu
In the case of kdump, the PCI device was not cleanly shut down
before the kdump kernel starts. This causes the initial
attempt of entering D0 state in the kdump kernel to fail with
invalid device state returned from Hyper-V host.
When this happens, explicitly call PCI bus exit and retry to
enter the D0 state.
Signed-off-by: Wei Hu <weh@microsoft.com>
---
v2: Incorporate review comments from Michael Kelley, Dexuan Cui and
Bjorn Helgaas
drivers/pci/controller/pci-hyperv.c | 40 +++++++++++++++++++++++++++--
1 file changed, 38 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/pci-hyperv.c b/drivers/pci/controller/pci-hyperv.c
index e6fac0187722..92092a47d3af 100644
--- a/drivers/pci/controller/pci-hyperv.c
+++ b/drivers/pci/controller/pci-hyperv.c
@@ -2739,6 +2739,8 @@ static void hv_free_config_window(struct hv_pcibus_device *hbus)
vmbus_free_mmio(hbus->mem_config->start, PCI_CONFIG_MMIO_LENGTH);
}
+static int hv_pci_bus_exit(struct hv_device *hdev, bool keep_devs);
+
/**
* hv_pci_enter_d0() - Bring the "bus" into the D0 power state
* @hdev: VMBus's tracking struct for this root PCI bus
@@ -2751,8 +2753,10 @@ static int hv_pci_enter_d0(struct hv_device *hdev)
struct pci_bus_d0_entry *d0_entry;
struct hv_pci_compl comp_pkt;
struct pci_packet *pkt;
+ bool retry = true;
int ret;
+enter_d0_retry:
/*
* Tell the host that the bus is ready to use, and moved into the
* powered-on state. This includes telling the host which region
@@ -2779,6 +2783,38 @@ static int hv_pci_enter_d0(struct hv_device *hdev)
if (ret)
goto exit;
+ /*
+ * In certain case (Kdump) the pci device of interest was
+ * not cleanly shut down and resource is still held on host
+ * side, the host could return invalid device status.
+ * We need to explicitly request host to release the resource
+ * and try to enter D0 again.
+ */
+ if (comp_pkt.completion_status < 0 && retry) {
+ retry = false;
+
+ dev_err(&hdev->device, "Retrying D0 Entry\n");
+
+ /*
+ * Hv_pci_bus_exit() calls hv_send_resource_released()
+ * to free up resources of its child devices.
+ * In the kdump kernel we need to set the
+ * wslot_res_allocated to 255 so it scans all child
+ * devices to release resources allocated in the
+ * normal kernel before panic happened.
+ */
+ hbus->wslot_res_allocated = 255;
+
+ ret = hv_pci_bus_exit(hdev, true);
+
+ if (ret == 0) {
+ kfree(pkt);
+ goto enter_d0_retry;
+ }
+ dev_err(&hdev->device,
+ "Retrying D0 failed with ret %d\n", ret);
+ }
+
if (comp_pkt.completion_status < 0) {
dev_err(&hdev->device,
"PCI Pass-through VSP failed D0 Entry with status %x\n",
@@ -3185,7 +3221,7 @@ static int hv_pci_probe(struct hv_device *hdev,
return ret;
}
-static int hv_pci_bus_exit(struct hv_device *hdev, bool hibernating)
+static int hv_pci_bus_exit(struct hv_device *hdev, bool keep_devs)
{
struct hv_pcibus_device *hbus = hv_get_drvdata(hdev);
struct {
@@ -3203,7 +3239,7 @@ static int hv_pci_bus_exit(struct hv_device *hdev, bool hibernating)
if (hdev->channel->rescind)
return 0;
- if (!hibernating) {
+ if (!keep_devs) {
/* Delete any children which might still exist. */
dr = kzalloc(sizeof(*dr), GFP_KERNEL);
if (dr && hv_pci_start_relations_work(hbus, dr))
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
From: David Hildenbrand @ 2020-05-01 9:34 UTC (permalink / raw)
To: Andrew Morton
Cc: Eric W. Biederman, linux-kernel, linux-mm, virtio-dev,
virtualization, linuxppc-dev, linux-acpi, linux-nvdimm,
linux-hyperv, linux-s390, xen-devel, Michal Hocko,
Michael S . Tsirkin, Michal Hocko, Pankaj Gupta, Wei Yang,
Baoquan He
In-Reply-To: <20200430152403.e0d6da5eb1cad06411ac6d46@linux-foundation.org>
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
^ permalink raw reply
* [PATCH 26/37] docs: networking: device drivers: convert microsoft/netvsc.txt to ReST
From: Mauro Carvalho Chehab @ 2020-05-01 14:44 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, linux-kernel, Jonathan Corbet,
David S. Miller, Jakub Kicinski, K. Y. Srinivasan, Haiyang Zhang,
Stephen Hemminger, Wei Liu, netdev, linux-hyperv
In-Reply-To: <cover.1588344146.git.mchehab+huawei@kernel.org>
- add SPDX header;
- adjust titles and chapters, adding proper markups;
- mark code blocks and literals as such;
- adjust identation, whitespaces and blank lines where needed;
- add to networking/index.rst.
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
---
.../networking/device_drivers/index.rst | 1 +
.../microsoft/{netvsc.txt => netvsc.rst} | 57 +++++++++++--------
MAINTAINERS | 2 +-
3 files changed, 36 insertions(+), 24 deletions(-)
rename Documentation/networking/device_drivers/microsoft/{netvsc.txt => netvsc.rst} (83%)
diff --git a/Documentation/networking/device_drivers/index.rst b/Documentation/networking/device_drivers/index.rst
index f9ce0089ec7d..575f0043b03e 100644
--- a/Documentation/networking/device_drivers/index.rst
+++ b/Documentation/networking/device_drivers/index.rst
@@ -41,6 +41,7 @@ Contents:
freescale/gianfar
intel/ipw2100
intel/ipw2200
+ microsoft/netvsc
.. only:: subproject and html
diff --git a/Documentation/networking/device_drivers/microsoft/netvsc.txt b/Documentation/networking/device_drivers/microsoft/netvsc.rst
similarity index 83%
rename from Documentation/networking/device_drivers/microsoft/netvsc.txt
rename to Documentation/networking/device_drivers/microsoft/netvsc.rst
index cd63556b27a0..c3f51c672a68 100644
--- a/Documentation/networking/device_drivers/microsoft/netvsc.txt
+++ b/Documentation/networking/device_drivers/microsoft/netvsc.rst
@@ -1,3 +1,6 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+======================
Hyper-V network driver
======================
@@ -10,15 +13,15 @@ Windows 10.
Features
========
- Checksum offload
- ----------------
+Checksum offload
+----------------
The netvsc driver supports checksum offload as long as the
Hyper-V host version does. Windows Server 2016 and Azure
support checksum offload for TCP and UDP for both IPv4 and
IPv6. Windows Server 2012 only supports checksum offload for TCP.
- Receive Side Scaling
- --------------------
+Receive Side Scaling
+--------------------
Hyper-V supports receive side scaling. For TCP & UDP, packets can
be distributed among available queues based on IP address and port
number.
@@ -32,30 +35,37 @@ Features
hashing. Using L3 hashing is recommended in this case.
For example, for UDP over IPv4 on eth0:
- To include UDP port numbers in hashing:
- ethtool -N eth0 rx-flow-hash udp4 sdfn
- To exclude UDP port numbers in hashing:
- ethtool -N eth0 rx-flow-hash udp4 sd
- To show UDP hash level:
- ethtool -n eth0 rx-flow-hash udp4
-
- Generic Receive Offload, aka GRO
- --------------------------------
+
+ To include UDP port numbers in hashing::
+
+ ethtool -N eth0 rx-flow-hash udp4 sdfn
+
+ To exclude UDP port numbers in hashing::
+
+ ethtool -N eth0 rx-flow-hash udp4 sd
+
+ To show UDP hash level::
+
+ ethtool -n eth0 rx-flow-hash udp4
+
+Generic Receive Offload, aka GRO
+--------------------------------
The driver supports GRO and it is enabled by default. GRO coalesces
like packets and significantly reduces CPU usage under heavy Rx
load.
- Large Receive Offload (LRO), or Receive Side Coalescing (RSC)
- -------------------------------------------------------------
+Large Receive Offload (LRO), or Receive Side Coalescing (RSC)
+-------------------------------------------------------------
The driver supports LRO/RSC in the vSwitch feature. It reduces the per packet
processing overhead by coalescing multiple TCP segments when possible. The
feature is enabled by default on VMs running on Windows Server 2019 and
- later. It may be changed by ethtool command:
+ later. It may be changed by ethtool command::
+
ethtool -K eth0 lro on
ethtool -K eth0 lro off
- SR-IOV support
- --------------
+SR-IOV support
+--------------
Hyper-V supports SR-IOV as a hardware acceleration option. If SR-IOV
is enabled in both the vSwitch and the guest configuration, then the
Virtual Function (VF) device is passed to the guest as a PCI
@@ -70,8 +80,8 @@ Features
flow direction is desired, these should be applied directly to the
VF slave device.
- Receive Buffer
- --------------
+Receive Buffer
+--------------
Packets are received into a receive area which is created when device
is probed. The receive area is broken into MTU sized chunks and each may
contain one or more packets. The number of receive sections may be changed
@@ -83,8 +93,8 @@ Features
will use slower method to handle very large packets or if the send buffer
area is exhausted.
- XDP support
- -----------
+XDP support
+-----------
XDP (eXpress Data Path) is a feature that runs eBPF bytecode at the early
stage when packets arrive at a NIC card. The goal is to increase performance
for packet processing, reducing the overhead of SKB allocation and other
@@ -99,7 +109,8 @@ Features
overwritten by setting of synthetic NIC.
XDP program cannot run with LRO (RSC) enabled, so you need to disable LRO
- before running XDP:
+ before running XDP::
+
ethtool -K eth0 lro off
XDP_REDIRECT action is not yet supported.
diff --git a/MAINTAINERS b/MAINTAINERS
index 62c654308bc8..ef6bd3be1bb5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7881,7 +7881,7 @@ S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/hyperv/linux.git
F: Documentation/ABI/stable/sysfs-bus-vmbus
F: Documentation/ABI/testing/debugfs-hyperv
-F: Documentation/networking/device_drivers/microsoft/netvsc.txt
+F: Documentation/networking/device_drivers/microsoft/netvsc.rst
F: arch/x86/hyperv
F: arch/x86/include/asm/hyperv-tlfs.h
F: arch/x86/include/asm/mshyperv.h
--
2.25.4
^ permalink raw reply related
* [PATCH 00/37]net: manually convert files to ReST format - part 3 (final)
From: Mauro Carvalho Chehab @ 2020-05-01 14:44 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Mauro Carvalho Chehab, linux-kernel, Jonathan Corbet,
Samuel Chessman, netdev, Andrew Hendry, Zorik Machulsky,
Sean Tranchetti, Igor Russkikh, Jon Mason, Haiyang Zhang,
linux-x25, Wei Liu, linux-hyperv, Kalle Valo, Jakub Kicinski,
Subash Abhinov Kasiviswanathan, David Ahern, K. Y. Srinivasan,
Ishizaki Kou, Joerg Reuter, Saeed Bishara, Shrijeet Mukherjee,
Netanel Belgazal, Stanislav Yakovlev, Guy Tzalik,
Maxim Krasnyansky, Arthur Kiyanovski, linux-wireless, linux-hams,
linux-parisc, Steffen Klassert, David S. Miller,
Stephen Hemminger
That's the third part (and the final one) of my work to convert the networking
text files into ReST. it is based on linux-next next-20200430 branch.
The full series (including those ones) are at:
https://git.linuxtv.org/mchehab/experimental.git/log/?h=net-docs
The built output documents, on html format is at:
https://www.infradead.org/~mchehab/kernel_docs/networking/
Mauro Carvalho Chehab (37):
docs: networking: convert tuntap.txt to ReST
docs: networking: convert udplite.txt to ReST
docs: networking: convert vrf.txt to ReST
docs: networking: convert vxlan.txt to ReST
docs: networking: convert x25-iface.txt to ReST
docs: networking: convert x25.txt to ReST
docs: networking: convert xfrm_device.txt to ReST
docs: networking: convert xfrm_proc.txt to ReST
docs: networking: convert xfrm_sync.txt to ReST
docs: networking: convert xfrm_sysctl.txt to ReST
docs: networking: convert z8530drv.txt to ReST
docs: networking: device drivers: convert 3com/3c509.txt to ReST
docs: networking: device drivers: convert 3com/vortex.txt to ReST
docs: networking: device drivers: convert amazon/ena.txt to ReST
docs: networking: device drivers: convert aquantia/atlantic.txt to
ReST
docs: networking: device drivers: convert chelsio/cxgb.txt to ReST
docs: networking: device drivers: convert cirrus/cs89x0.txt to ReST
docs: networking: device drivers: convert davicom/dm9000.txt to ReST
docs: networking: device drivers: convert dec/de4x5.txt to ReST
docs: networking: device drivers: convert dec/dmfe.txt to ReST
docs: networking: device drivers: convert dlink/dl2k.txt to ReST
docs: networking: device drivers: convert freescale/dpaa.txt to ReST
docs: networking: device drivers: convert freescale/gianfar.txt to
ReST
docs: networking: device drivers: convert intel/ipw2100.txt to ReST
docs: networking: device drivers: convert intel/ipw2200.txt to ReST
docs: networking: device drivers: convert microsoft/netvsc.txt to ReST
docs: networking: device drivers: convert neterion/s2io.txt to ReST
docs: networking: device drivers: convert neterion/vxge.txt to ReST
docs: networking: device drivers: convert qualcomm/rmnet.txt to ReST
docs: networking: device drivers: convert sb1000.txt to ReST
docs: networking: device drivers: convert smsc/smc9.txt to ReST
docs: networking: device drivers: convert ti/cpsw_switchdev.txt to
ReST
docs: networking: device drivers: convert ti/cpsw.txt to ReST
docs: networking: device drivers: convert ti/tlan.txt to ReST
docs: networking: device drivers: convert toshiba/spider_net.txt to
ReST
net: docs: add page_pool.rst to index.rst
docs: networking: arcnet-hardware.rst: don't duplicate chapter names
Documentation/networking/arcnet-hardware.rst | 8 +-
.../3com/{3c509.txt => 3c509.rst} | 158 +++--
.../3com/{vortex.txt => vortex.rst} | 223 ++++---
.../amazon/{ena.txt => ena.rst} | 142 ++--
.../aquantia/{atlantic.txt => atlantic.rst} | 373 ++++++-----
.../chelsio/{cxgb.txt => cxgb.rst} | 183 ++++--
.../cirrus/{cs89x0.txt => cs89x0.rst} | 557 ++++++++--------
.../davicom/{dm9000.txt => dm9000.rst} | 24 +-
.../dec/{de4x5.txt => de4x5.rst} | 105 +--
.../device_drivers/dec/{dmfe.txt => dmfe.rst} | 35 +-
.../dlink/{dl2k.txt => dl2k.rst} | 228 ++++---
.../freescale/{dpaa.txt => dpaa.rst} | 139 ++--
.../freescale/{gianfar.txt => gianfar.rst} | 21 +-
.../networking/device_drivers/index.rst | 24 +
.../intel/{ipw2100.txt => ipw2100.rst} | 242 ++++---
.../intel/{ipw2200.txt => ipw2200.rst} | 410 +++++++-----
.../microsoft/{netvsc.txt => netvsc.rst} | 57 +-
.../device_drivers/neterion/s2io.rst | 196 ++++++
.../device_drivers/neterion/s2io.txt | 141 ----
.../neterion/{vxge.txt => vxge.rst} | 60 +-
.../qualcomm/{rmnet.txt => rmnet.rst} | 43 +-
.../networking/device_drivers/sb1000.rst | 222 +++++++
.../networking/device_drivers/sb1000.txt | 207 ------
.../networking/device_drivers/smsc/smc9.rst | 49 ++
.../networking/device_drivers/smsc/smc9.txt | 42 --
.../networking/device_drivers/ti/cpsw.rst | 587 +++++++++++++++++
.../networking/device_drivers/ti/cpsw.txt | 541 ----------------
...{cpsw_switchdev.txt => cpsw_switchdev.rst} | 239 ++++---
.../device_drivers/ti/{tlan.txt => tlan.rst} | 73 ++-
.../{spider_net.txt => spider_net.rst} | 58 +-
Documentation/networking/index.rst | 12 +
.../networking/{tuntap.txt => tuntap.rst} | 200 +++---
.../networking/{udplite.txt => udplite.rst} | 175 ++---
Documentation/networking/vrf.rst | 451 +++++++++++++
Documentation/networking/vrf.txt | 418 ------------
.../networking/{vxlan.txt => vxlan.rst} | 33 +-
.../{x25-iface.txt => x25-iface.rst} | 10 +-
Documentation/networking/{x25.txt => x25.rst} | 4 +
.../{xfrm_device.txt => xfrm_device.rst} | 33 +-
.../{xfrm_proc.txt => xfrm_proc.rst} | 31 +
.../{xfrm_sync.txt => xfrm_sync.rst} | 66 +-
.../{xfrm_sysctl.txt => xfrm_sysctl.rst} | 7 +
.../networking/{z8530drv.txt => z8530drv.rst} | 609 +++++++++---------
MAINTAINERS | 30 +-
drivers/net/Kconfig | 4 +-
drivers/net/ethernet/3com/3c59x.c | 4 +-
drivers/net/ethernet/3com/Kconfig | 2 +-
drivers/net/ethernet/chelsio/Kconfig | 2 +-
drivers/net/ethernet/cirrus/Kconfig | 2 +-
drivers/net/ethernet/dec/tulip/Kconfig | 4 +-
drivers/net/ethernet/dlink/dl2k.c | 2 +-
drivers/net/ethernet/neterion/Kconfig | 4 +-
drivers/net/ethernet/smsc/Kconfig | 4 +-
drivers/net/ethernet/ti/Kconfig | 2 +-
drivers/net/ethernet/ti/tlan.c | 2 +-
drivers/net/hamradio/Kconfig | 4 +-
drivers/net/hamradio/scc.c | 2 +-
drivers/net/wireless/intel/ipw2x00/Kconfig | 4 +-
drivers/net/wireless/intel/ipw2x00/ipw2100.c | 2 +-
include/uapi/linux/if_x25.h | 2 +-
net/x25/Kconfig | 4 +-
61 files changed, 4175 insertions(+), 3341 deletions(-)
rename Documentation/networking/device_drivers/3com/{3c509.txt => 3c509.rst} (68%)
rename Documentation/networking/device_drivers/3com/{vortex.txt => vortex.rst} (72%)
rename Documentation/networking/device_drivers/amazon/{ena.txt => ena.rst} (86%)
rename Documentation/networking/device_drivers/aquantia/{atlantic.txt => atlantic.rst} (63%)
rename Documentation/networking/device_drivers/chelsio/{cxgb.txt => cxgb.rst} (81%)
rename Documentation/networking/device_drivers/cirrus/{cs89x0.txt => cs89x0.rst} (61%)
rename Documentation/networking/device_drivers/davicom/{dm9000.txt => dm9000.rst} (92%)
rename Documentation/networking/device_drivers/dec/{de4x5.txt => de4x5.rst} (78%)
rename Documentation/networking/device_drivers/dec/{dmfe.txt => dmfe.rst} (68%)
rename Documentation/networking/device_drivers/dlink/{dl2k.txt => dl2k.rst} (59%)
rename Documentation/networking/device_drivers/freescale/{dpaa.txt => dpaa.rst} (79%)
rename Documentation/networking/device_drivers/freescale/{gianfar.txt => gianfar.rst} (82%)
rename Documentation/networking/device_drivers/intel/{ipw2100.txt => ipw2100.rst} (70%)
rename Documentation/networking/device_drivers/intel/{ipw2200.txt => ipw2200.rst} (64%)
rename Documentation/networking/device_drivers/microsoft/{netvsc.txt => netvsc.rst} (83%)
create mode 100644 Documentation/networking/device_drivers/neterion/s2io.rst
delete mode 100644 Documentation/networking/device_drivers/neterion/s2io.txt
rename Documentation/networking/device_drivers/neterion/{vxge.txt => vxge.rst} (80%)
rename Documentation/networking/device_drivers/qualcomm/{rmnet.txt => rmnet.rst} (73%)
create mode 100644 Documentation/networking/device_drivers/sb1000.rst
delete mode 100644 Documentation/networking/device_drivers/sb1000.txt
create mode 100644 Documentation/networking/device_drivers/smsc/smc9.rst
delete mode 100644 Documentation/networking/device_drivers/smsc/smc9.txt
create mode 100644 Documentation/networking/device_drivers/ti/cpsw.rst
delete mode 100644 Documentation/networking/device_drivers/ti/cpsw.txt
rename Documentation/networking/device_drivers/ti/{cpsw_switchdev.txt => cpsw_switchdev.rst} (51%)
rename Documentation/networking/device_drivers/ti/{tlan.txt => tlan.rst} (73%)
rename Documentation/networking/device_drivers/toshiba/{spider_net.txt => spider_net.rst} (88%)
rename Documentation/networking/{tuntap.txt => tuntap.rst} (58%)
rename Documentation/networking/{udplite.txt => udplite.rst} (65%)
create mode 100644 Documentation/networking/vrf.rst
delete mode 100644 Documentation/networking/vrf.txt
rename Documentation/networking/{vxlan.txt => vxlan.rst} (73%)
rename Documentation/networking/{x25-iface.txt => x25-iface.rst} (96%)
rename Documentation/networking/{x25.txt => x25.rst} (96%)
rename Documentation/networking/{xfrm_device.txt => xfrm_device.rst} (92%)
rename Documentation/networking/{xfrm_proc.txt => xfrm_proc.rst} (95%)
rename Documentation/networking/{xfrm_sync.txt => xfrm_sync.rst} (82%)
rename Documentation/networking/{xfrm_sysctl.txt => xfrm_sysctl.rst} (52%)
rename Documentation/networking/{z8530drv.txt => z8530drv.rst} (57%)
--
2.25.4
^ permalink raw reply
* Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
From: Dan Williams @ 2020-05-01 16:56 UTC (permalink / raw)
To: David Hildenbrand
Cc: Andrew Morton, Eric W. Biederman, Linux Kernel Mailing List,
Linux MM, virtio-dev, virtualization, linuxppc-dev, Linux ACPI,
linux-nvdimm, linux-hyperv, linux-s390, xen-devel, Michal Hocko,
Michael S . Tsirkin, Michal Hocko, Pankaj Gupta, Wei Yang,
Baoquan He
In-Reply-To: <5c908ec3-9495-531e-9291-cbab24f292d6@redhat.com>
On Fri, May 1, 2020 at 2:34 AM David Hildenbrand <david@redhat.com> wrote:
>
> 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.
I'm still more of a fan of this being communicated by "System RAM"
being parented especially because that tells you something about how
the memory is driver-managed and which mechanism might be in play.
What about adding an optional /sys/firmware/memmap/X/parent attribute.
This lets tooling check if it cares via that interface and lets it
lookup the related infrastructure to interact with if it would do
something different for virtio-mem vs dax/kmem?
^ permalink raw reply
* Re: [PATCH v2 2/3] mm/memory_hotplug: Introduce MHP_NO_FIRMWARE_MEMMAP
From: David Hildenbrand @ 2020-05-01 17:21 UTC (permalink / raw)
To: Dan Williams
Cc: Andrew Morton, Eric W. Biederman, Linux Kernel Mailing List,
Linux MM, virtio-dev, virtualization, linuxppc-dev, Linux ACPI,
linux-nvdimm, linux-hyperv, linux-s390, xen-devel, Michal Hocko,
Michael S . Tsirkin, Michal Hocko, Pankaj Gupta, Wei Yang,
Baoquan He
In-Reply-To: <CAPcyv4j=YKnr1HW4OhAmpzbuKjtfP7FdAn4-V7uA=b-Tcpfu+A@mail.gmail.com>
On 01.05.20 18:56, Dan Williams wrote:
> On Fri, May 1, 2020 at 2:34 AM David Hildenbrand <david@redhat.com> wrote:
>>
>> 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.
>
> I'm still more of a fan of this being communicated by "System RAM"
I was mentioning somewhere in this thread that "System RAM" inside a
hierarchy (like dax/kmem) will already be basically ignored by
kexec-tools. So, placing it inside a hierarchy already makes it look
special already.
But after all, as we have to change kexec-tools either way, we can
directly go ahead and flag it properly as special (in case there will
ever be other cases where we could no longer distinguish it).
> being parented especially because that tells you something about how
> the memory is driver-managed and which mechanism might be in play.
The could be communicated to some degree via the resource hierarchy.
E.g.,
[root@localhost ~]# cat /proc/iomem
...
140000000-33fffffff : Persistent Memory
140000000-1481fffff : namespace0.0
150000000-33fffffff : dax0.0
150000000-33fffffff : System RAM (driver managed)
vs.
:/# cat /proc/iomem
[...]
140000000-333ffffff : virtio-mem (virtio0)
140000000-147ffffff : System RAM (driver managed)
148000000-14fffffff : System RAM (driver managed)
150000000-157ffffff : System RAM (driver managed)
Good enough for my taste.
> What about adding an optional /sys/firmware/memmap/X/parent attribute.
I really don't want any firmware memmap entries for something that is
not part of the firmware provided memmap. In addition,
/sys/firmware/memmap/ is still a fairly x86_64 specific thing. Only mips
and two arm configs enable it at all.
So, IMHO, /sys/firmware/memmap/ is definitely not the way to go.
--
Thanks,
David / dhildenb
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox