Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1292598 > unrolled thread

[RFC v1 5/8] x86/init: move ebda reservations into linker table

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [RFC v1 5/8] x86/init: move ebda reservations into linker table "Luis R. Rodriguez" <mcgrof@do-not-panic.com> - 2015-12-15 23:20 +0100
    Re: [RFC v1 5/8] x86/init: move ebda reservations into linker table Andy Lutomirski <luto@amacapital.net> - 2015-12-17 21:50 +0100
      Re: [RFC v1 5/8] x86/init: move ebda reservations into linker table Andy Lutomirski <luto@amacapital.net> - 2015-12-17 22:00 +0100
        Re: [RFC v1 5/8] x86/init: move ebda reservations into linker table "Luis R. Rodriguez" <mcgrof@suse.com> - 2015-12-18 00:50 +0100
      Re: [RFC v1 5/8] x86/init: move ebda reservations into linker table "H. Peter Anvin" <hpa@zytor.com> - 2015-12-17 22:00 +0100

#1292598 — [RFC v1 5/8] x86/init: move ebda reservations into linker table

From: "Luis R. Rodriguez" <mcgrof@suse.com>

This lets us annotate its requirements specifically for
PC and lguest subarchitectures. While at it since head.c
just has ebda data rename it. Since we're using linker tables
and both x86 32-bit and 64-bit have them we don't need
to declare a call for this separately. This lets us
also keep this declared static now.

Since we're using linker tables and have support to annotate
subarchitecture do that instead. pv_legacy() is incorrect as
its really only for legacy PV guests. There's no need for
pv_legacy() check anymore now.

Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
---
 arch/x86/include/asm/bios_ebda.h   | 2 --
 arch/x86/kernel/Makefile           | 2 +-
 arch/x86/kernel/{head.c => ebda.c} | 6 +++---
 arch/x86/kernel/head32.c           | 2 --
 arch/x86/kernel/head64.c           | 2 --
 5 files changed, 4 insertions(+), 10 deletions(-)
 rename arch/x86/kernel/{head.c => ebda.c} (94%)

diff --git a/arch/x86/include/asm/bios_ebda.h b/arch/x86/include/asm/bios_ebda.h
index aa6a3170ab5a..e63347eb3804 100644
--- a/arch/x86/include/asm/bios_ebda.h
+++ b/arch/x86/include/asm/bios_ebda.h
@@ -38,8 +38,6 @@ static inline unsigned int get_bios_ebda_length(void)
 	return length;
 }
 
-void reserve_ebda_region(void);
-
 #ifdef CONFIG_X86_CHECK_BIOS_CORRUPTION
 /*
  * This is obviously not a great place for this, but we want to be
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index be167a0a5e2c..e7a43f08bccc 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -2,7 +2,7 @@
 # Makefile for the linux kernel.
 #
 
-extra-y                := head_$(BITS).o head$(BITS).o head.o vmlinux.lds
+extra-y                := head_$(BITS).o head$(BITS).o ebda.o vmlinux.lds
 
 CPPFLAGS_vmlinux.lds += -U$(UTS_MACHINE)
 
diff --git a/arch/x86/kernel/head.c b/arch/x86/kernel/ebda.c
similarity index 94%
rename from arch/x86/kernel/head.c
rename to arch/x86/kernel/ebda.c
index 279fad7288f8..defc2f07a80b 100644
--- a/arch/x86/kernel/head.c
+++ b/arch/x86/kernel/ebda.c
@@ -4,6 +4,7 @@
 
 #include <asm/setup.h>
 #include <asm/bios_ebda.h>
+#include <asm/x86_init.h>
 
 /*
  * The BIOS places the EBDA/XBDA at the top of conventional
@@ -26,7 +27,7 @@
 #define LOWMEM_CAP		0x9f000U	/* Absolute maximum */
 #define INSANE_CUTOFF		0x20000U	/* Less than this = insane */
 
-void __init reserve_ebda_region(void)
+static void __init reserve_ebda_region(void)
 {
 	unsigned int lowmem, ebda_addr;
 
@@ -38,8 +39,6 @@ void __init reserve_ebda_region(void)
 	 * that the paravirt case can handle memory setup
 	 * correctly, without our help.
 	 */
-	if (paravirt_legacy())
-		return;
 
 	/* end of low (conventional) memory */
 	lowmem = *(unsigned short *)__va(BIOS_LOWMEM_KILOBYTES);
@@ -69,3 +68,4 @@ void __init reserve_ebda_region(void)
 	/* reserve all memory between lowmem and the 1MB mark */
 	memblock_reserve(lowmem, 0x100000 - lowmem);
 }
+x86_init_early_pc_simple(reserve_ebda_region);
diff --git a/arch/x86/kernel/head32.c b/arch/x86/kernel/head32.c
index d93f3e42e61b..768fa3888066 100644
--- a/arch/x86/kernel/head32.c
+++ b/arch/x86/kernel/head32.c
@@ -26,8 +26,6 @@ static void __init i386_default_early_setup(void)
 	/* Initialize 32bit specific setup functions */
 	x86_init.resources.reserve_resources = i386_reserve_resources;
 	x86_init.mpparse.setup_ioapic_ids = setup_ioapic_ids_from_mpc;
-
-	reserve_ebda_region();
 }
 
 asmlinkage __visible void __init i386_start_kernel(void)
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index f83263a8d0ed..c913b7eb5056 100644
--- a/arch/x86/kernel/head64.c
+++ b/arch/x86/kernel/head64.c
@@ -194,7 +194,5 @@ void __init x86_64_start_reservations(char *real_mode_data)
 	x86_init_fn_init_tables();
 	x86_init_fn_early_init();
 
-	reserve_ebda_region();
-
 	start_kernel();
 }
-- 
2.6.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1294260

On Tue, Dec 15, 2015 at 2:16 PM, Luis R. Rodriguez
<mcgrof@do-not-panic.com> wrote:
> From: "Luis R. Rodriguez" <mcgrof@suse.com>
>
> This lets us annotate its requirements specifically for
> PC and lguest subarchitectures. While at it since head.c
> just has ebda data rename it. Since we're using linker tables
> and both x86 32-bit and 64-bit have them we don't need
> to declare a call for this separately. This lets us
> also keep this declared static now.
>
> Since we're using linker tables and have support to annotate
> subarchitecture do that instead. pv_legacy() is incorrect as
> its really only for legacy PV guests. There's no need for
> pv_legacy() check anymore now.

I'm entirely ignorant of anything going on in gPXE/iPXE.

Can you explain what a linker table *does*?  It looks like all you've
done in this patch is to move code around.  What actually happens?

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1294261

On Thu, Dec 17, 2015 at 12:55 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 12/17/15 12:48, Andy Lutomirski wrote:
>>
>> I'm entirely ignorant of anything going on in gPXE/iPXE.
>>
>> Can you explain what a linker table *does*?  It looks like all you've
>> done in this patch is to move code around.  What actually happens?
>>
>
> A linker table is a data structure that is stitched together from items
> in multiple object files.
>
> We already have a *bunch* of linker tables in Linux, mostly the init
> tables, but they are all built in an ad hoc manner which requires linker
> script modifications, which are of course per architecture.
>
> My desire would be to make a general linker table facility so that a new
> linker table can be implemented by changing C code only.

Sounds good to me.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1294329

On Thu, Dec 17, 2015 at 12:57:49PM -0800, Andy Lutomirski wrote:
> On Thu, Dec 17, 2015 at 12:55 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> > On 12/17/15 12:48, Andy Lutomirski wrote:
> >>
> >> I'm entirely ignorant of anything going on in gPXE/iPXE.
> >>
> >> Can you explain what a linker table *does*?  It looks like all you've
> >> done in this patch is to move code around.  What actually happens?
> >>
> >
> > A linker table is a data structure that is stitched together from items
> > in multiple object files.
> >
> > We already have a *bunch* of linker tables in Linux, mostly the init
> > tables, but they are all built in an ad hoc manner which requires linker
> > script modifications, which are of course per architecture.
> >
> > My desire would be to make a general linker table facility so that a new
> > linker table can be implemented by changing C code only.
> 
> Sounds good to me.

That's what this actually accomplishes, there are just a few caveats to consider,
more on this shortly on the other thread in this patch series.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1294264

On 12/17/15 12:48, Andy Lutomirski wrote:
> 
> I'm entirely ignorant of anything going on in gPXE/iPXE.
> 
> Can you explain what a linker table *does*?  It looks like all you've
> done in this patch is to move code around.  What actually happens?
> 

A linker table is a data structure that is stitched together from items
in multiple object files.

We already have a *bunch* of linker tables in Linux, mostly the init
tables, but they are all built in an ad hoc manner which requires linker
script modifications, which are of course per architecture.

My desire would be to make a general linker table facility so that a new
linker table can be implemented by changing C code only.

	-hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web