* Re: [PATCH] powerpc/timebase_read: don't return time older than cycle_last
From: Benjamin Herrenschmidt @ 2011-06-30 0:29 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20110629141940.2c930411@schlenkerla.am.freescale.net>
On Wed, 2011-06-29 at 14:19 -0500, Scott Wood wrote:
> On Wed, 29 Jun 2011 11:06:36 +1000
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > I don't think we ever want to "fix" userspace... how would you "fix" the
> > vDSO gettimeofday implementation for example since the vDSO has no
> > storage ?
>
> Hmm... I guess you could at least make the libc interface monotonic, though
> that wouldn't help if multiple processes are doing some shared memory
> communication.
>
> Ideally, anything that uses timestamps should be robust against small jumps
> backwards (i.e. not blow it up into some huge jump forward or similar
> breakage), because reality just isn't perfect. Especially if you're writing
> userspace code that could run on all sorts of hardware.
Well, powerpc hardware so far has been "perfect" in that regard and I'm
unwilling to bend on that one without throwing a lot of shame at your
face for screwing up :-)
Point is, it's an assumption made by Linux, but also a pile of userspace
code, and I wouldn't be surprised if it extends way beyond just glibc.
So even if it's not spelled out in the PPC_AS (tho it is in PAPR), we
can define it as a Linux requirement :-)
> > We base this assumption on what I believe is an architectural
> > requirement tho of course it's not worded very explicitely, and probably
> > just "derived" from the architecture statement that the timebase can
> > always be used as a monotonic source of time.
>
> Is it making any statement about monotonicity across CPUs?
I think PAPR does actually, I suspect it's been mostly implied and never
written down from a more generic arch perspective.
> > smp-tbsync.c is and has always been a "workaround" for broken HW.
>
> As is this (or for broken firmware, or broken emulation).
>
> > Anybody with half a clue should follow the recommendation of the
> > architecture (this one is actually spelled out, but as a recommendation
> > only) to have a TB enable pin and use it to perform a perfect sync at
> > boot time.
>
> Where in the ISA is this?
In the TB chapter of 2.06
> Closest I see from a quick scan is "There must be a method for getting all
> Time Bases in the system to start incrementing with values that are
> identical or almost identical." (7.2 S, 9.2.1 E). Note the "almost".
>
> And while we do provide this beginning with the e500mc-based chips, e500v2
> isn't dead yet. Kexec is also currently breaking the boot sync, requiring
> smp-tbsync -- though ideally kexec could be reworked to not need to
> physically reset the core.
Right, fixable :-)
> > > We had a bug in U-Boot's timebase sync where the boot core would sometimes
> > > be one tick faster than the other cores.
> >
> > It's scary to think that your cores TBs seem to be soured from different
> > clock sources...
>
> They're not. We use the boot core's timebase for a while, then disable it,
> reset it to zero, and enable all the timebases at once. The bug was a
> missing readback to ensure that it was stopped before it was reset, so
> sometimes it would tick up to 1 on the boot core after reset, before being
> enabled again. This resulted in the boot core's timebase always reading
> one greater than the other cores'.
>
> It can also be an issue when running on simulated hardware.
Ok.
> > ie even if you fix uBoot, can you guarantee they won't
> > drift ? I hope so ...
>
> It shouldn't drift even with the old U-boot -- it's just a constant offset.
That's easier to fix.
> > I would consider that an unfixable architecture
> > violation and I am not at this stage keen on implementing the necessary
> > "workarounds" in Linux (the userspace case is nasty, really nasty).
> >
> > PowerPC always prided itself on having a "sane" time base mechanism
> > unlike x86, please don't tell me that you guys are now breaking that
> > assumption.
>
> If you mean "are we introducing new chips that have timebase problems", no.
>
> I'm questioning whether the assumption was ever fully valid under all
> circumstances.
I think it was, and regardless, the majority of code out there was
written with that assumption.
> > > It's been fixed, but there are
> > > probably people still running the old U-Boot. It seems like the kind of
> > > thing where defensive robustness is called for, like timing out instead of
> > > hanging if a hardware register never flips the bit we're waiting for.
> >
> > No, you'll just "hide" the problem from the kernel and horrible &
> > unexplainable things will happen in userspace. At the VERY LEAST you
> > must warn very loudly if you detect this is happening.
>
> A warning message is OK.
>
> The current situation hides it as well, since it appears to work fine
> until you hit the race, and suddenly things get stuck and it takes a lot of
> digging to find out why.
Yes but you can't hide it completely, so you can't "contain" the damage.
> > > > We make hard assumptions here and in various places actually.
> > >
> > > Are there any in the kernel that this doesn't cover?
> >
> > Check gtod implementation, I'm not sure whether that's enough at this
> > stage or not for it, and then there's the vDSO of course.
>
> I think the in-kernel gtod is OK after this patch (it breaks if it reads a
> timestamp that is less than cycle_last).
>
> The 32-bit vdso looks OK as is since it doesn't convert to nsec until after
> adding to xtime. Userspace will still see time go backwards a bit if the
> timebase does, but it shouldn't get a wildly wrong answer.
But it might calculate one. There's no such thing as a "small problem"
here. If userspace sees the time go backward, even by 1ns, horrible
unpredictable things will happen.
It's either fully correct or not correct at all, and our userspace makes
the assumption that it's always fully correct.
> The 64-bit vdso
> uses srdi instead of sradi, and does so before adding to the upper
> half of xtime, so if the race is hit the returned time will be too high by
> 2^32 seconds.
>
> The problem in the in-kernel gettimeofday that causes it to be sensitive to
> times less than cycles_last appears to be the same thing --
> clocksource_cyc2ns() does an unsigned shift, even though it claims to be
> returning a signed result.
>
> > Not sure what's up with sched_clock() and whether that has similar constraints.
>
> sched_clock() should be OK as long as the timestamp is always greater than
> boot_tb, and hopefully any timebase skew is less than the delay from when
> boot_tb is set to when secondary cores start up.
>
> Delay loops could end early if they use unsigned comparisons, but only if
> the timebase skew is greater than the time it takes to move a thread from
> one cpu to another.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v2] powerpc/book3e-64: use a separate TLB handler when linear map is bolted
From: Benjamin Herrenschmidt @ 2011-06-29 22:20 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20110629144010.1fe5df24@schlenkerla.am.freescale.net>
On Wed, 2011-06-29 at 14:40 -0500, Scott Wood wrote:
> What is the "weird page table format" referred to by the normal miss
> handler?
Not sure :-) Probably the fact that we allocate 64K for PTE pages but
only use 32K of them ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc/mm: add devmem_is_allowed() for STRICT_DEVMEM checking
From: Sukadev Bhattiprolu @ 2011-06-29 22:01 UTC (permalink / raw)
To: Scott Wood; +Cc: Nathan Lynch, linuxppc-dev, Steve Best
In-Reply-To: <20110614140431.31ae4357__48367.5367352136$1308078343$gmane$org@schlenkerla.am.freescale.net>
On 06/14/2011 12:04 PM, Scott Wood wrote:
> On Tue, 14 Jun 2011 14:17:01 -0400
> Steve Best<sfbest@us.ibm.com> wrote:
>
>> On Tue, 2011-06-14 at 12:30 -0500, Nathan Lynch wrote:
>>> Hi Steve,
>>>
>>> On Tue, 2011-06-14 at 12:58 -0400, Steve Best wrote:
>>>> +/*
>>>> + * devmem_is_allowed() checks to see if /dev/mem access to a certain address
>>>> + * is valid. The argument is a physical page number.
>>>> + *
>>>> + * On PowerPC, access has to be given to data regions used by X. We have to
>>>> + * disallow access to device-exclusive MMIO regions and system RAM.
>>>> + */
>>>> +int devmem_is_allowed(unsigned long pfn)
>>>> +{
>>>> + if ((pfn>= 57360 || pfn<= 57392))
>>>> + return 1;
>>>
>>> That seems... fragile. Where do these numbers come from, and are they
>>> appropriate for all platforms and configurations?
>>
>> This is the range I got from testing pseries blades and servers. maybe
>> there is a better way to get this range anyone know of a way?
>
> Use iomem_is_exclusive(), as other architectures (e.g. x86, arm) do.
>
> Anything else is both platform-specific, and inappropriate hardcoding of
> policy.
x86 allows access to the first 256 pages. Are there other regions that
we should allow in power besides the !iomem_is_exclusive() region ?
>
> -Scott
^ permalink raw reply
* Re: [PATCH 2/2] Add cpufreq driver for Momentum Maple boards
From: Dmitry Eremin-Solenikov @ 2011-06-29 20:58 UTC (permalink / raw)
To: kevin diggs; +Cc: Paul Mackerras, linuxppc-dev, cpufreq, Dave Jones
In-Reply-To: <BANLkTikD_x3QA8_q8+444QhA39SEW6hVfg@mail.gmail.com>
On Wed, Jun 29, 2011 at 10:09 PM, kevin diggs <diggskevin38@gmail.com> wrote:
> Hi,
>
> On Tue, Jun 28, 2011 at 10:28 PM, Benjamin Herrenschmidt >
>>
>> If we're going to have a Kconfig.powerpc, should we maybe just have a
>> powerpc subdirectory instead with the driver in it ?
>>
> Where would the powerpc subdirectory be? under drivers/cpufreq? Or
> somewhere under arch/powerpc where it belongs (and I put my 750GX
> stuff)?
drivers/cpufreq/powerpc. However my current version (as suggested by Ben)
goes directly to drivers/cpufreq
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2] powerpc/book3e-64: use a separate TLB handler when linear map is bolted
From: Scott Wood @ 2011-06-29 19:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1309333828.14501.65.camel@pasglop>
On Wed, 29 Jun 2011 17:50:28 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> On Wed, 2011-06-22 at 16:25 -0500, Scott Wood wrote:
> > On MMUs such as FSL where we can guarantee the entire linear mapping is
> > bolted, we don't need to worry about linear TLB misses. If on top of
> > that we do a full table walk, we get rid of all recursive TLB faults, and
> > can dispense with some state saving. This gains a few percent on
> > TLB-miss-heavy workloads, and around 50% on a benchmark that had a high
> > rate of virtual page table faults under the normal handler.
> >
> > While touching the EX_TLB layout, remove EX_TLB_MMUCR0, EX_TLB_SRR0, and
> > EX_TLB_SRR1 as they're not used.
>
> I merged that into -next, but it was breaking 64K pages on WSP, I had to
> add an ifdef in there to skip the PUD level when walking the page tables
> (PUD_SHIFT isn't defined for asm when doing 64K pages).
>
> Please check I didn't break anything.
Looks good, though I wonder if all the bolted stuff should be under the
ifdef, at least for now.
What is the "weird page table format" referred to by the normal miss
handler?
-Scott
^ permalink raw reply
* Re: perf_event_open system call support in powerpc
From: Scott Wood @ 2011-06-29 19:24 UTC (permalink / raw)
To: ashwath narasimhan; +Cc: linuxppc-dev
In-Reply-To: <BANLkTi=j1FwEv2tBmPck3GWHWgcYGchcew@mail.gmail.com>
On Tue, 28 Jun 2011 20:03:10 -0700
ashwath narasimhan <ashwath.narasimhan@oneconvergence.com> wrote:
> Hello,
>
> I am new to the powerpc architecture and I am trying to use
> perf_event_open() system call for power pc architecture (e500mc) using
> 2.6.32 kernel distribution. Is this system call number supported for power
> pc architecture?
perf event support for e500mc wasn't added until 2.6.34.
-Scott
^ permalink raw reply
* Re: [PATCH] powerpc/timebase_read: don't return time older than cycle_last
From: Scott Wood @ 2011-06-29 19:19 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1309309596.32158.487.camel@pasglop>
On Wed, 29 Jun 2011 11:06:36 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> I don't think we ever want to "fix" userspace... how would you "fix" the
> vDSO gettimeofday implementation for example since the vDSO has no
> storage ?
Hmm... I guess you could at least make the libc interface monotonic, though
that wouldn't help if multiple processes are doing some shared memory
communication.
Ideally, anything that uses timestamps should be robust against small jumps
backwards (i.e. not blow it up into some huge jump forward or similar
breakage), because reality just isn't perfect. Especially if you're writing
userspace code that could run on all sorts of hardware.
> We base this assumption on what I believe is an architectural
> requirement tho of course it's not worded very explicitely, and probably
> just "derived" from the architecture statement that the timebase can
> always be used as a monotonic source of time.
Is it making any statement about monotonicity across CPUs?
> smp-tbsync.c is and has always been a "workaround" for broken HW.
As is this (or for broken firmware, or broken emulation).
> Anybody with half a clue should follow the recommendation of the
> architecture (this one is actually spelled out, but as a recommendation
> only) to have a TB enable pin and use it to perform a perfect sync at
> boot time.
Where in the ISA is this?
Closest I see from a quick scan is "There must be a method for getting all
Time Bases in the system to start incrementing with values that are
identical or almost identical." (7.2 S, 9.2.1 E). Note the "almost".
And while we do provide this beginning with the e500mc-based chips, e500v2
isn't dead yet. Kexec is also currently breaking the boot sync, requiring
smp-tbsync -- though ideally kexec could be reworked to not need to
physically reset the core.
> > We had a bug in U-Boot's timebase sync where the boot core would sometimes
> > be one tick faster than the other cores.
>
> It's scary to think that your cores TBs seem to be soured from different
> clock sources...
They're not. We use the boot core's timebase for a while, then disable it,
reset it to zero, and enable all the timebases at once. The bug was a
missing readback to ensure that it was stopped before it was reset, so
sometimes it would tick up to 1 on the boot core after reset, before being
enabled again. This resulted in the boot core's timebase always reading
one greater than the other cores'.
It can also be an issue when running on simulated hardware.
> ie even if you fix uBoot, can you guarantee they won't
> drift ? I hope so ...
It shouldn't drift even with the old U-boot -- it's just a constant offset.
> I would consider that an unfixable architecture
> violation and I am not at this stage keen on implementing the necessary
> "workarounds" in Linux (the userspace case is nasty, really nasty).
>
> PowerPC always prided itself on having a "sane" time base mechanism
> unlike x86, please don't tell me that you guys are now breaking that
> assumption.
If you mean "are we introducing new chips that have timebase problems", no.
I'm questioning whether the assumption was ever fully valid under all
circumstances.
> > It's been fixed, but there are
> > probably people still running the old U-Boot. It seems like the kind of
> > thing where defensive robustness is called for, like timing out instead of
> > hanging if a hardware register never flips the bit we're waiting for.
>
> No, you'll just "hide" the problem from the kernel and horrible &
> unexplainable things will happen in userspace. At the VERY LEAST you
> must warn very loudly if you detect this is happening.
A warning message is OK.
The current situation hides it as well, since it appears to work fine
until you hit the race, and suddenly things get stuck and it takes a lot of
digging to find out why.
> > > We make hard assumptions here and in various places actually.
> >
> > Are there any in the kernel that this doesn't cover?
>
> Check gtod implementation, I'm not sure whether that's enough at this
> stage or not for it, and then there's the vDSO of course.
I think the in-kernel gtod is OK after this patch (it breaks if it reads a
timestamp that is less than cycle_last).
The 32-bit vdso looks OK as is since it doesn't convert to nsec until after
adding to xtime. Userspace will still see time go backwards a bit if the
timebase does, but it shouldn't get a wildly wrong answer. The 64-bit vdso
uses srdi instead of sradi, and does so before adding to the upper
half of xtime, so if the race is hit the returned time will be too high by
2^32 seconds.
The problem in the in-kernel gettimeofday that causes it to be sensitive to
times less than cycles_last appears to be the same thing --
clocksource_cyc2ns() does an unsigned shift, even though it claims to be
returning a signed result.
> Not sure what's up with sched_clock() and whether that has similar constraints.
sched_clock() should be OK as long as the timestamp is always greater than
boot_tb, and hopefully any timebase skew is less than the delay from when
boot_tb is set to when secondary cores start up.
Delay loops could end early if they use unsigned comparisons, but only if
the timebase skew is greater than the time it takes to move a thread from
one cpu to another.
-Scott
^ permalink raw reply
* Re: perf_event_open system call support in powerpc
From: ashwath narasimhan @ 2011-06-29 18:35 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <BANLkTi=j1FwEv2tBmPck3GWHWgcYGchcew@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 754 bytes --]
Yep e500mc supports performance counters in hardware. Found the mapping for
the kernel call in /arch/powerpc/include/asm/systbl.h
On Tue, Jun 28, 2011 at 8:03 PM, ashwath narasimhan <
ashwath.narasimhan@oneconvergence.com> wrote:
> Hello,
>
> I am new to the powerpc architecture and I am trying to use
> perf_event_open() system call for power pc architecture (e500mc) using
> 2.6.32 kernel distribution. Is this system call number supported for power
> pc architecture? If yes, is there something similar to
> arch/x86/kernel/syscall_table_32.S listing for powerpc that indicates the
> number for the above system call?
>
> Thanks in advance for assisting me. Please email me at
> ashwath.narasimhan@oneconvergence.com
>
> --
> -Ash
>
--
-Ash
[-- Attachment #2: Type: text/html, Size: 1158 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] Add cpufreq driver for Momentum Maple boards
From: kevin diggs @ 2011-06-29 18:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Dmitry Eremin-Solenikov, Dave Jones, Paul Mackerras, linuxppc-dev,
cpufreq
In-Reply-To: <1309337670.14501.69.camel@pasglop>
Hi,
Try this one more time ...
On Wed, Jun 29, 2011 at 3:54 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Wed, 2011-06-29 at 12:40 +0400, Dmitry Eremin-Solenikov wrote:
>
> If you feel like it :-) The powermac one has quite a bit more plumbing
> for voltage control etc... but it does make sense in the long run.
>
On my G5 (PowerMac7,3?), a dual 970FX @ 2.5G, I don't think the
voltage scaling works correctly. If someone else with one of these
(preferably someone who is NOT swamped (and named Ben)) could run some
experiments. I would like to know whether the G5 I bought on ebay is
some "FrankenG5" and the others actually work correctly.
To summarize, if I disable frequency scaling and look at the cpu core
voltages it runs at the LOW voltage at full (i.e. 2.5 GHz) speed. With
frequency scaling enabled, it runs the low speed at the same voltage
it runs at 2.5 GHz without frequency scaling enabled. At the full
speed it switches to a higher voltage. It WILL overheat if allowed to
'do stuff'. Temps above 110 are observed for cpu 1 (the second cpu in
the serial (i.e. cpu 1 is heated by cpu 0) cooling setup - DUH!!!).
The two voltages are like ~1.23 and ~1.35.
Back when this beast had MacOS X, I think it exhibited similar
behavior based on the fan noise.
kevin
^ permalink raw reply
* Re: powerpc/4xx: Regression failed on sil24 (and other) drivers
From: Ayman El-Khashab @ 2011-06-29 18:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: cam, linuxppc-dev
In-Reply-To: <1309311723.32158.514.camel@pasglop>
On Wed, Jun 29, 2011 at 11:42:03AM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2011-06-27 at 06:31 -0500, Ayman El-Khashab wrote:
> > On Mon, Jun 27, 2011 at 08:19:56PM +1000, Benjamin Herrenschmidt wrote:
> > > On Sat, 2011-06-25 at 18:52 -0500, Ayman El-Khashab wrote:
> > > > I noticed during a recent development with the 460SX that a
> > > > simple device that once worked stopped. I did a bisect to
> > > > find the offending commit and it turns out to be this one:
> > > >
> > > > 0e52247a2ed1f211f0c4f682dc999610a368903f is the first bad
> > > > commit
> > > > commit 0e52247a2ed1f211f0c4f682dc999610a368903f
> > > > Author: Cam Macdonell <cam@cs.ualberta.ca>
> > > > Date: Tue Sep 7 17:25:20 2010 -0700
> > > >
> > > > PCI: fix pci_resource_alignment prototype
> > > >
>
....
>
> I suspect you don't have CONFIG_PCI_QUIRKS enabled... I think that's the
> cause of your problem.
>
> It looks like this config option controls both compiling the "generic"
> quirks in from drivers/pci/quirk.c, and the actually mechanism for
> having quirks in the first place (pci_fixup_device() goes away without
> that config option).
>
> I think we probably want to unconditionally select that if CONFIG_PCI is
> enabled in arch/powerpc...
>
> Can you try changing it and tell us if that helps ?
Yes, that fixed our problem, thanks for your time. I am
going to try to get the MSI to work.
Ayman
^ permalink raw reply
* Re: [PATCH 2/2] Add cpufreq driver for Momentum Maple boards
From: kevin diggs @ 2011-06-29 18:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Dmitry Eremin-Solenikov, Dave Jones, Paul Mackerras, linuxppc-dev,
cpufreq
In-Reply-To: <1309318110.32158.520.camel@pasglop>
Hi,
On Tue, Jun 28, 2011 at 10:28 PM, Benjamin Herrenschmidt >
>
> If we're going to have a Kconfig.powerpc, should we maybe just have a
> powerpc subdirectory instead with the driver in it ?
>
Where would the powerpc subdirectory be? under drivers/cpufreq? Or
somewhere under arch/powerpc where it belongs (and I put my 750GX
stuff)?
>
>> + =A0 =A0 printk(KERN_INFO "Frequency method: SCOM, Voltage method: none=
\n");
>
> This is useless.
>
Why?
> Cheers,
> Ben.
>
kevin
^ permalink raw reply
* Re: [PATCH 1/2] mtd/nand : don't free the global data fsl_lbc_ctrl_dev->nand in fsl_elbc_chip_remove()
From: Scott Wood @ 2011-06-29 16:45 UTC (permalink / raw)
To: dedekind1; +Cc: linuxppc-dev, b35362, dwmw2, linux-mtd
In-Reply-To: <1309328435.23597.104.camel@sauron>
On Wed, 29 Jun 2011 09:20:25 +0300
Artem Bityutskiy <dedekind1@gmail.com> wrote:
> On Tue, 2011-06-28 at 09:50 +0800, b35362@freescale.com wrote:
> > From: Liu Shuo <b35362@freescale.com>
> >
> > The global data fsl_lbc_ctrl_dev->nand don't have to be freed in
> > fsl_elbc_chip_remove(). The right place to do that is in fsl_elbc_nand_remove()
> > if elbc_fcm_ctrl->counter is zero.
> >
> > Signed-off-by: Liu Shuo <b35362@freescale.com>
> > ---
> > drivers/mtd/nand/fsl_elbc_nand.c | 1 -
> > 1 files changed, 0 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/mtd/nand/fsl_elbc_nand.c b/drivers/mtd/nand/fsl_elbc_nand.c
> > index 0bb254c..a212116 100644
> > --- a/drivers/mtd/nand/fsl_elbc_nand.c
> > +++ b/drivers/mtd/nand/fsl_elbc_nand.c
> > @@ -829,7 +829,6 @@ static int fsl_elbc_chip_remove(struct fsl_elbc_mtd *priv)
> >
> > elbc_fcm_ctrl->chips[priv->bank] = NULL;
> > kfree(priv);
> > - kfree(elbc_fcm_ctrl);
> > return 0;
> > }
>
> Do we have to assign fsl_lbc_ctrl_dev->nand to NULL in
> fsl_elbc_nand_remove() then? I think that assignment can be killed then.
>
> if (!elbc_fcm_ctrl->counter) {
> fsl_lbc_ctrl_dev->nand = NULL;
> kfree(elbc_fcm_ctrl);
> }
>
If we're freeing fsl_lbc_ctrl, we'd better get rid of references to it...
-Scott
^ permalink raw reply
* Re: [PATCH 2/2] mtd/nand : workaround for Freescale FCM to support large-page Nand chip
From: Scott Wood @ 2011-06-29 16:43 UTC (permalink / raw)
To: dedekind1; +Cc: linuxppc-dev, b35362, dwmw2, linux-mtd
In-Reply-To: <1309328529.23597.106.camel@sauron>
On Wed, 29 Jun 2011 09:22:04 +0300
Artem Bityutskiy <dedekind1@gmail.com> wrote:
> On Tue, 2011-06-28 at 09:50 +0800, b35362@freescale.com wrote:
> > + /* Hack for supporting the flash chip whose writesize is
> > + * larger than 2K bytes.
> > + */
>
> Please, use proper kernel multi-line comments. Please, make sure
> checkpatch.pl does not generate 13 errors with this patch.
Most of the checkpatch complaints are about existing style in the file --
particularly, the use of tabs only for indentation, with spaces used for
alignment beyond the indentation point.
-Scott
^ permalink raw reply
* Re: [PATCH v4]PPC4xx: Adding PCI(E) MSI support
From: Ayman El-Khashab @ 2011-06-29 15:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Rupjyoti Sarmah, rsarmah, linux-kernel
In-Reply-To: <1309302928.32158.470.camel@pasglop>
On Wed, Jun 29, 2011 at 09:15:28AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2011-06-28 at 17:31 -0500, Ayman El-Khashab wrote:
> > > > +static int ppc4xx_setup_pcieh_hw(struct platform_device *dev,
> > > > + struct resource res, struct
> > ppc4xx_msi *msi)
> > > > +{
> > > > +
> >
> > <snip>
> >
> > > > +
> > > > + msi->msi_dev = of_find_node_by_name(NULL, "ppc4xx-msi");
> > > > + if (msi->msi_dev)
> > > > + return -ENODEV;
> >
> > This does not look correct. I guess it should probably read
> >
> > if (!msi->msi_dev) .....
>
> Indeed, that looks bogus. Rupjyoti, please test and send fixes if
> necessary, obviously this code has not been tested.
>
> This is not part of the bits I fixed up so I looks to me like the
> original patch was wrong (and thus obviously untested !!!)
>
Looking back through the mailing list, there have been
various incarnations of this patch to add MSI support to the
44x. Every one that I looked at had this same line of code
in it so I am not sure they worked. In any case I am trying
to make it work on my system (which is how I found the bug).
When I enable the "sdr-base" line in the MSI section of my
dts, it just reboots continuosly right after "Loading Device
Tree ....". I tried renaming it to "msi-sdr-base" just in
case there was a conflict (since it is reading through the
entire tree) but that did not help. If I understand
correctly, the ppc4xx_msi_probe function must be executing
very early since I suspect something in setup_pcieh_hw is
what causes it to fail.
ayman
^ permalink raw reply
* [PATCH V4 2/2] Add cpufreq driver for Momentum Maple boards
From: Dmitry Eremin-Solenikov @ 2011-06-29 15:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, cpufreq, Dave Jones
In-Reply-To: <1309360076-22579-1-git-send-email-dbaryshkov@gmail.com>
Add simple cpufreq driver for Maple-based boards (ppc970fx evaluation
kit and others). Driver is based on a cpufreq driver for 64-bit powermac
boxes with all pmac-dependant features removed and simple cleanup
applied.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
drivers/cpufreq/Kconfig | 5 +
drivers/cpufreq/Kconfig.powerpc | 7 +
drivers/cpufreq/Makefile | 5 +
drivers/cpufreq/maple-cpufreq.c | 309 +++++++++++++++++++++++++++++++++++++++
4 files changed, 326 insertions(+), 0 deletions(-)
create mode 100644 drivers/cpufreq/Kconfig.powerpc
create mode 100644 drivers/cpufreq/maple-cpufreq.c
diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index 9fb8485..61ae639 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -184,5 +184,10 @@ depends on X86
source "drivers/cpufreq/Kconfig.x86"
endmenu
+menu "PowerPC CPU frequency scaling drivers"
+depends on PPC32 || PPC64
+source "drivers/cpufreq/Kconfig.powerpc"
+endmenu
+
endif
endmenu
diff --git a/drivers/cpufreq/Kconfig.powerpc b/drivers/cpufreq/Kconfig.powerpc
new file mode 100644
index 0000000..e76992f
--- /dev/null
+++ b/drivers/cpufreq/Kconfig.powerpc
@@ -0,0 +1,7 @@
+config CPU_FREQ_MAPLE
+ bool "Support for Maple 970FX Evaluation Board"
+ depends on PPC_MAPLE
+ select CPU_FREQ_TABLE
+ help
+ This adds support for frequency switching on Maple 970FX
+ Evaluation Board and compatible boards (IBM JS2x blades).
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index e2fc2d2..ca3796d 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -41,3 +41,8 @@ obj-$(CONFIG_X86_CPUFREQ_NFORCE2) += cpufreq-nforce2.o
# ARM SoC drivers
obj-$(CONFIG_UX500_SOC_DB8500) += db8500-cpufreq.o
+
+
+##################################################################################d
+# PowerPC platform drivers
+obj-$(CONFIG_CPU_FREQ_MAPLE) += maple-cpufreq.o
diff --git a/drivers/cpufreq/maple-cpufreq.c b/drivers/cpufreq/maple-cpufreq.c
new file mode 100644
index 0000000..89b178a
--- /dev/null
+++ b/drivers/cpufreq/maple-cpufreq.c
@@ -0,0 +1,309 @@
+/*
+ * Copyright (C) 2011 Dmitry Eremin-Solenikov
+ * Copyright (C) 2002 - 2005 Benjamin Herrenschmidt <benh@kernel.crashing.org>
+ * and Markus Demleitner <msdemlei@cl.uni-heidelberg.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This driver adds basic cpufreq support for SMU & 970FX based G5 Macs,
+ * that is iMac G5 and latest single CPU desktop.
+ */
+
+#undef DEBUG
+
+#include <linux/module.h>
+#include <linux/types.h>
+#include <linux/errno.h>
+#include <linux/kernel.h>
+#include <linux/delay.h>
+#include <linux/sched.h>
+#include <linux/cpufreq.h>
+#include <linux/init.h>
+#include <linux/completion.h>
+#include <linux/mutex.h>
+#include <linux/time.h>
+#include <linux/of.h>
+
+#define DBG(fmt...) pr_debug(fmt)
+
+/* see 970FX user manual */
+
+#define SCOM_PCR 0x0aa001 /* PCR scom addr */
+
+#define PCR_HILO_SELECT 0x80000000U /* 1 = PCR, 0 = PCRH */
+#define PCR_SPEED_FULL 0x00000000U /* 1:1 speed value */
+#define PCR_SPEED_HALF 0x00020000U /* 1:2 speed value */
+#define PCR_SPEED_QUARTER 0x00040000U /* 1:4 speed value */
+#define PCR_SPEED_MASK 0x000e0000U /* speed mask */
+#define PCR_SPEED_SHIFT 17
+#define PCR_FREQ_REQ_VALID 0x00010000U /* freq request valid */
+#define PCR_VOLT_REQ_VALID 0x00008000U /* volt request valid */
+#define PCR_TARGET_TIME_MASK 0x00006000U /* target time */
+#define PCR_STATLAT_MASK 0x00001f00U /* STATLAT value */
+#define PCR_SNOOPLAT_MASK 0x000000f0U /* SNOOPLAT value */
+#define PCR_SNOOPACC_MASK 0x0000000fU /* SNOOPACC value */
+
+#define SCOM_PSR 0x408001 /* PSR scom addr */
+/* warning: PSR is a 64 bits register */
+#define PSR_CMD_RECEIVED 0x2000000000000000U /* command received */
+#define PSR_CMD_COMPLETED 0x1000000000000000U /* command completed */
+#define PSR_CUR_SPEED_MASK 0x0300000000000000U /* current speed */
+#define PSR_CUR_SPEED_SHIFT (56)
+
+/*
+ * The G5 only supports two frequencies (Quarter speed is not supported)
+ */
+#define CPUFREQ_HIGH 0
+#define CPUFREQ_LOW 1
+
+static struct cpufreq_frequency_table maple_cpu_freqs[] = {
+ {CPUFREQ_HIGH, 0},
+ {CPUFREQ_LOW, 0},
+ {0, CPUFREQ_TABLE_END},
+};
+
+static struct freq_attr *maple_cpu_freqs_attr[] = {
+ &cpufreq_freq_attr_scaling_available_freqs,
+ NULL,
+};
+
+/* Power mode data is an array of the 32 bits PCR values to use for
+ * the various frequencies, retrieved from the device-tree
+ */
+static int maple_pmode_cur;
+
+static DEFINE_MUTEX(maple_switch_mutex);
+
+static const u32 *maple_pmode_data;
+static int maple_pmode_max;
+
+/*
+ * SCOM based frequency switching for 970FX rev3
+ */
+static int maple_scom_switch_freq(int speed_mode)
+{
+ unsigned long flags;
+ int to;
+
+ local_irq_save(flags);
+
+ /* Clear PCR high */
+ scom970_write(SCOM_PCR, 0);
+ /* Clear PCR low */
+ scom970_write(SCOM_PCR, PCR_HILO_SELECT | 0);
+ /* Set PCR low */
+ scom970_write(SCOM_PCR, PCR_HILO_SELECT |
+ maple_pmode_data[speed_mode]);
+
+ /* Wait for completion */
+ for (to = 0; to < 10; to++) {
+ unsigned long psr = scom970_read(SCOM_PSR);
+
+ if ((psr & PSR_CMD_RECEIVED) == 0 &&
+ (((psr >> PSR_CUR_SPEED_SHIFT) ^
+ (maple_pmode_data[speed_mode] >> PCR_SPEED_SHIFT)) & 0x3)
+ == 0)
+ break;
+ if (psr & PSR_CMD_COMPLETED)
+ break;
+ udelay(100);
+ }
+
+ local_irq_restore(flags);
+
+ maple_pmode_cur = speed_mode;
+ ppc_proc_freq = maple_cpu_freqs[speed_mode].frequency * 1000ul;
+
+ return 0;
+}
+
+static int maple_scom_query_freq(void)
+{
+ unsigned long psr = scom970_read(SCOM_PSR);
+ int i;
+
+ for (i = 0; i <= maple_pmode_max; i++)
+ if ((((psr >> PSR_CUR_SPEED_SHIFT) ^
+ (maple_pmode_data[i] >> PCR_SPEED_SHIFT)) & 0x3) == 0)
+ break;
+ return i;
+}
+
+/*
+ * Common interface to the cpufreq core
+ */
+
+static int maple_cpufreq_verify(struct cpufreq_policy *policy)
+{
+ return cpufreq_frequency_table_verify(policy, maple_cpu_freqs);
+}
+
+static int maple_cpufreq_target(struct cpufreq_policy *policy,
+ unsigned int target_freq, unsigned int relation)
+{
+ unsigned int newstate = 0;
+ struct cpufreq_freqs freqs;
+ int rc;
+
+ if (cpufreq_frequency_table_target(policy, maple_cpu_freqs,
+ target_freq, relation, &newstate))
+ return -EINVAL;
+
+ if (maple_pmode_cur == newstate)
+ return 0;
+
+ mutex_lock(&maple_switch_mutex);
+
+ freqs.old = maple_cpu_freqs[maple_pmode_cur].frequency;
+ freqs.new = maple_cpu_freqs[newstate].frequency;
+ freqs.cpu = 0;
+
+ cpufreq_notify_transition(&freqs, CPUFREQ_PRECHANGE);
+ rc = maple_scom_switch_freq(newstate);
+ cpufreq_notify_transition(&freqs, CPUFREQ_POSTCHANGE);
+
+ mutex_unlock(&maple_switch_mutex);
+
+ return rc;
+}
+
+static unsigned int maple_cpufreq_get_speed(unsigned int cpu)
+{
+ return maple_cpu_freqs[maple_pmode_cur].frequency;
+}
+
+static int maple_cpufreq_cpu_init(struct cpufreq_policy *policy)
+{
+ policy->cpuinfo.transition_latency = 12000;
+ policy->cur = maple_cpu_freqs[maple_scom_query_freq()].frequency;
+ /* secondary CPUs are tied to the primary one by the
+ * cpufreq core if in the secondary policy we tell it that
+ * it actually must be one policy together with all others. */
+ cpumask_copy(policy->cpus, cpu_online_mask);
+ cpufreq_frequency_table_get_attr(maple_cpu_freqs, policy->cpu);
+
+ return cpufreq_frequency_table_cpuinfo(policy,
+ maple_cpu_freqs);
+}
+
+
+static struct cpufreq_driver maple_cpufreq_driver = {
+ .name = "maple",
+ .owner = THIS_MODULE,
+ .flags = CPUFREQ_CONST_LOOPS,
+ .init = maple_cpufreq_cpu_init,
+ .verify = maple_cpufreq_verify,
+ .target = maple_cpufreq_target,
+ .get = maple_cpufreq_get_speed,
+ .attr = maple_cpu_freqs_attr,
+};
+
+static int __init maple_cpufreq_init(void)
+{
+ struct device_node *cpus;
+ struct device_node *cpunode;
+ unsigned int psize;
+ unsigned long max_freq;
+ const u32 *valp;
+ u32 pvr_hi;
+ int rc = -ENODEV;
+
+ /*
+ * Behave here like powermac driver which checks machine compatibility
+ * to ease merging of two drivers in future.
+ */
+ if (!of_machine_is_compatible("Momentum,Maple") &&
+ !of_machine_is_compatible("Momentum,Apache"))
+ return 0;
+
+ cpus = of_find_node_by_path("/cpus");
+ if (cpus == NULL) {
+ DBG("No /cpus node !\n");
+ return -ENODEV;
+ }
+
+ /* Get first CPU node */
+ for (cpunode = NULL;
+ (cpunode = of_get_next_child(cpus, cpunode)) != NULL;) {
+ const u32 *reg = of_get_property(cpunode, "reg", NULL);
+ if (reg == NULL || (*reg) != 0)
+ continue;
+ if (!strcmp(cpunode->type, "cpu"))
+ break;
+ }
+ if (cpunode == NULL) {
+ printk(KERN_ERR "cpufreq: Can't find any CPU 0 node\n");
+ goto bail_cpus;
+ }
+
+ /* Check 970FX for now */
+ /* we actually don't care on which CPU to access PVR */
+ pvr_hi = PVR_VER(mfspr(SPRN_PVR));
+ if (pvr_hi != 0x3c && pvr_hi != 0x44) {
+ printk(KERN_ERR "cpufreq: Unsupported CPU version (%x)\n",
+ pvr_hi);
+ goto bail_noprops;
+ }
+
+ /* Look for the powertune data in the device-tree */
+ /*
+ * On Maple this property is provided by PIBS in dual-processor config,
+ * not provided by PIBS in CPU0 config and also not provided by SLOF,
+ * so YMMV
+ */
+ maple_pmode_data = of_get_property(cpunode, "power-mode-data", &psize);
+ if (!maple_pmode_data) {
+ DBG("No power-mode-data !\n");
+ goto bail_noprops;
+ }
+ maple_pmode_max = psize / sizeof(u32) - 1;
+
+ /*
+ * From what I see, clock-frequency is always the maximal frequency.
+ * The current driver can not slew sysclk yet, so we really only deal
+ * with powertune steps for now. We also only implement full freq and
+ * half freq in this version. So far, I haven't yet seen a machine
+ * supporting anything else.
+ */
+ valp = of_get_property(cpunode, "clock-frequency", NULL);
+ if (!valp)
+ return -ENODEV;
+ max_freq = (*valp)/1000;
+ maple_cpu_freqs[0].frequency = max_freq;
+ maple_cpu_freqs[1].frequency = max_freq/2;
+
+ /* Force apply current frequency to make sure everything is in
+ * sync (voltage is right for example). Firmware may leave us with
+ * a strange setting ...
+ */
+ msleep(10);
+ maple_pmode_cur = -1;
+ maple_scom_switch_freq(maple_scom_query_freq());
+
+ printk(KERN_INFO "Registering Maple CPU frequency driver\n");
+ printk(KERN_INFO "Low: %d Mhz, High: %d Mhz, Cur: %d MHz\n",
+ maple_cpu_freqs[1].frequency/1000,
+ maple_cpu_freqs[0].frequency/1000,
+ maple_cpu_freqs[maple_pmode_cur].frequency/1000);
+
+ rc = cpufreq_register_driver(&maple_cpufreq_driver);
+
+ of_node_put(cpunode);
+ of_node_put(cpus);
+
+ return rc;
+
+bail_noprops:
+ of_node_put(cpunode);
+bail_cpus:
+ of_node_put(cpus);
+
+ return rc;
+}
+
+module_init(maple_cpufreq_init);
+
+
+MODULE_LICENSE("GPL");
--
1.7.5.4
^ permalink raw reply related
* [PATCH V4 1/2] ppc: enable scom access functions on Maple
From: Dmitry Eremin-Solenikov @ 2011-06-29 15:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, cpufreq, Dave Jones
In-Reply-To: <1309360076-22579-1-git-send-email-dbaryshkov@gmail.com>
Enable functions used to access SCOM if PPC_MAPLE is defined: they are
used by cpufreq driver to control hardware.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
arch/powerpc/kernel/misc_64.S | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S
index e89df59..616921e 100644
--- a/arch/powerpc/kernel/misc_64.S
+++ b/arch/powerpc/kernel/misc_64.S
@@ -339,7 +339,7 @@ _GLOBAL(real_205_writeb)
#endif /* CONFIG_PPC_PASEMI */
-#ifdef CONFIG_CPU_FREQ_PMAC64
+#if defined(CONFIG_CPU_FREQ_PMAC64) || defined(CONFIG_CPU_FREQ_MAPLE)
/*
* SCOM access functions for 970 (FX only for now)
*
@@ -408,7 +408,7 @@ _GLOBAL(scom970_write)
/* restore interrupts */
mtmsrd r5,1
blr
-#endif /* CONFIG_CPU_FREQ_PMAC64 */
+#endif /* CONFIG_CPU_FREQ_PMAC64 || CONFIG_CPU_FREQ_MAPLE */
/*
--
1.7.5.4
^ permalink raw reply related
* [PATCH V4 0/2] Add cpufreq driver for Momentum Maple platform
From: Dmitry Eremin-Solenikov @ 2011-06-29 15:07 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras, cpufreq, Dave Jones
Please merge this patchset, adding a cpufreq driver for Momentum Maple
platform. Changes since V3:
* Add comment regarding power-mode-data
* Adjusted kernel output a bit
* Tied the driver to compatible platforms only (as per
arch/powerpc/platforms/maple/setup.c)
Dmitry Eremin-Solenikov (2):
ppc: enable scom access functions on Maple
Add cpufreq driver for Momentum Maple boards
arch/powerpc/kernel/misc_64.S | 4 +-
drivers/cpufreq/Kconfig | 5 +
drivers/cpufreq/Kconfig.powerpc | 7 +
drivers/cpufreq/Makefile | 5 +
drivers/cpufreq/maple-cpufreq.c | 309 +++++++++++++++++++++++++++++++++++++++
5 files changed, 328 insertions(+), 2 deletions(-)
create mode 100644 drivers/cpufreq/Kconfig.powerpc
create mode 100644 drivers/cpufreq/maple-cpufreq.c
^ permalink raw reply
* [PATCH] powerpc: correct annotations of pmu registration functions
From: Dmitry Eremin-Solenikov @ 2011-06-29 14:54 UTC (permalink / raw)
To: linuxppc-dev
This fixes the following warning:
WARNING: arch/powerpc/kernel/built-in.o(.text+0x29768): Section mismatch in reference from the function .register_power_pmu() to the function .cpuinit.text:.power_pmu_notifier()
The function .register_power_pmu() references
the function __cpuinit .power_pmu_notifier().
This is often because .register_power_pmu lacks a __cpuinit
annotation or the annotation of .power_pmu_notifier is wrong.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
arch/powerpc/kernel/mpc7450-pmu.c | 2 +-
arch/powerpc/kernel/perf_event.c | 2 +-
arch/powerpc/kernel/power4-pmu.c | 2 +-
arch/powerpc/kernel/power5+-pmu.c | 2 +-
arch/powerpc/kernel/power5-pmu.c | 2 +-
arch/powerpc/kernel/power6-pmu.c | 2 +-
arch/powerpc/kernel/power7-pmu.c | 2 +-
arch/powerpc/kernel/ppc970-pmu.c | 2 +-
8 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/kernel/mpc7450-pmu.c b/arch/powerpc/kernel/mpc7450-pmu.c
index 2cc5e03..a6de23d 100644
--- a/arch/powerpc/kernel/mpc7450-pmu.c
+++ b/arch/powerpc/kernel/mpc7450-pmu.c
@@ -405,7 +405,7 @@ struct power_pmu mpc7450_pmu = {
.cache_events = &mpc7450_cache_events,
};
-static int init_mpc7450_pmu(void)
+static int __init init_mpc7450_pmu(void)
{
if (!cur_cpu_spec->oprofile_cpu_type ||
strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc/7450"))
diff --git a/arch/powerpc/kernel/perf_event.c b/arch/powerpc/kernel/perf_event.c
index 822f630..31ab78f 100644
--- a/arch/powerpc/kernel/perf_event.c
+++ b/arch/powerpc/kernel/perf_event.c
@@ -1408,7 +1408,7 @@ power_pmu_notifier(struct notifier_block *self, unsigned long action, void *hcpu
return NOTIFY_OK;
}
-int register_power_pmu(struct power_pmu *pmu)
+int __cpuinit register_power_pmu(struct power_pmu *pmu)
{
if (ppmu)
return -EBUSY; /* something's already registered */
diff --git a/arch/powerpc/kernel/power4-pmu.c b/arch/powerpc/kernel/power4-pmu.c
index ead8b3c..4eb7095 100644
--- a/arch/powerpc/kernel/power4-pmu.c
+++ b/arch/powerpc/kernel/power4-pmu.c
@@ -604,7 +604,7 @@ static struct power_pmu power4_pmu = {
.cache_events = &power4_cache_events,
};
-static int init_power4_pmu(void)
+static int __init init_power4_pmu(void)
{
if (!cur_cpu_spec->oprofile_cpu_type ||
strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/power4"))
diff --git a/arch/powerpc/kernel/power5+-pmu.c b/arch/powerpc/kernel/power5+-pmu.c
index eca0ac5..23aaadb 100644
--- a/arch/powerpc/kernel/power5+-pmu.c
+++ b/arch/powerpc/kernel/power5+-pmu.c
@@ -672,7 +672,7 @@ static struct power_pmu power5p_pmu = {
.cache_events = &power5p_cache_events,
};
-static int init_power5p_pmu(void)
+static int __init init_power5p_pmu(void)
{
if (!cur_cpu_spec->oprofile_cpu_type ||
(strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/power5+")
diff --git a/arch/powerpc/kernel/power5-pmu.c b/arch/powerpc/kernel/power5-pmu.c
index d5ff0f6..589e49a 100644
--- a/arch/powerpc/kernel/power5-pmu.c
+++ b/arch/powerpc/kernel/power5-pmu.c
@@ -612,7 +612,7 @@ static struct power_pmu power5_pmu = {
.cache_events = &power5_cache_events,
};
-static int init_power5_pmu(void)
+static int __init init_power5_pmu(void)
{
if (!cur_cpu_spec->oprofile_cpu_type ||
strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/power5"))
diff --git a/arch/powerpc/kernel/power6-pmu.c b/arch/powerpc/kernel/power6-pmu.c
index 3160392..e13dcda 100644
--- a/arch/powerpc/kernel/power6-pmu.c
+++ b/arch/powerpc/kernel/power6-pmu.c
@@ -535,7 +535,7 @@ static struct power_pmu power6_pmu = {
.cache_events = &power6_cache_events,
};
-static int init_power6_pmu(void)
+static int __init init_power6_pmu(void)
{
if (!cur_cpu_spec->oprofile_cpu_type ||
strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/power6"))
diff --git a/arch/powerpc/kernel/power7-pmu.c b/arch/powerpc/kernel/power7-pmu.c
index 593740f..8123040 100644
--- a/arch/powerpc/kernel/power7-pmu.c
+++ b/arch/powerpc/kernel/power7-pmu.c
@@ -360,7 +360,7 @@ static struct power_pmu power7_pmu = {
.cache_events = &power7_cache_events,
};
-static int init_power7_pmu(void)
+static int __init init_power7_pmu(void)
{
if (!cur_cpu_spec->oprofile_cpu_type ||
strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/power7"))
diff --git a/arch/powerpc/kernel/ppc970-pmu.c b/arch/powerpc/kernel/ppc970-pmu.c
index 9a6e093..45d7879 100644
--- a/arch/powerpc/kernel/ppc970-pmu.c
+++ b/arch/powerpc/kernel/ppc970-pmu.c
@@ -484,7 +484,7 @@ static struct power_pmu ppc970_pmu = {
.cache_events = &ppc970_cache_events,
};
-static int init_ppc970_pmu(void)
+static int __init init_ppc970_pmu(void)
{
if (!cur_cpu_spec->oprofile_cpu_type ||
(strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc64/970")
--
1.7.5.4
^ permalink raw reply related
* [PATCH] powerpc: enable access to HT Host-Bridge on Maple
From: Dmitry Eremin-Solenikov @ 2011-06-29 14:17 UTC (permalink / raw)
To: linuxppc-dev
CPC925/CPC945 use special window to access host bridge functionality of
u3-ht. Provide a way to access this device.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
---
arch/powerpc/platforms/maple/pci.c | 55 ++++++++++++++++++++++++++++++++++++
1 files changed, 55 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/platforms/maple/pci.c b/arch/powerpc/platforms/maple/pci.c
index dd2e48b..401e3f3 100644
--- a/arch/powerpc/platforms/maple/pci.c
+++ b/arch/powerpc/platforms/maple/pci.c
@@ -207,6 +207,54 @@ static volatile void __iomem *u3_ht_cfg_access(struct pci_controller* hose,
return hose->cfg_data + u3_ht_cfa1(bus, devfn, offset);
}
+static int u3_ht_root_read_config(struct pci_controller *hose, u8 offset,
+ int len, u32 *val)
+{
+ volatile void __iomem *addr;
+
+ addr = hose->cfg_addr;
+ addr += ((offset & ~3) << 2) + (4 - len - (offset & 3));
+
+ switch (len) {
+ case 1:
+ *val = in_8(addr);
+ break;
+ case 2:
+ *val = in_be16(addr);
+ break;
+ default:
+ *val = in_be32(addr);
+ break;
+ }
+
+ return PCIBIOS_SUCCESSFUL;
+}
+
+static int u3_ht_root_write_config(struct pci_controller *hose, u8 offset,
+ int len, u32 val)
+{
+ volatile void __iomem *addr;
+
+ addr = hose->cfg_addr + ((offset & ~3) << 2) + (4 - len - (offset & 3));
+
+ if (offset >= PCI_BASE_ADDRESS_0 && offset < PCI_CAPABILITY_LIST)
+ return PCIBIOS_SUCCESSFUL;
+
+ switch (len) {
+ case 1:
+ out_8(addr, val);
+ break;
+ case 2:
+ out_be16(addr, val);
+ break;
+ default:
+ out_be32(addr, val);
+ break;
+ }
+
+ return PCIBIOS_SUCCESSFUL;
+}
+
static int u3_ht_read_config(struct pci_bus *bus, unsigned int devfn,
int offset, int len, u32 *val)
{
@@ -217,6 +265,9 @@ static int u3_ht_read_config(struct pci_bus *bus, unsigned int devfn,
if (hose == NULL)
return PCIBIOS_DEVICE_NOT_FOUND;
+ if (bus->number == hose->first_busno && devfn == PCI_DEVFN(0, 0))
+ return u3_ht_root_read_config(hose, offset, len, val);
+
if (offset > 0xff)
return PCIBIOS_BAD_REGISTER_NUMBER;
@@ -252,6 +303,9 @@ static int u3_ht_write_config(struct pci_bus *bus, unsigned int devfn,
if (hose == NULL)
return PCIBIOS_DEVICE_NOT_FOUND;
+ if (bus->number == hose->first_busno && devfn == PCI_DEVFN(0, 0))
+ return u3_ht_root_write_config(hose, offset, len, val);
+
if (offset > 0xff)
return PCIBIOS_BAD_REGISTER_NUMBER;
@@ -428,6 +482,7 @@ static void __init setup_u3_ht(struct pci_controller* hose)
* reg_property and using some accessor functions instead
*/
hose->cfg_data = ioremap(0xf2000000, 0x02000000);
+ hose->cfg_addr = ioremap(0xf8070000, 0x1000);
hose->first_busno = 0;
hose->last_busno = 0xef;
--
1.7.5.4
^ permalink raw reply related
* [PATCH net-next] net: ucc_geth: Omit check for multicast bit in netdev_for_each_mc_addr
From: Tobias Klauser @ 2011-06-29 12:16 UTC (permalink / raw)
To: David S. Miller, Li Yang; +Cc: netdev, linuxppc-dev
There is no need to check for the address being a multicast address in
the netdev_for_each_mc_addr loop, so remove it.
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
drivers/net/ucc_geth.c | 5 -----
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ucc_geth.c b/drivers/net/ucc_geth.c
index 3127700..d3465ab 100644
--- a/drivers/net/ucc_geth.c
+++ b/drivers/net/ucc_geth.c
@@ -2030,11 +2030,6 @@ static void ucc_geth_set_multi(struct net_device *dev)
out_be32(&p_82xx_addr_filt->gaddr_l, 0x0);
netdev_for_each_mc_addr(ha, dev) {
- /* Only support group multicast for now.
- */
- if (!is_multicast_ether_addr(ha->addr))
- continue;
-
/* Ask CPM to run CRC and set bit in
* filter mask.
*/
--
1.7.5.4
^ permalink raw reply related
* Re: [RFC PATCH 17/17] KVM: PPC: Add an ioctl for userspace to select which platform to emulate
From: Josh Boyer @ 2011-06-29 11:58 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev, Paul Mackerras, kvm-ppc, kvm
In-Reply-To: <B21FDD77-90CF-4A23-84E3-8C73CFF70B92@suse.de>
On Wed, Jun 29, 2011 at 01:56:16PM +0200, Alexander Graf wrote:
>
>On 29.06.2011, at 13:53, Josh Boyer wrote:
>
>> On Wed, Jun 29, 2011 at 08:41:03PM +1000, Paul Mackerras wrote:
>>> Documentation/virtual/kvm/api.txt | 35 +++++++++++++++++++++++++++++++++++
>>> arch/powerpc/include/asm/kvm.h | 15 +++++++++++++++
>>> arch/powerpc/include/asm/kvm_host.h | 1 +
>>> arch/powerpc/kvm/powerpc.c | 28 ++++++++++++++++++++++++++++
>>> include/linux/kvm.h | 1 +
>>> 5 files changed, 80 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
>>> index b0e4b9c..3ab012c 100644
>>> --- a/Documentation/virtual/kvm/api.txt
>>> +++ b/Documentation/virtual/kvm/api.txt
>>> @@ -1430,6 +1430,41 @@ is supported; 2 if the processor requires all virtual machines to have
>>> an RMA, or 1 if the processor can use an RMA but doesn't require it,
>>> because it supports the Virtual RMA (VRMA) facility.
>>>
>>> +4.64 KVM_PPC_SET_PLATFORM
>>> +
>>> +Capability: none
>>> +Architectures: powerpc
>>> +Type: vm ioctl
>>> +Parameters: struct kvm_ppc_set_platform (in)
>>> +Returns: 0, or -1 on error
>>> +
>>> +This is used by userspace to tell KVM what sort of platform it should
>>> +emulate. The return value of the ioctl tells userspace whether the
>>> +emulation it is requesting is supported by KVM.
>>> +
>>> +struct kvm_ppc_set_platform {
>>> + __u16 platform; /* defines the OS/hypervisor ABI */
>>> + __u16 guest_arch; /* e.g. decimal 206 for v2.06 */
>>> + __u32 flags;
>>> +};
>>> +
>>> +/* Values for platform */
>>> +#define KVM_PPC_PV_NONE 0 /* bare-metal, non-paravirtualized */
>>> +#define KVM_PPC_PV_KVM 1 /* as defined in kvm_para.h */
>>> +#define KVM_PPC_PV_SPAPR 2 /* IBM Server PAPR (a la PowerVM) */
>>> +
>>> +/* Values for flags */
>>> +#define KVM_PPC_CROSS_ARCH 1 /* guest architecture != host */
>>> +
>>> +The KVM_PPC_CROSS_ARCH bit being 1 indicates that the guest is of a
>>> +sufficiently different architecture to the host that the guest cannot
>>> +be permitted to use supervisor mode. For example, if the host is a
>>> +64-bit machine and the guest is a 32-bit machine, then this bit should
>>> +be set.
>>
>> This makes me wonder if a similar thing might eventually be usable for
>> running an i686 or x32 guest on an x86_64 KVM host. I have no idea if
>> that is even theoretically possible, but if it is it might be better to
>> rename the ioctl to be architecture agnostic.
>
>On x86 this is not required unless we want to "virtualize" pre-CPUID CPUs. Everything as of Pentium has a full bitmap of feature capabilities that KVM gets from user space, including information such as "Can we do 64-bit mode?".
Ah. Thank you for the explanation.
josh
^ permalink raw reply
* Re: [RFC PATCH 17/17] KVM: PPC: Add an ioctl for userspace to select which platform to emulate
From: Alexander Graf @ 2011-06-29 11:56 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, Paul Mackerras, kvm-ppc, kvm
In-Reply-To: <20110629115346.GA17551@zod.rchland.ibm.com>
On 29.06.2011, at 13:53, Josh Boyer wrote:
> On Wed, Jun 29, 2011 at 08:41:03PM +1000, Paul Mackerras wrote:
>> Documentation/virtual/kvm/api.txt | 35 =
+++++++++++++++++++++++++++++++++++
>> arch/powerpc/include/asm/kvm.h | 15 +++++++++++++++
>> arch/powerpc/include/asm/kvm_host.h | 1 +
>> arch/powerpc/kvm/powerpc.c | 28 =
++++++++++++++++++++++++++++
>> include/linux/kvm.h | 1 +
>> 5 files changed, 80 insertions(+), 0 deletions(-)
>>=20
>> diff --git a/Documentation/virtual/kvm/api.txt =
b/Documentation/virtual/kvm/api.txt
>> index b0e4b9c..3ab012c 100644
>> --- a/Documentation/virtual/kvm/api.txt
>> +++ b/Documentation/virtual/kvm/api.txt
>> @@ -1430,6 +1430,41 @@ is supported; 2 if the processor requires all =
virtual machines to have
>> an RMA, or 1 if the processor can use an RMA but doesn't require it,
>> because it supports the Virtual RMA (VRMA) facility.
>>=20
>> +4.64 KVM_PPC_SET_PLATFORM
>> +
>> +Capability: none
>> +Architectures: powerpc
>> +Type: vm ioctl
>> +Parameters: struct kvm_ppc_set_platform (in)
>> +Returns: 0, or -1 on error
>> +
>> +This is used by userspace to tell KVM what sort of platform it =
should
>> +emulate. The return value of the ioctl tells userspace whether the
>> +emulation it is requesting is supported by KVM.
>> +
>> +struct kvm_ppc_set_platform {
>> + __u16 platform; /* defines the OS/hypervisor ABI */
>> + __u16 guest_arch; /* e.g. decimal 206 for v2.06 */
>> + __u32 flags;
>> +};
>> +
>> +/* Values for platform */
>> +#define KVM_PPC_PV_NONE 0 /* bare-metal, =
non-paravirtualized */
>> +#define KVM_PPC_PV_KVM 1 /* as defined in =
kvm_para.h */
>> +#define KVM_PPC_PV_SPAPR 2 /* IBM Server PAPR (a la =
PowerVM) */
>> +
>> +/* Values for flags */
>> +#define KVM_PPC_CROSS_ARCH 1 /* guest architecture !=3D host =
*/
>> +
>> +The KVM_PPC_CROSS_ARCH bit being 1 indicates that the guest is of a
>> +sufficiently different architecture to the host that the guest =
cannot
>> +be permitted to use supervisor mode. For example, if the host is a
>> +64-bit machine and the guest is a 32-bit machine, then this bit =
should
>> +be set.
>=20
> This makes me wonder if a similar thing might eventually be usable for
> running an i686 or x32 guest on an x86_64 KVM host. I have no idea if
> that is even theoretically possible, but if it is it might be better =
to
> rename the ioctl to be architecture agnostic.
On x86 this is not required unless we want to "virtualize" pre-CPUID =
CPUs. Everything as of Pentium has a full bitmap of feature capabilities =
that KVM gets from user space, including information such as "Can we do =
64-bit mode?".
Alex
^ permalink raw reply
* Re: [RFC PATCH 17/17] KVM: PPC: Add an ioctl for userspace to select which platform to emulate
From: Josh Boyer @ 2011-06-29 11:53 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, kvm-ppc, kvm, Alexander Graf
In-Reply-To: <20110629104103.GR25406@bloggs.ozlabs.ibm.com>
On Wed, Jun 29, 2011 at 08:41:03PM +1000, Paul Mackerras wrote:
> Documentation/virtual/kvm/api.txt | 35 +++++++++++++++++++++++++++++++++++
> arch/powerpc/include/asm/kvm.h | 15 +++++++++++++++
> arch/powerpc/include/asm/kvm_host.h | 1 +
> arch/powerpc/kvm/powerpc.c | 28 ++++++++++++++++++++++++++++
> include/linux/kvm.h | 1 +
> 5 files changed, 80 insertions(+), 0 deletions(-)
>
>diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
>index b0e4b9c..3ab012c 100644
>--- a/Documentation/virtual/kvm/api.txt
>+++ b/Documentation/virtual/kvm/api.txt
>@@ -1430,6 +1430,41 @@ is supported; 2 if the processor requires all virtual machines to have
> an RMA, or 1 if the processor can use an RMA but doesn't require it,
> because it supports the Virtual RMA (VRMA) facility.
>
>+4.64 KVM_PPC_SET_PLATFORM
>+
>+Capability: none
>+Architectures: powerpc
>+Type: vm ioctl
>+Parameters: struct kvm_ppc_set_platform (in)
>+Returns: 0, or -1 on error
>+
>+This is used by userspace to tell KVM what sort of platform it should
>+emulate. The return value of the ioctl tells userspace whether the
>+emulation it is requesting is supported by KVM.
>+
>+struct kvm_ppc_set_platform {
>+ __u16 platform; /* defines the OS/hypervisor ABI */
>+ __u16 guest_arch; /* e.g. decimal 206 for v2.06 */
>+ __u32 flags;
>+};
>+
>+/* Values for platform */
>+#define KVM_PPC_PV_NONE 0 /* bare-metal, non-paravirtualized */
>+#define KVM_PPC_PV_KVM 1 /* as defined in kvm_para.h */
>+#define KVM_PPC_PV_SPAPR 2 /* IBM Server PAPR (a la PowerVM) */
>+
>+/* Values for flags */
>+#define KVM_PPC_CROSS_ARCH 1 /* guest architecture != host */
>+
>+The KVM_PPC_CROSS_ARCH bit being 1 indicates that the guest is of a
>+sufficiently different architecture to the host that the guest cannot
>+be permitted to use supervisor mode. For example, if the host is a
>+64-bit machine and the guest is a 32-bit machine, then this bit should
>+be set.
This makes me wonder if a similar thing might eventually be usable for
running an i686 or x32 guest on an x86_64 KVM host. I have no idea if
that is even theoretically possible, but if it is it might be better to
rename the ioctl to be architecture agnostic.
josh
^ permalink raw reply
* [RFC PATCH 17/17] KVM: PPC: Add an ioctl for userspace to select which platform to emulate
From: Paul Mackerras @ 2011-06-29 10:41 UTC (permalink / raw)
To: linuxppc-dev, kvm, kvm-ppc, Alexander Graf
In-Reply-To: <20110629101552.GA25406@bloggs.ozlabs.ibm.com>
This new ioctl allows userspace to specify what paravirtualization
interface (if any) KVM should implement, what architecture version
the guest virtual processors should conform to, and whether the guest
can be permitted to use a real supervisor mode.
At present the only effect of the ioctl is to indicate whether the
requested emulation is available, but in future it may be used to
select between different emulation techniques (book3s_pr vs. book3s_hv)
or set the CPU compatibility mode for the guest.
If book3s_pr KVM is enabled in the kernel config, then this new
ioctl accepts platform values of KVM_PPC_PV_NONE and KVM_PPC_PV_KVM,
but not KVM_PPC_PV_SPAPR. If book3s_hv KVM is enabled, then this
ioctl requires that the platform is KVM_PPC_PV_SPAPR and the
guest_arch field contains one of 201 or 206 (for architecture versions
2.01 and 2.06) -- when running on a PPC970, it must contain 201, and
when running on a POWER7, it must contain 206.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
Documentation/virtual/kvm/api.txt | 35 +++++++++++++++++++++++++++++++++++
arch/powerpc/include/asm/kvm.h | 15 +++++++++++++++
arch/powerpc/include/asm/kvm_host.h | 1 +
arch/powerpc/kvm/powerpc.c | 28 ++++++++++++++++++++++++++++
include/linux/kvm.h | 1 +
5 files changed, 80 insertions(+), 0 deletions(-)
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index b0e4b9c..3ab012c 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -1430,6 +1430,41 @@ is supported; 2 if the processor requires all virtual machines to have
an RMA, or 1 if the processor can use an RMA but doesn't require it,
because it supports the Virtual RMA (VRMA) facility.
+4.64 KVM_PPC_SET_PLATFORM
+
+Capability: none
+Architectures: powerpc
+Type: vm ioctl
+Parameters: struct kvm_ppc_set_platform (in)
+Returns: 0, or -1 on error
+
+This is used by userspace to tell KVM what sort of platform it should
+emulate. The return value of the ioctl tells userspace whether the
+emulation it is requesting is supported by KVM.
+
+struct kvm_ppc_set_platform {
+ __u16 platform; /* defines the OS/hypervisor ABI */
+ __u16 guest_arch; /* e.g. decimal 206 for v2.06 */
+ __u32 flags;
+};
+
+/* Values for platform */
+#define KVM_PPC_PV_NONE 0 /* bare-metal, non-paravirtualized */
+#define KVM_PPC_PV_KVM 1 /* as defined in kvm_para.h */
+#define KVM_PPC_PV_SPAPR 2 /* IBM Server PAPR (a la PowerVM) */
+
+/* Values for flags */
+#define KVM_PPC_CROSS_ARCH 1 /* guest architecture != host */
+
+The KVM_PPC_CROSS_ARCH bit being 1 indicates that the guest is of a
+sufficiently different architecture to the host that the guest cannot
+be permitted to use supervisor mode. For example, if the host is a
+64-bit machine and the guest is a 32-bit machine, then this bit should
+be set.
+
+The return value is 0 if KVM supports the requested emulation, or -1
+with errno == EINVAL if not.
+
5. The kvm_run structure
Application code obtains a pointer to the kvm_run structure by
diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/asm/kvm.h
index a4f6c85..0dd5cfb 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -287,4 +287,19 @@ struct kvm_allocate_rma {
__u64 rma_size;
};
+/* for KVM_PPC_SET_PLATFORM */
+struct kvm_ppc_set_platform {
+ __u16 platform; /* defines the OS/hypervisor ABI */
+ __u16 guest_arch; /* e.g. decimal 206 for v2.06 */
+ __u32 flags;
+};
+
+/* Values for platform */
+#define KVM_PPC_PV_NONE 0 /* bare-metal, non-paravirtualized */
+#define KVM_PPC_PV_KVM 1 /* as defined in kvm_para.h */
+#define KVM_PPC_PV_SPAPR 2 /* IBM Server PAPR (a la PowerVM) */
+
+/* Values for flags */
+#define KVM_PPC_CROSS_ARCH 1 /* guest architecture != host */
+
#endif /* __LINUX_KVM_POWERPC_H */
diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index cc22b28..00e7f1b 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -167,6 +167,7 @@ struct kvmppc_rma_info {
};
struct kvm_arch {
+ struct kvm_ppc_set_platform platform;
#ifdef CONFIG_KVM_BOOK3S_64_HV
unsigned long hpt_virt;
unsigned long ram_npages;
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index a107c9b..83265cd 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -690,6 +690,34 @@ long kvm_arch_vm_ioctl(struct file *filp,
break;
}
#endif /* CONFIG_KVM_BOOK3S_64_HV */
+ case KVM_PPC_SET_PLATFORM: {
+ struct kvm_ppc_set_platform plat;
+ struct kvm *kvm = filp->private_data;
+
+ r = -EFAULT;
+ if (copy_from_user(&plat, argp, sizeof(plat)))
+ goto out;
+ r = -EINVAL;
+#ifdef CONFIG_KVM_BOOK3S_64_HV
+ if (plat.platform != KVM_PPC_PV_SPAPR || plat.flags)
+ goto out;
+ /* requested guest arch must match real CPU */
+ if (!((plat.guest_arch == 201 &&
+ cpu_has_feature(CPU_FTR_ARCH_201)) ||
+ (plat.guest_arch == 206 &&
+ cpu_has_feature(CPU_FTR_ARCH_206))))
+ goto out;
+#else
+ if (plat.flags & ~KVM_PPC_CROSS_ARCH)
+ goto out;
+ if (plat.platform != KVM_PPC_PV_NONE &&
+ plat.platform != KVM_PPC_PV_KVM)
+ goto out;
+#endif
+ kvm->arch.platform = plat;
+ r = 0;
+ break;
+ }
default:
r = -ENOTTY;
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 2c366b5..e6258e7 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -758,6 +758,7 @@ struct kvm_clock_data {
#define KVM_CREATE_SPAPR_TCE _IOW(KVMIO, 0xa8, struct kvm_create_spapr_tce)
/* Available with KVM_CAP_RMA */
#define KVM_ALLOCATE_RMA _IOR(KVMIO, 0xa9, struct kvm_allocate_rma)
+#define KVM_PPC_SET_PLATFORM _IOR(KVMIO, 0xaa, struct kvm_ppc_set_platform)
#define KVM_DEV_ASSIGN_ENABLE_IOMMU (1 << 0)
--
1.7.5.4
^ permalink raw reply related
* [PATCH 16/17] KVM: PPC: book3s_hv: Add support for PPC970-family processors
From: Paul Mackerras @ 2011-06-29 10:40 UTC (permalink / raw)
To: linuxppc-dev, kvm, kvm-ppc, Alexander Graf
In-Reply-To: <20110629101552.GA25406@bloggs.ozlabs.ibm.com>
This adds support for running KVM guests in supervisor mode on those
PPC970 processors that have a usable hypervisor mode. Unfortunately,
Apple G5 machines have supervisor mode disabled (MSR[HV] is forced to
1), but the YDL PowerStation does have a usable hypervisor mode.
There are several differences between the PPC970 and POWER7 in how
guests are managed. These differences are accommodated using the
CPU_FTR_ARCH_201 (PPC970) and CPU_FTR_ARCH_206 (POWER7) CPU feature
bits. Notably, on PPC970:
* The LPCR, LPID or RMOR registers don't exist, and the functions of
those registers are provided by bits in HID4 and one bit in HID0.
* External interrupts can be directed to the hypervisor, but unlike
POWER7 they are masked by MSR[EE] in non-hypervisor modes and use
SRR0/1 not HSRR0/1.
* There is no virtual RMA (VRMA) mode; the guest must use an RMO
(real mode offset) area.
* The TLB entries are not tagged with the LPID, so it is necessary to
flush the whole TLB on partition switch. Furthermore, when switching
partitions we have to ensure that no other CPU is executing the tlbie
or tlbsync instructions in either the old or the new partition,
otherwise undefined behaviour can occur.
* The PMU has 8 counters (PMC registers) rather than 6.
* The DSCR, PURR, SPURR, AMR, AMOR, UAMOR registers don't exist.
* The SLB has 64 entries rather than 32.
* There is no mediated external interrupt facility, so if we switch to
a guest that has a virtual external interrupt pending but the guest
has MSR[EE] = 0, we have to arrange to have an interrupt pending for
it so that we can get control back once it re-enables interrupts. We
do that by sending ourselves an IPI with smp_send_reschedule after
hard-disabling interrupts.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
arch/powerpc/include/asm/exception-64s.h | 4 +
arch/powerpc/include/asm/kvm_book3s_asm.h | 2 +-
arch/powerpc/include/asm/kvm_host.h | 2 +-
arch/powerpc/kernel/asm-offsets.c | 1 +
arch/powerpc/kernel/exceptions-64s.S | 2 +-
arch/powerpc/kvm/Kconfig | 13 +-
arch/powerpc/kvm/book3s_64_mmu_hv.c | 30 +++-
arch/powerpc/kvm/book3s_hv.c | 60 ++++++--
arch/powerpc/kvm/book3s_hv_builtin.c | 11 +-
arch/powerpc/kvm/book3s_hv_interrupts.S | 30 ++++
arch/powerpc/kvm/book3s_hv_rm_mmu.c | 6 +-
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 230 ++++++++++++++++++++++++++++-
arch/powerpc/kvm/powerpc.c | 3 +
arch/powerpc/mm/hash_native_64.c | 2 +-
14 files changed, 354 insertions(+), 42 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h
index 69435da..8057f4f 100644
--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -246,6 +246,10 @@ label##_hv: \
KVMTEST(vec); \
_SOFTEN_TEST(EXC_HV)
+#define SOFTEN_TEST_HV_201(vec) \
+ KVMTEST(vec); \
+ _SOFTEN_TEST(EXC_STD)
+
#define __MASKABLE_EXCEPTION_PSERIES(vec, label, h, extra) \
HMT_MEDIUM; \
SET_SCRATCH0(r13); /* save r13 */ \
diff --git a/arch/powerpc/include/asm/kvm_book3s_asm.h b/arch/powerpc/include/asm/kvm_book3s_asm.h
index 9cfd543..ef7b368 100644
--- a/arch/powerpc/include/asm/kvm_book3s_asm.h
+++ b/arch/powerpc/include/asm/kvm_book3s_asm.h
@@ -82,7 +82,7 @@ struct kvmppc_host_state {
unsigned long xics_phys;
u64 dabr;
u64 host_mmcr[3];
- u32 host_pmc[6];
+ u32 host_pmc[8];
u64 host_purr;
u64 host_spurr;
u64 host_dscr;
diff --git a/arch/powerpc/include/asm/kvm_host.h b/arch/powerpc/include/asm/kvm_host.h
index f572d9c..cc22b28 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -353,7 +353,7 @@ struct kvm_vcpu_arch {
u32 dbsr;
u64 mmcr[3];
- u32 pmc[6];
+ u32 pmc[8];
#ifdef CONFIG_KVM_EXIT_TIMING
struct mutex exit_timing_lock;
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index f4aba93..54b935f 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -128,6 +128,7 @@ int main(void)
DEFINE(ICACHEL1LINESPERPAGE, offsetof(struct ppc64_caches, ilines_per_page));
/* paca */
DEFINE(PACA_SIZE, sizeof(struct paca_struct));
+ DEFINE(PACA_LOCK_TOKEN, offsetof(struct paca_struct, lock_token));
DEFINE(PACAPACAINDEX, offsetof(struct paca_struct, paca_index));
DEFINE(PACAPROCSTART, offsetof(struct paca_struct, cpu_start));
DEFINE(PACAKSAVE, offsetof(struct paca_struct, kstack));
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index a534538..41b02c7 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -171,7 +171,7 @@ hardware_interrupt_hv:
KVM_HANDLER(PACA_EXGEN, EXC_HV, 0x502)
FTR_SECTION_ELSE
_MASKABLE_EXCEPTION_PSERIES(0x500, hardware_interrupt,
- EXC_STD, SOFTEN_TEST_PR)
+ EXC_STD, SOFTEN_TEST_HV_201)
KVM_HANDLER(PACA_EXGEN, EXC_STD, 0x500)
ALT_FTR_SECTION_END_IFSET(CPU_FTR_HVMODE | CPU_FTR_ARCH_206)
diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig
index 5d9b78e..eeb42e0 100644
--- a/arch/powerpc/kvm/Kconfig
+++ b/arch/powerpc/kvm/Kconfig
@@ -67,23 +67,20 @@ config KVM_BOOK3S_64
If unsure, say N.
config KVM_BOOK3S_64_HV
- bool "KVM support for POWER7 using hypervisor mode in host"
+ bool "KVM support for POWER7 and PPC970 using hypervisor mode in host"
depends on KVM_BOOK3S_64
---help---
Support running unmodified book3s_64 guest kernels in
- virtual machines on POWER7 processors that have hypervisor
- mode available to the host.
+ virtual machines on POWER7 and PPC970 processors that have
+ hypervisor mode available to the host.
If you say Y here, KVM will use the hardware virtualization
facilities of POWER7 (and later) processors, meaning that
guest operating systems will run at full hardware speed
using supervisor and user modes. However, this also means
that KVM is not usable under PowerVM (pHyp), is only usable
- on POWER7 (or later) processors, and can only emulate
- POWER5+, POWER6 and POWER7 processors.
-
- This module provides access to the hardware capabilities through
- a character device node named /dev/kvm.
+ on POWER7 (or later) processors and PPC970-family processors,
+ and cannot emulate a different processor from the host processor.
If unsure, say N.
diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c b/arch/powerpc/kvm/book3s_64_mmu_hv.c
index 212dcd8..bc3a2ea 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
@@ -42,6 +42,8 @@
#define VRMA_PAGE_ORDER 24
#define VRMA_VSID 0x1ffffffUL /* 1TB VSID reserved for VRMA */
+/* POWER7 has 10-bit LPIDs, PPC970 has 6-bit LPIDs */
+#define MAX_LPID_970 63
#define NR_LPIDS (LPID_RSVD + 1)
unsigned long lpid_inuse[BITS_TO_LONGS(NR_LPIDS)];
@@ -69,9 +71,6 @@ long kvmppc_alloc_hpt(struct kvm *kvm)
kvm->arch.sdr1 = __pa(hpt) | (HPT_ORDER - 18);
kvm->arch.lpid = lpid;
- kvm->arch.host_sdr1 = mfspr(SPRN_SDR1);
- kvm->arch.host_lpid = mfspr(SPRN_LPID);
- kvm->arch.host_lpcr = mfspr(SPRN_LPCR);
pr_info("KVM guest htab at %lx, LPID %lx\n", hpt, lpid);
return 0;
@@ -128,12 +127,24 @@ void kvmppc_map_vrma(struct kvm *kvm, struct kvm_userspace_memory_region *mem)
int kvmppc_mmu_hv_init(void)
{
- if (!cpu_has_feature(CPU_FTR_HVMODE) ||
- !cpu_has_feature(CPU_FTR_ARCH_206))
+ unsigned long host_lpid, rsvd_lpid;
+
+ if (!cpu_has_feature(CPU_FTR_HVMODE))
return -EINVAL;
+
memset(lpid_inuse, 0, sizeof(lpid_inuse));
- set_bit(mfspr(SPRN_LPID), lpid_inuse);
- set_bit(LPID_RSVD, lpid_inuse);
+
+ if (cpu_has_feature(CPU_FTR_ARCH_206)) {
+ host_lpid = mfspr(SPRN_LPID); /* POWER7 */
+ rsvd_lpid = LPID_RSVD;
+ } else {
+ host_lpid = 0; /* PPC970 */
+ rsvd_lpid = MAX_LPID_970;
+ }
+
+ set_bit(host_lpid, lpid_inuse);
+ /* rsvd_lpid is reserved for use in partition switching */
+ set_bit(rsvd_lpid, lpid_inuse);
return 0;
}
@@ -157,7 +168,10 @@ void kvmppc_mmu_book3s_hv_init(struct kvm_vcpu *vcpu)
{
struct kvmppc_mmu *mmu = &vcpu->arch.mmu;
- vcpu->arch.slb_nr = 32; /* Assume POWER7 for now */
+ if (cpu_has_feature(CPU_FTR_ARCH_206))
+ vcpu->arch.slb_nr = 32; /* POWER7 */
+ else
+ vcpu->arch.slb_nr = 64;
mmu->xlate = kvmppc_mmu_book3s_64_hv_xlate;
mmu->reset_msr = kvmppc_mmu_book3s_64_hv_reset_msr;
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index dc70e77..cc0d7f1 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -443,8 +443,7 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
int kvmppc_core_check_processor_compat(void)
{
- if (cpu_has_feature(CPU_FTR_HVMODE) &&
- cpu_has_feature(CPU_FTR_ARCH_206))
+ if (cpu_has_feature(CPU_FTR_HVMODE))
return 0;
return -EIO;
}
@@ -731,6 +730,10 @@ static int kvmppc_run_vcpu(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu)
return -EINTR;
}
+ /* On PPC970, check that we have an RMA region */
+ if (!vcpu->kvm->arch.rma && cpu_has_feature(CPU_FTR_ARCH_201))
+ return -EPERM;
+
kvm_run->exit_reason = 0;
vcpu->arch.ret = RESUME_GUEST;
vcpu->arch.trap = 0;
@@ -920,12 +923,14 @@ fail:
}
/* Work out RMLS (real mode limit selector) field value for a given RMA size.
- Assumes POWER7. */
+ Assumes POWER7 or PPC970. */
static inline int lpcr_rmls(unsigned long rma_size)
{
switch (rma_size) {
case 32ul << 20: /* 32 MB */
- return 8;
+ if (cpu_has_feature(CPU_FTR_ARCH_206))
+ return 8; /* only supported on POWER7 */
+ return -1;
case 64ul << 20: /* 64 MB */
return 3;
case 128ul << 20: /* 128 MB */
@@ -1059,6 +1064,10 @@ int kvmppc_core_prepare_memory_region(struct kvm *kvm,
mem->userspace_addr == vma->vm_start)
ri = vma->vm_file->private_data;
up_read(¤t->mm->mmap_sem);
+ if (!ri && cpu_has_feature(CPU_FTR_ARCH_201)) {
+ pr_err("CPU requires an RMO\n");
+ return -EINVAL;
+ }
}
if (ri) {
@@ -1077,10 +1086,25 @@ int kvmppc_core_prepare_memory_region(struct kvm *kvm,
atomic_inc(&ri->use_count);
kvm->arch.rma = ri;
kvm->arch.n_rma_pages = rma_size >> porder;
- lpcr = kvm->arch.lpcr & ~(LPCR_VPM0 | LPCR_VRMA_L);
- lpcr |= rmls << LPCR_RMLS_SH;
+
+ /* Update LPCR and RMOR */
+ lpcr = kvm->arch.lpcr;
+ if (cpu_has_feature(CPU_FTR_ARCH_201)) {
+ /* PPC970; insert RMLS value (split field) in HID4 */
+ lpcr &= ~((1ul << HID4_RMLS0_SH) |
+ (3ul << HID4_RMLS2_SH));
+ lpcr |= ((rmls >> 2) << HID4_RMLS0_SH) |
+ ((rmls & 3) << HID4_RMLS2_SH);
+ /* RMOR is also in HID4 */
+ lpcr |= ((ri->base_pfn >> (26 - PAGE_SHIFT)) & 0xffff)
+ << HID4_RMOR_SH;
+ } else {
+ /* POWER7 */
+ lpcr &= ~(LPCR_VPM0 | LPCR_VRMA_L);
+ lpcr |= rmls << LPCR_RMLS_SH;
+ kvm->arch.rmor = kvm->arch.rma->base_pfn << PAGE_SHIFT;
+ }
kvm->arch.lpcr = lpcr;
- kvm->arch.rmor = kvm->arch.rma->base_pfn << PAGE_SHIFT;
pr_info("Using RMO at %lx size %lx (LPCR = %lx)\n",
ri->base_pfn << PAGE_SHIFT, rma_size, lpcr);
}
@@ -1151,11 +1175,25 @@ int kvmppc_core_init_vm(struct kvm *kvm)
kvm->arch.rma = NULL;
kvm->arch.n_rma_pages = 0;
- lpcr = kvm->arch.host_lpcr & (LPCR_PECE | LPCR_LPES);
- lpcr |= (4UL << LPCR_DPFD_SH) | LPCR_HDICE |
- LPCR_VPM0 | LPCR_VRMA_L;
- kvm->arch.lpcr = lpcr;
+ kvm->arch.host_sdr1 = mfspr(SPRN_SDR1);
+ if (cpu_has_feature(CPU_FTR_ARCH_201)) {
+ /* PPC970; HID4 is effectively the LPCR */
+ unsigned long lpid = kvm->arch.lpid;
+ kvm->arch.host_lpid = 0;
+ kvm->arch.host_lpcr = lpcr = mfspr(SPRN_HID4);
+ lpcr &= ~((3 << HID4_LPID1_SH) | (0xful << HID4_LPID5_SH));
+ lpcr |= ((lpid >> 4) << HID4_LPID1_SH) |
+ ((lpid & 0xf) << HID4_LPID5_SH);
+ } else {
+ /* POWER7; init LPCR for virtual RMA mode */
+ kvm->arch.host_lpid = mfspr(SPRN_LPID);
+ kvm->arch.host_lpcr = lpcr = mfspr(SPRN_LPCR);
+ lpcr &= LPCR_PECE | LPCR_LPES;
+ lpcr |= (4UL << LPCR_DPFD_SH) | LPCR_HDICE |
+ LPCR_VPM0 | LPCR_VRMA_L;
+ }
+ kvm->arch.lpcr = lpcr;
return 0;
diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c b/arch/powerpc/kvm/book3s_hv_builtin.c
index c67d7a1..e16a400 100644
--- a/arch/powerpc/kvm/book3s_hv_builtin.c
+++ b/arch/powerpc/kvm/book3s_hv_builtin.c
@@ -55,12 +55,14 @@ static LIST_HEAD(free_rmas);
static DEFINE_SPINLOCK(rma_lock);
/* Work out RMLS (real mode limit selector) field value for a given RMA size.
- Assumes POWER7. */
+ Assumes POWER7 or PPC970. */
static inline int lpcr_rmls(unsigned long rma_size)
{
switch (rma_size) {
case 32ul << 20: /* 32 MB */
- return 8;
+ if (cpu_has_feature(CPU_FTR_ARCH_206))
+ return 8; /* only supported on POWER7 */
+ return -1;
case 64ul << 20: /* 64 MB */
return 3;
case 128ul << 20: /* 128 MB */
@@ -90,8 +92,9 @@ void kvm_rma_init(void)
void *rma;
struct page *pg;
- /* Only do this in HV mode */
- if (!cpu_has_feature(CPU_FTR_HVMODE))
+ /* Only do this on PPC970 in HV mode */
+ if (!cpu_has_feature(CPU_FTR_HVMODE) ||
+ !cpu_has_feature(CPU_FTR_ARCH_201))
return;
if (!kvm_rma_size || !kvm_rma_count)
diff --git a/arch/powerpc/kvm/book3s_hv_interrupts.S b/arch/powerpc/kvm/book3s_hv_interrupts.S
index 532afaf..3f7b674 100644
--- a/arch/powerpc/kvm/book3s_hv_interrupts.S
+++ b/arch/powerpc/kvm/book3s_hv_interrupts.S
@@ -50,8 +50,10 @@ _GLOBAL(__kvmppc_vcore_entry)
SAVE_NVGPRS(r1)
/* Save host DSCR */
+BEGIN_FTR_SECTION
mfspr r3, SPRN_DSCR
std r3, HSTATE_DSCR(r13)
+END_FTR_SECTION_IFSET(CPU_FTR_ARCH_206)
/* Save host DABR */
mfspr r3, SPRN_DABR
@@ -86,12 +88,20 @@ _GLOBAL(__kvmppc_vcore_entry)
mfspr r7, SPRN_PMC4
mfspr r8, SPRN_PMC5
mfspr r9, SPRN_PMC6
+BEGIN_FTR_SECTION
+ mfspr r10, SPRN_PMC7
+ mfspr r11, SPRN_PMC8
+END_FTR_SECTION_IFSET(CPU_FTR_ARCH_201)
stw r3, HSTATE_PMC(r13)
stw r5, HSTATE_PMC + 4(r13)
stw r6, HSTATE_PMC + 8(r13)
stw r7, HSTATE_PMC + 12(r13)
stw r8, HSTATE_PMC + 16(r13)
stw r9, HSTATE_PMC + 20(r13)
+BEGIN_FTR_SECTION
+ stw r10, HSTATE_PMC + 24(r13)
+ stw r11, HSTATE_PMC + 28(r13)
+END_FTR_SECTION_IFSET(CPU_FTR_ARCH_201)
31:
/*
@@ -105,6 +115,26 @@ _GLOBAL(__kvmppc_vcore_entry)
add r8,r8,r7
std r8,HSTATE_DECEXP(r13)
+ /*
+ * On PPC970, if the guest vcpu has an external interrupt pending,
+ * send ourselves an IPI so as to interrupt the guest once it
+ * enables interrupts. (It must have interrupts disabled,
+ * otherwise we would already have delivered the interrupt.)
+ */
+BEGIN_FTR_SECTION
+ ld r0, VCPU_PENDING_EXC(r4)
+ li r7, (1 << BOOK3S_IRQPRIO_EXTERNAL)
+ oris r7, r7, (1 << BOOK3S_IRQPRIO_EXTERNAL_LEVEL)@h
+ and. r0, r0, r7
+ beq 32f
+ mr r31, r4
+ lhz r3, PACAPACAINDEX(r13)
+ bl smp_send_reschedule
+ nop
+ mr r4, r31
+32:
+END_FTR_SECTION_IFSET(CPU_FTR_ARCH_201)
+
/* Jump to partition switch code */
bl .kvmppc_hv_entry_trampoline
nop
diff --git a/arch/powerpc/kvm/book3s_hv_rm_mmu.c b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
index edb0aae..fcfe6b0 100644
--- a/arch/powerpc/kvm/book3s_hv_rm_mmu.c
+++ b/arch/powerpc/kvm/book3s_hv_rm_mmu.c
@@ -56,7 +56,8 @@ long kvmppc_h_enter(struct kvm_vcpu *vcpu, unsigned long flags,
/* only handle 4k, 64k and 16M pages for now */
porder = 12;
if (pteh & HPTE_V_LARGE) {
- if ((ptel & 0xf000) == 0x1000) {
+ if (cpu_has_feature(CPU_FTR_ARCH_206) &&
+ (ptel & 0xf000) == 0x1000) {
/* 64k page */
porder = 16;
} else if ((ptel & 0xff000) == 0) {
@@ -126,7 +127,8 @@ static unsigned long compute_tlbie_rb(unsigned long v, unsigned long r,
va_low &= 0x7ff;
if (v & HPTE_V_LARGE) {
rb |= 1; /* L field */
- if (r & 0xff000) {
+ if (cpu_has_feature(CPU_FTR_ARCH_206) &&
+ (r & 0xff000)) {
/* non-16MB large page, must be 64k */
/* (masks depend on page size) */
rb |= 0x1000; /* page encoding in LP field */
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index 9ee223c..6dd3358 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -148,12 +148,20 @@ kvmppc_hv_entry:
lwz r7, VCPU_PMC + 12(r4)
lwz r8, VCPU_PMC + 16(r4)
lwz r9, VCPU_PMC + 20(r4)
+BEGIN_FTR_SECTION
+ lwz r10, VCPU_PMC + 24(r4)
+ lwz r11, VCPU_PMC + 28(r4)
+END_FTR_SECTION_IFSET(CPU_FTR_ARCH_201)
mtspr SPRN_PMC1, r3
mtspr SPRN_PMC2, r5
mtspr SPRN_PMC3, r6
mtspr SPRN_PMC4, r7
mtspr SPRN_PMC5, r8
mtspr SPRN_PMC6, r9
+BEGIN_FTR_SECTION
+ mtspr SPRN_PMC7, r10
+ mtspr SPRN_PMC8, r11
+END_FTR_SECTION_IFSET(CPU_FTR_ARCH_201)
ld r3, VCPU_MMCR(r4)
ld r5, VCPU_MMCR + 8(r4)
ld r6, VCPU_MMCR + 16(r4)
@@ -165,9 +173,11 @@ kvmppc_hv_entry:
/* Load up FP, VMX and VSX registers */
bl kvmppc_load_fp
+BEGIN_FTR_SECTION
/* Switch DSCR to guest value */
ld r5, VCPU_DSCR(r4)
mtspr SPRN_DSCR, r5
+END_FTR_SECTION_IFSET(CPU_FTR_ARCH_206)
/*
* Set the decrementer to the guest decrementer.
@@ -210,6 +220,7 @@ kvmppc_hv_entry:
mtspr SPRN_DABRX,r5
mtspr SPRN_DABR,r6
+BEGIN_FTR_SECTION
/* Restore AMR and UAMOR, set AMOR to all 1s */
ld r5,VCPU_AMR(r4)
ld r6,VCPU_UAMOR(r4)
@@ -217,6 +228,7 @@ kvmppc_hv_entry:
mtspr SPRN_AMR,r5
mtspr SPRN_UAMOR,r6
mtspr SPRN_AMOR,r7
+END_FTR_SECTION_IFSET(CPU_FTR_ARCH_206)
/* Clear out SLB */
li r6,0
@@ -224,6 +236,14 @@ kvmppc_hv_entry:
slbia
ptesync
+BEGIN_FTR_SECTION
+ b 30f
+END_FTR_SECTION_IFSET(CPU_FTR_ARCH_201)
+ /*
+ * POWER7 host -> guest partition switch code.
+ * We don't have to lock against concurrent tlbies,
+ * but we do have to coordinate across hardware threads.
+ */
/* Increment entry count iff exit count is zero. */
ld r5,HSTATE_KVM_VCORE(r13)
addi r9,r5,VCORE_ENTRY_EXIT
@@ -315,9 +335,94 @@ kvmppc_hv_entry:
ld r8,VCPU_SPURR(r4)
mtspr SPRN_PURR,r7
mtspr SPRN_SPURR,r8
+ b 31f
+
+ /*
+ * PPC970 host -> guest partition switch code.
+ * We have to lock against concurrent tlbies,
+ * using native_tlbie_lock to lock against host tlbies
+ * and kvm->arch.tlbie_lock to lock against guest tlbies.
+ * We also have to invalidate the TLB since its
+ * entries aren't tagged with the LPID.
+ */
+30: ld r9,VCPU_KVM(r4) /* pointer to struct kvm */
+
+ /* first take native_tlbie_lock */
+ .section ".toc","aw"
+toc_tlbie_lock:
+ .tc native_tlbie_lock[TC],native_tlbie_lock
+ .previous
+ ld r3,toc_tlbie_lock@toc(2)
+ lwz r8,PACA_LOCK_TOKEN(r13)
+24: lwarx r0,0,r3
+ cmpwi r0,0
+ bne 24b
+ stwcx. r8,0,r3
+ bne 24b
+ isync
+
+ ld r7,KVM_LPCR(r9) /* use kvm->arch.lpcr to store HID4 */
+ li r0,0x18f
+ rotldi r0,r0,HID4_LPID5_SH /* all lpid bits in HID4 = 1 */
+ or r0,r7,r0
+ ptesync
+ sync
+ mtspr SPRN_HID4,r0 /* switch to reserved LPID */
+ isync
+ li r0,0
+ stw r0,0(r3) /* drop native_tlbie_lock */
+
+ /* invalidate the whole TLB */
+ li r0,256
+ mtctr r0
+ li r6,0
+25: tlbiel r6
+ addi r6,r6,0x1000
+ bdnz 25b
+ ptesync
+
+ /* Take the guest's tlbie_lock */
+ addi r3,r9,KVM_TLBIE_LOCK
+24: lwarx r0,0,r3
+ cmpwi r0,0
+ bne 24b
+ stwcx. r8,0,r3
+ bne 24b
+ isync
+ ld r6,KVM_SDR1(r9)
+ mtspr SPRN_SDR1,r6 /* switch to partition page table */
+
+ /* Set up HID4 with the guest's LPID etc. */
+ sync
+ mtspr SPRN_HID4,r7
+ isync
+
+ /* drop the guest's tlbie_lock */
+ li r0,0
+ stw r0,0(r3)
+
+ /* Check if HDEC expires soon */
+ mfspr r3,SPRN_HDEC
+ cmpwi r3,10
+ li r12,BOOK3S_INTERRUPT_HV_DECREMENTER
+ mr r9,r4
+ blt hdec_soon
+
+ /* Enable HDEC interrupts */
+ mfspr r0,SPRN_HID0
+ li r3,1
+ rldimi r0,r3, HID0_HDICE_SH, 64-HID0_HDICE_SH-1
+ sync
+ mtspr SPRN_HID0,r0
+ mfspr r0,SPRN_HID0
+ mfspr r0,SPRN_HID0
+ mfspr r0,SPRN_HID0
+ mfspr r0,SPRN_HID0
+ mfspr r0,SPRN_HID0
+ mfspr r0,SPRN_HID0
/* Load up guest SLB entries */
- lwz r5,VCPU_SLB_MAX(r4)
+31: lwz r5,VCPU_SLB_MAX(r4)
cmpwi r5,0
beq 9f
mtctr r5
@@ -472,6 +577,7 @@ kvmppc_interrupt:
hcall_real_cont:
/* Check for mediated interrupts (could be done earlier really ...) */
+BEGIN_FTR_SECTION
cmpwi r12,BOOK3S_INTERRUPT_EXTERNAL
bne+ 1f
ld r5,VCPU_KVM(r9)
@@ -481,6 +587,7 @@ hcall_real_cont:
andi. r0,r5,LPCR_MER
bne bounce_ext_interrupt
1:
+END_FTR_SECTION_IFSET(CPU_FTR_ARCH_206)
/* Save DEC */
mfspr r5,SPRN_DEC
@@ -492,9 +599,11 @@ hcall_real_cont:
/* Save HEIR (HV emulation assist reg) in last_inst
if this is an HEI (HV emulation interrupt, e40) */
li r3,-1
+BEGIN_FTR_SECTION
cmpwi r12,BOOK3S_INTERRUPT_H_EMUL_ASSIST
bne 11f
mfspr r3,SPRN_HEIR
+END_FTR_SECTION_IFSET(CPU_FTR_ARCH_206)
11: stw r3,VCPU_LAST_INST(r9)
/* Save more register state */
@@ -508,8 +617,10 @@ hcall_real_cont:
stw r7, VCPU_DSISR(r9)
std r8, VCPU_CTR(r9)
/* grab HDAR & HDSISR if HV data storage interrupt (HDSI) */
+BEGIN_FTR_SECTION
cmpwi r12,BOOK3S_INTERRUPT_H_DATA_STORAGE
beq 6f
+END_FTR_SECTION_IFSET(CPU_FTR_ARCH_206)
7: std r6, VCPU_FAULT_DAR(r9)
stw r7, VCPU_FAULT_DSISR(r9)
@@ -543,6 +654,7 @@ hcall_real_cont:
/*
* Save the guest PURR/SPURR
*/
+BEGIN_FTR_SECTION
mfspr r5,SPRN_PURR
mfspr r6,SPRN_SPURR
ld r7,VCPU_PURR(r9)
@@ -562,6 +674,7 @@ hcall_real_cont:
add r4,r4,r6
mtspr SPRN_PURR,r3
mtspr SPRN_SPURR,r4
+END_FTR_SECTION_IFCLR(CPU_FTR_ARCH_201)
/* Clear out SLB */
li r5,0
@@ -570,6 +683,14 @@ hcall_real_cont:
ptesync
hdec_soon:
+BEGIN_FTR_SECTION
+ b 32f
+END_FTR_SECTION_IFSET(CPU_FTR_ARCH_201)
+ /*
+ * POWER7 guest -> host partition switch code.
+ * We don't have to lock against tlbies but we do
+ * have to coordinate the hardware threads.
+ */
/* Increment the threads-exiting-guest count in the 0xff00
bits of vcore->entry_exit_count */
lwsync
@@ -640,9 +761,82 @@ hdec_soon:
16: ld r8,KVM_HOST_LPCR(r4)
mtspr SPRN_LPCR,r8
isync
+ b 33f
+
+ /*
+ * PPC970 guest -> host partition switch code.
+ * We have to lock against concurrent tlbies, and
+ * we have to flush the whole TLB.
+ */
+32: ld r4,VCPU_KVM(r9) /* pointer to struct kvm */
+
+ /* Take the guest's tlbie_lock */
+ lwz r8,PACA_LOCK_TOKEN(r13)
+ addi r3,r4,KVM_TLBIE_LOCK
+24: lwarx r0,0,r3
+ cmpwi r0,0
+ bne 24b
+ stwcx. r8,0,r3
+ bne 24b
+ isync
+
+ ld r7,KVM_HOST_LPCR(r4) /* use kvm->arch.host_lpcr for HID4 */
+ li r0,0x18f
+ rotldi r0,r0,HID4_LPID5_SH /* all lpid bits in HID4 = 1 */
+ or r0,r7,r0
+ ptesync
+ sync
+ mtspr SPRN_HID4,r0 /* switch to reserved LPID */
+ isync
+ li r0,0
+ stw r0,0(r3) /* drop guest tlbie_lock */
+
+ /* invalidate the whole TLB */
+ li r0,256
+ mtctr r0
+ li r6,0
+25: tlbiel r6
+ addi r6,r6,0x1000
+ bdnz 25b
+ ptesync
+
+ /* take native_tlbie_lock */
+ ld r3,toc_tlbie_lock@toc(2)
+24: lwarx r0,0,r3
+ cmpwi r0,0
+ bne 24b
+ stwcx. r8,0,r3
+ bne 24b
+ isync
+
+ ld r6,KVM_HOST_SDR1(r4)
+ mtspr SPRN_SDR1,r6 /* switch to host page table */
+
+ /* Set up host HID4 value */
+ sync
+ mtspr SPRN_HID4,r7
+ isync
+ li r0,0
+ stw r0,0(r3) /* drop native_tlbie_lock */
+
+ lis r8,0x7fff /* MAX_INT@h */
+ mtspr SPRN_HDEC,r8
+
+ /* Disable HDEC interrupts */
+ mfspr r0,SPRN_HID0
+ li r3,0
+ rldimi r0,r3, HID0_HDICE_SH, 64-HID0_HDICE_SH-1
+ sync
+ mtspr SPRN_HID0,r0
+ mfspr r0,SPRN_HID0
+ mfspr r0,SPRN_HID0
+ mfspr r0,SPRN_HID0
+ mfspr r0,SPRN_HID0
+ mfspr r0,SPRN_HID0
+ mfspr r0,SPRN_HID0
/* load host SLB entries */
- ld r8,PACA_SLBSHADOWPTR(r13)
+33: ld r8,PACA_SLBSHADOWPTR(r13)
.rept SLB_NUM_BOLTED
ld r5,SLBSHADOW_SAVEAREA(r8)
@@ -654,12 +848,14 @@ hdec_soon:
.endr
/* Save and reset AMR and UAMOR before turning on the MMU */
+BEGIN_FTR_SECTION
mfspr r5,SPRN_AMR
mfspr r6,SPRN_UAMOR
std r5,VCPU_AMR(r9)
std r6,VCPU_UAMOR(r9)
li r6,0
mtspr SPRN_AMR,r6
+END_FTR_SECTION_IFSET(CPU_FTR_ARCH_206)
/* Restore host DABR and DABRX */
ld r5,HSTATE_DABR(r13)
@@ -668,10 +864,12 @@ hdec_soon:
mtspr SPRN_DABRX,r6
/* Switch DSCR back to host value */
+BEGIN_FTR_SECTION
mfspr r8, SPRN_DSCR
ld r7, HSTATE_DSCR(r13)
std r8, VCPU_DSCR(r7)
mtspr SPRN_DSCR, r7
+END_FTR_SECTION_IFSET(CPU_FTR_ARCH_206)
/* Save non-volatile GPRs */
std r14, VCPU_GPR(r14)(r9)
@@ -735,21 +933,31 @@ hdec_soon:
mfspr r6, SPRN_PMC4
mfspr r7, SPRN_PMC5
mfspr r8, SPRN_PMC6
+BEGIN_FTR_SECTION
+ mfspr r10, SPRN_PMC7
+ mfspr r11, SPRN_PMC8
+END_FTR_SECTION_IFSET(CPU_FTR_ARCH_201)
stw r3, VCPU_PMC(r9)
stw r4, VCPU_PMC + 4(r9)
stw r5, VCPU_PMC + 8(r9)
stw r6, VCPU_PMC + 12(r9)
stw r7, VCPU_PMC + 16(r9)
stw r8, VCPU_PMC + 20(r9)
+BEGIN_FTR_SECTION
+ stw r10, VCPU_PMC + 24(r9)
+ stw r11, VCPU_PMC + 28(r9)
+END_FTR_SECTION_IFSET(CPU_FTR_ARCH_201)
22:
/* save FP state */
mr r3, r9
bl .kvmppc_save_fp
- /* Secondary threads go off to take a nap */
+ /* Secondary threads go off to take a nap on POWER7 */
+BEGIN_FTR_SECTION
lwz r0,VCPU_PTID(r3)
cmpwi r0,0
bne secondary_nap
+END_FTR_SECTION_IFSET(CPU_FTR_ARCH_206)
/*
* Reload DEC. HDEC interrupts were disabled when
@@ -771,12 +979,20 @@ hdec_soon:
lwz r6, HSTATE_PMC + 12(r13)
lwz r8, HSTATE_PMC + 16(r13)
lwz r9, HSTATE_PMC + 20(r13)
+BEGIN_FTR_SECTION
+ lwz r10, HSTATE_PMC + 24(r13)
+ lwz r11, HSTATE_PMC + 28(r13)
+END_FTR_SECTION_IFSET(CPU_FTR_ARCH_201)
mtspr SPRN_PMC1, r3
mtspr SPRN_PMC2, r4
mtspr SPRN_PMC3, r5
mtspr SPRN_PMC4, r6
mtspr SPRN_PMC5, r8
mtspr SPRN_PMC6, r9
+BEGIN_FTR_SECTION
+ mtspr SPRN_PMC7, r10
+ mtspr SPRN_PMC8, r11
+END_FTR_SECTION_IFSET(CPU_FTR_ARCH_201)
ld r3, HSTATE_MMCR(r13)
ld r4, HSTATE_MMCR + 8(r13)
ld r5, HSTATE_MMCR + 16(r13)
@@ -802,7 +1018,7 @@ hdec_soon:
cmpwi r12, BOOK3S_INTERRUPT_MACHINE_CHECK
/* RFI into the highmem handler, or branch to interrupt handler */
- mfmsr r6
+12: mfmsr r6
mtctr r12
li r0, MSR_RI
andc r6, r6, r0
@@ -812,7 +1028,11 @@ hdec_soon:
beqctr
RFI
-11: mtspr SPRN_HSRR0, r8
+11:
+BEGIN_FTR_SECTION
+ b 12b
+END_FTR_SECTION_IFSET(CPU_FTR_ARCH_201)
+ mtspr SPRN_HSRR0, r8
mtspr SPRN_HSRR1, r7
ba 0x500
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 72c5065..a107c9b 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -213,6 +213,9 @@ int kvm_dev_ioctl_check_extension(long ext)
break;
case KVM_CAP_PPC_RMA:
r = 1;
+ /* PPC970 requires an RMA */
+ if (cpu_has_feature(CPU_FTR_ARCH_201))
+ r = 2;
break;
#endif
default:
diff --git a/arch/powerpc/mm/hash_native_64.c b/arch/powerpc/mm/hash_native_64.c
index b44f5f8..90039bc 100644
--- a/arch/powerpc/mm/hash_native_64.c
+++ b/arch/powerpc/mm/hash_native_64.c
@@ -37,7 +37,7 @@
#define HPTE_LOCK_BIT 3
-static DEFINE_RAW_SPINLOCK(native_tlbie_lock);
+DEFINE_RAW_SPINLOCK(native_tlbie_lock);
static inline void __tlbie(unsigned long va, int psize, int ssize)
{
--
1.7.5.4
^ permalink raw reply related
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