Re: Please revert 928bea964827d7824b548c1f8e06eccbbc4d0d7d

2013-09-27 Thread Benjamin Herrenschmidt
On Fri, 2013-09-27 at 16:44 -0700, Yinghai Lu wrote:

> > Thus the port driver bails out before calling pci_set_master(). The fix
> > is to call pci_set_master() unconditionally. However that lead me to
> > find to a few interesting oddities in that port driver code:
> 
> can we revert that partially change ? aka we should check get_port
> at first...
> 
> like attached.

In the meantime, can you properly submit the other one with the warning
to Linus ? It will make things more robust overall...

Also, please read my other comments. I think we are treading on very
fragile ground with that whole business of potentially disabling bridges
in the pcieport driver ...

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: Please revert 928bea964827d7824b548c1f8e06eccbbc4d0d7d

2013-09-27 Thread Yinghai Lu
[+ Rafael]

On Fri, Sep 27, 2013 at 4:19 PM, Benjamin Herrenschmidt
 wrote:
> On Fri, 2013-09-27 at 15:56 -0700, Yinghai Lu wrote:
>
>> ok, please if you are ok attached one instead. It will print some warning 
>> about
>> driver skipping pci_set_master, so we can catch more problem with drivers.
>
> Except that the message is pretty cryptic :-) Especially since the
> driver causing the message to be printed is not the one that did
> the mistake in the first place, it's the next one coming up that
> trips the warning.
>
> In any case, the root cause is indeed the PCIe port driver:
>
> We don't have ACPI, so pcie_port_platform_notify() isn't implemented,
> and pcie_ports_auto is true, so we end up with capabilities set to 0.

in
| commit fe31e69740eddc7316071ed5165fed6703c8cd12
| Author: Rafael J. Wysocki 
| Date:   Sun Dec 19 15:57:16 2010 +0100
|
|PCI/PCIe: Clear Root PME Status bits early during system resume
|
|I noticed that PCI Express PMEs don't work on my Toshiba Portege R500
|after the system has been woken up from a sleep state by a PME
|(through Wake-on-LAN).  After some investigation it turned out that
|the BIOS didn't clear the Root PME Status bit in the root port that
|received the wakeup PME and since the Requester ID was also set in
|the port's Root Status register, any subsequent PMEs didn't trigger
|interrupts.
|
|This problem can be avoided by clearing the Root PME Status bits in
|all PCI Express root ports during early resume.  For this purpose,
|add an early resume routine to the PCIe port driver and make this
|driver be always registered, even if pci_ports_disable is set (in
|which case the driver's only function is to provide the early
|resume callback).
|
|
|@@ -349,15 +349,18 @@ int pcie_port_device_register(struct pci_dev *dev)
|int status, capabilities, i, nr_service;
|int irqs[PCIE_PORT_DEVICE_MAXSERVICES];
|
|-   /* Get and check PCI Express port services */
|-   capabilities = get_port_device_capability(dev);
|-   if (!capabilities)
|-   return -ENODEV;
|-
|/* Enable PCI Express port device */
|status = pci_enable_device(dev);
|if (status)
|return status;
|+
|+   /* Get and check PCI Express port services */
|+   capabilities = get_port_device_capability(dev);
|+   if (!capabilities) {
|+   pcie_no_aspm();
|+   return 0;
|+   }
|+
|pci_set_master(dev);
|/*
| * Initialize service irqs. Don't use service devices that

>
> Thus the port driver bails out before calling pci_set_master(). The fix
> is to call pci_set_master() unconditionally. However that lead me to
> find to a few interesting oddities in that port driver code:

can we revert that partially change ? aka we should check get_port
at first...

like attached.

Thanks

Yinghai


fix_pci_set_master_port_pcie.patch
Description: Binary data
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Please revert 928bea964827d7824b548c1f8e06eccbbc4d0d7d

2013-09-27 Thread Benjamin Herrenschmidt
On Fri, 2013-09-27 at 15:56 -0700, Yinghai Lu wrote:

> ok, please if you are ok attached one instead. It will print some warning 
> about
> driver skipping pci_set_master, so we can catch more problem with drivers.

Except that the message is pretty cryptic :-) Especially since the
driver causing the message to be printed is not the one that did
the mistake in the first place, it's the next one coming up that
trips the warning.

In any case, the root cause is indeed the PCIe port driver:

We don't have ACPI, so pcie_port_platform_notify() isn't implemented,
and pcie_ports_auto is true, so we end up with capabilities set to 0.

Thus the port driver bails out before calling pci_set_master(). The fix
is to call pci_set_master() unconditionally. However that lead me to
find to a few interesting oddities in that port driver code:

 - If capabilities is 0, it returns after enabling the device and
doesn't disable it. But if it fails for any other reason later on (such
as failing to enable interrupts), it *will* disable the device. This is
inconsistent. In fact, if it had disabled the device as a result of the
0 capabilities, the problem would also not have happened (the subsequent
enable_bridge done by the e1000e driver would have done the right
thing). I've tested "fixing" that instead of moving the set_master call
and it fixes my problem as well.

 - In get_port_device_capability(), all capabilities are gated by a
combination of the bit in cap_mask and a corresponding HW check of
the presence of the relevant PCIe capability or similar... except
for the VC one, which is solely read from the HW capability. That means
that the platform pcie_port_platform_notify() has no ability to prevent
the VC capability (so if I have a broken bridge that advertises it but
my platform wants to block it, it can't).

 - I am quite nervous with the PCIe port driver disabling bridges. I
understand the intent but what if that bridge has some system device
behind it ? Something you don't even know about (used by ACPI, behind an
ISA bridge for example ?).

I think disabling bridges is a VERY risky proposition at all times
(including during PM) and I don't think the port driver should do it.

Maybe a more robust approach would be to detect one way or another that
the bridge was already enabled and only disable it if it wasn't or
something along those lines (ie ,restore it in the state it was)...

This is not my problem right now of course (in my case the bridge was
disabled to begin with) but I have a long experience with system stuff
hiding behind bridges and the code as it is written makes me a bit
nervous.

Cheers,
Ben.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: Please revert 928bea964827d7824b548c1f8e06eccbbc4d0d7d

2013-09-27 Thread Yinghai Lu
On Fri, Sep 27, 2013 at 3:38 PM, Benjamin Herrenschmidt
 wrote:
> On Fri, 2013-09-27 at 14:54 -0700, Yinghai Lu wrote:
>> On Fri, Sep 27, 2013 at 2:46 PM, Benjamin Herrenschmidt
>>  wrote:
>>
>> > Wouldn't it be better to simply have pci_enable_device() always set bus
>> > master on a bridge? I don't see any case where it makes sense to have
>> > an enabled bridge without the master bit set on it...
>>
>> Do you mean attached?
>
> So this patch works and fixes the problem. I think it makes the whole
> thing more robust and should be applied.

good.

>
> I still don't know why the bridge doesn't get enabled properly without
> it yes, tracking it down (the machine in question takes a LONG time to
> reboot :-)

ok, please if you are ok attached one instead. It will print some warning about
driver skipping pci_set_master, so we can catch more problem with drivers.

Thanks

Yinghai


pci_set_master_again_v2.patch
Description: Binary data
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Please revert 928bea964827d7824b548c1f8e06eccbbc4d0d7d

2013-09-27 Thread Benjamin Herrenschmidt
On Fri, 2013-09-27 at 14:54 -0700, Yinghai Lu wrote:
> On Fri, Sep 27, 2013 at 2:46 PM, Benjamin Herrenschmidt
>  wrote:
> 
> > Wouldn't it be better to simply have pci_enable_device() always set bus
> > master on a bridge? I don't see any case where it makes sense to have
> > an enabled bridge without the master bit set on it...
> 
> Do you mean attached?

So this patch works and fixes the problem. I think it makes the whole
thing more robust and should be applied.

I still don't know why the bridge doesn't get enabled properly without
it yes, tracking it down (the machine in question takes a LONG time to
reboot :-)

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: Please revert 928bea964827d7824b548c1f8e06eccbbc4d0d7d

2013-09-27 Thread Benjamin Herrenschmidt
On Fri, 2013-09-27 at 10:44 -0700, Yinghai Lu wrote:
> |/* Get and check PCI Express port services */
> |capabilities = get_port_device_capability(dev);
> |if (!capabilities)
> |return 0;
> |
> |pci_set_master(dev);
> 
> so how come that pci_set_master is not called for powerpc?
> 
> Can you send out lspci -vvxxx with current linus-tree and v3.11?

Ah good point. It should have ... except that there are a number of ways
for get_port_device_capability() to fail and that should *not* leave the
bridge without the bus master capability set.

However I don't think that's what's happening here. I'll have to dig
more, will get back to you.

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: Please revert 928bea964827d7824b548c1f8e06eccbbc4d0d7d

2013-09-27 Thread Benjamin Herrenschmidt
On Fri, 2013-09-27 at 14:54 -0700, Yinghai Lu wrote:
> On Fri, Sep 27, 2013 at 2:46 PM, Benjamin Herrenschmidt
>  wrote:
> 
> > Wouldn't it be better to simply have pci_enable_device() always set bus
> > master on a bridge? I don't see any case where it makes sense to have
> > an enabled bridge without the master bit set on it...
> 
> Do you mean attached?

That's an option. I was thinking making pci_enable_device() itself
enable bus master on a bridge but yes, you approach should work.

I'm digging a bit more to figure out what went wrong in the
pcie port driver since that's interesting in its own right and I'll then
test your patch which I think is a more robust approach.

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: Please revert 928bea964827d7824b548c1f8e06eccbbc4d0d7d

2013-09-27 Thread Yinghai Lu
On Fri, Sep 27, 2013 at 2:46 PM, Benjamin Herrenschmidt
 wrote:

> Wouldn't it be better to simply have pci_enable_device() always set bus
> master on a bridge? I don't see any case where it makes sense to have
> an enabled bridge without the master bit set on it...

Do you mean attached?


pci_set_master_again.patch
Description: Binary data
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Please revert 928bea964827d7824b548c1f8e06eccbbc4d0d7d

2013-09-27 Thread Benjamin Herrenschmidt
On Fri, 2013-09-27 at 10:10 -0700, Linus Torvalds wrote:
> > So i would like to use the first way that you suggest : call pci_set_master
> > PCIe port driver.
> 
> So I have to say, that if we can fix this with just adding a single
> new pci_set_master() call, we should do that before we decide to
> revert.
> 
> If other, bigger issues then come up, we can decide to revert. But if
> there's a one-liner fix, let's just do that first, ok?
> 
> Mind sending a patch?

Wouldn't it be better to simply have pci_enable_device() always set bus
master on a bridge? I don't see any case where it makes sense to have
an enabled bridge without the master bit set on it...

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v4] powerpc 8xx: Fixing issue with CONFIG_PIN_TLB

2013-09-27 Thread Scott Wood
On Tue, 2013-09-24 at 10:18 +0200, Christophe Leroy wrote:
> Activating CONFIG_PIN_TLB is supposed to pin the IMMR and the first three
> 8Mbytes pages. But the setting of MD_CTR to a pinnable entry was missing 
> before
> the pinning of the third 8Mb page. As the index is decremented module 28
> (MD_RSV4D is set) after every DTLB update, the third 8Mbytes page was
> not pinned.

The examples you showed weren't quite modulo 28, more like "if (x >= 28)
x -= 4".  I'll fix up the changelog on applying, to read something like
"As the index is decremented to a value within the first 28 entries
(MD_RSV4D is set)...".

-Scott



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc/p1010rdb:update dts to adapt to both old and new p1010rdb

2013-09-27 Thread Scott Wood
On Sun, 2013-09-22 at 10:28 +0800, Zhao Qiang wrote:
> P1010rdb-pa and p1010rdb-pb have different phy interrupts.
> So update dts to adapt to both p1010rdb-pa and p1010rdb-pb.
> 
> Signed-off-by: Shengzhou Liu 
> Signed-off-by: Zhao Qiang 
> ---
>  arch/powerpc/boot/dts/p1010rdb-pa.dts | 33 ++
>  arch/powerpc/boot/dts/p1010rdb-pb.dts | 33 ++
>  arch/powerpc/boot/dts/p1010rdb.dts| 66 
> ---
>  arch/powerpc/boot/dts/p1010rdb.dtsi   | 51 ---
>  4 files changed, 112 insertions(+), 71 deletions(-)
>  create mode 100644 arch/powerpc/boot/dts/p1010rdb-pa.dts
>  create mode 100644 arch/powerpc/boot/dts/p1010rdb-pb.dts
>  delete mode 100644 arch/powerpc/boot/dts/p1010rdb.dts

What about p1010rdb_36b.dts?

-Scott



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and altivec idle

2013-09-27 Thread Scott Wood
On Thu, 2013-09-26 at 22:34 -0500, Wang Dongsheng-B40534 wrote:
> 
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Friday, September 27, 2013 5:37 AM
> > To: Wang Dongsheng-B40534
> > Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
> > d...@lists.ozlabs.org
> > Subject: Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state and
> > altivec idle
> > 
> > On Thu, 2013-09-26 at 01:18 -0500, Wang Dongsheng-B40534 wrote:
> > >
> > > > -Original Message-
> > > > From: Bhushan Bharat-R65777
> > > > Sent: Thursday, September 26, 2013 12:23 PM
> > > > To: Wang Dongsheng-B40534; Wood Scott-B07421
> > > > Cc: linuxppc-dev@lists.ozlabs.org
> > > > Subject: RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state
> > > > and altivec idle
> > > >
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Wang Dongsheng-B40534
> > > > > Sent: Thursday, September 26, 2013 8:02 AM
> > > > > To: Wood Scott-B07421
> > > > > Cc: Bhushan Bharat-R65777; linuxppc-dev@lists.ozlabs.org
> > > > > Subject: RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20 state
> > > > > and altivec idle
> > > > >
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: Wood Scott-B07421
> > > > > > Sent: Thursday, September 26, 2013 1:57 AM
> > > > > > To: Wang Dongsheng-B40534
> > > > > > Cc: Bhushan Bharat-R65777; Wood Scott-B07421; linuxppc-
> > > > > > d...@lists.ozlabs.org
> > > > > > Subject: Re: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20
> > > > > > state and altivec idle
> > > > > >
> > > > > > On Wed, 2013-09-25 at 03:10 -0500, Wang Dongsheng-B40534 wrote:
> > > > > > >
> > > > > > > > -Original Message-
> > > > > > > > From: Bhushan Bharat-R65777
> > > > > > > > Sent: Wednesday, September 25, 2013 2:23 PM
> > > > > > > > To: Wang Dongsheng-B40534; Wood Scott-B07421
> > > > > > > > Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
> > > > > > > > Subject: RE: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20
> > > > > > > > state and altivec idle
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > -Original Message-
> > > > > > > > > From: Linuxppc-dev [mailto:linuxppc-dev-
> > > > > > > > > bounces+bharat.bhushan=freescale@lists.ozlabs.org] On
> > > > > > > > > bounces+Behalf Of Dongsheng
> > > > > > > > > Wang
> > > > > > > > > Sent: Tuesday, September 24, 2013 2:59 PM
> > > > > > > > > To: Wood Scott-B07421
> > > > > > > > > Cc: linuxppc-dev@lists.ozlabs.org; Wang Dongsheng-B40534
> > > > > > > > > Subject: [PATCH v4 4/4] powerpc/85xx: add sysfs for pw20
> > > > > > > > > state and altivec idle
> > > > > > > > >
> > > > > > > > > From: Wang Dongsheng 
> > > > > > > > >
> > > > > > > > > Add a sys interface to enable/diable pw20 state or altivec
> > > > > > > > > idle, and control the wait entry time.
> > > > > > > > >
> > > > > > > > > Enable/Disable interface:
> > > > > > > > > 0, disable. 1, enable.
> > > > > > > > > /sys/devices/system/cpu/cpuX/pw20_state
> > > > > > > > > /sys/devices/system/cpu/cpuX/altivec_idle
> > > > > > > > >
> > > > > > > > > Set wait time interface:(Nanosecond)
> > > > > > > > > /sys/devices/system/cpu/cpuX/pw20_wait_time
> > > > > > > > > /sys/devices/system/cpu/cpuX/altivec_idle_wait_time
> > > > > > > > > Example: Base on TBfreq is 41MHZ.
> > > > > > > > > 1~47(ns): TB[63]
> > > > > > > > > 48~95(ns): TB[62]
> > > > > > > > > 96~191(ns): TB[61]
> > > > > > > > > 192~383(ns): TB[62]
> > > > > > > > > 384~767(ns): TB[60]
> > > > > > > > > ...
> > > > > > > > >
> > > > > > > > > Signed-off-by: Wang Dongsheng
> > > > > > > > > 
> > > > > > > > > ---
> > > > > > > > > *v4:
> > > > > > > > > Move code from 85xx/common.c to kernel/sysfs.c.
> > > > > > > > >
> > > > > > > > > Remove has_pw20_altivec_idle function.
> > > > > > > > >
> > > > > > > > > Change wait "entry_bit" to wait time.
> > > > > > > > >
> > > > > > > > >  arch/powerpc/kernel/sysfs.c | 291
> > > > > > > > > 
> > > > > > > > >  1 file changed, 291 insertions(+)
> > > > > > > > >
> > > > > > > > > diff --git a/arch/powerpc/kernel/sysfs.c
> > > > > > > > > b/arch/powerpc/kernel/sysfs.c index 27a90b9..23fece6
> > > > > > > > > 100644
> > > > > > > > > --- a/arch/powerpc/kernel/sysfs.c
> > > > > > > > > +++ b/arch/powerpc/kernel/sysfs.c
> > > > > > > > > @@ -85,6 +85,279 @@ __setup("smt-snooze-delay=",
> > > > > > > > > setup_smt_snooze_delay);
> > > > > > > > >
> > > > > > > > >  #endif /* CONFIG_PPC64 */
> > > > > > > > >
> > > > > > > > > +#ifdef CONFIG_FSL_SOC
> > > > > > > > > +#define MAX_BIT  63
> > > > > > > > > +
> > > > > > > > > +static u64 pw20_wt;
> > > > > > > > > +static u64 altivec_idle_wt;
> > > > > > > > > +
> > > > > > > > > +static unsigned int get_idle_ticks_bit(u64 ns) {
> > > > > > > > > + u64 cycle;
> > > > > > > > > +
> > > > > > > > > + cycle = div_u64(ns, 1000 / tb_ticks_per_usec);
> > > > > > > >
> > > > > > > > When tb_ticks_per_usec  > 1000 (tim

Re: Please revert 928bea964827d7824b548c1f8e06eccbbc4d0d7d

2013-09-27 Thread Yinghai Lu
On Fri, Sep 27, 2013 at 9:01 AM, Yinghai Lu  wrote:
> On Fri, Sep 27, 2013 at 1:28 AM, Benjamin Herrenschmidt
>  wrote:
>> Hi Linus, Yinghai !
>>
>> Please consider reverting:
>>
>> 928bea964827d7824b548c1f8e06eccbbc4d0d7d
>> PCI: Delay enabling bridges until they're needed
>>
>> (I'd suggest to revert now and maybe merge a better patch later)
>>
>> This breaks PCI on the PowerPC "powernv" platform (which is booted via
>> kexec) and probably x86 as well under similar circumstances. It will
>> basically break PCIe if the bus master bit of the bridge isn't set at
>> boot (by the firmware for example, or because kexec'ing cleared it).
>>
>> The reason is that the PCIe port driver will call pci_enable_device() on
>> the bridge (on everything under the sun actually), which will marked the
>> device enabled (but will not do a set_master).
>>
>> Because of that, pci_enable_bridge() later on (called as a result of the
>> child device driver doing pci_enable_device) will see the bridge as
>> already enabled and will not call pci_set_master() on it.

Ben,

looks like PCIe port driver does call pci_enable_device AND pci_set_master()

| int pcie_port_device_register(struct pci_dev *dev)
| {
|int status, capabilities, i, nr_service;
|int irqs[PCIE_PORT_DEVICE_MAXSERVICES];
|
|/* Enable PCI Express port device */
|status = pci_enable_device(dev);
|if (status)
|return status;
|
|/* Get and check PCI Express port services */
|capabilities = get_port_device_capability(dev);
|if (!capabilities)
|return 0;
|
|pci_set_master(dev);

so how come that pci_set_master is not called for powerpc?

Can you send out lspci -vvxxx with current linus-tree and v3.11?

Yinghai
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc/mpic: Disable preemption when calling mpic_processor_id()

2013-09-27 Thread Scott Wood
On Fri, 2013-09-27 at 12:09 -0500, Kumar Gala wrote:
> On Sep 27, 2013, at 11:15 AM, Scott Wood wrote:
> 
> > On Fri, 2013-09-27 at 10:52 -0500, Kumar Gala wrote:
> >> On Sep 26, 2013, at 7:18 PM, Scott Wood wrote:
> >> 
> >>> Otherwise, we get a debug traceback due to the use of
> >>> smp_processor_id() (or get_paca()) inside hard_smp_processor_id().
> >>> mpic_host_map() is just looking for a default CPU, so it doesn't matter
> >>> if we migrate after getting the CPU ID.
> >>> 
> >>> Signed-off-by: Scott Wood 
> >>> ---
> >>> arch/powerpc/sysdev/mpic.c | 8 +++-
> >>> 1 file changed, 7 insertions(+), 1 deletion(-)
> >>> 
> >>> diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> >>> index 1be54fa..bdcb858 100644
> >>> --- a/arch/powerpc/sysdev/mpic.c
> >>> +++ b/arch/powerpc/sysdev/mpic.c
> >>> @@ -1088,8 +1088,14 @@ static int mpic_host_map(struct irq_domain *h, 
> >>> unsigned int virq,
> >>>* is done here.
> >>>*/
> >>>   if (!mpic_is_ipi(mpic, hw) && (mpic->flags & MPIC_NO_RESET)) {
> >>> + int cpu;
> >>> +
> >>> + preempt_disable();
> >>> + cpu = mpic_processor_id(mpic);
> >>> + preempt_enable();
> >>> +
> >> 
> >> Any reason you didn't stick this inside of mpic_processor_id() ?
> > 
> > Because the debug check might be valid for other callers and we don't
> > want to defeat it.  In this caller it's used only as a heuristic and
> > thus it doesn't matter if we re-enable preemption before using the
> > result.
> 
> Gotcha, I think you should reword the commit message.  Reading it makes
> me think that preemption should be disabled for all mpic_processor_id()
> calls.

It should be disabled for all mpic_processor_id() calls -- but some
calls will need preemption to be disabled for longer than just the call
to mpic_processor_id().

I did mention in the commit message why mpic_host_map() is unusual.

BTW, I wonder why we don't use mpic_set_affinity (and thus
irq_choose_cpu), both here and in the non-MPIC_NO_RESET case.  Though I
usually notice IRQs being round robinned -- I guess userspace is writing
to the affinity in proc?  Or is something elsewhere in the kernel
calling set_affinity at some point?

Another thing I just noticed while looking at IRQ_DESTINATION-related
code, in mpic_teardown_this_cpu(), what stops it from removing the only
CPU that an interrupt is targeted at?

-Scott



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH][v5] powerpc/mpc85xx:Add initial device tree support of T104x

2013-09-27 Thread Scott Wood
On Wed, 2013-09-25 at 15:40 +0530, Prabhakar Kushwaha wrote:
> The QorIQ T1040/T1042 processor support four integrated 64-bit e5500 PA
> processor cores with high-performance data path acceleration architecture
> and network peripheral interfaces required for networking & 
> telecommunications.
> 
> T1042 personality is a reduced personality of T1040 without Integrated 8-port
> Gigabit Ethernet switch.
> 
> The T1040/T1042 SoC includes the following function and features:
> 
>  - Four e5500 cores, each with a private 256 KB L2 cache
>  - 256 KB shared L3 CoreNet platform cache (CPC)
>  - Interconnect CoreNet platform
>  - 32-/64-bit DDR3L/DDR4 SDRAM memory controller with ECC and interleaving
>support
>  - Data Path Acceleration Architecture (DPAA) incorporating acceleration
>  for the following functions:
> -  Packet parsing, classification, and distribution
> -  Queue management for scheduling, packet sequencing, and congestion
>   management
> -  Cryptography Acceleration (SEC 5.0)
> - RegEx Pattern Matching Acceleration (PME 2.2)
> - IEEE Std 1588 support
> - Hardware buffer management for buffer allocation and deallocation
>  - Ethernet interfaces
> - Integrated 8-port Gigabit Ethernet switch (T1040 only)
> - Four 1 Gbps Ethernet controllers
>  - Two RGMII interfaces or one RGMII and one MII interfaces
>  - High speed peripheral interfaces
>- Four PCI Express 2.0 controllers running at up to 5 GHz
>- Two SATA controllers supporting 1.5 and 3.0 Gb/s operation
>- Upto two QSGMII interface
>- Upto six SGMII interface supporting 1000 Mbps
>- One SGMII interface supporting upto 2500 Mbps
>  - Additional peripheral interfaces
>- Two USB 2.0 controllers with integrated PHY
>- SD/eSDHC/eMMC
>-  eSPI controller
>- Four I2C controllers
>- Four UARTs
>- Four GPIO controllers
>- Integrated flash controller (IFC)
>- Change this to  LCD/ HDMI interface (DIU) with 12 bit dual data rate
>- TDM interface
>  - Multicore programmable interrupt controller (PIC)
>  - Two 8-channel DMA engines
>  - Single source clocking implementation
>  - Deep Sleep power implementaion (wakeup from GPIO/Timer/Ethernet/USB)
> 
> Signed-off-by: Poonam Aggrwal 
> Signed-off-by: Priyanka Jain 
> Signed-off-by: Varun Sethi 
> Signed-off-by: Prabhakar Kushwaha 
> ---
>  Based upon git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
>  Branch next
> 
> Changes for v2: Incorporated Scott's comments
>   - Update t1040si-post.dtsi
> - update clock device tree node as per
>   http://patchwork.ozlabs.org/patch/274134/
> - removed DMA node, It will be added later as per
>   http://patchwork.ozlabs.org/patch/271238/
> - Updated display compatible field
>  
>  Changes for v3: Incorporated Scott's comments
>- Updated soc compatible field
>- updated clock compatible field
> 
>  Changes for v4: Sending as it is 
>  Changes for v5: Sending as it is 

This should have been marked as a numbered patch set along with
"powerpc/fsl-booke: Add initial T104x_QDS board support".

> + display@18 {
> +compatible = "fsl,t1040-diu", "fsl,diu";
> +reg = <0x18 1000>;
> +interrupts = <74 2 0 0>;
> +};

Whitespace

> +l2switch@80 {
> + compatible = "fsl,t1040-l2s";
> + reg = <0x80 0x40>;
> +};

s/l2s/l2-switch/

Is there a better name for this?  Is there a version number or register?

There should be a binding, even if it's just a trivial one establishing
the compatible name, similar to
Documentation/devicetree/bindings/i2c/trivial-devices.txt 

-Scott



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: Please revert 928bea964827d7824b548c1f8e06eccbbc4d0d7d

2013-09-27 Thread Linus Torvalds
On Fri, Sep 27, 2013 at 9:01 AM, Yinghai Lu  wrote:
>
> So i would like to use the first way that you suggest : call pci_set_master
> PCIe port driver.

So I have to say, that if we can fix this with just adding a single
new pci_set_master() call, we should do that before we decide to
revert.

If other, bigger issues then come up, we can decide to revert. But if
there's a one-liner fix, let's just do that first, ok?

Mind sending a patch?

 Linus
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc/mpic: Disable preemption when calling mpic_processor_id()

2013-09-27 Thread Kumar Gala

On Sep 27, 2013, at 11:15 AM, Scott Wood wrote:

> On Fri, 2013-09-27 at 10:52 -0500, Kumar Gala wrote:
>> On Sep 26, 2013, at 7:18 PM, Scott Wood wrote:
>> 
>>> Otherwise, we get a debug traceback due to the use of
>>> smp_processor_id() (or get_paca()) inside hard_smp_processor_id().
>>> mpic_host_map() is just looking for a default CPU, so it doesn't matter
>>> if we migrate after getting the CPU ID.
>>> 
>>> Signed-off-by: Scott Wood 
>>> ---
>>> arch/powerpc/sysdev/mpic.c | 8 +++-
>>> 1 file changed, 7 insertions(+), 1 deletion(-)
>>> 
>>> diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
>>> index 1be54fa..bdcb858 100644
>>> --- a/arch/powerpc/sysdev/mpic.c
>>> +++ b/arch/powerpc/sysdev/mpic.c
>>> @@ -1088,8 +1088,14 @@ static int mpic_host_map(struct irq_domain *h, 
>>> unsigned int virq,
>>>  * is done here.
>>>  */
>>> if (!mpic_is_ipi(mpic, hw) && (mpic->flags & MPIC_NO_RESET)) {
>>> +   int cpu;
>>> +
>>> +   preempt_disable();
>>> +   cpu = mpic_processor_id(mpic);
>>> +   preempt_enable();
>>> +
>> 
>> Any reason you didn't stick this inside of mpic_processor_id() ?
> 
> Because the debug check might be valid for other callers and we don't
> want to defeat it.  In this caller it's used only as a heuristic and
> thus it doesn't matter if we re-enable preemption before using the
> result.

Gotcha, I think you should reword the commit message.  Reading it makes me 
think that preemption should be disabled for all mpic_processor_id() calls.

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH V4 3/3] powerpc/85xx: Add TWR-P1025 board support

2013-09-27 Thread Scott Wood
On Wed, 2013-09-25 at 04:50 -0500, Xie Xiaobo-R63061 wrote:
> > > +#if defined(CONFIG_SERIAL_QE)
> > > + /* On P1025TWR board, the UCC7 acted as UART port.
> > > +  * However, The UCC7's CTS pin is low level in default,
> > > +  * it will impact the transmission in full duplex
> > > +  * communication. So disable the Flow control pin PA18.
> > > +  * The UCC7 UART just can use RXD and TXD pins.
> > > +  */
> > > + par_io_config_pin(0, 18, 0, 0, 0, 0); #endif
> > 
> > Any reason not to do this unconditionally?
> 
> This is a board issue, the code already have a condition - defined
> SERIAL_QE, and I will add a condition "if (machine_is(twr_p1025))".

My point was, is there any harm in doing this without regard to
CONFIG_SERIAL_QE?

-Scott



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH V5 1/2] powerpc/85xx: Add QE common init function

2013-09-27 Thread Scott Wood
On Thu, 2013-09-26 at 17:37 +0800, Xie Xiaobo wrote:
> +#ifdef CONFIG_QUICC_ENGINE
> +void __init mpc85xx_qe_init(void)
> +{
> + struct device_node *np;
> +
> + np = of_find_compatible_node(NULL, NULL, "fsl,qe");
> + if (!np) {
> + np = of_find_node_by_name(NULL, "qe");
> + if (!np) {
> + pr_err("%s: Could not find Quicc Engine node\n",
> + __func__);
> + return;
> + }
> + }
> +
> + qe_reset();
> + of_node_put(np);

You're missing the of_device_is_available() check:

> - np = of_find_compatible_node(NULL, NULL, "fsl,qe");
> - if (!np) {
> - np = of_find_node_by_name(NULL, "qe");
> - if (!np)
> - return;
> - }
> -
> - if (!of_device_is_available(np)) {
> - of_node_put(np);
> - return;
> - }
> -
> - qe_reset();
> - of_node_put(np);

-Scott



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 2/2] pci: fsl: rework PCI driver compatible with Layerscape

2013-09-27 Thread Scott Wood
On Wed, 2013-09-18 at 19:02 +0800, Minghuan Lian wrote:
> @@ -592,6 +719,7 @@ int fsl_pci_mcheck_exception(struct pt_regs *regs)
>  #if defined(CONFIG_FSL_SOC_BOOKE) || defined(CONFIG_PPC_86xx)
>  
>  struct device_node *fsl_pci_primary;
> +extern const struct of_device_id fsl_pci_ids[];

Externs go in headers.

> -static int fsl_pci_probe(struct platform_device *pdev)
> +static int __init fsl_pci_probe(struct platform_device *pdev)
>  {
>   int ret;
> - struct device_node *node;
> + struct fsl_pci *pci;
> +
> + if (!of_device_is_available(pdev->dev.of_node)) {
> + dev_warn(&pdev->dev, "disabled\n");
> + return -ENODEV;
> + }

This should be dev_dbg().

> -#ifdef CONFIG_PM
> -static int fsl_pci_resume(struct device *dev)
> +static int __exit fsl_pci_remove(struct platform_device *pdev)

Why __exit?  What happens if someone unbinds the PCI controller via
sysfs?
 
> +/*
> + * Structure of a PCI controller (host bridge)
> + */
> +struct fsl_pci {
> + struct list_head node;
> + int is_pcie;

bool is_pcie;

> +/* Return link status 0-> link, 1-> no link */
> +int fsl_pci_check_link(struct fsl_pci *pci);

bool

> +
> +/*
> + * The fsl_arch_* functions are arch hooks. Those functions are
> + * implemented as weak symbols so that they can be overridden by
> + * architecture specific code if needed.
> + */
> +
> +/* Return PCI64 DMA offset */
> +u64 fsl_arch_pci64_dma_offset(void);

Is this always guaranteed to exist?

> +/* Register PCI/PCIe controller to architecture system */
> +int __weak fsl_arch_pci_sys_register(struct fsl_pci *pci);
> +
> +/* Remove PCI/PCIe controller from architecture system */
> +void __weak fsl_arch_pci_sys_remove(struct fsl_pci *pci);

Why do these need to be weak?  Won't there be exactly one implementation
per supported arch?

-Scott



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 2/2] pci: fsl: rework PCI driver compatible with Layerscape

2013-09-27 Thread Scott Wood
On Fri, 2013-09-27 at 19:29 +0800, Lian Minghuan-b31939 wrote:
> Hi All,
> 
> Can anyone comment on my code or help to pick up?

Please break it up into multiple patches, each with one logical change
that is individually explained.  It will be much easier to review that
way.

-Scott



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc/mpic: Disable preemption when calling mpic_processor_id()

2013-09-27 Thread Scott Wood
On Fri, 2013-09-27 at 10:52 -0500, Kumar Gala wrote:
> On Sep 26, 2013, at 7:18 PM, Scott Wood wrote:
> 
> > Otherwise, we get a debug traceback due to the use of
> > smp_processor_id() (or get_paca()) inside hard_smp_processor_id().
> > mpic_host_map() is just looking for a default CPU, so it doesn't matter
> > if we migrate after getting the CPU ID.
> > 
> > Signed-off-by: Scott Wood 
> > ---
> > arch/powerpc/sysdev/mpic.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> > index 1be54fa..bdcb858 100644
> > --- a/arch/powerpc/sysdev/mpic.c
> > +++ b/arch/powerpc/sysdev/mpic.c
> > @@ -1088,8 +1088,14 @@ static int mpic_host_map(struct irq_domain *h, 
> > unsigned int virq,
> >  * is done here.
> >  */
> > if (!mpic_is_ipi(mpic, hw) && (mpic->flags & MPIC_NO_RESET)) {
> > +   int cpu;
> > +
> > +   preempt_disable();
> > +   cpu = mpic_processor_id(mpic);
> > +   preempt_enable();
> > +
> 
> Any reason you didn't stick this inside of mpic_processor_id() ?

Because the debug check might be valid for other callers and we don't
want to defeat it.  In this caller it's used only as a heuristic and
thus it doesn't matter if we re-enable preemption before using the
result.

-Scott



___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: Please revert 928bea964827d7824b548c1f8e06eccbbc4d0d7d

2013-09-27 Thread Yinghai Lu
On Fri, Sep 27, 2013 at 1:28 AM, Benjamin Herrenschmidt
 wrote:
> Hi Linus, Yinghai !
>
> Please consider reverting:
>
> 928bea964827d7824b548c1f8e06eccbbc4d0d7d
> PCI: Delay enabling bridges until they're needed
>
> (I'd suggest to revert now and maybe merge a better patch later)
>
> This breaks PCI on the PowerPC "powernv" platform (which is booted via
> kexec) and probably x86 as well under similar circumstances. It will
> basically break PCIe if the bus master bit of the bridge isn't set at
> boot (by the firmware for example, or because kexec'ing cleared it).
>
> The reason is that the PCIe port driver will call pci_enable_device() on
> the bridge (on everything under the sun actually), which will marked the
> device enabled (but will not do a set_master).
>
> Because of that, pci_enable_bridge() later on (called as a result of the
> child device driver doing pci_enable_device) will see the bridge as
> already enabled and will not call pci_set_master() on it.
>
> Now, this could probably be fixed by simply doing pci_set_master() in
> the PCIe port driver, but I find the whole logic very fragile (anything
> that "enables" the bridge without setting master or for some reason
> clears master will forever fail to re-enable it).
>
> Maybe a better option is to unconditionally do pci_set_mater() in
> pci_enable_bridge(), ie, move the call to before the enabled test.
>
> However I am not too happy with that either. My experience with bridges
> is that if bus master isn't set, they will also fail to report AER
> errors and other similar upstream transactions. We might want to get
> these reported properly even if no downstream device got successfully
> enabled.
>
> So I think the premises of the patches are flawed, at least on PCI
> express, and we should stick to always enabling bridges (at least the
> bus master bit on them).

there is pci_set_master everywhere in pci drivers.

So i would like to use the first way that you suggest : call pci_set_master
PCIe port driver.

Thanks

Yinghai
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: therm_pm72 units, interface

2013-09-27 Thread Michel Dänzer
On Mon, 2013-08-05 at 20:53 +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2013-08-05 at 12:32 +0200, Michel Dänzer wrote:
> > 
> > I did that, sorry should have mentioned that.
> > 
> > 
> > > > @@ -468,5 +478,3 @@ static struct platform_driver
> > i2c_powermac_driver
> > > > =
> > > > {
> > > >  };
> > > > 
> > > >  module_platform_driver(i2c_powermac_driver);
> > > > -
> > > > -MODULE_ALIAS("platform:i2c-powermac");
> > > 
> > > Maybe add the module alias back ? It shouldn't be necessary...
> > 
> > Doesn't help.
> 
> Hrm, that might require some more involved debugging, figuring out
> what's up with udev etc... that or maybe bisecting.
> 
> From what I can tell, we do attach an OF node to the platform device,
> but since the driver has no of match table, we should still fallback to
> the old platform matching style.
> 
> I think I see... adding Grant.

Did that work? He's not in Cc on the post I received from the list, but
that might be due to his mailman settings.


> Grant, something broke the auto-loading the of i2c-powermac module. It's
> a platform device, but while it does have a populated "of_node, its
> driver doesn't have an OF match table and relies on the old style
> platform device matching.
> 
> That's broken with newer kernels, platform_uevent() calls
> of_device_uevent_modalias() which sees the of_node and thus doesn't
> return -ENOMEM, and we don't create a platform modalias anymore.
> 
> Is it legit to add several MODALIAS ? If yes we could add both ... if
> not, we have a problem. Doing real OF matching with that critter is
> tricky at best for various reasons but it needs the of_node because it
> uses it to scan for children.
> 
> Any suggestion ?

Any news on this? I recently learned the hard way that loading
i2c-powermac manually via /etc/modules isn't a good workaround, as that
only happens after fsck...


-- 
Earthling Michel Dänzer|  http://www.amd.com
Libre software enthusiast  |Mesa and X developer

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/mpic: Disable preemption when calling mpic_processor_id()

2013-09-27 Thread Kumar Gala

On Sep 26, 2013, at 7:18 PM, Scott Wood wrote:

> Otherwise, we get a debug traceback due to the use of
> smp_processor_id() (or get_paca()) inside hard_smp_processor_id().
> mpic_host_map() is just looking for a default CPU, so it doesn't matter
> if we migrate after getting the CPU ID.
> 
> Signed-off-by: Scott Wood 
> ---
> arch/powerpc/sysdev/mpic.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
> index 1be54fa..bdcb858 100644
> --- a/arch/powerpc/sysdev/mpic.c
> +++ b/arch/powerpc/sysdev/mpic.c
> @@ -1088,8 +1088,14 @@ static int mpic_host_map(struct irq_domain *h, 
> unsigned int virq,
>* is done here.
>*/
>   if (!mpic_is_ipi(mpic, hw) && (mpic->flags & MPIC_NO_RESET)) {
> + int cpu;
> +
> + preempt_disable();
> + cpu = mpic_processor_id(mpic);
> + preempt_enable();
> +

Any reason you didn't stick this inside of mpic_processor_id() ?

>   mpic_set_vector(virq, hw);
> - mpic_set_destination(virq, mpic_processor_id(mpic));
> + mpic_set_destination(virq, cpu);
>   mpic_irq_set_priority(virq, 8);
>   }
> 
> -- 
> 1.8.1.2
> 
> 
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: mm: insure topdown mmap chooses addresses above security minimum

2013-09-27 Thread Timothy Pepper
On Wed 25 Sep at 19:44:36 +0200 mi...@kernel.org said:
> 
> * Timothy Pepper  wrote:
> 
> > On Wed 25 Sep at 09:30:49 +0200 mi...@kernel.org said:
> > > > info.flags = VM_UNMAPPED_AREA_TOPDOWN;
> > > > info.length = len;
> > > > -   info.low_limit = PAGE_SIZE;
> > > > +   info.low_limit = max(PAGE_SIZE, PAGE_ALIGN(mmap_min_addr));
> > > > info.high_limit = mm->mmap_base;
> > > > info.align_mask = filp ? get_align_mask() : 0;
> > > > info.align_offset = pgoff << PAGE_SHIFT;
> > > 
> > > There appears to be a lot of repetition in these methods - instead of 
> > > changing 6 places it would be more future-proof to first factor out the 
> > > common bits and then to apply the fix to the shared implementation.
> > 
> > Besides that existing redundancy in the multiple somewhat similar
> > arch_get_unmapped_area_topdown() functions, I was expecting people might
> > question the added redundancy of the six instances of:
> > 
> > max(PAGE_SIZE, PAGE_ALIGN(mmap_min_addr));
> 
> That redundancy would be automatically addressed by my suggestion.

Yes.

I'm looking at the cleanup and will post a bisectable series that
introduces a common helper, addes the calls to use that helper where
applicable (looks like it might be a few dozen per arch locations), and
then the single line change for the topdown case within the common helper
to do:

info->low_limit = max(PAGE_SIZE, PAGE_ALIGN(mmap_min_addr));

-- 
Tim Pepper 
Intel Open Source Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH v1] powerpc/mpc512x: silence build warning upon disabled DIU

2013-09-27 Thread Gerhard Sittig
a disabled Kconfig option results in a reference to a not implemented
routine when the IS_ENABLED() macro is used for both conditional
implementation of the routine as well as a C language source code test
at the call site -- the "if (0) func();" construct only gets eliminated
later by the optimizer, while the compiler already has emitted its
warning about "func()" being undeclared

provide an empty implementation for the mpc512x_setup_diu() and
mpc512x_init_diu() routines in case of the disabled option, to avoid the
compiler warning which is considered fatal and breaks compilation

the bug appeared with commit 2a63c90ab55ca3f054772c2e5ba7df810c48
"powerpc/mpc512x: move common code to shared.c file", how to reproduce:

  make mpc512x_defconfig
  echo CONFIG_FB_FSL_DIU=n >> .config && make olddefconfig
  make

CC  arch/powerpc/platforms/512x/mpc512x_shared.o
  .../arch/powerpc/platforms/512x/mpc512x_shared.c: In function 
'mpc512x_init_early':
  .../arch/powerpc/platforms/512x/mpc512x_shared.c:456:3: error: implicit 
declaration of function 'mpc512x_init_diu' 
[-Werror=implicit-function-declaration]
  .../arch/powerpc/platforms/512x/mpc512x_shared.c: In function 
'mpc512x_setup_arch':
  .../arch/powerpc/platforms/512x/mpc512x_shared.c:469:3: error: implicit 
declaration of function 'mpc512x_setup_diu' 
[-Werror=implicit-function-declaration]
  cc1: all warnings being treated as errors
  make[4]: *** [arch/powerpc/platforms/512x/mpc512x_shared.o] Error 1

Signed-off-by: Gerhard Sittig 
CC:  # v3.11
---
 arch/powerpc/platforms/512x/mpc512x_shared.c |3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c 
b/arch/powerpc/platforms/512x/mpc512x_shared.c
index a82a41b..1a7b1d0 100644
--- a/arch/powerpc/platforms/512x/mpc512x_shared.c
+++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
@@ -303,6 +303,9 @@ void __init mpc512x_setup_diu(void)
diu_ops.release_bootmem = mpc512x_release_bootmem;
 }
 
+#else
+void __init mpc512x_setup_diu(void) { /* EMPTY */ }
+void __init mpc512x_init_diu(void) { /* EMPTY */ }
 #endif
 
 void __init mpc512x_init_IRQ(void)
-- 
1.7.10.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v3] powerpc/83xx: gianfar_ptp: select 1588 clock source through dts file

2013-09-27 Thread Kumar Gala

On Sep 27, 2013, at 8:40 AM, Aida Mynzhasova wrote:

> Currently IEEE 1588 timer reference clock source is determined through
> hard-coded value in gianfar_ptp driver. This patch allows to select ptp
> clock source by means of device tree file node.
> 
> For instance:
> 
>   fsl,cksel = <0>;
> 
> for using external (TSEC_TMR_CLK input) high precision timer
> reference clock.
> 
> Other acceptable values:
> 
>   <1> : eTSEC system clock
>   <2> : eTSEC1 transmit clock
>   <3> : RTC clock input
> 
> When this attribute isn't used, eTSEC system clock will serve as
> IEEE 1588 timer reference clock.
> 
> Signed-off-by: Aida Mynzhasova 
> ---
> Documentation/devicetree/bindings/net/fsl-tsec-phy.txt | 18 +-
> drivers/net/ethernet/freescale/gianfar_ptp.c   |  4 +++-
> 2 files changed, 20 insertions(+), 2 deletions(-)

Acked-by: Kumar Gala 

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH] Correct memory hotplug for ppc with sparse vmemmap

2013-09-27 Thread Nathan Fontenot
Previous commit 46723bfa540... introduced a new config option
HAVE_BOOTMEM_INFO_NODE that ended up breaking memory hot-remove for ppc
when sparse vmemmap is not defined.

This patch defines HAVE_BOOTMEM_INFO_NODE for ppc and adds the call to
register_page_bootmem_info_node. Without this we get a BUG_ON for memory
hot remove in put_page_bootmem().

This also adds a stub for register_page_bootmem_memmap to allow ppc to build
with sparse vmemmap defined. Leaving this as a stub is fine since the same
vmemmap addresses are also handled in vmemmap_populate and as such are
properly mapped.

Signed-off-by: Nathan Fontenot 
---
 arch/powerpc/mm/init_64.c |4 
 arch/powerpc/mm/mem.c |9 +
 mm/Kconfig|2 +-
 3 files changed, 14 insertions(+), 1 deletion(-)

Index: powerpc/arch/powerpc/mm/init_64.c
===
--- powerpc.orig/arch/powerpc/mm/init_64.c
+++ powerpc/arch/powerpc/mm/init_64.c
@@ -300,5 +300,9 @@ void vmemmap_free(unsigned long start, u
 {
 }

+void register_page_bootmem_memmap(unsigned long section_nr,
+ struct page *start_page, unsigned long size)
+{
+}
 #endif /* CONFIG_SPARSEMEM_VMEMMAP */

Index: powerpc/arch/powerpc/mm/mem.c
===
--- powerpc.orig/arch/powerpc/mm/mem.c
+++ powerpc/arch/powerpc/mm/mem.c
@@ -297,12 +297,21 @@ void __init paging_init(void)
 }
 #endif /* ! CONFIG_NEED_MULTIPLE_NODES */

+static void __init register_page_bootmem_info(void)
+{
+   int i;
+
+   for_each_online_node(i)
+   register_page_bootmem_info_node(NODE_DATA(i));
+}
+
 void __init mem_init(void)
 {
 #ifdef CONFIG_SWIOTLB
swiotlb_init(0);
 #endif

+   register_page_bootmem_info();
high_memory = (void *) __va(max_low_pfn * PAGE_SIZE);
set_max_mapnr(max_pfn);
free_all_bootmem();
Index: powerpc/mm/Kconfig
===
--- powerpc.orig/mm/Kconfig
+++ powerpc/mm/Kconfig
@@ -183,7 +183,7 @@ config MEMORY_HOTPLUG_SPARSE
 config MEMORY_HOTREMOVE
bool "Allow for memory hot remove"
select MEMORY_ISOLATION
-   select HAVE_BOOTMEM_INFO_NODE if X86_64
+   select HAVE_BOOTMEM_INFO_NODE if (X86_64 || PPC64)
depends on MEMORY_HOTPLUG && ARCH_ENABLE_MEMORY_HOTREMOVE
depends on MIGRATION

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 09/11] kvm: simplify processor compat check

2013-09-27 Thread Paolo Bonzini
Il 27/09/2013 15:13, Aneesh Kumar K.V ha scritto:
> Alexander Graf  writes:
> 
>> On 27.09.2013, at 12:03, Aneesh Kumar K.V wrote:
>>
>>> From: "Aneesh Kumar K.V" 
>>
>> Missing patch description.
>>
>>> Signed-off-by: Aneesh Kumar K.V 
>>
>> I fail to see how this really simplifies things, but at the end of the
>> day it's Gleb's and Paolo's call.
> 
> will do. It avoid calling 
> 
>   for_each_online_cpu(cpu) {
>   smp_call_function_single() 
> 
> on multiple architecture.

I agree with Alex.

The current code is not specially awesome; having
kvm_arch_check_processor_compat take an int* disguised as a void* is a
bit ugly indeed.

However, the API makes sense and tells you that it is being passed as a
callback (to smp_call_function_single in this case).

You are making the API more complicated to use on the arch layer
(because arch maintainers now have to think "do I need to check this on
all online CPUs?") and making the "leaf" POWER code less legible because
it still has the weird void()(void *) calling convention.

If anything, you could change kvm_arch_check_processor_compat to return
an int and accept no argument, and introduce a wrapper that kvm_init
passes to smp_call_function_single.

Paolo

> We also want to make the smp call function a callback of opaque. Hence
> this should be made arch specific. 
> 
> int kvm_arch_check_processor_compat(void *opaque)
> {
>   int r,cpu;
>   struct kvmppc_ops *kvm_ops = (struct kvmppc_ops *)opaque;
>   for_each_online_cpu(cpu) {
>   smp_call_function_single(cpu,
>kvm_ops->check_processor_compat,
>&r, 1);
>   if (r < 0)
>   break;
>   }
>   return r;
> }
> 
> against
> 
> - for_each_online_cpu(cpu) {
> - smp_call_function_single(cpu,
> - kvm_arch_check_processor_compat,
> - &r, 1);
> - if (r < 0)
> - goto out_free_1;
> - }
> +
> + r = kvm_arch_check_processor_compat(opaque);
> + if (r < 0)
> + goto out_free_1;
> 
> 
> 
>>
>> Which brings me to the next issue: You forgot to CC kvm@vger on your
>> patch set. Gleb and Paolo don't read kvm-ppc@vger. And they shouldn't
>> have to. Every kvm patch that you want review on or that should get
>> applied needs to be sent to kvm@vger. If you want to tag it as PPC
>> specific patch, do so by CC'ing kvm-ppc@vger.
> 
> Will do in the next update
> 
> -aneesh
> 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH V2] powerpc/kvm/book3s_hv: propagate H_SET_MODE_RESOURCE_LE to the host

2013-09-27 Thread Greg Kurz
On Fri, 27 Sep 2013 15:59:30 +0200
Laurent Dufour  wrote:

> Follow-up to Anton's H_SET_MODE patch, the host should be taken aware
> of guest endianess change.
> 
> The hcall H_SET_MODE/H_SET_MODE_RESOURCE_LE is processed in kvm and
> then propagated to the host.
> 

Even if it seems a bit odd to get H_SET_MODE handled both by kvm and
qemu, it is a simple way to get the job done. Unless we expect tons of
calls to H_SET_MODE_RESOURCE_LE to occur, I do not see a better way for
the host code to know the guest endianess.

FYI, with this patch, Rusty's (Cc'ed) virtio endianess patchset for
qemu works like a charm: my guest kernel calls h_set_mode once at boot
time, qemu gets notified and keeps the information. Do we need more ?

> v2: taking in account the Paul Mackerras's comment, using H_TOO_HARD
> to propagate only H_SET_MODE_RESOURCE_LE to the host.
> 
> Signed-off-by: Laurent Dufour 
> ---

Tested-by: Greg Kurz 

>  arch/powerpc/kvm/book3s_hv.c |6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/kvm/book3s_hv.c
> b/arch/powerpc/kvm/book3s_hv.c index 998cad3..be0af39 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -523,14 +523,14 @@ static int kvmppc_h_set_mode(struct kvm_vcpu
> *vcpu, unsigned long mflags, kvm_for_each_vcpu(n, v, kvm)
>   v->arch.intr_msr &= ~MSR_LE;
>   kick_all_cpus_sync();
> - return H_SUCCESS;
> + return H_TOO_HARD; /* propagating to the
> host */
> 
>   case 1:
>   kvm->arch.lpcr |= LPCR_ILE;
>   kvm_for_each_vcpu(n, v, kvm)
>   v->arch.intr_msr |= MSR_LE;
>   kick_all_cpus_sync();
> - return H_SUCCESS;
> + return H_TOO_HARD; /* propagating to the
> host */
> 
>   default:
>   return H_UNSUPPORTED_FLAG_START;
> @@ -599,6 +599,8 @@ int kvmppc_pseries_do_hcall(struct kvm_vcpu *vcpu)
>   kvmppc_get_gpr(vcpu, 5),
>   kvmppc_get_gpr(vcpu, 6),
>   kvmppc_get_gpr(vcpu, 7));
> + if (ret == H_TOO_HARD)
> + return RESUME_HOST;
>   break;
> 
>   case H_XIRR:
> 
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
> 



-- 
Gregory Kurz kurzg...@fr.ibm.com
 gk...@linux.vnet.ibm.com
Software Engineer @ IBM/Meiosys  http://www.ibm.com
Tel +33 (0)562 165 496

"Anarchy is about taking complete responsibility for yourself."
Alan Moore.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 3/3] KVM: PPC: Book3S: Add support for hwrng found on some powernv systems

2013-09-27 Thread Anshuman Khandual
On 09/26/2013 12:01 PM, Michael Ellerman wrote:
> +int powernv_hwrng_present(void)
> +{
> + return __raw_get_cpu_var(powernv_rng) != NULL;
> +}
> +
>  static unsigned long rng_whiten(struct powernv_rng *rng, unsigned long val)
>  {
>   unsigned long parity;
> @@ -42,6 +48,17 @@ static unsigned long rng_whiten(struct powernv_rng *rng, 
> unsigned long val)
>   return val;
>  }
> 
> +int powernv_get_random_real_mode(unsigned long *v)
> +{
> + struct powernv_rng *rng;
> +
> + rng = __raw_get_cpu_var(powernv_rng);
> +
> + *v = rng_whiten(rng, in_rm64(rng->regs_real));
> +

Will it be in_be64() instead of in_rm64() ? Its failing the build here. Except 
this
all individual patches build correctly.

Regards
Anshuman

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH V2] powerpc/kvm/book3s_hv: propagate H_SET_MODE_RESOURCE_LE to the host

2013-09-27 Thread Laurent Dufour
Follow-up to Anton's H_SET_MODE patch, the host should be taken aware of
guest endianess change.

The hcall H_SET_MODE/H_SET_MODE_RESOURCE_LE is processed in kvm and then
propagated to the host.

v2: taking in account the Paul Mackerras's comment, using H_TOO_HARD to
propagate only H_SET_MODE_RESOURCE_LE to the host.

Signed-off-by: Laurent Dufour 
---
 arch/powerpc/kvm/book3s_hv.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 998cad3..be0af39 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -523,14 +523,14 @@ static int kvmppc_h_set_mode(struct kvm_vcpu *vcpu, 
unsigned long mflags,
kvm_for_each_vcpu(n, v, kvm)
v->arch.intr_msr &= ~MSR_LE;
kick_all_cpus_sync();
-   return H_SUCCESS;
+   return H_TOO_HARD; /* propagating to the host */
 
case 1:
kvm->arch.lpcr |= LPCR_ILE;
kvm_for_each_vcpu(n, v, kvm)
v->arch.intr_msr |= MSR_LE;
kick_all_cpus_sync();
-   return H_SUCCESS;
+   return H_TOO_HARD; /* propagating to the host */
 
default:
return H_UNSUPPORTED_FLAG_START;
@@ -599,6 +599,8 @@ int kvmppc_pseries_do_hcall(struct kvm_vcpu *vcpu)
kvmppc_get_gpr(vcpu, 5),
kvmppc_get_gpr(vcpu, 6),
kvmppc_get_gpr(vcpu, 7));
+   if (ret == H_TOO_HARD)
+   return RESUME_HOST;
break;
 
case H_XIRR:

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH v3] powerpc/83xx: gianfar_ptp: select 1588 clock source through dts file

2013-09-27 Thread Aida Mynzhasova
Currently IEEE 1588 timer reference clock source is determined through
hard-coded value in gianfar_ptp driver. This patch allows to select ptp
clock source by means of device tree file node.

For instance:

fsl,cksel = <0>;

for using external (TSEC_TMR_CLK input) high precision timer
reference clock.

Other acceptable values:

<1> : eTSEC system clock
<2> : eTSEC1 transmit clock
<3> : RTC clock input

When this attribute isn't used, eTSEC system clock will serve as
IEEE 1588 timer reference clock.

Signed-off-by: Aida Mynzhasova 
---
 Documentation/devicetree/bindings/net/fsl-tsec-phy.txt | 18 +-
 drivers/net/ethernet/freescale/gianfar_ptp.c   |  4 +++-
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt 
b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
index 2c6be03..d2ea460 100644
--- a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
+++ b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
@@ -86,6 +86,7 @@ General Properties:
 
 Clock Properties:
 
+  - fsl,ckselTimer reference clock source.
   - fsl,tclk-period  Timer reference clock period in nanoseconds.
   - fsl,tmr-prsc Prescaler, divides the output clock.
   - fsl,tmr-add  Frequency compensation value.
@@ -97,7 +98,7 @@ Clock Properties:
   clock. You must choose these carefully for the clock to work right.
   Here is how to figure good values:
 
-  TimerOsc = system clock   MHz
+  TimerOsc = selected reference clock   MHz
   tclk_period  = desired clock period   nanoseconds
   NominalFreq  = 1000 / tclk_period MHz
   FreqDivRatio = TimerOsc / NominalFreq (must be greater that 1.0)
@@ -114,6 +115,20 @@ Clock Properties:
   Pulse Per Second (PPS) signal, since this will be offered to the PPS
   subsystem to synchronize the Linux clock.
 
+  Reference clock source is determined by the value, which is holded
+  in CKSEL bits in TMR_CTRL register. "fsl,cksel" property keeps the
+  value, which will be directly written in those bits, that is why,
+  according to reference manual, the next clock sources can be used:
+
+  <0> - external high precision timer reference clock (TSEC_TMR_CLK
+input is used for this purpose);
+  <1> - eTSEC system clock;
+  <2> - eTSEC1 transmit clock;
+  <3> - RTC clock input.
+
+  When this attribute is not used, eTSEC system clock will serve as
+  IEEE 1588 timer reference clock.
+
 Example:
 
ptp_clock@24E00 {
@@ -121,6 +136,7 @@ Example:
reg = <0x24E00 0xB0>;
interrupts = <12 0x8 13 0x8>;
interrupt-parent = < &ipic >;
+   fsl,cksel   = <1>;
fsl,tclk-period = <10>;
fsl,tmr-prsc= <100>;
fsl,tmr-add = <0x99A4>;
diff --git a/drivers/net/ethernet/freescale/gianfar_ptp.c 
b/drivers/net/ethernet/freescale/gianfar_ptp.c
index 098f133..e006a09 100644
--- a/drivers/net/ethernet/freescale/gianfar_ptp.c
+++ b/drivers/net/ethernet/freescale/gianfar_ptp.c
@@ -452,7 +452,9 @@ static int gianfar_ptp_probe(struct platform_device *dev)
err = -ENODEV;
 
etsects->caps = ptp_gianfar_caps;
-   etsects->cksel = DEFAULT_CKSEL;
+
+   if (get_of_u32(node, "fsl,cksel", &etsects->cksel))
+   etsects->cksel = DEFAULT_CKSEL;
 
if (get_of_u32(node, "fsl,tclk-period", &etsects->tclk_period) ||
get_of_u32(node, "fsl,tmr-prsc", &etsects->tmr_prsc) ||
-- 
1.8.1.2

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 09/11] kvm: simplify processor compat check

2013-09-27 Thread Aneesh Kumar K.V
Alexander Graf  writes:

> On 27.09.2013, at 12:03, Aneesh Kumar K.V wrote:
>
>> From: "Aneesh Kumar K.V" 
>
> Missing patch description.
>
>> Signed-off-by: Aneesh Kumar K.V 
>
> I fail to see how this really simplifies things, but at the end of the
> day it's Gleb's and Paolo's call.

will do. It avoid calling 

for_each_online_cpu(cpu) {
smp_call_function_single() 

on multiple architecture.

We also want to make the smp call function a callback of opaque. Hence
this should be made arch specific. 

int kvm_arch_check_processor_compat(void *opaque)
{
int r,cpu;
struct kvmppc_ops *kvm_ops = (struct kvmppc_ops *)opaque;
for_each_online_cpu(cpu) {
smp_call_function_single(cpu,
 kvm_ops->check_processor_compat,
 &r, 1);
if (r < 0)
break;
}
return r;
}

against

-   for_each_online_cpu(cpu) {
-   smp_call_function_single(cpu,
-   kvm_arch_check_processor_compat,
-   &r, 1);
-   if (r < 0)
-   goto out_free_1;
-   }
+
+   r = kvm_arch_check_processor_compat(opaque);
+   if (r < 0)
+   goto out_free_1;



>
> Which brings me to the next issue: You forgot to CC kvm@vger on your
> patch set. Gleb and Paolo don't read kvm-ppc@vger. And they shouldn't
> have to. Every kvm patch that you want review on or that should get
> applied needs to be sent to kvm@vger. If you want to tag it as PPC
> specific patch, do so by CC'ing kvm-ppc@vger.

Will do in the next update

-aneesh

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 08/11] kvm: powerpc: book3s: Support building HV and PR KVM as module

2013-09-27 Thread Aneesh Kumar K.V
Alexander Graf  writes:

> On 27.09.2013, at 12:03, Aneesh Kumar K.V wrote:
>
>> diff --git a/arch/powerpc/kvm/book3s_64_mmu_host.c 
>> b/arch/powerpc/kvm/book3s_64_mmu_host.c
>> index fd5b393..775d368 100644
>> --- a/arch/powerpc/kvm/book3s_64_mmu_host.c
>> +++ b/arch/powerpc/kvm/book3s_64_mmu_host.c
>> @@ -27,6 +27,7 @@
>> #include 
>> #include 
>> #include 
>> +
>
> Stray whitespace change
>

will fix

>> #include "trace_pr.h"
>> 
>> #define PTE_SIZE 12
>> diff --git a/arch/powerpc/kvm/book3s_emulate.c 
>> b/arch/powerpc/kvm/book3s_emulate.c
>> index b9841ad..20d03c2 100644
>> --- a/arch/powerpc/kvm/book3s_emulate.c
>> +++ b/arch/powerpc/kvm/book3s_emulate.c
>> @@ -172,7 +172,7 @@ int kvmppc_core_emulate_op_pr(struct kvm_run *run, 
>> struct kvm_vcpu *vcpu,
>>  vcpu->arch.mmu.tlbie(vcpu, addr, large);
>>  break;
>>  }
>> -#ifdef CONFIG_KVM_BOOK3S_64_PR
>> +#ifdef CONFIG_KVM_BOOK3S_PR
>
> Why?

If i have CONFIG_KVM_BOOK3S_64_PR=m  #ifdef CONFIG_KVM_BOOK3S_64_PR will
not work. There is a runtime check I can use IS_ENABLED(). But didn't
want to do those. Hence moved to the symbol which will be set as
CONFIG_KVM_BOOK3S_PR = y

-aneesh

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 07/11] kvm: powerpc: book3s: pr: move PR related tracepoints to a separate header

2013-09-27 Thread Aneesh Kumar K.V
Alexander Graf  writes:

> On 27.09.2013, at 12:03, Aneesh Kumar K.V wrote:
>
>> From: "Aneesh Kumar K.V" 
>> 
>> This patch moves PR related tracepoints to a separate header. This
>> enables in converting PR to a kernel module which will be done in
>> later patches
>> 
>> Signed-off-by: Aneesh Kumar K.V 
>> ---
>> arch/powerpc/kvm/book3s_64_mmu_host.c |   2 +-
>> arch/powerpc/kvm/book3s_mmu_hpte.c|   2 +-
>> arch/powerpc/kvm/book3s_pr.c  |   3 +-
>> arch/powerpc/kvm/trace.h  | 234 +--
>> arch/powerpc/kvm/trace_pr.h   | 297 
>> ++
>> 5 files changed, 308 insertions(+), 230 deletions(-)
>> create mode 100644 arch/powerpc/kvm/trace_pr.h
>> 
>> diff --git a/arch/powerpc/kvm/book3s_64_mmu_host.c 
>> b/arch/powerpc/kvm/book3s_64_mmu_host.c
>> index 329a978..fd5b393 100644
>> --- a/arch/powerpc/kvm/book3s_64_mmu_host.c
>> +++ b/arch/powerpc/kvm/book3s_64_mmu_host.c
>> @@ -27,7 +27,7 @@
>> #include 
>> #include 
>> #include 
>> -#include "trace.h"
>> +#include "trace_pr.h"
>> 
>> #define PTE_SIZE 12
>> 
>> diff --git a/arch/powerpc/kvm/book3s_mmu_hpte.c 
>> b/arch/powerpc/kvm/book3s_mmu_hpte.c
>> index d2d280b..4556168 100644
>> --- a/arch/powerpc/kvm/book3s_mmu_hpte.c
>> +++ b/arch/powerpc/kvm/book3s_mmu_hpte.c
>> @@ -28,7 +28,7 @@
>> #include 
>> #include 
>> 
>> -#include "trace.h"
>> +#include "trace_pr.h"
>> 
>> #define PTE_SIZE 12
>> 
>> diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
>> index 2a97279..99d0839 100644
>> --- a/arch/powerpc/kvm/book3s_pr.c
>> +++ b/arch/powerpc/kvm/book3s_pr.c
>> @@ -41,7 +41,8 @@
>> #include 
>> #include 
>> 
>> -#include "trace.h"
>> +#define CREATE_TRACE_POINTS
>> +#include "trace_pr.h"
>> 
>> /* #define EXIT_DEBUG */
>> /* #define DEBUG_EXT */
>> diff --git a/arch/powerpc/kvm/trace.h b/arch/powerpc/kvm/trace.h
>> index a088e9a..7d5a136 100644
>> --- a/arch/powerpc/kvm/trace.h
>> +++ b/arch/powerpc/kvm/trace.h
>> @@ -85,6 +85,12 @@ TRACE_EVENT(kvm_ppc_instr,
>>  {41, "HV_PRIV"}
>> #endif
>> 
>> +#ifndef CONFIG_KVM_BOOK3S_PR
>> +/*
>> + * For pr we define this in trace_pr.h since it pr can be built as
>> + * a module
>
> Not sure I understand the need. If the config option is available, so
> should the struct field. Worst case that happens with HV is that we
> get empty shadow_srr1 values in our trace, no?

That is not the real reason. trace.h get built as part of kvm.ko or as
part of kernel. These trace functions actually get called from
kvm-pr.ko. To make they build i would either need EXPORT_SYMBOL or move
the definition of them to kvm-pr.ko. I did the later and moved only pr
related traces to kvm-pr.ko

>
> If your goal is to make it more obvious whether we are tracing in PR
> or HV land (which is a reasonable goal), then you should also split
> off all non-common trace points into a special hv trace header so that
> it's obvious whether we are looking at HV or PR.

-aneesh

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 06/11] kvm: powerpc: book3s: Add is_hv_enabled to kvmppc_ops

2013-09-27 Thread Aneesh Kumar K.V
Alexander Graf  writes:

> On 27.09.2013, at 12:03, Aneesh Kumar K.V wrote:
>
>> From: "Aneesh Kumar K.V" 
>> 
>> This help us to identify whether we are running with hypervisor mode KVM
>> enabled. The change is needed so that we can have both HV and PR kvm
>> enabled in the same kernel.
>> 
>> If both HV and PR KVM are included, interrupts come in to the HV version
>> of the kvmppc_interrupt code, which then jumps to the PR handler,
>> renamed to kvmppc_interrupt_pr, if the guest is a PR guest.
>> 
>> Allowing both PR and HV in the same kernel required some changes to
>> kvm_dev_ioctl_check_extension(), since the values returned now can't
>> be selected with #ifdefs as much as previously. We look at is_hv_enabled
>> to return the right value when checking for capabilities.For capabilities 
>> that
>> are only provided by HV KVM, we return the HV value only if
>> is_hv_enabled is true. For capabilities provided by PR KVM but not HV,
>> we return the PR value only if is_hv_enabled is false.
>> 
>> Signed-off-by: Aneesh Kumar K.V 
>> ---
>> arch/powerpc/include/asm/kvm_book3s.h   | 53 
>> arch/powerpc/include/asm/kvm_ppc.h  |  5 +--
>> arch/powerpc/kvm/Makefile   |  2 +-
>> arch/powerpc/kvm/book3s.c   | 44 +++
>> arch/powerpc/kvm/book3s_hv.c|  1 +
>> arch/powerpc/kvm/book3s_hv_rmhandlers.S |  4 +++
>> arch/powerpc/kvm/book3s_pr.c|  1 +
>> arch/powerpc/kvm/book3s_segment.S   |  7 -
>> arch/powerpc/kvm/book3s_xics.c  |  2 +-
>> arch/powerpc/kvm/powerpc.c  | 54 
>> ++---
>> 10 files changed, 90 insertions(+), 83 deletions(-)
>> 
>> diff --git a/arch/powerpc/include/asm/kvm_book3s.h 
>> b/arch/powerpc/include/asm/kvm_book3s.h
>> index 3efba3c..ba33c49 100644
>> --- a/arch/powerpc/include/asm/kvm_book3s.h
>> +++ b/arch/powerpc/include/asm/kvm_book3s.h
>> @@ -297,59 +297,6 @@ static inline ulong kvmppc_get_fault_dar(struct 
>> kvm_vcpu *vcpu)
>>  return vcpu->arch.fault_dar;
>> }
>> 
>> -#ifdef CONFIG_KVM_BOOK3S_PR
>> -
>> -static inline unsigned long kvmppc_interrupt_offset(struct kvm_vcpu *vcpu)
>> -{
>> -return to_book3s(vcpu)->hior;
>> -}
>> -
>> -static inline void kvmppc_update_int_pending(struct kvm_vcpu *vcpu,
>> -unsigned long pending_now, unsigned long old_pending)
>> -{
>> -if (pending_now)
>> -vcpu->arch.shared->int_pending = 1;
>> -else if (old_pending)
>> -vcpu->arch.shared->int_pending = 0;
>> -}
>> -
>> -static inline bool kvmppc_critical_section(struct kvm_vcpu *vcpu)
>> -{
>> -ulong crit_raw = vcpu->arch.shared->critical;
>> -ulong crit_r1 = kvmppc_get_gpr(vcpu, 1);
>> -bool crit;
>> -
>> -/* Truncate crit indicators in 32 bit mode */
>> -if (!(vcpu->arch.shared->msr & MSR_SF)) {
>> -crit_raw &= 0x;
>> -crit_r1 &= 0x;
>> -}
>> -
>> -/* Critical section when crit == r1 */
>> -crit = (crit_raw == crit_r1);
>> -/* ... and we're in supervisor mode */
>> -crit = crit && !(vcpu->arch.shared->msr & MSR_PR);
>> -
>> -return crit;
>> -}
>> -#else /* CONFIG_KVM_BOOK3S_PR */
>> -
>> -static inline unsigned long kvmppc_interrupt_offset(struct kvm_vcpu *vcpu)
>> -{
>> -return 0;
>> -}
>> -
>> -static inline void kvmppc_update_int_pending(struct kvm_vcpu *vcpu,
>> -unsigned long pending_now, unsigned long old_pending)
>> -{
>> -}
>> -
>> -static inline bool kvmppc_critical_section(struct kvm_vcpu *vcpu)
>> -{
>> -return false;
>> -}
>> -#endif
>> -
>> /* Magic register values loaded into r3 and r4 before the 'sc' assembly
>>  * instruction for the OSI hypercalls */
>> #define OSI_SC_MAGIC_R3  0x113724FA
>> diff --git a/arch/powerpc/include/asm/kvm_ppc.h 
>> b/arch/powerpc/include/asm/kvm_ppc.h
>> index 4d9641c..58e732f 100644
>> --- a/arch/powerpc/include/asm/kvm_ppc.h
>> +++ b/arch/powerpc/include/asm/kvm_ppc.h
>> @@ -169,6 +169,7 @@ extern int kvmppc_xics_int_on(struct kvm *kvm, u32 irq);
>> extern int kvmppc_xics_int_off(struct kvm *kvm, u32 irq);
>> 
>> struct kvmppc_ops {
>> +bool is_hv_enabled;
>
> This doesn't really belong into an ops struct. Either you compare
>
>   if (kvmppc_ops == kvmppc_ops_pr)

will do that in the next update. 

>
> against a global known good ops struct or you put the hint somewhere into the 
> kvm struct.
>
>>  int (*get_sregs)(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs);
>>  int (*set_sregs)(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs);
>>  int (*get_one_reg)(struct kvm_vcpu *vcpu, u64 id,
>> @@ -309,10 +310,10 @@ static inline void kvmppc_set_xics_phys(int cpu, 
>> unsigned long addr)
>> 
>> static inline u32 kvmppc_get_xics_latch(void)
>> {
>> -u32 xirr = get_paca()->kvm_hstate.saved_xirr;
>> +u32 xirr;
>> 
>> +xirr = get_paca()->kvm_hstate.saved_xirr;
>>  get_paca()->kvm_hstate.saved_x

Re: [RFC PATCH 05/11] kvm: powerpc: book3s: Add kvmppc_ops callback for HV and PR specific operations

2013-09-27 Thread Aneesh Kumar K.V
Alexander Graf  writes:

> On 27.09.2013, at 12:03, Aneesh Kumar K.V wrote:
>
>> From: "Aneesh Kumar K.V" 
>> 
>> This moves HV and PR specific functions to kvmppc_ops callback.
>> This is needed so that we can enable HV and PR together in the
>> same kernel. Actual changes to enable both come in the later
>> patch.This also renames almost all of the symbols that exist in both PR and 
>> HV
>> KVM for clarity. Symbols in the PR KVM implementation get "_pr"
>> appended, and those in the HV KVM implementation get "_hv".  Then,
>> in book3s.c, we add a function with the name without the suffix and
>> arrange for it to call the appropriate kvmppc_ops callback depending on
>> which kvm type we selected during VM creation.
>> 
>> NOTE: we still don't enable selecting both the HV and PR together
>> in this commit that will be done by a later commit.
>> 
>> Signed-off-by: Aneesh Kumar K.V 
>> ---
>> arch/powerpc/include/asm/kvm_book3s.h |   5 +-
>> arch/powerpc/include/asm/kvm_ppc.h|  63 --
>> arch/powerpc/kvm/Kconfig  |  15 ++-
>> arch/powerpc/kvm/Makefile |   9 +-
>> arch/powerpc/kvm/book3s.c | 145 +-
>> arch/powerpc/kvm/book3s_32_mmu_host.c |   2 +-
>> arch/powerpc/kvm/book3s_64_mmu_host.c |   2 +-
>> arch/powerpc/kvm/book3s_64_mmu_hv.c   |  17 ++-
>> arch/powerpc/kvm/book3s_emulate.c |   8 +-
>> arch/powerpc/kvm/book3s_hv.c  | 226 
>> +-
>> arch/powerpc/kvm/book3s_interrupts.S  |   2 +-
>> arch/powerpc/kvm/book3s_pr.c  | 196 ++---
>> arch/powerpc/kvm/emulate.c|   6 +-
>> arch/powerpc/kvm/powerpc.c|  58 +++--
>> 14 files changed, 539 insertions(+), 215 deletions(-)
>> 
>> 
>
> [...]
>
>> @@ -888,14 +890,8 @@ int kvmppc_set_one_reg(struct kvm_vcpu *vcpu, u64 id, 
>> union kvmppc_one_reg *val)
>>  return r;
>> }
>> 
>> -int kvmppc_core_check_processor_compat(void)
>> -{
>> -if (cpu_has_feature(CPU_FTR_HVMODE))
>> -return 0;
>> -return -EIO;
>> -}
>> -
>> -struct kvm_vcpu *kvmppc_core_vcpu_create(struct kvm *kvm, unsigned int id)
>> +static struct kvm_vcpu *kvmppc_core_vcpu_create_hv(struct kvm *kvm,
>> +   unsigned int id)
>> {
>>  struct kvm_vcpu *vcpu;
>>  int err = -EINVAL;
>> @@ -920,7 +916,6 @@ struct kvm_vcpu *kvmppc_core_vcpu_create(struct kvm 
>> *kvm, unsigned int id)
>>  vcpu->arch.ctrl = CTRL_RUNLATCH;
>>  /* default to host PVR, since we can't spoof it */
>>  vcpu->arch.pvr = mfspr(SPRN_PVR);
>> -kvmppc_set_pvr(vcpu, vcpu->arch.pvr);
>
> Where is this one going?

That is same as the line above. 

void kvmppc_set_pvr_hv(struct kvm_vcpu *vcpu, u32 pvr)
{
vcpu->arch.pvr = pvr;
}


>
>>  spin_lock_init(&vcpu->arch.vpa_update_lock);
>>  spin_lock_init(&vcpu->arch.tbacct_lock);
>>  vcpu->arch.busy_preempt = TB_NIL;
>> @@ -972,7 +967,7 @@ static void unpin_vpa(struct kvm *kvm, struct kvmppc_vpa 
>> *vpa)
>>  vpa->dirty);
>> }
>> 
>> -void kvmppc_core_vcpu_free(struct kvm_vcpu *vcpu)
>> +static void kvmppc_core_vcpu_free_hv(struct kvm_vcpu *vcpu)
>> {
>>  spin_lock(&vcpu->arch.vpa_update_lock);
>>  unpin_vpa(vcpu->kvm, &vcpu->arch.dtl);
>> @@ -983,6 +978,12 @@ void kvmppc_core_vcpu_free(struct kvm_vcpu *vcpu)
>>  kmem_cache_free(kvm_vcpu_cache, vcpu);
>> }
>> 
>> +static int kvmppc_core_check_requests_hv(struct kvm_vcpu *vcpu)
>> +{
>> +/* Indicate we want to get back into the guest */
>> +return 1;
>> +}
>> +
>> 
>
> [...]
>
>> +case KVM_PPC_GET_HTAB_FD: {
>> +struct kvm_get_htab_fd ghf;
>> +
>> +r = -EFAULT;
>> +if (copy_from_user(&ghf, argp, sizeof(ghf)))
>> +break;
>> +r = kvm_vm_ioctl_get_htab_fd(kvm, &ghf);
>> +break;
>> +}
>> +
>> +default:
>> +r = -ENOTTY;
>> +}
>> +
>> +return r;
>> }
>> 
>> -static int kvmppc_book3s_hv_init(void)
>> +/* FIXME!! move to header */
>
> Hrm :)

yes, want to get something out for review. Will fix if we agree on the
approach.

>
>> +extern void kvmppc_core_flush_memslot_hv(struct kvm *kvm,
>> + struct kvm_memory_slot *memslot);
>> +extern int kvm_unmap_hva_hv(struct kvm *kvm, unsigned long hva);
>> +extern int kvm_unmap_hva_range_hv(struct kvm *kvm, unsigned long start,
>> +  unsigned long end);
>> +extern int kvm_age_hva_hv(struct kvm *kvm, unsigned long hva);
>> +extern int kvm_test_age_hva_hv(struct kvm *kvm, unsigned long hva);
>> +extern void kvm_set_spte_hva_hv(struct kvm *kvm, unsigned long hva, pte_t 
>> pte);
>> +
>> +static struct kvmppc_ops kvmppc_hv_ops = {
>> +.get_sregs = kvm_arch_vcpu_ioctl_get_sregs_hv,
>> +.set_sregs = kvm_arch_vcpu_ioctl_set_sregs_hv,
>> +.get_one_reg = kvmppc_get_one_reg_hv,
>> +.set_one_reg = kvmppc_set_one_reg_hv

Re: [RFC PATCH 04/11] kvm: powerpc: book3s: Add a new config variable CONFIG_KVM_BOOK3S_HV

2013-09-27 Thread Aneesh Kumar K.V
Alexander Graf  writes:

> On 27.09.2013, at 12:03, Aneesh Kumar K.V wrote:
>
>> From: "Aneesh Kumar K.V" 
>> 
>> This help ups to select the relevant code in the kernel code
>> when we later move HV and PR bits as seperate modules.
>
> I don't think I grasp what semantically the difference between
> CONFIG_KVM_BOOK3S_HV and CONFIG_KVM_BOOK3S_64_HV is :).

When we later enable kvm-hv CONFIG_KVM_BOOK3S_64_HV becomes 'm' So we
can't do #ifdef CONFIG_KVM_BOOK3S_64_HV

-aneesh

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 09/11] kvm: simplify processor compat check

2013-09-27 Thread Alexander Graf

On 27.09.2013, at 12:03, Aneesh Kumar K.V wrote:

> From: "Aneesh Kumar K.V" 

Missing patch description.

> Signed-off-by: Aneesh Kumar K.V 

I fail to see how this really simplifies things, but at the end of the day it's 
Gleb's and Paolo's call.

Which brings me to the next issue: You forgot to CC kvm@vger on your patch set. 
Gleb and Paolo don't read kvm-ppc@vger. And they shouldn't have to. Every kvm 
patch that you want review on or that should get applied needs to be sent to 
kvm@vger. If you want to tag it as PPC specific patch, do so by CC'ing 
kvm-ppc@vger.


Alex

> ---
> arch/arm/kvm/arm.c |  4 ++--
> arch/ia64/kvm/kvm-ia64.c   |  4 ++--
> arch/mips/kvm/kvm_mips.c   |  6 ++
> arch/powerpc/include/asm/kvm_ppc.h |  2 +-
> arch/powerpc/kvm/44x.c |  2 +-
> arch/powerpc/kvm/book3s.c  | 15 ---
> arch/powerpc/kvm/book3s_hv.c   |  9 ++---
> arch/powerpc/kvm/book3s_pr.c   |  5 +++--
> arch/powerpc/kvm/e500.c|  2 +-
> arch/powerpc/kvm/e500mc.c  |  2 +-
> arch/powerpc/kvm/powerpc.c |  5 -
> arch/s390/kvm/kvm-s390.c   |  3 ++-
> arch/x86/kvm/x86.c | 13 +++--
> include/linux/kvm_host.h   |  2 +-
> virt/kvm/kvm_main.c| 14 +-
> 15 files changed, 50 insertions(+), 38 deletions(-)
> 
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index 9c697db..cccb121 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -109,9 +109,9 @@ void kvm_arch_hardware_unsetup(void)
> {
> }
> 
> -void kvm_arch_check_processor_compat(void *rtn)
> +int kvm_arch_check_processor_compat(void *opaque)
> {
> - *(int *)rtn = 0;
> + return 0;
> }
> 
> void kvm_arch_sync_events(struct kvm *kvm)
> diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
> index bdfd878..065942c 100644
> --- a/arch/ia64/kvm/kvm-ia64.c
> +++ b/arch/ia64/kvm/kvm-ia64.c
> @@ -185,9 +185,9 @@ void kvm_arch_hardware_disable(void *garbage)
>   ia64_ptr_entry(0x3, slot);
> }
> 
> -void kvm_arch_check_processor_compat(void *rtn)
> +int kvm_arch_check_processor_compat(void *opaque)
> {
> - *(int *)rtn = 0;
> + return 0;
> }
> 
> int kvm_dev_ioctl_check_extension(long ext)
> diff --git a/arch/mips/kvm/kvm_mips.c b/arch/mips/kvm/kvm_mips.c
> index a7b0445..4512739 100644
> --- a/arch/mips/kvm/kvm_mips.c
> +++ b/arch/mips/kvm/kvm_mips.c
> @@ -97,11 +97,9 @@ void kvm_arch_hardware_unsetup(void)
> {
> }
> 
> -void kvm_arch_check_processor_compat(void *rtn)
> +int kvm_arch_check_processor_compat(void *opaque)
> {
> - int *r = (int *)rtn;
> - *r = 0;
> - return;
> + return 0;
> }
> 
> static void kvm_mips_init_tlbs(struct kvm *kvm)
> diff --git a/arch/powerpc/include/asm/kvm_ppc.h 
> b/arch/powerpc/include/asm/kvm_ppc.h
> index 58e732f..592501b 100644
> --- a/arch/powerpc/include/asm/kvm_ppc.h
> +++ b/arch/powerpc/include/asm/kvm_ppc.h
> @@ -204,7 +204,7 @@ struct kvmppc_ops {
> unsigned long npages);
>   int (*init_vm)(struct kvm *kvm);
>   void (*destroy_vm)(struct kvm *kvm);
> - int (*check_processor_compat)(void);
> + void (*check_processor_compat)(void *r);
>   int (*get_smmu_info)(struct kvm *kvm, struct kvm_ppc_smmu_info *info);
>   int (*emulate_op)(struct kvm_run *run, struct kvm_vcpu *vcpu,
> unsigned int inst, int *advance);
> diff --git a/arch/powerpc/kvm/44x.c b/arch/powerpc/kvm/44x.c
> index 2f5c6b6..a1f4e60 100644
> --- a/arch/powerpc/kvm/44x.c
> +++ b/arch/powerpc/kvm/44x.c
> @@ -43,7 +43,7 @@ void kvmppc_core_vcpu_put(struct kvm_vcpu *vcpu)
>   kvmppc_booke_vcpu_put(vcpu);
> }
> 
> -int kvmppc_core_check_processor_compat(void)
> +int kvm_arch_check_processor_compat(void *opaque)
> {
>   int r;
> 
> diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
> index ca617e1..485a6ff 100644
> --- a/arch/powerpc/kvm/book3s.c
> +++ b/arch/powerpc/kvm/book3s.c
> @@ -827,9 +827,18 @@ void kvmppc_core_destroy_vm(struct kvm *kvm)
> #endif
> }
> 
> -int kvmppc_core_check_processor_compat(void)
> -{
> - return kvmppc_ops->check_processor_compat();
> +int kvm_arch_check_processor_compat(void *opaque)
> +{
> + int r,cpu;
> + struct kvmppc_ops *kvm_ops = (struct kvmppc_ops *)opaque;
> + for_each_online_cpu(cpu) {
> + smp_call_function_single(cpu,
> +  kvm_ops->check_processor_compat,
> +  &r, 1);
> + if (r < 0)
> + break;
> + }
> + return r;
> }
> 
> EXPORT_SYMBOL_GPL(kvm_get_dirty_log);
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index ff57be8..4322db4 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -1980,11 +1980,14 @@ static int kvmppc_core_emulate_mfspr_hv(struct 
> kvm_vcpu *vcpu, int sprn,
>   return EMULATE_FAIL;
> }
> 
> -sta

Re: [RFC PATCH 08/11] kvm: powerpc: book3s: Support building HV and PR KVM as module

2013-09-27 Thread Alexander Graf

On 27.09.2013, at 12:03, Aneesh Kumar K.V wrote:

> From: "Aneesh Kumar K.V" 
> 
> Signed-off-by: Aneesh Kumar K.V 
> ---
> arch/powerpc/kvm/Kconfig  |  6 +++---
> arch/powerpc/kvm/Makefile | 12 
> arch/powerpc/kvm/book3s.c | 19 ++-
> arch/powerpc/kvm/book3s_64_mmu_host.c |  1 +
> arch/powerpc/kvm/book3s_emulate.c |  2 +-
> arch/powerpc/kvm/book3s_hv.c  |  4 
> arch/powerpc/kvm/book3s_pr.c  |  5 -
> arch/powerpc/kvm/book3s_rtas.c|  1 +
> arch/powerpc/kvm/emulate.c|  1 +
> arch/powerpc/kvm/powerpc.c|  6 ++
> virt/kvm/kvm_main.c   |  3 +++
> 11 files changed, 50 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig
> index 5c62459..f63fd8f 100644
> --- a/arch/powerpc/kvm/Kconfig
> +++ b/arch/powerpc/kvm/Kconfig
> @@ -73,7 +73,7 @@ config KVM_BOOK3S_64
> If unsure, say N.
> 
> config KVM_BOOK3S_64_HV
> - bool "KVM support for POWER7 and PPC970 using hypervisor mode in host"
> + tristate "KVM support for POWER7 and PPC970 using hypervisor mode in 
> host"
>   depends on KVM_BOOK3S_64
>   select KVM_BOOK3S_HV
>   select MMU_NOTIFIER
> @@ -94,8 +94,8 @@ config KVM_BOOK3S_64_HV
> If unsure, say N.
> 
> config KVM_BOOK3S_64_PR
> - bool "KVM support without using hypervisor mode in host"
> - depends on KVM_BOOK3S_64 && !KVM_BOOK3S_64_HV
> + tristate "KVM support without using hypervisor mode in host"
> + depends on KVM_BOOK3S_64
>   select KVM_BOOK3S_PR
>   ---help---
> Support running guest kernels in virtual machines on processors
> diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile
> index a514ecd..861b8da 100644
> --- a/arch/powerpc/kvm/Makefile
> +++ b/arch/powerpc/kvm/Makefile
> @@ -56,8 +56,7 @@ kvm-objs-$(CONFIG_KVM_E500MC) := $(kvm-e500mc-objs)
> kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_HANDLER) := \
>   book3s_64_vio_hv.o
> 
> -kvm-book3s_64-objs-$(CONFIG_KVM_BOOK3S_64_PR) := \
> - $(KVM)/coalesced_mmio.o \
> +kvm-pr-y := \
>   fpu.o \
>   book3s_paired_singles.o \
>   book3s_pr.o \
> @@ -77,7 +76,7 @@ kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_HANDLER) 
> += \
>   book3s_rmhandlers.o
> endif
> 
> -kvm-book3s_64-objs-$(CONFIG_KVM_BOOK3S_64_HV)  += \
> +kvm-hv-y += \
>   book3s_hv.o \
>   book3s_hv_interrupts.o \
>   book3s_64_mmu_hv.o
> @@ -85,13 +84,15 @@ kvm-book3s_64-objs-$(CONFIG_KVM_BOOK3S_64_HV)  += \
> kvm-book3s_64-builtin-xics-objs-$(CONFIG_KVM_XICS) := \
>   book3s_hv_rm_xics.o
> 
> -kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_HV) += \
> +ifdef CONFIG_KVM_BOOK3S_HV
> +kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_HANDLER) += \
>   book3s_hv_rmhandlers.o \
>   book3s_hv_rm_mmu.o \
>   book3s_hv_ras.o \
>   book3s_hv_builtin.o \
>   book3s_hv_cma.o \
>   $(kvm-book3s_64-builtin-xics-objs-y)
> +endif
> 
> kvm-book3s_64-objs-$(CONFIG_KVM_XICS) += \
>   book3s_xics.o
> @@ -132,4 +133,7 @@ obj-$(CONFIG_KVM_E500MC) += kvm.o
> obj-$(CONFIG_KVM_BOOK3S_64) += kvm.o
> obj-$(CONFIG_KVM_BOOK3S_32) += kvm.o
> 
> +obj-$(CONFIG_KVM_BOOK3S_64_PR) += kvm-pr.o
> +obj-$(CONFIG_KVM_BOOK3S_64_HV) += kvm-hv.o
> +
> obj-y += $(kvm-book3s_64-builtin-objs-y)
> diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
> index 12f94bf..ca617e1 100644
> --- a/arch/powerpc/kvm/book3s.c
> +++ b/arch/powerpc/kvm/book3s.c
> @@ -170,13 +170,14 @@ void kvmppc_book3s_queue_irqprio(struct kvm_vcpu *vcpu, 
> unsigned int vec)
>   printk(KERN_INFO "Queueing interrupt %x\n", vec);
> #endif
> }
> -
> +EXPORT_SYMBOL_GPL(kvmppc_book3s_queue_irqprio);
> 
> void kvmppc_core_queue_program(struct kvm_vcpu *vcpu, ulong flags)
> {
>   /* might as well deliver this straight away */
>   kvmppc_inject_interrupt(vcpu, BOOK3S_INTERRUPT_PROGRAM, flags);
> }
> +EXPORT_SYMBOL_GPL(kvmppc_core_queue_program);
> 
> void kvmppc_core_queue_dec(struct kvm_vcpu *vcpu)
> {
> @@ -351,6 +352,7 @@ pfn_t kvmppc_gfn_to_pfn(struct kvm_vcpu *vcpu, gfn_t gfn)
> 
>   return gfn_to_pfn(vcpu->kvm, gfn);
> }
> +EXPORT_SYMBOL_GPL(kvmppc_gfn_to_pfn);
> 
> static int kvmppc_xlate(struct kvm_vcpu *vcpu, ulong eaddr, bool data,
>struct kvmppc_pte *pte)
> @@ -418,6 +420,7 @@ int kvmppc_st(struct kvm_vcpu *vcpu, ulong *eaddr, int 
> size, void *ptr,
> 
>   return EMULATE_DONE;
> }
> +EXPORT_SYMBOL_GPL(kvmppc_st);
> 
> int kvmppc_ld(struct kvm_vcpu *vcpu, ulong *eaddr, int size, void *ptr,
> bool data)
> @@ -448,6 +451,7 @@ nopte:
> mmio:
>   return EMULATE_DO_MMIO;
> }
> +EXPORT_SYMBOL_GPL(kvmppc_ld);
> 
> int kvm_arch_vcpu_setup(struct kvm_vcpu *vcpu)
> {
> @@ -693,6 +697,7 @@ void kvmppc_set_msr(struct kvm_vcpu *vcpu, u64 msr)
> {
>   kvmppc_ops->set_msr(vcpu, msr);
> }
> +EXPORT_SYMBOL_GPL(kvmppc_set_msr);
> 
> int kvmppc_vcpu_run(s

Re: [RFC PATCH 07/11] kvm: powerpc: book3s: pr: move PR related tracepoints to a separate header

2013-09-27 Thread Alexander Graf

On 27.09.2013, at 12:03, Aneesh Kumar K.V wrote:

> From: "Aneesh Kumar K.V" 
> 
> This patch moves PR related tracepoints to a separate header. This
> enables in converting PR to a kernel module which will be done in
> later patches
> 
> Signed-off-by: Aneesh Kumar K.V 
> ---
> arch/powerpc/kvm/book3s_64_mmu_host.c |   2 +-
> arch/powerpc/kvm/book3s_mmu_hpte.c|   2 +-
> arch/powerpc/kvm/book3s_pr.c  |   3 +-
> arch/powerpc/kvm/trace.h  | 234 +--
> arch/powerpc/kvm/trace_pr.h   | 297 ++
> 5 files changed, 308 insertions(+), 230 deletions(-)
> create mode 100644 arch/powerpc/kvm/trace_pr.h
> 
> diff --git a/arch/powerpc/kvm/book3s_64_mmu_host.c 
> b/arch/powerpc/kvm/book3s_64_mmu_host.c
> index 329a978..fd5b393 100644
> --- a/arch/powerpc/kvm/book3s_64_mmu_host.c
> +++ b/arch/powerpc/kvm/book3s_64_mmu_host.c
> @@ -27,7 +27,7 @@
> #include 
> #include 
> #include 
> -#include "trace.h"
> +#include "trace_pr.h"
> 
> #define PTE_SIZE 12
> 
> diff --git a/arch/powerpc/kvm/book3s_mmu_hpte.c 
> b/arch/powerpc/kvm/book3s_mmu_hpte.c
> index d2d280b..4556168 100644
> --- a/arch/powerpc/kvm/book3s_mmu_hpte.c
> +++ b/arch/powerpc/kvm/book3s_mmu_hpte.c
> @@ -28,7 +28,7 @@
> #include 
> #include 
> 
> -#include "trace.h"
> +#include "trace_pr.h"
> 
> #define PTE_SIZE  12
> 
> diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
> index 2a97279..99d0839 100644
> --- a/arch/powerpc/kvm/book3s_pr.c
> +++ b/arch/powerpc/kvm/book3s_pr.c
> @@ -41,7 +41,8 @@
> #include 
> #include 
> 
> -#include "trace.h"
> +#define CREATE_TRACE_POINTS
> +#include "trace_pr.h"
> 
> /* #define EXIT_DEBUG */
> /* #define DEBUG_EXT */
> diff --git a/arch/powerpc/kvm/trace.h b/arch/powerpc/kvm/trace.h
> index a088e9a..7d5a136 100644
> --- a/arch/powerpc/kvm/trace.h
> +++ b/arch/powerpc/kvm/trace.h
> @@ -85,6 +85,12 @@ TRACE_EVENT(kvm_ppc_instr,
>   {41, "HV_PRIV"}
> #endif
> 
> +#ifndef CONFIG_KVM_BOOK3S_PR
> +/*
> + * For pr we define this in trace_pr.h since it pr can be built as
> + * a module

Not sure I understand the need. If the config option is available, so should 
the struct field. Worst case that happens with HV is that we get empty 
shadow_srr1 values in our trace, no?

If your goal is to make it more obvious whether we are tracing in PR or HV land 
(which is a reasonable goal), then you should also split off all non-common 
trace points into a special hv trace header so that it's obvious whether we are 
looking at HV or PR.


Alex

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 06/11] kvm: powerpc: book3s: Add is_hv_enabled to kvmppc_ops

2013-09-27 Thread Alexander Graf

On 27.09.2013, at 12:03, Aneesh Kumar K.V wrote:

> From: "Aneesh Kumar K.V" 
> 
> This help us to identify whether we are running with hypervisor mode KVM
> enabled. The change is needed so that we can have both HV and PR kvm
> enabled in the same kernel.
> 
> If both HV and PR KVM are included, interrupts come in to the HV version
> of the kvmppc_interrupt code, which then jumps to the PR handler,
> renamed to kvmppc_interrupt_pr, if the guest is a PR guest.
> 
> Allowing both PR and HV in the same kernel required some changes to
> kvm_dev_ioctl_check_extension(), since the values returned now can't
> be selected with #ifdefs as much as previously. We look at is_hv_enabled
> to return the right value when checking for capabilities.For capabilities that
> are only provided by HV KVM, we return the HV value only if
> is_hv_enabled is true. For capabilities provided by PR KVM but not HV,
> we return the PR value only if is_hv_enabled is false.
> 
> Signed-off-by: Aneesh Kumar K.V 
> ---
> arch/powerpc/include/asm/kvm_book3s.h   | 53 
> arch/powerpc/include/asm/kvm_ppc.h  |  5 +--
> arch/powerpc/kvm/Makefile   |  2 +-
> arch/powerpc/kvm/book3s.c   | 44 +++
> arch/powerpc/kvm/book3s_hv.c|  1 +
> arch/powerpc/kvm/book3s_hv_rmhandlers.S |  4 +++
> arch/powerpc/kvm/book3s_pr.c|  1 +
> arch/powerpc/kvm/book3s_segment.S   |  7 -
> arch/powerpc/kvm/book3s_xics.c  |  2 +-
> arch/powerpc/kvm/powerpc.c  | 54 ++---
> 10 files changed, 90 insertions(+), 83 deletions(-)
> 
> diff --git a/arch/powerpc/include/asm/kvm_book3s.h 
> b/arch/powerpc/include/asm/kvm_book3s.h
> index 3efba3c..ba33c49 100644
> --- a/arch/powerpc/include/asm/kvm_book3s.h
> +++ b/arch/powerpc/include/asm/kvm_book3s.h
> @@ -297,59 +297,6 @@ static inline ulong kvmppc_get_fault_dar(struct kvm_vcpu 
> *vcpu)
>   return vcpu->arch.fault_dar;
> }
> 
> -#ifdef CONFIG_KVM_BOOK3S_PR
> -
> -static inline unsigned long kvmppc_interrupt_offset(struct kvm_vcpu *vcpu)
> -{
> - return to_book3s(vcpu)->hior;
> -}
> -
> -static inline void kvmppc_update_int_pending(struct kvm_vcpu *vcpu,
> - unsigned long pending_now, unsigned long old_pending)
> -{
> - if (pending_now)
> - vcpu->arch.shared->int_pending = 1;
> - else if (old_pending)
> - vcpu->arch.shared->int_pending = 0;
> -}
> -
> -static inline bool kvmppc_critical_section(struct kvm_vcpu *vcpu)
> -{
> - ulong crit_raw = vcpu->arch.shared->critical;
> - ulong crit_r1 = kvmppc_get_gpr(vcpu, 1);
> - bool crit;
> -
> - /* Truncate crit indicators in 32 bit mode */
> - if (!(vcpu->arch.shared->msr & MSR_SF)) {
> - crit_raw &= 0x;
> - crit_r1 &= 0x;
> - }
> -
> - /* Critical section when crit == r1 */
> - crit = (crit_raw == crit_r1);
> - /* ... and we're in supervisor mode */
> - crit = crit && !(vcpu->arch.shared->msr & MSR_PR);
> -
> - return crit;
> -}
> -#else /* CONFIG_KVM_BOOK3S_PR */
> -
> -static inline unsigned long kvmppc_interrupt_offset(struct kvm_vcpu *vcpu)
> -{
> - return 0;
> -}
> -
> -static inline void kvmppc_update_int_pending(struct kvm_vcpu *vcpu,
> - unsigned long pending_now, unsigned long old_pending)
> -{
> -}
> -
> -static inline bool kvmppc_critical_section(struct kvm_vcpu *vcpu)
> -{
> - return false;
> -}
> -#endif
> -
> /* Magic register values loaded into r3 and r4 before the 'sc' assembly
>  * instruction for the OSI hypercalls */
> #define OSI_SC_MAGIC_R3   0x113724FA
> diff --git a/arch/powerpc/include/asm/kvm_ppc.h 
> b/arch/powerpc/include/asm/kvm_ppc.h
> index 4d9641c..58e732f 100644
> --- a/arch/powerpc/include/asm/kvm_ppc.h
> +++ b/arch/powerpc/include/asm/kvm_ppc.h
> @@ -169,6 +169,7 @@ extern int kvmppc_xics_int_on(struct kvm *kvm, u32 irq);
> extern int kvmppc_xics_int_off(struct kvm *kvm, u32 irq);
> 
> struct kvmppc_ops {
> + bool is_hv_enabled;

This doesn't really belong into an ops struct. Either you compare

  if (kvmppc_ops == kvmppc_ops_pr)

against a global known good ops struct or you put the hint somewhere into the 
kvm struct.

>   int (*get_sregs)(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs);
>   int (*set_sregs)(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs);
>   int (*get_one_reg)(struct kvm_vcpu *vcpu, u64 id,
> @@ -309,10 +310,10 @@ static inline void kvmppc_set_xics_phys(int cpu, 
> unsigned long addr)
> 
> static inline u32 kvmppc_get_xics_latch(void)
> {
> - u32 xirr = get_paca()->kvm_hstate.saved_xirr;
> + u32 xirr;
> 
> + xirr = get_paca()->kvm_hstate.saved_xirr;
>   get_paca()->kvm_hstate.saved_xirr = 0;
> -

I don't see any functionality change here?

>   return xirr;
> }
> 
> diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile
> index c343793..

Re: [RFC PATCH 05/11] kvm: powerpc: book3s: Add kvmppc_ops callback for HV and PR specific operations

2013-09-27 Thread Alexander Graf

On 27.09.2013, at 12:03, Aneesh Kumar K.V wrote:

> From: "Aneesh Kumar K.V" 
> 
> This moves HV and PR specific functions to kvmppc_ops callback.
> This is needed so that we can enable HV and PR together in the
> same kernel. Actual changes to enable both come in the later
> patch.This also renames almost all of the symbols that exist in both PR and HV
> KVM for clarity. Symbols in the PR KVM implementation get "_pr"
> appended, and those in the HV KVM implementation get "_hv".  Then,
> in book3s.c, we add a function with the name without the suffix and
> arrange for it to call the appropriate kvmppc_ops callback depending on
> which kvm type we selected during VM creation.
> 
> NOTE: we still don't enable selecting both the HV and PR together
> in this commit that will be done by a later commit.
> 
> Signed-off-by: Aneesh Kumar K.V 
> ---
> arch/powerpc/include/asm/kvm_book3s.h |   5 +-
> arch/powerpc/include/asm/kvm_ppc.h|  63 --
> arch/powerpc/kvm/Kconfig  |  15 ++-
> arch/powerpc/kvm/Makefile |   9 +-
> arch/powerpc/kvm/book3s.c | 145 +-
> arch/powerpc/kvm/book3s_32_mmu_host.c |   2 +-
> arch/powerpc/kvm/book3s_64_mmu_host.c |   2 +-
> arch/powerpc/kvm/book3s_64_mmu_hv.c   |  17 ++-
> arch/powerpc/kvm/book3s_emulate.c |   8 +-
> arch/powerpc/kvm/book3s_hv.c  | 226 +-
> arch/powerpc/kvm/book3s_interrupts.S  |   2 +-
> arch/powerpc/kvm/book3s_pr.c  | 196 ++---
> arch/powerpc/kvm/emulate.c|   6 +-
> arch/powerpc/kvm/powerpc.c|  58 +++--
> 14 files changed, 539 insertions(+), 215 deletions(-)
> 
> 

[...]

> @@ -888,14 +890,8 @@ int kvmppc_set_one_reg(struct kvm_vcpu *vcpu, u64 id, 
> union kvmppc_one_reg *val)
>   return r;
> }
> 
> -int kvmppc_core_check_processor_compat(void)
> -{
> - if (cpu_has_feature(CPU_FTR_HVMODE))
> - return 0;
> - return -EIO;
> -}
> -
> -struct kvm_vcpu *kvmppc_core_vcpu_create(struct kvm *kvm, unsigned int id)
> +static struct kvm_vcpu *kvmppc_core_vcpu_create_hv(struct kvm *kvm,
> +unsigned int id)
> {
>   struct kvm_vcpu *vcpu;
>   int err = -EINVAL;
> @@ -920,7 +916,6 @@ struct kvm_vcpu *kvmppc_core_vcpu_create(struct kvm *kvm, 
> unsigned int id)
>   vcpu->arch.ctrl = CTRL_RUNLATCH;
>   /* default to host PVR, since we can't spoof it */
>   vcpu->arch.pvr = mfspr(SPRN_PVR);
> - kvmppc_set_pvr(vcpu, vcpu->arch.pvr);

Where is this one going?

>   spin_lock_init(&vcpu->arch.vpa_update_lock);
>   spin_lock_init(&vcpu->arch.tbacct_lock);
>   vcpu->arch.busy_preempt = TB_NIL;
> @@ -972,7 +967,7 @@ static void unpin_vpa(struct kvm *kvm, struct kvmppc_vpa 
> *vpa)
>   vpa->dirty);
> }
> 
> -void kvmppc_core_vcpu_free(struct kvm_vcpu *vcpu)
> +static void kvmppc_core_vcpu_free_hv(struct kvm_vcpu *vcpu)
> {
>   spin_lock(&vcpu->arch.vpa_update_lock);
>   unpin_vpa(vcpu->kvm, &vcpu->arch.dtl);
> @@ -983,6 +978,12 @@ void kvmppc_core_vcpu_free(struct kvm_vcpu *vcpu)
>   kmem_cache_free(kvm_vcpu_cache, vcpu);
> }
> 
> +static int kvmppc_core_check_requests_hv(struct kvm_vcpu *vcpu)
> +{
> + /* Indicate we want to get back into the guest */
> + return 1;
> +}
> +
> 

[...]

> + case KVM_PPC_GET_HTAB_FD: {
> + struct kvm_get_htab_fd ghf;
> +
> + r = -EFAULT;
> + if (copy_from_user(&ghf, argp, sizeof(ghf)))
> + break;
> + r = kvm_vm_ioctl_get_htab_fd(kvm, &ghf);
> + break;
> + }
> +
> + default:
> + r = -ENOTTY;
> + }
> +
> + return r;
> }
> 
> -static int kvmppc_book3s_hv_init(void)
> +/* FIXME!! move to header */

