* [PATCH] Update lppaca offset comments
From: Michael Neuling @ 2006-08-07 7:34 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Update offset comments. No functional change.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
include/asm-powerpc/lppaca.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6-ozlabs/include/asm-powerpc/lppaca.h
===================================================================
--- linux-2.6-ozlabs.orig/include/asm-powerpc/lppaca.h
+++ linux-2.6-ozlabs/include/asm-powerpc/lppaca.h
@@ -114,7 +114,7 @@ struct lppaca {
//=============================================================================
-// CACHE_LINE_3 0x0100 - 0x007F: This line is shared with other processors
+// CACHE_LINE_3 0x0100 - 0x017F: This line is shared with other processors
//=============================================================================
// This is the yield_count. An "odd" value (low bit on) means that
// the processor is yielded (either because of an OS yield or a PLIC
@@ -126,7 +126,7 @@ struct lppaca {
u8 reserved6[124]; // Reserved x04-x7F
//=============================================================================
-// CACHE_LINE_4-5 0x0100 - 0x01FF Contains PMC interrupt data
+// CACHE_LINE_4-5 0x0180 - 0x027F Contains PMC interrupt data
//=============================================================================
u8 pmc_save_area[256]; // PMC interrupt Area x00-xFF
} __attribute__((__aligned__(0x400)));
^ permalink raw reply
* Who cares about PReP?
From: Paul Mackerras @ 2006-08-07 6:59 UTC (permalink / raw)
To: linuxppc-dev
I started looking at moving the PReP code over to arch/powerpc. I am
struck by how many ifdefs there are in there to set things up for
particular individual PReP implementations. We can do better than
that, I'm sure, but the issue becomes one of testing. The only PReP I
have here is an RS/6000 43p-140.
Who else has a PReP system and would be willing to do some testing and
debugging? If so, what sort of PReP is it?
Paul.
^ permalink raw reply
* Re: [PATCH 1/6] bootwrapper: arch/powerpc/boot code reorg
From: Paul Mackerras @ 2006-08-07 6:48 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20060803192629.GD25251@mag.az.mvista.com>
Mark A. Greer writes:
> I realize that I didn't really answer your question. Its at least
> possible that the console driver could not be known at link time.
>
> An example I used in another email is a platform that has 4 serial
> ports, 2-16550 and 2-mpsc, say. The /chosen/linux,stdout-path could
> pick any of the four so you would need to compile in a low-level
> serial driver for both and hook the correct one up at runtime.
>
> Same could be said for a serial vs. video console.
OK, that's reasonable. Still would be nice not to have to do the
double dereference though. I think that the platform_ops and the
fw_ops could probably be combined. Also, an init method for the
platform/fw_ops would be useful - it would let us remove the kludge
you have in the OF malloc implementation.
The OF malloc is currently applying a minimum address constraint for
all platforms, where it used to apply it only for 64-bit platforms.
We need to fix that up somehow too.
Regards,
Paul.
^ permalink raw reply
* Re: [RFC] asm code for Hypervisor Call Instrumentation
From: Paul Mackerras @ 2006-08-07 6:26 UTC (permalink / raw)
To: Mike Kravetz; +Cc: linuxppc-dev
In-Reply-To: <20060802175947.GA7489@w-mikek2.ibm.com>
Mike Kravetz writes:
> This patch is built on top of Anton's hcall cleanup patch. One
> remaining issue is 'where should the statistic data structures
> be updated?'. For simplicity, I have the asm code call the
> following C routine to perform the updates.
Hmmm, doing the update in assembly would avoid the need to create a
stack frame, which would be nice... Maybe we need to add some macros
to include/asm-powerpc/percpu.h to make it easier to access per-cpu
variables from assembly code.
Alternatively, we could put a pointer to the hcall_stats array for
each cpu in its paca. That's very easily accessed from assembly code.
Paul.
^ permalink raw reply
* [PATCH] SLB shadow buffer
From: Michael Neuling @ 2006-08-07 6:19 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus, anton, miltonm
This adds a shadow buffer for the SLBs and regsiters it with PHYP.
Only the bolted SLB entries (top 3) are shadowed.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
Updated with comments from Milton.
arch/powerpc/kernel/asm-offsets.c | 2 +
arch/powerpc/kernel/entry_64.S | 13 ++++++++
arch/powerpc/kernel/paca.c | 15 +++++++++
arch/powerpc/mm/slb.c | 37 +++++++++++++++++++++---
arch/powerpc/platforms/pseries/lpar.c | 24 ++++++++++++---
arch/powerpc/platforms/pseries/plpar_wrappers.h | 10 ++++++
arch/powerpc/platforms/pseries/setup.c | 12 ++++++-
include/asm-powerpc/lppaca.h | 19 ++++++++++++
include/asm-powerpc/paca.h | 3 +
9 files changed, 124 insertions(+), 11 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/asm-offsets.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/asm-offsets.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/asm-offsets.c
@@ -135,11 +135,13 @@ int main(void)
DEFINE(PACA_STARTPURR, offsetof(struct paca_struct, startpurr));
DEFINE(PACA_USER_TIME, offsetof(struct paca_struct, user_time));
DEFINE(PACA_SYSTEM_TIME, offsetof(struct paca_struct, system_time));
+ DEFINE(PACA_SLBSHADOWPTR, offsetof(struct paca_struct, slb_shadow_ptr));
DEFINE(LPPACASRR0, offsetof(struct lppaca, saved_srr0));
DEFINE(LPPACASRR1, offsetof(struct lppaca, saved_srr1));
DEFINE(LPPACAANYINT, offsetof(struct lppaca, int_dword.any_int));
DEFINE(LPPACADECRINT, offsetof(struct lppaca, int_dword.fields.decr_int));
+ DEFINE(SLBSHADOW_SAVEAREA, offsetof(struct slb_shadow, save_area));
#endif /* CONFIG_PPC64 */
/* RTAS */
Index: linux-2.6-ozlabs/arch/powerpc/kernel/entry_64.S
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/entry_64.S
+++ linux-2.6-ozlabs/arch/powerpc/kernel/entry_64.S
@@ -323,6 +323,11 @@ _GLOBAL(ret_from_fork)
* The code which creates the new task context is in 'copy_thread'
* in arch/powerpc/kernel/process.c
*/
+#define SHADOW_SLB_BOLTED_STACK_ESID \
+ (SLBSHADOW_SAVEAREA + 0x10*(SLB_NUM_BOLTED-1))
+#define SHADOW_SLB_BOLTED_STACK_VSID \
+ (SLBSHADOW_SAVEAREA + 0x10*(SLB_NUM_BOLTED-1) + 8)
+
.align 7
_GLOBAL(_switch)
mflr r0
@@ -375,6 +380,14 @@ BEGIN_FTR_SECTION
ld r7,KSP_VSID(r4) /* Get new stack's VSID */
oris r0,r6,(SLB_ESID_V)@h
ori r0,r0,(SLB_NUM_BOLTED-1)@l
+
+ /* Update the last bolted SLB */
+ ld r9,PACA_SLBSHADOWPTR(r13)
+ li r12,0
+ std r12,SHADOW_SLB_BOLTED_STACK_ESID(r9) /* Clear ESID */
+ std r7,SHADOW_SLB_BOLTED_STACK_VSID(r9) /* Save VSID */
+ std r0,SHADOW_SLB_BOLTED_STACK_ESID(r9) /* Save ESID */
+
slbie r6
slbie r6 /* Workaround POWER5 < DD2.1 issue */
slbmte r7,r0
Index: linux-2.6-ozlabs/arch/powerpc/kernel/paca.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/paca.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/paca.c
@@ -17,6 +17,7 @@
#include <asm/lppaca.h>
#include <asm/iseries/it_lp_reg_save.h>
#include <asm/paca.h>
+#include <asm/mmu.h>
/* This symbol is provided by the linker - let it fill in the paca
@@ -45,6 +46,17 @@ struct lppaca lppaca[] = {
},
};
+/*
+ * 3 persistent SLBs are registered here. The buffer will be zero
+ * initially, hence will all be invaild until we actually write them.
+ */
+struct slb_shadow slb_shadow[] __cacheline_aligned = {
+ [0 ... (NR_CPUS-1)] = {
+ .persistent = SLB_NUM_BOLTED,
+ .buffer_length = sizeof(struct slb_shadow),
+ },
+};
+
/* The Paca is an array with one entry per processor. Each contains an
* lppaca, which contains the information shared between the
* hypervisor and Linux.
@@ -59,7 +71,8 @@ struct lppaca lppaca[] = {
.lock_token = 0x8000, \
.paca_index = (number), /* Paca Index */ \
.kernel_toc = (unsigned long)(&__toc_start) + 0x8000UL, \
- .hw_cpu_id = 0xffff,
+ .hw_cpu_id = 0xffff, \
+ .slb_shadow_ptr = &slb_shadow[number],
#ifdef CONFIG_PPC_ISERIES
#define PACA_INIT_ISERIES(number) \
Index: linux-2.6-ozlabs/arch/powerpc/mm/slb.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/mm/slb.c
+++ linux-2.6-ozlabs/arch/powerpc/mm/slb.c
@@ -22,6 +22,8 @@
#include <asm/paca.h>
#include <asm/cputable.h>
#include <asm/cacheflush.h>
+#include <asm/smp.h>
+#include <linux/compiler.h>
#ifdef DEBUG
#define DBG(fmt...) udbg_printf(fmt)
@@ -50,9 +52,32 @@ static inline unsigned long mk_vsid_data
return (get_kernel_vsid(ea) << SLB_VSID_SHIFT) | flags;
}
-static inline void create_slbe(unsigned long ea, unsigned long flags,
- unsigned long entry)
+static inline void slb_shadow_update(unsigned long esid, unsigned long vsid,
+ unsigned long entry)
{
+ /*
+ * Clear the ESID first so the entry is not valid while we are
+ * updating it.
+ */
+ get_slb_shadow()->save_area[entry].esid = 0;
+ barrier();
+ get_slb_shadow()->save_area[entry].vsid = vsid;
+ barrier();
+ get_slb_shadow()->save_area[entry].esid = esid;
+
+}
+
+static inline void create_shadowed_slbe(unsigned long ea, unsigned long flags,
+ unsigned long entry)
+{
+ /*
+ * Updating the shadow buffer before writing the SLB ensures
+ * we don't get a stale entry here if we get preempted by PHYP
+ * between these two statements.
+ */
+ slb_shadow_update(mk_esid_data(ea, entry), mk_vsid_data(ea, flags),
+ entry);
+
asm volatile("slbmte %0,%1" :
: "r" (mk_vsid_data(ea, flags)),
"r" (mk_esid_data(ea, entry))
@@ -77,6 +102,10 @@ void slb_flush_and_rebolt(void)
if ((ksp_esid_data & ESID_MASK) == PAGE_OFFSET)
ksp_esid_data &= ~SLB_ESID_V;
+ /* Only third entry (stack) may change here so only resave that */
+ slb_shadow_update(ksp_esid_data,
+ mk_vsid_data(ksp_esid_data, lflags), 2);
+
/* We need to do this all in asm, so we're sure we don't touch
* the stack between the slbia and rebolting it. */
asm volatile("isync\n"
@@ -209,9 +238,9 @@ void slb_initialize(void)
asm volatile("isync":::"memory");
asm volatile("slbmte %0,%0"::"r" (0) : "memory");
asm volatile("isync; slbia; isync":::"memory");
- create_slbe(PAGE_OFFSET, lflags, 0);
+ create_shadowed_slbe(PAGE_OFFSET, lflags, 0);
- create_slbe(VMALLOC_START, vflags, 1);
+ create_shadowed_slbe(VMALLOC_START, vflags, 1);
/* We don't bolt the stack for the time being - we're in boot,
* so the stack is in the bolted segment. By the time it goes
Index: linux-2.6-ozlabs/arch/powerpc/platforms/pseries/lpar.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/platforms/pseries/lpar.c
+++ linux-2.6-ozlabs/arch/powerpc/platforms/pseries/lpar.c
@@ -254,18 +254,34 @@ out:
void vpa_init(int cpu)
{
int hwcpu = get_hard_smp_processor_id(cpu);
- unsigned long vpa = __pa(&lppaca[cpu]);
+ unsigned long addr;
long ret;
if (cpu_has_feature(CPU_FTR_ALTIVEC))
lppaca[cpu].vmxregs_in_use = 1;
- ret = register_vpa(hwcpu, vpa);
+ addr = __pa(&lppaca[cpu]);
+ ret = register_vpa(hwcpu, addr);
- if (ret)
+ if (ret) {
printk(KERN_ERR "WARNING: vpa_init: VPA registration for "
"cpu %d (hw %d) of area %lx returns %ld\n",
- cpu, hwcpu, vpa, ret);
+ cpu, hwcpu, addr, ret);
+ return;
+ }
+ /*
+ * PAPR says this feature is SLB-Buffer but firmware never
+ * reports that. All SPLPAR support SLB shadow buffer.
+ */
+ addr = __pa(&slb_shadow[cpu]);
+ if (firmware_has_feature(FW_FEATURE_SPLPAR)) {
+ ret = register_slb_shadow(hwcpu, addr);
+ if (ret)
+ printk(KERN_ERR
+ "WARNING: vpa_init: SLB shadow buffer "
+ "registration for cpu %d (hw %d) of area %lx "
+ "returns %ld\n", cpu, hwcpu, addr, ret);
+ }
}
long pSeries_lpar_hpte_insert(unsigned long hpte_group,
Index: linux-2.6-ozlabs/arch/powerpc/platforms/pseries/plpar_wrappers.h
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/platforms/pseries/plpar_wrappers.h
+++ linux-2.6-ozlabs/arch/powerpc/platforms/pseries/plpar_wrappers.h
@@ -40,6 +40,16 @@ static inline long register_vpa(unsigned
return vpa_call(0x1, cpu, vpa);
}
+static inline long unregister_slb_shadow(unsigned long cpu, unsigned long vpa)
+{
+ return vpa_call(0x7, cpu, vpa);
+}
+
+static inline long register_slb_shadow(unsigned long cpu, unsigned long vpa)
+{
+ return vpa_call(0x3, cpu, vpa);
+}
+
extern void vpa_init(int cpu);
static inline long plpar_pte_remove(unsigned long flags, unsigned long ptex,
Index: linux-2.6-ozlabs/arch/powerpc/platforms/pseries/setup.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/platforms/pseries/setup.c
+++ linux-2.6-ozlabs/arch/powerpc/platforms/pseries/setup.c
@@ -234,9 +234,17 @@ static void pseries_kexec_cpu_down_xics(
{
/* Don't risk a hypervisor call if we're crashing */
if (firmware_has_feature(FW_FEATURE_SPLPAR) && !crash_shutdown) {
- unsigned long vpa = __pa(get_lppaca());
+ unsigned long addr;
- if (unregister_vpa(hard_smp_processor_id(), vpa)) {
+ addr = __pa(get_slb_shadow());
+ if (unregister_slb_shadow(hard_smp_processor_id(), addr))
+ printk("SLB shadow buffer deregistration of "
+ "cpu %u (hw_cpu_id %d) failed\n",
+ smp_processor_id(),
+ hard_smp_processor_id());
+
+ addr = __pa(get_lppaca());
+ if (unregister_vpa(hard_smp_processor_id(), addr)) {
printk("VPA deregistration of cpu %u (hw_cpu_id %d) "
"failed\n", smp_processor_id(),
hard_smp_processor_id());
Index: linux-2.6-ozlabs/include/asm-powerpc/lppaca.h
===================================================================
--- linux-2.6-ozlabs.orig/include/asm-powerpc/lppaca.h
+++ linux-2.6-ozlabs/include/asm-powerpc/lppaca.h
@@ -27,7 +27,9 @@
//
//
//----------------------------------------------------------------------------
+#include <linux/cache.h>
#include <asm/types.h>
+#include <asm/mmu.h>
/* The Hypervisor barfs if the lppaca crosses a page boundary. A 1k
* alignment is sufficient to prevent this */
@@ -133,5 +135,22 @@ struct lppaca {
extern struct lppaca lppaca[];
+/*
+ * SLB shadow buffer structure as defined in the PAPR. The save_area
+ * contains adjacent ESID and VSID pairs for each shadowed SLB. The
+ * ESID is stored in the lower 64bits, then the VSID.
+ */
+struct slb_shadow {
+ u32 persistent; // Number of persistent SLBs x00-x03
+ u32 buffer_length; // Total shadow buffer length x04-x07
+ u64 reserved; // Alignment x08-x0f
+ struct {
+ u64 esid;
+ u64 vsid;
+ } save_area[SLB_NUM_BOLTED]; // x10-x40
+} ____cacheline_aligned;
+
+extern struct slb_shadow slb_shadow[];
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_LPPACA_H */
Index: linux-2.6-ozlabs/include/asm-powerpc/paca.h
===================================================================
--- linux-2.6-ozlabs.orig/include/asm-powerpc/paca.h
+++ linux-2.6-ozlabs/include/asm-powerpc/paca.h
@@ -23,6 +23,7 @@
register struct paca_struct *local_paca asm("r13");
#define get_paca() local_paca
#define get_lppaca() (get_paca()->lppaca_ptr)
+#define get_slb_shadow() (get_paca()->slb_shadow_ptr)
struct task_struct;
@@ -98,6 +99,8 @@ struct paca_struct {
u64 user_time; /* accumulated usermode TB ticks */
u64 system_time; /* accumulated system TB ticks */
u64 startpurr; /* PURR/TB value snapshot */
+
+ struct slb_shadow *slb_shadow_ptr;
};
extern struct paca_struct paca[];
^ permalink raw reply
* Re: [PATCH] SLB shadow buffer
From: Michael Neuling @ 2006-08-07 5:55 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev, paulus
In-Reply-To: <111547573996b8b45671.846930886.miltonm@bga.com>
> > +#define SHADOW_SLB_BOLTED_LAST_ESID \
> > + (SLBSHADOW_SAVEAREA + 0x10*(SLB_NUM_BOLTED-1))
> > +#define SHADOW_SLB_BOLTED_LAST_VSID \
> > + (SLBSHADOW_SAVEAREA + 0x10*(SLB_NUM_BOLTED-1) + 8)
>
> It's not because it's the last one but that it's the one with the stack.
Yep changed to SHADOW_SLB_BOLTED_STACK_<blah>
> > + std r12,SHADOW_SLB_BOLTED_LAST_ESID(r9) /* Clear ESID */
> > + std r7,SHADOW_SLB_BOLTED_LAST_VSID(r9) /* Save VSID */
> > + std r0,SHADOW_SLB_BOLTED_LAST_ESID(r9) /* Save ESID */
> > +
>
> Tabs not spaces please
Oops.. done
> > +/*
> > + * 3 persistent SLBs are registered here. The buffer will be zero
> > + * initially, hence will all be invaild until we actually write them.
> > + */
> > +struct slb_shadow_buffer slb_shadow_buffer[] = {
> > + [0 ... (NR_CPUS-1)] = {
> > + .persistent = SLB_NUM_BOLTED,
> > + .buffer_length = sizeof(struct slb_shadow_buffer),
> > + },
> > +};
>
> How about making this per-cpu and setting the paca pointer at runtime?
> It would save NR_CPUS-1 cachelines of data. Otherwise, put in
> cacheline_aligned will potentially save some space.
The PAPR requirement is that it's cache aligned so I've added the
necessary __cacheline_aligned foo.
I did some experiments and without the alignment. Alignment costs
around 8KB when NR_CPUS=128 so there is some space to be saved if we
play around.
I also tried putting the structure directly in the PACA but I couldn't
get any savings. I tired in a few different locations in the paca
struct, but it didn't make any difference. I may have been doing
something stupid though :-)
>
> > +
> > /* The Paca is an array with one entry per processor. Each contains an
> > * lppaca, which contains the information shared between the
> > * hypervisor and Linux.
> > @@ -59,7 +71,8 @@ struct lppaca lppaca[] = {
> > .lock_token = 0x8000, \
> > .paca_index = (number), /* Paca Index */ \
> > .kernel_toc = (unsigned long)(&__toc_start) + 0x8000UL, \
> > - .hw_cpu_id = 0xffff,
> > + .hw_cpu_id = 0xffff, \
> > + .slb_shadow_buffer_ptr = &slb_shadow_buffer[number]
>
> Trailing , (yeah, still have to add the \ )
Oops.. done
>
> >
> > #ifdef CONFIG_PPC_ISERIES
> > #define PACA_INIT_ISERIES(number) \
> > Index: linux-2.6-ozlabs/arch/powerpc/mm/slb.c
> > ===================================================================
> > --- linux-2.6-ozlabs.orig/arch/powerpc/mm/slb.c
> > +++ linux-2.6-ozlabs/arch/powerpc/mm/slb.c
> > @@ -22,6 +22,8 @@
> > #include <asm/paca.h>
> > #include <asm/cputable.h>
> > #include <asm/cacheflush.h>
> > +#include <asm/smp.h>
> > +#include <linux/compiler.h>
> >
> > #ifdef DEBUG
> > #define DBG(fmt...) udbg_printf(fmt)
> > @@ -50,9 +52,29 @@ static inline unsigned long mk_vsid_data
> > return (get_kernel_vsid(ea) << SLB_VSID_SHIFT) | flags;
> > }
> >
> > +static inline void slb_shadow_update(unsigned long esid, unsigned long vsi
d,
> > + unsigned long entry)
> > +{
> > + /* Clear the ESID first so the entry is not valid while we are
> > + * updating it. Then write the VSID before the real ESID. */
>
> Multi-line comments get the */ on it's own line
Ok... (most comments in that file are like this though)
> > + get_slb_shadow_buffer()->save_area[2*entry] = 0;
> > + barrier();
> > + get_slb_shadow_buffer()->save_area[2*entry+1] = vsid;
> > + barrier();
> > + get_slb_shadow_buffer()->save_area[2*entry] = esid;
> > +
> > +}
>
> This 2* seems magic. How about an array of structs?
OK, that's two people I've confused. Changed.
>
> > +
> > static inline void create_slbe(unsigned long ea, unsigned long flags,
> > unsigned long entry)
>
> Should we rename to create_shadowed_slbe?
Good point. Changed
> > + slb_shadow_update(mk_esid_data(ea, entry),
> > + mk_vsid_data(ea, flags),
> > + entry);
>
> Do we need the third line?
Nope.
>
> > +
> > asm volatile("slbmte %0,%1" :
> > : "r" (mk_vsid_data(ea, flags)),
> > "r" (mk_esid_data(ea, entry))
>
> Hopefully the compiler only calculates these once.
I've been keeping all my fingers and toes crossed...
> > @@ -77,6 +99,11 @@ void slb_flush_and_rebolt(void)
> > if ((ksp_esid_data & ESID_MASK) == PAGE_OFFSET)
> > ksp_esid_data &= ~SLB_ESID_V;
> >
> > + /* Only second entry may change here so only resave that */
> > + slb_shadow_update(ksp_esid_data,
> > + mk_vsid_data(ksp_esid_data, lflags),
> > + 2);
> > +
>
> 1) it's the third entry 2) it's the stack slot
Yep. Updated comment.
>
> > asm volatile("isync\n"
> > Index: linux-2.6-ozlabs/arch/powerpc/platforms/pseries/lpar.c
> > ===================================================================
> > --- linux-2.6-ozlabs.orig/arch/powerpc/platforms/pseries/lpar.c
> > +++ linux-2.6-ozlabs/arch/powerpc/platforms/pseries/lpar.c
> > @@ -254,18 +254,32 @@ out:
> > void vpa_init(int cpu)
> > {
> > int hwcpu = get_hard_smp_processor_id(cpu);
> > - unsigned long vpa = __pa(&lppaca[cpu]);
> > + unsigned long vpa;
>
> This is used for something other than vpa, rename.
Another complaint about this, I'll changed.
BTW It's called vpa in the PAPR for both calls.
> > +/* SLB shadow buffer structure as defined in the PAPR. The save_area
> > + * contains adjacent ESID and VSID pairs for each shadowed SLB. The
> > + * ESID is stored in the lower 64bits, then the VSID. NOTE: This
> > + * structure is 0x40 bytes long (with 3 bolted SLBs), but PHYP
> > + * complaints if we're not 0x80 (cache line?) aligned. */
>
> Own line
>
> Less explaination needed with array of structs.
Yep and yep.
>
> > +struct slb_shadow_buffer {
> > + u32 persistent; // Number of persistent SLBs x00-x03
> > + u32 buffer_length; // Total shadow buffer length x04-x07
> > + u64 reserved; // Alignment x08-x0f
> > + u64 save_area[SLB_NUM_BOLTED * 2]; // x10-x40
> > +} __attribute__((__aligned__(0x80)));
> > +
> > +extern struct slb_shadow_buffer slb_shadow_buffer[];
> > +
>
> Remove buffer from these names? They seem quite long for linux.
Ok. Changed.
> > u64 user_time; /* accumulated usermode TB ticks */
> > u64 system_time; /* accumulated system TB ticks */
> > u64 startpurr; /* PURR/TB value snapshot */
> > +
> > + /* Pointer to SLB shadow buffer */
> > + struct slb_shadow_buffer *slb_shadow_buffer_ptr;
> > };
>
> With the long name the comment doesn't add much.
True. The comment was only there since most other items in that struct
were documented.
Thanks for the review. I'll repost the updated patch.
Mikey
^ permalink raw reply
* [PATCH] fix for firewire patch added in 2.6.17.2 that breaks things on ppc
From: danny @ 2006-08-07 4:38 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20060805151050.B24484@luna.ellen.dexterslabs.com>
[-- Attachment #1: Type: text/plain, Size: 614 bytes --]
Hello,
I sent this to Ben earlier but forgot to cc this list:
>
> Sleep broke on my ibook G3 with 2.6.17. After some tests it seemed it only broke when I had used my
> iSight. Plugging it after a sleep/resume cycle would sometimes instantly hang the machine.
>
> The problem appeared to result from a patch added in 2.6.17.2, where a
> pci_save_state(pdev);
> is called after
> pmac_call_feature(PMAC_FTR_1394_ENABLE, of_node, 0, 0);
>
> resuming shows that the corresponding pci_restore_state is writing all ffffffff to the config space.
> Which is probably not a good idea.
>
Patch is attached
Danny
[-- Attachment #2: ohci1394_save_state.patch --]
[-- Type: text/plain, Size: 987 bytes --]
2.6.17.2 contained a patch for preliminary suspend/resume
handling on !PPC_PMAC. However, this broke suspend and firewire
on powerpc because it saves the state after the device has already
been disabled.
Firewire works perfectly through suspend on my ibook, so save/restore
state is not needed there.
Signed-off-by: Danny Tholen <obiwan@mailmij.org>
--- linux-2.6.17.7/drivers/ieee1394/ohci1394.c~ 2006-08-03 10:00:01.875855084 -0400
+++ linux-2.6.17.7/drivers/ieee1394/ohci1394.c 2006-08-03 10:08:24.274059577 -0400
@@ -3537,9 +3537,9 @@
if (of_node)
pmac_call_feature (PMAC_FTR_1394_ENABLE, of_node, 0, 1);
}
-#endif /* CONFIG_PPC_PMAC */
-
+#else
pci_restore_state(pdev);
+#endif /* CONFIG_PPC_PMAC */
pci_enable_device(pdev);
return 0;
@@ -3557,10 +3557,9 @@
if (of_node)
pmac_call_feature(PMAC_FTR_1394_ENABLE, of_node, 0, 0);
}
-#endif
-
+#else
pci_save_state(pdev);
-
+#endif /* CONFIG_PPC_PMAC */
return 0;
}
^ permalink raw reply
* Re: [PATCH] powerpc: fix udbg warning
From: Geoff Levand @ 2006-08-07 0:51 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <44D655BF.3080803@am.sony.com>
Here's an updated version that fixes a few more warnings.
-Geoff
Fix an implicit declaration warning in hash_utils_64.c
when udbg is enabled.
hash_utils_64.c: In function =E2=80=98htab_bolt_mapping=E2=80=99:
hash_utils_64.c:169: warning: implicit declaration of function =E2=80=98u=
dbg_printf=E2=80=99
hash_utils_64.c:251: warning: format =E2=80=98%04x=E2=80=99 expects type =
=E2=80=98unsigned int=E2=80=99
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
Index: cell--common--4/arch/powerpc/mm/hash_utils_64.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- cell--common--4.orig/arch/powerpc/mm/hash_utils_64.c
+++ cell--common--4/arch/powerpc/mm/hash_utils_64.c
@@ -51,6 +51,7 @@
#include <asm/cputable.h>
#include <asm/abs_addr.h>
#include <asm/sections.h>
+#include <asm/udbg.h>
#ifdef DEBUG
#define DBG(fmt...) udbg_printf(fmt)
@@ -247,7 +248,7 @@ static int __init htab_dt_scan_page_size
else
def->tlbiel =3D 0;
- DBG(" %d: shift=3D%02x, sllp=3D%04x, avpnm=3D%08x, "
+ DBG(" %d: shift=3D%02x, sllp=3D%04lx, avpnm=3D%08lx, "
"tlbiel=3D%d, penc=3D%d\n",
idx, shift, def->sllp, def->avpnm, def->tlbiel,
def->penc);
@@ -773,7 +774,7 @@ void flush_hash_page(unsigned long va, r
{
unsigned long hash, index, shift, hidx, slot;
- DBG_LOW("flush_hash_page(va=3D%016x)\n", va);
+ DBG_LOW("flush_hash_page(va=3D%016lx)\n", va);
pte_iterate_hashed_subpages(pte, psize, va, index, shift) {
hash =3D hpt_hash(va, shift);
hidx =3D __rpte_to_hidx(pte, index);
@@ -781,7 +782,7 @@ void flush_hash_page(unsigned long va, r
hash =3D ~hash;
slot =3D (hash & htab_hash_mask) * HPTES_PER_GROUP;
slot +=3D hidx & _PTEIDX_GROUP_IX;
- DBG_LOW(" sub %d: hash=3D%x, hidx=3D%x\n", index, slot, hidx);
+ DBG_LOW(" sub %ld: hash=3D%lx, hidx=3D%lx\n", index, slot, hidx);
ppc_md.hpte_invalidate(slot, va, psize, local);
} pte_iterate_hashed_end();
}
^ permalink raw reply
* Re: [PATCH 3/6] bootwrapper: Add device tree ops for flattened device tree
From: Hollis Blanchard @ 2006-08-07 0:38 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, xen-ppc-devel@lists.xensource.com
In-Reply-To: <20060719230544.GD3887@mag.az.mvista.com>
On Wed, 2006-07-19 at 16:05 -0700, an unknown sender wrote:
> --- /dev/null
> +++ b/arch/powerpc/boot/fdt.c
> @@ -0,0 +1,525 @@
> +/*
> + * Simple dtb (binary flattened device tree) search/manipulation routines.
> + *
> + * Author: Mark A. Greer <mgreer at mvista.com>
> + * - The code for strrchr() was copied from lib/string.c and is
> + * copyrighted by Linus Torvalds.
> + * - The smarts for fdt_finddevice() were copied with the author's
> + * permission from u-boot:common/ft_build.c which was written by
> + * Pantelis Antoniou <pantelis at embeddedalley.com>.
Hmm, so we'll have at least three copies of this code: uboot, kernel,
and Xen. Would it make sense to put this stuff into a libdt.a?
Technically, dtc has a "libdt" already, but it's absurdly incomplete (I
don't even know why it's there), so we could just replace it.
Xen needs all the finddevice and setprop functionality here, which looks
like it's about 2/3rds of this code.
> +static void *dtb_start;
> +static void *dtb_end;
I'd like to avoid the use of globals here. I know it's fine when you're
running in early boot, but as I mentioned I'd like to copy this code
elsewhere. Could these be moved into a structure that's passed as a
function parameter?
> +static void
> +fdt_modify_prop(u32 *dp, char *datap, u32 *old_prop_sizep, char *buf,
> + int buflen)
> +{
> + u32 old_prop_data_len, new_prop_data_len;
> +
> + old_prop_data_len = _ALIGN_UP(*old_prop_sizep, 4);
> + new_prop_data_len = _ALIGN_UP(buflen, 4);
> +
> + /* Check if new prop data fits in old prop data area */
> + if (new_prop_data_len == old_prop_data_len) {
> + memcpy(datap, buf, buflen);
> + *old_prop_sizep = buflen;
> + }
> + else { /* Need to alloc new area to put larger or smaller fdt */
> + struct boot_param_header *old_bph, *new_bph;
> + u32 *old_tailp, *new_tailp, *new_datap;
> + u32 old_total_size, new_total_size, head_len, tail_len, diff;
> + void *new_dtb_start, *new_dtb_end;
> +
> + old_bph = fdt_get_bph(dtb_start),
> + old_total_size = old_bph->totalsize;
> + head_len = (u32)datap - (u32)dtb_start;
> + tail_len = old_total_size - (head_len + old_prop_data_len);
> + old_tailp = (u32 *)((u32)dtb_end - tail_len);
> + new_total_size = head_len + new_prop_data_len + tail_len;
> +
> + if (!(new_dtb_start = malloc(new_total_size))) {
> + printf("Can't alloc space for new fdt\n\r");
> + exit();
> + }
> +
> + new_dtb_end = (void *)((u32)new_dtb_start + new_total_size);
> + new_datap = (u32 *)((u32)new_dtb_start + head_len);
> + new_tailp = (u32 *)((u32)new_dtb_end - tail_len);
> +
> + memcpy(new_dtb_start, dtb_start, head_len);
> + memcpy(new_datap, buf, buflen);
> + memcpy(new_tailp, old_tailp, tail_len);
> + *(new_datap - 2) = buflen;
> +
> + new_bph = fdt_get_bph(new_dtb_start),
> + new_bph->totalsize = new_total_size;
> +
> + diff = new_prop_data_len - old_prop_data_len;
> +
> + /* Adjust offsets of other sections, if necessary */
> + if (new_bph->off_dt_strings > new_bph->off_dt_struct)
> + new_bph->off_dt_strings += diff;
> +
> + if (new_bph->off_mem_rsvmap > new_bph->off_dt_struct)
> + new_bph->off_mem_rsvmap += diff;
> +
> + free(dtb_start, old_total_size);
> +
> + dtb_start = new_dtb_start;
> + dtb_end = new_dtb_end;
> + }
> +}
I didn't realize the boot wrapper had a full malloc() to work with. I
was actually planning to only allow overwriting properties with values
of the same size, since for the most part I just need to modify some
small fixed-size data. Do you need more? I guess if the code already
works...
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH 1/6] bootwrapper: arch/powerpc/boot code reorg
From: Hollis Blanchard @ 2006-08-07 0:21 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev, xen-ppc-devel@lists.xensource.com
In-Reply-To: <20060719230014.GB3887@mag.az.mvista.com>
On Wed, 2006-07-19 at 16:00 -0700, an unknown sender wrote:
> diff --git a/arch/powerpc/boot/types.h b/arch/powerpc/boot/types.h
> new file mode 100644
> index 0000000..2a2fa2b
> --- /dev/null
> +++ b/arch/powerpc/boot/types.h
> @@ -0,0 +1,29 @@
> +#ifndef _TYPES_H_
> +#define _TYPES_H_
> +
> +#define COMMAND_LINE_SIZE 512
> +#define MAX_PATH_LEN 256
> +#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
> +
> +typedef unsigned char u8;
> +typedef unsigned short u16;
> +typedef unsigned int u32;
> +#ifdef __powerpc64__
> +typedef unsigned long u64;
> +#else
> +typedef unsigned long long u64;
> +#endif
As long as we're adding new typedefs, could we please use the stdint.h
ones (e.g. uint32_t)? For Xen, I need to do flat tree munging in
userspace, so using real types would help with code reuse.
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* Re: [PATCH] pSeries hvsi char driver null pointer deref
From: Hollis Blanchard @ 2006-08-06 23:49 UTC (permalink / raw)
To: Linas Vepstas; +Cc: akpm, linuxppc-dev, linux-kernel
In-Reply-To: <20060803201300.GB10638@austin.ibm.com>
On Thu, 2006-08-03 at 15:13 -0500, Linas Vepstas wrote:
> Andrew,
> Please apply.
>
> Under certain rare circumstances, it appears that there can be
> be a NULL-pointer deref when a user fiddles with terminal
> emeulation programs while outpu is being sent to the console.
> This patch checks for and avoids a NULL-pointer deref.
>
> Signed-off-by: Hollis Blanchard <hollisbl@austin.ibm.com>
> Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
That email address is incorrect.
Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>
> ----
> drivers/char/hvsi.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> Index: linux-2.6.18-rc3-git1/drivers/char/hvsi.c
> ===================================================================
> --- linux-2.6.18-rc3-git1.orig/drivers/char/hvsi.c 2006-08-03 14:50:00.000000000 -0500
> +++ linux-2.6.18-rc3-git1/drivers/char/hvsi.c 2006-08-03 14:51:46.000000000 -0500
> @@ -311,7 +311,8 @@ static void hvsi_recv_control(struct hvs
> /* CD went away; no more connection */
> pr_debug("hvsi%i: CD dropped\n", hp->index);
> hp->mctrl &= TIOCM_CD;
> - if (!(hp->tty->flags & CLOCAL))
> + /* If userland hasn't done an open(2) yet, hp->tty is NULL. */
> + if (hp->tty && !(hp->tty->flags & CLOCAL))
> *to_hangup = hp->tty;
> }
> break;
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* [PATCH] powerpc: fix udbg warning
From: Geoff Levand @ 2006-08-06 20:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Fix an implicit declaration warning in hash_utils_64.c
when udbg is enabled.
hash_utils_64.c: In function =91htab_bolt_mapping=92:
hash_utils_64.c:169: warning: implicit declaration of function =91udbg_pr=
intf=92
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
Index: a/arch/powerpc/mm/hash_utils_64.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- a.orig/arch/powerpc/mm/hash_utils_64.c
+++ a/arch/powerpc/mm/hash_utils_64.c
@@ -51,6 +51,7 @@
#include <asm/cputable.h>
#include <asm/abs_addr.h>
#include <asm/sections.h>
+#include <asm/udbg.h>
#ifdef DEBUG
#define DBG(fmt...) udbg_printf(fmt)
^ permalink raw reply
* [PATCH] cputable: Correct IBM/750CXe rev3.x setup
From: Nicolas DET @ 2006-08-06 8:42 UTC (permalink / raw)
To: linuxppc-dev; +Cc: akpm
[-- Attachment #1: Type: text/plain, Size: 163 bytes --]
This patch simply add an entry in the cputable to recognize correctly the IBM750CXe rev3.1. Only rev 2.x was correctly detected before.
Your sincerly
Nicolas DET
[-- Attachment #2: powerpc_750cxe_rev3.patch --]
[-- Type: application/octet-stream, Size: 684 bytes --]
--- linux-2.6.17.7.orig/arch/powerpc/kernel/cputable.c 2006-07-25 05:36:01.000000000 +0200
+++ linux-2.6.17.7_nico/arch/powerpc/kernel/cputable.c 2006-08-06 07:50:29.000000000 +0200
@@ -447,6 +447,18 @@
.cpu_setup = __setup_cpu_750cx,
.platform = "ppc750",
},
+ { /* 750CXe rev 3.1 (0008x311) */
+ .pvr_mask = 0xffff0fff,
+ .pvr_value = 0x00080311,
+ .cpu_name = "750CXe",
+ .cpu_features = CPU_FTRS_750,
+ .cpu_user_features = COMMON_USER,
+ .icache_bsize = 32,
+ .dcache_bsize = 32,
+ .num_pmcs = 4,
+ .cpu_setup = __setup_cpu_750cx,
+ .platform = "ppc750",
+ },
{ /* 750CXe "Gekko" (83214) */
.pvr_mask = 0xffffffff,
.pvr_value = 0x00083214,
^ permalink raw reply
* Re: [PATCH] SLB shadow buffer
From: Michael Neuling @ 2006-08-06 1:27 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev, sfr, paulus, anton
In-Reply-To: <1115481268674b0dc511.424238335.miltonm@bga.com>
> The SLB shadow buffer is a pure software construct recording the required
> segment translations. Registering a the shadow buffer informs the
> hypervisor which entries are required when switching partitions, and may
> allow it to recover the partition from a hardware error.
What Milton said. It's a high availability feature.
We can register volatile and persistent SLBs with PHYP. PHYP will
invalidate volatile entries and replace persistent entries if it sees a
problem with them.
Here I've only registered the 3 persistent (bolted) SLBs, as the
volatile SLBs can be handled with SLB faults in the kernel.
Mikey
^ permalink raw reply
* Re: [PATCH] SLB shadow buffer
From: Milton Miller @ 2006-08-05 21:18 UTC (permalink / raw)
To: hch, mikey; +Cc: linuxppc-dev, paulus, anton, sfr
On Sat Aug 5 2006 07:45:44 AM CDT, Christoph Hellwig wrote:
> On Fri, Aug 04, 2006 at 03:53:19PM +1000, Michael Neuling wrote:
> > This adds a shadow buffer for the SLBs and regsiters it with PHYP.
> > Only the bolted SLB entries (first 3) are saved.
>
> What is a SLB shadow buffer and why do we need it? (I don't want to
> question the patch but rather learn a little more about lowlevel ppc64
> mmu details)
The SLB is the segment lookaside buffer and holds mappings from the
effective address space (the address you get adding the register and
offset) to the virtual address space. Each entry covers 256MB (2^28)
and includes an access lookup switch for both problem states (a single
bit for each user and kernel mode), allowing the same or different
access permissions. The virtual address space, 80 bits shared by all
processes in the system (partition in lpar), is translated to a real address
and page permissions via the hash table, which is cached in the TLB.
The original 64 bit archiecture filled the SLB from a segment table
buffer (STAB), but this was changed to expicit software management in
version 2, used by POWER4 and later processors. The 32 bit
architecture uses 16 fixed segment registers to perfom this mapping to
a 52 bit virtual space.
The SLB shadow buffer is a pure software construct recording the required
segment translations. Registering a the shadow buffer informs the
hypervisor which entries are required when switching partitions, and may
allow it to recover the partition from a hardware error.
milton
^ permalink raw reply
* Re: ELDK 3.1.1 support for x86_64 host architecture
From: Wolfgang Denk @ 2006-08-05 19:32 UTC (permalink / raw)
To: Frank; +Cc: Michael Carey, linuxppc-embedded
In-Reply-To: <20060804204327.16319.qmail@web32202.mail.mud.yahoo.com>
In message <20060804204327.16319.qmail@web32202.mail.mud.yahoo.com> you wrote:
>
> There is something wrong with your Suse installation. I have
> been using ELDK with Suse(9.2 and 10.1) since 2004 without any problems...
Good to hear. But I heard similar reports before. Eventually they are
just missing some compatibility packages. I have no idea. I keep my
fingers off SuSE.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Were there fewer fools, knaves would starve. - Anonymous
^ permalink raw reply
* Re: [PATCH] Fix powerpc 44x_mmu build
From: Josh Boyer @ 2006-08-05 16:33 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-dev
In-Reply-To: <20060805131157.GA1873@matthew-porters-computer.local>
On Sat, 2006-08-05 at 09:11 -0400, Matt Porter wrote:
> On Fri, Aug 04, 2006 at 08:12:22PM -0500, Josh Boyer wrote:
> > On Fri, 2006-08-04 at 11:44 -0500, Matt Porter wrote:
> > > The PIN_SIZE definition name changed, update 44x_mmu.c accordingly.
> >
> > As far as I know, 4xx still builds as ARCH=ppc... is this patch just
> > something you noticed, or is it a hint that you're working on moving 4xx
> > to arch/powerpc?
>
> Yes, working on moving 4xx to arch/powerpc.
Excellent.
>
> > Just curious, since I've been poking at this a bit and would rather not
> > duplicate effort.
>
> Sounds great. In fact, I talked to BenH and tgall at ols about this
> and they mentioned you were doing some work. These patches are
> just some obvious basic things to get started.
>
> Since there's a lot of work here, what aspect are you working on?
> I haven't seen anything publicly but hear plenty of talk of people
> working on dt soc definitions for 4xx i/o blocks.
At the moment, I'm mostly trying to sit down and figure out the whole
device tree stack. That, and keep up with the irq rework BenH did. I
won't really be digging in for another couple weeks, but then I hope to
start actually doing something.
> I'm currently looking at merging ocotea but am using it to focus
> on a few fundamental things like merging over a version of the
> non-coherent DMA API implementation. The plan here is to get
> a serial-only port merged and then sync with whoever is working
> on the definitions and driver changes for the essential drivers
> (obviously emac first from my POV).
That sounds like a good plan. I know a guy already working on emac, but
it's a bit of a unique setup he's got. I'll try and get some patches
out of him soon.
>From talking with BenH, we'd also need the dt-in-zImage patches that are
floating around. Anybody know what's going on with those?
josh
^ permalink raw reply
* Re: [Alsa-devel] [PATCH 0/5] powerpc sound, some more patches
From: Johannes Berg @ 2006-08-05 16:09 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linuxppc-dev, alsa-devel, Jaroslav Kysela
In-Reply-To: <s5hirllsoae.wl%tiwai@suse.de>
[-- Attachment #1: Type: text/plain, Size: 300 bytes --]
> Jaroslav, could you update alsa git tree for pushing?
> We have ca. 20 pending fixes including these ppc-patches.
Pretty please? People are hitting these bugs every week and I always get
mail about it (and probably more people hitting the bugs who don't
manage to mail me...).
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH] SLB shadow buffer
From: Christoph Hellwig @ 2006-08-05 12:45 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, paulus, anton, sfr
In-Reply-To: <20060804055323.1A9BE679FB@ozlabs.org>
On Fri, Aug 04, 2006 at 03:53:19PM +1000, Michael Neuling wrote:
> This adds a shadow buffer for the SLBs and regsiters it with PHYP.
> Only the bolted SLB entries (first 3) are saved.
What is a SLB shadow buffer and why do we need it? (I don't want to
question the patch but rather learn a little more about lowlevel ppc64
mmu details)
^ permalink raw reply
* Re: [PATCH] SLB shadow buffer
From: Milton Miller @ 2006-08-05 5:56 UTC (permalink / raw)
To: mikey, paulus, linuxppc-dev; +Cc: sfr
On Fri Aug 4 2006 12:53:19 AM CDT, Michael Neuling wrote:
> This adds a shadow buffer for the SLBs and regsiters it with PHYP.
> Only the bolted SLB entries (first 3) are saved.
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
>
>
> Index: linux-2.6-ozlabs/arch/powerpc/kernel/entry_64.S
> ===================================================================
> --- linux-2.6-ozlabs.orig/arch/powerpc/kernel/entry_64.S
> +++ linux-2.6-ozlabs/arch/powerpc/kernel/entry_64.S
> @@ -323,6 +323,10 @@ _GLOBAL(ret_from_fork)
> * The code which creates the new task context is in 'copy_thread'
> * in arch/powerpc/kernel/process.c
> */
> +#define SHADOW_SLB_BOLTED_LAST_ESID \
> + (SLBSHADOW_SAVEAREA + 0x10*(SLB_NUM_BOLTED-1))
> +#define SHADOW_SLB_BOLTED_LAST_VSID \
> + (SLBSHADOW_SAVEAREA + 0x10*(SLB_NUM_BOLTED-1) + 8)
It's not because it's the last one but that it's the one with the stack.
> .align 7
> _GLOBAL(_switch)
> mflr r0
> @@ -375,6 +379,14 @@ BEGIN_FTR_SECTION
> ld r7,KSP_VSID(r4) /* Get new stack's VSID */
> oris r0,r6,(SLB_ESID_V)@h
> ori r0,r0,(SLB_NUM_BOLTED-1)@l
> +
> + /* Update the last bolted SLB */
> + ld r9,PACA_SLBSHADOWPTR(r13)
> + li r12,0
> + std r12,SHADOW_SLB_BOLTED_LAST_ESID(r9) /* Clear ESID */
> + std r7,SHADOW_SLB_BOLTED_LAST_VSID(r9) /* Save VSID */
> + std r0,SHADOW_SLB_BOLTED_LAST_ESID(r9) /* Save ESID */
> +
Tabs not spaces please
> slbie r6
> slbie r6 /* Workaround POWER5 < DD2.1 issue */
> slbmte r7,r0
> Index: linux-2.6-ozlabs/arch/powerpc/kernel/paca.c
> ===================================================================
> --- linux-2.6-ozlabs.orig/arch/powerpc/kernel/paca.c
> +++ linux-2.6-ozlabs/arch/powerpc/kernel/paca.c
> @@ -17,6 +17,7 @@
> #include <asm/lppaca.h>
> #include <asm/iseries/it_lp_reg_save.h>
> #include <asm/paca.h>
> +#include <asm/mmu.h>
>
>
> /* This symbol is provided by the linker - let it fill in the paca
> @@ -45,6 +46,17 @@ struct lppaca lppaca[] = {
> },
> };
>
> +/*
> + * 3 persistent SLBs are registered here. The buffer will be zero
> + * initially, hence will all be invaild until we actually write them.
> + */
> +struct slb_shadow_buffer slb_shadow_buffer[] = {
> + [0 ... (NR_CPUS-1)] = {
> + .persistent = SLB_NUM_BOLTED,
> + .buffer_length = sizeof(struct slb_shadow_buffer),
> + },
> +};
How about making this per-cpu and setting the paca pointer at runtime?
It would save NR_CPUS-1 cachelines of data. Otherwise, put in
cacheline_aligned will potentially save some space.
> +
> /* The Paca is an array with one entry per processor. Each contains an
> * lppaca, which contains the information shared between the
> * hypervisor and Linux.
> @@ -59,7 +71,8 @@ struct lppaca lppaca[] = {
> .lock_token = 0x8000, \
> .paca_index = (number), /* Paca Index */ \
> .kernel_toc = (unsigned long)(&__toc_start) + 0x8000UL, \
> - .hw_cpu_id = 0xffff,
> + .hw_cpu_id = 0xffff, \
> + .slb_shadow_buffer_ptr = &slb_shadow_buffer[number]
Trailing , (yeah, still have to add the \ )
>
> #ifdef CONFIG_PPC_ISERIES
> #define PACA_INIT_ISERIES(number) \
> Index: linux-2.6-ozlabs/arch/powerpc/mm/slb.c
> ===================================================================
> --- linux-2.6-ozlabs.orig/arch/powerpc/mm/slb.c
> +++ linux-2.6-ozlabs/arch/powerpc/mm/slb.c
> @@ -22,6 +22,8 @@
> #include <asm/paca.h>
> #include <asm/cputable.h>
> #include <asm/cacheflush.h>
> +#include <asm/smp.h>
> +#include <linux/compiler.h>
>
> #ifdef DEBUG
> #define DBG(fmt...) udbg_printf(fmt)
> @@ -50,9 +52,29 @@ static inline unsigned long mk_vsid_data
> return (get_kernel_vsid(ea) << SLB_VSID_SHIFT) | flags;
> }
>
> +static inline void slb_shadow_update(unsigned long esid, unsigned long vsid,
> + unsigned long entry)
> +{
> + /* Clear the ESID first so the entry is not valid while we are
> + * updating it. Then write the VSID before the real ESID. */
Multi-line comments get the */ on it's own line
> + get_slb_shadow_buffer()->save_area[2*entry] = 0;
> + barrier();
> + get_slb_shadow_buffer()->save_area[2*entry+1] = vsid;
> + barrier();
> + get_slb_shadow_buffer()->save_area[2*entry] = esid;
> +
> +}
This 2* seems magic. How about an array of structs?
> +
> static inline void create_slbe(unsigned long ea, unsigned long flags,
> unsigned long entry)
Should we rename to create_shadowed_slbe?
> {
> + /* Updating the shadow buffer before writing the SLB ensures
> + * we don't get a stale entry here if we get preempted by PHYP
> + * between these two statements. */
own line
> + slb_shadow_update(mk_esid_data(ea, entry),
> + mk_vsid_data(ea, flags),
> + entry);
Do we need the third line?
> +
> asm volatile("slbmte %0,%1" :
> : "r" (mk_vsid_data(ea, flags)),
> "r" (mk_esid_data(ea, entry))
Hopefully the compiler only calculates these once.
> @@ -77,6 +99,11 @@ void slb_flush_and_rebolt(void)
> if ((ksp_esid_data & ESID_MASK) == PAGE_OFFSET)
> ksp_esid_data &= ~SLB_ESID_V;
>
> + /* Only second entry may change here so only resave that */
> + slb_shadow_update(ksp_esid_data,
> + mk_vsid_data(ksp_esid_data, lflags),
> + 2);
> +
1) it's the third entry 2) it's the stack slot
> /* We need to do this all in asm, so we're sure we don't touch
> * the stack between the slbia and rebolting it. */
own line
> asm volatile("isync\n"
> Index: linux-2.6-ozlabs/arch/powerpc/platforms/pseries/lpar.c
> ===================================================================
> --- linux-2.6-ozlabs.orig/arch/powerpc/platforms/pseries/lpar.c
> +++ linux-2.6-ozlabs/arch/powerpc/platforms/pseries/lpar.c
> @@ -254,18 +254,32 @@ out:
> void vpa_init(int cpu)
> {
> int hwcpu = get_hard_smp_processor_id(cpu);
> - unsigned long vpa = __pa(&lppaca[cpu]);
> + unsigned long vpa;
This is used for something other than vpa, rename.
> long ret;
>
> if (cpu_has_feature(CPU_FTR_ALTIVEC))
> lppaca[cpu].vmxregs_in_use = 1;
>
> + vpa = __pa(&lppaca[cpu]);
> ret = register_vpa(hwcpu, vpa);
>
> - if (ret)
> + if (ret) {
> printk(KERN_ERR "WARNING: vpa_init: VPA registration for "
> "cpu %d (hw %d) of area %lx returns %ld\n",
> cpu, hwcpu, vpa, ret);
> + return;
> + }
> + /* PAPR says this feature is SLB-Buffer but firmware never
> + * reports that. All SPLPAR support SLB shadow buffer. */
own line
> + vpa = __pa(&slb_shadow_buffer[cpu]);
> + if (firmware_has_feature(FW_FEATURE_SPLPAR)) {
> + ret = register_slb_shadow(hwcpu, vpa);
> + if (ret)
> + printk(KERN_ERR
> + "WARNING: vpa_init: SLB shadow buffer "
> + "registration for cpu %d (hw %d) of area %lx "
> + "returns %ld\n", cpu, hwcpu, vpa, ret);
> + }
> }
>
> long pSeries_lpar_hpte_insert(unsigned long hpte_group,
...
> Index: linux-2.6-ozlabs/arch/powerpc/platforms/pseries/setup.c
> ===================================================================
> --- linux-2.6-ozlabs.orig/arch/powerpc/platforms/pseries/setup.c
> +++ linux-2.6-ozlabs/arch/powerpc/platforms/pseries/setup.c
> @@ -234,8 +234,16 @@ static void pseries_kexec_cpu_down_xics(
> {
> /* Don't risk a hypervisor call if we're crashing */
> if (firmware_has_feature(FW_FEATURE_SPLPAR) && !crash_shutdown) {
> - unsigned long vpa = __pa(get_lppaca());
> + unsigned long vpa;
Rename.
>
> + vpa = __pa(get_slb_shadow_buffer());
> + if (unregister_slb_shadow(hard_smp_processor_id(), vpa))
> + printk("SLB shadow buffer deregistration of "
> + "cpu %u (hw_cpu_id %d) failed\n",
> + smp_processor_id(),
> + hard_smp_processor_id());
> +
> + vpa = __pa(get_lppaca());
> if (unregister_vpa(hard_smp_processor_id(), vpa)) {
> printk("VPA deregistration of cpu %u (hw_cpu_id %d) "
> "failed\n", smp_processor_id(),
Side comment: this seems like it should be in pseeries/lpar.c, that would
be a seperate cleanup.
> Index: linux-2.6-ozlabs/include/asm-powerpc/lppaca.h
> ===================================================================
> --- linux-2.6-ozlabs.orig/include/asm-powerpc/lppaca.h
> +++ linux-2.6-ozlabs/include/asm-powerpc/lppaca.h
> @@ -28,6 +28,7 @@
> //
> //----------------------------------------------------------------------------
> #include <asm/types.h>
> +#include <asm/mmu.h>
>
> /* The Hypervisor barfs if the lppaca crosses a page boundary. A 1k
> * alignment is sufficient to prevent this */
> @@ -133,5 +134,19 @@ struct lppaca {
>
> extern struct lppaca lppaca[];
>
> +/* SLB shadow buffer structure as defined in the PAPR. The save_area
> + * contains adjacent ESID and VSID pairs for each shadowed SLB. The
> + * ESID is stored in the lower 64bits, then the VSID. NOTE: This
> + * structure is 0x40 bytes long (with 3 bolted SLBs), but PHYP
> + * complaints if we're not 0x80 (cache line?) aligned. */
Own line
Less explaination needed with array of structs.
> +struct slb_shadow_buffer {
> + u32 persistent; // Number of persistent SLBs x00-x03
> + u32 buffer_length; // Total shadow buffer length x04-x07
> + u64 reserved; // Alignment x08-x0f
> + u64 save_area[SLB_NUM_BOLTED * 2]; // x10-x40
> +} __attribute__((__aligned__(0x80)));
> +
> +extern struct slb_shadow_buffer slb_shadow_buffer[];
> +
Remove buffer from these names? They seem quite long for linux.
> #endif /* __KERNEL__ */
> #endif /* _ASM_POWERPC_LPPACA_H */
> Index: linux-2.6-ozlabs/include/asm-powerpc/paca.h
> ===================================================================
> --- linux-2.6-ozlabs.orig/include/asm-powerpc/paca.h
> +++ linux-2.6-ozlabs/include/asm-powerpc/paca.h
> @@ -23,6 +23,7 @@
> register struct paca_struct *local_paca asm("r13");
> #define get_paca() local_paca
> #define get_lppaca() (get_paca()->lppaca_ptr)
> +#define get_slb_shadow_buffer() (get_paca()->slb_shadow_buffer_ptr)
>
> struct task_struct;
>
> @@ -98,6 +99,9 @@ struct paca_struct {
> u64 user_time; /* accumulated usermode TB ticks */
> u64 system_time; /* accumulated system TB ticks */
> u64 startpurr; /* PURR/TB value snapshot */
> +
> + /* Pointer to SLB shadow buffer */
> + struct slb_shadow_buffer *slb_shadow_buffer_ptr;
> };
With the long name the comment doesn't add much.
>
> extern struct paca_struct paca[];
>
^ permalink raw reply
* Re: [PATCH] Fix powerpc 44x_mmu build
From: Josh Boyer @ 2006-08-05 1:12 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-dev
In-Reply-To: <20060804164401.GB4959@gate.crashing.org>
On Fri, 2006-08-04 at 11:44 -0500, Matt Porter wrote:
> The PIN_SIZE definition name changed, update 44x_mmu.c accordingly.
As far as I know, 4xx still builds as ARCH=ppc... is this patch just
something you noticed, or is it a hint that you're working on moving 4xx
to arch/powerpc?
Just curious, since I've been poking at this a bit and would rather not
duplicate effort.
josh
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Paul Mackerras @ 2006-08-04 23:29 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev, g.liakhovetski, Milton Miller
In-Reply-To: <20060804175418.GA28095@smtp.west.cox.net>
Tom Rini writes:
> But doesn't the representation include meaning?
No, in the sense that the device-tree representation doesn't define
what meaning or interpretation is to be given to particular node and
property names or to particular property values.
> I'll rephrase what I said to what I think we all agree. Changing
> existing fields meanings in incompatible ways and not somehow allowing
> that to still work (like by adding a flag so new trees are interpreted
> one way, old trees are fixed-up or whatever) is a problem.
Yes it's a problem. Not one that we want to solve by changing the dt
version number, though.
Paul.
^ permalink raw reply
* Re: ELDK 3.1.1 support for x86_64 host architecture
From: Ben Warren @ 2006-08-04 21:00 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Michael Carey, linuxppc-embedded
In-Reply-To: <20060804201127.00D2D352640@atlas.denx.de>
On Fri, 2006-08-04 at 22:11 +0200, Wolfgang Denk wrote:
> Yes, SuSE has always found interesting ways to break compatibility.
> That's why I avoid it. IIRC, SuSE provides a special tool "linux32"
> which has to be used to run 32-bit applications on a x86_64 system.
>
> Don't ask me why they need it. Other distros run the 32-bit
> applications just fine without such intricacy.
>
>
I don't know about SUSE, but to get ELDK 4.0 running on my Debian x86_64
server I had to install a package called 'ia32_libs'.
regards,
Ben
^ permalink raw reply
* Re: ELDK 3.1.1 support for x86_64 host architecture
From: Frank @ 2006-08-04 20:43 UTC (permalink / raw)
To: Wolfgang Denk, Michael Carey; +Cc: linuxppc-embedded
In-Reply-To: <20060804201127.00D2D352640@atlas.denx.de>
--- Wolfgang Denk <wd@denx.de> wrote:
> In message <44D22E43020000710000243E@webmail.nearfield.com>
> you wrote:
> > I found the subject "ELDK 3.1.1 support for x86_64 host
> architecture" in the archives (Apr 15 2005) which describes my
> problem, however there was never any posting of a resolution.
>
> There was none, as there is no problem. ELDK 3.1.1 (and
> later
> versions) runs fine on x86_64 hosts, assuming you're using
> any sane
> Linux distribution. For example:
>
> -> ppc_8xx-gcc -v
> Reading specs from
> /opt/eldk-3.1.1/usr/bin/../lib/gcc-lib/ppc-linux/3.3.3/specs
> Configured with: ../configure --prefix=/usr
> --mandir=/usr/share/man --infodir=/usr/share/info
> --enable-shared --enable-threads=posix --disable-checking
> --with-system-zlib --enable-__cxa_atexit --with-newlib
> --enable-languages=c,c++ --disable-libgcj
> --host=i386-redhat-linux --target=ppc-linux
> Thread model: posix
> gcc version 3.3.3 (DENX ELDK 3.1.1 3.3.3-9)
> ------------------------^^^^^^^^^^
There is something wrong with your Suse installation. I have
been using ELDK with Suse(9.2 and 10.1) since 2004 without any problems...
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: ELDK 3.1.1 support for x86_64 host architecture
From: Wolfgang Denk @ 2006-08-04 20:11 UTC (permalink / raw)
To: Michael Carey; +Cc: linuxppc-embedded
In-Reply-To: <44D22E43020000710000243E@webmail.nearfield.com>
In message <44D22E43020000710000243E@webmail.nearfield.com> you wrote:
> I found the subject "ELDK 3.1.1 support for x86_64 host architecture" in the archives (Apr 15 2005) which describes my problem, however there was never any posting of a resolution.
There was none, as there is no problem. ELDK 3.1.1 (and later
versions) runs fine on x86_64 hosts, assuming you're using any sane
Linux distribution. For example:
-> ppc_8xx-gcc -v
Reading specs from /opt/eldk-3.1.1/usr/bin/../lib/gcc-lib/ppc-linux/3.3.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --with-newlib --enable-languages=c,c++ --disable-libgcj --host=i386-redhat-linux --target=ppc-linux
Thread model: posix
gcc version 3.3.3 (DENX ELDK 3.1.1 3.3.3-9)
------------------------^^^^^^^^^^
-> uname -a
Linux pollux.denx.de 2.6.10-1.771_FC2smp #1 SMP Mon Mar 28 01:05:47 EST 2005 x86_64 x86_64 x86_64 GNU/Linux
-----------------------------------------------------------------------------^^^^^^
-> cat /etc/issue
Fedora Core release 2 (Tettnang)
...
> package rpm-4.1.1-1.8xa_10 is intended for a i386 architecture
Your Linux distro is kind of broken.
> The details on my system are:
...
> Welcome to SUSE LINUX 10.1 (X86-64) - Kernel \r (\l).
Yes, SuSE has always found interesting ways to break compatibility.
That's why I avoid it. IIRC, SuSE provides a special tool "linux32"
which has to be used to run 32-bit applications on a x86_64 system.
Don't ask me why they need it. Other distros run the 32-bit
applications just fine without such intricacy.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
There are very few personal problems that cannot be solved through a
suitable application of high explosives.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox