[RFC] /proc/efi_memmap

[RFC] /proc/efi_memmap

[Luck, Tony]

kexec folks asked whether I could export the EFI memory map in /proc
for use by their user level tools.

Questions:
0) Is this information already available some place I missed?
1) Is /proc/efi_memmap a good name?
2) I used mm/slab.c as my model for using seq_file ... does this look right?

-Tony

Patch against the "test" branch of my GIT tree.

---

diff --git a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c
--- a/arch/ia64/kernel/efi.c
+++ b/arch/ia64/kernel/efi.c
@@ -22,6 +22,8 @@
 #include <linux/module.h>
 #include <linux/kernel.h>
 #include <linux/init.h>
+#include <linux/proc_fs.h>
+#include <linux/seq_file.h>
 #include <linux/types.h>
 #include <linux/time.h>
 #include <linux/efi.h>
@@ -923,3 +925,89 @@ efi_memmap_init(unsigned long *s, unsign
 	*s = (u64)kern_memmap;
 	*e = (u64)++k;
 }
+
+#ifdef CONFIG_PROC_FS
+
+static void *s_start(struct seq_file *m, loff_t *pos)
+{
+	loff_t n = *pos;
+	void *efi_map_start, *efi_map_end, *p;
+	u64	efi_desc_size;
+
+	if (!n)
+		seq_puts(m, "type            start              end attributes\n");
+
+	p = efi_map_start = __va(ia64_boot_param->efi_memmap);
+	efi_map_end   = efi_map_start + ia64_boot_param->efi_memmap_size;
+	efi_desc_size = ia64_boot_param->efi_memdesc_size;
+
+	while (n--) {
+		p += efi_desc_size;
+		if (p >= efi_map_end)
+			return NULL;
+	}
+
+	return p;
+}
+
+static void *s_next(struct seq_file *m, void *p, loff_t *pos)
+{
+	void *efi_map_start, *efi_map_end;
+	u64	efi_desc_size;
+
+	++*pos;
+
+	efi_map_start = __va(ia64_boot_param->efi_memmap);
+	efi_map_end   = efi_map_start + ia64_boot_param->efi_memmap_size;
+	efi_desc_size = ia64_boot_param->efi_memdesc_size;
+
+	return (p + efi_desc_size >= efi_map_end) ? NULL : p + efi_desc_size;
+}
+
+static void s_stop(struct seq_file *m, void *p)
+{
+}
+
+static int s_show(struct seq_file *m, void *p)
+{
+	efi_memory_desc_t *md = p;
+
+	seq_printf(m, "%4d %16.16lx %16.16lx %lx\n", md->type, md->phys_addr,
+		efi_md_end(md), md->attribute);
+
+	return 0;
+}
+
+static struct seq_operations efimeminfo_op = {
+	.start	= s_start,
+	.next	= s_next,
+	.stop	= s_stop,
+	.show	= s_show,
+};
+
+static int efimeminfo_open(struct inode *inode, struct file *file)
+{
+        return seq_open(file, &efimeminfo_op);
+}
+
+static struct file_operations proc_efimeminfo_operations = {
+	.open		= efimeminfo_open,
+	.read		= seq_read,
+	.llseek		= seq_lseek,
+	.release	= seq_release,
+};
+
+static int __init
+efi_procmem(void)
+{
+	struct proc_dir_entry *entry;
+
+	entry = create_proc_entry("efi_memmap", S_IRUGO, NULL);
+	if (entry)
+		entry->proc_fops = &proc_efimeminfo_operations;
+
+	return 0;
+}
+late_initcall(efi_procmem);
+
+#endif

Re: [RFC] /proc/efi_memmap

[KAMEZAWA Hiroyuki]

Luck, Tony wrote:
> kexec folks asked whether I could export the EFI memory map in /proc
> for use by their user level tools.
> 
What does Kexec-people really want ?
Excact EFI memory map ? or physical address map with some attributes ?

(exporiting just EFI memmap looks easy but...)
I think EFI memory map cannot cooperate with memory hotplug and
will be obsolete in future.
So more generic "physical memory map" looks good.

 > 1) Is /proc/efi_memmap a good name?
just rename to memory_map and show efi's for now looks good.

 > +	seq_printf(m, "%4d %16.16lx %16.16lx %lx\n", md->type, md->phys_addr,
 > +		efi_md_end(md), md->attribute);

and please define more "generic format".
If an interface is fixed, we can change implementation.


BTW, EFI memory map doesn't matches kernel's memory view (by GRANULE etc..)
It isn't problem for kexec-people ?

-- Kame <kamezawa.hiroyu@jp.fujitsu.com>

> Questions:
> 0) Is this information already available some place I missed?
> 1) Is /proc/efi_memmap a good name?
> 2) I used mm/slab.c as my model for using seq_file ... does this look right?
> 
> -Tony
> 
> Patch against the "test" branch of my GIT tree.
> 
> ---
> 
> diff --git a/arch/ia64/kernel/efi.c b/arch/ia64/kernel/efi.c
> --- a/arch/ia64/kernel/efi.c
> +++ b/arch/ia64/kernel/efi.c
> @@ -22,6 +22,8 @@
>  #include <linux/module.h>
>  #include <linux/kernel.h>
>  #include <linux/init.h>
> +#include <linux/proc_fs.h>
> +#include <linux/seq_file.h>
>  #include <linux/types.h>
>  #include <linux/time.h>
>  #include <linux/efi.h>
> @@ -923,3 +925,89 @@ efi_memmap_init(unsigned long *s, unsign
>  	*s = (u64)kern_memmap;
>  	*e = (u64)++k;
>  }
> +
> +#ifdef CONFIG_PROC_FS
> +
> +static void *s_start(struct seq_file *m, loff_t *pos)
> +{
> +	loff_t n = *pos;
> +	void *efi_map_start, *efi_map_end, *p;
> +	u64	efi_desc_size;
> +
> +	if (!n)
> +		seq_puts(m, "type            start              end attributes\n");
> +
> +	p = efi_map_start = __va(ia64_boot_param->efi_memmap);
> +	efi_map_end   = efi_map_start + ia64_boot_param->efi_memmap_size;
> +	efi_desc_size = ia64_boot_param->efi_memdesc_size;
> +
> +	while (n--) {
> +		p += efi_desc_size;
> +		if (p >= efi_map_end)
> +			return NULL;
> +	}
> +
> +	return p;
> +}
> +
> +static void *s_next(struct seq_file *m, void *p, loff_t *pos)
> +{
> +	void *efi_map_start, *efi_map_end;
> +	u64	efi_desc_size;
> +
> +	++*pos;
> +
> +	efi_map_start = __va(ia64_boot_param->efi_memmap);
> +	efi_map_end   = efi_map_start + ia64_boot_param->efi_memmap_size;
> +	efi_desc_size = ia64_boot_param->efi_memdesc_size;
> +
> +	return (p + efi_desc_size >= efi_map_end) ? NULL : p + efi_desc_size;
> +}
> +
> +static void s_stop(struct seq_file *m, void *p)
> +{
> +}
> +
> +static int s_show(struct seq_file *m, void *p)
> +{
> +	efi_memory_desc_t *md = p;
> +
> +	seq_printf(m, "%4d %16.16lx %16.16lx %lx\n", md->type, md->phys_addr,
> +		efi_md_end(md), md->attribute);
> +
> +	return 0;
> +}
> +
> +static struct seq_operations efimeminfo_op = {
> +	.start	= s_start,
> +	.next	= s_next,
> +	.stop	= s_stop,
> +	.show	= s_show,
> +};
> +
> +static int efimeminfo_open(struct inode *inode, struct file *file)
> +{
> +        return seq_open(file, &efimeminfo_op);
> +}
> +
> +static struct file_operations proc_efimeminfo_operations = {
> +	.open		= efimeminfo_open,
> +	.read		= seq_read,
> +	.llseek		= seq_lseek,
> +	.release	= seq_release,
> +};
> +
> +static int __init
> +efi_procmem(void)
> +{
> +	struct proc_dir_entry *entry;
> +
> +	entry = create_proc_entry("efi_memmap", S_IRUGO, NULL);
> +	if (entry)
> +		entry->proc_fops = &proc_efimeminfo_operations;
> +
> +	return 0;
> +}
> +late_initcall(efi_procmem);
> +
> +#endif
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

RE: [RFC] /proc/efi_memmap

[Luck, Tony]

>What does Kexec-people really want ?
>Excact EFI memory map ? or physical address map with some attributes ?

Not sure what their exact needs are.

>(exporiting just EFI memmap looks easy but...)
>I think EFI memory map cannot cooperate with memory hotplug and
>will be obsolete in future.
>So more generic "physical memory map" looks good.

Good point.  EFI memory map is static, so the information may
be wrong in a hot-plug memory world.

> > 1) Is /proc/efi_memmap a good name?
>just rename to memory_map and show efi's for now looks good.
>
> > +	seq_printf(m, "%4d %16.16lx %16.16lx %lx\n", md->type, 
>md->phys_addr,
> > +		efi_md_end(md), md->attribute);
>
>and please define more "generic format".
>If an interface is fixed, we can change implementation.

If this is a general memory map, rather than EFI map, then
yes, the EFI type and attributes aren't helpful.

>BTW, EFI memory map doesn't matches kernel's memory view (by 
>GRANULE etc..)
>It isn't problem for kexec-people ?

I don't see why the new kernel would have the same page and
granule size.  So it may be able to use memory that the old
kernel couldn't.

-Tony

Re: [RFC] /proc/efi_memmap

[Bjorn Helgaas]

On Friday 09 September 2005 5:46 pm, Luck, Tony wrote:
> 1) Is /proc/efi_memmap a good name?

There's already a /sys/firmware/efi/;  maybe it should go under
there somewhere?

This functionality is arch-independent, so if you do it, you might
as well put it somewhere like drivers/firmware/efi/, and make it
work for x86 at the same time.

RE: [RFC] /proc/efi_memmap

[Khalid Aziz]

On Sun, 2005-09-11 at 21:34 -0700, Luck, Tony wrote:
> >What does Kexec-people really want ?
> >Excact EFI memory map ? or physical address map with some attributes ?
> 
> Not sure what their exact needs are.

The userspace kexec tools looks at the memory map to verify a new kernel
being loaded in memory will be loaded in memory that is normally
available for it. Same goes for initial ramdisk as well. kexec
opens /proc/iomem on x86 for this. I had sent a patch in July (subject
"[PATCH] /proc/iomem update") that provides same info in /proc/iomem as
x86 does and that will take care of kexec needs. I have already tested
kexec tool for ia64 with that patch and it works fine.

--
Khalid

> 
> >(exporiting just EFI memmap looks easy but...)
> >I think EFI memory map cannot cooperate with memory hotplug and
> >will be obsolete in future.
> >So more generic "physical memory map" looks good.
> 
> Good point.  EFI memory map is static, so the information may
> be wrong in a hot-plug memory world.
> 
> > > 1) Is /proc/efi_memmap a good name?
> >just rename to memory_map and show efi's for now looks good.
> >
> > > +	seq_printf(m, "%4d %16.16lx %16.16lx %lx\n", md->type, 
> >md->phys_addr,
> > > +		efi_md_end(md), md->attribute);
> >
> >and please define more "generic format".
> >If an interface is fixed, we can change implementation.
> 
> If this is a general memory map, rather than EFI map, then
> yes, the EFI type and attributes aren't helpful.
> 
> >BTW, EFI memory map doesn't matches kernel's memory view (by 
> >GRANULE etc..)
> >It isn't problem for kexec-people ?
> 
> I don't see why the new kernel would have the same page and
> granule size.  So it may be able to use memory that the old
> kernel couldn't.
> 
> -Tony
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] /proc/efi_memmap

[Luck, Tony]

On Tue, Sep 13, 2005 at 10:05:03AM -0600, Khalid Aziz wrote:
> The userspace kexec tools looks at the memory map to verify a new kernel
> being loaded in memory will be loaded in memory that is normally
> available for it. Same goes for initial ramdisk as well. kexec
> opens /proc/iomem on x86 for this. I had sent a patch in July (subject
> "[PATCH] /proc/iomem update") that provides same info in /proc/iomem as
> x86 does and that will take care of kexec needs. I have already tested
> kexec tool for ia64 with that patch and it works fine.

I should dust that off and take a look at it.  /proc/iomem seems a curious
name for a file that contains this information.

So what is the current state of kexec for ia64?  I think that there
are two modes of operation:

1) Fast reboot (bypasses f/w ... which takes a significant amount of
   the reboot time).

2) A means to getting a running kernel to take a crash dump.

In case 1, the system is still running ... so kexec can load the new
kernel from disk, and arrange for an orderly transfer of control from
the old kernel to the new.

In case 2, we need to plan ahead, and have the new kernel pre-loaded
into some reserved memory so when the panic hits (or the INIT button
is pressed) we don't need to do any I/O or memory allocation.  We just
leap to the new kernel.  For this case ia64 would appear to have an
advantage over other architectures ... we don't need to locate the new
kernel at any particular address, so we can leave the original kernel
untouched while we boot just using the reserved block of memory.

What's working?  What's still being developed?  Can we get this into
shape for 2.6.15?

-Tony

Re: [RFC] /proc/efi_memmap

[Grant Grundler]

On Tue, Sep 13, 2005 at 12:30:07PM -0700, Luck, Tony wrote:
> I should dust that off and take a look at it.  /proc/iomem seems a curious
> name for a file that contains this information.

It doesn't to me. "/proc/iomem" contains host physical addresses AFAICT.
The original use might have been only for tracking MMIO, but I see no
harm in other uses.

grant

Re: [RFC] /proc/efi_memmap

[Khalid Aziz]

On Tue, 2005-09-13 at 12:30 -0700, Luck, Tony wrote:
> On Tue, Sep 13, 2005 at 10:05:03AM -0600, Khalid Aziz wrote:
> > The userspace kexec tools looks at the memory map to verify a new kernel
> > being loaded in memory will be loaded in memory that is normally
> > available for it. Same goes for initial ramdisk as well. kexec
> > opens /proc/iomem on x86 for this. I had sent a patch in July (subject
> > "[PATCH] /proc/iomem update") that provides same info in /proc/iomem as
> > x86 does and that will take care of kexec needs. I have already tested
> > kexec tool for ia64 with that patch and it works fine.
> 
> I should dust that off and take a look at it.  /proc/iomem seems a curious
> name for a file that contains this information.

It may have evolved from its original use. On x86, it currently seems to
give information about full memory space. David pointed out a bug in the
last patch I had sent out. I found another bug in that patch this
morning which I have fixed now. I am running a few tests on it. I will
send out updated patch tomorrow.

> 
> So what is the current state of kexec for ia64?  I think that there
> are two modes of operation:
> 
> 1) Fast reboot (bypasses f/w ... which takes a significant amount of
>    the reboot time).
> 
> 2) A means to getting a running kernel to take a crash dump.
> 
> In case 1, the system is still running ... so kexec can load the new
> kernel from disk, and arrange for an orderly transfer of control from
> the old kernel to the new.
> 
> In case 2, we need to plan ahead, and have the new kernel pre-loaded
> into some reserved memory so when the panic hits (or the INIT button
> is pressed) we don't need to do any I/O or memory allocation.  We just
> leap to the new kernel.  For this case ia64 would appear to have an
> advantage over other architectures ... we don't need to locate the new
> kernel at any particular address, so we can leave the original kernel
> untouched while we boot just using the reserved block of memory.
> 
> What's working?  What's still being developed?  Can we get this into
> shape for 2.6.15?
> 
> -Tony

I am testing my patch for 2.6.13 kernel. I will try to send it out next
week. A normal reboot using kexec (your case 1) works very reliably. I
have done 9000 back to back kexec reboots bypassing firmware each time
successfully. I have case 2 working as well. If a kernel is pre-loaded,
a pnic or INIT automatically causes a kexec reboot.

-- 
Khalid

==================================
Khalid Aziz                       Open Source and Linux Organization
(970)898-9214                                        Hewlett-Packard
khalid.aziz@hp.com                                  Fort Collins, CO

"The Linux kernel is subject to relentless development" 
                                - Alessandro Rubini

Re: [RFC] /proc/efi_memmap

[Khalid Aziz]

On Tue, 2005-09-13 at 12:30 -0700, Luck, Tony wrote:
> On Tue, Sep 13, 2005 at 10:05:03AM -0600, Khalid Aziz wrote:
> > The userspace kexec tools looks at the memory map to verify a new kernel
> > being loaded in memory will be loaded in memory that is normally
> > available for it. Same goes for initial ramdisk as well. kexec
> > opens /proc/iomem on x86 for this. I had sent a patch in July (subject
> > "[PATCH] /proc/iomem update") that provides same info in /proc/iomem as
> > x86 does and that will take care of kexec needs. I have already tested
> > kexec tool for ia64 with that patch and it works fine.
> 
> I should dust that off and take a look at it.  /proc/iomem seems a curious
> name for a file that contains this information.
> 
> So what is the current state of kexec for ia64?  I think that there
> are two modes of operation:
> 
> 1) Fast reboot (bypasses f/w ... which takes a significant amount of
>    the reboot time).
> 
> 2) A means to getting a running kernel to take a crash dump.
> 
> In case 1, the system is still running ... so kexec can load the new
> kernel from disk, and arrange for an orderly transfer of control from
> the old kernel to the new.
> 
> In case 2, we need to plan ahead, and have the new kernel pre-loaded
> into some reserved memory so when the panic hits (or the INIT button
> is pressed) we don't need to do any I/O or memory allocation.  We just
> leap to the new kernel.  For this case ia64 would appear to have an
> advantage over other architectures ... we don't need to locate the new
> kernel at any particular address, so we can leave the original kernel
> untouched while we boot just using the reserved block of memory.
> 
> What's working?  What's still being developed?  Can we get this into
> shape for 2.6.15?
> 
> -Tony

A working kexec patch requires the EFI memory map walk rewrite patch (so
we can pass a pristine EFI memory map to the kernel being kexec'd)
and /proc/iomem patch (for kexec-tool to work). I have been dragging my
feet on kexec patch partially since those two have not been accepted
yet :) If you add those two patches, it makes it lot easier for me to
give you a final kexec patch.

-- 
Khalid

==================================
Khalid Aziz                       Open Source and Linux Organization
(970)898-9214                                        Hewlett-Packard
khalid.aziz@hp.com                                  Fort Collins, CO

"The Linux kernel is subject to relentless development" 
                                - Alessandro Rubini