Hrm :)

> +extern void kvmppc_core_flush_memslot_hv(struct kvm *kvm,
> +  struct kvm_memory_slot *memslot);
> +extern int kvm_unmap_hva_hv(struct kvm *kvm, unsigned long hva);
> +extern int kvm_unmap_hva_range_hv(struct kvm *kvm, unsigned long start,
> +   unsigned long end);
> +extern int kvm_age_hva_hv(struct kvm *kvm, unsigned long hva);
> +extern int kvm_test_age_hva_hv(struct kvm *kvm, unsigned long hva);
> +extern void kvm_set_spte_hva_hv(struct kvm *kvm, unsigned long hva, pte_t 
> pte);
> +
> +static struct kvmppc_ops kvmppc_hv_ops = {
> + .get_sregs = kvm_arch_vcpu_ioctl_get_sregs_hv,
> + .set_sregs = kvm_arch_vcpu_ioctl_set_sregs_hv,
> + .get_one_reg = kvmppc_get_one_reg_hv,
> + .set_one_reg = kvmppc_set_one_reg_hv,
> + .vcpu_load   = kvmppc_core_vcpu_load_hv,
> + .vcpu_put= kvmppc_core_vcpu_put_hv,
> + .set_msr = kvmppc_set_msr_hv,
> + .vcpu_run= kvmppc_vcpu_run_hv,
> + .vcpu_create = kvmppc_core_vcpu_create_hv,
> + .vcpu_free   = kvmppc_core_vcpu_free_hv,
> + .check_requests = kvmppc_core_check_requests_h

Re: [RFC PATCH 04/11] kvm: powerpc: book3s: Add a new config variable CONFIG_KVM_BOOK3S_HV

2013-09-27 Thread Alexander Graf

On 27.09.2013, at 12:03, Aneesh Kumar K.V wrote:

> From: "Aneesh Kumar K.V" 
> 
> This help ups to select the relevant code in the kernel code
> when we later move HV and PR bits as seperate modules.

I don't think I grasp what semantically the difference between 
CONFIG_KVM_BOOK3S_HV and CONFIG_KVM_BOOK3S_64_HV is :).


