[2.6.6 PATCH] Exposing EFI memory map

[2.6.6 PATCH] Exposing EFI memory map

[Sourav Sen]

Hi,

The following simple patch creates a read-only file
"memmap" under <mount point>/firmware/efi/ in sysfs
and exposes the efi memory map thru it.

Thanks
Sourav


The patch is w.r.t 2.6.6-rc3
----------------------------
===========================================================================
--- a/drivers/firmware/efivars.c        2004-05-05 13:55:40.000000000 +0530
+++ b/drivers/firmware/efivars.c        2004-05-06 11:43:40.000000000 +0530
@@ -580,10 +580,42 @@ systab_read(struct subsystem *entry, cha
        return str - buf;
 }

+/*
+ * Expose the efi memory map as kernel keeps it. Note, it may be a little
+ * different from what gets actually passed in at loader handoff time as a
+ * call to efi_memmap_walk modifies that.
+ */
+
+static ssize_t
+efi_memmap_read(struct subsystem *entry, char * buf)
+{
+       void * efi_map_start, *efi_map_end, *p;
+       efi_memory_desc_t *md;
+       u64 efi_desc_size;
+       char * str = buf;
+
+       if (!entry || !buf)
+               return -EINVAL;
+
+       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;
+
+       for (p = efi_map_start; p < efi_map_end; p += efi_desc_size) {
+               md = (efi_memory_desc_t *)p;
+               str += sprintf(str, "%2u     %-#18lx    %#016lx %#016lx\n",
\
+                       md->type, md->attribute, md->phys_addr, \
+                       md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT));
+       }
+       return (str - buf);
+}
+
 static EFI_ATTR(systab, 0400, systab_read, NULL);
+static EFI_ATTR(memmap, 0400, efi_memmap_read, NULL);

 static struct subsys_attribute *efi_subsys_attrs[] = {
        &efi_attr_systab,
+       &efi_attr_memmap,       /* Here comes one */
        NULL,   /* maybe more in the future? */
 };

[2.6.6 PATCH] Exposing EFI memory map

[Sourav Sen]

Hi,

The following simple patch creates a read-only file
"memmap" under <mount point>/firmware/efi/ in sysfs
and exposes the efi memory map thru it.

Thanks
Sourav


The patch is w.r.t 2.6.6-rc3
----------------------------
=====================================--- a/drivers/firmware/efivars.c        2004-05-05 13:55:40.000000000 +0530
+++ b/drivers/firmware/efivars.c        2004-05-06 11:43:40.000000000 +0530
@@ -580,10 +580,42 @@ systab_read(struct subsystem *entry, cha
        return str - buf;
 }

+/*
+ * Expose the efi memory map as kernel keeps it. Note, it may be a little
+ * different from what gets actually passed in at loader handoff time as a
+ * call to efi_memmap_walk modifies that.
+ */
+
+static ssize_t
+efi_memmap_read(struct subsystem *entry, char * buf)
+{
+       void * efi_map_start, *efi_map_end, *p;
+       efi_memory_desc_t *md;
+       u64 efi_desc_size;
+       char * str = buf;
+
+       if (!entry || !buf)
+               return -EINVAL;
+
+       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;
+
+       for (p = efi_map_start; p < efi_map_end; p += efi_desc_size) {
+               md = (efi_memory_desc_t *)p;
+               str += sprintf(str, "%2u     %-#18lx    %#016lx %#016lx\n",
\
+                       md->type, md->attribute, md->phys_addr, \
+                       md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT));
+       }
+       return (str - buf);
+}
+
 static EFI_ATTR(systab, 0400, systab_read, NULL);
+static EFI_ATTR(memmap, 0400, efi_memmap_read, NULL);

 static struct subsys_attribute *efi_subsys_attrs[] = {
        &efi_attr_systab,
+       &efi_attr_memmap,       /* Here comes one */
        NULL,   /* maybe more in the future? */
 };

Re: [2.6.6 PATCH] Exposing EFI memory map

[Christoph Hellwig]

On Thu, May 06, 2004 at 02:22:46PM +0530, Sourav Sen wrote:
> Hi,
> 
> The following simple patch creates a read-only file
> "memmap" under <mount point>/firmware/efi/ in sysfs
> and exposes the efi memory map thru it.

doesn't exactly fit into the one value per file approach, does it?

Re: [2.6.6 PATCH] Exposing EFI memory map

[Christoph Hellwig]

On Thu, May 06, 2004 at 02:22:46PM +0530, Sourav Sen wrote:
> Hi,
> 
> The following simple patch creates a read-only file
> "memmap" under <mount point>/firmware/efi/ in sysfs
> and exposes the efi memory map thru it.

doesn't exactly fit into the one value per file approach, does it?

Re: [2.6.6 PATCH] Exposing EFI memory map

[Matthew Wilcox]

On Thu, May 06, 2004 at 11:44:14AM +0100, Christoph Hellwig wrote:
> On Thu, May 06, 2004 at 02:22:46PM +0530, Sourav Sen wrote:
> > Hi,
> > 
> > The following simple patch creates a read-only file
> > "memmap" under <mount point>/firmware/efi/ in sysfs
> > and exposes the efi memory map thru it.
> 
> doesn't exactly fit into the one value per file approach, does it?

It's not exactly modifiable.  I'm not sure what benefit we'd gain from
splitting this file into dozens.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: [2.6.6 PATCH] Exposing EFI memory map

[Matthew Wilcox]

On Thu, May 06, 2004 at 11:44:14AM +0100, Christoph Hellwig wrote:
> On Thu, May 06, 2004 at 02:22:46PM +0530, Sourav Sen wrote:
> > Hi,
> > 
> > The following simple patch creates a read-only file
> > "memmap" under <mount point>/firmware/efi/ in sysfs
> > and exposes the efi memory map thru it.
> 
> doesn't exactly fit into the one value per file approach, does it?

It's not exactly modifiable.  I'm not sure what benefit we'd gain from
splitting this file into dozens.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: [2.6.6 PATCH] Exposing EFI memory map

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 682 bytes --]

On Thu, 2004-05-06 at 13:59, Matthew Wilcox wrote:
> On Thu, May 06, 2004 at 11:44:14AM +0100, Christoph Hellwig wrote:
> > On Thu, May 06, 2004 at 02:22:46PM +0530, Sourav Sen wrote:
> > > Hi,
> > > 
> > > The following simple patch creates a read-only file
> > > "memmap" under <mount point>/firmware/efi/ in sysfs
> > > and exposes the efi memory map thru it.
> > 
> > doesn't exactly fit into the one value per file approach, does it?
> 
> It's not exactly modifiable. 

come on, it's the ideal hotplug memory interface ;)
should we try to unify the memory map exports between architectures
instead of matching the firmware-of-the-day for each architecture ??


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [2.6.6 PATCH] Exposing EFI memory map

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 682 bytes --]

On Thu, 2004-05-06 at 13:59, Matthew Wilcox wrote:
> On Thu, May 06, 2004 at 11:44:14AM +0100, Christoph Hellwig wrote:
> > On Thu, May 06, 2004 at 02:22:46PM +0530, Sourav Sen wrote:
> > > Hi,
> > > 
> > > The following simple patch creates a read-only file
> > > "memmap" under <mount point>/firmware/efi/ in sysfs
> > > and exposes the efi memory map thru it.
> > 
> > doesn't exactly fit into the one value per file approach, does it?
> 
> It's not exactly modifiable. 

come on, it's the ideal hotplug memory interface ;)
should we try to unify the memory map exports between architectures
instead of matching the firmware-of-the-day for each architecture ??


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [2.6.6 PATCH] Exposing EFI memory map

[Matthew Wilcox]

On Thu, May 06, 2004 at 02:18:24PM +0200, Arjan van de Ven wrote:
> On Thu, 2004-05-06 at 13:59, Matthew Wilcox wrote:
> > On Thu, May 06, 2004 at 11:44:14AM +0100, Christoph Hellwig wrote:
> > > On Thu, May 06, 2004 at 02:22:46PM +0530, Sourav Sen wrote:
> > > > Hi,
> > > > 
> > > > The following simple patch creates a read-only file
> > > > "memmap" under <mount point>/firmware/efi/ in sysfs
> > > > and exposes the efi memory map thru it.
> > > 
> > > doesn't exactly fit into the one value per file approach, does it?
> > 
> > It's not exactly modifiable. 
> 
> come on, it's the ideal hotplug memory interface ;)
> should we try to unify the memory map exports between architectures
> instead of matching the firmware-of-the-day for each architecture ??

Well, firmware-du-jour is what /sys/firmware/... is for ;-)

I don't have a clear picture of what a hotplug memory interface would look
like; and even if I did, I don't think the EFI memory map is of much help
in that matter.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: [2.6.6 PATCH] Exposing EFI memory map

[Matthew Wilcox]

On Thu, May 06, 2004 at 02:18:24PM +0200, Arjan van de Ven wrote:
> On Thu, 2004-05-06 at 13:59, Matthew Wilcox wrote:
> > On Thu, May 06, 2004 at 11:44:14AM +0100, Christoph Hellwig wrote:
> > > On Thu, May 06, 2004 at 02:22:46PM +0530, Sourav Sen wrote:
> > > > Hi,
> > > > 
> > > > The following simple patch creates a read-only file
> > > > "memmap" under <mount point>/firmware/efi/ in sysfs
> > > > and exposes the efi memory map thru it.
> > > 
> > > doesn't exactly fit into the one value per file approach, does it?
> > 
> > It's not exactly modifiable. 
> 
> come on, it's the ideal hotplug memory interface ;)
> should we try to unify the memory map exports between architectures
> instead of matching the firmware-of-the-day for each architecture ??

Well, firmware-du-jour is what /sys/firmware/... is for ;-)

I don't have a clear picture of what a hotplug memory interface would look
like; and even if I did, I don't think the EFI memory map is of much help
in that matter.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: [2.6.6 PATCH] Exposing EFI memory map

[Dave Hansen]

On Thu, 2004-05-06 at 06:27, Matthew Wilcox wrote:
> On Thu, May 06, 2004 at 02:18:24PM +0200, Arjan van de Ven wrote:
> > On Thu, 2004-05-06 at 13:59, Matthew Wilcox wrote:
> > > It's not exactly modifiable. 
> > 
> > come on, it's the ideal hotplug memory interface ;)
> > should we try to unify the memory map exports between architectures
> > instead of matching the firmware-of-the-day for each architecture ??
> 
> Well, firmware-du-jour is what /sys/firmware/... is for ;-)
> 
> I don't have a clear picture of what a hotplug memory interface would look
> like; and even if I did, I don't think the EFI memory map is of much help
> in that matter.

If you _get_ a clear picture, please let me know.  I've been looking for
one. :)

You're right that the EFI map itself isn't any help to memory hotplug,
but things derived from it are.  The amount and physical locations of
all of the memory in the system are obviously pulled out of this table
at some point, and Linux already has a representation of them, otherwise
we couldn't allocate memory or do things like virt_to_phys() or
page_to_pfn().

I think what Arjan doesn't want is 14 different architectures with 14
different userspace programs reading 14 different things in /proc and
/sys for each of their memory hotplug schemes.  I guarantee you don't
want to know what ppc64 is planning on doing.

BTW, Sourav, what is it that you need from the EFI map?  Could you take
a quick look through the lhms-devel list archives and see if anything
there is similar to what you're trying to do? Here's a place to start:

http://sourceforge.net/mailarchive/forum.php?thread_idA20609&forum_id"3


-- Dave

Re: [2.6.6 PATCH] Exposing EFI memory map

[Dave Hansen]

On Thu, 2004-05-06 at 06:27, Matthew Wilcox wrote:
> On Thu, May 06, 2004 at 02:18:24PM +0200, Arjan van de Ven wrote:
> > On Thu, 2004-05-06 at 13:59, Matthew Wilcox wrote:
> > > It's not exactly modifiable. 
> > 
> > come on, it's the ideal hotplug memory interface ;)
> > should we try to unify the memory map exports between architectures
> > instead of matching the firmware-of-the-day for each architecture ??
> 
> Well, firmware-du-jour is what /sys/firmware/... is for ;-)
> 
> I don't have a clear picture of what a hotplug memory interface would look
> like; and even if I did, I don't think the EFI memory map is of much help
> in that matter.

If you _get_ a clear picture, please let me know.  I've been looking for
one. :)

You're right that the EFI map itself isn't any help to memory hotplug,
but things derived from it are.  The amount and physical locations of
all of the memory in the system are obviously pulled out of this table
at some point, and Linux already has a representation of them, otherwise
we couldn't allocate memory or do things like virt_to_phys() or
page_to_pfn().

I think what Arjan doesn't want is 14 different architectures with 14
different userspace programs reading 14 different things in /proc and
/sys for each of their memory hotplug schemes.  I guarantee you don't
want to know what ppc64 is planning on doing.

BTW, Sourav, what is it that you need from the EFI map?  Could you take
a quick look through the lhms-devel list archives and see if anything
there is similar to what you're trying to do? Here's a place to start:

http://sourceforge.net/mailarchive/forum.php?thread_id=4120609&forum_id=223


-- Dave

Re: [2.6.6 PATCH] Exposing EFI memory map

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 337 bytes --]


On Thu, May 06, 2004 at 07:00:40AM -0700, Dave Hansen wrote:
> I think what Arjan doesn't want is 14 different architectures with 14
> different userspace programs reading 14 different things in /proc and
> /sys for each of their memory hotplug schemes. 

*exactly*

well 14 architecture and 28 programs because firmware got rev'ed ;)


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [2.6.6 PATCH] Exposing EFI memory map

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 337 bytes --]


On Thu, May 06, 2004 at 07:00:40AM -0700, Dave Hansen wrote:
> I think what Arjan doesn't want is 14 different architectures with 14
> different userspace programs reading 14 different things in /proc and
> /sys for each of their memory hotplug schemes. 

*exactly*

well 14 architecture and 28 programs because firmware got rev'ed ;)


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [2.6.6 PATCH] Exposing EFI memory map

[Christoph Hellwig]

On Thu, May 06, 2004 at 12:59:19PM +0100, Matthew Wilcox wrote:
> It's not exactly modifiable.  I'm not sure what benefit we'd gain from
> splitting this file into dozens.

a consistant interface.  If we support gazillion random formats in sysfs
it's no gain at all over the old procfs mess.

Re: [2.6.6 PATCH] Exposing EFI memory map

[Christoph Hellwig]

On Thu, May 06, 2004 at 12:59:19PM +0100, Matthew Wilcox wrote:
> It's not exactly modifiable.  I'm not sure what benefit we'd gain from
> splitting this file into dozens.

a consistant interface.  If we support gazillion random formats in sysfs
it's no gain at all over the old procfs mess.

Re: [2.6.6 PATCH] Exposing EFI memory map

[Matt Domsch]

[-- Attachment #1: Type: text/plain, Size: 902 bytes --]

On Thu, May 06, 2004 at 02:22:46PM +0530, Sourav Sen wrote:
> The following simple patch creates a read-only file
> "memmap" under <mount point>/firmware/efi/ in sysfs
> and exposes the efi memory map thru it.

I'm not generally opposed, but have a couple questions.

1) Why does userspace / humans need to know this?  For debugging firmware?

2) Can the memory map output ever be larger than PAGE_SIZE (lower
limit is 4KB on x86)?  If not, what guarantees that?  If so, you need
your own read mechanism rather than the generic sysfs one.

The one-value-per-file rule has an exception for an array of values of
the same type per Documentation/filesystems/sysfs.txt, which this
looks to adhere to.

Thanks,
Matt

-- 
Matt Domsch
Sr. Software Engineer, Lead Engineer
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [2.6.6 PATCH] Exposing EFI memory map

[Matt Domsch]

[-- Attachment #1: Type: text/plain, Size: 902 bytes --]

On Thu, May 06, 2004 at 02:22:46PM +0530, Sourav Sen wrote:
> The following simple patch creates a read-only file
> "memmap" under <mount point>/firmware/efi/ in sysfs
> and exposes the efi memory map thru it.

I'm not generally opposed, but have a couple questions.

1) Why does userspace / humans need to know this?  For debugging firmware?

2) Can the memory map output ever be larger than PAGE_SIZE (lower
limit is 4KB on x86)?  If not, what guarantees that?  If so, you need
your own read mechanism rather than the generic sysfs one.

The one-value-per-file rule has an exception for an array of values of
the same type per Documentation/filesystems/sysfs.txt, which this
looks to adhere to.

Thanks,
Matt

-- 
Matt Domsch
Sr. Software Engineer, Lead Engineer
Dell Linux Solutions linux.dell.com & www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

RE: [2.6.6 PATCH] Exposing EFI memory map

[Sourav Sen]

Hi Matt,

+ -----Original Message-----
+ From: Matt Domsch [mailto:Matt_Domsch@dell.com]
+ On Thu, May 06, 2004 at 02:22:46PM +0530, Sourav Sen wrote:
+ > The following simple patch creates a read-only file
+ > "memmap" under <mount point>/firmware/efi/ in sysfs
+ > and exposes the efi memory map thru it.
+ 
+ I'm not generally opposed, but have a couple questions.
+ 
+ 1) Why does userspace / humans need to know this?  For 
+ debugging firmware?
	
	Maybe. But the point I had in mind is, say for example
memory diagnostics applications/exercisers which reads (Blind
reads, without caring about contents) memory
to uncover errors (single bit errors)  can use
this to know the usable ranges and map them thru /dev/mem and
read those ranges.

+ 
+ 2) Can the memory map output ever be larger than PAGE_SIZE (lower
+ limit is 4KB on x86)?  If not, what guarantees that?  If so, you need
+ your own read mechanism rather than the generic sysfs one.
+ 

	I don't have an answer right now. I'll investigate. Tony Luck also 
expressed similar concerns and suggested seq*() interfaces. I'll see
how I can do that.

+ The one-value-per-file rule has an exception for an array of values of
+ the same type per Documentation/filesystems/sysfs.txt, which this
+ looks to adhere to.
+ 
+ Thanks,
+ Matt
+ 
+ -- 
+ Matt Domsch
+ Sr. Software Engineer, Lead Engineer
+ Dell Linux Solutions linux.dell.com & www.dell.com/linux
+ Linux on Dell mailing lists @ http://lists.us.dell.com
+ 

Thanks
Sourav

RE: [2.6.6 PATCH] Exposing EFI memory map

[Sourav Sen]

Hi Matt,

+ -----Original Message-----
+ From: Matt Domsch [mailto:Matt_Domsch@dell.com]
+ On Thu, May 06, 2004 at 02:22:46PM +0530, Sourav Sen wrote:
+ > The following simple patch creates a read-only file
+ > "memmap" under <mount point>/firmware/efi/ in sysfs
+ > and exposes the efi memory map thru it.
+ 
+ I'm not generally opposed, but have a couple questions.
+ 
+ 1) Why does userspace / humans need to know this?  For 
+ debugging firmware?
	
	Maybe. But the point I had in mind is, say for example
memory diagnostics applications/exercisers which reads (Blind
reads, without caring about contents) memory
to uncover errors (single bit errors)  can use
this to know the usable ranges and map them thru /dev/mem and
read those ranges.

+ 
+ 2) Can the memory map output ever be larger than PAGE_SIZE (lower
+ limit is 4KB on x86)?  If not, what guarantees that?  If so, you need
+ your own read mechanism rather than the generic sysfs one.
+ 

	I don't have an answer right now. I'll investigate. Tony Luck also 
expressed similar concerns and suggested seq*() interfaces. I'll see
how I can do that.

+ The one-value-per-file rule has an exception for an array of values of
+ the same type per Documentation/filesystems/sysfs.txt, which this
+ looks to adhere to.
+ 
+ Thanks,
+ Matt
+ 
+ -- 
+ Matt Domsch
+ Sr. Software Engineer, Lead Engineer
+ Dell Linux Solutions linux.dell.com & www.dell.com/linux
+ Linux on Dell mailing lists @ http://lists.us.dell.com
+ 

Thanks
Sourav

Re: [2.6.6 PATCH] Exposing EFI memory map

[Bjorn Helgaas]

On Thursday 06 May 2004 7:20 am, Sourav Sen wrote:
> + 1) Why does userspace / humans need to know this?  For 
> + debugging firmware?
> 	
> 	Maybe. But the point I had in mind is, say for example
> memory diagnostics applications/exercisers which reads (Blind
> reads, without caring about contents) memory
> to uncover errors (single bit errors)  can use
> this to know the usable ranges and map them thru /dev/mem and
> read those ranges.

For this application, the EFI memory map isn't what you want.
It's a pretty good approximation today, but the day when we'll
be able to hot-add memory is fast approaching, and the EFI map
won't mention anything added after boot.  We'll discover all
that via ACPI (on ia64).

Re: [2.6.6 PATCH] Exposing EFI memory map

[Bjorn Helgaas]

On Thursday 06 May 2004 7:20 am, Sourav Sen wrote:
> + 1) Why does userspace / humans need to know this?  For 
> + debugging firmware?
> 	
> 	Maybe. But the point I had in mind is, say for example
> memory diagnostics applications/exercisers which reads (Blind
> reads, without caring about contents) memory
> to uncover errors (single bit errors)  can use
> this to know the usable ranges and map them thru /dev/mem and
> read those ranges.

For this application, the EFI memory map isn't what you want.
It's a pretty good approximation today, but the day when we'll
be able to hot-add memory is fast approaching, and the EFI map
won't mention anything added after boot.  We'll discover all
that via ACPI (on ia64).

RE: [2.6.6 PATCH] Exposing EFI memory map

[Sourav Sen]

+ -----Original Message-----
+ From: Bjorn Helgaas [mailto:bjorn.helgaas@hp.com]
+ Sent: Thursday, May 06, 2004 8:39 PM
+ To: Sourav Sen
+ Cc: 'Matt Domsch'; matthew.e.tolentino@intel.com;
+ linux-ia64@vger.kernel.org; linux-kernel@vger.kernel.org;
+ tony.luck@intel.com
+ Subject: Re: [2.6.6 PATCH] Exposing EFI memory map
+ 
+ 
+ On Thursday 06 May 2004 7:20 am, Sourav Sen wrote:
+ > + 1) Why does userspace / humans need to know this?  For 
+ > + debugging firmware?
+ > 	
+ > 	Maybe. But the point I had in mind is, say for example
+ > memory diagnostics applications/exercisers which reads (Blind
+ > reads, without caring about contents) memory
+ > to uncover errors (single bit errors)  can use
+ > this to know the usable ranges and map them thru /dev/mem and
+ > read those ranges.
+ 
+ For this application, the EFI memory map isn't what you want.
+ It's a pretty good approximation today, but the day when we'll
+ be able to hot-add memory is fast approaching, and the EFI map
+ won't mention anything added after boot.  We'll discover all
+ that via ACPI (on ia64).
+ 

	Why not also update the efi memory table on a hotplug :-)
(Now also it gets modified a little on a call to efi_memmap_walk()).
Otherwise clients of efi_memmap_walk() will also get stale 
information after a hotplug, isn't it (assuming they want to
know about available physical ranges)?

	Also, kernel may not exactly use all the memory added via
hotplug and there may be some truncation (just as efi_memmap_walk()
does today). And it isn't help us if we get to know about those
extents. Additionally we get to know about various mmio ranges and
other ranges thru that table -- may be useful opportunistically.

--Sourav

RE: [2.6.6 PATCH] Exposing EFI memory map

[Sourav Sen]

+ -----Original Message-----
+ From: Bjorn Helgaas [mailto:bjorn.helgaas@hp.com]
+ Sent: Thursday, May 06, 2004 8:39 PM
+ To: Sourav Sen
+ Cc: 'Matt Domsch'; matthew.e.tolentino@intel.com;
+ linux-ia64@vger.kernel.org; linux-kernel@vger.kernel.org;
+ tony.luck@intel.com
+ Subject: Re: [2.6.6 PATCH] Exposing EFI memory map
+ 
+ 
+ On Thursday 06 May 2004 7:20 am, Sourav Sen wrote:
+ > + 1) Why does userspace / humans need to know this?  For 
+ > + debugging firmware?
+ > 	
+ > 	Maybe. But the point I had in mind is, say for example
+ > memory diagnostics applications/exercisers which reads (Blind
+ > reads, without caring about contents) memory
+ > to uncover errors (single bit errors)  can use
+ > this to know the usable ranges and map them thru /dev/mem and
+ > read those ranges.
+ 
+ For this application, the EFI memory map isn't what you want.
+ It's a pretty good approximation today, but the day when we'll
+ be able to hot-add memory is fast approaching, and the EFI map
+ won't mention anything added after boot.  We'll discover all
+ that via ACPI (on ia64).
+ 

	Why not also update the efi memory table on a hotplug :-)
(Now also it gets modified a little on a call to efi_memmap_walk()).
Otherwise clients of efi_memmap_walk() will also get stale 
information after a hotplug, isn't it (assuming they want to
know about available physical ranges)?

	Also, kernel may not exactly use all the memory added via
hotplug and there may be some truncation (just as efi_memmap_walk()
does today). And it isn't help us if we get to know about those
extents. Additionally we get to know about various mmio ranges and
other ranges thru that table -- may be useful opportunistically.

--Sourav

RE: [2.6.6 PATCH] Exposing EFI memory map

[Dave Hansen]

On Thu, 2004-05-06 at 09:25, Sourav Sen wrote:
> From: Bjorn Helgaas [mailto:bjorn.helgaas@hp.com]
> + For this application, the EFI memory map isn't what you want.
> + It's a pretty good approximation today, but the day when we'll
> + be able to hot-add memory is fast approaching, and the EFI map
> + won't mention anything added after boot.  We'll discover all
> + that via ACPI (on ia64).
>
> 	Why not also update the efi memory table on a hotplug :-)

That's actually what ppc64 does.  But, they do it via /proc (not even
from inside the kernel).  I'm not very fond of that solution :)

> (Now also it gets modified a little on a call to efi_memmap_walk()).
> Otherwise clients of efi_memmap_walk() will also get stale 
> information after a hotplug, isn't it (assuming they want to
> know about available physical ranges)?

We'll probably end up having to lock down hotplug around the time that
someone *needs* persistent information about memory layout from
userspace.  Think crashdump...

> Also, kernel may not exactly use all the memory added via hotplug

That's a good point.  Some of the happy consumers of this should be
things like crashdump and kexec.  They might want a choice to either
dump only the memory that Linux is currently using, or to know about all
of the memory that is present.  

>  and there may be some truncation (just as efi_memmap_walk()
> does today). And it isn't help us if we get to know about those
> extents. Additionally we get to know about various mmio ranges and
> other ranges thru that table -- may be useful opportunistically.

There can be some pretty generic (although asynchronous) events given
via /sbin/hotplug.  I'm currently planning on having the memory hotplug
"drivers" get the hot-added memory ready, but keep it offline.  It then
creates some kobjects, which generate hotplug events, and *then* the
decision can be made in the hotplug scripts about what to do with it.

-- Dave

RE: [2.6.6 PATCH] Exposing EFI memory map

[Dave Hansen]

On Thu, 2004-05-06 at 09:25, Sourav Sen wrote:
> From: Bjorn Helgaas [mailto:bjorn.helgaas@hp.com]
> + For this application, the EFI memory map isn't what you want.
> + It's a pretty good approximation today, but the day when we'll
> + be able to hot-add memory is fast approaching, and the EFI map
> + won't mention anything added after boot.  We'll discover all
> + that via ACPI (on ia64).
>
> 	Why not also update the efi memory table on a hotplug :-)

That's actually what ppc64 does.  But, they do it via /proc (not even
from inside the kernel).  I'm not very fond of that solution :)

> (Now also it gets modified a little on a call to efi_memmap_walk()).
> Otherwise clients of efi_memmap_walk() will also get stale 
> information after a hotplug, isn't it (assuming they want to
> know about available physical ranges)?

We'll probably end up having to lock down hotplug around the time that
someone *needs* persistent information about memory layout from
userspace.  Think crashdump...

> Also, kernel may not exactly use all the memory added via hotplug

That's a good point.  Some of the happy consumers of this should be
things like crashdump and kexec.  They might want a choice to either
dump only the memory that Linux is currently using, or to know about all
of the memory that is present.  

>  and there may be some truncation (just as efi_memmap_walk()
> does today). And it isn't help us if we get to know about those
> extents. Additionally we get to know about various mmio ranges and
> other ranges thru that table -- may be useful opportunistically.

There can be some pretty generic (although asynchronous) events given
via /sbin/hotplug.  I'm currently planning on having the memory hotplug
"drivers" get the hot-added memory ready, but keep it offline.  It then
creates some kobjects, which generate hotplug events, and *then* the
decision can be made in the hotplug scripts about what to do with it.

-- Dave

RE: [2.6.6 PATCH] Exposing EFI memory map

[Luck, Tony]

>2) Can the memory map output ever be larger than PAGE_SIZE (lower
>limit is 4KB on x86)?  If not, what guarantees that?  If so, you need
>your own read mechanism rather than the generic sysfs one.

The output format of the sprintf() gives 58 characters per entry, which
with a 4k page allows for 70 entries before the page overflows, which
feels borderline for ccNUMA machines.  On ia64 the pagesize is usually
16k, which would allow 282 entries.  I think this will fail on a 128
node SGI sn2 (because there are 4 memory banks per node => min 512
entries
in the memory map).

-Tony

RE: [2.6.6 PATCH] Exposing EFI memory map

[Luck, Tony]

>2) Can the memory map output ever be larger than PAGE_SIZE (lower
>limit is 4KB on x86)?  If not, what guarantees that?  If so, you need
>your own read mechanism rather than the generic sysfs one.

The output format of the sprintf() gives 58 characters per entry, which
with a 4k page allows for 70 entries before the page overflows, which
feels borderline for ccNUMA machines.  On ia64 the pagesize is usually
16k, which would allow 282 entries.  I think this will fail on a 128
node SGI sn2 (because there are 4 memory banks per node => min 512
entries
in the memory map).

-Tony

RE: [2.6.6 PATCH] Exposing EFI memory map

[Tolentino, Matthew E]

> 2) Can the memory map output ever be larger than PAGE_SIZE (lower
> limit is 4KB on x86)?  If not, what guarantees that?  If so, you need
> your own read mechanism rather than the generic sysfs one.

There are no size guarantees with the EFI memory map.  It could
be of various sizes...

matt

RE: [2.6.6 PATCH] Exposing EFI memory map

[Tolentino, Matthew E]

> 2) Can the memory map output ever be larger than PAGE_SIZE (lower
> limit is 4KB on x86)?  If not, what guarantees that?  If so, you need
> your own read mechanism rather than the generic sysfs one.

There are no size guarantees with the EFI memory map.  It could
be of various sizes...

matt

Re: [2.6.6 PATCH] Exposing EFI memory map

[Greg KH]

On Thu, May 06, 2004 at 02:22:46PM +0530, Sourav Sen wrote:
> 
> The following simple patch creates a read-only file
> "memmap" under <mount point>/firmware/efi/ in sysfs
> and exposes the efi memory map thru it.

No, data in this kind of format does not belong in sysfs.

thanks,

greg k-h

Re: [2.6.6 PATCH] Exposing EFI memory map

[Greg KH]

On Thu, May 06, 2004 at 02:22:46PM +0530, Sourav Sen wrote:
> 
> The following simple patch creates a read-only file
> "memmap" under <mount point>/firmware/efi/ in sysfs
> and exposes the efi memory map thru it.

No, data in this kind of format does not belong in sysfs.

thanks,

greg k-h

RE: [2.6.6 PATCH] Exposing EFI memory map

[Sourav Sen]

Hi Greg,

+ -----Original Message-----
+ From: Greg KH [mailto:greg@kroah.com]
+ Sent: Thursday, May 06, 2004 10:11 PM
+ To: Sourav Sen
+ Cc: Matt_Domsch@dell.com; matthew.e.tolentino@intel.com;
+ linux-ia64@vger.kernel.org; linux-kernel@vger.kernel.org
+ Subject: Re: [2.6.6 PATCH] Exposing EFI memory map
+
+
+ On Thu, May 06, 2004 at 02:22:46PM +0530, Sourav Sen wrote:
+ >
+ > The following simple patch creates a read-only file
+ > "memmap" under <mount point>/firmware/efi/ in sysfs
+ > and exposes the efi memory map thru it.
+
+ No, data in this kind of format does not belong in sysfs.

	Please tell me more. In Documentation/filesystems/sysfs.txt
I get:

"Attributes should be ASCII text files, preferably with only one value
per file. It is noted that it may not be efficient to contain only
value per file, so it is socially acceptable to express an array of
values of the same type."

Here we have "Array of values of same types". And it does not do much
nifty formatting either. Is that not acceptable?

If that is not, how about the following.

	1. Create a directory "memmap" under firmware/efi/
	2. Create files "map_start", "map_size" and "mapdesc_size" under
         that exposing ia64_boot_param->efi_memmap,
ia64_boot_param->efi_memmap_size
	   and ia64_boot_param->efi_memdesc_size respectively.

Userland can make meaning out of them by knowing the values and knowing
about
"efi_memory_desc_t" which is already there in /usr/include/asm/efi.h


Thanks
Sourav

PS: BTW, Your slides on "Dealing with the Linux Kernel Community" at:
http://www.kroah.com/linux/talks/cgl_talk_2002_10_16/mgp00001.html
is kind of useful to me. This is my first time :-)

RE: [2.6.6 PATCH] Exposing EFI memory map

[Sourav Sen]

Hi Greg,

+ -----Original Message-----
+ From: Greg KH [mailto:greg@kroah.com]
+ Sent: Thursday, May 06, 2004 10:11 PM
+ To: Sourav Sen
+ Cc: Matt_Domsch@dell.com; matthew.e.tolentino@intel.com;
+ linux-ia64@vger.kernel.org; linux-kernel@vger.kernel.org
+ Subject: Re: [2.6.6 PATCH] Exposing EFI memory map
+
+
+ On Thu, May 06, 2004 at 02:22:46PM +0530, Sourav Sen wrote:
+ >
+ > The following simple patch creates a read-only file
+ > "memmap" under <mount point>/firmware/efi/ in sysfs
+ > and exposes the efi memory map thru it.
+
+ No, data in this kind of format does not belong in sysfs.

	Please tell me more. In Documentation/filesystems/sysfs.txt
I get:

"Attributes should be ASCII text files, preferably with only one value
per file. It is noted that it may not be efficient to contain only
value per file, so it is socially acceptable to express an array of
values of the same type."

Here we have "Array of values of same types". And it does not do much
nifty formatting either. Is that not acceptable?

If that is not, how about the following.

	1. Create a directory "memmap" under firmware/efi/
	2. Create files "map_start", "map_size" and "mapdesc_size" under
         that exposing ia64_boot_param->efi_memmap,
ia64_boot_param->efi_memmap_size
	   and ia64_boot_param->efi_memdesc_size respectively.

Userland can make meaning out of them by knowing the values and knowing
about
"efi_memory_desc_t" which is already there in /usr/include/asm/efi.h


Thanks
Sourav

PS: BTW, Your slides on "Dealing with the Linux Kernel Community" at:
http://www.kroah.com/linux/talks/cgl_talk_2002_10_16/mgp00001.html
is kind of useful to me. This is my first time :-)

Re: [2.6.6 PATCH] Exposing EFI memory map

[Greg KH]

On Fri, May 07, 2004 at 03:15:30PM +0530, Sourav Sen wrote:
> Here we have "Array of values of same types". And it does not do much
> nifty formatting either. Is that not acceptable?

But they are not of the same time, as you admitted :)

Also, they could be bigger than a single page, right?  That is not
possible right now in sysfs.

> If that is not, how about the following.
> 
> 	1. Create a directory "memmap" under firmware/efi/
> 	2. Create files "map_start", "map_size" and "mapdesc_size" under
>          that exposing ia64_boot_param->efi_memmap,
> ia64_boot_param->efi_memmap_size
> 	   and ia64_boot_param->efi_memdesc_size respectively.
> 
> Userland can make meaning out of them by knowing the values and knowing
> about "efi_memory_desc_t" which is already there in
> /usr/include/asm/efi.h

I think you should address the other issues in this thread before
worrying about the sysfs interface (why have this at all, incorrect
data for hotplug mem, etc.)

> PS: BTW, Your slides on "Dealing with the Linux Kernel Community" at:
> http://www.kroah.com/linux/talks/cgl_talk_2002_10_16/mgp00001.html
> is kind of useful to me. This is my first time :-)

If only more people/companies would heed those rules...

thanks,

greg k-h

Re: [2.6.6 PATCH] Exposing EFI memory map

[Greg KH]

On Fri, May 07, 2004 at 03:15:30PM +0530, Sourav Sen wrote:
> Here we have "Array of values of same types". And it does not do much
> nifty formatting either. Is that not acceptable?

But they are not of the same time, as you admitted :)

Also, they could be bigger than a single page, right?  That is not
possible right now in sysfs.

> If that is not, how about the following.
> 
> 	1. Create a directory "memmap" under firmware/efi/
> 	2. Create files "map_start", "map_size" and "mapdesc_size" under
>          that exposing ia64_boot_param->efi_memmap,
> ia64_boot_param->efi_memmap_size
> 	   and ia64_boot_param->efi_memdesc_size respectively.
> 
> Userland can make meaning out of them by knowing the values and knowing
> about "efi_memory_desc_t" which is already there in
> /usr/include/asm/efi.h

I think you should address the other issues in this thread before
worrying about the sysfs interface (why have this at all, incorrect
data for hotplug mem, etc.)

> PS: BTW, Your slides on "Dealing with the Linux Kernel Community" at:
> http://www.kroah.com/linux/talks/cgl_talk_2002_10_16/mgp00001.html
> is kind of useful to me. This is my first time :-)

If only more people/companies would heed those rules...

thanks,

greg k-h

RE: [2.6.6 PATCH] Exposing EFI memory map

[Sourav Sen]

+ -----Original Message-----
+ From: Greg KH [mailto:greg@kroah.com]
+ Sent: Saturday, May 08, 2004 3:19 AM
+ To: Sourav Sen
+ Cc: Matt_Domsch@dell.com; matthew.e.tolentino@intel.com;
+ linux-ia64@vger.kernel.org; linux-kernel@vger.kernel.org
+ Subject: Re: [2.6.6 PATCH] Exposing EFI memory map
+ 
+ 
+ On Fri, May 07, 2004 at 03:15:30PM +0530, Sourav Sen wrote:
+ > Here we have "Array of values of same types". And it does 
+ not do much
+ > nifty formatting either. Is that not acceptable?
+ 
+ But they are not of the same time, as you admitted :)
+ 

	Right. On similar lines I believe we need to split 
firmware/efi/systab as well.

+ Also, they could be bigger than a single page, right?  That is not
+ possible right now in sysfs.
+ 
+ > If that is not, how about the following.
+ > 
+ > 	1. Create a directory "memmap" under firmware/efi/
+ > 	2. Create files "map_start", "map_size" and "mapdesc_size" under
+ >          that exposing ia64_boot_param->efi_memmap,
+ > ia64_boot_param->efi_memmap_size
+ > 	   and ia64_boot_param->efi_memdesc_size respectively.
+ > 
+ > Userland can make meaning out of them by knowing the values 
+ and knowing
+ > about "efi_memory_desc_t" which is already there in
+ > /usr/include/asm/efi.h
+ 
+ I think you should address the other issues in this thread before
+ worrying about the sysfs interface (why have this at all, incorrect
+ data for hotplug mem, etc.)
+ 
	I did not hear whether the idea of updating efi memory map on a 
hotplug is good or bad. In any case, can somebody tell me to how do 
I get the available physical range map (only the ranges that VM is 
using at a given point in time) from userland. I believe I outlined 
a legitimate requirement earlier in this thread :-)

Thanks
Sourav 

RE: [2.6.6 PATCH] Exposing EFI memory map

[Sourav Sen]

+ -----Original Message-----
+ From: Greg KH [mailto:greg@kroah.com]
+ Sent: Saturday, May 08, 2004 3:19 AM
+ To: Sourav Sen
+ Cc: Matt_Domsch@dell.com; matthew.e.tolentino@intel.com;
+ linux-ia64@vger.kernel.org; linux-kernel@vger.kernel.org
+ Subject: Re: [2.6.6 PATCH] Exposing EFI memory map
+ 
+ 
+ On Fri, May 07, 2004 at 03:15:30PM +0530, Sourav Sen wrote:
+ > Here we have "Array of values of same types". And it does 
+ not do much
+ > nifty formatting either. Is that not acceptable?
+ 
+ But they are not of the same time, as you admitted :)
+ 

	Right. On similar lines I believe we need to split 
firmware/efi/systab as well.

+ Also, they could be bigger than a single page, right?  That is not
+ possible right now in sysfs.
+ 
+ > If that is not, how about the following.
+ > 
+ > 	1. Create a directory "memmap" under firmware/efi/
+ > 	2. Create files "map_start", "map_size" and "mapdesc_size" under
+ >          that exposing ia64_boot_param->efi_memmap,
+ > ia64_boot_param->efi_memmap_size
+ > 	   and ia64_boot_param->efi_memdesc_size respectively.
+ > 
+ > Userland can make meaning out of them by knowing the values 
+ and knowing
+ > about "efi_memory_desc_t" which is already there in
+ > /usr/include/asm/efi.h
+ 
+ I think you should address the other issues in this thread before
+ worrying about the sysfs interface (why have this at all, incorrect
+ data for hotplug mem, etc.)
+ 
	I did not hear whether the idea of updating efi memory map on a 
hotplug is good or bad. In any case, can somebody tell me to how do 
I get the available physical range map (only the ranges that VM is 
using at a given point in time) from userland. I believe I outlined 
a legitimate requirement earlier in this thread :-)

Thanks
Sourav 

RE: [2.6.6 PATCH] Exposing EFI memory map

[Dave Hansen]

On Tue, 2004-05-11 at 07:44, Sourav Sen wrote:
> + I think you should address the other issues in this thread before
> + worrying about the sysfs interface (why have this at all, incorrect
> + data for hotplug mem, etc.)
> + 
> 	I did not hear whether the idea of updating efi memory map on a 
> hotplug is good or bad. In any case, can somebody tell me to how do 
> I get the available physical range map (only the ranges that VM is 
> using at a given point in time) from userland. I believe I outlined 
> a legitimate requirement earlier in this thread :-)

Let me paraphrase: exporting generic information in an architecture or
firmware-specific way in sysfs is bad.

I apologize, but I think I missed yout legitimate requirements earlier
in the thread.  Could you briefly remind me?

-- Dave

RE: [2.6.6 PATCH] Exposing EFI memory map

[Dave Hansen]

On Tue, 2004-05-11 at 07:44, Sourav Sen wrote:
> + I think you should address the other issues in this thread before
> + worrying about the sysfs interface (why have this at all, incorrect
> + data for hotplug mem, etc.)
> + 
> 	I did not hear whether the idea of updating efi memory map on a 
> hotplug is good or bad. In any case, can somebody tell me to how do 
> I get the available physical range map (only the ranges that VM is 
> using at a given point in time) from userland. I believe I outlined 
> a legitimate requirement earlier in this thread :-)

Let me paraphrase: exporting generic information in an architecture or
firmware-specific way in sysfs is bad.

I apologize, but I think I missed yout legitimate requirements earlier
in the thread.  Could you briefly remind me?

-- Dave

RE: [2.6.6 PATCH] Exposing EFI memory map

[Sourav Sen]

+ I think I missed yout legitimate requirements earlier
+ in the thread.  Could you briefly remind me?
+ 

Here:

http://www.uwsg.iu.edu/hypermail/linux/kernel/0405.0/0991.html

Thanks
Sourav

RE: [2.6.6 PATCH] Exposing EFI memory map

[Sourav Sen]

+ I think I missed yout legitimate requirements earlier
+ in the thread.  Could you briefly remind me?
+ 

Here:

http://www.uwsg.iu.edu/hypermail/linux/kernel/0405.0/0991.html

Thanks
Sourav

RE: [2.6.6 PATCH] Exposing EFI memory map

[Dave Hansen]

On Wed, 2004-05-12 at 03:24, Sourav Sen wrote:
> Maybe. But the point I had in mind is, say for example
> memory diagnostics applications/exercisers which reads (Blind
> reads, without caring about contents) memory
> to uncover errors (single bit errors) can use
> this to know the usable ranges and map them thru /dev/mem and
> read those ranges.

If you expose the EFI memory map, then you'll be able to write memory
diagnostics that will work on any EFI-based machine.

If you expose the EFI memory map in an architecture-independent fashion,
then you'll be able to write diagnostics that will work on any *Linux*
machine, plus all of the EFI machines.  Plus, by doing it first, you get
to greatly influence how the arch-independent stuff is done to make your
life the easiest.  

Think /sys/system/devices/memory, not /sys/firmware/efi.

We're planning on doing this anyway for memory hotplug, so some of the
work and ideas are already there.  I'd be happy to point you to some
past discussions and code on the subject.  

-- Dave

RE: [2.6.6 PATCH] Exposing EFI memory map

[Dave Hansen]

On Wed, 2004-05-12 at 03:24, Sourav Sen wrote:
> Maybe. But the point I had in mind is, say for example
> memory diagnostics applications/exercisers which reads (Blind
> reads, without caring about contents) memory
> to uncover errors (single bit errors) can use
> this to know the usable ranges and map them thru /dev/mem and
> read those ranges.

If you expose the EFI memory map, then you'll be able to write memory
diagnostics that will work on any EFI-based machine.

If you expose the EFI memory map in an architecture-independent fashion,
then you'll be able to write diagnostics that will work on any *Linux*
machine, plus all of the EFI machines.  Plus, by doing it first, you get
to greatly influence how the arch-independent stuff is done to make your
life the easiest.  

Think /sys/system/devices/memory, not /sys/firmware/efi.

We're planning on doing this anyway for memory hotplug, so some of the
work and ideas are already there.  I'd be happy to point you to some
past discussions and code on the subject.  

-- Dave

RE: [2.6.6 PATCH] Exposing EFI memory map

[Sourav Sen]

+ We're planning on doing this anyway for memory hotplug, so some of the
+ work and ideas are already there.  I'd be happy to point you to some
+ past discussions and code on the subject.  

	Yes, please.

Thanks
Sourav

RE: [2.6.6 PATCH] Exposing EFI memory map

[Sourav Sen]

+ We're planning on doing this anyway for memory hotplug, so some of the
+ work and ideas are already there.  I'd be happy to point you to some
+ past discussions and code on the subject.  

	Yes, please.

Thanks
Sourav

RE: [2.6.6 PATCH] Exposing EFI memory map

[Dave Hansen]

On Thu, 2004-05-13 at 07:10, Sourav Sen wrote:
> + We're planning on doing this anyway for memory hotplug, so some of the
> + work and ideas are already there.  I'd be happy to point you to some
> + past discussions and code on the subject.  

Here was my sample implementation of how to export memory areas:

http://sourceforge.net/mailarchive/forum.php?thread_idA20609&forum_id"3

There was at least one other way to do the same thing on the lhms-devel
list.  I believe it was some time last month.

-- Dave

RE: [2.6.6 PATCH] Exposing EFI memory map

[Dave Hansen]

On Thu, 2004-05-13 at 07:10, Sourav Sen wrote:
> + We're planning on doing this anyway for memory hotplug, so some of the
> + work and ideas are already there.  I'd be happy to point you to some
> + past discussions and code on the subject.  

Here was my sample implementation of how to export memory areas:

http://sourceforge.net/mailarchive/forum.php?thread_id=4120609&forum_id=223

There was at least one other way to do the same thing on the lhms-devel
list.  I believe it was some time last month.

-- Dave

RE: [2.6.6 PATCH] Exposing EFI memory map

[Tolentino, Matthew E]

> On Thu, 2004-05-06 at 09:25, Sourav Sen wrote:
> > From: Bjorn Helgaas [mailto:bjorn.helgaas@hp.com]
> > + For this application, the EFI memory map isn't what you want.
> > + It's a pretty good approximation today, but the day when we'll
> > + be able to hot-add memory is fast approaching, and the EFI map
> > + won't mention anything added after boot.  We'll discover all
> > + that via ACPI (on ia64).
> >
> > 	Why not also update the efi memory table on a hotplug :-)
> 
> That's actually what ppc64 does.  But, they do it via /proc (not even
> from inside the kernel).  I'm not very fond of that solution :)

Interesting. What does ppc64 do with the memmap after that?  

> >  and there may be some truncation (just as efi_memmap_walk()
> > does today). And it isn't help us if we get to know about those
> > extents. Additionally we get to know about various mmio ranges and
> > other ranges thru that table -- may be useful opportunistically.
> 
> There can be some pretty generic (although asynchronous) events given
> via /sbin/hotplug.  I'm currently planning on having the 
> memory hotplug
> "drivers" get the hot-added memory ready, but keep it 
> offline.  It then
> creates some kobjects, which generate hotplug events, and *then* the
> decision can be made in the hotplug scripts about what to do with it.

So, allocate the page structs which constitute the new memmap, set up
the nonlinear sections, and then wait for hotplug events in order to 
clear the appropriate bits in the pages for a given range?  Is that 
what you're thinking?

matt

RE: [2.6.6 PATCH] Exposing EFI memory map

[Tolentino, Matthew E]

> On Thu, 2004-05-06 at 09:25, Sourav Sen wrote:
> > From: Bjorn Helgaas [mailto:bjorn.helgaas@hp.com]
> > + For this application, the EFI memory map isn't what you want.
> > + It's a pretty good approximation today, but the day when we'll
> > + be able to hot-add memory is fast approaching, and the EFI map
> > + won't mention anything added after boot.  We'll discover all
> > + that via ACPI (on ia64).
> >
> > 	Why not also update the efi memory table on a hotplug :-)
> 
> That's actually what ppc64 does.  But, they do it via /proc (not even
> from inside the kernel).  I'm not very fond of that solution :)

Interesting. What does ppc64 do with the memmap after that?  

> >  and there may be some truncation (just as efi_memmap_walk()
> > does today). And it isn't help us if we get to know about those
> > extents. Additionally we get to know about various mmio ranges and
> > other ranges thru that table -- may be useful opportunistically.
> 
> There can be some pretty generic (although asynchronous) events given
> via /sbin/hotplug.  I'm currently planning on having the 
> memory hotplug
> "drivers" get the hot-added memory ready, but keep it 
> offline.  It then
> creates some kobjects, which generate hotplug events, and *then* the
> decision can be made in the hotplug scripts about what to do with it.

So, allocate the page structs which constitute the new memmap, set up
the nonlinear sections, and then wait for hotplug events in order to 
clear the appropriate bits in the pages for a given range?  Is that 
what you're thinking?

matt

RE: [2.6.6 PATCH] Exposing EFI memory map

[Dave Hansen]

cc'ing lhms list as well, as this has diverged a bit...

On Thu, 2004-05-06 at 11:47, Tolentino, Matthew E wrote:
> > On Thu, 2004-05-06 at 09:25, Sourav Sen wrote:
> > > From: Bjorn Helgaas [mailto:bjorn.helgaas@hp.com]
> > > 	Why not also update the efi memory table on a hotplug :-)
> > 
> > That's actually what ppc64 does.  But, they do it via /proc (not even
> > from inside the kernel).  I'm not very fond of that solution :)
> 
> Interesting. What does ppc64 do with the memmap after that?  

This doesn't even concern mem_map yet.  The userspace ppc64 hotplug
tools actually write into the "OpenFirmware" tree from userspace, after
a hotplug happens.  This is partly because all of the ppc64 hotplug
operations happen in userspace as it stands now.  

> So, allocate the page structs which constitute the new memmap, set up
> the nonlinear sections, and then wait for hotplug events in order to 
> clear the appropriate bits in the pages for a given range?  Is that 
> what you're thinking?

Actually, I was thinking that we'd just allocate the kobjects, and note
the presence of the memory in the nonlinear phys_section table.  Then,
when we online it, we can decide where it's mapped, what zone to put it
in, and where to get the mem_map space from.  I think that approach
gives the best flexibility. 

-- Dave

RE: [2.6.6 PATCH] Exposing EFI memory map

[Dave Hansen]

cc'ing lhms list as well, as this has diverged a bit...

On Thu, 2004-05-06 at 11:47, Tolentino, Matthew E wrote:
> > On Thu, 2004-05-06 at 09:25, Sourav Sen wrote:
> > > From: Bjorn Helgaas [mailto:bjorn.helgaas@hp.com]
> > > 	Why not also update the efi memory table on a hotplug :-)
> > 
> > That's actually what ppc64 does.  But, they do it via /proc (not even
> > from inside the kernel).  I'm not very fond of that solution :)
> 
> Interesting. What does ppc64 do with the memmap after that?  

This doesn't even concern mem_map yet.  The userspace ppc64 hotplug
tools actually write into the "OpenFirmware" tree from userspace, after
a hotplug happens.  This is partly because all of the ppc64 hotplug
operations happen in userspace as it stands now.  

> So, allocate the page structs which constitute the new memmap, set up
> the nonlinear sections, and then wait for hotplug events in order to 
> clear the appropriate bits in the pages for a given range?  Is that 
> what you're thinking?

Actually, I was thinking that we'd just allocate the kobjects, and note
the presence of the memory in the nonlinear phys_section table.  Then,
when we online it, we can decide where it's mapped, what zone to put it
in, and where to get the mem_map space from.  I think that approach
gives the best flexibility. 

-- Dave

RE: [2.6.6 PATCH] Exposing EFI memory map

[Tolentino, Matthew E]

> > Interesting. What does ppc64 do with the memmap after that?  
> 
> This doesn't even concern mem_map yet.  The userspace ppc64 hotplug
> tools actually write into the "OpenFirmware" tree from 
> userspace, after
> a hotplug happens.  This is partly because all of the ppc64 hotplug
> operations happen in userspace as it stands now.  

Umm..  my mistake, I meant the memory map passed up by the firmware,
not THE mem_map.  ;-)

> Actually, I was thinking that we'd just allocate the 
> kobjects, and note
> the presence of the memory in the nonlinear phys_section table.  Then,
> when we online it, we can decide where it's mapped, what zone 
> to put it
> in, and where to get the mem_map space from.  I think that approach
> gives the best flexibility. 

Yes, indeed. 

matt

RE: [2.6.6 PATCH] Exposing EFI memory map

[Tolentino, Matthew E]

> > Interesting. What does ppc64 do with the memmap after that?  
> 
> This doesn't even concern mem_map yet.  The userspace ppc64 hotplug
> tools actually write into the "OpenFirmware" tree from 
> userspace, after
> a hotplug happens.  This is partly because all of the ppc64 hotplug
> operations happen in userspace as it stands now.  

Umm..  my mistake, I meant the memory map passed up by the firmware,
not THE mem_map.  ;-)

> Actually, I was thinking that we'd just allocate the 
> kobjects, and note
> the presence of the memory in the nonlinear phys_section table.  Then,
> when we online it, we can decide where it's mapped, what zone 
> to put it
> in, and where to get the mem_map space from.  I think that approach
> gives the best flexibility. 

Yes, indeed. 

matt

Re: [Lhms-devel] RE: [2.6.6 PATCH] Exposing EFI memory map

[Dave Hansen]

On Thu, 2004-05-06 at 13:54, Tolentino, Matthew E wrote:
> > > Interesting. What does ppc64 do with the memmap after that?  
> > 
> > This doesn't even concern mem_map yet.  The userspace ppc64 hotplug
> > tools actually write into the "OpenFirmware" tree from 
> > userspace, after
> > a hotplug happens.  This is partly because all of the ppc64 hotplug
> > operations happen in userspace as it stands now.  
> 
> Umm..  my mistake, I meant the memory map passed up by the firmware,
> not THE mem_map.  ;-)

Sorry for the ppc64 tangent, ia64 list people... :)

I'm not quite sure what's it's used for.  I *think* there's a node in
each of the fake OpenFirmware tree directories that exports a magic
resource tag that can identify the memory when it's handed back to the
hypervisor. 

We need this number exported to userspace, because we basically make the
hypervisor calls from there.  It's safe to say that I'd prefer this
method be revised at some point in the future.  

-- Dave

Re: [Lhms-devel] RE: [2.6.6 PATCH] Exposing EFI memory map

[Dave Hansen]

On Thu, 2004-05-06 at 13:54, Tolentino, Matthew E wrote:
> > > Interesting. What does ppc64 do with the memmap after that?  
> > 
> > This doesn't even concern mem_map yet.  The userspace ppc64 hotplug
> > tools actually write into the "OpenFirmware" tree from 
> > userspace, after
> > a hotplug happens.  This is partly because all of the ppc64 hotplug
> > operations happen in userspace as it stands now.  
> 
> Umm..  my mistake, I meant the memory map passed up by the firmware,
> not THE mem_map.  ;-)

Sorry for the ppc64 tangent, ia64 list people... :)

I'm not quite sure what's it's used for.  I *think* there's a node in
each of the fake OpenFirmware tree directories that exports a magic
resource tag that can identify the memory when it's handed back to the
hypervisor. 

We need this number exported to userspace, because we basically make the
hypervisor calls from there.  It's safe to say that I'd prefer this
method be revised at some point in the future.  

-- Dave

[2.6.6 PATCH] Exposing EFI memory map

[Sourav Sen]

Resending it as the last one line wrapped :-(

----------------------------------------------------
Hi,

The following simple patch creates a read-only file 
"memmap" under <mount point>/firmware/efi/ in sysfs 
and exposes the efi memory map thru it.
 
Thanks
Sourav
HP-STS, Bangalore

The patch is w.r.t 2.6.6-rc3
----------------------------
===========================================================================
--- a/drivers/firmware/efivars.c        2004-05-05 13:55:40.000000000 +0530
+++ b/drivers/firmware/efivars.c        2004-05-06 14:03:13.000000000 +0530
@@ -580,10 +580,42 @@ systab_read(struct subsystem *entry, cha
        return str - buf;
 }

+/*
+ * Expose the efi memory map as kernel keeps it. Note, it may be a little
+ * different from what gets actually passed in at loader handoff time as a
+ * call to efi_memmap_walk modifies that.
+ */
+
+static ssize_t
+efi_memmap_read(struct subsystem *entry, char * buf)
+{
+       void * efi_map_start, *efi_map_end, *p;
+       efi_memory_desc_t *md;
+       u64 efi_desc_size;
+       char * str = buf;
+
+       if (!entry || !buf)
+               return -EINVAL;
+
+       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;
+
+       for (p = efi_map_start; p < efi_map_end; p += efi_desc_size) {
+               md = (efi_memory_desc_t *)p;
+               str += sprintf(str, "%2u  %-#18lx  %#016lx %#016lx\n", \
+                       md->type, md->attribute, md->phys_addr, \
+                       md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT));
+       }
+       return (str - buf);
+}
+
 static EFI_ATTR(systab, 0400, systab_read, NULL);
+static EFI_ATTR(memmap, 0400, efi_memmap_read, NULL);

 static struct subsys_attribute *efi_subsys_attrs[] = {
        &efi_attr_systab,
+       &efi_attr_memmap,       /* Here comes one */
        NULL,   /* maybe more in the future? */
 }; 

[2.6.6 PATCH] Exposing EFI memory map

[Sourav Sen]

Resending it as the last one line wrapped :-(

----------------------------------------------------
Hi,

The following simple patch creates a read-only file 
"memmap" under <mount point>/firmware/efi/ in sysfs 
and exposes the efi memory map thru it.
 
Thanks
Sourav
HP-STS, Bangalore

The patch is w.r.t 2.6.6-rc3
----------------------------
=====================================--- a/drivers/firmware/efivars.c        2004-05-05 13:55:40.000000000 +0530
+++ b/drivers/firmware/efivars.c        2004-05-06 14:03:13.000000000 +0530
@@ -580,10 +580,42 @@ systab_read(struct subsystem *entry, cha
        return str - buf;
 }

+/*
+ * Expose the efi memory map as kernel keeps it. Note, it may be a little
+ * different from what gets actually passed in at loader handoff time as a
+ * call to efi_memmap_walk modifies that.
+ */
+
+static ssize_t
+efi_memmap_read(struct subsystem *entry, char * buf)
+{
+       void * efi_map_start, *efi_map_end, *p;
+       efi_memory_desc_t *md;
+       u64 efi_desc_size;
+       char * str = buf;
+
+       if (!entry || !buf)
+               return -EINVAL;
+
+       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;
+
+       for (p = efi_map_start; p < efi_map_end; p += efi_desc_size) {
+               md = (efi_memory_desc_t *)p;
+               str += sprintf(str, "%2u  %-#18lx  %#016lx %#016lx\n", \
+                       md->type, md->attribute, md->phys_addr, \
+                       md->phys_addr + (md->num_pages << EFI_PAGE_SHIFT));
+       }
+       return (str - buf);
+}
+
 static EFI_ATTR(systab, 0400, systab_read, NULL);
+static EFI_ATTR(memmap, 0400, efi_memmap_read, NULL);

 static struct subsys_attribute *efi_subsys_attrs[] = {
        &efi_attr_systab,
+       &efi_attr_memmap,       /* Here comes one */
        NULL,   /* maybe more in the future? */
 };