* Re: [Suggestion] PowerPC: kernel: cross compiling issue with allmodconfig
From: Chen Gang @ 2013-03-21 5:55 UTC (permalink / raw)
To: Michael Neuling, Benjamin Herrenschmidt
Cc: sfr, matt, linux-kernel@vger.kernel.org, paulus@samba.org,
imunsie, linuxppc-dev
In-Reply-To: <5142AE27.7060003@asianux.com>
Hello All:
summary:
the root cause is no enough room in exception area (0x5500 -- 0x7000).
it is caused by the patches "for saving/restre PPR":
they consumed much space of this area (0x5500 -- 0x7000).
for pseries_defconfig and ppc64_defconfig, it is still ok.
but for allmodconfig and "some additional config", it will cause issue.
the solving patch "Make room in exception vector area" can make room larger.
it can let "some additional config" ok.
but for allmodconfig, it is still not enough.
details
reason:
it is caused by:
commit number: 13e7a8e846c2ea38a552b986ea49332f965bbb7a
commit number: 44e9309f1f357794b7ae93d5f3e3e6f11d2b8a7f
they are "for saving/restore PPR"
by Haren Myneni <haren@linux.vnet.ibm.com> Thu, 6 Dec 2012
compiling result:
pseries_defconfig: pass (cpu for POWER7)
ppc64_defconfig: pass (cpu for POWER7)
allmodconfig: failed (cpu for POWER7)
analysing:
solving patch:
------------------------------------------------------------------
commit number: 61383407677aef05928541a00678591abea2d84c
Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Thu Jan 10 17:44:19 2013 +1100
powerpc: Make room in exception vector area
The FWNMI region is fixed at 0x7000 and the vector are now
overflowing that with some configurations. Fix that by moving
some hash management code out of that region as it doesn't need
to be that close to the call sites (isn't accessed using
conditional branches).
------------------------------------------------------------------
but for allmodconfig (not only for "some configurations"):
it really can reduce much overflow bytes,
(maybe from hundreds bytes to dozens bytes)
but still not enough (still content overflow bytes)
additional trying:
after del CONFIG_VSX and CONFIG_PPC_970_NAP in allmodconfig,
(will reduce dozens bytes in the region .0x5500 -- .0x7000)
it can pass compiling (not overflow).
next:
I am sorry:
I am not quite familiar with the detail features of powerpc.
it seems I am not the suitable member to continue trying.
I prefer Benjamin to continue trying (just like what he has done).
if Benjamin will not do it (e.g. maybe no time to do)
I should continue: "make additional room in exception vector area".
(if get no reply within a week: before 2013-03-28, I should continue)
welcome any members' (especially Benjamin) suggestions or completions.
thanks.
:-)
On 2013年03月15日 13:14, Chen Gang wrote:
> 于 2013年03月15日 12:52, Michael Neuling 写道:
>> Yep it's a known problem but no one has bothered to fix it since it
>> doesn't happen in a config that anyone cares about like
>> pseries_defconfig and ppc64_defconfig. We've been moving code around in
>> this area a lot recently hence the breakage.
>>
>> It should be fixed though. Patches welcome. :-)
>
> thanks, and I should try, and very glad to try.
>
> :-) :-)
>
> excuse me, I try to provide related patch within this month (2013-03-31), is it ok ?
> the reason is:
> I am not familiar with ppc assembly code, neither ppc kernel,
> so need additional time resource.
> (originally, I worked for x86(_64) core dump analysing for kernel and user programs)
>
> thanks.
>
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* linux-next: build failure after merge of the final tree (linus' tree related)
From: Stephen Rothwell @ 2013-03-21 6:23 UTC (permalink / raw)
To: Marcelo Tosatti, Gleb Natapov
Cc: Kevin Hilman, linuxppc-dev, linux-kernel, linux-next,
Paul Mackerras, Linus
[-- Attachment #1: Type: text/plain, Size: 1813 bytes --]
Hi all,
After merging the final tree, today's linux-next build (powerpc64
allnoconfig) failed like this:
In file included from arch/powerpc/include/asm/kvm_ppc.h:33:0,
from arch/powerpc/kernel/setup_64.c:67:
arch/powerpc/include/asm/kvm_book3s.h:65:20: error: field 'pte' has incomplete type
arch/powerpc/include/asm/kvm_book3s.h:69:18: error: field 'vcpu' has incomplete type
arch/powerpc/include/asm/kvm_book3s.h:98:34: error: 'HPTEG_HASH_NUM_PTE' undeclared here (not in a function)
arch/powerpc/include/asm/kvm_book3s.h:99:39: error: 'HPTEG_HASH_NUM_PTE_LONG' undeclared here (not in a function)
arch/powerpc/include/asm/kvm_book3s.h:100:35: error: 'HPTEG_HASH_NUM_VPTE' undeclared here (not in a function)
arch/powerpc/include/asm/kvm_book3s.h:101:40: error: 'HPTEG_HASH_NUM_VPTE_LONG' undeclared here (not in a function)
arch/powerpc/include/asm/kvm_book3s.h:129:4: error: 'struct kvm_run' declared inside parameter list [-Werror]
arch/powerpc/include/asm/kvm_book3s.h:129:4: error: its scope is only this definition or declaration, which is probably not what you want [-Werror]
And it went downhill form there. This build does not have CONFIG_KVM
defined.
Caused by commit f445f11eb2cc ("KVM: allow host header to be included
even for !CONFIG_KVM") which clearly never saw the light of day in
linux-next :-(
It would have been nice if the "compile failure when KVM is not enabled"
was included in the commit log so that we could figure out exactly what
needed to be protected instead of just effectively removing the whole
file.
I just reverted that commit for today. Can someone please supply a
better solution or even just more information about what that commit was
solving.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/uprobes: teach uprobes to ignore gdb breakpoints
From: Ananth N Mavinakayanahalli @ 2013-03-21 7:15 UTC (permalink / raw)
To: Oleg Nesterov; +Cc: ppcdev, Srikar Dronamraju, stable
In-Reply-To: <20130320160644.GA20352@redhat.com>
On Wed, Mar 20, 2013 at 05:06:44PM +0100, Oleg Nesterov wrote:
> On 03/20, Ananth N Mavinakayanahalli wrote:
> >
> > On Wed, Mar 20, 2013 at 01:26:39PM +0100, Oleg Nesterov wrote:
> >
> > > But, at the same time, is the new definition fine for verify_opcode()?
> > >
> > > IOW, powerpc has another is_trap() insn(s) used by gdb, lets denote it X.
> > > X != UPROBE_SWBP_INSN.
> > >
> > > Suppose that gdb installs the trap X at some addr, and then uprobe_register()
> > > tries to install uprobe at the same address. Then set_swbp() will do nothing,
> > > assuming the uprobe was already installed.
I think that is not right... see below...
> > > But we did not install UPROBE_SWBP_INSN. Is it fine? I hope yes, just to
> > > verify. If not, we need 2 definitions. is_uprobe_insn() should still check
> > > insns == UPROBE_SWBP_INSN, and is_swbp_insn() should check is_trap().
Its fine from gdb's perspective with my patch.
> > is_trap() checks for all trap variants on powerpc, including the one
> > uprobe uses. It returns true if the instruction is *any* trap variant.
>
> I understand,
>
> > So, install_breakpoint()->prepare_uprobe()->is_swbp_insn() will return
> > ENOTSUPP. In fact, arch_uprobe_analyze_insn() will also do the same.
>
> Yes and the check in arch_uprobe_analyze_insn() should go away.
>
> But you missed my point. Please forget about prepare_uprobe(), it is
> wrong anyway. And, prepare_uprobe() inspects the _original_ insn from
> the file, this has nothing install_breakpoint/etc.
>
> I meant verify_opcode() called by install_breakpoint/etc.
For the case where X already exists, verify_opcode() currently returns 0.
IMO, it should return -EEXIST, unless you are proposing that uprobes
should ride on the existing trap (even if its a variant).
If you are proposing that uprobes ride on X if it already exists, that's
not always possible and is a big can of worms... see below...
> > This itself should take care of all the cases.
> >
> > > And I am just curious, could you explain how X and UPROBE_SWBP_INSN
> > > differ?
> >
> > Powerpc has numerous variants of the trap instruction based on
> > comparison of two registers or a regsiter and immediate value and a condition
> > (less than, greater than, [signed forms thereof], or equal to).
> >
> > Uprobes uses 0x7fe0008 which is 'tw 31,0,0' which essentially is an
> > unconditional trap.
> >
> > Gdb uses many traps, one of which is 0x7d821008 which is twge r2,r2,
> > which is basically trap if r2 greater than or equal to r2.
>
> OK. So, if I understand correctly, gdb can use some conditional
> breakpoint, and it is possible that this insn won't generate the
> trap?
Yes it is possible if the condition is not met. If the condition is
met, the instruction will generate a trap, and uprobes will do a
send_sig(SIGTRAP) from handle_swbp().
> Then this patch is not right, or at least we need another change
> on top?
>
> Once again. Suppose that gdb installs the TRAP_IF_R1_GT_R2.
>
> After that uprobe_register() is called, but it won't change this
> insn because verify_opcode() returns 0.
>
> Then the probed task hits this breakoint with "r1 < r2" and we do
> not report this event.
At this time, the condition for the trap is not satisfied, so no
exception occurs. If the expectation is that the trap always trigger,
then all such trap variants need to be replaced with the unconditional
trap and we should either add logic to re-execute the condional trap
after uprobe handling and send_sig() via handle_swbp() or emulate the
condition in software and do a send_sig() if needed.
> So. I still think that we actually need something like below, and
> powerpc should reimplement is_trap_insn() to use is_trap(insn).
>
> No?
I don't see how this will help, especially since the gdb<->uprobes is
fraught with races.
With your proposed patch, we refuse to insert a uprobe if the underlying
instruction is a UPROBE_SWBP_INSTRUCTION; changing is_swbp_at_addr()
will need changes in handle_swbp() too. But, unlike x86, we cannot
expect a uprobe with an underlying trap variant (X) to always trigger.
IMHO, its not a good idea to do that for x86 either, since you'll run
into many other complications (what if the entity that put the original
breakpoint, removed it, etc).
IMHO, I really think we should not allow uprobe_register() to succeed if
the underlying instruction is a breakpoint (or a variant thereof).
Ananth
^ permalink raw reply
* Re: [PATCH] powerpc/uprobes: teach uprobes to ignore gdb breakpoints
From: Ananth N Mavinakayanahalli @ 2013-03-21 7:17 UTC (permalink / raw)
To: Oleg Nesterov; +Cc: ppcdev, Srikar Dronamraju, stable
In-Reply-To: <20130320160728.GB20352@redhat.com>
On Wed, Mar 20, 2013 at 05:07:28PM +0100, Oleg Nesterov wrote:
> On 03/20, Ananth N Mavinakayanahalli wrote:
> >
> > On Wed, Mar 20, 2013 at 01:43:01PM +0100, Oleg Nesterov wrote:
> > > On 03/20, Oleg Nesterov wrote:
> > > >
> > > > But we did not install UPROBE_SWBP_INSN. Is it fine? I hope yes, just to
> > > > verify. If not, we need 2 definitions. is_uprobe_insn() should still check
> > > > insns == UPROBE_SWBP_INSN, and is_swbp_insn() should check is_trap().
> > > >
> > > > And I am just curious, could you explain how X and UPROBE_SWBP_INSN
> > > > differ?
> > >
> > > IOW, if I wasn't clear... Lets forget about gdb/etc for the moment.
> > > Suppose we apply the patch below. Will uprobes on powerpc work?
> > >
> > > If yes, then your patch should be fine. If not, we probably need more
> > > changes.
> >
> > Yes, it will work fine.
>
> Even if this new insn is conditional?
Yes.
^ permalink raw reply
* Re: [RFC PATCH -V2 00/21] THP support for PPC64
From: Simon Jeons @ 2013-03-21 8:17 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: paulus, linuxppc-dev, linux-mm
In-Reply-To: <1361465248-10867-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
Hi Aneesh,
On 02/22/2013 12:47 AM, Aneesh Kumar K.V wrote:
> Hi,
>
> This patchset adds transparent huge page support for PPC64.
>
> I am marking the series to linux-mm because the PPC64 implementation
> required few interface changes to core THP code. I still have considerable
> number of FIXME!! in the patchset mostly related to PPC64 mm susbsytem.
> Those would require closer review and once we are clear on those changes,
> I will drop those FIXME!! with necessary comments.
>
> Some numbers:
>
> The latency measurements code from Anton found at
> http://ozlabs.org/~anton/junkcode/latency2001.c
Can this benchmark use for x86?
>
> THP disabled 64K page size
> ------------------------
> [root@llmp24l02 ~]# ./latency2001 8G
> 8589934592 731.73 cycles 205.77 ns
> [root@llmp24l02 ~]# ./latency2001 8G
> 8589934592 743.39 cycles 209.05 ns
> [root@llmp24l02 ~]#
>
> THP disabled large page via hugetlbfs
> -------------------------------------
> [root@llmp24l02 ~]# ./latency2001 -l 8G
> 8589934592 416.09 cycles 117.01 ns
> [root@llmp24l02 ~]# ./latency2001 -l 8G
> 8589934592 415.74 cycles 116.91 ns
>
> THP enabled 64K page size.
> ----------------
> [root@llmp24l02 ~]# ./latency2001 8G
> 8589934592 405.07 cycles 113.91 ns
> [root@llmp24l02 ~]# ./latency2001 8G
> 8589934592 411.82 cycles 115.81 ns
> [root@llmp24l02 ~]#
>
>
> We are close to hugetlbfs in latency and we can achieve this with zero
> config/page reservation. Most of the allocations above are fault allocated.
> I haven't really measured the collapse alloc impact.
>
> Another test that does 50000000 random access over 1GB area goes from
> 2.65 seconds to 1.07 seconds with this patchset.
>
> Changes from RFC V1:
> * HugeTLB fs now works
> * Compile issues fixed
> * rebased to v3.8
> * Patch series reorded so that ppc64 cleanups and MM THP changes are moved
> early in the series. This should help in picking those patches early.
>
> Thanks,
> -aneesh
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] powerpc: add CONFIG(s) require for using flash controller
From: Kumar Gala @ 2013-03-21 9:04 UTC (permalink / raw)
To: Prabhakar Kushwaha; +Cc: linuxppc-dev
In-Reply-To: <1363595483-7248-1-git-send-email-prabhakar@freescale.com>
On Mar 18, 2013, at 3:31 AM, Prabhakar Kushwaha wrote:
> Add CONFIG(s) required for NAND and NOR flash controller usage.
> It defines MTD, Jffs2 and UBIFS file system required for controllers.
>=20
> It also enables IFC controller
>=20
> Signed-off-by: Prabhakar Kushwaha <prabhakar@freescale.com>
> ---
> Based upon =
http://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
> branch next
>=20
> arch/powerpc/configs/corenet64_smp_defconfig | 35 =
+++++++++++++++++++++++++-
> arch/powerpc/configs/mpc85xx_defconfig | 31 =
+++++++++++++++++++++++
> arch/powerpc/configs/mpc85xx_smp_defconfig | 31 =
+++++++++++++++++++++++
> 3 files changed, 96 insertions(+), 1 deletion(-)
applied to next
- k=
^ permalink raw reply
* MPC5121e, Linux, simple IO ports
From: CF Studelec @ 2013-03-21 8:54 UTC (permalink / raw)
To: linuxppc-dev
Hello,
This is a simple board base on mpc5121e MCU.
Gpio is detected: kernel is compiled with its support - i got
gpiochip_find_base: found new base @224 in dmesg - on kernel 3.0.4.
But i'm unable to access it through /sys/class/gpio. I can successfully
export a pin (ie, if i type cat 224 > export, gpio224 is created), but i
can't successfully control it:
echo "out" > /sys/class/gpio/gpio224/direction
cat /sys/class/gpio/gpio224/value
0
echo 1 > /sys/class/gpio/gpio224/value
cat /sys/class/gpio/gpio224/value
0
My need is a simple chipselect (well, 3 chipselect exactly ), for a
custom design. Running linux is mandatory. I suspect the MPC5121e to be
in the bad function mode, so:
- does anyone knows how to change mode ? What register can i acces and
how ? does it worths a try ?
- does anyone successfully performed simple IO control ?
Last thing, i have tryed to access internal registers through /dev/mem,
but no success. There are very few ressources available for this
microcontroler, but i'm stick to it. Perhaps anybody knows how to access
(read) internal registers with /proc or sys-fs ?
Thank you for your help.
^ permalink raw reply
* Re: [PATCH 2/2] powerpc/fsl-booke: Update DCSR EPU device tree entries
From: Kumar Gala @ 2013-03-21 9:05 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Stephen George
In-Reply-To: <1363633870-3894-2-git-send-email-galak@kernel.crashing.org>
On Mar 18, 2013, at 2:11 PM, Kumar Gala wrote:
> From: Stephen George <Stephen.George@freescale.com>
>
> Identifies the epu as compatible with Chassis v1 Debug IP.
>
> Signed-off-by: Stephen George <Stephen.George@freescale.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 2 +-
> arch/powerpc/boot/dts/fsl/p3041si-post.dtsi | 2 +-
> arch/powerpc/boot/dts/fsl/p4080si-post.dtsi | 2 +-
> arch/powerpc/boot/dts/fsl/p5020si-post.dtsi | 2 +-
> arch/powerpc/boot/dts/fsl/p5040si-post.dtsi | 2 +-
> 5 files changed, 5 insertions(+), 5 deletions(-)
applied to next
- k
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/fsl-booke: Added device tree DCSR entries for
From: Kumar Gala @ 2013-03-21 9:06 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Stephen George
In-Reply-To: <1363633870-3894-1-git-send-email-galak@kernel.crashing.org>
On Mar 18, 2013, at 2:11 PM, Kumar Gala wrote:
> From: Stephen George <Stephen.George@freescale.com>
>=20
> Signed-off-by: Stephen George <Stephen.George@freescale.com>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 131 =
+++++++++++++++++++++++++++
> arch/powerpc/boot/dts/fsl/t4240si-pre.dtsi | 25 ++---
> arch/powerpc/boot/dts/t4240qds.dts | 4 +
> 3 files changed, 148 insertions(+), 12 deletions(-)
applied to next
- k=
^ permalink raw reply
* [PATCH] memblock: kill "config MAX_ACTIVE_REGIONS"
From: Paul Bolle @ 2013-03-21 9:27 UTC (permalink / raw)
To: James Hogan, Benjamin Herrenschmidt, Paul Mackerras, Paul Mundt
Cc: Tejun Heo, linuxppc-dev, linux-kernel, linux-sh
The Kconfig symbol MAX_ACTIVE_REGIONS is unused. Commit
0ee332c1451869963626bf9cac88f165a90990e1 ("memblock: Kill
early_node_map[]") removed the only place were it was actually used. But
it did not remove its Kconfig entries (for powerpc and sh).
Remove those two entries (and the entry for metag, that popped up in
v3.9-rc1).
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
---
0) Eyeball tested again.
1) It felt silly to split this clean up patch into three patches. But if
the maintainers involved disagree I'm happy to split and resend it.
arch/metag/mm/Kconfig | 5 -----
arch/powerpc/Kconfig | 5 -----
arch/sh/mm/Kconfig | 7 -------
3 files changed, 17 deletions(-)
diff --git a/arch/metag/mm/Kconfig b/arch/metag/mm/Kconfig
index 794f26a..03fb8f1 100644
--- a/arch/metag/mm/Kconfig
+++ b/arch/metag/mm/Kconfig
@@ -93,11 +93,6 @@ config ARCH_SPARSEMEM_ENABLE
config ARCH_SPARSEMEM_DEFAULT
def_bool y
-config MAX_ACTIVE_REGIONS
- int
- default "2" if SPARSEMEM
- default "1"
-
config ARCH_SELECT_MEMORY_MODEL
def_bool y
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 867ace7..b674397 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -427,11 +427,6 @@ config NODES_SHIFT
default "4"
depends on NEED_MULTIPLE_NODES
-config MAX_ACTIVE_REGIONS
- int
- default "256" if PPC64
- default "32"
-
config ARCH_SELECT_MEMORY_MODEL
def_bool y
depends on PPC64
diff --git a/arch/sh/mm/Kconfig b/arch/sh/mm/Kconfig
index 5a43a87..dba285e 100644
--- a/arch/sh/mm/Kconfig
+++ b/arch/sh/mm/Kconfig
@@ -137,13 +137,6 @@ config ARCH_SPARSEMEM_ENABLE
config ARCH_SPARSEMEM_DEFAULT
def_bool y
-config MAX_ACTIVE_REGIONS
- int
- default "6" if (CPU_SUBTYPE_SHX3 && SPARSEMEM)
- default "2" if SPARSEMEM && (CPU_SUBTYPE_SH7722 || \
- CPU_SUBTYPE_SH7785)
- default "1"
-
config ARCH_SELECT_MEMORY_MODEL
def_bool y
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH] memblock: kill "config MAX_ACTIVE_REGIONS"
From: Paul Mundt @ 2013-03-21 9:34 UTC (permalink / raw)
To: Paul Bolle
Cc: James Hogan, linux-sh, linux-kernel, Paul Mackerras, Tejun Heo,
linuxppc-dev
In-Reply-To: <1363858076.1390.104.camel@x61.thuisdomein>
On Thu, Mar 21, 2013 at 10:27:56AM +0100, Paul Bolle wrote:
> The Kconfig symbol MAX_ACTIVE_REGIONS is unused. Commit
> 0ee332c1451869963626bf9cac88f165a90990e1 ("memblock: Kill
> early_node_map[]") removed the only place were it was actually used. But
> it did not remove its Kconfig entries (for powerpc and sh).
>
> Remove those two entries (and the entry for metag, that popped up in
> v3.9-rc1).
>
> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
> ---
> 0) Eyeball tested again.
>
> 1) It felt silly to split this clean up patch into three patches. But if
> the maintainers involved disagree I'm happy to split and resend it.
>
Given that it's unused now it doesn't really matter how it gets applied,
it looks fine to me.
Acked-by: Paul Mundt <lethal@linux-sh.org>
^ permalink raw reply
* Re: [PATCH] memblock: kill "config MAX_ACTIVE_REGIONS"
From: James Hogan @ 2013-03-21 9:48 UTC (permalink / raw)
To: Paul Bolle
Cc: linux-sh, linux-kernel, Paul Mundt, Paul Mackerras, Tejun Heo,
linuxppc-dev
In-Reply-To: <20130321093455.GA8027@linux-sh.org>
On 21/03/13 09:34, Paul Mundt wrote:
> On Thu, Mar 21, 2013 at 10:27:56AM +0100, Paul Bolle wrote:
>> The Kconfig symbol MAX_ACTIVE_REGIONS is unused. Commit
>> 0ee332c1451869963626bf9cac88f165a90990e1 ("memblock: Kill
>> early_node_map[]") removed the only place were it was actually used. But
>> it did not remove its Kconfig entries (for powerpc and sh).
>>
>> Remove those two entries (and the entry for metag, that popped up in
>> v3.9-rc1).
>>
>> Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
>> ---
>> 0) Eyeball tested again.
>>
>> 1) It felt silly to split this clean up patch into three patches. But if
>> the maintainers involved disagree I'm happy to split and resend it.
>>
> Given that it's unused now it doesn't really matter how it gets applied,
> it looks fine to me.
>
> Acked-by: Paul Mundt <lethal@linux-sh.org>
>
Acked-by: James Hogan <james.hogan@imgtec.com>
^ permalink raw reply
* [PATCH] powerpc/dts: Add qe support for 36bit
From: Zhicheng Fan @ 2013-03-21 9:26 UTC (permalink / raw)
To: galak, linuxppc-dev; +Cc: Zhicheng Fan
fixed the following errors:
Error: arch/powerpc/boot/dts/p1025rdb.dtsi:326.2-3 label or path, 'qe', not found
Error: arch/powerpc/boot/dts/fsl/p1021si-post.dtsi:242.2-3 label or path, 'qe', not found
FATAL ERROR: Syntax error parsing input tree
Signed-off-by: Zhicheng Fan <B32736@freescale.com>
---
arch/powerpc/boot/dts/p1025rdb_36b.dts | 48 ++++++++++++++++++++++++++++++++
1 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/p1025rdb_36b.dts b/arch/powerpc/boot/dts/p1025rdb_36b.dts
index 4ce4bfa..c74c39b 100644
--- a/arch/powerpc/boot/dts/p1025rdb_36b.dts
+++ b/arch/powerpc/boot/dts/p1025rdb_36b.dts
@@ -82,6 +82,54 @@
0x0 0x100000>;
};
};
+
+ qe: qe@fffe80000 {
+ ranges = <0x0 0xf 0xffe80000 0x40000>;
+ reg = <0xf 0xffe80000 0 0x480>;
+ brg-frequency = <0>;
+ bus-frequency = <0>;
+ status = "disabled"; /* no firmware loaded */
+
+ enet3: ucc@2000 {
+ device_type = "network";
+ compatible = "ucc_geth";
+ rx-clock-name = "clk12";
+ tx-clock-name = "clk9";
+ pio-handle = <&pio1>;
+ phy-handle = <&qe_phy0>;
+ phy-connection-type = "mii";
+ };
+
+ mdio@2120 {
+ qe_phy0: ethernet-phy@0 {
+ interrupt-parent = <&mpic>;
+ interrupts = <4 1 0 0>;
+ reg = <0x6>;
+ device_type = "ethernet-phy";
+ };
+ qe_phy1: ethernet-phy@03 {
+ interrupt-parent = <&mpic>;
+ interrupts = <5 1 0 0>;
+ reg = <0x3>;
+ device_type = "ethernet-phy";
+ };
+ tbi-phy@11 {
+ reg = <0x11>;
+ device_type = "tbi-phy";
+ };
+ };
+
+ enet4: ucc@2400 {
+ device_type = "network";
+ compatible = "ucc_geth";
+ rx-clock-name = "none";
+ tx-clock-name = "clk13";
+ pio-handle = <&pio2>;
+ phy-handle = <&qe_phy1>;
+ phy-connection-type = "rmii";
+ };
+ };
+
};
/include/ "p1025rdb.dtsi"
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] KVM: PPC: e500: Expose MMU registers via ONE_REG
From: Alexander Graf @ 2013-03-21 10:06 UTC (permalink / raw)
To: Scott Wood; +Cc: Mihai Caraman, linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1363713985.16671.12@snotra>
On 19.03.2013, at 18:26, Scott Wood wrote:
> On 03/19/2013 12:17:11 PM, Mihai Caraman wrote:
>> diff --git a/arch/powerpc/kvm/e500_mmu.c =
b/arch/powerpc/kvm/e500_mmu.c
>> index 66b6e31..b77b855 100644
>> --- a/arch/powerpc/kvm/e500_mmu.c
>> +++ b/arch/powerpc/kvm/e500_mmu.c
>> @@ -596,6 +596,95 @@ int kvmppc_set_sregs_e500_tlb(struct kvm_vcpu =
*vcpu, struct kvm_sregs *sregs)
>> return 0;
>> }
>> +int kvmppc_get_one_reg_500_tlb(struct kvm_vcpu *vcpu, u64 id,
>> + union kvmppc_one_reg *val)
>=20
> s/500/e500/
>=20
>> +int kvmppc_set_one_reg_500_tlb(struct kvm_vcpu *vcpu, u64 id,
>> + union kvmppc_one_reg *val)
>> +{
>> + int r =3D 0;
>> + long int i;
>> +
>> + switch (id) {
>> + case KVM_REG_PPC_MAS0:
>> + vcpu->arch.shared->mas0 =3D set_reg_val(id, *val);
>> + break;
>> + case KVM_REG_PPC_MAS1:
>> + vcpu->arch.shared->mas1 =3D set_reg_val(id, *val);
>> + break;
>> + case KVM_REG_PPC_MAS2:
>> + vcpu->arch.shared->mas2 =3D set_reg_val(id, *val);
>> + break;
>> + case KVM_REG_PPC_MAS7_3:
>> + vcpu->arch.shared->mas7_3 =3D set_reg_val(id, *val);
>> + break;
>> + case KVM_REG_PPC_MAS4:
>> + vcpu->arch.shared->mas4 =3D set_reg_val(id, *val);
>> + break;
>> + case KVM_REG_PPC_MAS6:
>> + vcpu->arch.shared->mas6 =3D set_reg_val(id, *val);
>> + break;
>> + case KVM_REG_PPC_MMUCFG: {
>> + u32 mmucfg =3D set_reg_val(id, *val);
>> + vcpu->arch.mmucfg =3D mmucfg & ~MMUCFG_LPIDSIZE;
>> + break;
>> + }
>=20
> Do we really want to allow arbitrary MMUCFG changes? It won't =
magically make us able to support larger RAs, PIDs, different MAVN, etc.
Only if we update the actual shadow mmu configuration as well.
>=20
>> + case KVM_REG_PPC_TLB0CFG:
>> + case KVM_REG_PPC_TLB1CFG:
>> + case KVM_REG_PPC_TLB2CFG:
>> + case KVM_REG_PPC_TLB3CFG: {
>> + u32 tlbncfg =3D set_reg_val(id, *val); =09=
>> + u32 geometry_mask =3D TLBnCFG_N_ENTRY | TLBnCFG_ASSOC;
>> + i =3D id - KVM_REG_PPC_TLB0CFG;
>> +
>> + /* MMU geometry (way/size) can be set only using SW_TLB =
*/
>> + if ((vcpu->arch.tlbcfg[i] & geometry_mask) !=3D
>> + (tlbncfg & geometry_mask))
>> + r =3D -EINVAL;
>> +
>> + vcpu->arch.tlbcfg[i] =3D set_reg_val(id, *val);
>> + break;
>> + }
>=20
> Likewise -- just because QEMU sets a bit here doesn't mean KVM can =
support it.
>=20
> I thought the initial plan for setting these config registers was to =
accept it if it exactly matches what KVM already has, and give an error =
otherwise -- thus allowing for the possibliity of accepting certain =
specific updates in the future.
Yes, that was the idea :).
Alex
^ permalink raw reply
* Re: [PATCH] KVM: PPC: e500: Add separate functions for vcpu's MMU configuration
From: Alexander Graf @ 2013-03-21 10:07 UTC (permalink / raw)
To: Mihai Caraman; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1363713407-27886-1-git-send-email-mihai.caraman@freescale.com>
On 19.03.2013, at 18:16, Mihai Caraman wrote:
> Move vcpu's MMU default configuration and geometry update into their =
own
> functions.
Mind to explain why?
Alex
>=20
> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> ---
> arch/powerpc/kvm/e500_mmu.c | 59 =
+++++++++++++++++++++++++++----------------
> 1 files changed, 37 insertions(+), 22 deletions(-)
>=20
> diff --git a/arch/powerpc/kvm/e500_mmu.c b/arch/powerpc/kvm/e500_mmu.c
> index 5c44759..66b6e31 100644
> --- a/arch/powerpc/kvm/e500_mmu.c
> +++ b/arch/powerpc/kvm/e500_mmu.c
> @@ -596,6 +596,20 @@ int kvmppc_set_sregs_e500_tlb(struct kvm_vcpu =
*vcpu, struct kvm_sregs *sregs)
> return 0;
> }
>=20
> +static int vcpu_mmu_geometry_update(struct kvm_vcpu *vcpu,
> + struct kvm_book3e_206_tlb_params *params)
> +{
> + vcpu->arch.tlbcfg[0] &=3D ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
> + if (params->tlb_sizes[0] <=3D 2048)
> + vcpu->arch.tlbcfg[0] |=3D params->tlb_sizes[0];
> + vcpu->arch.tlbcfg[0] |=3D params->tlb_ways[0] << =
TLBnCFG_ASSOC_SHIFT;
> +
> + vcpu->arch.tlbcfg[1] &=3D ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
> + vcpu->arch.tlbcfg[1] |=3D params->tlb_sizes[1];
> + vcpu->arch.tlbcfg[1] |=3D params->tlb_ways[1] << =
TLBnCFG_ASSOC_SHIFT;
> + return 0; =09
> +}
> +
> int kvm_vcpu_ioctl_config_tlb(struct kvm_vcpu *vcpu,
> struct kvm_config_tlb *cfg)
> {
> @@ -692,16 +706,8 @@ int kvm_vcpu_ioctl_config_tlb(struct kvm_vcpu =
*vcpu,
> vcpu_e500->gtlb_offset[0] =3D 0;
> vcpu_e500->gtlb_offset[1] =3D params.tlb_sizes[0];
>=20
> - vcpu->arch.mmucfg =3D mfspr(SPRN_MMUCFG) & ~MMUCFG_LPIDSIZE;
> -
> - vcpu->arch.tlbcfg[0] &=3D ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
> - if (params.tlb_sizes[0] <=3D 2048)
> - vcpu->arch.tlbcfg[0] |=3D params.tlb_sizes[0];
> - vcpu->arch.tlbcfg[0] |=3D params.tlb_ways[0] << =
TLBnCFG_ASSOC_SHIFT;
> -
> - vcpu->arch.tlbcfg[1] &=3D ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
> - vcpu->arch.tlbcfg[1] |=3D params.tlb_sizes[1];
> - vcpu->arch.tlbcfg[1] |=3D params.tlb_ways[1] << =
TLBnCFG_ASSOC_SHIFT;
> + /* Update vcpu's MMU geometry based on SW_TLB input */
> + vcpu_mmu_geometry_update(vcpu, ¶ms);
>=20
> vcpu_e500->shared_tlb_pages =3D pages;
> vcpu_e500->num_shared_tlb_pages =3D num_pages;
> @@ -737,6 +743,26 @@ int kvm_vcpu_ioctl_dirty_tlb(struct kvm_vcpu =
*vcpu,
> return 0;
> }
>=20
> +/* vcpu's MMU default configuration */
> +static int vcpu_mmu_init(struct kvm_vcpu *vcpu,
> + struct kvmppc_e500_tlb_params *params)
> +{
> + /* Initialize RASIZE, PIDSIZE, NTLBS and MAVN fields with host =
values*/
> + vcpu->arch.mmucfg =3D mfspr(SPRN_MMUCFG) & ~MMUCFG_LPIDSIZE;
> +
> + /* Initialize IPROT field with host value*/
> + vcpu->arch.tlbcfg[0] =3D mfspr(SPRN_TLB0CFG) &
> + ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
> + vcpu->arch.tlbcfg[0] |=3D params[0].entries;
> + vcpu->arch.tlbcfg[0] |=3D params[0].ways << TLBnCFG_ASSOC_SHIFT;
> +
> + vcpu->arch.tlbcfg[1] =3D mfspr(SPRN_TLB1CFG) &
> + ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
> + vcpu->arch.tlbcfg[1] |=3D params[1].entries;
> + vcpu->arch.tlbcfg[1] |=3D params[1].ways << TLBnCFG_ASSOC_SHIFT;
> + return 0;
> +}
> +
> int kvmppc_e500_tlb_init(struct kvmppc_vcpu_e500 *vcpu_e500)
> {
> struct kvm_vcpu *vcpu =3D &vcpu_e500->vcpu;
> @@ -781,18 +807,7 @@ int kvmppc_e500_tlb_init(struct kvmppc_vcpu_e500 =
*vcpu_e500)
> if (!vcpu_e500->g2h_tlb1_map)
> goto err;
>=20
> - /* Init TLB configuration register */
> - vcpu->arch.tlbcfg[0] =3D mfspr(SPRN_TLB0CFG) &
> - ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
> - vcpu->arch.tlbcfg[0] |=3D vcpu_e500->gtlb_params[0].entries;
> - vcpu->arch.tlbcfg[0] |=3D
> - vcpu_e500->gtlb_params[0].ways << TLBnCFG_ASSOC_SHIFT;
> -
> - vcpu->arch.tlbcfg[1] =3D mfspr(SPRN_TLB1CFG) &
> - ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
> - vcpu->arch.tlbcfg[1] |=3D vcpu_e500->gtlb_params[1].entries;
> - vcpu->arch.tlbcfg[1] |=3D
> - vcpu_e500->gtlb_params[1].ways << TLBnCFG_ASSOC_SHIFT;
> + vcpu_mmu_init(vcpu, vcpu_e500->gtlb_params);
>=20
> kvmppc_recalc_tlb1map_range(vcpu_e500);
> return 0;
> --=20
> 1.7.4.1
>=20
>=20
> --
> To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH V2] powerpc/85xx: workaround for chips with MSI hardware errata
From: Jia Hongtao-B38951 @ 2013-03-21 10:22 UTC (permalink / raw)
To: Wood Scott-B07421, Kumar Gala
Cc: linuxppc-dev@lists.ozlabs.org, Li Yang-R58472
In-Reply-To: <1363710693.16671.7@snotra>
> -----Original Message-----
> From: Wood Scott-B07421
> Sent: Wednesday, March 20, 2013 12:32 AM
> To: Jia Hongtao-B38951
> Cc: Kumar Gala; linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421;
> michael@ellerman.id.au; Li Yang-R58472
> Subject: Re: [PATCH V2] powerpc/85xx: workaround for chips with MSI
> hardware errata
>=20
> ;On 03/19/2013 03:03:13 AM, Jia Hongtao-B38951 wrote:
> >
> >
> > > -----Original Message-----
> > > From: Kumar Gala [mailto:galak@kernel.crashing.org]
> > > Sent: Friday, March 15, 2013 11:53 PM
> > > To: Jia Hongtao-B38951
> > > Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421;
> > > michael@ellerman.id.au; Li Yang-R58472
> > > Subject: Re: [PATCH V2] powerpc/85xx: workaround for chips with MSI
> > > hardware errata
> > >
> > >
> > > On Mar 14, 2013, at 9:00 PM, Jia Hongtao-B38951 wrote:
> > >
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> > > >> Sent: Friday, March 15, 2013 4:05 AM
> > > >> To: Jia Hongtao-B38951
> > > >> Cc: linuxppc-dev@lists.ozlabs.org; Wood Scott-B07421;
> > > >> michael@ellerman.id.au; Li Yang-R58472; Jia Hongtao-B38951
> > > >> Subject: Re: [PATCH V2] powerpc/85xx: workaround for chips with
> > MSI
> > > >> hardware errata
> > > >>
> > > >>
> > > >> On Mar 14, 2013, at 5:35 AM, Jia Hongtao wrote:
> > > >>
> > > >>> The MPIC version 2.0 has a MSI errata (errata PIC1 of mpc8544),
> > It
> > > >>> causes that neither MSI nor MSI-X can work fine. This is a
> > > >>> workaround to allow MSI-X to function properly.
> > > >>>
> > > >>> Signed-off-by: Liu Shuo <soniccat.liu@gmail.com>
> > > >>> Signed-off-by: Li Yang <leoli@freescale.com>
> > > >>> Signed-off-by: Jia Hongtao <hongtao.jia@freescale.com>
> > > >>> ---
> > > >>> Changes for V2:
> > > >>> - Address almost all the comments from Michael Ellerman for V1.
> > > >>> Here is the link:
> > > >>> http://patchwork.ozlabs.org/patch/226833/
> > > >>>
> > > >>> arch/powerpc/sysdev/fsl_msi.c | 65
> > > >>> +++++++++++++++++++++++++++++++++++++++++--
> > > >>> arch/powerpc/sysdev/fsl_msi.h | 2 ++
> > > >>> 2 files changed, 64 insertions(+), 3 deletions(-)
> > > >>>
> > > >>> diff --git a/arch/powerpc/sysdev/fsl_msi.c
> > > >>> b/arch/powerpc/sysdev/fsl_msi.c index 178c994..54cb83e 100644
> > > >>> --- a/arch/powerpc/sysdev/fsl_msi.c
> > > >>> +++ b/arch/powerpc/sysdev/fsl_msi.c
> > > >>> @@ -98,8 +98,18 @@ static int fsl_msi_init_allocator(struct
> > fsl_msi
> > > >>> *msi_data)
> > > >>>
> > > >>> static int fsl_msi_check_device(struct pci_dev *pdev, int nvec,
> > int
> > > >>> type) {
> > > >>> - if (type =3D=3D PCI_CAP_ID_MSIX)
> > > >>> - pr_debug("fslmsi: MSI-X untested, trying
> > anyway.\n");
> > > >>> + struct fsl_msi *msi;
> > > >>> +
> > > >>> + if (type =3D=3D PCI_CAP_ID_MSI) {
> > > >>> + /*
> > > >>> + * MPIC version 2.0 has erratum PIC1. For now
> > MSI
> > > >>> + * could not work. So check to prevent MSI from
> > > >>> + * being used on the board with this erratum.
> > > >>> + */
> > > >>> + list_for_each_entry(msi, &msi_head, list)
> > > >>> + if (msi->feature & MSI_HW_ERRATA_ENDIAN)
> > > >>> + return -EINVAL;
> > > >>> + }
> > > >>>
> > > >>> return 0;
> > > >>> }
> > > >>> @@ -142,7 +152,17 @@ static void fsl_compose_msi_msg(struct
> > pci_dev
> > > >> *pdev, int hwirq,
> > > >>> msg->address_lo =3D lower_32_bits(address);
> > > >>> msg->address_hi =3D upper_32_bits(address);
> > > >>>
> > > >>> - msg->data =3D hwirq;
> > > >>> + /*
> > > >>> + * MPIC version 2.0 has erratum PIC1. It causes
> > > >>> + * that neither MSI nor MSI-X can work fine.
> > > >>> + * This is a workaround to allow MSI-X to function
> > > >>> + * properly. It only works for MSI-X, we prevent
> > > >>> + * MSI on buggy chips in fsl_msi_check_device().
> > > >>> + */
> > > >>> + if (msi_data->feature & MSI_HW_ERRATA_ENDIAN)
> > > >>> + msg->data =3D __swab32(hwirq);
> > > >>> + else
> > > >>> + msg->data =3D hwirq;
> > > >>>
> > > >>> pr_debug("%s: allocated srs: %d, ibs: %d\n",
> > > >>> __func__, hwirq / IRQS_PER_MSI_REG, hwirq %
> > IRQS_PER_MSI_REG);
> > > >> @@
> > > >>> -361,6 +381,35 @@ static int fsl_msi_setup_hwirq(struct fsl_msi
> > > >>> *msi,
> > > >> struct platform_device *dev,
> > > >>> return 0;
> > > >>> }
> > > >>>
> > > >>> +/* MPIC version 2.0 has erratum PIC1 */ static int
> > > >>> +mpic_has_errata(struct platform_device *dev) {
> > > >>> + struct device_node *mpic_node;
> > > >>> +
> > > >>> + mpic_node =3D of_irq_find_parent(dev->dev.of_node);
> > > >>> + if (mpic_node) {
> > > >>> + u32 *reg_base, brr1 =3D 0;
> > > >>> + /* Get the PIC reg base */
> > > >>> + reg_base =3D of_iomap(mpic_node, 0);
> > > >>> + of_node_put(mpic_node);
> > > >>> + if (!reg_base) {
> > > >>> + dev_err(&dev->dev, "ioremap problem
> > failed.\n");
> > > >>> + return -EIO;
> > > >>> + }
> > > >>> +
> > > >>> + /* Get the mpic version from block revision
> > register 1 */
> > > >>> + brr1 =3D in_be32(reg_base + MPIC_FSL_BRR1);
> > > >>> + iounmap(reg_base);
> > > >>> + if ((brr1 & MPIC_FSL_BRR1_VER) =3D=3D 0x0200)
> > > >>> + return 1;
> > > >>> + } else {
> > > >>> + dev_err(&dev->dev, "MSI can't find his parent
> > mpic node.\n");
> > > >>> + return -ENODEV;
> > > >>> + }
> > > >>> +
> > > >>> + return 0;
> > > >>> +}
> > > >>> +
> > > >>> static const struct of_device_id fsl_of_msi_ids[]; static int
> > > >>> fsl_of_msi_probe(struct platform_device *dev) { @@ -423,6
> > +472,16 @@
> > > >>> static int fsl_of_msi_probe(struct platform_device *dev)
> > > >>>
> > > >>> msi->feature =3D features->fsl_pic_ip;
> > > >>>
> > > >>> + if ((features->fsl_pic_ip & FSL_PIC_IP_MASK) =3D=3D
> > FSL_PIC_IP_MPIC) {
> > > >>> + rc =3D mpic_has_errata(dev);
> > > >>> + if (rc > 0) {
> > > >>> + msi->feature |=3D MSI_HW_ERRATA_ENDIAN;
> > > >>> + } else if (rc < 0) {
> > > >>> + err =3D rc;
> > > >>> + goto error_out;
> > > >>> + }
> > > >>> + }
> > > >>> +
> > > >>> /*
> > > >>> * Remember the phandle, so that we can match with any
> > PCI nodes
> > > >>> * that have an "fsl,msi" property.
> > > >>> diff --git a/arch/powerpc/sysdev/fsl_msi.h
> > > >>> b/arch/powerpc/sysdev/fsl_msi.h index 8225f86..7389e8e 100644
> > > >>> --- a/arch/powerpc/sysdev/fsl_msi.h
> > > >>> +++ b/arch/powerpc/sysdev/fsl_msi.h
> > > >>> @@ -25,6 +25,8 @@
> > > >>> #define FSL_PIC_IP_IPIC 0x00000002
> > > >>> #define FSL_PIC_IP_VMPIC 0x00000003
> > > >>>
> > > >>> +#define MSI_HW_ERRATA_ENDIAN 0x00000010
> > > >>> +
> > > >>
> > > >> Is there any reason to put this in fsl_msi.h rather than just in
> > > >> fsl_msi.c itself?
> > > >>
> > > >> - k
> > > >
> > > > Actually no. This micro is only used by fsl_msi.c.
> > > > Will move it to fsl_msi.c.
> > > >
> > > > Thanks.
> > > > -Hongtao.
> > >
> > > Also, wondering if we can do the mpic version detection in mpic.c
> > and not
> > > here. I'm not sure what means we'd have to get back to the mpic
> > struct
> > > so we could possible use mpic->flags.
> > >
> >
> > Use the MPIC version result in mpic.c was my plan.
> > But as you point out there seems no obvious way to get the mpic
> > struct.
> > mpic struct is defined as an automatic variable in platform files.
> > Also MSI driver is not so close to mpic driver under current
> > architecture.
> >
> > If you get some elegant way to do this please feel free to tell me.
>=20
> Declare a non-static function to retrieve the MPIC version.
>=20
> -Scott
The struct pointer "mpic" is for internal use only while the "mpic_primary"
could be used for external.
So I'd like to declare two functions something like:
mpic_get_version(struct *mpic);
mpic_primary_get_version(void);
The first function is for mpic.c internal use by mpic_alloc() and mpic_init=
().
The second function is for external use by fsl_msi.c.
There will be two patches:
1. Declare the two MPIC get-version APIs.
2. Fix the MSI errata.
Any comments for this plan?
Thanks.
-Hongtao.
^ permalink raw reply
* RE: [PATCH] KVM: PPC: e500: Expose MMU registers via ONE_REG
From: Caraman Mihai Claudiu-B02008 @ 2013-03-21 11:02 UTC (permalink / raw)
To: Alexander Graf, Wood Scott-B07421
Cc: linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
kvm-ppc@vger.kernel.org
In-Reply-To: <5F65F205-3B81-4154-B9E0-43FA1100A3FD@suse.de>
> -----Original Message-----
> From: Alexander Graf [mailto:agraf@suse.de]
> Sent: Thursday, March 21, 2013 12:07 PM
> To: Wood Scott-B07421
> Cc: Caraman Mihai Claudiu-B02008; kvm-ppc@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org; kvm@vger.kernel.org
> Subject: Re: [PATCH] KVM: PPC: e500: Expose MMU registers via ONE_REG
>=20
>=20
> On 19.03.2013, at 18:26, Scott Wood wrote:
>=20
> > On 03/19/2013 12:17:11 PM, Mihai Caraman wrote:
> >> diff --git a/arch/powerpc/kvm/e500_mmu.c b/arch/powerpc/kvm/e500_mmu.c
> >> index 66b6e31..b77b855 100644
> >> --- a/arch/powerpc/kvm/e500_mmu.c
> >> +++ b/arch/powerpc/kvm/e500_mmu.c
> >> @@ -596,6 +596,95 @@ int kvmppc_set_sregs_e500_tlb(struct kvm_vcpu
> *vcpu, struct kvm_sregs *sregs)
> >> return 0;
> >> }
> >> +int kvmppc_get_one_reg_500_tlb(struct kvm_vcpu *vcpu, u64 id,
> >> + union kvmppc_one_reg *val)
> >
> > s/500/e500/
> >
> >> +int kvmppc_set_one_reg_500_tlb(struct kvm_vcpu *vcpu, u64 id,
> >> + union kvmppc_one_reg *val)
> >> +{
> >> + int r =3D 0;
> >> + long int i;
> >> +
> >> + switch (id) {
> >> + case KVM_REG_PPC_MAS0:
> >> + vcpu->arch.shared->mas0 =3D set_reg_val(id, *val);
> >> + break;
> >> + case KVM_REG_PPC_MAS1:
> >> + vcpu->arch.shared->mas1 =3D set_reg_val(id, *val);
> >> + break;
> >> + case KVM_REG_PPC_MAS2:
> >> + vcpu->arch.shared->mas2 =3D set_reg_val(id, *val);
> >> + break;
> >> + case KVM_REG_PPC_MAS7_3:
> >> + vcpu->arch.shared->mas7_3 =3D set_reg_val(id, *val);
> >> + break;
> >> + case KVM_REG_PPC_MAS4:
> >> + vcpu->arch.shared->mas4 =3D set_reg_val(id, *val);
> >> + break;
> >> + case KVM_REG_PPC_MAS6:
> >> + vcpu->arch.shared->mas6 =3D set_reg_val(id, *val);
> >> + break;
> >> + case KVM_REG_PPC_MMUCFG: {
> >> + u32 mmucfg =3D set_reg_val(id, *val);
> >> + vcpu->arch.mmucfg =3D mmucfg & ~MMUCFG_LPIDSIZE;
> >> + break;
> >> + }
> >
> > Do we really want to allow arbitrary MMUCFG changes? It won't
> magically make us able to support larger RAs, PIDs, different MAVN, etc.
Not magically, some changes e.g TLBnCFG_IND or TLBnPS require just a kvm
check other changes e.g. TLBnCFG_MAVN require additional support and we
might not implement all of them. Until then this code should do the job:
/* MMU registers can be set only to the configuration supported by KVM */
case KVM_REG_PPC_MMUCFG: {
if (set_reg_val(id, *val) !=3D vcpu->arch.mmucfg)
r =3D -EINVAL;
break;
}
>=20
> Only if we update the actual shadow mmu configuration as well.
These registers (MMUCFG, EPTCFG, TLBnCFG, TLBnPS) are read-only (and shared
between e6500 threads), we can only emulate them.
-Mike
^ permalink raw reply
* Re: [PATCH] KVM: PPC: e500: Expose MMU registers via ONE_REG
From: Alexander Graf @ 2013-03-21 11:06 UTC (permalink / raw)
To: Caraman Mihai Claudiu-B02008
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
kvm@vger.kernel.org, kvm-ppc@vger.kernel.org
In-Reply-To: <300B73AA675FCE4A93EB4FC1D42459FF37304B@039-SN2MPN1-012.039d.mgd.msft.net>
On 21.03.2013, at 12:02, Caraman Mihai Claudiu-B02008 wrote:
>=20
>=20
>> -----Original Message-----
>> From: Alexander Graf [mailto:agraf@suse.de]
>> Sent: Thursday, March 21, 2013 12:07 PM
>> To: Wood Scott-B07421
>> Cc: Caraman Mihai Claudiu-B02008; kvm-ppc@vger.kernel.org; linuxppc-
>> dev@lists.ozlabs.org; kvm@vger.kernel.org
>> Subject: Re: [PATCH] KVM: PPC: e500: Expose MMU registers via ONE_REG
>>=20
>>=20
>> On 19.03.2013, at 18:26, Scott Wood wrote:
>>=20
>>> On 03/19/2013 12:17:11 PM, Mihai Caraman wrote:
>>>> diff --git a/arch/powerpc/kvm/e500_mmu.c =
b/arch/powerpc/kvm/e500_mmu.c
>>>> index 66b6e31..b77b855 100644
>>>> --- a/arch/powerpc/kvm/e500_mmu.c
>>>> +++ b/arch/powerpc/kvm/e500_mmu.c
>>>> @@ -596,6 +596,95 @@ int kvmppc_set_sregs_e500_tlb(struct kvm_vcpu
>> *vcpu, struct kvm_sregs *sregs)
>>>> return 0;
>>>> }
>>>> +int kvmppc_get_one_reg_500_tlb(struct kvm_vcpu *vcpu, u64 id,
>>>> + union kvmppc_one_reg *val)
>>>=20
>>> s/500/e500/
>>>=20
>>>> +int kvmppc_set_one_reg_500_tlb(struct kvm_vcpu *vcpu, u64 id,
>>>> + union kvmppc_one_reg *val)
>>>> +{
>>>> + int r =3D 0;
>>>> + long int i;
>>>> +
>>>> + switch (id) {
>>>> + case KVM_REG_PPC_MAS0:
>>>> + vcpu->arch.shared->mas0 =3D set_reg_val(id, *val);
>>>> + break;
>>>> + case KVM_REG_PPC_MAS1:
>>>> + vcpu->arch.shared->mas1 =3D set_reg_val(id, *val);
>>>> + break;
>>>> + case KVM_REG_PPC_MAS2:
>>>> + vcpu->arch.shared->mas2 =3D set_reg_val(id, *val);
>>>> + break;
>>>> + case KVM_REG_PPC_MAS7_3:
>>>> + vcpu->arch.shared->mas7_3 =3D set_reg_val(id, *val);
>>>> + break;
>>>> + case KVM_REG_PPC_MAS4:
>>>> + vcpu->arch.shared->mas4 =3D set_reg_val(id, *val);
>>>> + break;
>>>> + case KVM_REG_PPC_MAS6:
>>>> + vcpu->arch.shared->mas6 =3D set_reg_val(id, *val);
>>>> + break;
>>>> + case KVM_REG_PPC_MMUCFG: {
>>>> + u32 mmucfg =3D set_reg_val(id, *val);
>>>> + vcpu->arch.mmucfg =3D mmucfg & ~MMUCFG_LPIDSIZE;
>>>> + break;
>>>> + }
>>>=20
>>> Do we really want to allow arbitrary MMUCFG changes? It won't
>> magically make us able to support larger RAs, PIDs, different MAVN, =
etc.
>=20
> Not magically, some changes e.g TLBnCFG_IND or TLBnPS require just a =
kvm
> check other changes e.g. TLBnCFG_MAVN require additional support and =
we
> might not implement all of them. Until then this code should do the =
job:
>=20
> /* MMU registers can be set only to the configuration supported =
by KVM */
> case KVM_REG_PPC_MMUCFG: {
> if (set_reg_val(id, *val) !=3D vcpu->arch.mmucfg)
> r =3D -EINVAL;
> break;
> }
Yes :).
>=20
>>=20
>> Only if we update the actual shadow mmu configuration as well.
>=20
> These registers (MMUCFG, EPTCFG, TLBnCFG, TLBnPS) are read-only (and =
shared
> between e6500 threads), we can only emulate them.
We need to change the behavior of the shadow mmu as well. It's not about =
the registers, but the actually exposed TLBs. If you configure 4 TLBs, =
and you announce to the guest that you can do 4 TLBs, you better emulate =
4 TLBs :).
Alex
^ permalink raw reply
* [PATCH] powerpc: drop even more unused Kconfig symbols
From: Paul Bolle @ 2013-03-21 11:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras; +Cc: linuxppc-dev, linux-kernel
When I submitted commit 6805ab6daa2b589fe3242d05ddc47a9dbb0c4eb1
("powerpc: drop unused Kconfig symbols") I apparently failed to notice
that my patch also made PREP_RESIDUAL and PPC_A2_DD2 unused. Drop these
now.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
---
0) Untested.
1) I investigated these Kconfig files a bit and discovered that PPC_PREP
is marked BROKEN since v2.6.15, see commit
5be396b00ca0f2f769c55cf69bbd7c77451c925e ("powerpc: Mark PREP and
embedded as broken for now"). Though it's not my problem, this does
suggest PReP support can be removed entirely.
arch/powerpc/platforms/prep/Kconfig | 13 -------------
arch/powerpc/platforms/wsp/Kconfig | 4 ----
2 files changed, 17 deletions(-)
diff --git a/arch/powerpc/platforms/prep/Kconfig b/arch/powerpc/platforms/prep/Kconfig
index 1547f66..2036e7e 100644
--- a/arch/powerpc/platforms/prep/Kconfig
+++ b/arch/powerpc/platforms/prep/Kconfig
@@ -8,16 +8,3 @@ config PPC_PREP
select PPC_UDBG_16550
select PPC_NATIVE
default n
-
-config PREP_RESIDUAL
- bool "Support for PReP Residual Data"
- depends on PPC_PREP
- help
- Some PReP systems have residual data passed to the kernel by the
- firmware. This allows detection of memory size, devices present and
- other useful pieces of information. Sometimes this information is
- not present or incorrect, in which case it could lead to the machine
- behaving incorrectly. If this happens, either disable PREP_RESIDUAL
- or pass the 'noresidual' option to the kernel.
-
- If you are running a PReP system, say Y here, otherwise say N.
diff --git a/arch/powerpc/platforms/wsp/Kconfig b/arch/powerpc/platforms/wsp/Kconfig
index 79d2225..9eea710 100644
--- a/arch/powerpc/platforms/wsp/Kconfig
+++ b/arch/powerpc/platforms/wsp/Kconfig
@@ -29,7 +29,3 @@ config PPC_CHROMA
default y
endmenu
-
-config PPC_A2_DD2
- bool "Support for DD2 based A2/WSP systems"
- depends on PPC_A2
--
1.7.11.7
^ permalink raw reply related
* RE: [PATCH] KVM: PPC: e500: Add separate functions for vcpu's MMU configuration
From: Caraman Mihai Claudiu-B02008 @ 2013-03-21 11:19 UTC (permalink / raw)
To: Alexander Graf
Cc: linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
kvm-ppc@vger.kernel.org
In-Reply-To: <90E4FFA9-97C8-4D7D-910E-2E5DB273C88C@suse.de>
> -----Original Message-----
> From: kvm-ppc-owner@vger.kernel.org [mailto:kvm-ppc-
> owner@vger.kernel.org] On Behalf Of Alexander Graf
> Sent: Thursday, March 21, 2013 12:07 PM
> To: Caraman Mihai Claudiu-B02008
> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org
> Subject: Re: [PATCH] KVM: PPC: e500: Add separate functions for vcpu's
> MMU configuration
>=20
>=20
> On 19.03.2013, at 18:16, Mihai Caraman wrote:
>=20
> > Move vcpu's MMU default configuration and geometry update into their
> own
> > functions.
>=20
> Mind to explain why?
You requested a separate function for clearing TLBnCFG_IND bit (E.PT remova=
l)
to self-document the code. The existing logic (that TLBnCFG_IND relies on)
was buried in a chunk of code and I thought this will add more clarity.
If you don't agree I would document the code at least.
-Mike
>=20
>=20
> Alex
>=20
> >
> > Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> > ---
> > arch/powerpc/kvm/e500_mmu.c | 59 +++++++++++++++++++++++++++---------
> -------
> > 1 files changed, 37 insertions(+), 22 deletions(-)
> >
> > diff --git a/arch/powerpc/kvm/e500_mmu.c b/arch/powerpc/kvm/e500_mmu.c
> > index 5c44759..66b6e31 100644
> > --- a/arch/powerpc/kvm/e500_mmu.c
> > +++ b/arch/powerpc/kvm/e500_mmu.c
> > @@ -596,6 +596,20 @@ int kvmppc_set_sregs_e500_tlb(struct kvm_vcpu
> *vcpu, struct kvm_sregs *sregs)
> > return 0;
> > }
> >
> > +static int vcpu_mmu_geometry_update(struct kvm_vcpu *vcpu,
> > + struct kvm_book3e_206_tlb_params *params)
> > +{
> > + vcpu->arch.tlbcfg[0] &=3D ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
> > + if (params->tlb_sizes[0] <=3D 2048)
> > + vcpu->arch.tlbcfg[0] |=3D params->tlb_sizes[0];
> > + vcpu->arch.tlbcfg[0] |=3D params->tlb_ways[0] << TLBnCFG_ASSOC_SHIFT;
> > +
> > + vcpu->arch.tlbcfg[1] &=3D ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
> > + vcpu->arch.tlbcfg[1] |=3D params->tlb_sizes[1];
> > + vcpu->arch.tlbcfg[1] |=3D params->tlb_ways[1] << TLBnCFG_ASSOC_SHIFT;
> > + return 0;
> > +}
> > +
> > int kvm_vcpu_ioctl_config_tlb(struct kvm_vcpu *vcpu,
> > struct kvm_config_tlb *cfg)
> > {
> > @@ -692,16 +706,8 @@ int kvm_vcpu_ioctl_config_tlb(struct kvm_vcpu
> *vcpu,
> > vcpu_e500->gtlb_offset[0] =3D 0;
> > vcpu_e500->gtlb_offset[1] =3D params.tlb_sizes[0];
> >
> > - vcpu->arch.mmucfg =3D mfspr(SPRN_MMUCFG) & ~MMUCFG_LPIDSIZE;
> > -
> > - vcpu->arch.tlbcfg[0] &=3D ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
> > - if (params.tlb_sizes[0] <=3D 2048)
> > - vcpu->arch.tlbcfg[0] |=3D params.tlb_sizes[0];
> > - vcpu->arch.tlbcfg[0] |=3D params.tlb_ways[0] << TLBnCFG_ASSOC_SHIFT;
> > -
> > - vcpu->arch.tlbcfg[1] &=3D ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
> > - vcpu->arch.tlbcfg[1] |=3D params.tlb_sizes[1];
> > - vcpu->arch.tlbcfg[1] |=3D params.tlb_ways[1] << TLBnCFG_ASSOC_SHIFT;
> > + /* Update vcpu's MMU geometry based on SW_TLB input */
> > + vcpu_mmu_geometry_update(vcpu, ¶ms);
> >
> > vcpu_e500->shared_tlb_pages =3D pages;
> > vcpu_e500->num_shared_tlb_pages =3D num_pages;
> > @@ -737,6 +743,26 @@ int kvm_vcpu_ioctl_dirty_tlb(struct kvm_vcpu
> *vcpu,
> > return 0;
> > }
> >
> > +/* vcpu's MMU default configuration */
> > +static int vcpu_mmu_init(struct kvm_vcpu *vcpu,
> > + struct kvmppc_e500_tlb_params *params)
> > +{
> > + /* Initialize RASIZE, PIDSIZE, NTLBS and MAVN fields with host
> values*/
> > + vcpu->arch.mmucfg =3D mfspr(SPRN_MMUCFG) & ~MMUCFG_LPIDSIZE;
> > +
> > + /* Initialize IPROT field with host value*/
> > + vcpu->arch.tlbcfg[0] =3D mfspr(SPRN_TLB0CFG) &
> > + ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
> > + vcpu->arch.tlbcfg[0] |=3D params[0].entries;
> > + vcpu->arch.tlbcfg[0] |=3D params[0].ways << TLBnCFG_ASSOC_SHIFT;
> > +
> > + vcpu->arch.tlbcfg[1] =3D mfspr(SPRN_TLB1CFG) &
> > + ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
> > + vcpu->arch.tlbcfg[1] |=3D params[1].entries;
> > + vcpu->arch.tlbcfg[1] |=3D params[1].ways << TLBnCFG_ASSOC_SHIFT;
> > + return 0;
> > +}
> > +
> > int kvmppc_e500_tlb_init(struct kvmppc_vcpu_e500 *vcpu_e500)
> > {
> > struct kvm_vcpu *vcpu =3D &vcpu_e500->vcpu;
> > @@ -781,18 +807,7 @@ int kvmppc_e500_tlb_init(struct kvmppc_vcpu_e500
> *vcpu_e500)
> > if (!vcpu_e500->g2h_tlb1_map)
> > goto err;
> >
> > - /* Init TLB configuration register */
> > - vcpu->arch.tlbcfg[0] =3D mfspr(SPRN_TLB0CFG) &
> > - ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
> > - vcpu->arch.tlbcfg[0] |=3D vcpu_e500->gtlb_params[0].entries;
> > - vcpu->arch.tlbcfg[0] |=3D
> > - vcpu_e500->gtlb_params[0].ways << TLBnCFG_ASSOC_SHIFT;
> > -
> > - vcpu->arch.tlbcfg[1] =3D mfspr(SPRN_TLB1CFG) &
> > - ~(TLBnCFG_N_ENTRY | TLBnCFG_ASSOC);
> > - vcpu->arch.tlbcfg[1] |=3D vcpu_e500->gtlb_params[1].entries;
> > - vcpu->arch.tlbcfg[1] |=3D
> > - vcpu_e500->gtlb_params[1].ways << TLBnCFG_ASSOC_SHIFT;
> > + vcpu_mmu_init(vcpu, vcpu_e500->gtlb_params);
> >
> > kvmppc_recalc_tlb1map_range(vcpu_e500);
> > return 0;
> > --
> > 1.7.4.1
> >
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>=20
> --
> To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH] KVM: PPC: e500: Expose MMU registers via ONE_REG
From: Caraman Mihai Claudiu-B02008 @ 2013-03-21 11:42 UTC (permalink / raw)
To: Alexander Graf
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org,
kvm@vger.kernel.org, kvm-ppc@vger.kernel.org
In-Reply-To: <53B128A9-FE74-4C85-994B-6A8674270C8B@suse.de>
> -----Original Message-----
> From: Alexander Graf [mailto:agraf@suse.de]
> Sent: Thursday, March 21, 2013 1:07 PM
> To: Caraman Mihai Claudiu-B02008
> Cc: Wood Scott-B07421; kvm-ppc@vger.kernel.org; linuxppc-
> dev@lists.ozlabs.org; kvm@vger.kernel.org
> Subject: Re: [PATCH] KVM: PPC: e500: Expose MMU registers via ONE_REG
>=20
>=20
> On 21.03.2013, at 12:02, Caraman Mihai Claudiu-B02008 wrote:
>=20
> >
> >
> >> -----Original Message-----
> >> From: Alexander Graf [mailto:agraf@suse.de]
> >> Sent: Thursday, March 21, 2013 12:07 PM
> >> To: Wood Scott-B07421
> >> Cc: Caraman Mihai Claudiu-B02008; kvm-ppc@vger.kernel.org; linuxppc-
> >> dev@lists.ozlabs.org; kvm@vger.kernel.org
> >> Subject: Re: [PATCH] KVM: PPC: e500: Expose MMU registers via ONE_REG
> >>
> >>
> >> On 19.03.2013, at 18:26, Scott Wood wrote:
> >>
> >>> On 03/19/2013 12:17:11 PM, Mihai Caraman wrote:
> >>>> diff --git a/arch/powerpc/kvm/e500_mmu.c
> b/arch/powerpc/kvm/e500_mmu.c
> >>>> index 66b6e31..b77b855 100644
> >>>> --- a/arch/powerpc/kvm/e500_mmu.c
> >>>> +++ b/arch/powerpc/kvm/e500_mmu.c
> >>>> @@ -596,6 +596,95 @@ int kvmppc_set_sregs_e500_tlb(struct kvm_vcpu
> >> *vcpu, struct kvm_sregs *sregs)
> >>>> return 0;
> >>>> }
> >>>> +int kvmppc_get_one_reg_500_tlb(struct kvm_vcpu *vcpu, u64 id,
> >>>> + union kvmppc_one_reg *val)
> >>>
> >>> s/500/e500/
> >>>
> >>>> +int kvmppc_set_one_reg_500_tlb(struct kvm_vcpu *vcpu, u64 id,
> >>>> + union kvmppc_one_reg *val)
> >>>> +{
> >>>> + int r =3D 0;
> >>>> + long int i;
> >>>> +
> >>>> + switch (id) {
> >>>> + case KVM_REG_PPC_MAS0:
> >>>> + vcpu->arch.shared->mas0 =3D set_reg_val(id, *val);
> >>>> + break;
> >>>> + case KVM_REG_PPC_MAS1:
> >>>> + vcpu->arch.shared->mas1 =3D set_reg_val(id, *val);
> >>>> + break;
> >>>> + case KVM_REG_PPC_MAS2:
> >>>> + vcpu->arch.shared->mas2 =3D set_reg_val(id, *val);
> >>>> + break;
> >>>> + case KVM_REG_PPC_MAS7_3:
> >>>> + vcpu->arch.shared->mas7_3 =3D set_reg_val(id, *val);
> >>>> + break;
> >>>> + case KVM_REG_PPC_MAS4:
> >>>> + vcpu->arch.shared->mas4 =3D set_reg_val(id, *val);
> >>>> + break;
> >>>> + case KVM_REG_PPC_MAS6:
> >>>> + vcpu->arch.shared->mas6 =3D set_reg_val(id, *val);
> >>>> + break;
> >>>> + case KVM_REG_PPC_MMUCFG: {
> >>>> + u32 mmucfg =3D set_reg_val(id, *val);
> >>>> + vcpu->arch.mmucfg =3D mmucfg & ~MMUCFG_LPIDSIZE;
> >>>> + break;
> >>>> + }
> >>>
> >>> Do we really want to allow arbitrary MMUCFG changes? It won't
> >> magically make us able to support larger RAs, PIDs, different MAVN,
> etc.
> >
> > Not magically, some changes e.g TLBnCFG_IND or TLBnPS require just a
> kvm
> > check other changes e.g. TLBnCFG_MAVN require additional support and we
> > might not implement all of them. Until then this code should do the
> job:
> >
> > /* MMU registers can be set only to the configuration supported by
> KVM */
> > case KVM_REG_PPC_MMUCFG: {
> > if (set_reg_val(id, *val) !=3D vcpu->arch.mmucfg)
> > r =3D -EINVAL;
> > break;
> > }
>=20
> Yes :).
>=20
> >
> >>
> >> Only if we update the actual shadow mmu configuration as well.
> >
> > These registers (MMUCFG, EPTCFG, TLBnCFG, TLBnPS) are read-only (and
> shared
> > between e6500 threads), we can only emulate them.
>=20
> We need to change the behavior of the shadow mmu as well. It's not about
> the registers, but the actually exposed TLBs. If you configure 4 TLBs,
> and you announce to the guest that you can do 4 TLBs, you better emulate
> 4 TLBs :).
Right, like the rest of configs I was talking above:)
-Mike
^ permalink raw reply
* Re: [PATCH] KVM: PPC: e500: Add separate functions for vcpu's MMU configuration
From: Alexander Graf @ 2013-03-21 11:48 UTC (permalink / raw)
To: Caraman Mihai Claudiu-B02008
Cc: linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
kvm-ppc@vger.kernel.org
In-Reply-To: <300B73AA675FCE4A93EB4FC1D42459FF373151@039-SN2MPN1-012.039d.mgd.msft.net>
On 21.03.2013, at 12:19, Caraman Mihai Claudiu-B02008 wrote:
>> -----Original Message-----
>> From: kvm-ppc-owner@vger.kernel.org [mailto:kvm-ppc-
>> owner@vger.kernel.org] On Behalf Of Alexander Graf
>> Sent: Thursday, March 21, 2013 12:07 PM
>> To: Caraman Mihai Claudiu-B02008
>> Cc: kvm-ppc@vger.kernel.org; kvm@vger.kernel.org; linuxppc-
>> dev@lists.ozlabs.org
>> Subject: Re: [PATCH] KVM: PPC: e500: Add separate functions for =
vcpu's
>> MMU configuration
>>=20
>>=20
>> On 19.03.2013, at 18:16, Mihai Caraman wrote:
>>=20
>>> Move vcpu's MMU default configuration and geometry update into their
>> own
>>> functions.
>>=20
>> Mind to explain why?
>=20
> You requested a separate function for clearing TLBnCFG_IND bit (E.PT =
removal)
> to self-document the code. The existing logic (that TLBnCFG_IND relies =
on)
> was buried in a chunk of code and I thought this will add more =
clarity.
> If you don't agree I would document the code at least.
I guess I'll have to see the full picture then. Please just include this =
patch in the series when you change the IND bit and make the patch =
description a bit more obvious: Just indicate that you need this a =
cleanup to make the IND patch more readable.
Alex
^ permalink raw reply
* Re: [Suggestion] PowerPC: kernel: cross compiling issue with allmodconfig
From: Benjamin Herrenschmidt @ 2013-03-21 12:38 UTC (permalink / raw)
To: Chen Gang F T
Cc: sfr, Michael Neuling, matt, Chen Gang,
linux-kernel@vger.kernel.org, paulus@samba.org, imunsie,
linuxppc-dev
In-Reply-To: <514AC418.1070806@gmail.com>
On Thu, 2013-03-21 at 16:26 +0800, Chen Gang F T wrote:
> it seems:
> only move slb_miss_realmode to the end, can fix this issue without negative effect.
Thanks. I'm currently on vacation, I'll have a closer look when I'm back
unless Stephen or Paulus wants to shoot that to Linus while I'm
away.
Cheers,
Ben.
>
> diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
> index 200afa5..56bd923 100644
> --- a/arch/powerpc/kernel/exceptions-64s.S
> +++ b/arch/powerpc/kernel/exceptions-64s.S
> @@ -1066,78 +1066,6 @@ unrecov_user_slb:
> #endif /* __DISABLED__ */
>
>
> -/*
> - * r13 points to the PACA, r9 contains the saved CR,
> - * r12 contain the saved SRR1, SRR0 is still ready for return
> - * r3 has the faulting address
> - * r9 - r13 are saved in paca->exslb.
> - * r3 is saved in paca->slb_r3
> - * We assume we aren't going to take any exceptions during this procedure.
> - */
> -_GLOBAL(slb_miss_realmode)
> - mflr r10
> -#ifdef CONFIG_RELOCATABLE
> - mtctr r11
> -#endif
> -
> - stw r9,PACA_EXSLB+EX_CCR(r13) /* save CR in exc. frame */
> - std r10,PACA_EXSLB+EX_LR(r13) /* save LR */
> -
> - bl .slb_allocate_realmode
> -
> - /* All done -- return from exception. */
> -
> - ld r10,PACA_EXSLB+EX_LR(r13)
> - ld r3,PACA_EXSLB+EX_R3(r13)
> - lwz r9,PACA_EXSLB+EX_CCR(r13) /* get saved CR */
> -
> - mtlr r10
> -
> - andi. r10,r12,MSR_RI /* check for unrecoverable exception */
> - beq- 2f
> -
> -.machine push
> -.machine "power4"
> - mtcrf 0x80,r9
> - mtcrf 0x01,r9 /* slb_allocate uses cr0 and cr7 */
> -.machine pop
> -
> - RESTORE_PPR_PACA(PACA_EXSLB, r9)
> - ld r9,PACA_EXSLB+EX_R9(r13)
> - ld r10,PACA_EXSLB+EX_R10(r13)
> - ld r11,PACA_EXSLB+EX_R11(r13)
> - ld r12,PACA_EXSLB+EX_R12(r13)
> - ld r13,PACA_EXSLB+EX_R13(r13)
> - rfid
> - b . /* prevent speculative execution */
> -
> -2: mfspr r11,SPRN_SRR0
> - ld r10,PACAKBASE(r13)
> - LOAD_HANDLER(r10,unrecov_slb)
> - mtspr SPRN_SRR0,r10
> - ld r10,PACAKMSR(r13)
> - mtspr SPRN_SRR1,r10
> - rfid
> - b .
> -
> -unrecov_slb:
> - EXCEPTION_PROLOG_COMMON(0x4100, PACA_EXSLB)
> - DISABLE_INTS
> - bl .save_nvgprs
> -1: addi r3,r1,STACK_FRAME_OVERHEAD
> - bl .unrecoverable_exception
> - b 1b
> -
> -
> -#ifdef CONFIG_PPC_970_NAP
> -power4_fixup_nap:
> - andc r9,r9,r10
> - std r9,TI_LOCAL_FLAGS(r11)
> - ld r10,_LINK(r1) /* make idle task do the */
> - std r10,_NIP(r1) /* equivalent of a blr */
> - blr
> -#endif
> -
> .align 7
> .globl alignment_common
> alignment_common:
> @@ -1336,6 +1264,78 @@ _GLOBAL(opal_mc_secondary_handler)
>
>
> /*
> + * r13 points to the PACA, r9 contains the saved CR,
> + * r12 contain the saved SRR1, SRR0 is still ready for return
> + * r3 has the faulting address
> + * r9 - r13 are saved in paca->exslb.
> + * r3 is saved in paca->slb_r3
> + * We assume we aren't going to take any exceptions during this procedure.
> + */
> +_GLOBAL(slb_miss_realmode)
> + mflr r10
> +#ifdef CONFIG_RELOCATABLE
> + mtctr r11
> +#endif
> +
> + stw r9,PACA_EXSLB+EX_CCR(r13) /* save CR in exc. frame */
> + std r10,PACA_EXSLB+EX_LR(r13) /* save LR */
> +
> + bl .slb_allocate_realmode
> +
> + /* All done -- return from exception. */
> +
> + ld r10,PACA_EXSLB+EX_LR(r13)
> + ld r3,PACA_EXSLB+EX_R3(r13)
> + lwz r9,PACA_EXSLB+EX_CCR(r13) /* get saved CR */
> +
> + mtlr r10
> +
> + andi. r10,r12,MSR_RI /* check for unrecoverable exception */
> + beq- 2f
> +
> +.machine push
> +.machine "power4"
> + mtcrf 0x80,r9
> + mtcrf 0x01,r9 /* slb_allocate uses cr0 and cr7 */
> +.machine pop
> +
> + RESTORE_PPR_PACA(PACA_EXSLB, r9)
> + ld r9,PACA_EXSLB+EX_R9(r13)
> + ld r10,PACA_EXSLB+EX_R10(r13)
> + ld r11,PACA_EXSLB+EX_R11(r13)
> + ld r12,PACA_EXSLB+EX_R12(r13)
> + ld r13,PACA_EXSLB+EX_R13(r13)
> + rfid
> + b . /* prevent speculative execution */
> +
> +2: mfspr r11,SPRN_SRR0
> + ld r10,PACAKBASE(r13)
> + LOAD_HANDLER(r10,unrecov_slb)
> + mtspr SPRN_SRR0,r10
> + ld r10,PACAKMSR(r13)
> + mtspr SPRN_SRR1,r10
> + rfid
> + b .
> +
> +unrecov_slb:
> + EXCEPTION_PROLOG_COMMON(0x4100, PACA_EXSLB)
> + DISABLE_INTS
> + bl .save_nvgprs
> +1: addi r3,r1,STACK_FRAME_OVERHEAD
> + bl .unrecoverable_exception
> + b 1b
> +
> +
> +#ifdef CONFIG_PPC_970_NAP
> +power4_fixup_nap:
> + andc r9,r9,r10
> + std r9,TI_LOCAL_FLAGS(r11)
> + ld r10,_LINK(r1) /* make idle task do the */
> + std r10,_NIP(r1) /* equivalent of a blr */
> + blr
> +#endif
> +
> +/*
> * Hash table stuff
> */
> .align 7
>
>
> On 2013年03月21日 13:55, Chen Gang wrote:
> > Hello All:
> >
> > summary:
> > the root cause is no enough room in exception area (0x5500 -- 0x7000).
> >
> > it is caused by the patches "for saving/restre PPR":
> > they consumed much space of this area (0x5500 -- 0x7000).
> > for pseries_defconfig and ppc64_defconfig, it is still ok.
> > but for allmodconfig and "some additional config", it will cause issue.
> >
> > the solving patch "Make room in exception vector area" can make room larger.
> > it can let "some additional config" ok.
> > but for allmodconfig, it is still not enough.
> >
> >
> > details
> > reason:
> > it is caused by:
> > commit number: 13e7a8e846c2ea38a552b986ea49332f965bbb7a
> > commit number: 44e9309f1f357794b7ae93d5f3e3e6f11d2b8a7f
> > they are "for saving/restore PPR"
> > by Haren Myneni <haren@linux.vnet.ibm.com> Thu, 6 Dec 2012
> > compiling result:
> > pseries_defconfig: pass (cpu for POWER7)
> > ppc64_defconfig: pass (cpu for POWER7)
> > allmodconfig: failed (cpu for POWER7)
> >
> > analysing:
> > solving patch:
> > ------------------------------------------------------------------
> > commit number: 61383407677aef05928541a00678591abea2d84c
> > Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > Date: Thu Jan 10 17:44:19 2013 +1100
> >
> > powerpc: Make room in exception vector area
> >
> > The FWNMI region is fixed at 0x7000 and the vector are now
> > overflowing that with some configurations. Fix that by moving
> > some hash management code out of that region as it doesn't need
> > to be that close to the call sites (isn't accessed using
> > conditional branches).
> > ------------------------------------------------------------------
> >
> > but for allmodconfig (not only for "some configurations"):
> > it really can reduce much overflow bytes,
> > (maybe from hundreds bytes to dozens bytes)
> > but still not enough (still content overflow bytes)
> >
> > additional trying:
> > after del CONFIG_VSX and CONFIG_PPC_970_NAP in allmodconfig,
> > (will reduce dozens bytes in the region .0x5500 -- .0x7000)
> > it can pass compiling (not overflow).
> >
> >
> > next:
> > I am sorry:
> > I am not quite familiar with the detail features of powerpc.
> > it seems I am not the suitable member to continue trying.
> >
> > I prefer Benjamin to continue trying (just like what he has done).
> >
> > if Benjamin will not do it (e.g. maybe no time to do)
> > I should continue: "make additional room in exception vector area".
> > (if get no reply within a week: before 2013-03-28, I should continue)
> >
> >
> >
> > welcome any members' (especially Benjamin) suggestions or completions.
> >
> > thanks.
> >
> > :-)
> >
> >
> > On 2013年03月15日 13:14, Chen Gang wrote:
> >> 于 2013年03月15日 12:52, Michael Neuling 写道:
> >>> Yep it's a known problem but no one has bothered to fix it since it
> >>> doesn't happen in a config that anyone cares about like
> >>> pseries_defconfig and ppc64_defconfig. We've been moving code around in
> >>> this area a lot recently hence the breakage.
> >>>
> >>> It should be fixed though. Patches welcome. :-)
> >>
> >> thanks, and I should try, and very glad to try.
> >>
> >> :-) :-)
> >>
> >> excuse me, I try to provide related patch within this month (2013-03-31), is it ok ?
> >> the reason is:
> >> I am not familiar with ppc assembly code, neither ppc kernel,
> >> so need additional time resource.
> >> (originally, I worked for x86(_64) core dump analysing for kernel and user programs)
> >>
> >> thanks.
> >>
> >
> >
>
>
^ permalink raw reply
* Re: [PATCH] [RFC] powerpc: Add VDSO version of time
From: Adhemerval Zanella @ 2013-03-21 13:40 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1363755620.18880.27.camel@pasglop>
On 20-03-2013 02:00, Benjamin Herrenschmidt wrote:
> On Tue, 2013-03-19 at 16:55 -0300, Adhemerval Zanella wrote:
>> I focused on 64 bit kernel, do I need to provide a scheme for 32 bits
>> as well?
> You did provide both 32 and 64-bit VDSO implementations so 32-bit
> kernels should be covered.
Indeed and thanks for the reply. Any objection or request about including it?
Thanks.
^ permalink raw reply
* Re: MPC5121e, Linux, simple IO ports
From: CF Studelec @ 2013-03-21 13:44 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <514ACAD6.6010909@studelec-sa.com>
Sorry to bump the post, i'm wondering if it was correctly sent.
Le 21/03/2013 09:54, CF Studelec a écrit :
> Hello,
>
> This is a simple board base on mpc5121e MCU.
>
>
> Gpio is detected: kernel is compiled with its support - i got
> gpiochip_find_base: found new base @224 in dmesg - on kernel 3.0.4.
>
>
> But i'm unable to access it through /sys/class/gpio. I can successfully
> export a pin (ie, if i type cat 224 > export, gpio224 is created), but i
> can't successfully control it:
>
>
>
> echo "out" > /sys/class/gpio/gpio224/direction
>
> cat /sys/class/gpio/gpio224/value
>
> 0
>
> echo 1 > /sys/class/gpio/gpio224/value
>
> cat /sys/class/gpio/gpio224/value
>
> 0
>
>
>
> My need is a simple chipselect (well, 3 chipselect exactly ), for a
> custom design. Running linux is mandatory. I suspect the MPC5121e to be
> in the bad function mode, so:
>
> - does anyone knows how to change mode ? What register can i acces and
> how ? does it worths a try ?
>
> - does anyone successfully performed simple IO control ?
>
>
>
> Last thing, i have tryed to access internal registers through /dev/mem,
> but no success. There are very few ressources available for this
> microcontroler, but i'm stick to it. Perhaps anybody knows how to access
> (read) internal registers with /proc or sys-fs ?
>
>
>
> Thank you for your help.
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ 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