Alex

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [RFC PATCH 01/11] kvm: powerpc: book3s hv: Fix vcore leak

2013-09-27 Thread Alexander Graf

On 27.09.2013, at 12:03, Aneesh Kumar K.V wrote:

> From: Paul Mackerras 
> 
> add kvmppc_free_vcores() to free the kvmppc_vcore structures
> that we allocate for a guest, which are currently being leaked.
> 
> Signed-off-by: Paul Mackerras 
> Signed-off-by: Aneesh Kumar K.V 

This one doesn't look like an RFC to me. Applied to kvm-ppc-queue :).


Alex

> ---
> arch/powerpc/kvm/book3s_hv.c | 10 ++
> 1 file changed, 10 insertions(+)
> 
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index 62a2b5a..edc7f9f 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -1931,10 +1931,20 @@ int kvmppc_core_init_vm(struct kvm *kvm)
>   return 0;
> }
> 
> +static void kvmppc_free_vcores(struct kvm *kvm)
> +{
> + long int i;
> +
> + for (i = 0; i < KVM_MAX_VCORES; ++i)
> + kfree(kvm->arch.vcores[i]);
> + kvm->arch.online_vcores = 0;
> +}
> +
> void kvmppc_core_destroy_vm(struct kvm *kvm)
> {
>   uninhibit_secondary_onlining();
> 
> + kvmppc_free_vcores(kvm);
>   if (kvm->arch.rma) {
>   kvm_release_rma(kvm->arch.rma);
>   kvm->arch.rma = NULL;
> -- 
> 1.8.1.2
> 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH V2] powerpc/kernel/sysfs: disable writing to purr in non-powernv

2013-09-27 Thread Madhavan Srinivasan
powerpc/kernel/sysfs.c exports purr with write permission.
This is only valid for kernel in hypervisor mode.
But writing to the file in PowerVM lpar causes crash.

# echo 0 > purr
cpu 0x0: Vector: 700 (Program Check) at [c0d072b0]
pc: c001770c: .write_purr+0x1c/0x40
lr: c0017708: .write_purr+0x18/0x40
sp: c0d07530
   msr: 80049032
  current = 0xc0c53de0
  paca= 0xcec7   softe: 0irq_happened: 0x01
pid   = 0, comm = swapper/0
enter ? for help
[c0d075b0] c00fba64
.generic_smp_call_function_single_interrupt+0x104/0x190
[c0d07650] c0037748 .smp_ipi_demux+0xa8/0xf0
[c0d076e0] c0035314 .doorbell_exception+0x74/0xb0
[c0d07760] c0002950 doorbell_super_common+0x150/0x180
--- Exception: a01 (Doorbell) at c0060904
.plpar_hcall_norets+0x84/0xd4
[link register   ] c006dbd4 .check_and_cede_processor+0x24/0x40
[c0d07a50] c1002558 (unreliable)
[c0d07ac0] c006dd0c .shared_cede_loop+0x2c/0x70
[c0d07b40] c06ae954 .cpuidle_enter_state+0x64/0x150
[c0d07c00] c06aeb30 .cpuidle_idle_call+0xf0/0x300
[c0d07cb0] c0062fa0 .pseries_lpar_idle+0x10/0x50
[c0d07d20] c0016d14 .arch_cpu_idle+0x64/0x150
[c0d07da0] c00e0060 .cpu_startup_entry+0x1a0/0x2c0
[c0d07e80] c000bca4 .rest_init+0x94/0xb0
[c0d07ef0] c0b54530 .start_kernel+0x478/0x494
[c0d07f90] c0009be0 .start_here_common+0x20/0x40
0:mon>

Changes:

1)Changed the test for to hypervisor mode instead of platform

