x86 boot : export boot_params via sysfs

PATCH In review Huang, Ying 5 participants 10 messages Dec 12, 2007

Subsystems (3)

x86 Live update kexec handover (KHO)

lore

Share & tools

lore

Huang, Ying

author

2007-12-12 09:00 UTC #0 lore raw

PATCH 1/1 x86 boot : export boot_params via sysfs

This patch export the boot parameters via sysfs. This can be used for debugging and kexec.

The files added are as follow:

/sys/kernel/boot_params/data : binary file for struct boot_params
/sys/kernel/boot_params/version : boot protocol version

This patch is based on 2.6.24-rc4-mm1 and has been tested on i386 and x86_64 platoform.

This patch is based on the Peter Anvin's proposal.

v2:

- Add document in Document/ABI.

Signed-off-by Huang Ying <[email protected]>

---
 Documentation/ABI/testing/sysfs-kernel-boot_params |   14 +++
 arch/x86/kernel/Makefile_32                        |    1 
 arch/x86/kernel/Makefile_64                        |    1 
 arch/x86/kernel/ksysfs.c                           |   89 +++++++++++++++++++++
 arch/x86/kernel/setup64.c                          |    2 
 arch/x86/kernel/setup_32.c                         |    2 
 6 files changed, 107 insertions(+), 2 deletions(-)

arch/x86/kernel/Makefile_64 +1 -0

@@ -39,6 +39,7 @@ obj-$(CONFIG_X86_VSMP)		+= vsmp_64.o
 obj-$(CONFIG_K8_NB)		+= k8.o
 obj-$(CONFIG_AUDIT)		+= audit_64.o
 obj-$(CONFIG_EFI)		+= efi.o efi_64.o efi_stub_64.o
+obj-$(CONFIG_SYSFS)		+= ksysfs.o
 
 obj-$(CONFIG_MODULES)		+= module_64.o
 obj-$(CONFIG_PCI)		+= early-quirks.o

arch/x86/kernel/setup64.c +1 -1

@@ -24,7 +24,7 @@
 #include <asm/sections.h>
 #include <asm/setup.h>
 
-struct boot_params __initdata boot_params;
+struct boot_params boot_params;
 
 cpumask_t cpu_initialized __cpuinitdata = CPU_MASK_NONE;

arch/x86/kernel/ksysfs.c new file +89 -0

89 lines not on this page · raw message

arch/x86/kernel/Makefile_32 +1 -0

@@ -44,6 +44,7 @@ obj-$(CONFIG_EARLY_PRINTK)	+= early_prin
 obj-$(CONFIG_HPET_TIMER) 	+= hpet.o
 obj-$(CONFIG_K8_NB)		+= k8.o
 obj-$(CONFIG_MGEODE_LX)		+= geode_32.o mfgpt_32.o
+obj-$(CONFIG_SYSFS)		+= ksysfs.o
 
 obj-$(CONFIG_VMI)		+= vmi_32.o vmiclock_32.o
 obj-$(CONFIG_PARAVIRT)		+= paravirt_32.o

arch/x86/kernel/setup_32.c +1 -1

@@ -194,7 +194,7 @@ unsigned long saved_videomode;
 
 static char __initdata command_line[COMMAND_LINE_SIZE];
 
-struct boot_params __initdata boot_params;
+struct boot_params boot_params;
 
 #if defined(CONFIG_EDD) || defined(CONFIG_EDD_MODULE)
 struct edd edd;

Documentation/ABI/testing/sysfs-kernel-boot_params new file +14 -0

@@ -0,0 +1,14 @@
+What:		/sys/kernel/boot_params
+Date:		December 2007
+Contact:	Huang Ying <[email protected]>
+Description:
+		The /sys/kernel/boot_params directory contains two
+		files: "data" and "version". It is used to export the
+		kernel boot parameters of x86 platform to user space
+		for debugging and kexec. The "data" file is the binary
+		representation of struct boot_params. The "version"
+		file is the string representation of boot protocol
+		version.
+
+Users:
+		Kexec Mailing List <[email protected]>

Greg KH

2007-12-12 17:47 UTC #1 lore raw

Quoted 5 lines · Ying

This patch export the boot parameters via sysfs. This can be used for debugging and kexec.
The files added are as follow:

Quoted 7 lines

/sys/kernel/boot_params/data : binary file for struct boot_params
/sys/kernel/boot_params/version : boot protocol version
This patch is based on 2.6.24-rc4-mm1 and has been tested on i386 and x86_64 platoform.
This patch is based on the Peter Anvin's proposal.

As outlined in a previous email, I object to the whole structure being exported to userspace as a binary blob. Please change that.

thanks,

greg k-h

H. Peter Anvin

reviewer

2007-12-12 18:09 UTC #2 lore raw

Quoted 9 lines · Greg KH

Quoted 8 lines · Ying
This patch export the boot parameters via sysfs. This can be used for debugging and kexec.
The files added are as follow:
/sys/kernel/boot_params/data : binary file for struct boot_params
/sys/kernel/boot_params/version : boot protocol version

Quoted 8 lines

Quoted 4 lines
This patch is based on 2.6.24-rc4-mm1 and has been tested on i386 and x86_64 platoform.
This patch is based on the Peter Anvin's proposal.
As outlined in a previous email, I object to the whole structure being exported to userspace as a binary blob. Please change that.

I would prefer to have the binary blob available; exported fields is possible too, of course.

This is a binary structure defined by protocol; in that way it's not significantly different from something passed from the firmware (in fact, it might very well *be* passed from the firmware.) We have in the past found platform bugs by looking at the contents of the whole structure, e.g. to find that part of it has been inappropriately clobbered.

It is also in the form needed by e.g. kexec to operate.

-hpa

Greg KH

2007-12-12 19:01 UTC #3 lore raw

Quoted 13 lines · H. Peter Anvin

Quoted 12 lines · Greg KH
Quoted 11 lines · Ying
This patch export the boot parameters via sysfs. This can be used for debugging and kexec.
The files added are as follow:
/sys/kernel/boot_params/data : binary file for struct boot_params
/sys/kernel/boot_params/version : boot protocol version
This patch is based on 2.6.24-rc4-mm1 and has been tested on i386 and x86_64 platoform.

Quoted 8 lines

Quoted 3 lines
Quoted 1 line
This patch is based on the Peter Anvin's proposal.
As outlined in a previous email, I object to the whole structure being exported to userspace as a binary blob. Please change that.
I would prefer to have the binary blob available; exported fields is possible too, of course.
This is a binary structure defined by protocol;

What protocol? Is this a "standard" documented somewhere?

Quoted 5 lines

in that way it's not significantly different from something passed from the firmware (in fact, it might very well *be* passed from the firmware.) We have in the past found platform bugs by looking at the contents of the whole structure, e.g. to find that part of it has been inappropriately clobbered.

For debugging things, then just export it through debugfs.

Quoted 1 line

It is also in the form needed by e.g. kexec to operate.

Does kexec need this today to work properly? Or is this something new?

What userspace program is going to know the exact data format of this blob, and where is it going to know that format from? The kernel header files in sanitized form? Or something else?

thanks,

greg k-h

H. Peter Anvin

reviewer

2007-12-12 19:07 UTC #4 lore raw

Quoted 3 lines · Greg KH

Quoted 1 line
This is a binary structure defined by protocol;
What protocol? Is this a "standard" documented somewhere?

Yes, see Documentation/i386/* (although some of it is documented by reference to include/asm-x86/boot_params.h).

Quoted 7 lines

Quoted 5 lines
in that way it's not significantly different from something passed from the firmware (in fact, it might very well *be* passed from the firmware.) We have in the past found platform bugs by looking at the contents of the whole structure, e.g. to find that part of it has been inappropriately clobbered.
For debugging things, then just export it through debugfs.

Fair enough, however...

Quoted 3 lines

Quoted 1 line
It is also in the form needed by e.g. kexec to operate.
Does kexec need this today to work properly? Or is this something new?

I believe kexec currently tries to reconstitute it from what data is available to it. This is incomplete, though, and has been flagged as a problem for kexec.

Quoted 3 lines

What userspace program is going to know the exact data format of this blob, and where is it going to know that format from? The kernel header files in sanitized form? Or something else?

It can pick it up from <asm/boot_params.h> (which is now userspace-safe); or it can decode it itself. Programs like kexec can pass through most of the data without examining it, this is the main reason for having it as a blob.

-hpa

Greg KH

2007-12-12 22:31 UTC #5 lore raw

Quoted 6 lines · H. Peter Anvin

Quoted 2 lines · Greg KH
Quoted 1 line
This is a binary structure defined by protocol;
What protocol? Is this a "standard" documented somewhere?
Yes, see Documentation/i386/* (although some of it is documented by reference to include/asm-x86/boot_params.h).

Ah, so the structure has changed over the years, making this not so much a "firmware" field as originally thought :)

Quoted 7 lines

Quoted 6 lines
Quoted 5 lines
in that way it's not significantly different from something passed from the firmware (in fact, it might very well *be* passed from the firmware.) We have in the past found platform bugs by looking at the contents of the whole structure, e.g. to find that part of it has been inappropriately clobbered.
For debugging things, then just export it through debugfs.

Quoted 8 lines

Fair enough, however...
Quoted 2 lines
Quoted 1 line
It is also in the form needed by e.g. kexec to operate.
Does kexec need this today to work properly? Or is this something new?
I believe kexec currently tries to reconstitute it from what data is available to it. This is incomplete, though, and has been flagged as a problem for kexec.

Can't kexec get this from within the kernel itself when it is running? It doesn't need to get this from userspace, does it?

Quoted 8 lines

Quoted 3 lines
What userspace program is going to know the exact data format of this blob, and where is it going to know that format from? The kernel header files in sanitized form? Or something else?
It can pick it up from <asm/boot_params.h> (which is now userspace-safe); or it can decode it itself. Programs like kexec can pass through most of the data without examining it, this is the main reason for having it as a blob.

I just don't want kernel structures exported in binary fashions in sysfs. If there are specific portions that kexec currently can't figure out, why not just export those fields?

And, by exporting the different fields (yeah, lots of files, no big deal), you can handle the change in the structure over time much easier than trying to "know" the layout of the binary blob.

thanks,

greg k-h

H. Peter Anvin

reviewer

2007-12-12 22:38 UTC #6 lore raw

Quoted 8 lines · Greg KH

Quoted 4 lines · H. Peter Anvin
Quoted 2 lines · Greg KH
Quoted 1 line
This is a binary structure defined by protocol;
What protocol? Is this a "standard" documented somewhere?
Yes, see Documentation/i386/* (although some of it is documented by reference to include/asm-x86/boot_params.h).
Ah, so the structure has changed over the years, making this not so much a "firmware" field as originally thought :)

The structure has been *amended* to over the years. That's why the format is so awkward...

Quoted 6 lines

Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
in that way it's not significantly different from something passed from the firmware (in fact, it might very well *be* passed from the firmware.) We have in the past found platform bugs by looking at the contents of the whole structure, e.g. to find that part of it has been inappropriately clobbered.
For debugging things, then just export it through debugfs.

Quoted 8 lines

Quoted 5 lines
Fair enough, however...
Quoted 2 lines
Quoted 1 line
It is also in the form needed by e.g. kexec to operate.
Does kexec need this today to work properly? Or is this something new?
I believe kexec currently tries to reconstitute it from what data is available to it. This is incomplete, though, and has been flagged as a problem for kexec.
Can't kexec get this from within the kernel itself when it is running? It doesn't need to get this from userspace, does it?

It probably could, but it probably needs to modify some fields.

Quoted 5 lines

Quoted 4 lines
Quoted 3 lines
What userspace program is going to know the exact data format of this blob, and where is it going to know that format from? The kernel header files in sanitized form? Or something else?
It can pick it up from <asm/boot_params.h> (which is now userspace-safe); or it can decode it itself. Programs like kexec can pass through most of the data without examining it, this is the main reason for having it as a blob.

Quoted 7 lines

I just don't want kernel structures exported in binary fashions in sysfs. If there are specific portions that kexec currently can't figure out, why not just export those fields?
And, by exporting the different fields (yeah, lots of files, no big deal), you can handle the change in the structure over time much easier than trying to "know" the layout of the binary blob.

But if you kexec an older kernel from a newer kernel, the potential additional information will be lost for a subsequent uprevision kexec, for example.

-hpa

Randy Dunlap

2007-12-12 22:45 UTC #7 lore raw

In reply to Greg KH

Quoted 21 lines · On Wed, 12 Dec 2007 14:21:46 -0800 Greg KH wrote:

Quoted 6 lines · H. Peter Anvin
Quoted 2 lines · Greg KH
Quoted 1 line
This is a binary structure defined by protocol;
What protocol? Is this a "standard" documented somewhere?
Yes, see Documentation/i386/* (although some of it is documented by reference to include/asm-x86/boot_params.h).
Ah, so the structure has changed over the years, making this not so much a "firmware" field as originally thought :)
Quoted 10 lines
Quoted 6 lines
Quoted 5 lines
in that way it's not significantly different from something passed from the firmware (in fact, it might very well *be* passed from the firmware.) We have in the past found platform bugs by looking at the contents of the whole structure, e.g. to find that part of it has been inappropriately clobbered.
For debugging things, then just export it through debugfs.
Fair enough, however...
Quoted 1 line
Quoted 1 line
It is also in the form needed by e.g. kexec to operate.

Quoted 8 lines

Quoted 5 lines
Quoted 1 line
Does kexec need this today to work properly? Or is this something new?
I believe kexec currently tries to reconstitute it from what data is available to it. This is incomplete, though, and has been flagged as a problem for kexec.
Can't kexec get this from within the kernel itself when it is running? It doesn't need to get this from userspace, does it?

I don't know if this patch is trying to solve this (->) problem, but there is a desire for drivers to have a decent way to tell if the kernel that is executing is a kexec/crash kernel or not. If it is a kexec/crash kernel, then (some) drivers may not allocate as many buffers as they normally do, since the kernel would likely be configured to use less memory. The solution doesn't have to involve sysfs .. or it could.

Quoted 9 lines

Quoted 8 lines
Quoted 3 lines
What userspace program is going to know the exact data format of this blob, and where is it going to know that format from? The kernel header files in sanitized form? Or something else?
It can pick it up from <asm/boot_params.h> (which is now userspace-safe); or it can decode it itself. Programs like kexec can pass through most of the data without examining it, this is the main reason for having it as a blob.

Quoted 7 lines

I just don't want kernel structures exported in binary fashions in sysfs. If there are specific portions that kexec currently can't figure out, why not just export those fields?
And, by exporting the different fields (yeah, lots of files, no big deal), you can handle the change in the structure over time much easier than trying to "know" the layout of the binary blob.

---
~Randy

Eric W. Biederman

2007-12-12 23:11 UTC #8 lore raw

Quoted 6 lines · Randy Dunlap

I don't know if this patch is trying to solve this (->) problem, but there is a desire for drivers to have a decent way to tell if the kernel that is executing is a kexec/crash kernel or not. If it is a kexec/crash kernel, then (some) drivers may not allocate as many buffers as they normally do, since the kernel would likely be configured to use less memory. The solution doesn't have to involve sysfs .. or it could.

The patch is trying to make it easier to observe new fields passed to the kernel by the bootloader in user space.

The drivers should have a way to look at the amount of memory the kernel is configured to use and operate on that. I expect this is a general embedded scenario.

I don't think I have seen a driver concern in the kdump environment that is unique to that environment. So in general I figure we should use whatever it is that is different about the kdump environment that the causes the drivers to want to do something differently, so the changes can ideally support more people.

Eric

Eric W. Biederman

2007-12-12 22:54 UTC #9 lore raw

In reply to Greg KH

Quoted 10 lines · Greg KH

Quoted 6 lines · H. Peter Anvin
Quoted 2 lines · Greg KH
Quoted 1 line
This is a binary structure defined by protocol;
What protocol? Is this a "standard" documented somewhere?
Yes, see Documentation/i386/* (although some of it is documented by reference to include/asm-x86/boot_params.h).
Ah, so the structure has changed over the years, making this not so much a "firmware" field as originally thought :)

The structure has grown and fields have been added in a backwards compatible way. It is very much an ABI from the bootloader to the kernel.

Quoted 6 lines

Quoted 3 lines
I believe kexec currently tries to reconstitute it from what data is available to it. This is incomplete, though, and has been flagged as a problem for kexec.
Can't kexec get this from within the kernel itself when it is running? It doesn't need to get this from userspace, does it?

/proc/kmem? All of this work happens in user space. The kexec syscall interface is just load these chunks of data at this these addresses and finally jump to this address.

All of the interesting kexec work happens in user space, and it needs to stay that way. Otherwise we loose the flexibility and simplicity on the kernel side.

Quoted 8 lines

Quoted 4 lines
It can pick it up from <asm/boot_params.h> (which is now userspace-safe); or it can decode it itself. Programs like kexec can pass through most of the data without examining it, this is the main reason for having it as a blob.
I just don't want kernel structures exported in binary fashions in sysfs. If there are specific portions that kexec currently can't figure out, why not just export those fields?

So all of the fields are binary.
The entire structure is binary.
The native format is binary.

So either we need to export the processed and chewed up version of the information like we do today in /proc/iomem. Or we need to export the raw binary format.

Quoted 3 lines

And, by exporting the different fields (yeah, lots of files, no big deal), you can handle the change in the structure over time much easier than trying to "know" the layout of the binary blob.

Well /sbin/kexec fundamentally has to "know" the layout of that binary blob because it generates it and hands it to the kernel.

Greg I think I am with you on this one. If something other then /sbin/kexec is going to use that information we need to split it by field, although I expect the fields to remain binary. Things like the e820 memory map and most of the other fields are binary structures defined to be returned by the firmware so at that level we have extremely well defined binary blobs, that may possibly be used for other things.

/sbin/kexec needs to retain the ability to parse and understand the information because frequently it needs to change little things like the memory map and the command line and possibly other things so it can't blindly pass this information through.

Eric

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec