* Re: [PATCH] KVM: PPC: Add generic hpte management functions
From: Avi Kivity @ 2010-06-28 13:30 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc@vger.kernel.org
In-Reply-To: <4C28A2C1.50700@suse.de>
On 06/28/2010 04:25 PM, Alexander Graf wrote:
>>
>>>> Less and simpler code, better reporting through slabtop, less wastage
>>>> of partially allocated slab pages.
>>>>
>>>>
>>> But it also means that one VM can spill the global slab cache and kill
>>> another VM's mm performance, no?
>>>
>>>
>> What do you mean by spill?
>>
Well?
>> btw, in the midst of the nit-picking frenzy I forgot to ask how the
>> individual hash chain lengths as well as the per-vm allocation were
>> limited.
>>
>> On x86 we have a per-vm limit and we allow the mm shrinker to reduce
>> shadow mmu data structures dynamically.
>>
>>
> Very simple. I keep an int with the number of allocated entries around
> and if that hits a define'd threshold, I flush all shadow pages.
>
A truly nefarious guest will make all ptes hash to the same chain,
making some operations very long (O(n^2) in the x86 mmu, don't know
about ppc) under a spinlock. So we had to limit hash chains, not just
the number of entries.
But your mmu is per-cpu, no? In that case, no spinlock, and any damage
the guest does is limited to itself.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH] KVM: PPC: Add generic hpte management functions
From: Alexander Graf @ 2010-06-28 13:32 UTC (permalink / raw)
To: Avi Kivity; +Cc: linuxppc-dev, KVM list, kvm-ppc@vger.kernel.org
In-Reply-To: <4C28A409.9090207@redhat.com>
Avi Kivity wrote:
> On 06/28/2010 04:25 PM, Alexander Graf wrote:
>>>
>>>>> Less and simpler code, better reporting through slabtop, less wastage
>>>>> of partially allocated slab pages.
>>>>>
>>>>>
>>>> But it also means that one VM can spill the global slab cache and kill
>>>> another VM's mm performance, no?
>>>>
>>>>
>>> What do you mean by spill?
>>>
>
>
> Well?
I was thinking of a global capping, but I guess I could still do it
per-vcpu. So yes, doing a global slab doesn't hurt.
>
>>> btw, in the midst of the nit-picking frenzy I forgot to ask how the
>>> individual hash chain lengths as well as the per-vm allocation were
>>> limited.
>>>
>>> On x86 we have a per-vm limit and we allow the mm shrinker to reduce
>>> shadow mmu data structures dynamically.
>>>
>>>
>> Very simple. I keep an int with the number of allocated entries around
>> and if that hits a define'd threshold, I flush all shadow pages.
>>
>
> A truly nefarious guest will make all ptes hash to the same chain,
> making some operations very long (O(n^2) in the x86 mmu, don't know
> about ppc) under a spinlock. So we had to limit hash chains, not just
> the number of entries.
>
> But your mmu is per-cpu, no? In that case, no spinlock, and any
> damage the guest does is limited to itself.
Yes, it is. No locking. The vcpu can kill its own performance, but I
don't care about that.
Alex
^ permalink raw reply
* Re: BUG: scheduling while atomic: swapper/0/0x00000002
From: Paul E. McKenney @ 2010-06-28 16:49 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, paulus, anton
In-Reply-To: <20100610010854.GA11432@linux.vnet.ibm.com>
On Wed, Jun 09, 2010 at 06:08:54PM -0700, Paul E. McKenney wrote:
> On Thu, Jun 10, 2010 at 09:20:08AM +1000, Benjamin Herrenschmidt wrote:
> > On Wed, 2010-06-09 at 14:52 -0700, Paul E. McKenney wrote:
> > > Hello!
> > >
> > > I get the following during boot on a 16 CPU Power box. Thoughts?
> > > (/proc/config attached)
> >
> > Wow... looks like the preempt count of the idle task got busted or
> > something ... how reproduceable ? Something like a record of previous
> > interrupts might be useful..
>
> I have seen it only once, but it did get my attention. I will try running
> it again this evening when/if kernel-ml8 is free again. 2.6.35-rc2,
> I should have mentioned.
And it does appear to be reproducible perhaps 50% of boots running
CONFIG_PREEMPT on kernel-ml8. I have not yet seen it on any other system.
Do you have a patch to instrument the interrupts so as to get the info
you need, or should I improvise?
Thanx, Paul
^ permalink raw reply
* Re: of-flash: Unable to ioremap() both 128MB NOR flashes on 32-bit system with 2GB+ RAM
From: Kyle Moffett @ 2010-06-28 17:05 UTC (permalink / raw)
To: Milton Miller; +Cc: linux-mtd, linuxppc-dev
In-Reply-To: <1277709539_13309@mail4.comsite.net>
On Mon, Jun 28, 2010 at 03:18, Milton Miller <miltonm@bga.com> wrote:
> On Fri Jun 25 around 14:01:51 EST 2010 Kyle Moffett wrote:
>> I've got a new P2020 (32bit mpc85xx family) board I'm working on a
>> port for that includes 2 NOR flashes (128MB each) and a removable
>> SO-RDIMM of 2GB or 4GB. =C2=A0Unfortunately when I configure both flashe=
s
>> in the device-tree off my elbc, Linux is completely unable to access
>> the second one because it attempts to ioremap() the entire virtual
>> address space of both FLASH chips.
>>
>> Even with only one flash chip enabled, there's a bit of a noticeable
>> performance degradation because the mapping consumes almost all of my
>> available vmalloc space and forces bounce-buffering for all my
>> HIGHMEM.
>>
>> It looks like the "of-flash" driver currently requires that the whole
>> chip be mapped in the kernel at once. =C2=A0I would much rather have a 5=
0%
>> performance penalty on flash accesses (which are already very slow)
>> and regain most of the vmap space.
>>
>> So the question is, is there a way to convince the MTD layer to
>> iomap() only what it needs to access to do reads and writes? =C2=A0If no=
t,
>> what changes would need to be made to MTD and/or "of-flash" to create
>> such functionality?
>
> I believe the MTD layer would be happy, but it is beyond the scope of
> the physmap_of driver.
Well, I believe that the physmap_of driver is the correct place for
it; that driver is used by a large number of embedded PPC systems and
at present it is completely unable to handle some of the larger flash
memories currently being produced (256MByte+), and there's a decent
system-wide performance penalty (due to lack of ioremap space) even
for the larger flash memories which do function.
Cheers,
Kyle Moffett
^ permalink raw reply
* RE: JFFS2 corruption when mounting filesystem with filenamesoflength> 7
From: Steve Deiters @ 2010-06-28 21:25 UTC (permalink / raw)
To: linux-mtd; +Cc: linuxppc-dev
In-Reply-To: <181804936ABC2349BE503168465576460F20CB90@exchserver.basler.com>
> I think there may be something weird going on with the memcpy=20
> in my build. If I use the following patch I no longer get=20
> errors when I mount the filesystem. All I did was replace=20
> the memcpy with a loop.
>=20
> I'm not sure what's special about this particular use of=20
> memcpy. I can't believe that things would be working as well=20
> as they do if memcpy was broken in general.
>=20
> This is on a PowerPC 32 bit build for a MPC5121. I am using=20
> a GCC 4.1.2 to compile. Is anyone aware of any issues with=20
> memcpy in this configuration?
>=20
> Thanks.
It seems this processor is mangling the data when it access unaligned
addresses into Flash with a lwz instruction. The memcpy implementation
in copy_32.S aligns the destination, leaving the source possibly
unaligned. In this particular instance the source is an address into=
my
Flash address space which is causing the problem. When the filenames
were < 8 it always does a bytewise copy which is why I wasn't having
problems with those.
It seems this only occurs when I have the translation enabled. If I
clear the DR bit in the MSR and then repeat the instruction with the
corresponding physical address it will read correctly.
I'm not sure if this is expected behavior with this core. I can fix at
least this one problem by using memcpy_fromio since it does alignment
checks for the source and destination.
I'm not sure what the proper fix is for this. If I use memcpy_fromio=
I
think I'll just run into problems somewhere else. Any other
suggestions?
Thanks.
^ permalink raw reply
* Re: BUG: scheduling while atomic: swapper/0/0x00000002
From: Benjamin Herrenschmidt @ 2010-06-28 21:29 UTC (permalink / raw)
To: paulmck; +Cc: linuxppc-dev, paulus, anton
In-Reply-To: <20100628164906.GA6667@linux.vnet.ibm.com>
On Mon, 2010-06-28 at 09:49 -0700, Paul E. McKenney wrote:
> And it does appear to be reproducible perhaps 50% of boots running
> CONFIG_PREEMPT on kernel-ml8. I have not yet seen it on any other
> system.
> Do you have a patch to instrument the interrupts so as to get the info
> you need, or should I improvise?
ftrace & friends ?
I don't have anything existing in mind...
Cheers,
Ben.
^ permalink raw reply
* Re: JFFS2 corruption when mounting filesystem with filenamesoflength> 7
From: Wolfgang Denk @ 2010-06-28 22:30 UTC (permalink / raw)
To: Steve Deiters; +Cc: linuxppc-dev, linux-mtd
In-Reply-To: <181804936ABC2349BE503168465576460F20D651@exchserver.basler.com>
Dear "Steve Deiters",
In message <181804936ABC2349BE503168465576460F20D651@exchserver.basler.com> you wrote:
> > I think there may be something weird going on with the memcpy
> > in my build. If I use the following patch I no longer get
> > errors when I mount the filesystem. All I did was replace
> > the memcpy with a loop.
> >
> > I'm not sure what's special about this particular use of
> > memcpy. I can't believe that things would be working as well
> > as they do if memcpy was broken in general.
> >
> > This is on a PowerPC 32 bit build for a MPC5121. I am using
> > a GCC 4.1.2 to compile. Is anyone aware of any issues with
> > memcpy in this configuration?
> >
> > Thanks.
>
> It seems this processor is mangling the data when it access unaligned
> addresses into Flash with a lwz instruction. The memcpy implementation
> in copy_32.S aligns the destination, leaving the source possibly
> unaligned. In this particular instance the source is an address into my
> Flash address space which is causing the problem. When the filenames
> were < 8 it always does a bytewise copy which is why I wasn't having
> problems with those.
>
> It seems this only occurs when I have the translation enabled. If I
> clear the DR bit in the MSR and then repeat the instruction with the
> corresponding physical address it will read correctly.
>
> I'm not sure if this is expected behavior with this core. I can fix at
> least this one problem by using memcpy_fromio since it does alignment
> checks for the source and destination.
Both the MPC52xx and MPC512x have know problems (silent data
corruption) with unaligned accesses on the local bus.
This can be trivially demonstrated in U-Boot by reading the flash
memory with 32 bit accesses; for example like this:
=> md FC0C0000 20
fc0c0000: 7012ab65 01616464 636f6e73 3d736574 p..e.addcons=set
fc0c0010: 656e7620 626f6f74 61726773 20247b62 env bootargs ${b
fc0c0020: 6f6f7461 7267737d 20636f6e 736f6c65 ootargs} console
fc0c0030: 3d247b63 6f6e736f 6c657d2c 247b6261 =${console},${ba
fc0c0040: 75647261 74657d00 61646469 703d7365 udrate}.addip=se
fc0c0050: 74656e76 20626f6f 74617267 7320247b tenv bootargs ${
fc0c0060: 626f6f74 61726773 7d206970 3d247b69 bootargs} ip=${i
fc0c0070: 70616464 727d3a24 7b736572 76657269 paddr}:${serveri
=> md FC0C0001 20
fc0c0001: 65726901 00000063 0000003d 00000065 eri....c...=...e
fc0c0011: 00000062 00000061 00000020 0000006f ...b...a... ...o
fc0c0021: 00000072 00000020 00000073 0000003d ...r... ...s...=
fc0c0031: 0000006f 0000006c 00000024 00000075 ...o...l...$...u
fc0c0041: 00000074 00000061 00000070 00000074 ...t...a...p...t
fc0c0051: 00000020 00000074 00000073 00000062 ... ...t...s...b
fc0c0061: 00000061 0000007d 0000003d 00000070 ...a...}...=...p
fc0c0071: 00000072 0000007b 00000076 00000070 ...r...{...v...p
> I'm not sure what the proper fix is for this. If I use memcpy_fromio I
> think I'll just run into problems somewhere else. Any other
> suggestions?
See http://article.gmane.org/gmane.comp.boot-loaders.u-boot/80278 for
how we fix this in U-Boot.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"On two occasions I have been asked [by members of Parliament!],
'Pray, Mr. Babbage, if you put into the machine wrong figures, will
the right answers come out?' I am not able rightly to apprehend the
kind of confusion of ideas that could provoke such a question."
- Charles Babbage
^ permalink raw reply
* Re: [PATCH 39/40] trace syscalls: Clean confusing {s, r, }name and fix ABI breakage
From: Ian Munsie @ 2010-06-29 1:02 UTC (permalink / raw)
To: Jason Baron
Cc: Jesper Nilsson, Frederic Weisbecker, linux-kernel, Steven Rostedt,
Christoph Hellwig, linuxppc-dev, Ingo Molnar, Paul Mackerras,
Ingo Molnar, Andrew Morton
In-Reply-To: <20100623180353.GB2680@redhat.com>
Excerpts from Jason Baron's message of Thu Jun 24 04:03:54 +1000 2010:
> overall this patch is a major improvement! My question though is
> about the naming of the compat syscalls in the context of events. I
> believe this patch differeniates compat syscall event names as:
> "sys32_enter_sname", and "compat_sys_enter_sname". I agree that we keep that
> distinction for purposes of defining the actual syscall function. However,
> we had discuessed previously about keeping the event name the same for
> all compat syscalls. ie they are all called "compat_sys_sname" or some
> such. Reason being you could just do "compat_*" to match all compat
> events.
Sorry for the delay in replying - I've been pretty busy with other work
over the last few days.
I can certainly change that to name them all compat_sys to be more
consistent. In terms of activating all of them at once that can still be
done fairly easily since they are in their own compat_sys category with
something like "perf record -e 'compat_syscalls:*' ..." or "echo 1 >
/sys/kernel/debug/tracing/events/compat_syscalls/enable".
Ideally I would actually like to consolidate these events with the
ordinary syscall events and just print out compat=0|1 as part of their
output.
Since many of the native syscalls are used as compat syscalls as well I
think that would make a whole lot more sense - at the moment to catch
all syscalls from a compat process both the compat and native syscalls
would need to be activated.
It would also have the benefit of removing any arch specific naming from
userspace, which would make things a lot nicer.
Cheers,
-Ian
^ permalink raw reply
* Re: [PATCH 01/40] ftrace syscalls: don't add events for unmapped syscalls
From: Ian Munsie @ 2010-06-29 1:18 UTC (permalink / raw)
To: Steven Rostedt
Cc: Frederic Weisbecker, Jason Baron, linux-kernel, linuxppc-dev,
Ingo Molnar, Paul Mackerras, Ingo Molnar, Masami Hiramatsu
In-Reply-To: <1277305339.9181.33.camel@gandalf.stny.rr.com>
Excerpts from Steven Rostedt's message of Thu Jun 24 01:02:19 +1000 2010:
> > diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
> > index 34e3580..82246ce 100644
> > --- a/kernel/trace/trace_syscalls.c
> > +++ b/kernel/trace/trace_syscalls.c
> > @@ -431,6 +431,14 @@ void unreg_event_syscall_exit(struct ftrace_event_call *call)
> > int init_syscall_trace(struct ftrace_event_call *call)
> > {
> > int id;
> > + int num;
> > +
> > + num = ((struct syscall_metadata *)call->data)->syscall_nr;
> > + if (num < 0 || num >= NR_syscalls) {
> > + pr_debug("syscall %s metadata not mapped, disabling ftrace event\n",
> > + ((struct syscall_metadata *)call->data)->name);
> > + return -ENOSYS;
> > + }
>
> Perhaps this should be:
>
> if (WARN_ON_ONCE(num < 0 || num >= NR_syscalls)
> return -ENOSYS;
>
> -- Steve
Hi Steven,
I don't think this should produce a warning - it signifies that a
syscall defined in the code has not successfully matched a syscall at
boot.
That may signify the matching failed, but it may just as likely signify
that the syscall isn't used on that arch (for instance, if an arch uses
an arch specific implementation in favour of a generic implementation,
or doesn't implement a particular syscall at all that is defined in the
generic code).
The problem case is actually the other way around - when a syscall
number from an arch's syscall table has not successfully mapped to some
syscall meta-data. Patch #37 prints out those cases with KERN_DEBUG so
booting a kernel with loglevel=8 can track them down.
This pr_debug may still be useful, for example to help locate unused
syscalls which can be removed if no arch uses them.
Cheers,
-Ian
^ permalink raw reply
* Re: [PATCH]460EX on-chip SATA driver<kernel 2.6.33><resubmission>
From: Marek Vasut @ 2010-06-29 1:33 UTC (permalink / raw)
To: Rupjyoti Sarmah; +Cc: linux-ide, sr, jgarzik, linux-kernel, linuxppc-dev
In-Reply-To: <201006041226.o54CQH2V017366@amcc.com>
Dne P=C3=A1 4. =C4=8Dervna 2010 14:26:17 Rupjyoti Sarmah napsal(a):
> This patch enables the on-chip DWC SATA controller of the AppliedMicro
> processor 460EX.
>=20
> Signed-off-by: Rupjyoti Sarmah <rsarmah@appliedmicro.com>
> Signed-off-by: Mark Miesfeld <mmiesfeld@appliedmicro.com>
> Signed-off-by: Prodyut Hazarika <phazarika@appliedmicro.com>
>=20
=2D-SNIP--
> + dev_err(ap->dev, "%s: Command not pending cmd_issued=3D%d "
> + "(tag=3D%d) DMA NOT started\n", __func__,
> + hsdevp->cmd_issued[tag], tag);
Just a nitpick, but don't break strings if possible.
^ permalink raw reply
* [PATCH] sched: fix spelling of sibling
From: Michael Neuling @ 2010-06-29 2:02 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: linuxppc-dev, Ingo Molnar, linux-kernel
No logic changes, only spelling.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
arch/powerpc/kernel/process.c | 2 +-
include/linux/topology.h | 2 +-
kernel/sched_fair.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
Index: linux-tip/arch/powerpc/kernel/process.c
===================================================================
--- linux-tip.orig/arch/powerpc/kernel/process.c
+++ linux-tip/arch/powerpc/kernel/process.c
@@ -1270,7 +1270,7 @@ unsigned long randomize_et_dyn(unsigned
}
#ifdef CONFIG_SMP
-int arch_sd_sibiling_asym_packing(void)
+int arch_sd_sibling_asym_packing(void)
{
if (cpu_has_feature(CPU_FTR_ASYM_SMT)) {
printk_once(KERN_INFO "Enabling Asymmetric SMT scheduling\n");
Index: linux-tip/include/linux/topology.h
===================================================================
--- linux-tip.orig/include/linux/topology.h
+++ linux-tip/include/linux/topology.h
@@ -103,7 +103,7 @@ int arch_update_cpu_topology(void);
| 1*SD_SHARE_PKG_RESOURCES \
| 0*SD_SERIALIZE \
| 0*SD_PREFER_SIBLING \
- | arch_sd_sibiling_asym_packing() \
+ | arch_sd_sibling_asym_packing() \
, \
.last_balance = jiffies, \
.balance_interval = 1, \
Index: linux-tip/kernel/sched_fair.c
===================================================================
--- linux-tip.orig/kernel/sched_fair.c
+++ linux-tip/kernel/sched_fair.c
@@ -2567,7 +2567,7 @@ static inline void update_sd_lb_stats(st
} while (sg != sd->groups);
}
-int __weak arch_sd_sibiling_asym_packing(void)
+int __weak arch_sd_sibling_asym_packing(void)
{
return 0*SD_ASYM_PACKING;
}
^ permalink raw reply
* Re: Using devices trees on X86
From: Stephen Rothwell @ 2010-06-29 2:38 UTC (permalink / raw)
To: Stephen Neuendorffer
Cc: Michal Simek, microblaze-uclinux, devicetree-discuss,
Paul Mackerras, sparclinux, linuxppc-dev, David Miller
In-Reply-To: <0bcc23b9-2cbd-4465-b17c-7b3c2dff9fd3@VA3EHSMHS007.ehs.local>
[-- Attachment #1: Type: text/plain, Size: 1054 bytes --]
Hi Stephen,
On Mon, 28 Jun 2010 10:57:33 -0700 Stephen Neuendorffer <stephen.neuendorffer@xilinx.com> wrote:
>
> 2) config OF is currently implemented in the architecture code. This
> should be non-architecture dependent and selected by the arches that
> need it.
>
> Comments greatly appreciated, in particular if you have
> likely-to-be-easy-to-get-accepted suggestions for 3), or feel like
> carefully solving 2) in
> a way which doesn't bork the existing of-based arches.
See the following patch set. Parts 1, 2 and 3 could be applied to the
respective architecture trees as well as Grant's tree to aleviate some
conflict problems. Part 5 could wait until a later time if necessary.
However, this is relatively trivial, so we could just collect ACKs and
put it all in Grant's tree and live with any minor pain.
Having OF in more than one Kconfig file should not cause any problems as
long as they are all the same.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [PATCH 1/5] microblaze: turn CONFIG_OF into a select
From: Stephen Rothwell @ 2010-06-29 2:42 UTC (permalink / raw)
To: Michal Simek, microblaze-uclinux
Cc: David Miller, Paul Mackerras, sparclinux, linuxppc-dev,
devicetree-discuss
In-Reply-To: <20100629123843.5f94d477.sfr@canb.auug.org.au>
so that we can make CONFIG_OF global and remove it from
the architecture Kconfig files later.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/microblaze/Kconfig | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index 76818f9..2b37820 100644
--- a/arch/microblaze/Kconfig
+++ b/arch/microblaze/Kconfig
@@ -17,6 +17,8 @@ config MICROBLAZE
select HAVE_DMA_ATTRS
select HAVE_DMA_API_DEBUG
select TRACING_SUPPORT
+ select OF
+ select OF_FLATTREE
config SWAP
def_bool n
@@ -125,8 +127,7 @@ config CMDLINE_FORCE
override those passed by the boot loader.
config OF
- def_bool y
- select OF_FLATTREE
+ bool
config PROC_DEVICETREE
bool "Support for device tree in /proc"
--
1.7.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* [PATCH 2/5] powerpc: turn CONFIG_OF into a select
From: Stephen Rothwell @ 2010-06-29 2:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, linuxppc-dev
Cc: Michal Simek, microblaze-uclinux, David Miller, sparclinux,
devicetree-discuss
In-Reply-To: <20100629123843.5f94d477.sfr@canb.auug.org.au>
so that we can make CONFIG_OF global and remove it from
the architecture Kconfig files later.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/Kconfig | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 328774b..3697231 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -120,6 +120,8 @@ config ARCH_NO_VIRT_TO_BUS
config PPC
bool
default y
+ select OF
+ select OF_FLATTREE
select HAVE_FTRACE_MCOUNT_RECORD
select HAVE_DYNAMIC_FTRACE
select HAVE_FUNCTION_TRACER
@@ -173,8 +175,7 @@ config PPC_OF
def_bool y
config OF
- def_bool y
- select OF_FLATTREE
+ bool
config PPC_UDBG_16550
bool
--
1.7.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* [PATCH 3/5] sparc: turn CONFIG_OF into a select
From: Stephen Rothwell @ 2010-06-29 2:44 UTC (permalink / raw)
To: David Miller, sparclinux
Cc: Michal Simek, Paul Mackerras, microblaze-uclinux, linuxppc-dev,
devicetree-discuss
In-Reply-To: <20100629123843.5f94d477.sfr@canb.auug.org.au>
so that we can make CONFIG_OF global and remove it from
the architecture Kconfig files later.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/sparc/Kconfig | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 6f1470b..d02e8ac 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -18,6 +18,7 @@ config 64BIT
config SPARC
bool
default y
+ select OF
select HAVE_IDE
select HAVE_OPROFILE
select HAVE_ARCH_KGDB if !SMP || SPARC64
@@ -149,7 +150,7 @@ config ARCH_NO_VIRT_TO_BUS
def_bool y
config OF
- def_bool y
+ bool
config ARCH_SUPPORTS_DEBUG_PAGEALLOC
def_bool y if SPARC64
--
1.7.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* [PATCH 4/5] of: define CONFIG_OF globally so architectures can select it
From: Stephen Rothwell @ 2010-06-29 2:45 UTC (permalink / raw)
To: Grant Likely
Cc: Michal Simek, microblaze-uclinux, David Miller, Paul Mackerras,
sparclinux, linuxppc-dev, devicetree-discuss
In-Reply-To: <20100629123843.5f94d477.sfr@canb.auug.org.au>
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/of/Kconfig | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index 7cecc8f..1678dbc 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -1,3 +1,6 @@
+config OF
+ bool
+
config OF_FLATTREE
bool
depends on OF
--
1.7.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* [PATCH 5/5] of: remove architecture CONFIG_OF definitions
From: Stephen Rothwell @ 2010-06-29 2:47 UTC (permalink / raw)
To: Grant Likely
Cc: Michal Simek, microblaze-uclinux, David Miller, Paul Mackerras,
sparclinux, linuxppc-dev, devicetree-discuss
In-Reply-To: <20100629123843.5f94d477.sfr@canb.auug.org.au>
now that CONFIG_OF is defined globally
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/microblaze/Kconfig | 3 ---
arch/powerpc/Kconfig | 3 ---
arch/sparc/Kconfig | 3 ---
3 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/arch/microblaze/Kconfig b/arch/microblaze/Kconfig
index 2b37820..1a8f682 100644
--- a/arch/microblaze/Kconfig
+++ b/arch/microblaze/Kconfig
@@ -126,9 +126,6 @@ config CMDLINE_FORCE
Set this to have arguments from the default kernel command string
override those passed by the boot loader.
-config OF
- bool
-
config PROC_DEVICETREE
bool "Support for device tree in /proc"
depends on PROC_FS
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 3697231..402f4c0 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -174,9 +174,6 @@ config ARCH_MAY_HAVE_PC_FDC
config PPC_OF
def_bool y
-config OF
- bool
-
config PPC_UDBG_16550
bool
default n
diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index d02e8ac..13a9f2f 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -149,9 +149,6 @@ config GENERIC_GPIO
config ARCH_NO_VIRT_TO_BUS
def_bool y
-config OF
- bool
-
config ARCH_SUPPORTS_DEBUG_PAGEALLOC
def_bool y if SPARC64
--
1.7.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: [PATCH 3/5] sparc: turn CONFIG_OF into a select
From: David Miller @ 2010-06-29 3:11 UTC (permalink / raw)
To: sfr
Cc: monstr, microblaze-uclinux, paulus, sparclinux, linuxppc-dev,
devicetree-discuss
In-Reply-To: <20100629124450.5e85bafe.sfr@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 29 Jun 2010 12:44:50 +1000
> so that we can make CONFIG_OF global and remove it from
> the architecture Kconfig files later.
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: Using devices trees on X86
From: Grant Likely @ 2010-06-29 5:56 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Michal Simek, microblaze-uclinux, David Miller, Paul Mackerras,
sparclinux, linuxppc-dev, devicetree-discuss
In-Reply-To: <20100629123843.5f94d477.sfr@canb.auug.org.au>
On Mon, Jun 28, 2010 at 7:38 PM, Stephen Rothwell <sfr@canb.auug.org.au> wr=
ote:
> Hi Stephen,
>
> On Mon, 28 Jun 2010 10:57:33 -0700 Stephen Neuendorffer <stephen.neuendor=
ffer@xilinx.com> wrote:
>>
>> 2) config OF is currently implemented in the architecture code. =A0This
>> should be non-architecture dependent and selected by the arches that
>> need it.
>>
>> Comments greatly appreciated, in particular if you have
>> likely-to-be-easy-to-get-accepted suggestions for 3), or feel like
>> carefully solving 2) in
>> a way which doesn't bork the existing of-based arches.
>
> See the following patch set. =A0Parts 1, 2 and 3 could be applied to the
> respective architecture trees as well as Grant's tree to aleviate some
> conflict problems. =A0Part 5 could wait until a later time if necessary.
> However, this is relatively trivial, so we could just collect ACKs and
> put it all in Grant's tree and live with any minor pain.
>
> Having OF in more than one Kconfig file should not cause any problems as
> long as they are all the same.
I've got an Ack from David now. I'll wait for more acks, and then
pull the whole series of 5 into my devicetree-next branch. It's
certainly less invasive that some of the other changes arch changes
I've taken through my tree.
g.
^ permalink raw reply
* Re: Using devices trees on X86
From: Stephen Rothwell @ 2010-06-29 6:02 UTC (permalink / raw)
To: Grant Likely
Cc: Michal Simek, microblaze-uclinux, David Miller, Paul Mackerras,
sparclinux, linuxppc-dev, devicetree-discuss
In-Reply-To: <AANLkTikEJluwUSTmG64jgQYAt_8YI7-gVA2iqOPKrM9W@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 697 bytes --]
Hi Grant,
On Mon, 28 Jun 2010 22:56:14 -0700 Grant Likely <grant.likely@secretlab.ca> wrote:
>
> I've got an Ack from David now. I'll wait for more acks, and then
> pull the whole series of 5 into my devicetree-next branch. It's
> certainly less invasive that some of the other changes arch changes
> I've taken through my tree.
Yes, certainly. However, I have a plan to write a series of patches for
PowerPC that may clash some what, so if that is the case, I might ask Ben
to take the one patch as well. Especially if the conflict turns up in
linux-next :-)
Thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [PATCH] powerpc: fix feature-fixup tests for gcc 4.5
From: Stephen Rothwell @ 2010-06-29 7:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: ppc-dev
The feature-fixup test declare some extern void variables and then take
their addresses. Fix this by declaring them as extern u8 instead.
Fixes these warnings (treated as errors):
CC arch/powerpc/lib/feature-fixups.o
cc1: warnings being treated as errors
arch/powerpc/lib/feature-fixups.c: In function 'test_cpu_macros':
arch/powerpc/lib/feature-fixups.c:293:23: error: taking address of expression of type 'void'
arch/powerpc/lib/feature-fixups.c:294:9: error: taking address of expression of type 'void'
arch/powerpc/lib/feature-fixups.c:297:2: error: taking address of expression of type 'void'
arch/powerpc/lib/feature-fixups.c:297:2: error: taking address of expression of type 'void'
arch/powerpc/lib/feature-fixups.c: In function 'test_fw_macros':
arch/powerpc/lib/feature-fixups.c:306:23: error: taking address of expression of type 'void'
arch/powerpc/lib/feature-fixups.c:307:9: error: taking address of expression of type 'void'
arch/powerpc/lib/feature-fixups.c:310:2: error: taking address of expression of type 'void'
arch/powerpc/lib/feature-fixups.c:310:2: error: taking address of expression of type 'void'
arch/powerpc/lib/feature-fixups.c: In function 'test_lwsync_macros':
arch/powerpc/lib/feature-fixups.c:321:23: error: taking address of expression of type 'void'
arch/powerpc/lib/feature-fixups.c:322:9: error: taking address of expression of type 'void'
arch/powerpc/lib/feature-fixups.c:326:3: error: taking address of expression of type 'void'
arch/powerpc/lib/feature-fixups.c:326:3: error: taking address of expression of type 'void'
arch/powerpc/lib/feature-fixups.c:329:3: error: taking address of expression of type 'void'
arch/powerpc/lib/feature-fixups.c:329:3: error: taking address of expression of type 'void'
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/lib/feature-fixups.c | 17 +++++++++--------
1 files changed, 9 insertions(+), 8 deletions(-)
I haven't actually booted this, just built it.
diff --git a/arch/powerpc/lib/feature-fixups.c b/arch/powerpc/lib/feature-fixups.c
index e640175..0d08d01 100644
--- a/arch/powerpc/lib/feature-fixups.c
+++ b/arch/powerpc/lib/feature-fixups.c
@@ -12,6 +12,7 @@
* 2 of the License, or (at your option) any later version.
*/
+#include <linux/types.h>
#include <linux/kernel.h>
#include <linux/string.h>
#include <linux/init.h>
@@ -288,8 +289,8 @@ static void test_alternative_case_with_external_branch(void)
static void test_cpu_macros(void)
{
- extern void ftr_fixup_test_FTR_macros;
- extern void ftr_fixup_test_FTR_macros_expected;
+ extern u8 ftr_fixup_test_FTR_macros;
+ extern u8 ftr_fixup_test_FTR_macros_expected;
unsigned long size = &ftr_fixup_test_FTR_macros_expected -
&ftr_fixup_test_FTR_macros;
@@ -301,8 +302,8 @@ static void test_cpu_macros(void)
static void test_fw_macros(void)
{
#ifdef CONFIG_PPC64
- extern void ftr_fixup_test_FW_FTR_macros;
- extern void ftr_fixup_test_FW_FTR_macros_expected;
+ extern u8 ftr_fixup_test_FW_FTR_macros;
+ extern u8 ftr_fixup_test_FW_FTR_macros_expected;
unsigned long size = &ftr_fixup_test_FW_FTR_macros_expected -
&ftr_fixup_test_FW_FTR_macros;
@@ -314,10 +315,10 @@ static void test_fw_macros(void)
static void test_lwsync_macros(void)
{
- extern void lwsync_fixup_test;
- extern void end_lwsync_fixup_test;
- extern void lwsync_fixup_test_expected_LWSYNC;
- extern void lwsync_fixup_test_expected_SYNC;
+ extern u8 lwsync_fixup_test;
+ extern u8 end_lwsync_fixup_test;
+ extern u8 lwsync_fixup_test_expected_LWSYNC;
+ extern u8 lwsync_fixup_test_expected_SYNC;
unsigned long size = &end_lwsync_fixup_test -
&lwsync_fixup_test;
--
1.7.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
^ permalink raw reply related
* Re: [PATCH 11/26] KVM: PPC: Make RMO a define
From: Segher Boessenkool @ 2010-06-29 7:32 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc@vger.kernel.org
In-Reply-To: <9B84B663-7DC6-4543-96F7-23F77106065C@suse.de>
>>> On PowerPC it's very normal to not support all of the physical
>>> RAM in real mode.
>>
>> Oh? Are you referring to "real mode limit", or 32-bit
>> implementations with
>> more than 32 address lines, or something else?
>
> The former.
Okay. In that case, the hypervisor can usually access all of physical
ram directly, unless it limits itself; and a supervisor gets either
no real mode access, or all ram, or some part -- whatever the hypervisor
likes.
If you access outside of ram, you will most likely get a machine check.
Depends on the implementation (like most things here).
>> Either way, RMO is a really bad name for this, since that name is
>> already
>> used for a similar but different concept.
>
> It's the same concept, no? Not all physical memory is accessible
> from real mode.
I think you're looking for "real mode limit":
The concept is called "offset real mode".
RMO ("real mode offset") is the value that is ORed to an effective
address
to make the physical address (not added, "offset" is a pretty bad name).
RML ("real mode limit") is the value that has to be bigger than the
effective
address or you will get an exception.
RMA ("real mode area") is the name for the range of addresses usable
in offset
real mode.
>> Also, it seems you construct the physical address by masking out
>> bits from
>> the effective address. Most implementations will trap or machine
>> check if
>> you address outside of physical address space, instead.
>
> Well the only case where I remember to have hit a real RMO case is
> on the PS3 - that issues a data/instruction storage interrupt when
> accessing anything > 8MB in real mode.
>
> So I'd argue this is heavily implementation specific.
It is. So what is the behaviour you want to implement?
> Apart from that what I'm trying to cover is that on ppc64 accessing
> 0xc0000000000000 in real mode gets you 0x0. Is there a better name
> for this?
(You missed two zeroes).
In hypervisor real mode, the top few bits are magic. They are used
for e.g.
enabling hypervisor offset real mode.
In supervisor real mode, those bits are ignored (and all other bits
that do
not correspond to physical address lines may also be ignored).
Maybe you want to call it physical_address_mask or similar?
Segher
^ permalink raw reply
* Re: [PATCH 24/26] KVM: PPC: PV mtmsrd L=0 and mtmsr
From: Segher Boessenkool @ 2010-06-29 7:37 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc@vger.kernel.org
In-Reply-To: <05E77C6E-7465-4A0E-B00B-F1240417281D@suse.de>
>>> There is also a form of mtmsr where all bits need to be
>>> addressed. While the
>>> PPC64 Linux kernel behaves resonably well here, the PPC32 one
>>> never uses the
>>> L=1 form but does mtmsr even for simple things like only changing
>>> EE.
>>
>> You make it sound like the 32-bit kernel does something stupid, while
>> there is no other choice. The "L=1" thing only exists for 64-bit.
>
> Oh, so that's why :). That doesn't really change the fact that it's
> very hard to distinguish between a mtmsr that only changes MSR_EE
> vs one that changes MSR_IR for example :).
Hard to predict for the CPU as well, guess why there is a separate
instruction now :-P
By the way, L=1 _does_ exist for mtmsr; it's just that no 32-bit
"classic"
implementations support it.
Segher
^ permalink raw reply
* Re: [PATCH 11/26] KVM: PPC: Make RMO a define
From: Alexander Graf @ 2010-06-29 7:39 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, KVM list, kvm-ppc@vger.kernel.org
In-Reply-To: <07830DA6-1B53-4E84-A0E2-8449289C71F1@kernel.crashing.org>
On 29.06.2010, at 09:32, Segher Boessenkool wrote:
>>>> On PowerPC it's very normal to not support all of the physical RAM =
in real mode.
>>>=20
>>> Oh? Are you referring to "real mode limit", or 32-bit =
implementations with
>>> more than 32 address lines, or something else?
>>=20
>> The former.
>=20
> Okay. In that case, the hypervisor can usually access all of physical
> ram directly, unless it limits itself; and a supervisor gets either
> no real mode access, or all ram, or some part -- whatever the =
hypervisor
> likes.
>=20
> If you access outside of ram, you will most likely get a machine =
check.
> Depends on the implementation (like most things here).
>=20
>>> Either way, RMO is a really bad name for this, since that name is =
already
>>> used for a similar but different concept.
>>=20
>> It's the same concept, no? Not all physical memory is accessible from =
real mode.
>=20
> I think you're looking for "real mode limit":
>=20
> The concept is called "offset real mode".
>=20
> RMO ("real mode offset") is the value that is ORed to an effective =
address
> to make the physical address (not added, "offset" is a pretty bad =
name).
> RML ("real mode limit") is the value that has to be bigger than the =
effective
> address or you will get an exception.
> RMA ("real mode area") is the name for the range of addresses usable =
in offset
> real mode.
>=20
>>> Also, it seems you construct the physical address by masking out =
bits from
>>> the effective address. Most implementations will trap or machine =
check if
>>> you address outside of physical address space, instead.
>>=20
>> Well the only case where I remember to have hit a real RMO case is on =
the PS3 - that issues a data/instruction storage interrupt when =
accessing anything > 8MB in real mode.
>>=20
>> So I'd argue this is heavily implementation specific.
>=20
> It is. So what is the behaviour you want to implement?
The one below.
>=20
>> Apart from that what I'm trying to cover is that on ppc64 accessing =
0xc0000000000000 in real mode gets you 0x0. Is there a better name for =
this?
>=20
> (You missed two zeroes).
> In hypervisor real mode, the top few bits are magic. They are used =
for e.g.
> enabling hypervisor offset real mode.
> In supervisor real mode, those bits are ignored (and all other bits =
that do
> not correspond to physical address lines may also be ignored).
So which bits exactly are reserved? I couldn't find a reference to that =
part.
> Maybe you want to call it physical_address_mask or similar?
PAM - doesn't sound bad :).
Alex
^ permalink raw reply
* Re: [PATCH 11/26] KVM: PPC: Make RMO a define
From: Segher Boessenkool @ 2010-06-29 7:52 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, KVM list, kvm-ppc@vger.kernel.org
In-Reply-To: <182AF505-54A6-4F71-AF5D-7CA40D911C35@suse.de>
>>>> Also, it seems you construct the physical address by masking out
>>>> bits from
>>>> the effective address. Most implementations will trap or
>>>> machine check if
>>>> you address outside of physical address space, instead.
>>>
>>> Well the only case where I remember to have hit a real RMO case
>>> is on the PS3 - that issues a data/instruction storage interrupt
>>> when accessing anything > 8MB in real mode.
>>>
>>> So I'd argue this is heavily implementation specific.
>>
>> It is. So what is the behaviour you want to implement?
>
> The one below.
I'm sorry, I lost it. "Below"?
>>> Apart from that what I'm trying to cover is that on ppc64
>>> accessing 0xc0000000000000 in real mode gets you 0x0. Is there a
>>> better name for this?
>>
>> (You missed two zeroes).
>> In hypervisor real mode, the top few bits are magic. They are
>> used for e.g.
>> enabling hypervisor offset real mode.
>> In supervisor real mode, those bits are ignored (and all other
>> bits that do
>> not correspond to physical address lines may also be ignored).
>
> So which bits exactly are reserved? I couldn't find a reference to
> that part.
If by "reserved" you mean "cannot be used for addressing", it's the
top four
bits. Book III-S chapter 5.7.3 in the Power Architecture 2.06 document.
Implementations are allowed to ignore more bits than that.
I believe in earlier versions of the architecture it was the top two
bits,
not four, but maybe I misremember.
>> Maybe you want to call it physical_address_mask or similar?
>
> PAM - doesn't sound bad :).
And miraculously nothing in the Power arch uses that acronym yet! But I
would spell it out if I were you, acronyms are confusing.
Segher
^ 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