Signed-off-by: Madhavan Srinivasan 
---
 arch/powerpc/kernel/sysfs.c |   20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index 27a90b9..42becfa 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "cacheinfo.h"
 
@@ -179,15 +180,27 @@ SYSFS_PMCSETUP(spurr, SPRN_SPURR);
 SYSFS_PMCSETUP(dscr, SPRN_DSCR);
 SYSFS_PMCSETUP(pir, SPRN_PIR);
 
+/*
+  Lets only enable Read for Hyp resources and
+  enable Write when needed with a separate function.
+  Lets be conservative and default to pseries.
+*/
 static DEVICE_ATTR(mmcra, 0600, show_mmcra, store_mmcra);
 static DEVICE_ATTR(spurr, 0400, show_spurr, NULL);
 static DEVICE_ATTR(dscr, 0600, show_dscr, store_dscr);
-static DEVICE_ATTR(purr, 0600, show_purr, store_purr);
+static DEVICE_ATTR(purr, 0400, show_purr, store_purr);
 static DEVICE_ATTR(pir, 0400, show_pir, NULL);
 
 unsigned long dscr_default = 0;
 EXPORT_SYMBOL(dscr_default);
 
+static void add_write_permission_dev_attr(void *ptr)
+{
+   struct device_attribute *attr = (struct device_attribute *)ptr;
+
+   attr->attr.mode |= (unsigned short) 0200;
+}
+
 static ssize_t show_dscr_default(struct device *dev,
struct device_attribute *attr, char *buf)
 {
@@ -394,8 +407,11 @@ static void register_cpu_online(unsigned int cpu)
if (cpu_has_feature(CPU_FTR_MMCRA))
device_create_file(s, &dev_attr_mmcra);
 
-   if (cpu_has_feature(CPU_FTR_PURR))
+   if (cpu_has_feature(CPU_FTR_PURR)) {
+   if (mfmsr() & MSR_HV)
+   add_write_permission_dev_attr((void *)&dev_attr_purr);
device_create_file(s, &dev_attr_purr);
+   }
 
if (cpu_has_feature(CPU_FTR_SPURR))
device_create_file(s, &dev_attr_spurr);
-- 
1.7.10.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 2/2] pci: fsl: rework PCI driver compatible with Layerscape

2013-09-27 Thread Lian Minghuan-b31939

Hi All,

Can anyone comment on my code or help to pick up?

Thanks,
Minghuan


On 09/18/2013 07:02 PM, Minghuan Lian wrote:

The Freescale's Layerscape series processors will use the same PCI
controller but change cores from PowerPC to ARM. This patch is to
rework FSL PCI driver to support PowerPC and ARM simultaneously.
PowerPC uses structure pci_controller to describe PCI controller,
but arm uses structure hw_pci and pci_sys_data. They also have
different architecture implementation and initialization flow.
The architecture-dependent driver will bridge the gap, get the
settings from the common driver and initialize the corresponding
structure and call the related interface to register PCI controller.
The common driver pci-fsl.c removes all the architecture-specific
code and provides structure fsl_pci to store all the controller
settings and the common functionalities that include reading/writing
PCI configuration space, parsing dts node and getting the MEM/IO and
bus number ranges, setting ATMU and check link status.

Signed-off-by: Minghuan Lian 
---
Based on upstream master
Based on the discussion of RFC version here
http://patchwork.ozlabs.org/patch/274488/
The function has been tested on MPC8315ERDB MPC8572DS P5020DS P3041DS
and T4240QDS boards

  arch/powerpc/Kconfig  |   1 +
  arch/powerpc/sysdev/fsl_pci.c | 147 +-
  drivers/edac/mpc85xx_edac.c   |  16 +-
  drivers/pci/host/Kconfig  |   7 +
  drivers/pci/host/Makefile |   1 +
  drivers/pci/host/pci-fsl.c| 653 +++---
  include/linux/fsl/pci.h   |  69 +
  7 files changed, 653 insertions(+), 241 deletions(-)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 38f3b7e..6fd6348 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -690,6 +690,7 @@ config FSL_SOC
  
  config FSL_PCI

bool
+   select PCI_FSL if FSL_SOC_BOOKE || PPC_86xx
select PPC_INDIRECT_PCI
select PCI_QUIRKS
  
diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c

index a189ff0..1413257 100644
--- a/arch/powerpc/sysdev/fsl_pci.c
+++ b/arch/powerpc/sysdev/fsl_pci.c
@@ -62,7 +62,11 @@ static void quirk_fsl_pcie_header(struct pci_dev *dev)
  #if defined(CONFIG_FSL_SOC_BOOKE) || defined(CONFIG_PPC_86xx)
  
  #define MAX_PHYS_ADDR_BITS	40

-static u64 pci64_dma_offset = 1ull << MAX_PHYS_ADDR_BITS;
+
+u64 fsl_arch_pci64_dma_offset(void)
+{
+   return 1ull << MAX_PHYS_ADDR_BITS;
+}
  
  static int fsl_pci_dma_set_mask(struct device *dev, u64 dma_mask)

  {
@@ -77,17 +81,43 @@ static int fsl_pci_dma_set_mask(struct device *dev, u64 
dma_mask)
if ((dev->bus == &pci_bus_type) &&
dma_mask >= DMA_BIT_MASK(MAX_PHYS_ADDR_BITS)) {
set_dma_ops(dev, &dma_direct_ops);
-   set_dma_offset(dev, pci64_dma_offset);
+   set_dma_offset(dev, fsl_arch_pci64_dma_offset());
}
  
  	*dev->dma_mask = dma_mask;

return 0;
  }
  
+struct fsl_pci *fsl_arch_sys_to_pci(void *sys)

+{
+   struct pci_controller *hose = sys;
+   struct fsl_pci *pci = hose->private_data;
+
+   /* Update the first bus number */
+   if (pci->first_busno != hose->first_busno)
+   pci->first_busno = hose->first_busno;
+
+   return pci;
+}
+
+struct pci_bus *fsl_arch_fake_pci_bus(struct fsl_pci *pci, int busnr)
+{
+   static struct pci_bus bus;
+   static struct pci_controller hose;
+
+   bus.number = busnr;
+   bus.sysdata = &hose;
+   hose.private_data = pci;
+   bus.ops = pci->ops;
+
+   return &bus;
+}
+
  void fsl_pcibios_fixup_bus(struct pci_bus *bus)
  {
struct pci_controller *hose = pci_bus_to_host(bus);
-   int i, is_pcie = 0, no_link;
+   int i, is_pcie, no_link;
+   struct fsl_pci *pci = fsl_arch_sys_to_pci(hose);
  
  	/* The root complex bridge comes up with bogus resources,

 * we copy the PHB ones in.
@@ -97,9 +127,8 @@ void fsl_pcibios_fixup_bus(struct pci_bus *bus)
 * tricky.
 */
  
-	if (fsl_pcie_bus_fixup)

-   is_pcie = early_find_capability(hose, 0, 0, PCI_CAP_ID_EXP);
-   no_link = !!(hose->indirect_type & PPC_INDIRECT_TYPE_NO_PCIE_LINK);
+   is_pcie = pci->is_pcie;
+   no_link = fsl_pci_check_link(pci);
  
  	if (bus->parent == hose->bus && (is_pcie || no_link)) {

for (i = 0; i < PCI_BRIDGE_RESOURCE_NUM; ++i) {
@@ -121,6 +150,94 @@ void fsl_pcibios_fixup_bus(struct pci_bus *bus)
}
  }
  
+int fsl_arch_pci_exclude_device(struct fsl_pci *pci, u8 bus, u8 devfn)

+{
+   struct pci_controller *hose = pci->sys;
+
+   if (!hose)
+   return PCIBIOS_SUCCESSFUL;
+
+   if (ppc_md.pci_exclude_device)
+   if (ppc_md.pci_exclude_device(hose, bus, devfn))
+   return PCIBIOS_DEVICE_NOT_FOUND;
+
+   return PCIBIOS_SUCCESSFUL;
+}
+
+int fsl_arch_pci_sys_register(struct fsl_pci *pci)
+{
+   struct pci_control

Re: [RFC PATCH 00/11 Allow PR and HV KVM to coexist in one kernel

2013-09-27 Thread Aneesh Kumar K.V
"Aneesh Kumar K.V"  writes:

> Hi All,
>
> This patch series support enabling HV and PR KVM together in the same kernel. 
> We
> extend machine property with new property "kvm_type". A value of 1 will force 
> HV
> KVM and 2 PR KVM. The default value is 0 which will select the fastest KVM 
> mode.
> ie, HV if that is supported otherwise PR.
>
> With Qemu command line having
>
>  -machine pseries,accel=kvm,kvm_type=1
>
> [root@llmp24l02 qemu]# bash ../qemu
> failed to initialize KVM: Invalid argument
> [root@llmp24l02 qemu]# modprobe kvm-pr
> [root@llmp24l02 qemu]# bash ../qemu
> failed to initialize KVM: Invalid argument
> [root@llmp24l02 qemu]# modprobe  kvm-hv
> [root@llmp24l02 qemu]# bash ../qemu
>
> now with
>
>  -machine pseries,accel=kvm,kvm_type=2
>
> [root@llmp24l02 qemu]# rmmod kvm-pr
> [root@llmp24l02 qemu]# bash ../qemu
> failed to initialize KVM: Invalid argument
> [root@llmp24l02 qemu]#
> [root@llmp24l02 qemu]# modprobe kvm-pr
> [root@llmp24l02 qemu]# bash ../qemu
>
> if don't specify kvm_type machine property, it will take a default value 0,
> which means fastest supported.

Related qemu patch

commit 8d139053177d48a70cb710b211ea4c2843eccdfb
Author: Aneesh Kumar K.V 
Date:   Mon Sep 23 12:28:37 2013 +0530

kvm: Add a new machine property kvm_type

Targets like ppc64 support different type of KVM, one which use
hypervisor mode and the other which doesn't. Add a new machine
property kvm_type that helps in selecting the respective ones

Signed-off-by: Aneesh Kumar K.V 

diff --git a/kvm-all.c b/kvm-all.c
index b87215c..a061eda 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -1350,7 +1350,7 @@ int kvm_init(void)
 KVMState *s;
 const KVMCapabilityInfo *missing_cap;
 int ret;
-int i;
+int i, kvm_type;
 int max_vcpus;
 
 s = g_malloc0(sizeof(KVMState));
@@ -1407,7 +1407,8 @@ int kvm_init(void)
 goto err;
 }
 
-s->vmfd = kvm_ioctl(s, KVM_CREATE_VM, 0);
+kvm_type = qemu_opt_get_number(qemu_get_machine_opts(), "kvm_type", 0);
+s->vmfd = kvm_ioctl(s, KVM_CREATE_VM, kvm_type);
 if (s->vmfd < 0) {
 #ifdef TARGET_S390X
 fprintf(stderr, "Please add the 'switch_amode' kernel parameter to "
diff --git a/vl.c b/vl.c
index 4e709d5..4374b17 100644
--- a/vl.c
+++ b/vl.c
@@ -427,7 +427,12 @@ static QemuOptsList qemu_machine_opts = {
 .name = "usb",
 .type = QEMU_OPT_BOOL,
 .help = "Set on/off to enable/disable usb",
+},{
+.name = "kvm_type",
+.type = QEMU_OPT_NUMBER,
+.help = "Set to kvm type to be used in create vm ioctl",
 },
+
 { /* End of list */ }
 },
 };

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH 2/2] powerpc: Free up _PAGE_COHERENCE for numa fault use later

2013-09-27 Thread Aneesh Kumar K.V
From: "Aneesh Kumar K.V" 

only hash 64 config we always set memory coherence, If
a platform cannot have memory coherence always set they
can infer that from _PAGE_NO_CACHE and _PAGE_WRITETHRU
like in lpar. So we dont' really need a separate bit
for tracking _PAGE_COHERENCE.

Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/include/asm/pte-hash64.h |  2 +-
 arch/powerpc/mm/hash_low_64.S | 15 ---
 arch/powerpc/mm/hugepage-hash64.c |  6 +-
 arch/powerpc/mm/hugetlbpage-hash64.c  |  4 
 4 files changed, 22 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/include/asm/pte-hash64.h 
b/arch/powerpc/include/asm/pte-hash64.h
index 0419eeb..55aea0c 100644
--- a/arch/powerpc/include/asm/pte-hash64.h
+++ b/arch/powerpc/include/asm/pte-hash64.h
@@ -19,7 +19,7 @@
 #define _PAGE_FILE 0x0002 /* (!present only) software: pte holds 
file offset */
 #define _PAGE_EXEC 0x0004 /* No execute on POWER4 and newer (we 
invert) */
 #define _PAGE_GUARDED  0x0008
-#define _PAGE_COHERENT 0x0010 /* M: enforce memory coherence (SMP 
systems) */
+/* We can derive Memory coherence from _PAGE_NO_CACHE */
 #define _PAGE_NO_CACHE 0x0020 /* I: cache inhibit */
 #define _PAGE_WRITETHRU0x0040 /* W: cache write-through */
 #define _PAGE_DIRTY0x0080 /* C: page changed */
diff --git a/arch/powerpc/mm/hash_low_64.S b/arch/powerpc/mm/hash_low_64.S
index d3cbda6..1136d26 100644
--- a/arch/powerpc/mm/hash_low_64.S
+++ b/arch/powerpc/mm/hash_low_64.S
@@ -148,7 +148,10 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_1T_SEGMENT)
and r0,r0,r4/* _PAGE_RW & _PAGE_DIRTY ->r0 bit 30*/
andcr0,r30,r0   /* r0 = pte & ~r0 */
rlwimi  r3,r0,32-1,31,31/* Insert result into PP lsb */
-   ori r3,r3,HPTE_R_C  /* Always add "C" bit for perf. */
+   /*
+* Always add "C" bit for perf. Memory coherence is always enabled
+*/
+   ori r3,r3,HPTE_R_C | HPTE_R_M
 
/* We eventually do the icache sync here (maybe inline that
 * code rather than call a C function...) 
@@ -457,7 +460,10 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_1T_SEGMENT)
and r0,r0,r4/* _PAGE_RW & _PAGE_DIRTY ->r0 bit 30*/
andcr0,r3,r0/* r0 = pte & ~r0 */
rlwimi  r3,r0,32-1,31,31/* Insert result into PP lsb */
-   ori r3,r3,HPTE_R_C  /* Always add "C" bit for perf. */
+   /*
+* Always add "C" bit for perf. Memory coherence is always enabled
+*/
+   ori r3,r3,HPTE_R_C | HPTE_R_M
 
/* We eventually do the icache sync here (maybe inline that
 * code rather than call a C function...)
@@ -795,7 +801,10 @@ END_MMU_FTR_SECTION_IFSET(MMU_FTR_1T_SEGMENT)
and r0,r0,r4/* _PAGE_RW & _PAGE_DIRTY ->r0 bit 30*/
andcr0,r30,r0   /* r0 = pte & ~r0 */
rlwimi  r3,r0,32-1,31,31/* Insert result into PP lsb */
-   ori r3,r3,HPTE_R_C  /* Always add "C" bit for perf. */
+   /*
+* Always add "C" bit for perf. Memory coherence is always enabled
+*/
+   ori r3,r3,HPTE_R_C | HPTE_R_M
 
/* We eventually do the icache sync here (maybe inline that
 * code rather than call a C function...)
diff --git a/arch/powerpc/mm/hugepage-hash64.c 
b/arch/powerpc/mm/hugepage-hash64.c
index 34de9e0..b640595 100644
--- a/arch/powerpc/mm/hugepage-hash64.c
+++ b/arch/powerpc/mm/hugepage-hash64.c
@@ -127,7 +127,11 @@ repeat:
 
/* Add in WIMG bits */
rflags |= (new_pmd & (_PAGE_WRITETHRU | _PAGE_NO_CACHE |
- _PAGE_COHERENT | _PAGE_GUARDED));
+ _PAGE_GUARDED));
+   /*
+* enable the memory coherence always
+*/
+   rflgs |= HPTE_R_M;
 
/* Insert into the hash table, primary slot */
slot = ppc_md.hpte_insert(hpte_group, vpn, pa, rflags, 0,
diff --git a/arch/powerpc/mm/hugetlbpage-hash64.c 
b/arch/powerpc/mm/hugetlbpage-hash64.c
index 0b7fb67..a5bcf93 100644
--- a/arch/powerpc/mm/hugetlbpage-hash64.c
+++ b/arch/powerpc/mm/hugetlbpage-hash64.c
@@ -99,6 +99,10 @@ int __hash_page_huge(unsigned long ea, unsigned long access, 
unsigned long vsid,
/* Add in WIMG bits */
rflags |= (new_pte & (_PAGE_WRITETHRU | _PAGE_NO_CACHE |
  _PAGE_COHERENT | _PAGE_GUARDED));
+   /*
+* enable the memory coherence always
+*/
+   rflags |= HPTE_R_M;
 
slot = hpte_insert_repeating(hash, vpn, pa, rflags, 0,
 mmu_psize, ssize);
-- 
1.8.1.2

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
htt

[PATCH 1/2] powerpc: Use HPTE constants when updating hpte bits

2013-09-27 Thread Aneesh Kumar K.V
From: "Aneesh Kumar K.V" 

Even though we have same value for linux PTE bits and hash PTE pits
use the hash pte bits wen updating hash pte

Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/platforms/cell/beat_htab.c | 4 ++--
 arch/powerpc/platforms/pseries/lpar.c   | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/platforms/cell/beat_htab.c 
b/arch/powerpc/platforms/cell/beat_htab.c
index c34ee4e..d4d245c 100644
--- a/arch/powerpc/platforms/cell/beat_htab.c
+++ b/arch/powerpc/platforms/cell/beat_htab.c
@@ -111,7 +111,7 @@ static long beat_lpar_hpte_insert(unsigned long hpte_group,
DBG_LOW(" hpte_v=%016lx, hpte_r=%016lx\n", hpte_v, hpte_r);
 
if (rflags & _PAGE_NO_CACHE)
-   hpte_r &= ~_PAGE_COHERENT;
+   hpte_r &= ~HPTE_R_M;
 
raw_spin_lock(&beat_htab_lock);
lpar_rc = beat_read_mask(hpte_group);
@@ -337,7 +337,7 @@ static long beat_lpar_hpte_insert_v3(unsigned long 
hpte_group,
DBG_LOW(" hpte_v=%016lx, hpte_r=%016lx\n", hpte_v, hpte_r);
 
if (rflags & _PAGE_NO_CACHE)
-   hpte_r &= ~_PAGE_COHERENT;
+   hpte_r &= ~HPTE_R_M;
 
/* insert into not-volted entry */
lpar_rc = beat_insert_htab_entry3(0, hpte_group, hpte_v, hpte_r,
diff --git a/arch/powerpc/platforms/pseries/lpar.c 
b/arch/powerpc/platforms/pseries/lpar.c
index 356bc75..450fca2 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -153,7 +153,7 @@ static long pSeries_lpar_hpte_insert(unsigned long 
hpte_group,
 
/* Make pHyp happy */
if ((rflags & _PAGE_NO_CACHE) && !(rflags & _PAGE_WRITETHRU))
-   hpte_r &= ~_PAGE_COHERENT;
+   hpte_r &= ~HPTE_R_M;
if (firmware_has_feature(FW_FEATURE_XCMO) && !(hpte_r & HPTE_R_N))
flags |= H_COALESCE_CAND;
 
-- 
1.8.1.2

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[RFC PATCH 03/11] kvm: powerpc: book3s: move book3s_64_vio_hv.c into the main kernel binary

2013-09-27 Thread Aneesh Kumar K.V
From: Paul Mackerras 

Since the code in book3s_64_vio_hv.c is called from real mode with HV
KVM, and therefore has to be built into the main kernel binary, this
makes it always built-in rather than part of the KVM module.  It gets
called from the KVM module by PR KVM, so this adds an EXPORT_SYMBOL_GPL().

Signed-off-by: Paul Mackerras 
Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/kvm/Makefile   | 12 
 arch/powerpc/kvm/book3s_64_vio_hv.c |  2 ++
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile
index 6646c95..104e8dc 100644
--- a/arch/powerpc/kvm/Makefile
+++ b/arch/powerpc/kvm/Makefile
@@ -53,32 +53,36 @@ kvm-e500mc-objs := \
e500_emulate.o
 kvm-objs-$(CONFIG_KVM_E500MC) := $(kvm-e500mc-objs)
 
+kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_HANDLER) := \
+   book3s_64_vio_hv.o
+
 kvm-book3s_64-objs-$(CONFIG_KVM_BOOK3S_64_PR) := \
$(KVM)/coalesced_mmio.o \
fpu.o \
book3s_paired_singles.o \
book3s_pr.o \
book3s_pr_papr.o \
-   book3s_64_vio_hv.o \
book3s_emulate.o \
book3s_interrupts.o \
book3s_mmu_hpte.o \
book3s_64_mmu_host.o \
book3s_64_mmu.o \
book3s_32_mmu.o
-kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_PR) := \
+
+kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_PR) += \
book3s_rmhandlers.o
 
 kvm-book3s_64-objs-$(CONFIG_KVM_BOOK3S_64_HV) := \
book3s_hv.o \
book3s_hv_interrupts.o \
book3s_64_mmu_hv.o
+
 kvm-book3s_64-builtin-xics-objs-$(CONFIG_KVM_XICS) := \
book3s_hv_rm_xics.o
-kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_HV) := \
+
+kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_HV) += \
book3s_hv_rmhandlers.o \
book3s_hv_rm_mmu.o \
-   book3s_64_vio_hv.o \
book3s_hv_ras.o \
book3s_hv_builtin.o \
book3s_hv_cma.o \
diff --git a/arch/powerpc/kvm/book3s_64_vio_hv.c 
b/arch/powerpc/kvm/book3s_64_vio_hv.c
index 30c2f3b..70d6594 100644
--- a/arch/powerpc/kvm/book3s_64_vio_hv.c
+++ b/arch/powerpc/kvm/book3s_64_vio_hv.c
@@ -74,3 +74,5 @@ long kvmppc_h_put_tce(struct kvm_vcpu *vcpu, unsigned long 
liobn,
/* Didn't find the liobn, punt it to userspace */
return H_TOO_HARD;
 }
+EXPORT_SYMBOL_GPL(kvmppc_h_put_tce);
+
-- 
1.8.1.2

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[RFC PATCH 05/11] kvm: powerpc: book3s: Add kvmppc_ops callback for HV and PR specific operations

2013-09-27 Thread Aneesh Kumar K.V
From: "Aneesh Kumar K.V" 

This moves HV and PR specific functions to kvmppc_ops callback.
This is needed so that we can enable HV and PR together in the
same kernel. Actual changes to enable both come in the later
patch.This also renames almost all of the symbols that exist in both PR and HV
KVM for clarity. Symbols in the PR KVM implementation get "_pr"
appended, and those in the HV KVM implementation get "_hv".  Then,
in book3s.c, we add a function with the name without the suffix and
arrange for it to call the appropriate kvmppc_ops callback depending on
which kvm type we selected during VM creation.

NOTE: we still don't enable selecting both the HV and PR together
in this commit that will be done by a later commit.

Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/include/asm/kvm_book3s.h |   5 +-
 arch/powerpc/include/asm/kvm_ppc.h|  63 --
 arch/powerpc/kvm/Kconfig  |  15 ++-
 arch/powerpc/kvm/Makefile |   9 +-
 arch/powerpc/kvm/book3s.c | 145 +-
 arch/powerpc/kvm/book3s_32_mmu_host.c |   2 +-
 arch/powerpc/kvm/book3s_64_mmu_host.c |   2 +-
 arch/powerpc/kvm/book3s_64_mmu_hv.c   |  17 ++-
 arch/powerpc/kvm/book3s_emulate.c |   8 +-
 arch/powerpc/kvm/book3s_hv.c  | 226 +-
 arch/powerpc/kvm/book3s_interrupts.S  |   2 +-
 arch/powerpc/kvm/book3s_pr.c  | 196 ++---
 arch/powerpc/kvm/emulate.c|   6 +-
 arch/powerpc/kvm/powerpc.c|  58 +++--
 14 files changed, 539 insertions(+), 215 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm_book3s.h 
b/arch/powerpc/include/asm/kvm_book3s.h
index 1b32f6c..3efba3c 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -24,6 +24,8 @@
 #include 
 #include 
 
+union kvmppc_one_reg;
+
 struct kvmppc_bat {
u64 raw;
u32 bepi;
@@ -124,7 +126,6 @@ extern void kvmppc_mmu_pte_flush(struct kvm_vcpu *vcpu, 
ulong ea, ulong ea_mask)
 extern void kvmppc_mmu_pte_vflush(struct kvm_vcpu *vcpu, u64 vp, u64 vp_mask);
 extern void kvmppc_mmu_pte_pflush(struct kvm_vcpu *vcpu, ulong pa_start, ulong 
pa_end);
 extern void kvmppc_set_msr(struct kvm_vcpu *vcpu, u64 new_msr);
-extern void kvmppc_set_pvr(struct kvm_vcpu *vcpu, u32 pvr);
 extern void kvmppc_mmu_book3s_64_init(struct kvm_vcpu *vcpu);
 extern void kvmppc_mmu_book3s_32_init(struct kvm_vcpu *vcpu);
 extern void kvmppc_mmu_book3s_hv_init(struct kvm_vcpu *vcpu);
@@ -193,8 +194,6 @@ static inline struct kvmppc_vcpu_book3s *to_book3s(struct 
kvm_vcpu *vcpu)
return vcpu->arch.book3s;
 }
 
-extern void kvm_return_point(void);
-
 /* Also add subarch specific defines */
 
 #ifdef CONFIG_KVM_BOOK3S_32_HANDLER
diff --git a/arch/powerpc/include/asm/kvm_ppc.h 
b/arch/powerpc/include/asm/kvm_ppc.h
index 9161bd1..4d9641c 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -106,13 +106,6 @@ extern void kvmppc_core_queue_external(struct kvm_vcpu 
*vcpu,
struct kvm_interrupt *irq);
 extern void kvmppc_core_dequeue_external(struct kvm_vcpu *vcpu);
 extern void kvmppc_core_flush_tlb(struct kvm_vcpu *vcpu);
-
-extern int kvmppc_core_emulate_op(struct kvm_run *run, struct kvm_vcpu *vcpu,
-  unsigned int op, int *advance);
-extern int kvmppc_core_emulate_mtspr(struct kvm_vcpu *vcpu, int sprn,
-ulong val);
-extern int kvmppc_core_emulate_mfspr(struct kvm_vcpu *vcpu, int sprn,
-ulong *val);
 extern int kvmppc_core_check_requests(struct kvm_vcpu *vcpu);
 
 extern int kvmppc_booke_init(void);
@@ -135,8 +128,6 @@ extern long kvm_vm_ioctl_create_spapr_tce(struct kvm *kvm,
struct kvm_create_spapr_tce *args);
 extern long kvmppc_h_put_tce(struct kvm_vcpu *vcpu, unsigned long liobn,
 unsigned long ioba, unsigned long tce);
-extern long kvm_vm_ioctl_allocate_rma(struct kvm *kvm,
-   struct kvm_allocate_rma *rma);
 extern struct kvm_rma_info *kvm_alloc_rma(void);
 extern void kvm_release_rma(struct kvm_rma_info *ri);
 extern struct page *kvm_alloc_hpt(unsigned long nr_pages);
@@ -177,6 +168,55 @@ extern int kvmppc_xics_get_xive(struct kvm *kvm, u32 irq, 
u32 *server,
 extern int kvmppc_xics_int_on(struct kvm *kvm, u32 irq);
 extern int kvmppc_xics_int_off(struct kvm *kvm, u32 irq);
 
+struct kvmppc_ops {
+   int (*get_sregs)(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs);
+   int (*set_sregs)(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs);
+   int (*get_one_reg)(struct kvm_vcpu *vcpu, u64 id,
+  union kvmppc_one_reg *val);
+   int (*set_one_reg)(struct kvm_vcpu *vcpu, u64 id,
+  union kvmppc_one_reg *val);
+   void (*vcpu_load)(struct kvm_vcpu *vcpu, int cpu);
+   void (*vcpu_put)(st

[RFC PATCH 07/11] kvm: powerpc: book3s: pr: move PR related tracepoints to a separate header

2013-09-27 Thread Aneesh Kumar K.V
From: "Aneesh Kumar K.V" 

This patch moves PR related tracepoints to a separate header. This
enables in converting PR to a kernel module which will be done in
later patches

Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/kvm/book3s_64_mmu_host.c |   2 +-
 arch/powerpc/kvm/book3s_mmu_hpte.c|   2 +-
 arch/powerpc/kvm/book3s_pr.c  |   3 +-
 arch/powerpc/kvm/trace.h  | 234 +--
 arch/powerpc/kvm/trace_pr.h   | 297 ++
 5 files changed, 308 insertions(+), 230 deletions(-)
 create mode 100644 arch/powerpc/kvm/trace_pr.h

diff --git a/arch/powerpc/kvm/book3s_64_mmu_host.c 
b/arch/powerpc/kvm/book3s_64_mmu_host.c
index 329a978..fd5b393 100644
--- a/arch/powerpc/kvm/book3s_64_mmu_host.c
+++ b/arch/powerpc/kvm/book3s_64_mmu_host.c
@@ -27,7 +27,7 @@
 #include 
 #include 
 #include 
-#include "trace.h"
+#include "trace_pr.h"
 
 #define PTE_SIZE 12
 
diff --git a/arch/powerpc/kvm/book3s_mmu_hpte.c 
b/arch/powerpc/kvm/book3s_mmu_hpte.c
index d2d280b..4556168 100644
--- a/arch/powerpc/kvm/book3s_mmu_hpte.c
+++ b/arch/powerpc/kvm/book3s_mmu_hpte.c
@@ -28,7 +28,7 @@
 #include 
 #include 
 
-#include "trace.h"
+#include "trace_pr.h"
 
 #define PTE_SIZE   12
 
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index 2a97279..99d0839 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -41,7 +41,8 @@
 #include 
 #include 
 
-#include "trace.h"
+#define CREATE_TRACE_POINTS
+#include "trace_pr.h"
 
 /* #define EXIT_DEBUG */
 /* #define DEBUG_EXT */
diff --git a/arch/powerpc/kvm/trace.h b/arch/powerpc/kvm/trace.h
index a088e9a..7d5a136 100644
--- a/arch/powerpc/kvm/trace.h
+++ b/arch/powerpc/kvm/trace.h
@@ -85,6 +85,12 @@ TRACE_EVENT(kvm_ppc_instr,
{41, "HV_PRIV"}
 #endif
 
+#ifndef CONFIG_KVM_BOOK3S_PR
+/*
+ * For pr we define this in trace_pr.h since it pr can be built as
+ * a module
+ */
+
 TRACE_EVENT(kvm_exit,
TP_PROTO(unsigned int exit_nr, struct kvm_vcpu *vcpu),
TP_ARGS(exit_nr, vcpu),
@@ -94,9 +100,6 @@ TRACE_EVENT(kvm_exit,
__field(unsigned long,  pc  )
__field(unsigned long,  msr )
__field(unsigned long,  dar )
-#ifdef CONFIG_KVM_BOOK3S_PR
-   __field(unsigned long,  srr1)
-#endif
__field(unsigned long,  last_inst   )
),
 
@@ -105,9 +108,6 @@ TRACE_EVENT(kvm_exit,
__entry->pc = kvmppc_get_pc(vcpu);
__entry->dar= kvmppc_get_fault_dar(vcpu);
__entry->msr= vcpu->arch.shared->msr;
-#ifdef CONFIG_KVM_BOOK3S_PR
-   __entry->srr1   = vcpu->arch.shadow_srr1;
-#endif
__entry->last_inst  = vcpu->arch.last_inst;
),
 
@@ -115,18 +115,12 @@ TRACE_EVENT(kvm_exit,
" | pc=0x%lx"
" | msr=0x%lx"
" | dar=0x%lx"
-#ifdef CONFIG_KVM_BOOK3S_PR
-   " | srr1=0x%lx"
-#endif
" | last_inst=0x%lx"
,
__print_symbolic(__entry->exit_nr, kvm_trace_symbol_exit),
__entry->pc,
__entry->msr,
__entry->dar,
-#ifdef CONFIG_KVM_BOOK3S_PR
-   __entry->srr1,
-#endif
__entry->last_inst
)
 );
@@ -145,6 +139,7 @@ TRACE_EVENT(kvm_unmap_hva,
 
TP_printk("unmap hva 0x%lx\n", __entry->hva)
 );
+#endif
 
 TRACE_EVENT(kvm_stlb_inval,
TP_PROTO(unsigned int stlb_index),
@@ -231,221 +226,6 @@ TRACE_EVENT(kvm_check_requests,
__entry->cpu_nr, __entry->requests)
 );
 
-
-/*
- * Book3S trace points   *
- */
-
-#ifdef CONFIG_KVM_BOOK3S_PR
-
-TRACE_EVENT(kvm_book3s_reenter,
-   TP_PROTO(int r, struct kvm_vcpu *vcpu),
-   TP_ARGS(r, vcpu),
-
-   TP_STRUCT__entry(
-   __field(unsigned int,   r   )
-   __field(unsigned long,  pc  )
-   ),
-
-   TP_fast_assign(
-   __entry->r  = r;
-   __entry->pc = kvmppc_get_pc(vcpu);
-   ),
-
-   TP_printk("reentry r=%d | pc=0x%lx", __entry->r, __entry->pc)
-);
-
-#ifdef CONFIG_PPC_BOOK3S_64
-
-TRACE_EVENT(kvm_book3s_64_mmu_map,
-   TP_PROTO(int rflags, ulong hpteg, ulong va, pfn_t hpaddr,
-struct kvmppc_pte *orig_pte),
-   TP_ARGS(rflags, hpteg, va, hpaddr, orig_pte),
-
-   TP_STRUCT__entry(
-   __field(unsigned char,  flag_w  )
-   __field(unsigned char,  flag_x  )
-   __field(unsigned long,  eaddr

[RFC PATCH 10/11] kvm: powerpc: book3s: Allow the HV and PR selection per virtual machine

2013-09-27 Thread Aneesh Kumar K.V
From: "Aneesh Kumar K.V" 

This moves the kvmppc_ops callbacks to be a per VM entity. This
enables us to select HV and PR mode when creating a VM

Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/include/asm/kvm_host.h |  3 ++
 arch/powerpc/include/asm/kvm_ppc.h  | 11 --
 arch/powerpc/kvm/book3s.c   | 60 +++---
 arch/powerpc/kvm/book3s_hv.c| 18 +
 arch/powerpc/kvm/book3s_pr.c| 18 ++---
 arch/powerpc/kvm/emulate.c  | 11 +++---
 arch/powerpc/kvm/powerpc.c  | 74 -
 include/linux/kvm_host.h|  7 ++--
 include/uapi/linux/kvm.h|  4 ++
 virt/kvm/kvm_main.c | 18 -
 10 files changed, 135 insertions(+), 89 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm_host.h 
b/arch/powerpc/include/asm/kvm_host.h
index 283e52e..61a297fc 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -276,6 +276,9 @@ struct kvm_arch {
 #ifdef CONFIG_KVM_XICS
struct kvmppc_xics *xics;
 #endif
+#ifdef CONFIG_PPC_BOOK3S_64
+   struct kvmppc_ops *kvm_ops;
+#endif
 };
 
 /*
diff --git a/arch/powerpc/include/asm/kvm_ppc.h 
b/arch/powerpc/include/asm/kvm_ppc.h
index 592501b..a4a5893 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -134,9 +134,11 @@ extern struct page *kvm_alloc_hpt(unsigned long nr_pages);
 extern void kvm_release_hpt(struct page *page, unsigned long nr_pages);
 extern int kvmppc_core_init_vm(struct kvm *kvm);
 extern void kvmppc_core_destroy_vm(struct kvm *kvm);
-extern void kvmppc_core_free_memslot(struct kvm_memory_slot *free,
+extern void kvmppc_core_free_memslot(struct kvm *kvm,
+struct kvm_memory_slot *free,
 struct kvm_memory_slot *dont);
-extern int kvmppc_core_create_memslot(struct kvm_memory_slot *slot,
+extern int kvmppc_core_create_memslot(struct kvm *kvm,
+ struct kvm_memory_slot *slot,
  unsigned long npages);
 extern int kvmppc_core_prepare_memory_region(struct kvm *kvm,
struct kvm_memory_slot *memslot,
@@ -216,7 +218,8 @@ struct kvmppc_ops {
 
 };
 
-extern struct kvmppc_ops *kvmppc_ops;
+extern struct kvmppc_ops *kvmppc_hv_ops;
+extern struct kvmppc_ops *kvmppc_pr_ops;
 
 /*
  * Cuts out inst bits with ordering according to spec.
@@ -324,7 +327,7 @@ static inline void kvmppc_set_host_ipi(int cpu, u8 host_ipi)
 
 static inline void kvmppc_fast_vcpu_kick(struct kvm_vcpu *vcpu)
 {
-   kvmppc_ops->fast_vcpu_kick(vcpu);
+   vcpu->kvm->arch.kvm_ops->fast_vcpu_kick(vcpu);
 }
 
 #else
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 485a6ff..34e189c 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -71,7 +71,7 @@ void kvmppc_core_load_guest_debugstate(struct kvm_vcpu *vcpu)
 
 static inline unsigned long kvmppc_interrupt_offset(struct kvm_vcpu *vcpu)
 {
-   if (!kvmppc_ops->is_hv_enabled)
+   if (!vcpu->kvm->arch.kvm_ops->is_hv_enabled)
return to_book3s(vcpu)->hior;
return 0;
 }
@@ -79,7 +79,7 @@ static inline unsigned long kvmppc_interrupt_offset(struct 
kvm_vcpu *vcpu)
 static inline void kvmppc_update_int_pending(struct kvm_vcpu *vcpu,
unsigned long pending_now, unsigned long old_pending)
 {
-   if (kvmppc_ops->is_hv_enabled)
+   if (vcpu->kvm->arch.kvm_ops->is_hv_enabled)
return;
if (pending_now)
vcpu->arch.shared->int_pending = 1;
@@ -93,7 +93,7 @@ static inline bool kvmppc_critical_section(struct kvm_vcpu 
*vcpu)
ulong crit_r1;
bool crit;
 
-   if (kvmppc_ops->is_hv_enabled)
+   if (vcpu->kvm->arch.kvm_ops->is_hv_enabled)
return false;
 
crit_raw = vcpu->arch.shared->critical;
@@ -470,13 +470,13 @@ void kvmppc_subarch_vcpu_uninit(struct kvm_vcpu *vcpu)
 int kvm_arch_vcpu_ioctl_get_sregs(struct kvm_vcpu *vcpu,
  struct kvm_sregs *sregs)
 {
-   return kvmppc_ops->get_sregs(vcpu, sregs);
+   return vcpu->kvm->arch.kvm_ops->get_sregs(vcpu, sregs);
 }
 
 int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
  struct kvm_sregs *sregs)
 {
-   return kvmppc_ops->set_sregs(vcpu, sregs);
+   return vcpu->kvm->arch.kvm_ops->set_sregs(vcpu, sregs);
 }
 
 int kvm_arch_vcpu_ioctl_get_regs(struct kvm_vcpu *vcpu, struct kvm_regs *regs)
@@ -555,7 +555,7 @@ int kvm_vcpu_ioctl_get_one_reg(struct kvm_vcpu *vcpu, 
struct kvm_one_reg *reg)
if (size > sizeof(val))
return -EINVAL;
 
-   r = kvmppc_ops->get_one_reg(vcpu, reg->id, &val);
+   r = vcpu->kvm->arch.kvm_ops->get_one_reg(vcpu, reg->id, &val);
if (r == -EINVAL) {
r = 0;
switch (reg->id) {
@@

[RFC PATCH 09/11] kvm: simplify processor compat check

2013-09-27 Thread Aneesh Kumar K.V
From: "Aneesh Kumar K.V" 

Signed-off-by: Aneesh Kumar K.V 
---
 arch/arm/kvm/arm.c |  4 ++--
 arch/ia64/kvm/kvm-ia64.c   |  4 ++--
 arch/mips/kvm/kvm_mips.c   |  6 ++
 arch/powerpc/include/asm/kvm_ppc.h |  2 +-
 arch/powerpc/kvm/44x.c |  2 +-
 arch/powerpc/kvm/book3s.c  | 15 ---
 arch/powerpc/kvm/book3s_hv.c   |  9 ++---
 arch/powerpc/kvm/book3s_pr.c   |  5 +++--
 arch/powerpc/kvm/e500.c|  2 +-
 arch/powerpc/kvm/e500mc.c  |  2 +-
 arch/powerpc/kvm/powerpc.c |  5 -
 arch/s390/kvm/kvm-s390.c   |  3 ++-
 arch/x86/kvm/x86.c | 13 +++--
 include/linux/kvm_host.h   |  2 +-
 virt/kvm/kvm_main.c| 14 +-
 15 files changed, 50 insertions(+), 38 deletions(-)

diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 9c697db..cccb121 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -109,9 +109,9 @@ void kvm_arch_hardware_unsetup(void)
 {
 }
 
-void kvm_arch_check_processor_compat(void *rtn)
+int kvm_arch_check_processor_compat(void *opaque)
 {
-   *(int *)rtn = 0;
+   return 0;
 }
 
 void kvm_arch_sync_events(struct kvm *kvm)
diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
index bdfd878..065942c 100644
--- a/arch/ia64/kvm/kvm-ia64.c
+++ b/arch/ia64/kvm/kvm-ia64.c
@@ -185,9 +185,9 @@ void kvm_arch_hardware_disable(void *garbage)
ia64_ptr_entry(0x3, slot);
 }
 
-void kvm_arch_check_processor_compat(void *rtn)
+int kvm_arch_check_processor_compat(void *opaque)
 {
-   *(int *)rtn = 0;
+   return 0;
 }
 
 int kvm_dev_ioctl_check_extension(long ext)
diff --git a/arch/mips/kvm/kvm_mips.c b/arch/mips/kvm/kvm_mips.c
index a7b0445..4512739 100644
--- a/arch/mips/kvm/kvm_mips.c
+++ b/arch/mips/kvm/kvm_mips.c
@@ -97,11 +97,9 @@ void kvm_arch_hardware_unsetup(void)
 {
 }
 
-void kvm_arch_check_processor_compat(void *rtn)
+int kvm_arch_check_processor_compat(void *opaque)
 {
-   int *r = (int *)rtn;
-   *r = 0;
-   return;
+   return 0;
 }
 
 static void kvm_mips_init_tlbs(struct kvm *kvm)
diff --git a/arch/powerpc/include/asm/kvm_ppc.h 
b/arch/powerpc/include/asm/kvm_ppc.h
index 58e732f..592501b 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -204,7 +204,7 @@ struct kvmppc_ops {
  unsigned long npages);
int (*init_vm)(struct kvm *kvm);
void (*destroy_vm)(struct kvm *kvm);
-   int (*check_processor_compat)(void);
+   void (*check_processor_compat)(void *r);
int (*get_smmu_info)(struct kvm *kvm, struct kvm_ppc_smmu_info *info);
int (*emulate_op)(struct kvm_run *run, struct kvm_vcpu *vcpu,
  unsigned int inst, int *advance);
diff --git a/arch/powerpc/kvm/44x.c b/arch/powerpc/kvm/44x.c
index 2f5c6b6..a1f4e60 100644
--- a/arch/powerpc/kvm/44x.c
+++ b/arch/powerpc/kvm/44x.c
@@ -43,7 +43,7 @@ void kvmppc_core_vcpu_put(struct kvm_vcpu *vcpu)
kvmppc_booke_vcpu_put(vcpu);
 }
 
-int kvmppc_core_check_processor_compat(void)
+int kvm_arch_check_processor_compat(void *opaque)
 {
int r;
 
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index ca617e1..485a6ff 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -827,9 +827,18 @@ void kvmppc_core_destroy_vm(struct kvm *kvm)
 #endif
 }
 
-int kvmppc_core_check_processor_compat(void)
-{
-   return kvmppc_ops->check_processor_compat();
+int kvm_arch_check_processor_compat(void *opaque)
+{
+   int r,cpu;
+   struct kvmppc_ops *kvm_ops = (struct kvmppc_ops *)opaque;
+   for_each_online_cpu(cpu) {
+   smp_call_function_single(cpu,
+kvm_ops->check_processor_compat,
+&r, 1);
+   if (r < 0)
+   break;
+   }
+   return r;
 }
 
 EXPORT_SYMBOL_GPL(kvm_get_dirty_log);
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index ff57be8..4322db4 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -1980,11 +1980,14 @@ static int kvmppc_core_emulate_mfspr_hv(struct kvm_vcpu 
*vcpu, int sprn,
return EMULATE_FAIL;
 }
 
-static int kvmppc_core_check_processor_compat_hv(void)
+
+static void kvmppc_core_check_processor_compat_hv(void *r)
 {
if (!cpu_has_feature(CPU_FTR_HVMODE))
-   return -EIO;
-   return 0;
+   *(int *)r = -EIO;
+   else
+   *(int *)r = 0;
+   return;
 }
 
 static long kvm_arch_vm_ioctl_hv(struct file *filp,
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index df48d89..127b961 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -1490,10 +1490,11 @@ static void kvmppc_core_destroy_vm_pr(struct kvm *kvm)
enable_relon_interrupts(kvm);
 }
 
-static int kvmppc

[RFC PATCH 06/11] kvm: powerpc: book3s: Add is_hv_enabled to kvmppc_ops

2013-09-27 Thread Aneesh Kumar K.V
From: "Aneesh Kumar K.V" 

This help us to identify whether we are running with hypervisor mode KVM
enabled. The change is needed so that we can have both HV and PR kvm
enabled in the same kernel.

If both HV and PR KVM are included, interrupts come in to the HV version
of the kvmppc_interrupt code, which then jumps to the PR handler,
renamed to kvmppc_interrupt_pr, if the guest is a PR guest.

Allowing both PR and HV in the same kernel required some changes to
kvm_dev_ioctl_check_extension(), since the values returned now can't
be selected with #ifdefs as much as previously. We look at is_hv_enabled
to return the right value when checking for capabilities.For capabilities that
are only provided by HV KVM, we return the HV value only if
is_hv_enabled is true. For capabilities provided by PR KVM but not HV,
we return the PR value only if is_hv_enabled is false.

Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/include/asm/kvm_book3s.h   | 53 
 arch/powerpc/include/asm/kvm_ppc.h  |  5 +--
 arch/powerpc/kvm/Makefile   |  2 +-
 arch/powerpc/kvm/book3s.c   | 44 +++
 arch/powerpc/kvm/book3s_hv.c|  1 +
 arch/powerpc/kvm/book3s_hv_rmhandlers.S |  4 +++
 arch/powerpc/kvm/book3s_pr.c|  1 +
 arch/powerpc/kvm/book3s_segment.S   |  7 -
 arch/powerpc/kvm/book3s_xics.c  |  2 +-
 arch/powerpc/kvm/powerpc.c  | 54 ++---
 10 files changed, 90 insertions(+), 83 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm_book3s.h 
b/arch/powerpc/include/asm/kvm_book3s.h
index 3efba3c..ba33c49 100644
--- a/arch/powerpc/include/asm/kvm_book3s.h
+++ b/arch/powerpc/include/asm/kvm_book3s.h
@@ -297,59 +297,6 @@ static inline ulong kvmppc_get_fault_dar(struct kvm_vcpu 
*vcpu)
return vcpu->arch.fault_dar;
 }
 
-#ifdef CONFIG_KVM_BOOK3S_PR
-
-static inline unsigned long kvmppc_interrupt_offset(struct kvm_vcpu *vcpu)
-{
-   return to_book3s(vcpu)->hior;
-}
-
-static inline void kvmppc_update_int_pending(struct kvm_vcpu *vcpu,
-   unsigned long pending_now, unsigned long old_pending)
-{
-   if (pending_now)
-   vcpu->arch.shared->int_pending = 1;
-   else if (old_pending)
-   vcpu->arch.shared->int_pending = 0;
-}
-
-static inline bool kvmppc_critical_section(struct kvm_vcpu *vcpu)
-{
-   ulong crit_raw = vcpu->arch.shared->critical;
-   ulong crit_r1 = kvmppc_get_gpr(vcpu, 1);
-   bool crit;
-
-   /* Truncate crit indicators in 32 bit mode */
-   if (!(vcpu->arch.shared->msr & MSR_SF)) {
-   crit_raw &= 0x;
-   crit_r1 &= 0x;
-   }
-
-   /* Critical section when crit == r1 */
-   crit = (crit_raw == crit_r1);
-   /* ... and we're in supervisor mode */
-   crit = crit && !(vcpu->arch.shared->msr & MSR_PR);
-
-   return crit;
-}
-#else /* CONFIG_KVM_BOOK3S_PR */
-
-static inline unsigned long kvmppc_interrupt_offset(struct kvm_vcpu *vcpu)
-{
-   return 0;
-}
-
-static inline void kvmppc_update_int_pending(struct kvm_vcpu *vcpu,
-   unsigned long pending_now, unsigned long old_pending)
-{
-}
-
-static inline bool kvmppc_critical_section(struct kvm_vcpu *vcpu)
-{
-   return false;
-}
-#endif
-
 /* Magic register values loaded into r3 and r4 before the 'sc' assembly
  * instruction for the OSI hypercalls */
 #define OSI_SC_MAGIC_R30x113724FA
diff --git a/arch/powerpc/include/asm/kvm_ppc.h 
b/arch/powerpc/include/asm/kvm_ppc.h
index 4d9641c..58e732f 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -169,6 +169,7 @@ extern int kvmppc_xics_int_on(struct kvm *kvm, u32 irq);
 extern int kvmppc_xics_int_off(struct kvm *kvm, u32 irq);
 
 struct kvmppc_ops {
+   bool is_hv_enabled;
int (*get_sregs)(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs);
int (*set_sregs)(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs);
int (*get_one_reg)(struct kvm_vcpu *vcpu, u64 id,
@@ -309,10 +310,10 @@ static inline void kvmppc_set_xics_phys(int cpu, unsigned 
long addr)
 
 static inline u32 kvmppc_get_xics_latch(void)
 {
-   u32 xirr = get_paca()->kvm_hstate.saved_xirr;
+   u32 xirr;
 
+   xirr = get_paca()->kvm_hstate.saved_xirr;
get_paca()->kvm_hstate.saved_xirr = 0;
-
return xirr;
 }
 
diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile
index c343793..a514ecd 100644
--- a/arch/powerpc/kvm/Makefile
+++ b/arch/powerpc/kvm/Makefile
@@ -77,7 +77,7 @@ kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_HANDLER) += 
\
book3s_rmhandlers.o
 endif
 
-kvm-book3s_64-objs-$(CONFIG_KVM_BOOK3S_64_HV) := \
+kvm-book3s_64-objs-$(CONFIG_KVM_BOOK3S_64_HV)  += \
book3s_hv.o \
book3s_hv_interrupts.o \
book3s_64_mmu_hv.o
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
ind

[RFC PATCH 04/11] kvm: powerpc: book3s: Add a new config variable CONFIG_KVM_BOOK3S_HV

2013-09-27 Thread Aneesh Kumar K.V
From: "Aneesh Kumar K.V" 

This help ups to select the relevant code in the kernel code
when we later move HV and PR bits as seperate modules.

Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/include/asm/kvm_book3s_64.h  |  6 +++---
 arch/powerpc/include/asm/kvm_book3s_asm.h |  2 +-
 arch/powerpc/include/asm/kvm_host.h   | 10 +-
 arch/powerpc/include/asm/kvm_ppc.h|  2 +-
 arch/powerpc/kernel/asm-offsets.c |  8 
 arch/powerpc/kernel/exceptions-64s.S  |  2 +-
 arch/powerpc/kernel/idle_power7.S |  2 +-
 arch/powerpc/kvm/Kconfig  |  4 
 arch/powerpc/kvm/book3s_exports.c |  5 +++--
 arch/powerpc/kvm/book3s_xics.c|  4 ++--
 10 files changed, 25 insertions(+), 20 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm_book3s_64.h 
b/arch/powerpc/include/asm/kvm_book3s_64.h
index 86d638a..37af4ae 100644
--- a/arch/powerpc/include/asm/kvm_book3s_64.h
+++ b/arch/powerpc/include/asm/kvm_book3s_64.h
@@ -35,7 +35,7 @@ static inline void svcpu_put(struct kvmppc_book3s_shadow_vcpu 
*svcpu)
 
 #define SPAPR_TCE_SHIFT12
 
-#ifdef CONFIG_KVM_BOOK3S_64_HV
+#ifdef CONFIG_KVM_BOOK3S_HV
 #define KVM_DEFAULT_HPT_ORDER  24  /* 16MB HPT by default */
 extern unsigned long kvm_rma_pages;
 #endif
@@ -278,7 +278,7 @@ static inline int is_vrma_hpte(unsigned long hpte_v)
(HPTE_V_1TB_SEG | (VRMA_VSID << (40 - 16)));
 }
 
-#ifdef CONFIG_KVM_BOOK3S_64_HV
+#ifdef CONFIG_KVM_BOOK3S_HV
 /*
  * Note modification of an HPTE; set the HPTE modified bit
  * if anyone is interested.
@@ -289,6 +289,6 @@ static inline void note_hpte_modification(struct kvm *kvm,
if (atomic_read(&kvm->arch.hpte_mod_interest))
rev->guest_rpte |= HPTE_GR_MODIFIED;
 }
-#endif /* CONFIG_KVM_BOOK3S_64_HV */
+#endif /* CONFIG_KVM_BOOK3S_HV */
 
 #endif /* __ASM_KVM_BOOK3S_64_H__ */
diff --git a/arch/powerpc/include/asm/kvm_book3s_asm.h 
b/arch/powerpc/include/asm/kvm_book3s_asm.h
index 360742a..1272178 100644
--- a/arch/powerpc/include/asm/kvm_book3s_asm.h
+++ b/arch/powerpc/include/asm/kvm_book3s_asm.h
@@ -84,7 +84,7 @@ struct kvmppc_host_state {
u8 restore_hid5;
u8 napping;
 
-#ifdef CONFIG_KVM_BOOK3S_64_HV
+#ifdef CONFIG_KVM_BOOK3S_HV
u8 hwthread_req;
u8 hwthread_state;
u8 host_ipi;
diff --git a/arch/powerpc/include/asm/kvm_host.h 
b/arch/powerpc/include/asm/kvm_host.h
index 78627c2..283e52e 100644
--- a/arch/powerpc/include/asm/kvm_host.h
+++ b/arch/powerpc/include/asm/kvm_host.h
@@ -229,15 +229,15 @@ struct revmap_entry {
 #define KVMPPC_GOT_PAGE0x80
 
 struct kvm_arch_memory_slot {
-#ifdef CONFIG_KVM_BOOK3S_64_HV
+#ifdef CONFIG_KVM_BOOK3S_HV
unsigned long *rmap;
unsigned long *slot_phys;
-#endif /* CONFIG_KVM_BOOK3S_64_HV */
+#endif /* CONFIG_KVM_BOOK3S_HV */
 };
 
 struct kvm_arch {
unsigned int lpid;
-#ifdef CONFIG_KVM_BOOK3S_64_HV
+#ifdef CONFIG_KVM_BOOK3S_HV
unsigned long hpt_virt;
struct revmap_entry *revmap;
unsigned int host_lpid;
@@ -261,7 +261,7 @@ struct kvm_arch {
cpumask_t need_tlb_flush;
struct kvmppc_vcore *vcores[KVM_MAX_VCORES];
int hpt_cma_alloc;
-#endif /* CONFIG_KVM_BOOK3S_64_HV */
+#endif /* CONFIG_KVM_BOOK3S_HV */
 #ifdef CONFIG_KVM_BOOK3S_PR
struct mutex hpt_mutex;
bool relon_disabled;
@@ -598,7 +598,7 @@ struct kvm_vcpu_arch {
struct kvmppc_icp *icp; /* XICS presentation controller */
 #endif
 
-#ifdef CONFIG_KVM_BOOK3S_64_HV
+#ifdef CONFIG_KVM_BOOK3S_HV
struct kvm_vcpu_arch_shared shregs;
 
unsigned long pgfault_addr;
diff --git a/arch/powerpc/include/asm/kvm_ppc.h 
b/arch/powerpc/include/asm/kvm_ppc.h
index b15554a..9161bd1 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -260,7 +260,7 @@ void kvmppc_set_pid(struct kvm_vcpu *vcpu, u32 pid);
 
 struct openpic;
 
-#ifdef CONFIG_KVM_BOOK3S_64_HV
+#ifdef CONFIG_KVM_BOOK3S_HV
 extern void kvm_cma_reserve(void) __init;
 static inline void kvmppc_set_xics_phys(int cpu, unsigned long addr)
 {
diff --git a/arch/powerpc/kernel/asm-offsets.c 
b/arch/powerpc/kernel/asm-offsets.c
index 67b5d56..dd7ad4a 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -445,7 +445,7 @@ int main(void)
DEFINE(VCPU_LR, offsetof(struct kvm_vcpu, arch.lr));
DEFINE(VCPU_CR, offsetof(struct kvm_vcpu, arch.cr));
DEFINE(VCPU_PC, offsetof(struct kvm_vcpu, arch.pc));
-#ifdef CONFIG_KVM_BOOK3S_64_HV
+#ifdef CONFIG_KVM_BOOK3S_HV
DEFINE(VCPU_MSR, offsetof(struct kvm_vcpu, arch.shregs.msr));
DEFINE(VCPU_SRR0, offsetof(struct kvm_vcpu, arch.shregs.srr0));
DEFINE(VCPU_SRR1, offsetof(struct kvm_vcpu, arch.shregs.srr1));
@@ -476,7 +476,7 @@ int main(void)
DEFINE(KVM_LPID, offsetof(struct kvm, arch.lpid));
 
/* book3s */
-#ifdef CONFIG_KVM_BOOK3S_64_HV
+#ifdef CONFIG_KVM_BOOK3S_HV

[RFC PATCH 08/11] kvm: powerpc: book3s: Support building HV and PR KVM as module

2013-09-27 Thread Aneesh Kumar K.V
From: "Aneesh Kumar K.V" 

Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/kvm/Kconfig  |  6 +++---
 arch/powerpc/kvm/Makefile | 12 
 arch/powerpc/kvm/book3s.c | 19 ++-
 arch/powerpc/kvm/book3s_64_mmu_host.c |  1 +
 arch/powerpc/kvm/book3s_emulate.c |  2 +-
 arch/powerpc/kvm/book3s_hv.c  |  4 
 arch/powerpc/kvm/book3s_pr.c  |  5 -
 arch/powerpc/kvm/book3s_rtas.c|  1 +
 arch/powerpc/kvm/emulate.c|  1 +
 arch/powerpc/kvm/powerpc.c|  6 ++
 virt/kvm/kvm_main.c   |  3 +++
 11 files changed, 50 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/kvm/Kconfig b/arch/powerpc/kvm/Kconfig
index 5c62459..f63fd8f 100644
--- a/arch/powerpc/kvm/Kconfig
+++ b/arch/powerpc/kvm/Kconfig
@@ -73,7 +73,7 @@ config KVM_BOOK3S_64
  If unsure, say N.
 
 config KVM_BOOK3S_64_HV
-   bool "KVM support for POWER7 and PPC970 using hypervisor mode in host"
+   tristate "KVM support for POWER7 and PPC970 using hypervisor mode in 
host"
depends on KVM_BOOK3S_64
select KVM_BOOK3S_HV
select MMU_NOTIFIER
@@ -94,8 +94,8 @@ config KVM_BOOK3S_64_HV
  If unsure, say N.
 
 config KVM_BOOK3S_64_PR
-   bool "KVM support without using hypervisor mode in host"
-   depends on KVM_BOOK3S_64 && !KVM_BOOK3S_64_HV
+   tristate "KVM support without using hypervisor mode in host"
+   depends on KVM_BOOK3S_64
select KVM_BOOK3S_PR
---help---
  Support running guest kernels in virtual machines on processors
diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile
index a514ecd..861b8da 100644
--- a/arch/powerpc/kvm/Makefile
+++ b/arch/powerpc/kvm/Makefile
@@ -56,8 +56,7 @@ kvm-objs-$(CONFIG_KVM_E500MC) := $(kvm-e500mc-objs)
 kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_HANDLER) := \
book3s_64_vio_hv.o
 
-kvm-book3s_64-objs-$(CONFIG_KVM_BOOK3S_64_PR) := \
-   $(KVM)/coalesced_mmio.o \
+kvm-pr-y := \
fpu.o \
book3s_paired_singles.o \
book3s_pr.o \
@@ -77,7 +76,7 @@ kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_HANDLER) += 
\
book3s_rmhandlers.o
 endif
 
-kvm-book3s_64-objs-$(CONFIG_KVM_BOOK3S_64_HV)  += \
+kvm-hv-y += \
book3s_hv.o \
book3s_hv_interrupts.o \
book3s_64_mmu_hv.o
@@ -85,13 +84,15 @@ kvm-book3s_64-objs-$(CONFIG_KVM_BOOK3S_64_HV)  += \
 kvm-book3s_64-builtin-xics-objs-$(CONFIG_KVM_XICS) := \
book3s_hv_rm_xics.o
 
-kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_HV) += \
+ifdef CONFIG_KVM_BOOK3S_HV
+kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_HANDLER) += \
book3s_hv_rmhandlers.o \
book3s_hv_rm_mmu.o \
book3s_hv_ras.o \
book3s_hv_builtin.o \
book3s_hv_cma.o \
$(kvm-book3s_64-builtin-xics-objs-y)
+endif
 
 kvm-book3s_64-objs-$(CONFIG_KVM_XICS) += \
book3s_xics.o
@@ -132,4 +133,7 @@ obj-$(CONFIG_KVM_E500MC) += kvm.o
 obj-$(CONFIG_KVM_BOOK3S_64) += kvm.o
 obj-$(CONFIG_KVM_BOOK3S_32) += kvm.o
 
+obj-$(CONFIG_KVM_BOOK3S_64_PR) += kvm-pr.o
+obj-$(CONFIG_KVM_BOOK3S_64_HV) += kvm-hv.o
+
 obj-y += $(kvm-book3s_64-builtin-objs-y)
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 12f94bf..ca617e1 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -170,13 +170,14 @@ void kvmppc_book3s_queue_irqprio(struct kvm_vcpu *vcpu, 
unsigned int vec)
printk(KERN_INFO "Queueing interrupt %x\n", vec);
 #endif
 }
-
+EXPORT_SYMBOL_GPL(kvmppc_book3s_queue_irqprio);
 
 void kvmppc_core_queue_program(struct kvm_vcpu *vcpu, ulong flags)
 {
/* might as well deliver this straight away */
kvmppc_inject_interrupt(vcpu, BOOK3S_INTERRUPT_PROGRAM, flags);
 }
+EXPORT_SYMBOL_GPL(kvmppc_core_queue_program);
 
 void kvmppc_core_queue_dec(struct kvm_vcpu *vcpu)
 {
@@ -351,6 +352,7 @@ pfn_t kvmppc_gfn_to_pfn(struct kvm_vcpu *vcpu, gfn_t gfn)
 
return gfn_to_pfn(vcpu->kvm, gfn);
 }
+EXPORT_SYMBOL_GPL(kvmppc_gfn_to_pfn);
 
 static int kvmppc_xlate(struct kvm_vcpu *vcpu, ulong eaddr, bool data,
 struct kvmppc_pte *pte)
@@ -418,6 +420,7 @@ int kvmppc_st(struct kvm_vcpu *vcpu, ulong *eaddr, int 
size, void *ptr,
 
return EMULATE_DONE;
 }
+EXPORT_SYMBOL_GPL(kvmppc_st);
 
 int kvmppc_ld(struct kvm_vcpu *vcpu, ulong *eaddr, int size, void *ptr,
  bool data)
@@ -448,6 +451,7 @@ nopte:
 mmio:
return EMULATE_DO_MMIO;
 }
+EXPORT_SYMBOL_GPL(kvmppc_ld);
 
 int kvm_arch_vcpu_setup(struct kvm_vcpu *vcpu)
 {
@@ -693,6 +697,7 @@ void kvmppc_set_msr(struct kvm_vcpu *vcpu, u64 msr)
 {
kvmppc_ops->set_msr(vcpu, msr);
 }
+EXPORT_SYMBOL_GPL(kvmppc_set_msr);
 
 int kvmppc_vcpu_run(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu)
 {
@@ -774,6 +779,7 @@ int kvm_unmap_hva(struct kvm *kvm, unsigned long hva)
 {
return kvmppc_ops->unmap_hva(kvm, hva);
 }
+EXPORT_SYMBOL_GPL(kvm_unma

[RFC PATCH 00/11 Allow PR and HV KVM to coexist in one kernel

2013-09-27 Thread Aneesh Kumar K.V
Hi All,

This patch series support enabling HV and PR KVM together in the same kernel. We
extend machine property with new property "kvm_type". A value of 1 will force HV
KVM and 2 PR KVM. The default value is 0 which will select the fastest KVM mode.
ie, HV if that is supported otherwise PR.

With Qemu command line having

 -machine pseries,accel=kvm,kvm_type=1

[root@llmp24l02 qemu]# bash ../qemu
failed to initialize KVM: Invalid argument
[root@llmp24l02 qemu]# modprobe kvm-pr
[root@llmp24l02 qemu]# bash ../qemu
failed to initialize KVM: Invalid argument
[root@llmp24l02 qemu]# modprobe  kvm-hv
[root@llmp24l02 qemu]# bash ../qemu

now with

 -machine pseries,accel=kvm,kvm_type=2

[root@llmp24l02 qemu]# rmmod kvm-pr
[root@llmp24l02 qemu]# bash ../qemu
failed to initialize KVM: Invalid argument
[root@llmp24l02 qemu]#
[root@llmp24l02 qemu]# modprobe kvm-pr
[root@llmp24l02 qemu]# bash ../qemu

if don't specify kvm_type machine property, it will take a default value 0,
which means fastest supported.

-aneesh

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[RFC PATCH 02/11] kvm: powerpc: book3s: remove kvmppc_handler_highmem label

2013-09-27 Thread Aneesh Kumar K.V
From: Paul Mackerras 

This label is not used now.

Signed-off-by: Paul Mackerras 
Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/kvm/book3s_hv_interrupts.S | 3 ---
 arch/powerpc/kvm/book3s_interrupts.S| 3 ---
 2 files changed, 6 deletions(-)

diff --git a/arch/powerpc/kvm/book3s_hv_interrupts.S 
b/arch/powerpc/kvm/book3s_hv_interrupts.S
index 37f1cc4..928142c 100644
--- a/arch/powerpc/kvm/book3s_hv_interrupts.S
+++ b/arch/powerpc/kvm/book3s_hv_interrupts.S
@@ -158,9 +158,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_201)
  * Interrupts are enabled again at this point.
  */
 
-.global kvmppc_handler_highmem
-kvmppc_handler_highmem:
-
/*
 * Register usage at this point:
 *
diff --git a/arch/powerpc/kvm/book3s_interrupts.S 
b/arch/powerpc/kvm/book3s_interrupts.S
index bf8f1ab..279ee3f 100644
--- a/arch/powerpc/kvm/book3s_interrupts.S
+++ b/arch/powerpc/kvm/book3s_interrupts.S
@@ -121,9 +121,6 @@ kvm_start_lightweight:
  *
  */
 
-.global kvmppc_handler_highmem
-kvmppc_handler_highmem:
-
/*
 * Register usage at this point:
 *
-- 
1.8.1.2

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[RFC PATCH 11/11] kvm: powerpc: book3s: Fix module ownership

2013-09-27 Thread Aneesh Kumar K.V
From: "Aneesh Kumar K.V" 

This moves /dev/kvm ownership to kvm.ko module. Depending on
which KVM mode we select during VM creation we take a reference
count on respective module

Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/include/asm/kvm_ppc.h |  1 +
 arch/powerpc/kvm/book3s.c  | 21 +
 arch/powerpc/kvm/book3s_hv.c   | 15 ++-
 arch/powerpc/kvm/book3s_pr.c   | 15 +--
 arch/powerpc/kvm/powerpc.c | 19 +++
 5 files changed, 48 insertions(+), 23 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm_ppc.h 
b/arch/powerpc/include/asm/kvm_ppc.h
index a4a5893..2022720 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -171,6 +171,7 @@ extern int kvmppc_xics_int_on(struct kvm *kvm, u32 irq);
 extern int kvmppc_xics_int_off(struct kvm *kvm, u32 irq);
 
 struct kvmppc_ops {
+   struct module *owner;
bool is_hv_enabled;
int (*get_sregs)(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs);
int (*set_sregs)(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs);
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 34e189c..363df6a 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -831,6 +831,10 @@ int kvm_arch_check_processor_compat(void *opaque)
 {
int r,cpu;
struct kvmppc_ops *kvm_ops = (struct kvmppc_ops *)opaque;
+
+   if (!kvm_ops)
+   return 0;
+
for_each_online_cpu(cpu) {
smp_call_function_single(cpu,
 kvm_ops->check_processor_compat,
@@ -840,6 +844,7 @@ int kvm_arch_check_processor_compat(void *opaque)
}
return r;
 }
+EXPORT_SYMBOL_GPL(kvm_arch_check_processor_compat);
 
 EXPORT_SYMBOL_GPL(kvm_get_dirty_log);
 EXPORT_SYMBOL_GPL(kvmppc_core_pending_dec);
@@ -851,3 +856,19 @@ EXPORT_SYMBOL_GPL(kvmppc_core_prepare_to_enter);
 EXPORT_SYMBOL_GPL(kvmppc_core_queue_dec);
 EXPORT_SYMBOL_GPL(kvmppc_free_lpid);
 
+static int kvmppc_book3s_init(void)
+{
+   int r;
+
+   r = kvm_init(NULL, sizeof(struct kvm_vcpu), 0, THIS_MODULE);
+   return r;
+}
+
+static void kvmppc_book3s_exit(void)
+{
+   kvm_exit();
+}
+
+module_init(kvmppc_book3s_init);
+module_exit(kvmppc_book3s_exit);
+
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 0a684a7..7bdc780 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -2092,23 +2092,20 @@ static int kvmppc_book3s_init_hv(void)
 {
int r;
 
-   if (!kvmppc_pr_ops) {
-   r = kvm_init(&kvm_ops_hv, sizeof(struct kvm_vcpu),
-0, THIS_MODULE);
-   if (r)
-   return r;
-   }
+   r = kvm_arch_check_processor_compat(&kvm_ops_hv);
+   if (r < 0)
+   return r;
+
+   kvm_ops_hv.owner = THIS_MODULE;
kvmppc_hv_ops = &kvm_ops_hv;
-   r = kvmppc_mmu_hv_init();
 
+   r = kvmppc_mmu_hv_init();
return r;
 }
 
 static void kvmppc_book3s_exit_hv(void)
 {
kvmppc_hv_ops = NULL;
-   if (!kvmppc_pr_ops)
-   kvm_exit();
 }
 
 module_init(kvmppc_book3s_init_hv);
diff --git a/arch/powerpc/kvm/book3s_pr.c b/arch/powerpc/kvm/book3s_pr.c
index e49e4b0..c79fada 100644
--- a/arch/powerpc/kvm/book3s_pr.c
+++ b/arch/powerpc/kvm/book3s_pr.c
@@ -1551,17 +1551,14 @@ static int kvmppc_book3s_init_pr(void)
 {
int r;
 
-   if (!kvmppc_hv_ops) {
-   r = kvm_init(&kvm_ops_pr, sizeof(struct kvm_vcpu),
-0, THIS_MODULE);
-   if (r)
-   return r;
-   }
-   /* Assign the global value */
+   r = kvm_arch_check_processor_compat(&kvm_ops_pr);
+   if (r < 0)
+   return r;
+
+   kvm_ops_pr.owner = THIS_MODULE;
kvmppc_pr_ops = &kvm_ops_pr;
 
r = kvmppc_mmu_hpte_sysinit();
-
return r;
 }
 
@@ -1569,8 +1566,6 @@ static void kvmppc_book3s_exit_pr(void)
 {
kvmppc_pr_ops = NULL;
kvmppc_mmu_hpte_sysexit();
-   if (!kvmppc_hv_ops)
-   kvm_exit();
 }
 
 module_init(kvmppc_book3s_init_pr);
diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
index 1209229..677fa7e 100644
--- a/arch/powerpc/kvm/powerpc.c
+++ b/arch/powerpc/kvm/powerpc.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -270,25 +271,32 @@ void kvm_arch_hardware_unsetup(void)
 
 int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
 {
+   struct kvmppc_ops *kvm_ops = NULL;
/*
 * if we have both HV and PR enabled, default is HV
 */
if (type == 0) {
if (kvmppc_hv_ops)
-   kvm->arch.kvm_ops = kvmppc_hv_ops;
+   kvm_ops = kvmppc_hv_ops;
else
-   kvm->arch.kvm_ops = kvmppc_pr_ops;
+   kvm_op

[RFC PATCH 01/11] kvm: powerpc: book3s hv: Fix vcore leak

2013-09-27 Thread Aneesh Kumar K.V
From: Paul Mackerras 

add kvmppc_free_vcores() to free the kvmppc_vcore structures
that we allocate for a guest, which are currently being leaked.

Signed-off-by: Paul Mackerras 
Signed-off-by: Aneesh Kumar K.V 
---
 arch/powerpc/kvm/book3s_hv.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 62a2b5a..edc7f9f 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -1931,10 +1931,20 @@ int kvmppc_core_init_vm(struct kvm *kvm)
return 0;
 }
 
+static void kvmppc_free_vcores(struct kvm *kvm)
+{
+   long int i;
+
+   for (i = 0; i < KVM_MAX_VCORES; ++i)
+   kfree(kvm->arch.vcores[i]);
+   kvm->arch.online_vcores = 0;
+}
+
 void kvmppc_core_destroy_vm(struct kvm *kvm)
 {
uninhibit_secondary_onlining();
 
+   kvmppc_free_vcores(kvm);
if (kvm->arch.rma) {
kvm_release_rma(kvm->arch.rma);
kvm->arch.rma = NULL;
-- 
1.8.1.2

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH 00/51] DMA mask changes

2013-09-27 Thread Russell King - ARM Linux
On Thu, Sep 26, 2013 at 10:23:08PM +0200, Rafał Miłecki wrote:
> 2013/9/19 Russell King - ARM Linux :
> > This email is only being sent to the mailing lists in question, not to
> > anyone personally.  The list of individuals is far to great to do that.
> > I'm hoping no mailing lists reject the patches based on the number of
> > recipients.
> 
> Huh, I think it was enough to send only 3 patches to the b43-dev@. Like:
> [PATCH 01/51] DMA-API: provide a helper to set both DMA and coherent DMA masks
> [PATCH 14/51] DMA-API: net: b43: (...)
> [PATCH 15/51] DMA-API: net: b43legacy: (...)
> ;)
> 
> I believe Joe has some nice script for doing it that way. When fixing
> some coding style / formatting, he sends only related patches to the
> given ML.

If I did that, then the mailing lists would not get the first patch,
because almost none of the lists would be referred to by patch 1.

Moreover, people complain when they don't have access to the full
patch series - they assume patches are missing for some reason, and
they ask for the rest of the series.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Please revert 928bea964827d7824b548c1f8e06eccbbc4d0d7d

2013-09-27 Thread Benjamin Herrenschmidt
Hi Linus, Yinghai !

Please consider reverting:

928bea964827d7824b548c1f8e06eccbbc4d0d7d
PCI: Delay enabling bridges until they're needed

(I'd suggest to revert now and maybe merge a better patch later)

This breaks PCI on the PowerPC "powernv" platform (which is booted via
kexec) and probably x86 as well under similar circumstances. It will
basically break PCIe if the bus master bit of the bridge isn't set at
boot (by the firmware for example, or because kexec'ing cleared it).

The reason is that the PCIe port driver will call pci_enable_device() on
the bridge (on everything under the sun actually), which will marked the
device enabled (but will not do a set_master).

Because of that, pci_enable_bridge() later on (called as a result of the
child device driver doing pci_enable_device) will see the bridge as
already enabled and will not call pci_set_master() on it.

Now, this could probably be fixed by simply doing pci_set_master() in
the PCIe port driver, but I find the whole logic very fragile (anything
that "enables" the bridge without setting master or for some reason
clears master will forever fail to re-enable it).

Maybe a better option is to unconditionally do pci_set_mater() in
pci_enable_bridge(), ie, move the call to before the enabled test.

However I am not too happy with that either. My experience with bridges
is that if bus master isn't set, they will also fail to report AER
errors and other similar upstream transactions. We might want to get
these reported properly even if no downstream device got successfully
enabled.

So I think the premises of the patches are flawed, at least on PCI
express, and we should stick to always enabling bridges (at least the
bus master bit on them).

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc/kvmbook3s_hv: propagate H_SET_MODE to the host

2013-09-27 Thread Laurent Dufour
On 26/09/2013 00:31, Paul Mackerras wrote:
> On Wed, Sep 25, 2013 at 02:10:27PM +0200, Laurent Dufour wrote:
>> Follow-up to Anton's H_SET_MODE patch, the host should be taken aware of
>> guest endianess change.
>>
>> The hcall H_SET_MODE is processed in kvm then in the host.
>>
>> Signed-off-by: Laurent Dufour 
>> ---
>>  arch/powerpc/kvm/book3s_hv.c |8 
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
>> index 998cad3..4a47c74 100644
>> --- a/arch/powerpc/kvm/book3s_hv.c
>> +++ b/arch/powerpc/kvm/book3s_hv.c
>> @@ -599,6 +599,14 @@ int kvmppc_pseries_do_hcall(struct kvm_vcpu *vcpu)
>>  kvmppc_get_gpr(vcpu, 5),
>>  kvmppc_get_gpr(vcpu, 6),
>>  kvmppc_get_gpr(vcpu, 7));
>> +/*
>> + * If the hcall succeeded, we propagate it to the host.
>> + * This way, it will be aware of the endianess's change too.
>> + * The assumption is made that the hcall will succeed in the
>> + * host.
>> + */
>> +if (ret == H_SUCCESS)
>> +return RESUME_HOST;
>>  break;
> 
> The problem with this is that H_SET_MODE isn't just used for setting
> endianness; it also does breakpoint setting (DAWR/X and CIABR), which
> might happen very frequently, so we don't want them being punted up to
> userspace.
> 
> Paul.

Hi Paul,

My mistake, the patch was based on a too old kernel missing yours and
Michael's latest patches on H_SET_MODE handling.

I'll propose a new one asap.

Thanks,
Laurent.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH] powerpc/kernel/sysfs: disable writing to purr in non-powernv

2013-09-27 Thread Benjamin Herrenschmidt
On Fri, 2013-09-27 at 13:32 +0530, Madhavan Srinivasan wrote:
> powerpc/kernel/sysfs.c exports purr with write permission.
> This may be valid for powernv kernel since purr is Hyp resource.
> But writing to the file in PowerVM lpar causes crash.

Testing powernv isn't right, you should test for hypervisor mode.

Cheers,
Ben.

> # echo 0 > purr
> cpu 0x0: Vector: 700 (Program Check) at [c0d072b0]
> pc: c001770c: .write_purr+0x1c/0x40
> lr: c0017708: .write_purr+0x18/0x40
> sp: c0d07530
>msr: 80049032
>   current = 0xc0c53de0
>   paca= 0xcec7 softe: 0irq_happened: 0x01
> pid   = 0, comm = swapper/0
> enter ? for help
> [c0d075b0] c00fba64
> .generic_smp_call_function_single_interrupt+0x104/0x190
> [c0d07650] c0037748 .smp_ipi_demux+0xa8/0xf0
> [c0d076e0] c0035314 .doorbell_exception+0x74/0xb0
> [c0d07760] c0002950 doorbell_super_common+0x150/0x180
> --- Exception: a01 (Doorbell) at c0060904
> .plpar_hcall_norets+0x84/0xd4
> [link register   ] c006dbd4 .check_and_cede_processor+0x24/0x40
> [c0d07a50] c1002558 (unreliable)
> [c0d07ac0] c006dd0c .shared_cede_loop+0x2c/0x70
> [c0d07b40] c06ae954 .cpuidle_enter_state+0x64/0x150
> [c0d07c00] c06aeb30 .cpuidle_idle_call+0xf0/0x300
> [c0d07cb0] c0062fa0 .pseries_lpar_idle+0x10/0x50
> [c0d07d20] c0016d14 .arch_cpu_idle+0x64/0x150
> [c0d07da0] c00e0060 .cpu_startup_entry+0x1a0/0x2c0
> [c0d07e80] c000bca4 .rest_init+0x94/0xb0
> [c0d07ef0] c0b54530 .start_kernel+0x478/0x494
> [c0d07f90] c0009be0 .start_here_common+0x20/0x40
> 0:mon>
> 
> Signed-off-by: Madhavan Srinivasan 
> ---
>  arch/powerpc/kernel/sysfs.c |   19 +--
>  1 file changed, 17 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
> index 27a90b9..d7097c2 100644
> --- a/arch/powerpc/kernel/sysfs.c
> +++ b/arch/powerpc/kernel/sysfs.c
> @@ -179,15 +179,27 @@ SYSFS_PMCSETUP(spurr, SPRN_SPURR);
>  SYSFS_PMCSETUP(dscr, SPRN_DSCR);
>  SYSFS_PMCSETUP(pir, SPRN_PIR);
>  
> +/*
> +  Lets only enable Read for Hyp resources and
> +  enable Write when needed with a separate function.
> +  Lets be conservative and default to pseries.
> +*/
>  static DEVICE_ATTR(mmcra, 0600, show_mmcra, store_mmcra);
>  static DEVICE_ATTR(spurr, 0400, show_spurr, NULL);
>  static DEVICE_ATTR(dscr, 0600, show_dscr, store_dscr);
> -static DEVICE_ATTR(purr, 0600, show_purr, store_purr);
> +static DEVICE_ATTR(purr, 0400, show_purr, store_purr);
>  static DEVICE_ATTR(pir, 0400, show_pir, NULL);
>  
>  unsigned long dscr_default = 0;
>  EXPORT_SYMBOL(dscr_default);
>  
> +static void add_write_permission_dev_attr(void *ptr)
> +{
> + struct device_attribute *attr = (struct device_attribute *)ptr;
> +
> + attr->attr.mode |= (unsigned short) 0200;
> +}
> +
>  static ssize_t show_dscr_default(struct device *dev,
>   struct device_attribute *attr, char *buf)
>  {
> @@ -394,8 +406,11 @@ static void register_cpu_online(unsigned int cpu)
>   if (cpu_has_feature(CPU_FTR_MMCRA))
>   device_create_file(s, &dev_attr_mmcra);
>  
> - if (cpu_has_feature(CPU_FTR_PURR))
> + if (cpu_has_feature(CPU_FTR_PURR)) {
> + if (machine_is(powernv))
> + add_write_permission_dev_attr((void *)&dev_attr_purr);
>   device_create_file(s, &dev_attr_purr);
> + }
>  
>   if (cpu_has_feature(CPU_FTR_SPURR))
>   device_create_file(s, &dev_attr_spurr);


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


[PATCH] powerpc/kernel/sysfs: disable writing to purr in non-powernv

2013-09-27 Thread Madhavan Srinivasan
powerpc/kernel/sysfs.c exports purr with write permission.
This may be valid for powernv kernel since purr is Hyp resource.
But writing to the file in PowerVM lpar causes crash.

# echo 0 > purr
cpu 0x0: Vector: 700 (Program Check) at [c0d072b0]
pc: c001770c: .write_purr+0x1c/0x40
lr: c0017708: .write_purr+0x18/0x40
sp: c0d07530
   msr: 80049032
  current = 0xc0c53de0
  paca= 0xcec7   softe: 0irq_happened: 0x01
pid   = 0, comm = swapper/0
enter ? for help
[c0d075b0] c00fba64
.generic_smp_call_function_single_interrupt+0x104/0x190
[c0d07650] c0037748 .smp_ipi_demux+0xa8/0xf0
[c0d076e0] c0035314 .doorbell_exception+0x74/0xb0
[c0d07760] c0002950 doorbell_super_common+0x150/0x180
--- Exception: a01 (Doorbell) at c0060904
.plpar_hcall_norets+0x84/0xd4
[link register   ] c006dbd4 .check_and_cede_processor+0x24/0x40
[c0d07a50] c1002558 (unreliable)
[c0d07ac0] c006dd0c .shared_cede_loop+0x2c/0x70
[c0d07b40] c06ae954 .cpuidle_enter_state+0x64/0x150
[c0d07c00] c06aeb30 .cpuidle_idle_call+0xf0/0x300
[c0d07cb0] c0062fa0 .pseries_lpar_idle+0x10/0x50
[c0d07d20] c0016d14 .arch_cpu_idle+0x64/0x150
[c0d07da0] c00e0060 .cpu_startup_entry+0x1a0/0x2c0
[c0d07e80] c000bca4 .rest_init+0x94/0xb0
[c0d07ef0] c0b54530 .start_kernel+0x478/0x494
[c0d07f90] c0009be0 .start_here_common+0x20/0x40
0:mon>

Signed-off-by: Madhavan Srinivasan 
---
 arch/powerpc/kernel/sysfs.c |   19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index 27a90b9..d7097c2 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -179,15 +179,27 @@ SYSFS_PMCSETUP(spurr, SPRN_SPURR);
 SYSFS_PMCSETUP(dscr, SPRN_DSCR);
 SYSFS_PMCSETUP(pir, SPRN_PIR);
 
+/*
+  Lets only enable Read for Hyp resources and
+  enable Write when needed with a separate function.
+  Lets be conservative and default to pseries.
+*/
 static DEVICE_ATTR(mmcra, 0600, show_mmcra, store_mmcra);
 static DEVICE_ATTR(spurr, 0400, show_spurr, NULL);
 static DEVICE_ATTR(dscr, 0600, show_dscr, store_dscr);
-static DEVICE_ATTR(purr, 0600, show_purr, store_purr);
+static DEVICE_ATTR(purr, 0400, show_purr, store_purr);
 static DEVICE_ATTR(pir, 0400, show_pir, NULL);
 
 unsigned long dscr_default = 0;
 EXPORT_SYMBOL(dscr_default);
 
+static void add_write_permission_dev_attr(void *ptr)
+{
+   struct device_attribute *attr = (struct device_attribute *)ptr;
+
+   attr->attr.mode |= (unsigned short) 0200;
+}
+
 static ssize_t show_dscr_default(struct device *dev,
struct device_attribute *attr, char *buf)
 {
@@ -394,8 +406,11 @@ static void register_cpu_online(unsigned int cpu)
if (cpu_has_feature(CPU_FTR_MMCRA))
device_create_file(s, &dev_attr_mmcra);
 
-   if (cpu_has_feature(CPU_FTR_PURR))
+   if (cpu_has_feature(CPU_FTR_PURR)) {
+   if (machine_is(powernv))
+   add_write_permission_dev_attr((void *)&dev_attr_purr);
device_create_file(s, &dev_attr_purr);
+   }
 
if (cpu_has_feature(CPU_FTR_SPURR))
device_create_file(s, &dev_attr_spurr);
-- 
1.7.10.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev