[PATCH] powerpc/85xx: Move ePAPR paravirt initialization earlier

[PATCH] powerpc/85xx: Move ePAPR paravirt initialization earlier

[Laurentiu Tudor]

From: Tudor Laurentiu <laurentiu.tudor@freescale.com>

The ePAPR para-virtualization needs to happen very early
otherwise the bytechannel based console will silently
drop some of the early boot messages.

Before this patch, this is how the kernel log started:
-----------------------------------------------------
 > Brought up 2 CPUs
 > devtmpfs: initialized
 > NET: Registered protocol family 16
 [...]
-----------------------------------------------------

After the patch the early messages show up:
-----------------------------------------------------
 > Using P5020 DS machine description
 > MMU: Supported page sizes
 >          4 KB as direct
 >       4096 KB as direct
 [...]
-----------------------------------------------------

At console init, the kernel tried to flush the log buffer.
Since the paravirt was not yet initialized the console write
function failed silently, thus losing the buffered messages.

Signed-off-by: Laurentiu Tudor <Laurentiu.Tudor@freescale.com>
---
 arch/powerpc/include/asm/epapr_hcalls.h |    6 ++++++
 arch/powerpc/kernel/epapr_paravirt.c    |    3 +--
 arch/powerpc/kernel/setup_32.c          |    2 ++
 arch/powerpc/kernel/setup_64.c          |    3 +++
 4 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/include/asm/epapr_hcalls.h b/arch/powerpc/include/asm/epapr_hcalls.h
index d3d6342..544176e 100644
--- a/arch/powerpc/include/asm/epapr_hcalls.h
+++ b/arch/powerpc/include/asm/epapr_hcalls.h
@@ -105,6 +105,12 @@
 extern bool epapr_paravirt_enabled;
 extern u32 epapr_hypercall_start[];
 
+#ifdef CONFIG_EPAPR_PARAVIRT
+int __init epapr_paravirt_init(void);
+#else
+static inline int epapr_paravirt_init(void) { return 0; }
+#endif
+
 /*
  * We use "uintptr_t" to define a register because it's guaranteed to be a
  * 32-bit integer on a 32-bit platform, and a 64-bit integer on a 64-bit
diff --git a/arch/powerpc/kernel/epapr_paravirt.c b/arch/powerpc/kernel/epapr_paravirt.c
index f3eab85..9848713 100644
--- a/arch/powerpc/kernel/epapr_paravirt.c
+++ b/arch/powerpc/kernel/epapr_paravirt.c
@@ -28,7 +28,7 @@ extern u32 epapr_ev_idle_start[];
 
 bool epapr_paravirt_enabled;
 
-static int __init epapr_paravirt_init(void)
+int __init epapr_paravirt_init(void)
 {
 	struct device_node *hyper_node;
 	const u32 *insts;
@@ -58,4 +58,3 @@ static int __init epapr_paravirt_init(void)
 	return 0;
 }
 
-early_initcall(epapr_paravirt_init);
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index a8f54ec..1464655 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -38,6 +38,7 @@
 #include <asm/serial.h>
 #include <asm/udbg.h>
 #include <asm/mmu_context.h>
+#include <asm/epapr_hcalls.h>
 
 #include "setup.h"
 
@@ -327,4 +328,5 @@ void __init setup_arch(char **cmdline_p)
 	/* Initialize the MMU context management stuff */
 	mmu_context_init();
 
+	epapr_paravirt_init();
 }
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 6da881b..ce092ac 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -66,6 +66,7 @@
 #include <asm/code-patching.h>
 #include <asm/kvm_ppc.h>
 #include <asm/hugetlb.h>
+#include <asm/epapr_hcalls.h>
 
 #include "setup.h"
 
@@ -599,6 +600,8 @@ void __init setup_arch(char **cmdline_p)
 	/* Initialize the MMU context management stuff */
 	mmu_context_init();
 
+	epapr_paravirt_init();
+
 	kvm_linear_init();
 
 	/* Interrupt code needs to be 64K-aligned */
-- 
1.7.6.5

Re: powerpc/85xx: Move ePAPR paravirt initialization earlier

[Scott Wood]

On Tue, Mar 05, 2013 at 05:52:36PM +0200, Laurentiu TUDOR wrote:
> From: Tudor Laurentiu <laurentiu.tudor@freescale.com>
> 
> The ePAPR para-virtualization needs to happen very early
> otherwise the bytechannel based console will silently
> drop some of the early boot messages.
> 
> Before this patch, this is how the kernel log started:
> -----------------------------------------------------
>  > Brought up 2 CPUs
>  > devtmpfs: initialized
>  > NET: Registered protocol family 16
>  [...]
> -----------------------------------------------------
> 
> After the patch the early messages show up:
> -----------------------------------------------------
>  > Using P5020 DS machine description
>  > MMU: Supported page sizes
>  >          4 KB as direct
>  >       4096 KB as direct
>  [...]
> -----------------------------------------------------
> 
> At console init, the kernel tried to flush the log buffer.
> Since the paravirt was not yet initialized the console write
> function failed silently, thus losing the buffered messages.
[snip]
> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
> index 6da881b..ce092ac 100644
> --- a/arch/powerpc/kernel/setup_64.c
> +++ b/arch/powerpc/kernel/setup_64.c
> @@ -66,6 +66,7 @@
>  #include <asm/code-patching.h>
>  #include <asm/kvm_ppc.h>
>  #include <asm/hugetlb.h>
> +#include <asm/epapr_hcalls.h>
>  
>  #include "setup.h"
>  
> @@ -599,6 +600,8 @@ void __init setup_arch(char **cmdline_p)
>  	/* Initialize the MMU context management stuff */
>  	mmu_context_init();
>  
> +	epapr_paravirt_init();
> +
>  	kvm_linear_init();
>  
>  	/* Interrupt code needs to be 64K-aligned */

Is this early enough?  There's udbg activity before this.  Maybe it
should even go before udbg_early_init...  This would require converting
the code to use the early device tree functions.

-Scott

Re: powerpc/85xx: Move ePAPR paravirt initialization earlier

[Tudor Laurentiu]

On 06/26/2013 02:14 AM, Scott Wood wrote:
> On Tue, Mar 05, 2013 at 05:52:36PM +0200, Laurentiu TUDOR wrote:
>> From: Tudor Laurentiu<laurentiu.tudor@freescale.com>
>>
>> The ePAPR para-virtualization needs to happen very early
>> otherwise the bytechannel based console will silently
>> drop some of the early boot messages.
>>
>> Before this patch, this is how the kernel log started:
>> -----------------------------------------------------
>>   >  Brought up 2 CPUs
>>   >  devtmpfs: initialized
>>   >  NET: Registered protocol family 16
>>   [...]
>> -----------------------------------------------------
>>
>> After the patch the early messages show up:
>> -----------------------------------------------------
>>   >  Using P5020 DS machine description
>>   >  MMU: Supported page sizes
>>   >           4 KB as direct
>>   >        4096 KB as direct
>>   [...]
>> -----------------------------------------------------
>>
>> At console init, the kernel tried to flush the log buffer.
>> Since the paravirt was not yet initialized the console write
>> function failed silently, thus losing the buffered messages.
> [snip]
>> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
>> index 6da881b..ce092ac 100644
>> --- a/arch/powerpc/kernel/setup_64.c
>> +++ b/arch/powerpc/kernel/setup_64.c
>> @@ -66,6 +66,7 @@
>>   #include<asm/code-patching.h>
>>   #include<asm/kvm_ppc.h>
>>   #include<asm/hugetlb.h>
>> +#include<asm/epapr_hcalls.h>
>>
>>   #include "setup.h"
>>
>> @@ -599,6 +600,8 @@ void __init setup_arch(char **cmdline_p)
>>   	/* Initialize the MMU context management stuff */
>>   	mmu_context_init();
>>
>> +	epapr_paravirt_init();
>> +
>>   	kvm_linear_init();
>>
>>   	/* Interrupt code needs to be 64K-aligned */
>
> Is this early enough?  There's udbg activity before this.  Maybe it
> should even go before udbg_early_init...

Right. I'll try moving it in machine_init().

> This would require converting
> the code to use the early device tree functions.
>

I see. Had a look at that api and it seems pretty limited.
I couldn't find a simple way of reading a property other than scanning 
the entire tree with of_scan_flat_dt().

---
Best Regards, Laurentiu

Re: powerpc/85xx: Move ePAPR paravirt initialization earlier

[Scott Wood]

On 06/26/2013 07:36:23 AM, Tudor Laurentiu wrote:
> On 06/26/2013 02:14 AM, Scott Wood wrote:
>> This would require converting
>> the code to use the early device tree functions.
>>=20
>=20
> I see. Had a look at that api and it seems pretty limited.
> I couldn't find a simple way of reading a property other than =20
> scanning the entire tree with of_scan_flat_dt().

What's wrong with scanning the entire tree?  The data format doesn't =20
allow any more efficient type of lookup (it was designed to be simple =20
and small, not fast).

-Scott=