* Re: [PATCH 1/5] ibmebus: convert of_platform_driver to platform_driver
From: Rob Herring @ 2013-04-25 20:45 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Roland Dreier, Arnd Bergmann, linux-rdma, netdev,
devicetree-discuss@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Christoph Raisch, Hoang-Nam Nguyen, Thadeu Lima de Souza Cascardo,
Grant Likely, Paul Mackerras, Sean Hefty, linuxppc-dev,
Hal Rosenstock
In-Reply-To: <1366920741.2869.32.camel@pasglop>
On 04/25/2013 03:12 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2013-04-25 at 14:14 -0500, Rob Herring wrote:
>> On 04/25/2013 12:35 PM, Benjamin Herrenschmidt wrote:
[...]
>> You need patch 2 of this series to fix this:
>>
>> driver core: move to_platform_driver to platform_device.h
>>
>> which as Arnd pointed out needs to come first. I've fixed that in my
>> tree, but I don't think it warrants another post.
>
> Can I pull you tree from somewhere to test ?
Here you go:
git://sources.calxeda.com/kernel/linux.git of-platform-removal
Rob
^ permalink raw reply
* RE: [PATCH 1/3] rapidio: make enumeration/discovery configurable
From: Bounine, Alexandre @ 2013-04-25 21:00 UTC (permalink / raw)
To: Andrew Morton
Cc: linuxppc-dev@lists.ozlabs.org, Micha Nelissen,
linux-kernel@vger.kernel.org, Andre van Herk
In-Reply-To: <20130424143714.4911405aa979bff27887765a@linux-foundation.org>
On Wednesday, April 24, 2013 5:37 PM Andrew Morton wrote:
>=20
> On Wed, 24 Apr 2013 10:31:57 -0400 Alexandre Bounine
> <alexandre.bounine@idt.com> wrote:
>=20
> > Rework to implement RapidIO enumeration/discovery method selection
> > combined with ability to use enumeration/discovery as a kernel module.
> >
> > ...
> >
> > @@ -1421,3 +1295,46 @@ enum_done:
> > bail:
> > return -EBUSY;
> > }
> > +
> > +struct rio_scan rio_scan_ops =3D {
> > + .enumerate =3D rio_enum_mport,
> > + .discover =3D rio_disc_mport,
> > +};
> > +
> > +
> > +#ifdef MODULE
>=20
> Why the `ifdef MODULE'? The module parameters are still accessible if
> the driver is statically linked and we do want the driver to behave in
> the same way regardless of how it was linked and loaded.
Marked for review.
> > +static bool scan;
> > +module_param(scan, bool, 0);
> > +MODULE_PARM_DESC(scan, "Start RapidIO network enumeration/discovery
> "
> > + "(default =3D 1)");
> > +
> > +/**
> > + * rio_basic_attach:
> > + *
> > + * When this enumeration/discovery method is loaded as a module this f=
unction
> > + * registers its specific enumeration and discover routines for all av=
ailable
> > + * RapidIO mport devices. The "scan" command line parameter controls a=
bility of
> > + * the module to start RapidIO enumeration/discovery automatically.
> > + *
> > + * Returns 0 for success or -EIO if unable to register itself.
> > + *
> > + * This enumeration/discovery method cannot be unloaded and therefore =
does not
> > + * provide a matching cleanup_module routine.
> > + */
> > +
> > +int __init rio_basic_attach(void)
>=20
> static
My miss. Will fix.
> > +{
> > + if (rio_register_scan(RIO_MPORT_ANY, &rio_scan_ops))
> > + return -EIO;
> > + if (scan)
> > + rio_init_mports();
> > + return 0;
> > +}
> > +
> > +module_init(rio_basic_attach);
> > +
> > +MODULE_DESCRIPTION("Basic RapidIO enumeration/discovery");
> > +MODULE_LICENSE("GPL");
> > +
> > +#endif /* MODULE */
> > diff --git a/drivers/rapidio/rio.c b/drivers/rapidio/rio.c
> > index d553b5d..e36628a 100644
> > --- a/drivers/rapidio/rio.c
> > +++ b/drivers/rapidio/rio.c
> > @@ -31,6 +31,9 @@
> >
> > #include "rio.h"
> >
> > +LIST_HEAD(rio_devices);
>=20
> static?
>=20
> > +DEFINE_SPINLOCK(rio_global_list_lock);
>=20
> static?
These two have been very tempting for me to make them static.
But because a goal was simple code move and they have been visible
from very beginning of RapidIO code, I decided to keep the scope "as is".
While I am against using the device list directly, I am not sure that this
patch is a good place to change the existing scope.
Because keeping them global prompted your comment I will happily make them
static and see if anyone will complain about it.
=20
> > +
> > static LIST_HEAD(rio_mports);
> > static unsigned char next_portid;
> > static DEFINE_SPINLOCK(rio_mmap_lock);
> >
> > ...
> >
> > +/**
> > + * rio_switch_init - Sets switch operations for a particular vendor sw=
itch
> > + * @rdev: RIO device
> > + * @do_enum: Enumeration/Discovery mode flag
> > + *
> > + * Searches the RIO switch ops table for known switch types. If the vi=
d
> > + * and did match a switch table entry, then call switch initialization
> > + * routine to setup switch-specific routines.
> > + */
> > +void rio_switch_init(struct rio_dev *rdev, int do_enum)
> > +{
> > + struct rio_switch_ops *cur =3D __start_rio_switch_ops;
> > + struct rio_switch_ops *end =3D __end_rio_switch_ops;
>=20
> huh, I hadn't noticed that RIO has its very own vmlinux section. How
> peculair.
Yes it is there (since 2.6.15). We will address it at some point later.
At this moment just moving the code from one file to another.
=20
> > + while (cur < end) {
> > + if ((cur->vid =3D=3D rdev->vid) && (cur->did =3D=3D rdev->did)) {
> > + pr_debug("RIO: calling init routine for %s\n",
> > + rio_name(rdev));
> > + cur->init_hook(rdev, do_enum);
> > + break;
> > + }
> > + cur++;
> > + }
> > +
> > + if ((cur >=3D end) && (rdev->pef & RIO_PEF_STD_RT)) {
> > + pr_debug("RIO: adding STD routing ops for %s\n",
> > + rio_name(rdev));
> > + rdev->rswitch->add_entry =3D rio_std_route_add_entry;
> > + rdev->rswitch->get_entry =3D rio_std_route_get_entry;
> > + rdev->rswitch->clr_table =3D rio_std_route_clr_table;
> > + }
> > +
> > + if (!rdev->rswitch->add_entry || !rdev->rswitch->get_entry)
> > + printk(KERN_ERR "RIO: missing routing ops for %s\n",
> > + rio_name(rdev));
> > +}
> > +EXPORT_SYMBOL_GPL(rio_switch_init);
> >
> > ...
> >
> > +int rio_register_scan(int mport_id, struct rio_scan *scan_ops)
> > +{
> > + struct rio_mport *port;
> > + int rc =3D -EBUSY;
> > +
> > + list_for_each_entry(port, &rio_mports, node) {
>=20
> How come the driver has no locking for rio_mports? If a bugfix isn't
> needed here then a code comment is!
Locking is not needed at this moment, but has to be added sooner or later a=
nyway.
I will add it now to avoid fixing it later.=20
=20
> > + if (port->id =3D=3D mport_id || mport_id =3D=3D RIO_MPORT_ANY) {
> > + if (port->nscan && mport_id =3D=3D RIO_MPORT_ANY)
> > + continue;
> > + else if (port->nscan)
> > + break;
> > +
> > + port->nscan =3D scan_ops;
> > + rc =3D 0;
> > +
> > + if (mport_id !=3D RIO_MPORT_ANY)
> > + break;
> > + }
> > + }
> > +
> > + return rc;
> > +}
> >
> > ...
^ permalink raw reply
* Re: [PATCH v2] PowerPC: kernel: compiling issue, make additional room in exception vector area
From: Michael Neuling @ 2013-04-25 23:16 UTC (permalink / raw)
To: Chen Gang
Cc: sfr, matt, linux-kernel, Paul Mackerras, Aneesh Kumar K.V,
Mike Qiu, linuxppc-dev
In-Reply-To: <517918AB.4020508@asianux.com>
Chen Gang <gang.chen@asianux.com> wrote:
>
> When CONFIG_KVM_BOOK3S_64_PR is enabled,
> MASKABLE_EXCEPTION_PSERIES(0x900 ...) will includes __KVMTEST, it will
> exceed 0x980 which STD_EXCEPTION_HV(0x980 ...) will use, it will cause
> compiling issue.
>
> The related errors:
> arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
> arch/powerpc/kernel/exceptions-64s.S:258: Error: attempt to move .org backwards
> make[1]: *** [arch/powerpc/kernel/head_64.o] Error 1
>
> The position 0x900 and 0x980 are solid, so can not move the position
> to make room larger. The final solution is to jump to another area to
> execute the related code.
>
>
> Signed-off-by: Chen Gang <gang.chen@asianux.com>
> ---
> arch/powerpc/kernel/exceptions-64s.S | 12 +++++++++++-
> 1 files changed, 11 insertions(+), 1 deletions(-)
>
> diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
> index e789ee7..8997de2 100644
> --- a/arch/powerpc/kernel/exceptions-64s.S
> +++ b/arch/powerpc/kernel/exceptions-64s.S
> @@ -254,7 +254,11 @@ hardware_interrupt_hv:
> STD_EXCEPTION_PSERIES(0x800, 0x800, fp_unavailable)
> KVM_HANDLER_PR(PACA_EXGEN, EXC_STD, 0x800)
>
> - MASKABLE_EXCEPTION_PSERIES(0x900, 0x900, decrementer)
> + . = 0x900
> + .globl decrementer_pSeries
> +decrementer_pSeries:
> + b decrementer_pSeries_0
> +
Unfortunately you can't do this ether as we need to save the CFAR[1]
before it's overwritten by any branch. MASKABLE_EXCEPTION_PSERIES does
this.
CFAR is the Come From Register. It saves the location of the last
branch and is hence overwritten by any branch.
Thanks for trying.
Mikey
> STD_EXCEPTION_HV(0x980, 0x982, hdecrementer)
>
> MASKABLE_EXCEPTION_PSERIES(0xa00, 0xa00, doorbell_super)
> @@ -536,6 +540,12 @@ ALT_FTR_SECTION_END_IFCLR(CPU_FTR_ARCH_206)
> #endif
>
> .align 7
> + /* moved from 0x900 */
> +decrementer_pSeries_0:
> + _MASKABLE_EXCEPTION_PSERIES(0x900, decrementer,
> + EXC_STD, SOFTEN_TEST_PR)
> +
> + .align 7
> /* moved from 0xe00 */
> STD_EXCEPTION_HV_OOL(0xe02, h_data_storage)
> KVM_HANDLER_SKIP(PACA_EXGEN, EXC_HV, 0xe02)
> --
> 1.7.7.6
>
>
^ permalink raw reply
* why does CONFIG_NONSTATIC_KERNEL affect the boot kernel?
From: Chris Friesen @ 2013-04-25 23:33 UTC (permalink / raw)
To: linuxppc-dev, Benjamin Herrenschmidt, Paul Mackerras
Hi,
Looking at the kdump code for powerpc, I see that if
CONFIG_NONSTATIC_KERNEL is not set then the load address for the capture
kernel is fixed at 32MB.
Why is this?
When using a separate capture kernel I don't see why that should
restrict where I allocate space in the boot kernel.
Chris
--
Chris Friesen
Software Designer
500 Palladium Drive, Suite 2100
Ottawa, Ontario K2N 1C2, Canada
www.genband.com
office:+1.343.883.2717
chris.friesen@genband.com
^ permalink raw reply
* Re: [PATCH v2 12/15] powerpc/85xx: add time base sync support for e6500
From: Scott Wood @ 2013-04-26 0:07 UTC (permalink / raw)
To: Zhao Chenhui; +Cc: linuxppc-dev, linux-kernel, r58472
In-Reply-To: <20130425002818.GE3172@localhost.localdomain>
On 04/24/2013 07:28:18 PM, Zhao Chenhui wrote:
> On Wed, Apr 24, 2013 at 05:38:16PM -0500, Scott Wood wrote:
> > On 04/24/2013 06:29:29 AM, Zhao Chenhui wrote:
> > >On Tue, Apr 23, 2013 at 07:04:06PM -0500, Scott Wood wrote:
> > >> On 04/19/2013 05:47:45 AM, Zhao Chenhui wrote:
> > >> >From: Chen-Hui Zhao <chenhui.zhao@freescale.com>
> > >> >
> > >> >For e6500, two threads in one core share one time base. Just =20
> need
> > >> >to do time base sync on first thread of one core, and skip it on
> > >> >the other thread.
> > >> >
> > >> >Signed-off-by: Zhao Chenhui <chenhui.zhao@freescale.com>
> > >> >Signed-off-by: Li Yang <leoli@freescale.com>
> > >> >Signed-off-by: Andy Fleming <afleming@freescale.com>
> > >> >---
> > >> > arch/powerpc/platforms/85xx/smp.c | 52
> > >> >+++++++++++++++++++++++++++++++-----
> > >> > 1 files changed, 44 insertions(+), 8 deletions(-)
> > >> >
> > >> >diff --git a/arch/powerpc/platforms/85xx/smp.c
> > >> >b/arch/powerpc/platforms/85xx/smp.c
> > >> >index 74d8cde..5f3eee3 100644
> > >> >--- a/arch/powerpc/platforms/85xx/smp.c
> > >> >+++ b/arch/powerpc/platforms/85xx/smp.c
> > >> >@@ -53,26 +55,40 @@ static inline u32 get_phy_cpu_mask(void)
> > >> > u32 mask;
> > >> > int cpu;
> > >> >
> > >> >- mask =3D 1 << cur_booting_core;
> > >> >- for_each_online_cpu(cpu)
> > >> >- mask |=3D 1 << get_hard_smp_processor_id(cpu);
> > >> >+ if (smt_capable()) {
> > >> >+ /* two threads in one core share one time base =20
> */
> > >> >+ mask =3D 1 << =20
> cpu_core_index_of_thread(cur_booting_core);
> > >> >+ for_each_online_cpu(cpu)
> > >> >+ mask |=3D 1 << cpu_core_index_of_thread(
> > >> >+ =20
> get_hard_smp_processor_id(cpu));
> > >> >+ } else {
> > >> >+ mask =3D 1 << cur_booting_core;
> > >> >+ for_each_online_cpu(cpu)
> > >> >+ mask |=3D 1 << =20
> get_hard_smp_processor_id(cpu);
> > >> >+ }
> > >>
> > >> Where is smt_capable defined()? I assume somewhere in the =20
> patchset
> > >> but it's a pain to search 12 patches...
> > >>
> > >
> > >It is defined in arch/powerpc/include/asm/topology.h.
> > > #define smt_capable() (cpu_has_feature(CPU_FTR_SMT))
> > >
> > >Thanks for your review again.
> >
> > We shouldn't base it on CPU_FTR_SMT. For example, e6500 doesn't
> > claim that feature yet, except in our SDK kernel. That doesn't
> > change the topology of CPU numbering.
> >
>=20
> Then, where can I get the thread information? dts?
> Or, wait for upstream of the thread suppport of e6500.
It's an inherent property of e6500 (outside of some virtualization =20
scenarios, but you wouldn't run this code under a hypervisor) that you =20
have two threads per core (whether Linux uses them or not). Or you =20
could read TMCFG0[NTHRD] if you know you're on a chip that has TMRs but =20
aren't positive it's an e6500, but I wouldn't bother. If we do ever =20
have such a chip, there are probably other things that will need =20
updating.
> > >static inline u32 get_phy_cpu_mask(void)
> > >{
> > > u32 mask;
> > > int cpu;
> > >
> > > mask =3D 1 << cpu_core_index_of_thread(cur_booting_core);
> > > for_each_online_cpu(cpu)
> > > mask |=3D 1 << cpu_core_index_of_thread(
> > > get_hard_smp_processor_id(cpu));
> > >
> > > return mask;
> > >}
> >
> > Likewise, this will get it wrong if SMT is disabled or not yet
> > implemented on a core.
> >
> > -Scott
>=20
> Let's look into cpu_core_index_of_thread() in =20
> arch/powerpc/kernel/smp.c.
>=20
> int cpu_core_index_of_thread(int cpu)
> {
> return cpu >> threads_shift;
> }
>=20
> If no thread, the threads_shift is equal to 0. It can work with no
> thread.
My point is that if threads are disabled, threads_shift will be 0, but =20
e6500 cores will still be numbered 0, 2, 4, etc.
> Perhaps, I should submit this patch after the thread patches for =20
> e6500.
Why?
-Scott=
^ permalink raw reply
* Re: [PATCH v2] PowerPC: kernel: compiling issue, make additional room in exception vector area
From: Chen Gang @ 2013-04-26 1:06 UTC (permalink / raw)
To: Michael Neuling
Cc: sfr, matt, linux-kernel, Paul Mackerras, Aneesh Kumar K.V,
Mike Qiu, linuxppc-dev
In-Reply-To: <30269.1366931768@ale.ozlabs.ibm.com>
On 2013年04月26日 07:16, Michael Neuling wrote:
>> > diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
>> > index e789ee7..8997de2 100644
>> > --- a/arch/powerpc/kernel/exceptions-64s.S
>> > +++ b/arch/powerpc/kernel/exceptions-64s.S
>> > @@ -254,7 +254,11 @@ hardware_interrupt_hv:
>> > STD_EXCEPTION_PSERIES(0x800, 0x800, fp_unavailable)
>> > KVM_HANDLER_PR(PACA_EXGEN, EXC_STD, 0x800)
>> >
>> > - MASKABLE_EXCEPTION_PSERIES(0x900, 0x900, decrementer)
>> > + . = 0x900
>> > + .globl decrementer_pSeries
>> > +decrementer_pSeries:
>> > + b decrementer_pSeries_0
>> > +
> Unfortunately you can't do this ether as we need to save the CFAR[1]
> before it's overwritten by any branch. MASKABLE_EXCEPTION_PSERIES does
> this.
>
Thanks for your checking.
> CFAR is the Come From Register. It saves the location of the last
> branch and is hence overwritten by any branch.
>
Do we process it just like others done (e.g. 0x300, 0xe00, 0xe20 ...) ?
. = 0x900
.globl decrementer_pSeries
decrementer_pSeries:
HMT_MEDIUM_PPR_DISCARD
SET_SCRATCH0(r13)
b decrementer_pSeries_0
...
> Thanks for trying.
>
Not at all, before get fixed by other members, I should continue trying.
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* Re: [PATCH v2] PowerPC: kernel: compiling issue, make additional room in exception vector area
From: Chen Gang @ 2013-04-26 1:18 UTC (permalink / raw)
To: Michael Neuling
Cc: sfr, matt, linux-kernel, Paul Mackerras, Aneesh Kumar K.V,
Mike Qiu, linuxppc-dev
In-Reply-To: <5179D302.9060203@asianux.com>
On 2013年04月26日 09:06, Chen Gang wrote:
>> CFAR is the Come From Register. It saves the location of the last
>> > branch and is hence overwritten by any branch.
>> >
> Do we process it just like others done (e.g. 0x300, 0xe00, 0xe20 ...) ?
> . = 0x900
> .globl decrementer_pSeries
> decrementer_pSeries:
> HMT_MEDIUM_PPR_DISCARD
> SET_SCRATCH0(r13)
> b decrementer_pSeries_0
>
> ...
>
>
Such as the fix below, is it OK (just like 0x300 or 0x200 has done) ?
Please check, thanks.
---------------------------diff begin-------------------------------------
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index e789ee7..a0a5ff2 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -254,7 +254,14 @@ hardware_interrupt_hv:
STD_EXCEPTION_PSERIES(0x800, 0x800, fp_unavailable)
KVM_HANDLER_PR(PACA_EXGEN, EXC_STD, 0x800)
- MASKABLE_EXCEPTION_PSERIES(0x900, 0x900, decrementer)
+ . = 0x900
+ .globl decrementer_pSeries
+decrementer_pSeries:
+ HMT_MEDIUM_PPR_DISCARD
+ SET_SCRATCH0(r13) /* save r13 */
+ EXCEPTION_PROLOG_0(PACA_EXGEN)
+ b decrementer_pSeries_0
+
STD_EXCEPTION_HV(0x980, 0x982, hdecrementer)
MASKABLE_EXCEPTION_PSERIES(0xa00, 0xa00, doorbell_super)
@@ -536,6 +543,12 @@ ALT_FTR_SECTION_END_IFCLR(CPU_FTR_ARCH_206)
#endif
.align 7
+ /* moved from 0x900 */
+decrementer_pSeries_0:
+ EXCEPTION_PROLOG_1(PACA_EXGEN, SOFTEN_TEST_PR, 0x900)
+ EXCEPTION_PROLOG_PSERIES_1(decrementer_common, EXC_STD)
+
+ .align 7
/* moved from 0xe00 */
STD_EXCEPTION_HV_OOL(0xe02, h_data_storage)
KVM_HANDLER_SKIP(PACA_EXGEN, EXC_HV, 0xe02)
---------------------------diff end---------------------------------------
--
Chen Gang
Asianux Corporation
^ permalink raw reply related
* [PATCH] powerpc: Fix hardware IRQs with MMU on exceptions when HV=0
From: Michael Neuling @ 2013-04-26 1:30 UTC (permalink / raw)
To: benh; +Cc: Linux PPC dev, Nishanth Aravamudan
POWER8 allows us to take interrupts with the MMU on. This gives us a
second set of vectors offset at 0x4000.
Unfortunately when coping these vectors we missed checking for MSR HV
for hardware interrupts (0x500). This results in us trying to use
HSRR0/1 when HV=0, rather than SRR0/1 on HW IRQs
The below fixes this to check CPU_FTR_HVMODE when patching the code at
0x4500.
Also we remove the check for CPU_FTR_ARCH_206 since relocation on IRQs
are only available in arch 2.07 and beyond.
Thanks to benh for helping find this.
Signed-off-by: Michael Neuling <mikey@neuling.org>
cc: stable@kernel.org
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index 56bd923..3bbe7ed 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -797,7 +797,7 @@ hardware_interrupt_relon_hv:
_MASKABLE_RELON_EXCEPTION_PSERIES(0x502, hardware_interrupt, EXC_HV, SOFTEN_TEST_HV)
FTR_SECTION_ELSE
_MASKABLE_RELON_EXCEPTION_PSERIES(0x500, hardware_interrupt, EXC_STD, SOFTEN_TEST_PR)
- ALT_FTR_SECTION_END_IFSET(CPU_FTR_ARCH_206)
+ ALT_FTR_SECTION_END_IFSET(CPU_FTR_HVMODE)
STD_RELON_EXCEPTION_PSERIES(0x4600, 0x600, alignment)
STD_RELON_EXCEPTION_PSERIES(0x4700, 0x700, program_check)
STD_RELON_EXCEPTION_PSERIES(0x4800, 0x800, fp_unavailable)
^ permalink raw reply related
* Re: [PATCH v2] PowerPC: kernel: compiling issue, make additional room in exception vector area
From: Chen Gang @ 2013-04-26 1:36 UTC (permalink / raw)
To: Michael Neuling
Cc: sfr, matt, linux-kernel, Paul Mackerras, Aneesh Kumar K.V,
Mike Qiu, linuxppc-dev
In-Reply-To: <5179D5D8.8080102@asianux.com>
On 2013年04月26日 09:18, Chen Gang wrote:
> On 2013年04月26日 09:06, Chen Gang wrote:
>>> CFAR is the Come From Register. It saves the location of the last
>>>> branch and is hence overwritten by any branch.
>>>>
>> Do we process it just like others done (e.g. 0x300, 0xe00, 0xe20 ...) ?
>> . = 0x900
>> .globl decrementer_pSeries
>> decrementer_pSeries:
>> HMT_MEDIUM_PPR_DISCARD
>> SET_SCRATCH0(r13)
>> b decrementer_pSeries_0
>>
>> ...
>>
>>
Oh, it seems EXCEPTION_PROLOG_1 will save the regesters which related
with CFAR, so I think need move EXCEPTION_PROLOG_1 to near 0x900.
---------------------------------diff v2 begin-----------------------------
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index e789ee7..f0489c4 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -254,7 +254,15 @@ hardware_interrupt_hv:
STD_EXCEPTION_PSERIES(0x800, 0x800, fp_unavailable)
KVM_HANDLER_PR(PACA_EXGEN, EXC_STD, 0x800)
- MASKABLE_EXCEPTION_PSERIES(0x900, 0x900, decrementer)
+ . = 0x900
+ .globl decrementer_pSeries
+decrementer_pSeries:
+ HMT_MEDIUM_PPR_DISCARD
+ SET_SCRATCH0(r13) /* save r13 */
+ EXCEPTION_PROLOG_0(PACA_EXGEN)
+ EXCEPTION_PROLOG_1(PACA_EXGEN, SOFTEN_TEST_PR, 0x900)
+ b decrementer_pSeries_0
+
STD_EXCEPTION_HV(0x980, 0x982, hdecrementer)
MASKABLE_EXCEPTION_PSERIES(0xa00, 0xa00, doorbell_super)
@@ -536,6 +544,11 @@ ALT_FTR_SECTION_END_IFCLR(CPU_FTR_ARCH_206)
#endif
.align 7
+ /* moved from 0x900 */
+decrementer_pSeries_0:
+ EXCEPTION_PROLOG_PSERIES_1(decrementer_common, EXC_STD)
+
+ .align 7
/* moved from 0xe00 */
STD_EXCEPTION_HV_OOL(0xe02, h_data_storage)
KVM_HANDLER_SKIP(PACA_EXGEN, EXC_HV, 0xe02)
---------------------------------diff v2 end-------------------------------
>
> Such as the fix below, is it OK (just like 0x300 or 0x200 has done) ?
>
> Please check, thanks.
>
> ---------------------------diff begin-------------------------------------
>
> diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
> index e789ee7..a0a5ff2 100644
> --- a/arch/powerpc/kernel/exceptions-64s.S
> +++ b/arch/powerpc/kernel/exceptions-64s.S
> @@ -254,7 +254,14 @@ hardware_interrupt_hv:
> STD_EXCEPTION_PSERIES(0x800, 0x800, fp_unavailable)
> KVM_HANDLER_PR(PACA_EXGEN, EXC_STD, 0x800)
>
> - MASKABLE_EXCEPTION_PSERIES(0x900, 0x900, decrementer)
> + . = 0x900
> + .globl decrementer_pSeries
> +decrementer_pSeries:
> + HMT_MEDIUM_PPR_DISCARD
> + SET_SCRATCH0(r13) /* save r13 */
> + EXCEPTION_PROLOG_0(PACA_EXGEN)
> + b decrementer_pSeries_0
> +
> STD_EXCEPTION_HV(0x980, 0x982, hdecrementer)
>
> MASKABLE_EXCEPTION_PSERIES(0xa00, 0xa00, doorbell_super)
> @@ -536,6 +543,12 @@ ALT_FTR_SECTION_END_IFCLR(CPU_FTR_ARCH_206)
> #endif
>
> .align 7
> + /* moved from 0x900 */
> +decrementer_pSeries_0:
> + EXCEPTION_PROLOG_1(PACA_EXGEN, SOFTEN_TEST_PR, 0x900)
> + EXCEPTION_PROLOG_PSERIES_1(decrementer_common, EXC_STD)
> +
> + .align 7
> /* moved from 0xe00 */
> STD_EXCEPTION_HV_OOL(0xe02, h_data_storage)
> KVM_HANDLER_SKIP(PACA_EXGEN, EXC_HV, 0xe02)
>
> ---------------------------diff end---------------------------------------
>
--
Chen Gang
Asianux Corporation
^ permalink raw reply related
* Re: [PATCH 1/1] kvm:book3e: Fix a build error
From: tiejun.chen @ 2013-04-26 1:53 UTC (permalink / raw)
To: Caraman Mihai Claudiu-B02008
Cc: linuxppc-dev@lists.ozlabs.org, kvm-ppc@vger.kernel.org,
kvm@vger.kernel.org
In-Reply-To: <300B73AA675FCE4A93EB4FC1D42459FF3D9C33@039-SN2MPN1-013.039d.mgd.msft.net>
On 04/25/2013 08:11 PM, Caraman Mihai Claudiu-B02008 wrote:
>> -----Original Message-----
>> From: kvm-ppc-owner@vger.kernel.org [mailto:kvm-ppc-
>> owner@vger.kernel.org] On Behalf Of Tiejun Chen
>> Sent: Thursday, April 25, 2013 2:46 PM
>> To: galak@kernel.crashing.org
>> Cc: linuxppc-dev@lists.ozlabs.org; kvm-ppc@vger.kernel.org;
>> kvm@vger.kernel.org
>> Subject: [PATCH 1/1] kvm:book3e: Fix a build error
>>
>> Commit cd66cc2e, "powerpc/85xx: Add AltiVec support for e6500", adds
>> support for AltiVec on a Book-E class processor, but while compiling
>> in the CONFIG_PPC_BOOK3E_64 and CONFIG_VIRTUALIZATION case, this
>> introduce the following error:
>>
>> arch/powerpc/kernel/exceptions-64e.S:402: undefined reference to
>> `kvmppc_handler_42_0x01B'
>> arch/powerpc/kernel/built-in.o: In function `exc_altivec_assist_book3e':
>> arch/powerpc/kernel/exceptions-64e.S:424: undefined reference to
>> `kvmppc_handler_43_0x01B'
>> make: *** [vmlinux] Error 1
>>
>> Looks we should add these altivec kvm handlers.
>>
>> Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
>> ---
>> arch/powerpc/kvm/bookehv_interrupts.S | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/arch/powerpc/kvm/bookehv_interrupts.S
>> b/arch/powerpc/kvm/bookehv_interrupts.S
>> index e8ed7d6..fa9c78a 100644
>> --- a/arch/powerpc/kvm/bookehv_interrupts.S
>> +++ b/arch/powerpc/kvm/bookehv_interrupts.S
>> @@ -319,6 +319,11 @@ kvm_handler BOOKE_INTERRUPT_DEBUG, EX_PARAMS(DBG), \
>> SPRN_DSRR0, SPRN_DSRR1, 0
>> kvm_handler BOOKE_INTERRUPT_DEBUG, EX_PARAMS(CRIT), \
>> SPRN_CSRR0, SPRN_CSRR1, 0
>> +/* altivec */
>> +kvm_handler BOOKE_INTERRUPT_ALTIVEC_UNAVAIL, EX_PARAMS(GEN), \
>> + SPRN_SRR0, SPRN_SRR1, 0
>> +kvm_handler BOOKE_INTERRUPT_ALTIVEC_ASSIST, EX_PARAMS(GEN), \
>> + SPRN_SRR0, SPRN_SRR1, 0
>> #else
>> /*
>> * For input register values, see
>> arch/powerpc/include/asm/kvm_booke_hv_asm.h
>> --
>
> It seems that you are not using kvm-ppc-queue branch.
This is just used to fix a build error in powerpc.git when introduce commit
cd66cc2e, "powerpc/85xx: Add AltiVec support for e6500", in *powerpc.git* as I
mentioned in this patch head.
>
> I already have a patch ready for this (and AltiVec support is work
This change don't block your AltiVec support for kvm unless you think this
change is wrong. And especially, we always can reproduce this error with/without
enabling AltiVec, so I also don't think this should be suspended until support
e6500 in kvm since kvm based on e5500 should work.
Tiejun
> in progress) but we need first to pull e6500 kernel patches from
> Linux tree into agraf.git.
>
> -Mike
>
>
>
>
>
>
>
>
^ permalink raw reply
* Re: "attempt to move .org backwards" still show up
From: Mike Qiu @ 2013-04-26 1:58 UTC (permalink / raw)
To: Chen Gang
Cc: sfr, Michael Neuling, matt, linux-kernel, Paul Mackerras,
Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <51791076.9040405@asianux.com>
于 2013/4/25 19:16, Chen Gang 写道:
> On 2013年04月25日 14:25, Paul Mackerras wrote:
>> On Thu, Apr 25, 2013 at 12:05:54PM +0800, Mike Qiu wrote:
>>>> This has block my work now
>>>> So I hope you can take a look ASAP
>>>> Thanks
>>>> :)
>>>>
>>>> Mike
>> As a quick fix, turn on CONFIG_KVM_BOOK3S_64_HV. That will eliminate
>> the immediate problem.
> Yes, just as my original reply to Mike to bypass it, but get no reply, I
> guess he has to face the CONFIG_KVM_BOOK3S_64_PR.
>
> Now, I am just fixing it, when I finish one patch, please help check.
Actually, I have compile pass by your patch, but I see Micheal Neuling's
reply,
I just stop to do that, and wait for you new patch :)
Now I will use your V2 patch to build
Thanks
Mike
> Thanks.
>
^ permalink raw reply
* Re: [PATCH v2] PowerPC: kernel: compiling issue, make additional room in exception vector area
From: Mike Qiu @ 2013-04-26 2:03 UTC (permalink / raw)
To: Chen Gang
Cc: sfr, Michael Neuling, matt, linux-kernel, Paul Mackerras,
Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <5179DA23.8000407@asianux.com>
于 2013/4/26 9:36, Chen Gang 写道:
> On 2013年04月26日 09:18, Chen Gang wrote:
>> On 2013年04月26日 09:06, Chen Gang wrote:
>>>> CFAR is the Come From Register. It saves the location of the last
>>>>> branch and is hence overwritten by any branch.
>>>>>
>>> Do we process it just like others done (e.g. 0x300, 0xe00, 0xe20 ...) ?
>>> . = 0x900
>>> .globl decrementer_pSeries
>>> decrementer_pSeries:
>>> HMT_MEDIUM_PPR_DISCARD
>>> SET_SCRATCH0(r13)
>>> b decrementer_pSeries_0
>>>
>>> ...
>>>
>>>
> Oh, it seems EXCEPTION_PROLOG_1 will save the regesters which related
> with CFAR, so I think need move EXCEPTION_PROLOG_1 to near 0x900.
I will try your diff V2, to see if the machine can boot up
> ---------------------------------diff v2 begin-----------------------------
>
> diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
> index e789ee7..f0489c4 100644
> --- a/arch/powerpc/kernel/exceptions-64s.S
> +++ b/arch/powerpc/kernel/exceptions-64s.S
> @@ -254,7 +254,15 @@ hardware_interrupt_hv:
> STD_EXCEPTION_PSERIES(0x800, 0x800, fp_unavailable)
> KVM_HANDLER_PR(PACA_EXGEN, EXC_STD, 0x800)
>
> - MASKABLE_EXCEPTION_PSERIES(0x900, 0x900, decrementer)
> + . = 0x900
> + .globl decrementer_pSeries
> +decrementer_pSeries:
> + HMT_MEDIUM_PPR_DISCARD
> + SET_SCRATCH0(r13) /* save r13 */
> + EXCEPTION_PROLOG_0(PACA_EXGEN)
> + EXCEPTION_PROLOG_1(PACA_EXGEN, SOFTEN_TEST_PR, 0x900)
> + b decrementer_pSeries_0
> +
> STD_EXCEPTION_HV(0x980, 0x982, hdecrementer)
>
> MASKABLE_EXCEPTION_PSERIES(0xa00, 0xa00, doorbell_super)
> @@ -536,6 +544,11 @@ ALT_FTR_SECTION_END_IFCLR(CPU_FTR_ARCH_206)
> #endif
>
> .align 7
> + /* moved from 0x900 */
> +decrementer_pSeries_0:
> + EXCEPTION_PROLOG_PSERIES_1(decrementer_common, EXC_STD)
> +
> + .align 7
> /* moved from 0xe00 */
> STD_EXCEPTION_HV_OOL(0xe02, h_data_storage)
> KVM_HANDLER_SKIP(PACA_EXGEN, EXC_HV, 0xe02)
>
>
> ---------------------------------diff v2 end-------------------------------
>
>
>> Such as the fix below, is it OK (just like 0x300 or 0x200 has done) ?
>>
>> Please check, thanks.
>>
>> ---------------------------diff begin-------------------------------------
>>
>> diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
>> index e789ee7..a0a5ff2 100644
>> --- a/arch/powerpc/kernel/exceptions-64s.S
>> +++ b/arch/powerpc/kernel/exceptions-64s.S
>> @@ -254,7 +254,14 @@ hardware_interrupt_hv:
>> STD_EXCEPTION_PSERIES(0x800, 0x800, fp_unavailable)
>> KVM_HANDLER_PR(PACA_EXGEN, EXC_STD, 0x800)
>>
>> - MASKABLE_EXCEPTION_PSERIES(0x900, 0x900, decrementer)
>> + . = 0x900
>> + .globl decrementer_pSeries
>> +decrementer_pSeries:
>> + HMT_MEDIUM_PPR_DISCARD
>> + SET_SCRATCH0(r13) /* save r13 */
>> + EXCEPTION_PROLOG_0(PACA_EXGEN)
>> + b decrementer_pSeries_0
>> +
>> STD_EXCEPTION_HV(0x980, 0x982, hdecrementer)
>>
>> MASKABLE_EXCEPTION_PSERIES(0xa00, 0xa00, doorbell_super)
>> @@ -536,6 +543,12 @@ ALT_FTR_SECTION_END_IFCLR(CPU_FTR_ARCH_206)
>> #endif
>>
>> .align 7
>> + /* moved from 0x900 */
>> +decrementer_pSeries_0:
>> + EXCEPTION_PROLOG_1(PACA_EXGEN, SOFTEN_TEST_PR, 0x900)
>> + EXCEPTION_PROLOG_PSERIES_1(decrementer_common, EXC_STD)
>> +
>> + .align 7
>> /* moved from 0xe00 */
>> STD_EXCEPTION_HV_OOL(0xe02, h_data_storage)
>> KVM_HANDLER_SKIP(PACA_EXGEN, EXC_HV, 0xe02)
>>
>> ---------------------------diff end---------------------------------------
>>
>
^ permalink raw reply
* Re: "attempt to move .org backwards" still show up
From: Chen Gang @ 2013-04-26 2:05 UTC (permalink / raw)
To: Mike Qiu
Cc: sfr, Michael Neuling, matt, linux-kernel, Paul Mackerras,
Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <5179DF37.8020407@linux.vnet.ibm.com>
On 2013年04月26日 09:58, Mike Qiu wrote:
> 于 2013/4/25 19:16, Chen Gang 写道:
>> On 2013年04月25日 14:25, Paul Mackerras wrote:
>>> On Thu, Apr 25, 2013 at 12:05:54PM +0800, Mike Qiu wrote:
>>>>> This has block my work now
>>>>> So I hope you can take a look ASAP
>>>>> Thanks
>>>>> :)
>>>>>
>>>>> Mike
>>> As a quick fix, turn on CONFIG_KVM_BOOK3S_64_HV. That will eliminate
>>> the immediate problem.
>> Yes, just as my original reply to Mike to bypass it, but get no reply, I
>> guess he has to face the CONFIG_KVM_BOOK3S_64_PR.
>>
>> Now, I am just fixing it, when I finish one patch, please help check.
> Actually, I have compile pass by your patch, but I see Micheal Neuling's
> reply,
> I just stop to do that, and wait for you new patch :)
>
I am just continuing (before get fixed, I should continue)
> Now I will use your V2 patch to build
Please see the discussion of patch v2, it still has another issues, but
I am still trying (I guess Michael is just checking).
:-)
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* Re: [PATCH v2] PowerPC: kernel: compiling issue, make additional room in exception vector area
From: Chen Gang @ 2013-04-26 2:06 UTC (permalink / raw)
To: Mike Qiu
Cc: sfr, Michael Neuling, matt, linux-kernel, Paul Mackerras,
Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <5179E056.2000709@linux.vnet.ibm.com>
On 2013年04月26日 10:03, Mike Qiu wrote:
> �� 2013/4/26 9:36, Chen Gang �:
>> > On 2013��04��26�� 09:18, Chen Gang wrote:
>>> >> On 2013��04��26�� 09:06, Chen Gang wrote:
>>>>> >>>> CFAR is the Come From Register. It saves the location of the last
>>>>>> >>>>> branch and is hence overwritten by any branch.
>>>>>> >>>>>
>>>> >>> Do we process it just like others done (e.g. 0x300, 0xe00, 0xe20 ...) ?
>>>> >>> . = 0x900
>>>> >>> .globl decrementer_pSeries
>>>> >>> decrementer_pSeries:
>>>> >>> HMT_MEDIUM_PPR_DISCARD
>>>> >>> SET_SCRATCH0(r13)
>>>> >>> b decrementer_pSeries_0
>>>> >>>
>>>> >>> ...
>>>> >>>
>>>> >>>
>> > Oh, it seems EXCEPTION_PROLOG_1 will save the regesters which related
>> > with CFAR, so I think need move EXCEPTION_PROLOG_1 to near 0x900.
> I will try your diff V2, to see if the machine can boot up
OK, thanks. (hope it can work)
:-)
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* RE: [PATCH 1/2] powerpc: Move opcode definitions from kvm/emulate.c to asm/ppc-opcode.h
From: Jia Hongtao-B38951 @ 2013-04-26 2:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1366777161.2869.0.camel@pasglop>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmVuamFtaW4gSGVycmVu
c2NobWlkdCBbbWFpbHRvOmJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZ10NCj4gU2VudDogV2VkbmVz
ZGF5LCBBcHJpbCAyNCwgMjAxMyAxMjoxOSBQTQ0KPiBUbzogSmlhIEhvbmd0YW8tQjM4OTUxDQo+
IENjOiBNaWNoYWVsIEVsbGVybWFuOyBXb29kIFNjb3R0LUIwNzQyMTsgbGludXhwcGMtZGV2QGxp
c3RzLm96bGFicy5vcmcNCj4gU3ViamVjdDogUmU6IFtQQVRDSCAxLzJdIHBvd2VycGM6IE1vdmUg
b3Bjb2RlIGRlZmluaXRpb25zIGZyb20NCj4ga3ZtL2VtdWxhdGUuYyB0byBhc20vcHBjLW9wY29k
ZS5oDQo+IA0KPiBPbiBUdWUsIDIwMTMtMDQtMjMgYXQgMDY6MzYgKzAwMDAsIEppYSBIb25ndGFv
LUIzODk1MSB3cm90ZToNCj4gPiBUaGVzZSBkZWZpbml0aW9ucyBhcmUgZmlyc3RseSB1c2VkIGJ5
IEtWTSBkZWZpbmVkIGxpa2UgT1BfMzFfWE9QX1RSQVAuDQo+ID4gVHdvIHdheXMgdG8gZXh0cmFj
dCB0aGVzZSBkZWZpbml0aW9ucyBmb3IgcHVibGljIHVzZToNCj4gPg0KPiA+IDEuIExpa2UgdGhp
cyBwYXRjaCBkaWQuIEZvciBrZWVwaW5nIHRoZSBLVk0gY29kZSB0aGF0IHVzaW5nIHRoZXNlDQo+
ID4gICAgZGVmaW5pdGlvbnMgdW5jaGFuZ2VkIHdlIGRvIG5vdCB1cGRhdGUgdGhlbSB0byBtYXRj
aC4NCj4gPg0KPiA+IDIuIE1vdmUgdGhlc2UgZGVmaW5pdGlvbnMgdG8gYW5vdGhlciAuaCBmaWxl
IGxpa2UgbXkgbGFzdCBwYXRjaCBkaWQ6DQo+ID4gICAgaHR0cDovL3BhdGNod29yay5vemxhYnMu
b3JnL3BhdGNoLzIzNTY0Ni8NCj4gPiAgICBZb3UgY2FuIHNlZSB0aGUgY29tbWVudHMgdGhlcmUu
DQo+IA0KPiBUaGVyZSdzIGEgYmV0dGVyIHdheSAuLi4gYnV0IGl0J3MgbW9yZSB3b3JrLg0KPiAN
Cj4gQWxsIG9wY29kZXMgYXJlIGJhc2VkIG9uIGEgcHJpbWFyeSBvcGNvZGUgYW5kIGEgcG90ZW50
aWFsIHNlY29uZGFyeQ0KPiBvcGNvZGUuIFlvdSBjb3VsZC9zaG91bGQgcmV3b3JrIHBwYy1vcGNv
ZGVzLmggdG8gaW4gZmFjdCBkZWZpbmUgdGhlbQ0KPiBhbGwgdGhhdCB3YXkgYXMgd2VsbCwgd2hp
Y2ggd291bGQgInJlY29uY2lsZSIgdGhlIEtWTSB3YXkgYW5kIHRoZQ0KPiBleGlzdGluZyBzdHVm
Zi4NCj4gDQo+IENoZWVycywNCj4gQmVuLg0KPiANCg0KQWdyZWUuIEJ1dCBJJ20gYWZyYWlkIHRv
IHNheSB0aGF0IEknbSB0b28gYnVzeSB0byBkbyB0aGlzICJtb3JlIHdvcmsiDQpyaWdodCBub3cu
IENvdWxkIHdlIGRlZmVyIHRoaXMgd29yayBmb3Igc29tZSB0aW1lPw0KDQpUaGFua3MuDQotIEhv
bmd0YW8NCg==
^ permalink raw reply
* Re: [PATCH v4 2/13] Correct buffer parsing in update_dt_node()
From: Stephen Rothwell @ 2013-04-26 3:01 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linuxppc-dev
In-Reply-To: <5177FF10.4000508@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 893 bytes --]
Hi Nathan,
On Wed, 24 Apr 2013 10:49:36 -0500 Nathan Fontenot <nfont@linux.vnet.ibm.com> wrote:
>
> @@ -134,6 +134,7 @@
> char *prop_data;
> char *rtas_buf;
> int update_properties_token;
> + u32 vd;
>
> update_properties_token = rtas_token("ibm,update-properties");
> if (update_properties_token == RTAS_UNKNOWN_SERVICE)
> @@ -160,13 +161,24 @@
>
> prop_data = rtas_buf + sizeof(*upwa);
>
> - for (i = 0; i < upwa->nprops; i++) {
> + /* The first element of the buffer is the path of the node
> + * being updated in the form of a 8 byte string length
^^^^
"bit" ?
> + * followed by the string. Skip past this to get to the
> + * properties being updated.
> + */
> + vd = *prop_data++;
> + prop_data += vd;
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v4 5/13] Use ARRAY_SIZE to iterate over firmware_features_table array
From: Stephen Rothwell @ 2013-04-26 3:08 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linuxppc-dev
In-Reply-To: <5178005C.1070204@linux.vnet.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 986 bytes --]
Hi Nathan,
On Wed, 24 Apr 2013 10:55:08 -0500 Nathan Fontenot <nfont@linux.vnet.ibm.com> wrote:
>
> When iterating over the entries in firmware_features_table we only need
> to go over the actual number of entries in the array instead of declaring
> it to be bigger and checking to make sure there is a valid entry in every
> slot.
>
> This patch removes the FIRMWARE_MAX_FEATURES #define and replaces the
> array looping with the use of ARRAY_SIZE().
>
Suggested-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Nathan Fontenot <nfont@linux.vnet.ibm.com>
> @@ -77,12 +77,10 @@
> pr_debug(" -> fw_feature_init()\n");
>
> for (s = hypertas; s < hypertas + len; s += strlen(s) + 1) {
> - for (i = 0; i < FIRMWARE_MAX_FEATURES; i++) {
> + for (i = 0; i < ARRAY_SIZE(firmware_features_table); i++) {
You should explicitly include linux/kernel.h to use ARRAY_SIZE().
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2] PowerPC: kernel: compiling issue, make additional room in exception vector area
From: Mike Qiu @ 2013-04-26 3:08 UTC (permalink / raw)
To: Chen Gang
Cc: sfr, Michael Neuling, matt, linux-kernel, Paul Mackerras,
Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <5179E11F.8010007@asianux.com>
于 2013/4/26 10:06, Chen Gang 写道:
> On 2013年04月26日 10:03, Mike Qiu wrote:
>> �� 2013/4/26 9:36, Chen Gang �:
>>>> On 2013��04��26�� 09:18, Chen Gang wrote:
>>>>>> On 2013��04��26�� 09:06, Chen Gang wrote:
>>>>>>>>>> CFAR is the Come From Register. It saves the location of the last
>>>>>>>>>>>> branch and is hence overwritten by any branch.
>>>>>>>>>>>>
>>>>>>>> Do we process it just like others done (e.g. 0x300, 0xe00, 0xe20 ...) ?
>>>>>>>> . = 0x900
>>>>>>>> .globl decrementer_pSeries
>>>>>>>> decrementer_pSeries:
>>>>>>>> HMT_MEDIUM_PPR_DISCARD
>>>>>>>> SET_SCRATCH0(r13)
>>>>>>>> b decrementer_pSeries_0
>>>>>>>>
>>>>>>>> ...
>>>>>>>>
>>>>>>>>
>>>> Oh, it seems EXCEPTION_PROLOG_1 will save the regesters which related
>>>> with CFAR, so I think need move EXCEPTION_PROLOG_1 to near 0x900.
>> I will try your diff V2, to see if the machine can boot up
> OK, thanks. (hope it can work)
It seems that the machine can be bootup in powernv mode, but I'm not
sure if my machine call that module.
At lease my machine can boot up
Thanks
Mike
>
> :-)
>
^ permalink raw reply
* Re: [PATCH V4 0/5] powerpc, perf: BHRB based branch stack enablement on POWER8
From: Michael Neuling @ 2013-04-26 3:11 UTC (permalink / raw)
To: Anshuman Khandual; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1366695764-3073-1-git-send-email-khandual@linux.vnet.ibm.com>
Anshuman,
IIRC there are new bits in the FSCR and HFSCR you need to enable for the
PMU and BRHB. Can you please check these are enabled?
Mikey
Anshuman Khandual <khandual@linux.vnet.ibm.com> wrote:
> Branch History Rolling Buffer (BHRB) is a new PMU feaure in IBM
> POWER8 processor which records the branch instructions inside the execution
> pipeline. This patchset enables the basic functionality of the feature through
> generic perf branch stack sampling framework.
>
> Sample output
> -------------
> $./perf record -b top
> $./perf report
>
> Overhead Command Source Shared Object Source Symbol Target Shared Object Target Symbol
> # ........ ....... .................... ...................................... .................... ...................................
> #
>
> 7.82% top libc-2.11.2.so [k] _IO_vfscanf libc-2.11.2.so [k] _IO_vfscanf
> 6.17% top libc-2.11.2.so [k] _IO_vfscanf [unknown] [k] 00000000
> 2.37% top [unknown] [k] 0xf7aafb30 [unknown] [k] 00000000
> 1.80% top [unknown] [k] 0x0fe07978 libc-2.11.2.so [k] _IO_vfscanf
> 1.60% top libc-2.11.2.so [k] _IO_vfscanf [kernel.kallsyms] [k] .do_task_stat
> 1.20% top [kernel.kallsyms] [k] .do_task_stat [kernel.kallsyms] [k] .do_task_stat
> 1.02% top libc-2.11.2.so [k] vfprintf libc-2.11.2.so [k] vfprintf
> 0.92% top top [k] _init [unknown] [k] 0x0fe037f4
>
> Changes in V2
> --------------
> - Added copyright messages to the newly created files
> - Modified couple of commit messages
>
> Changes in V3
> -------------
> - Incorporated review comments from Segher https://lkml.org/lkml/2013/4/16/350
> - Worked on a solution for review comment from Michael Ellerman https://lkml.org/lkml/2013/4/17/548
> - Could not move updated cpu_hw_events structure from core-book3s.c file into perf_event_server.h
> Because perf_event_server.h is pulled in first inside linux/perf_event.h before the definition of
> perf_branch_entry structure. Thats the reason why perf_branch_entry definition is not available
> inside perf_event_server.h where we define the array inside cpu_hw_events structure.
>
> - Finally have pulled in the code from perf_event_bhrb.c into core-book3s.c
>
> - Improved documentation for the patchset
>
> Changes in V4
> -------------
> - Incorporated review comments on V3 regarding new instruction encoding
>
> Anshuman Khandual (5):
> powerpc, perf: Add new BHRB related instructions for POWER8
> powerpc, perf: Add basic assembly code to read BHRB entries on POWER8
> powerpc, perf: Add new BHRB related generic functions, data and flags
> powerpc, perf: Define BHRB generic functions, data and flags for POWER8
> powerpc, perf: Enable branch stack sampling framework
>
> arch/powerpc/include/asm/perf_event_server.h | 7 ++
> arch/powerpc/include/asm/ppc-opcode.h | 8 ++
> arch/powerpc/perf/Makefile | 2 +-
> arch/powerpc/perf/bhrb.S | 44 +++++++
> arch/powerpc/perf/core-book3s.c | 167 ++++++++++++++++++++++++++-
> arch/powerpc/perf/power8-pmu.c | 57 ++++++++-
> 6 files changed, 280 insertions(+), 5 deletions(-)
> create mode 100644 arch/powerpc/perf/bhrb.S
>
> --
> 1.7.11.7
>
^ permalink raw reply
* Re: "attempt to move .org backwards" still show up
From: Mike Qiu @ 2013-04-26 3:19 UTC (permalink / raw)
To: Paul Mackerras
Cc: sfr, Michael Neuling, matt, Chen Gang, linux-kernel,
Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <20130425062539.GA421@iris.ozlabs.ibm.com>
于 2013/4/25 14:25, Paul Mackerras 写道:
> On Thu, Apr 25, 2013 at 12:05:54PM +0800, Mike Qiu wrote:
>> This has block my work now
>> So I hope you can take a look ASAP
>> Thanks
>> :)
>>
>> Mike
> As a quick fix, turn on CONFIG_KVM_BOOK3S_64_HV. That will eliminate
> the immediate problem.
Thanks
got it, I will have a try.
> Paul.
>
^ permalink raw reply
* Re: [PATCH v2] PowerPC: kernel: compiling issue, make additional room in exception vector area
From: Chen Gang @ 2013-04-26 3:25 UTC (permalink / raw)
To: Mike Qiu
Cc: sfr, Michael Neuling, matt, linux-kernel, Paul Mackerras,
Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <5179EFB6.3090602@linux.vnet.ibm.com>
On 2013年04月26日 11:08, Mike Qiu wrote:
> 于 2013/4/26 10:06, Chen Gang 写道:
>> On 2013年04月26日 10:03, Mike Qiu wrote:
>>> �� 2013/4/26 9:36, Chen Gang �:
>>>>> On 2013��04��26�� 09:18, Chen Gang wrote:
>>>>>>> On 2013��04��26�� 09:06, Chen Gang wrote:
>>>>>>>>>>> CFAR is the Come From Register. It saves the location of the
>>>>>>>>>>> last
>>>>>>>>>>>>> branch and is hence overwritten by any branch.
>>>>>>>>>>>>>
>>>>>>>>> Do we process it just like others done (e.g. 0x300, 0xe00,
>>>>>>>>> 0xe20 ...) ?
>>>>>>>>> . = 0x900
>>>>>>>>> .globl decrementer_pSeries
>>>>>>>>> decrementer_pSeries:
>>>>>>>>> HMT_MEDIUM_PPR_DISCARD
>>>>>>>>> SET_SCRATCH0(r13)
>>>>>>>>> b decrementer_pSeries_0
>>>>>>>>>
>>>>>>>>> ...
>>>>>>>>>
>>>>>>>>>
>>>>> Oh, it seems EXCEPTION_PROLOG_1 will save the regesters which related
>>>>> with CFAR, so I think need move EXCEPTION_PROLOG_1 to near 0x900.
>>> I will try your diff V2, to see if the machine can boot up
>> OK, thanks. (hope it can work)
> It seems that the machine can be bootup in powernv mode, but I'm not
> sure if my machine call that module.
>
> At lease my machine can boot up
Thank you for your information !
I have checked the disassemble by powerpc64-linux-gnu-objdump, it seems
all we have done for 0x900 is almost like the original done for 0x200.
I am just learning about the CFAR (google it), And I plan to wait for a
day, if all things go smoothly, I will send patch v3.
:-)
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* Re: [PATCH v2] PowerPC: kernel: compiling issue, make additional room in exception vector area
From: Chen Gang @ 2013-04-26 3:42 UTC (permalink / raw)
To: Mike Qiu
Cc: sfr, Michael Neuling, matt, linux-kernel, Paul Mackerras,
Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <5179F39C.5020408@asianux.com>
On 2013年04月26日 11:25, Chen Gang wrote:
> On 2013年04月26日 11:08, Mike Qiu wrote:
>> 于 2013/4/26 10:06, Chen Gang 写道:
>>> On 2013年04月26日 10:03, Mike Qiu wrote:
>>>> �� 2013/4/26 9:36, Chen Gang �:
>>>>>> On 2013��04��26�� 09:18, Chen Gang wrote:
>>>>>>>> On 2013��04��26�� 09:06, Chen Gang wrote:
>>>>>>>>>>>> CFAR is the Come From Register. It saves the location of the
>>>>>>>>>>>> last
>>>>>>>>>>>>>> branch and is hence overwritten by any branch.
>>>>>>>>>>>>>>
>>>>>>>>>> Do we process it just like others done (e.g. 0x300, 0xe00,
>>>>>>>>>> 0xe20 ...) ?
>>>>>>>>>> . = 0x900
>>>>>>>>>> .globl decrementer_pSeries
>>>>>>>>>> decrementer_pSeries:
>>>>>>>>>> HMT_MEDIUM_PPR_DISCARD
>>>>>>>>>> SET_SCRATCH0(r13)
>>>>>>>>>> b decrementer_pSeries_0
>>>>>>>>>>
>>>>>>>>>> ...
>>>>>>>>>>
>>>>>>>>>>
>>>>>> Oh, it seems EXCEPTION_PROLOG_1 will save the regesters which related
>>>>>> with CFAR, so I think need move EXCEPTION_PROLOG_1 to near 0x900.
>>>> I will try your diff V2, to see if the machine can boot up
>>> OK, thanks. (hope it can work)
>> It seems that the machine can be bootup in powernv mode, but I'm not
>> sure if my machine call that module.
>>
>> At lease my machine can boot up
>
Please reference commit number: 1707dd161349e6c54170c88d94fed012e3d224e3
(1707dd1 powerpc: Save CFAR before branching in interrupt entry paths)
What our diff v2 has done is just the fix for our patch v2 (just like
the commit 1707dd1 has done).
Please check, thanks.
:-)
> Thank you for your information !
>
> I have checked the disassemble by powerpc64-linux-gnu-objdump, it seems
> all we have done for 0x900 is almost like the original done for 0x200.
>
> I am just learning about the CFAR (google it), And I plan to wait for a
> day, if all things go smoothly, I will send patch v3.
>
>
> :-)
>
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* [PATCH] powerpc: Fix "attempt to move .org backwards" error
From: Paul Mackerras @ 2013-04-26 3:51 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Chen Gang, Mike Qiu
Building a 64-bit powerpc kernel with PR KVM enabled currently gives
this error:
AS arch/powerpc/kernel/head_64.o
arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
arch/powerpc/kernel/exceptions-64s.S:258: Error: attempt to move .org backwards
make[2]: *** [arch/powerpc/kernel/head_64.o] Error 1
This happens because the MASKABLE_EXCEPTION_PSERIES macro turns into
33 instructions, but we only have space for 32 at the decrementer
interrupt vector (from 0x900 to 0x980).
In the code generated by the MASKABLE_EXCEPTION_PSERIES macro, we
currently have two instances of the HMT_MEDIUM macro, which has the
effect of setting the SMT thread priority to medium. One is the
first instruction, and is overwritten by a no-op on processors where
we save the PPR (processor priority register), that is, POWER7 or
later. The other is after we have saved the PPR.
In order to reduce the code at 0x900 by one instruction, we omit the
first HMT_MEDIUM. On processors without SMT this will have no effect
since HMT_MEDIUM is a no-op there. On POWER5 and RS64 machines this
will mean that the first few instructions take a little longer in the
case where a decrementer interrupt occurs when the hardware thread is
running at low SMT priority. On POWER6 and later machines, the
hardware automatically boosts the thread priority when a decrementer
interrupt is taken if the thread priority was below medium, so this
change won't make any difference.
The alternative would be to branch out of line after saving the CFAR.
However, that would incur an extra overhead on all processors, whereas
the approach adopted here only adds overhead on older threaded processors.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
arch/powerpc/include/asm/exception-64s.h | 2 +-
arch/powerpc/kernel/exceptions-64s.S | 7 ++++++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h
index 05e6d2e..8e5fae8 100644
--- a/arch/powerpc/include/asm/exception-64s.h
+++ b/arch/powerpc/include/asm/exception-64s.h
@@ -414,7 +414,6 @@ label##_relon_hv: \
#define SOFTEN_NOTEST_HV(vec) _SOFTEN_TEST(EXC_HV, vec)
#define __MASKABLE_EXCEPTION_PSERIES(vec, label, h, extra) \
- HMT_MEDIUM_PPR_DISCARD; \
SET_SCRATCH0(r13); /* save r13 */ \
EXCEPTION_PROLOG_0(PACA_EXGEN); \
__EXCEPTION_PROLOG_1(PACA_EXGEN, extra, vec); \
@@ -427,6 +426,7 @@ label##_relon_hv: \
. = loc; \
.globl label##_pSeries; \
label##_pSeries: \
+ HMT_MEDIUM_PPR_DISCARD; \
_MASKABLE_EXCEPTION_PSERIES(vec, label, \
EXC_STD, SOFTEN_TEST_PR)
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index 56bd923..574db3f 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -235,6 +235,7 @@ instruction_access_slb_pSeries:
.globl hardware_interrupt_hv;
hardware_interrupt_pSeries:
hardware_interrupt_hv:
+ HMT_MEDIUM_PPR_DISCARD
BEGIN_FTR_SECTION
_MASKABLE_EXCEPTION_PSERIES(0x502, hardware_interrupt,
EXC_HV, SOFTEN_TEST_HV)
@@ -254,7 +255,11 @@ hardware_interrupt_hv:
STD_EXCEPTION_PSERIES(0x800, 0x800, fp_unavailable)
KVM_HANDLER_PR(PACA_EXGEN, EXC_STD, 0x800)
- MASKABLE_EXCEPTION_PSERIES(0x900, 0x900, decrementer)
+ . = 0x900
+ .globl decrementer_pSeries
+decrementer_pSeries:
+ _MASKABLE_EXCEPTION_PSERIES(0x900, decrementer, EXC_STD, SOFTEN_TEST_PR)
+
STD_EXCEPTION_HV(0x980, 0x982, hdecrementer)
MASKABLE_EXCEPTION_PSERIES(0xa00, 0xa00, doorbell_super)
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH v2] PowerPC: kernel: compiling issue, make additional room in exception vector area
From: Mike Qiu @ 2013-04-26 3:54 UTC (permalink / raw)
To: Chen Gang
Cc: sfr, Michael Neuling, matt, linux-kernel, Paul Mackerras,
Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <5179F7B8.5010701@asianux.com>
于 2013/4/26 11:42, Chen Gang 写道:
> On 2013年04月26日 11:25, Chen Gang wrote:
>> On 2013年04月26日 11:08, Mike Qiu wrote:
>>> 于 2013/4/26 10:06, Chen Gang 写道:
>>>> On 2013年04月26日 10:03, Mike Qiu wrote:
>>>>> �� 2013/4/26 9:36, Chen Gang �:
>>>>>>> On 2013��04��26�� 09:18, Chen Gang wrote:
>>>>>>>>> On 2013��04��26�� 09:06, Chen Gang wrote:
>>>>>>>>>>>>> CFAR is the Come From Register. It saves the location of the
>>>>>>>>>>>>> last
>>>>>>>>>>>>>>> branch and is hence overwritten by any branch.
>>>>>>>>>>>>>>>
>>>>>>>>>>> Do we process it just like others done (e.g. 0x300, 0xe00,
>>>>>>>>>>> 0xe20 ...) ?
>>>>>>>>>>> . = 0x900
>>>>>>>>>>> .globl decrementer_pSeries
>>>>>>>>>>> decrementer_pSeries:
>>>>>>>>>>> HMT_MEDIUM_PPR_DISCARD
>>>>>>>>>>> SET_SCRATCH0(r13)
>>>>>>>>>>> b decrementer_pSeries_0
>>>>>>>>>>>
>>>>>>>>>>> ...
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>> Oh, it seems EXCEPTION_PROLOG_1 will save the regesters which related
>>>>>>> with CFAR, so I think need move EXCEPTION_PROLOG_1 to near 0x900.
>>>>> I will try your diff V2, to see if the machine can boot up
>>>> OK, thanks. (hope it can work)
>>> It seems that the machine can be bootup in powernv mode, but I'm not
>>> sure if my machine call that module.
>>>
>>> At lease my machine can boot up
> Please reference commit number: 1707dd161349e6c54170c88d94fed012e3d224e3
> (1707dd1 powerpc: Save CFAR before branching in interrupt entry paths)
>
> What our diff v2 has done is just the fix for our patch v2 (just like
> the commit 1707dd1 has done).
>
> Please check, thanks.
>
> :-)
I will check this evening or tomorrow, I have something else to do this
afteroon.
>> Thank you for your information !
>>
>> I have checked the disassemble by powerpc64-linux-gnu-objdump, it seems
>> all we have done for 0x900 is almost like the original done for 0x200.
>>
>> I am just learning about the CFAR (google it), And I plan to wait for a
>> day, if all things go smoothly, I will send patch v3.
>>
>>
>> :-)
>>
>
^ permalink raw reply
* Re: [PATCH] powerpc: Fix "attempt to move .org backwards" error
From: Chen Gang @ 2013-04-26 4:13 UTC (permalink / raw)
To: Paul Mackerras, Mike Qiu
Cc: linuxppc-dev, Michael Neuling, sfr@canb.auug.org.au
In-Reply-To: <20130426035140.GA5796@drongo>
On 2013年04月26日 11:51, Paul Mackerras wrote:
> Building a 64-bit powerpc kernel with PR KVM enabled currently gives
> this error:
>
> AS arch/powerpc/kernel/head_64.o
> arch/powerpc/kernel/exceptions-64s.S: Assembler messages:
> arch/powerpc/kernel/exceptions-64s.S:258: Error: attempt to move .org backwards
> make[2]: *** [arch/powerpc/kernel/head_64.o] Error 1
>
> This happens because the MASKABLE_EXCEPTION_PSERIES macro turns into
> 33 instructions, but we only have space for 32 at the decrementer
> interrupt vector (from 0x900 to 0x980).
>
> In the code generated by the MASKABLE_EXCEPTION_PSERIES macro, we
> currently have two instances of the HMT_MEDIUM macro, which has the
> effect of setting the SMT thread priority to medium. One is the
> first instruction, and is overwritten by a no-op on processors where
> we save the PPR (processor priority register), that is, POWER7 or
> later. The other is after we have saved the PPR.
>
> In order to reduce the code at 0x900 by one instruction, we omit the
> first HMT_MEDIUM. On processors without SMT this will have no effect
> since HMT_MEDIUM is a no-op there. On POWER5 and RS64 machines this
> will mean that the first few instructions take a little longer in the
> case where a decrementer interrupt occurs when the hardware thread is
> running at low SMT priority. On POWER6 and later machines, the
> hardware automatically boosts the thread priority when a decrementer
> interrupt is taken if the thread priority was below medium, so this
> change won't make any difference.
>
> The alternative would be to branch out of line after saving the CFAR.
> However, that would incur an extra overhead on all processors, whereas
> the approach adopted here only adds overhead on older threaded processors.
>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> ---
Hello Mike:
Please try Paul's patch, firstly.
:-)
Thanks.
> arch/powerpc/include/asm/exception-64s.h | 2 +-
> arch/powerpc/kernel/exceptions-64s.S | 7 ++++++-
> 2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/exception-64s.h b/arch/powerpc/include/asm/exception-64s.h
> index 05e6d2e..8e5fae8 100644
> --- a/arch/powerpc/include/asm/exception-64s.h
> +++ b/arch/powerpc/include/asm/exception-64s.h
> @@ -414,7 +414,6 @@ label##_relon_hv: \
> #define SOFTEN_NOTEST_HV(vec) _SOFTEN_TEST(EXC_HV, vec)
>
> #define __MASKABLE_EXCEPTION_PSERIES(vec, label, h, extra) \
> - HMT_MEDIUM_PPR_DISCARD; \
> SET_SCRATCH0(r13); /* save r13 */ \
> EXCEPTION_PROLOG_0(PACA_EXGEN); \
> __EXCEPTION_PROLOG_1(PACA_EXGEN, extra, vec); \
> @@ -427,6 +426,7 @@ label##_relon_hv: \
> . = loc; \
> .globl label##_pSeries; \
> label##_pSeries: \
> + HMT_MEDIUM_PPR_DISCARD; \
> _MASKABLE_EXCEPTION_PSERIES(vec, label, \
> EXC_STD, SOFTEN_TEST_PR)
>
> diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
> index 56bd923..574db3f 100644
> --- a/arch/powerpc/kernel/exceptions-64s.S
> +++ b/arch/powerpc/kernel/exceptions-64s.S
> @@ -235,6 +235,7 @@ instruction_access_slb_pSeries:
> .globl hardware_interrupt_hv;
> hardware_interrupt_pSeries:
> hardware_interrupt_hv:
> + HMT_MEDIUM_PPR_DISCARD
> BEGIN_FTR_SECTION
> _MASKABLE_EXCEPTION_PSERIES(0x502, hardware_interrupt,
> EXC_HV, SOFTEN_TEST_HV)
> @@ -254,7 +255,11 @@ hardware_interrupt_hv:
> STD_EXCEPTION_PSERIES(0x800, 0x800, fp_unavailable)
> KVM_HANDLER_PR(PACA_EXGEN, EXC_STD, 0x800)
>
> - MASKABLE_EXCEPTION_PSERIES(0x900, 0x900, decrementer)
> + . = 0x900
> + .globl decrementer_pSeries
> +decrementer_pSeries:
> + _MASKABLE_EXCEPTION_PSERIES(0x900, decrementer, EXC_STD, SOFTEN_TEST_PR)
> +
> STD_EXCEPTION_HV(0x980, 0x982, hdecrementer)
>
> MASKABLE_EXCEPTION_PSERIES(0xa00, 0xa00, doorbell_super)
>
--
Chen Gang
Asianux Corporation
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox