* Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: tiejun.chen @ 2013-05-09 8:04 UTC (permalink / raw)
To: Bhushan Bharat-R65777
Cc: Caraman Mihai Claudiu-B02008, kvm@vger.kernel.org,
Wood Scott-B07421, agraf@suse.de, kvm-ppc@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D0700E563@039-SN2MPN1-011.039d.mgd.msft.net>
On 05/09/2013 03:51 PM, Bhushan Bharat-R65777 wrote:
>
>
>> -----Original Message-----
>> From: tiejun.chen [mailto:tiejun.chen@windriver.com]
>> Sent: Thursday, May 09, 2013 1:18 PM
>> To: Bhushan Bharat-R65777
>> Cc: Caraman Mihai Claudiu-B02008; Wood Scott-B07421; linuxppc-
>> dev@lists.ozlabs.org; agraf@suse.de; kvm-ppc@vger.kernel.org;
>> kvm@vger.kernel.org
>> Subject: Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
>>
>> On 05/09/2013 03:33 PM, Bhushan Bharat-R65777 wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Linuxppc-dev [mailto:linuxppc-dev-
>>>> bounces+bharat.bhushan=freescale.com@lists.ozlabs.org] On Behalf Of
>>>> bounces+Caraman
>>>> Mihai Claudiu-B02008
>>>> Sent: Wednesday, May 08, 2013 6:44 PM
>>>> To: Wood Scott-B07421; tiejun.chen
>>>> Cc: linuxppc-dev@lists.ozlabs.org; agraf@suse.de;
>>>> kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
>>>> Subject: RE: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable
>>>> interrupts
>>>>
>>>>>> This only disable soft interrupt for kvmppc_restart_interrupt()
>>>>>> that restarts interrupts if they were meant for the host:
>>>>>>
>>>>>> a. SOFT_DISABLE_INTS() only for BOOKE_INTERRUPT_EXTERNAL |
>>>>>> BOOKE_INTERRUPT_DECREMENTER | BOOKE_INTERRUPT_DOORBELL
>>>>>
>>>>> Those aren't the only exceptions that can end up going to the host.
>>>>> We could get a TLB miss that results in a heavyweight MMIO exit, etc.
>>>>>
>>>>>> And shouldn't we handle kvmppc_restart_interrupt() like the
>>>>>> original HOST flow?
>>>>>>
>>>>>> #define MASKABLE_EXCEPTION(trapnum, intnum, label, hdlr,
>>>>>> ack) \
>>>>>>
>>>>>> START_EXCEPTION(label); \
>>>>>> NORMAL_EXCEPTION_PROLOG(trapnum, intnum,
>>>>>> PROLOG_ADDITION_MASKABLE)\
>>>>>> EXCEPTION_COMMON(trapnum, PACA_EXGEN,
>>>>>> *INTS_DISABLE*) \
>>>>>> ...
>>>>>
>>>>> Could you elaborate on what you mean?
>>>>
>>>> I think Tiejun was saying that host has flags and replays only
>>>> EE/DEC/DBELL interrupts. There is special macro
>>>> masked_interrupt_book3e in those exception handlers that sets paca-
>>> irq_happened.
>>>>
>>>> The list of replied interrupts is limited to asynchronous noncritical
>>>> interrupts which can be masked by MSR[EE] (therefore no TLB miss).
>>>
>>> Embedded Perfmon interrupt is also asynchronous, Why that is not in the list
>> of masked interruts.
>>
>> Are you saying perfmon? If so, its also in that list:
>>
>> START_EXCEPTION(perfmon);
>> NORMAL_EXCEPTION_PROLOG(0x260, BOOKE_INTERRUPT_PERFORMANCE_MONITOR,
>> PROLOG_ADDITION_NONE)
>> EXCEPTION_COMMON(0x260, PACA_EXGEN, INTS_DISABLE)
>
> Where it is recorded in paca->irq_happned to be replayed later ?
In stead of PROLOG_ADDITION_MASKABLE, actually we have nothing to do with
PROLOG_ADDITION_NONE for perfmon, so perfmon can be executed without lazy state.
Tiejun
>
>>
>> Tiejun
>>
>>>
>>> -Bharat
>>>
>>>> Now on KVM book3e we
>>>> don't want to put them in the irq_happened lazy state but rather to
>>>> execute them directly, so there is no reason for exception handling
>>>> symmetry between host and guest.
>>>>
>>>> -Mike
>>
>
^ permalink raw reply
* Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: Kevin Hao @ 2013-05-09 8:08 UTC (permalink / raw)
To: Bhushan Bharat-R65777
Cc: Wood Scott-B07421, kvm@vger.kernel.org,
Caraman Mihai Claudiu-B02008, agraf@suse.de,
kvm-ppc@vger.kernel.org, tiejun.chen,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D0700E563@039-SN2MPN1-011.039d.mgd.msft.net>
[-- Attachment #1: Type: text/plain, Size: 4122 bytes --]
On Thu, May 09, 2013 at 07:51:09AM +0000, Bhushan Bharat-R65777 wrote:
>
>
> > -----Original Message-----
> > From: tiejun.chen [mailto:tiejun.chen@windriver.com]
> > Sent: Thursday, May 09, 2013 1:18 PM
> > To: Bhushan Bharat-R65777
> > Cc: Caraman Mihai Claudiu-B02008; Wood Scott-B07421; linuxppc-
> > dev@lists.ozlabs.org; agraf@suse.de; kvm-ppc@vger.kernel.org;
> > kvm@vger.kernel.org
> > Subject: Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
> >
> > On 05/09/2013 03:33 PM, Bhushan Bharat-R65777 wrote:
> > >
> > >
> > >> -----Original Message-----
> > >> From: Linuxppc-dev [mailto:linuxppc-dev-
> > >> bounces+bharat.bhushan=freescale.com@lists.ozlabs.org] On Behalf Of
> > >> bounces+Caraman
> > >> Mihai Claudiu-B02008
> > >> Sent: Wednesday, May 08, 2013 6:44 PM
> > >> To: Wood Scott-B07421; tiejun.chen
> > >> Cc: linuxppc-dev@lists.ozlabs.org; agraf@suse.de;
> > >> kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
> > >> Subject: RE: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable
> > >> interrupts
> > >>
> > >>>> This only disable soft interrupt for kvmppc_restart_interrupt()
> > >>>> that restarts interrupts if they were meant for the host:
> > >>>>
> > >>>> a. SOFT_DISABLE_INTS() only for BOOKE_INTERRUPT_EXTERNAL |
> > >>>> BOOKE_INTERRUPT_DECREMENTER | BOOKE_INTERRUPT_DOORBELL
> > >>>
> > >>> Those aren't the only exceptions that can end up going to the host.
> > >>> We could get a TLB miss that results in a heavyweight MMIO exit, etc.
> > >>>
> > >>>> And shouldn't we handle kvmppc_restart_interrupt() like the
> > >>>> original HOST flow?
> > >>>>
> > >>>> #define MASKABLE_EXCEPTION(trapnum, intnum, label, hdlr,
> > >>>> ack) \
> > >>>>
> > >>>> START_EXCEPTION(label); \
> > >>>> NORMAL_EXCEPTION_PROLOG(trapnum, intnum,
> > >>>> PROLOG_ADDITION_MASKABLE)\
> > >>>> EXCEPTION_COMMON(trapnum, PACA_EXGEN,
> > >>>> *INTS_DISABLE*) \
> > >>>> ...
> > >>>
> > >>> Could you elaborate on what you mean?
> > >>
> > >> I think Tiejun was saying that host has flags and replays only
> > >> EE/DEC/DBELL interrupts. There is special macro
> > >> masked_interrupt_book3e in those exception handlers that sets paca-
> > >irq_happened.
> > >>
> > >> The list of replied interrupts is limited to asynchronous noncritical
> > >> interrupts which can be masked by MSR[EE] (therefore no TLB miss).
> > >
> > > Embedded Perfmon interrupt is also asynchronous, Why that is not in the list
> > of masked interruts.
> >
> > Are you saying perfmon? If so, its also in that list:
> >
> > START_EXCEPTION(perfmon);
> > NORMAL_EXCEPTION_PROLOG(0x260, BOOKE_INTERRUPT_PERFORMANCE_MONITOR,
> > PROLOG_ADDITION_NONE)
> > EXCEPTION_COMMON(0x260, PACA_EXGEN, INTS_DISABLE)
>
> Where it is recorded in paca->irq_happned to be replayed later ?
Actually we don't want replay the perfmon interrupt later. We would run it
even soft irq is disabled and just treat it as NMI. Please see the following
function quoted from arch/powerpc/perf/core-fsl-emb.c:
/*
* If interrupts were soft-disabled when a PMU interrupt occurs, treat
* it as an NMI.
*/
static inline int perf_intr_is_nmi(struct pt_regs *regs)
{
#ifdef __powerpc64__
return !regs->softe;
#else
return 0;
#endif
}
Thanks,
Kevin
>
> >
> > Tiejun
> >
> > >
> > > -Bharat
> > >
> > >> Now on KVM book3e we
> > >> don't want to put them in the irq_happened lazy state but rather to
> > >> execute them directly, so there is no reason for exception handling
> > >> symmetry between host and guest.
> > >>
> > >> -Mike
> >
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* RE: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: Bhushan Bharat-R65777 @ 2013-05-09 8:12 UTC (permalink / raw)
To: Kevin Hao
Cc: Wood Scott-B07421, kvm@vger.kernel.org,
Caraman Mihai Claudiu-B02008, agraf@suse.de,
kvm-ppc@vger.kernel.org, tiejun.chen,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20130509080813.GD2263@pek-khao-d1.corp.ad.wrs.com>
> -----Original Message-----
> From: Kevin Hao [mailto:haokexin@gmail.com]
> Sent: Thursday, May 09, 2013 1:38 PM
> To: Bhushan Bharat-R65777
> Cc: tiejun.chen; Caraman Mihai Claudiu-B02008; kvm@vger.kernel.org; Wood =
Scott-
> B07421; agraf@suse.de; kvm-ppc@vger.kernel.org; linuxppc-dev@lists.ozlabs=
.org
> Subject: Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interru=
pts
>=20
> On Thu, May 09, 2013 at 07:51:09AM +0000, Bhushan Bharat-R65777 wrote:
> >
> >
> > > -----Original Message-----
> > > From: tiejun.chen [mailto:tiejun.chen@windriver.com]
> > > Sent: Thursday, May 09, 2013 1:18 PM
> > > To: Bhushan Bharat-R65777
> > > Cc: Caraman Mihai Claudiu-B02008; Wood Scott-B07421; linuxppc-
> > > dev@lists.ozlabs.org; agraf@suse.de; kvm-ppc@vger.kernel.org;
> > > kvm@vger.kernel.org
> > > Subject: Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable
> > > interrupts
> > >
> > > On 05/09/2013 03:33 PM, Bhushan Bharat-R65777 wrote:
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: Linuxppc-dev [mailto:linuxppc-dev-
> > > >> bounces+bharat.bhushan=3Dfreescale.com@lists.ozlabs.org] On Behalf
> > > >> bounces+Of Caraman
> > > >> Mihai Claudiu-B02008
> > > >> Sent: Wednesday, May 08, 2013 6:44 PM
> > > >> To: Wood Scott-B07421; tiejun.chen
> > > >> Cc: linuxppc-dev@lists.ozlabs.org; agraf@suse.de;
> > > >> kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
> > > >> Subject: RE: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable
> > > >> interrupts
> > > >>
> > > >>>> This only disable soft interrupt for kvmppc_restart_interrupt()
> > > >>>> that restarts interrupts if they were meant for the host:
> > > >>>>
> > > >>>> a. SOFT_DISABLE_INTS() only for BOOKE_INTERRUPT_EXTERNAL |
> > > >>>> BOOKE_INTERRUPT_DECREMENTER | BOOKE_INTERRUPT_DOORBELL
> > > >>>
> > > >>> Those aren't the only exceptions that can end up going to the hos=
t.
> > > >>> We could get a TLB miss that results in a heavyweight MMIO exit, =
etc.
> > > >>>
> > > >>>> And shouldn't we handle kvmppc_restart_interrupt() like the
> > > >>>> original HOST flow?
> > > >>>>
> > > >>>> #define MASKABLE_EXCEPTION(trapnum, intnum, label, hdlr,
> > > >>>> ack) \
> > > >>>>
> > > >>>> START_EXCEPTION(label); =
\
> > > >>>> NORMAL_EXCEPTION_PROLOG(trapnum, intnum,
> > > >>>> PROLOG_ADDITION_MASKABLE)\
> > > >>>> EXCEPTION_COMMON(trapnum, PACA_EXGEN,
> > > >>>> *INTS_DISABLE*) \
> > > >>>> ...
> > > >>>
> > > >>> Could you elaborate on what you mean?
> > > >>
> > > >> I think Tiejun was saying that host has flags and replays only
> > > >> EE/DEC/DBELL interrupts. There is special macro
> > > >> masked_interrupt_book3e in those exception handlers that sets
> > > >> paca-
> > > >irq_happened.
> > > >>
> > > >> The list of replied interrupts is limited to asynchronous
> > > >> noncritical interrupts which can be masked by MSR[EE] (therefore n=
o TLB
> miss).
> > > >
> > > > Embedded Perfmon interrupt is also asynchronous, Why that is not
> > > > in the list
> > > of masked interruts.
> > >
> > > Are you saying perfmon? If so, its also in that list:
> > >
> > > START_EXCEPTION(perfmon);
> > > NORMAL_EXCEPTION_PROLOG(0x260, BOOKE_INTERRUPT_PERFORMANCE_M=
ONITOR,
> > > PROLOG_ADDITION_NONE)
> > > EXCEPTION_COMMON(0x260, PACA_EXGEN, INTS_DISABLE)
> >
> > Where it is recorded in paca->irq_happned to be replayed later ?
>=20
> Actually we don't want replay the perfmon interrupt later. We would run i=
t even
> soft irq is disabled and just treat it as NMI. Please see the following f=
unction
> quoted from arch/powerpc/perf/core-fsl-emb.c:
> /*
> * If interrupts were soft-disabled when a PMU interrupt occurs, treat
> * it as an NMI.
> */
> static inline int perf_intr_is_nmi(struct pt_regs *regs)
> {
> #ifdef __powerpc64__
> return !regs->softe;
> #else
> return 0;
> #endif
> }
Is it because that we cannot afford to lose perfmon interrupt for more accu=
rate capturing of data ?
-Bharat
>=20
> Thanks,
> Kevin
>=20
> >
> > >
> > > Tiejun
> > >
> > > >
> > > > -Bharat
> > > >
> > > >> Now on KVM book3e we
> > > >> don't want to put them in the irq_happened lazy state but rather
> > > >> to execute them directly, so there is no reason for exception
> > > >> handling symmetry between host and guest.
> > > >>
> > > >> -Mike
> > >
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: tiejun.chen @ 2013-05-09 8:17 UTC (permalink / raw)
To: Bhushan Bharat-R65777
Cc: Caraman Mihai Claudiu-B02008, Kevin Hao, kvm@vger.kernel.org,
Wood Scott-B07421, agraf@suse.de, kvm-ppc@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D0700E5F5@039-SN2MPN1-011.039d.mgd.msft.net>
On 05/09/2013 04:12 PM, Bhushan Bharat-R65777 wrote:
>
>
>> -----Original Message-----
>> From: Kevin Hao [mailto:haokexin@gmail.com]
>> Sent: Thursday, May 09, 2013 1:38 PM
>> To: Bhushan Bharat-R65777
>> Cc: tiejun.chen; Caraman Mihai Claudiu-B02008; kvm@vger.kernel.org; Wood Scott-
>> B07421; agraf@suse.de; kvm-ppc@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
>> Subject: Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
>>
>> On Thu, May 09, 2013 at 07:51:09AM +0000, Bhushan Bharat-R65777 wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: tiejun.chen [mailto:tiejun.chen@windriver.com]
>>>> Sent: Thursday, May 09, 2013 1:18 PM
>>>> To: Bhushan Bharat-R65777
>>>> Cc: Caraman Mihai Claudiu-B02008; Wood Scott-B07421; linuxppc-
>>>> dev@lists.ozlabs.org; agraf@suse.de; kvm-ppc@vger.kernel.org;
>>>> kvm@vger.kernel.org
>>>> Subject: Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable
>>>> interrupts
>>>>
>>>> On 05/09/2013 03:33 PM, Bhushan Bharat-R65777 wrote:
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Linuxppc-dev [mailto:linuxppc-dev-
>>>>>> bounces+bharat.bhushan=freescale.com@lists.ozlabs.org] On Behalf
>>>>>> bounces+Of Caraman
>>>>>> Mihai Claudiu-B02008
>>>>>> Sent: Wednesday, May 08, 2013 6:44 PM
>>>>>> To: Wood Scott-B07421; tiejun.chen
>>>>>> Cc: linuxppc-dev@lists.ozlabs.org; agraf@suse.de;
>>>>>> kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
>>>>>> Subject: RE: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable
>>>>>> interrupts
>>>>>>
>>>>>>>> This only disable soft interrupt for kvmppc_restart_interrupt()
>>>>>>>> that restarts interrupts if they were meant for the host:
>>>>>>>>
>>>>>>>> a. SOFT_DISABLE_INTS() only for BOOKE_INTERRUPT_EXTERNAL |
>>>>>>>> BOOKE_INTERRUPT_DECREMENTER | BOOKE_INTERRUPT_DOORBELL
>>>>>>>
>>>>>>> Those aren't the only exceptions that can end up going to the host.
>>>>>>> We could get a TLB miss that results in a heavyweight MMIO exit, etc.
>>>>>>>
>>>>>>>> And shouldn't we handle kvmppc_restart_interrupt() like the
>>>>>>>> original HOST flow?
>>>>>>>>
>>>>>>>> #define MASKABLE_EXCEPTION(trapnum, intnum, label, hdlr,
>>>>>>>> ack) \
>>>>>>>>
>>>>>>>> START_EXCEPTION(label); \
>>>>>>>> NORMAL_EXCEPTION_PROLOG(trapnum, intnum,
>>>>>>>> PROLOG_ADDITION_MASKABLE)\
>>>>>>>> EXCEPTION_COMMON(trapnum, PACA_EXGEN,
>>>>>>>> *INTS_DISABLE*) \
>>>>>>>> ...
>>>>>>>
>>>>>>> Could you elaborate on what you mean?
>>>>>>
>>>>>> I think Tiejun was saying that host has flags and replays only
>>>>>> EE/DEC/DBELL interrupts. There is special macro
>>>>>> masked_interrupt_book3e in those exception handlers that sets
>>>>>> paca-
>>>>> irq_happened.
>>>>>>
>>>>>> The list of replied interrupts is limited to asynchronous
>>>>>> noncritical interrupts which can be masked by MSR[EE] (therefore no TLB
>> miss).
>>>>>
>>>>> Embedded Perfmon interrupt is also asynchronous, Why that is not
>>>>> in the list
>>>> of masked interruts.
>>>>
>>>> Are you saying perfmon? If so, its also in that list:
>>>>
>>>> START_EXCEPTION(perfmon);
>>>> NORMAL_EXCEPTION_PROLOG(0x260, BOOKE_INTERRUPT_PERFORMANCE_MONITOR,
>>>> PROLOG_ADDITION_NONE)
>>>> EXCEPTION_COMMON(0x260, PACA_EXGEN, INTS_DISABLE)
>>>
>>> Where it is recorded in paca->irq_happned to be replayed later ?
>>
>> Actually we don't want replay the perfmon interrupt later. We would run it even
>> soft irq is disabled and just treat it as NMI. Please see the following function
>> quoted from arch/powerpc/perf/core-fsl-emb.c:
>> /*
>> * If interrupts were soft-disabled when a PMU interrupt occurs, treat
>> * it as an NMI.
>> */
>> static inline int perf_intr_is_nmi(struct pt_regs *regs)
>> {
>> #ifdef __powerpc64__
>> return !regs->softe;
>> #else
>> return 0;
>> #endif
>> }
>
> Is it because that we cannot afford to lose perfmon interrupt for more accurate capturing of data ?
powerpc/perf: e500 support
This implements perf_event support for the Freescale embedded performance
monitor, based on the existing perf_event.c that supports server/classic
chips.
Some limitations:
- Performance monitor interrupts are regular EE interrupts, and thus you
can't profile places with interrupts disabled. We may want to implement
soft IRQ-disabling, with perfmon interrupts exempted and treated as NMIs.
Tiejun
>
> -Bharat
>
>>
>> Thanks,
>> Kevin
>>
>>>
>>>>
>>>> Tiejun
>>>>
>>>>>
>>>>> -Bharat
>>>>>
>>>>>> Now on KVM book3e we
>>>>>> don't want to put them in the irq_happened lazy state but rather
>>>>>> to execute them directly, so there is no reason for exception
>>>>>> handling symmetry between host and guest.
>>>>>>
>>>>>> -Mike
>>>>
>>>
>>> _______________________________________________
>>> Linuxppc-dev mailing list
>>> Linuxppc-dev@lists.ozlabs.org
>>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
>
^ permalink raw reply
* Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: Kevin Hao @ 2013-05-09 8:21 UTC (permalink / raw)
To: Bhushan Bharat-R65777
Cc: Wood Scott-B07421, kvm@vger.kernel.org,
Caraman Mihai Claudiu-B02008, agraf@suse.de,
kvm-ppc@vger.kernel.org, tiejun.chen,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D0700E5F5@039-SN2MPN1-011.039d.mgd.msft.net>
[-- Attachment #1: Type: text/plain, Size: 5141 bytes --]
On Thu, May 09, 2013 at 08:12:51AM +0000, Bhushan Bharat-R65777 wrote:
>
>
> > -----Original Message-----
> > From: Kevin Hao [mailto:haokexin@gmail.com]
> > Sent: Thursday, May 09, 2013 1:38 PM
> > To: Bhushan Bharat-R65777
> > Cc: tiejun.chen; Caraman Mihai Claudiu-B02008; kvm@vger.kernel.org; Wood Scott-
> > B07421; agraf@suse.de; kvm-ppc@vger.kernel.org; linuxppc-dev@lists.ozlabs.org
> > Subject: Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
> >
> > On Thu, May 09, 2013 at 07:51:09AM +0000, Bhushan Bharat-R65777 wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: tiejun.chen [mailto:tiejun.chen@windriver.com]
> > > > Sent: Thursday, May 09, 2013 1:18 PM
> > > > To: Bhushan Bharat-R65777
> > > > Cc: Caraman Mihai Claudiu-B02008; Wood Scott-B07421; linuxppc-
> > > > dev@lists.ozlabs.org; agraf@suse.de; kvm-ppc@vger.kernel.org;
> > > > kvm@vger.kernel.org
> > > > Subject: Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable
> > > > interrupts
> > > >
> > > > On 05/09/2013 03:33 PM, Bhushan Bharat-R65777 wrote:
> > > > >
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: Linuxppc-dev [mailto:linuxppc-dev-
> > > > >> bounces+bharat.bhushan=freescale.com@lists.ozlabs.org] On Behalf
> > > > >> bounces+Of Caraman
> > > > >> Mihai Claudiu-B02008
> > > > >> Sent: Wednesday, May 08, 2013 6:44 PM
> > > > >> To: Wood Scott-B07421; tiejun.chen
> > > > >> Cc: linuxppc-dev@lists.ozlabs.org; agraf@suse.de;
> > > > >> kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
> > > > >> Subject: RE: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable
> > > > >> interrupts
> > > > >>
> > > > >>>> This only disable soft interrupt for kvmppc_restart_interrupt()
> > > > >>>> that restarts interrupts if they were meant for the host:
> > > > >>>>
> > > > >>>> a. SOFT_DISABLE_INTS() only for BOOKE_INTERRUPT_EXTERNAL |
> > > > >>>> BOOKE_INTERRUPT_DECREMENTER | BOOKE_INTERRUPT_DOORBELL
> > > > >>>
> > > > >>> Those aren't the only exceptions that can end up going to the host.
> > > > >>> We could get a TLB miss that results in a heavyweight MMIO exit, etc.
> > > > >>>
> > > > >>>> And shouldn't we handle kvmppc_restart_interrupt() like the
> > > > >>>> original HOST flow?
> > > > >>>>
> > > > >>>> #define MASKABLE_EXCEPTION(trapnum, intnum, label, hdlr,
> > > > >>>> ack) \
> > > > >>>>
> > > > >>>> START_EXCEPTION(label); \
> > > > >>>> NORMAL_EXCEPTION_PROLOG(trapnum, intnum,
> > > > >>>> PROLOG_ADDITION_MASKABLE)\
> > > > >>>> EXCEPTION_COMMON(trapnum, PACA_EXGEN,
> > > > >>>> *INTS_DISABLE*) \
> > > > >>>> ...
> > > > >>>
> > > > >>> Could you elaborate on what you mean?
> > > > >>
> > > > >> I think Tiejun was saying that host has flags and replays only
> > > > >> EE/DEC/DBELL interrupts. There is special macro
> > > > >> masked_interrupt_book3e in those exception handlers that sets
> > > > >> paca-
> > > > >irq_happened.
> > > > >>
> > > > >> The list of replied interrupts is limited to asynchronous
> > > > >> noncritical interrupts which can be masked by MSR[EE] (therefore no TLB
> > miss).
> > > > >
> > > > > Embedded Perfmon interrupt is also asynchronous, Why that is not
> > > > > in the list
> > > > of masked interruts.
> > > >
> > > > Are you saying perfmon? If so, its also in that list:
> > > >
> > > > START_EXCEPTION(perfmon);
> > > > NORMAL_EXCEPTION_PROLOG(0x260, BOOKE_INTERRUPT_PERFORMANCE_MONITOR,
> > > > PROLOG_ADDITION_NONE)
> > > > EXCEPTION_COMMON(0x260, PACA_EXGEN, INTS_DISABLE)
> > >
> > > Where it is recorded in paca->irq_happned to be replayed later ?
> >
> > Actually we don't want replay the perfmon interrupt later. We would run it even
> > soft irq is disabled and just treat it as NMI. Please see the following function
> > quoted from arch/powerpc/perf/core-fsl-emb.c:
> > /*
> > * If interrupts were soft-disabled when a PMU interrupt occurs, treat
> > * it as an NMI.
> > */
> > static inline int perf_intr_is_nmi(struct pt_regs *regs)
> > {
> > #ifdef __powerpc64__
> > return !regs->softe;
> > #else
> > return 0;
> > #endif
> > }
>
> Is it because that we cannot afford to lose perfmon interrupt for more accurate capturing of data ?
Yes, I think this will definitely improve the perf sample quality.
Thanks,
Kevin
>
> -Bharat
>
> >
> > Thanks,
> > Kevin
> >
> > >
> > > >
> > > > Tiejun
> > > >
> > > > >
> > > > > -Bharat
> > > > >
> > > > >> Now on KVM book3e we
> > > > >> don't want to put them in the irq_happened lazy state but rather
> > > > >> to execute them directly, so there is no reason for exception
> > > > >> handling symmetry between host and guest.
> > > > >>
> > > > >> -Mike
> > > >
> > >
> > > _______________________________________________
> > > Linuxppc-dev mailing list
> > > Linuxppc-dev@lists.ozlabs.org
> > > https://lists.ozlabs.org/listinfo/linuxppc-dev
>
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* RE: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: Bhushan Bharat-R65777 @ 2013-05-09 8:23 UTC (permalink / raw)
To: Caraman Mihai Claudiu-B02008, Wood Scott-B07421, tiejun.chen
Cc: linuxppc-dev@lists.ozlabs.org, agraf@suse.de,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
In-Reply-To: <300B73AA675FCE4A93EB4FC1D42459FF3F00D0@039-SN2MPN1-013.039d.mgd.msft.net>
> -----Original Message-----
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+bharat.bhushan=3Dfreescale.com@lists.ozlabs.org] On Behalf Of Car=
aman
> Mihai Claudiu-B02008
> Sent: Wednesday, May 08, 2013 6:44 PM
> To: Wood Scott-B07421; tiejun.chen
> Cc: linuxppc-dev@lists.ozlabs.org; agraf@suse.de; kvm-ppc@vger.kernel.org=
;
> kvm@vger.kernel.org
> Subject: RE: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interru=
pts
>=20
> > > This only disable soft interrupt for kvmppc_restart_interrupt() that
> > > restarts interrupts if they were meant for the host:
> > >
> > > a. SOFT_DISABLE_INTS() only for BOOKE_INTERRUPT_EXTERNAL |
> > > BOOKE_INTERRUPT_DECREMENTER | BOOKE_INTERRUPT_DOORBELL
> >
> > Those aren't the only exceptions that can end up going to the host.
> > We could get a TLB miss that results in a heavyweight MMIO exit, etc.
> >
> > > And shouldn't we handle kvmppc_restart_interrupt() like the original
> > > HOST flow?
> > >
> > > #define MASKABLE_EXCEPTION(trapnum, intnum, label, hdlr,
> > > ack) \
> > >
> > > START_EXCEPTION(label); \
> > > NORMAL_EXCEPTION_PROLOG(trapnum, intnum,
> > > PROLOG_ADDITION_MASKABLE)\
> > > EXCEPTION_COMMON(trapnum, PACA_EXGEN,
> > > *INTS_DISABLE*) \
> > > ...
> >
> > Could you elaborate on what you mean?
>=20
> I think Tiejun was saying that host has flags and replays only EE/DEC/DBE=
LL
> interrupts. There is special macro masked_interrupt_book3e in those excep=
tion
> handlers that sets paca->irq_happened.
>=20
> The list of replied interrupts is limited to asynchronous noncritical int=
errupts
> which can be masked by MSR[EE] (therefore no TLB miss). Now on KVM book3e=
we
> don't want to put them in the irq_happened lazy state but rather to execu=
te them
> directly, so there is no reason for exception handling symmetry between h=
ost and
> guest.
Another Question:=20
The case is:=20
Case 1)
-> Local_irq_disable() will set soft_enabled =3D 0
-> Now Externel interrupt happens, there we set PACA_IRQ_EE in irq_happene=
d, Also clears EE in SRR1 and rfi. So interrupts are hard disabled. No more=
other interrupt gated by MSR.EE can happen. Looks like the idea here is to=
not let a device keep on inserting interrupt till the interrupt condition =
on device is cleared, right?
-> local_irq_enable() - This checks that irq_happened is set, and replays
Now the case 2)
Case 2)
-> Local_irq_disable() will set soft_enabled =3D 0
-> Now DEC interrupt happens. We set PACA_IRQ_DEC in irq_happened, But do =
not clear EE in SRR1 and rfi. So interrupts are not hard disabled.=20
-> Now say EE interrupt happens, there we set PACA_IRQ_EE in irq_happened,=
Also clears EE in SRR1 and rfi. So interrupts are hard disabled.=20
-> local_irq_enable() - This checks that irq_happened is set.
IIUC, it replays only one interrupt? is not it?
-Bharat
^ permalink raw reply
* RE: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: Bhushan Bharat-R65777 @ 2013-05-09 8:26 UTC (permalink / raw)
To: tiejun.chen
Cc: Caraman Mihai Claudiu-B02008, Kevin Hao, kvm@vger.kernel.org,
Wood Scott-B07421, agraf@suse.de, kvm-ppc@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <518B5B9B.6020901@windriver.com>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdGllanVuLmNoZW4gW21h
aWx0bzp0aWVqdW4uY2hlbkB3aW5kcml2ZXIuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgTWF5IDA5
LCAyMDEzIDE6NDggUE0NCj4gVG86IEJodXNoYW4gQmhhcmF0LVI2NTc3Nw0KPiBDYzogS2V2aW4g
SGFvOyBDYXJhbWFuIE1paGFpIENsYXVkaXUtQjAyMDA4OyBrdm1Admdlci5rZXJuZWwub3JnOyBX
b29kIFNjb3R0LQ0KPiBCMDc0MjE7IGFncmFmQHN1c2UuZGU7IGt2bS1wcGNAdmdlci5rZXJuZWwu
b3JnOyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZw0KPiBTdWJqZWN0OiBSZTogW1JGQ11b
S1ZNXVtQQVRDSCAxLzFdIGt2bTpwcGM6Ym9va2UtNjQ6IHNvZnQtZGlzYWJsZSBpbnRlcnJ1cHRz
DQo+IA0KPiBPbiAwNS8wOS8yMDEzIDA0OjEyIFBNLCBCaHVzaGFuIEJoYXJhdC1SNjU3Nzcgd3Jv
dGU6DQo+ID4NCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9t
OiBLZXZpbiBIYW8gW21haWx0bzpoYW9rZXhpbkBnbWFpbC5jb21dDQo+ID4+IFNlbnQ6IFRodXJz
ZGF5LCBNYXkgMDksIDIwMTMgMTozOCBQTQ0KPiA+PiBUbzogQmh1c2hhbiBCaGFyYXQtUjY1Nzc3
DQo+ID4+IENjOiB0aWVqdW4uY2hlbjsgQ2FyYW1hbiBNaWhhaSBDbGF1ZGl1LUIwMjAwODsga3Zt
QHZnZXIua2VybmVsLm9yZzsNCj4gPj4gV29vZCBTY290dC0gQjA3NDIxOyBhZ3JhZkBzdXNlLmRl
OyBrdm0tcHBjQHZnZXIua2VybmVsLm9yZzsNCj4gPj4gbGludXhwcGMtZGV2QGxpc3RzLm96bGFi
cy5vcmcNCj4gPj4gU3ViamVjdDogUmU6IFtSRkNdW0tWTV1bUEFUQ0ggMS8xXSBrdm06cHBjOmJv
b2tlLTY0OiBzb2Z0LWRpc2FibGUNCj4gPj4gaW50ZXJydXB0cw0KPiA+Pg0KPiA+PiBPbiBUaHUs
IE1heSAwOSwgMjAxMyBhdCAwNzo1MTowOUFNICswMDAwLCBCaHVzaGFuIEJoYXJhdC1SNjU3Nzcg
d3JvdGU6DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K
PiA+Pj4+IEZyb206IHRpZWp1bi5jaGVuIFttYWlsdG86dGllanVuLmNoZW5Ad2luZHJpdmVyLmNv
bV0NCj4gPj4+PiBTZW50OiBUaHVyc2RheSwgTWF5IDA5LCAyMDEzIDE6MTggUE0NCj4gPj4+PiBU
bzogQmh1c2hhbiBCaGFyYXQtUjY1Nzc3DQo+ID4+Pj4gQ2M6IENhcmFtYW4gTWloYWkgQ2xhdWRp
dS1CMDIwMDg7IFdvb2QgU2NvdHQtQjA3NDIxOyBsaW51eHBwYy0NCj4gPj4+PiBkZXZAbGlzdHMu
b3psYWJzLm9yZzsgYWdyYWZAc3VzZS5kZTsga3ZtLXBwY0B2Z2VyLmtlcm5lbC5vcmc7DQo+ID4+
Pj4ga3ZtQHZnZXIua2VybmVsLm9yZw0KPiA+Pj4+IFN1YmplY3Q6IFJlOiBbUkZDXVtLVk1dW1BB
VENIIDEvMV0ga3ZtOnBwYzpib29rZS02NDogc29mdC1kaXNhYmxlDQo+ID4+Pj4gaW50ZXJydXB0
cw0KPiA+Pj4+DQo+ID4+Pj4gT24gMDUvMDkvMjAxMyAwMzozMyBQTSwgQmh1c2hhbiBCaGFyYXQt
UjY1Nzc3IHdyb3RlOg0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS0NCj4gPj4+Pj4+IEZyb206IExpbnV4cHBjLWRldiBbbWFpbHRvOmxpbnV4cHBj
LWRldi0NCj4gPj4+Pj4+IGJvdW5jZXMrYmhhcmF0LmJodXNoYW49ZnJlZXNjYWxlLmNvbUBsaXN0
cy5vemxhYnMub3JnXSBPbiBCZWhhbGYNCj4gPj4+Pj4+IGJvdW5jZXMrT2YgQ2FyYW1hbg0KPiA+
Pj4+Pj4gTWloYWkgQ2xhdWRpdS1CMDIwMDgNCj4gPj4+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgTWF5
IDA4LCAyMDEzIDY6NDQgUE0NCj4gPj4+Pj4+IFRvOiBXb29kIFNjb3R0LUIwNzQyMTsgdGllanVu
LmNoZW4NCj4gPj4+Pj4+IENjOiBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsgYWdyYWZA
c3VzZS5kZTsNCj4gPj4+Pj4+IGt2bS1wcGNAdmdlci5rZXJuZWwub3JnOyBrdm1Admdlci5rZXJu
ZWwub3JnDQo+ID4+Pj4+PiBTdWJqZWN0OiBSRTogW1JGQ11bS1ZNXVtQQVRDSCAxLzFdIGt2bTpw
cGM6Ym9va2UtNjQ6IHNvZnQtZGlzYWJsZQ0KPiA+Pj4+Pj4gaW50ZXJydXB0cw0KPiA+Pj4+Pj4N
Cj4gPj4+Pj4+Pj4gVGhpcyBvbmx5IGRpc2FibGUgc29mdCBpbnRlcnJ1cHQgZm9yIGt2bXBwY19y
ZXN0YXJ0X2ludGVycnVwdCgpDQo+ID4+Pj4+Pj4+IHRoYXQgcmVzdGFydHMgaW50ZXJydXB0cyBp
ZiB0aGV5IHdlcmUgbWVhbnQgZm9yIHRoZSBob3N0Og0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBh
LiBTT0ZUX0RJU0FCTEVfSU5UUygpIG9ubHkgZm9yIEJPT0tFX0lOVEVSUlVQVF9FWFRFUk5BTCB8
DQo+ID4+Pj4+Pj4+IEJPT0tFX0lOVEVSUlVQVF9ERUNSRU1FTlRFUiB8IEJPT0tFX0lOVEVSUlVQ
VF9ET09SQkVMTA0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gVGhvc2UgYXJlbid0IHRoZSBvbmx5IGV4
Y2VwdGlvbnMgdGhhdCBjYW4gZW5kIHVwIGdvaW5nIHRvIHRoZSBob3N0Lg0KPiA+Pj4+Pj4+IFdl
IGNvdWxkIGdldCBhIFRMQiBtaXNzIHRoYXQgcmVzdWx0cyBpbiBhIGhlYXZ5d2VpZ2h0IE1NSU8g
ZXhpdCwgZXRjLg0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4+IEFuZCBzaG91bGRuJ3Qgd2UgaGFuZGxl
IGt2bXBwY19yZXN0YXJ0X2ludGVycnVwdCgpIGxpa2UgdGhlDQo+ID4+Pj4+Pj4+IG9yaWdpbmFs
IEhPU1QgZmxvdz8NCj4gPj4+Pj4+Pj4NCj4gPj4+Pj4+Pj4gI2RlZmluZSBNQVNLQUJMRV9FWENF
UFRJT04odHJhcG51bSwgaW50bnVtLCBsYWJlbCwgaGRsciwNCj4gPj4+Pj4+Pj4gYWNrKSAgICAg
ICAgICAgXA0KPiA+Pj4+Pj4+Pg0KPiA+Pj4+Pj4+PiBTVEFSVF9FWENFUFRJT04obGFiZWwpOyAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXA0KPiA+Pj4+Pj4+PiAgICAg
ICAgICAgTk9STUFMX0VYQ0VQVElPTl9QUk9MT0codHJhcG51bSwgaW50bnVtLA0KPiA+Pj4+Pj4+
PiBQUk9MT0dfQURESVRJT05fTUFTS0FCTEUpXA0KPiA+Pj4+Pj4+PiAgICAgICAgICAgRVhDRVBU
SU9OX0NPTU1PTih0cmFwbnVtLCBQQUNBX0VYR0VOLA0KPiA+Pj4+Pj4+PiAqSU5UU19ESVNBQkxF
KikgICAgICAgICAgICAgXA0KPiA+Pj4+Pj4+PiAJLi4uDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBD
b3VsZCB5b3UgZWxhYm9yYXRlIG9uIHdoYXQgeW91IG1lYW4/DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4g
SSB0aGluayBUaWVqdW4gd2FzIHNheWluZyB0aGF0IGhvc3QgaGFzIGZsYWdzIGFuZCByZXBsYXlz
IG9ubHkNCj4gPj4+Pj4+IEVFL0RFQy9EQkVMTCBpbnRlcnJ1cHRzLiBUaGVyZSBpcyBzcGVjaWFs
IG1hY3JvDQo+ID4+Pj4+PiBtYXNrZWRfaW50ZXJydXB0X2Jvb2szZSBpbiB0aG9zZSBleGNlcHRp
b24gaGFuZGxlcnMgdGhhdCBzZXRzDQo+ID4+Pj4+PiBwYWNhLQ0KPiA+Pj4+PiBpcnFfaGFwcGVu
ZWQuDQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gVGhlIGxpc3Qgb2YgcmVwbGllZCBpbnRlcnJ1cHRzIGlz
IGxpbWl0ZWQgdG8gYXN5bmNocm9ub3VzDQo+ID4+Pj4+PiBub25jcml0aWNhbCBpbnRlcnJ1cHRz
IHdoaWNoIGNhbiBiZSBtYXNrZWQgYnkgTVNSW0VFXSAodGhlcmVmb3JlDQo+ID4+Pj4+PiBubyBU
TEINCj4gPj4gbWlzcykuDQo+ID4+Pj4+DQo+ID4+Pj4+IEVtYmVkZGVkIFBlcmZtb24gaW50ZXJy
dXB0IGlzIGFsc28gYXN5bmNocm9ub3VzLCBXaHkgdGhhdCBpcyBub3QNCj4gPj4+Pj4gaW4gdGhl
IGxpc3QNCj4gPj4+PiBvZiBtYXNrZWQgaW50ZXJydXRzLg0KPiA+Pj4+DQo+ID4+Pj4gQXJlIHlv
dSBzYXlpbmcgcGVyZm1vbj8gSWYgc28sIGl0cyBhbHNvIGluIHRoYXQgbGlzdDoNCj4gPj4+Pg0K
PiA+Pj4+ICAgICAgICAgICBTVEFSVF9FWENFUFRJT04ocGVyZm1vbik7DQo+ID4+Pj4gICAgICAg
ICAgIE5PUk1BTF9FWENFUFRJT05fUFJPTE9HKDB4MjYwLA0KPiBCT09LRV9JTlRFUlJVUFRfUEVS
Rk9STUFOQ0VfTU9OSVRPUiwNCj4gPj4+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgUFJPTE9HX0FERElUSU9OX05PTkUpDQo+ID4+Pj4gICAgICAgICAgIEVYQ0VQVElPTl9DT01N
T04oMHgyNjAsIFBBQ0FfRVhHRU4sIElOVFNfRElTQUJMRSkNCj4gPj4+DQo+ID4+PiBXaGVyZSBp
dCBpcyByZWNvcmRlZCBpbiBwYWNhLT5pcnFfaGFwcG5lZCB0byBiZSByZXBsYXllZCBsYXRlciA/
DQo+ID4+DQo+ID4+IEFjdHVhbGx5IHdlIGRvbid0IHdhbnQgcmVwbGF5IHRoZSBwZXJmbW9uIGlu
dGVycnVwdCBsYXRlci4gV2Ugd291bGQNCj4gPj4gcnVuIGl0IGV2ZW4gc29mdCBpcnEgaXMgZGlz
YWJsZWQgYW5kIGp1c3QgdHJlYXQgaXQgYXMgTk1JLiBQbGVhc2Ugc2VlDQo+ID4+IHRoZSBmb2xs
b3dpbmcgZnVuY3Rpb24gcXVvdGVkIGZyb20gYXJjaC9wb3dlcnBjL3BlcmYvY29yZS1mc2wtZW1i
LmM6DQo+ID4+ICAgIC8qDQo+ID4+ICAgICAqIElmIGludGVycnVwdHMgd2VyZSBzb2Z0LWRpc2Fi
bGVkIHdoZW4gYSBQTVUgaW50ZXJydXB0IG9jY3VycywgdHJlYXQNCj4gPj4gICAgICogaXQgYXMg
YW4gTk1JLg0KPiA+PiAgICAgKi8NCj4gPj4gICAgc3RhdGljIGlubGluZSBpbnQgcGVyZl9pbnRy
X2lzX25taShzdHJ1Y3QgcHRfcmVncyAqcmVncykNCj4gPj4gICAgew0KPiA+PiAgICAjaWZkZWYg
X19wb3dlcnBjNjRfXw0KPiA+PiAgICAgICAgICAgIHJldHVybiAhcmVncy0+c29mdGU7DQo+ID4+
ICAgICNlbHNlDQo+ID4+ICAgICAgICAgICAgcmV0dXJuIDA7DQo+ID4+ICAgICNlbmRpZg0KPiA+
PiAgICB9DQo+ID4NCj4gPiBJcyBpdCBiZWNhdXNlIHRoYXQgd2UgY2Fubm90IGFmZm9yZCB0byBs
b3NlIHBlcmZtb24gaW50ZXJydXB0IGZvciBtb3JlDQo+IGFjY3VyYXRlIGNhcHR1cmluZyBvZiBk
YXRhID8NCj4gDQo+ICAgICAgcG93ZXJwYy9wZXJmOiBlNTAwIHN1cHBvcnQNCj4gDQo+ICAgICAg
VGhpcyBpbXBsZW1lbnRzIHBlcmZfZXZlbnQgc3VwcG9ydCBmb3IgdGhlIEZyZWVzY2FsZSBlbWJl
ZGRlZCBwZXJmb3JtYW5jZQ0KPiAgICAgIG1vbml0b3IsIGJhc2VkIG9uIHRoZSBleGlzdGluZyBw
ZXJmX2V2ZW50LmMgdGhhdCBzdXBwb3J0cyBzZXJ2ZXIvY2xhc3NpYw0KPiAgICAgIGNoaXBzLg0K
PiANCj4gICAgICBTb21lIGxpbWl0YXRpb25zOg0KPiAgICAgIC0gUGVyZm9ybWFuY2UgbW9uaXRv
ciBpbnRlcnJ1cHRzIGFyZSByZWd1bGFyIEVFIGludGVycnVwdHMsIGFuZCB0aHVzIHlvdQ0KPiAg
ICAgICAgY2FuJ3QgcHJvZmlsZSBwbGFjZXMgd2l0aCBpbnRlcnJ1cHRzIGRpc2FibGVkLiAgV2Ug
bWF5IHdhbnQgdG8gaW1wbGVtZW50DQo+ICAgICAgICBzb2Z0IElSUS1kaXNhYmxpbmcsIHdpdGgg
cGVyZm1vbiBpbnRlcnJ1cHRzIGV4ZW1wdGVkIGFuZCB0cmVhdGVkIGFzIE5NSXMuDQoNCkFoaCwg
dGhhdCBnaXZlcyB0aGUgYW5zd2VyIGFuZCBzYW1lIGFzIEkgZXhwZWN0ZWQgOikNCg0KLUJoYXJh
dA0KDQo+IA0KPiBUaWVqdW4NCj4gDQo+ID4NCj4gPiAtQmhhcmF0DQo+ID4NCj4gPj4NCj4gPj4g
VGhhbmtzLA0KPiA+PiBLZXZpbg0KPiA+Pg0KPiA+Pj4NCj4gPj4+Pg0KPiA+Pj4+IFRpZWp1bg0K
PiA+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4+IC1CaGFyYXQNCj4gPj4+Pj4NCj4gPj4+Pj4+IE5vdyBv
biBLVk0gYm9vazNlIHdlDQo+ID4+Pj4+PiBkb24ndCB3YW50IHRvIHB1dCB0aGVtIGluIHRoZSBp
cnFfaGFwcGVuZWQgbGF6eSBzdGF0ZSBidXQgcmF0aGVyDQo+ID4+Pj4+PiB0byBleGVjdXRlIHRo
ZW0gZGlyZWN0bHksIHNvIHRoZXJlIGlzIG5vIHJlYXNvbiBmb3IgZXhjZXB0aW9uDQo+ID4+Pj4+
PiBoYW5kbGluZyBzeW1tZXRyeSBiZXR3ZWVuIGhvc3QgYW5kIGd1ZXN0Lg0KPiA+Pj4+Pj4NCj4g
Pj4+Pj4+IC1NaWtlDQo+ID4+Pj4NCj4gPj4+DQo+ID4+PiBfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4gTGludXhwcGMtZGV2IG1haWxpbmcgbGlz
dA0KPiA+Pj4gTGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmcNCj4gPj4+IGh0dHBzOi8vbGlz
dHMub3psYWJzLm9yZy9saXN0aW5mby9saW51eHBwYy1kZXYNCj4gPg0KPiA+DQo+ID4NCj4gDQoN
Cg==
^ permalink raw reply
* [PATCH] powerpc/fsl: add property 'reg' to pcie@0 node
From: Minghuan Lian @ 2013-05-08 9:17 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Minghuan Lian, Zang Roy-R61911
The property 'reg' is used to identify the PCIe device. if there is
no 'reg' the PCI driver can not find PCI device node corresponding
to PCI controller, and can not map the interrupts. So all the INTx
interrupts can not be used.
Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
---
arch/powerpc/boot/dts/fsl/b4si-post.dtsi | 1 +
arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 4 ++++
2 files changed, 5 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
index 7399154..d82c8da 100644
--- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
@@ -49,6 +49,7 @@
interrupts = <20 2 0 0>;
fsl,iommu-parent = <&pamu0>;
pcie@0 {
+ reg = <0 0 0 0 0>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
diff --git a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
index bd611a9..3a6179f 100644
--- a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
+++ b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
@@ -48,6 +48,7 @@
bus-range = <0x0 0xff>;
interrupts = <20 2 0 0>;
pcie@0 {
+ reg = <0 0 0 0 0>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
@@ -74,6 +75,7 @@
bus-range = <0 0xff>;
interrupts = <21 2 0 0>;
pcie@0 {
+ reg = <0 0 0 0 0>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
@@ -100,6 +102,7 @@
bus-range = <0x0 0xff>;
interrupts = <22 2 0 0>;
pcie@0 {
+ reg = <0 0 0 0 0>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
@@ -126,6 +129,7 @@
bus-range = <0x0 0xff>;
interrupts = <23 2 0 0>;
pcie@0 {
+ reg = <0 0 0 0 0>;
#interrupt-cells = <1>;
#size-cells = <2>;
#address-cells = <3>;
--
1.8.1.2
^ permalink raw reply related
* Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: tiejun.chen @ 2013-05-09 9:44 UTC (permalink / raw)
To: Bhushan Bharat-R65777
Cc: Caraman Mihai Claudiu-B02008, kvm@vger.kernel.org,
Wood Scott-B07421, agraf@suse.de, kvm-ppc@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D0700E64A@039-SN2MPN1-011.039d.mgd.msft.net>
On 05/09/2013 04:23 PM, Bhushan Bharat-R65777 wrote:
>
>
>> -----Original Message-----
>> From: Linuxppc-dev [mailto:linuxppc-dev-
>> bounces+bharat.bhushan=freescale.com@lists.ozlabs.org] On Behalf Of Caraman
>> Mihai Claudiu-B02008
>> Sent: Wednesday, May 08, 2013 6:44 PM
>> To: Wood Scott-B07421; tiejun.chen
>> Cc: linuxppc-dev@lists.ozlabs.org; agraf@suse.de; kvm-ppc@vger.kernel.org;
>> kvm@vger.kernel.org
>> Subject: RE: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
>>
>>>> This only disable soft interrupt for kvmppc_restart_interrupt() that
>>>> restarts interrupts if they were meant for the host:
>>>>
>>>> a. SOFT_DISABLE_INTS() only for BOOKE_INTERRUPT_EXTERNAL |
>>>> BOOKE_INTERRUPT_DECREMENTER | BOOKE_INTERRUPT_DOORBELL
>>>
>>> Those aren't the only exceptions that can end up going to the host.
>>> We could get a TLB miss that results in a heavyweight MMIO exit, etc.
>>>
>>>> And shouldn't we handle kvmppc_restart_interrupt() like the original
>>>> HOST flow?
>>>>
>>>> #define MASKABLE_EXCEPTION(trapnum, intnum, label, hdlr,
>>>> ack) \
>>>>
>>>> START_EXCEPTION(label); \
>>>> NORMAL_EXCEPTION_PROLOG(trapnum, intnum,
>>>> PROLOG_ADDITION_MASKABLE)\
>>>> EXCEPTION_COMMON(trapnum, PACA_EXGEN,
>>>> *INTS_DISABLE*) \
>>>> ...
>>>
>>> Could you elaborate on what you mean?
>>
>> I think Tiejun was saying that host has flags and replays only EE/DEC/DBELL
>> interrupts. There is special macro masked_interrupt_book3e in those exception
>> handlers that sets paca->irq_happened.
>>
>> The list of replied interrupts is limited to asynchronous noncritical interrupts
>> which can be masked by MSR[EE] (therefore no TLB miss). Now on KVM book3e we
>> don't want to put them in the irq_happened lazy state but rather to execute them
>> directly, so there is no reason for exception handling symmetry between host and
>> guest.
>
>
> Another Question:
>
> The case is:
>
Actually in the case GS=1 even if EE=0, EXT/DEC/DBELL still occur as I recall.
> Case 1)
> -> Local_irq_disable() will set soft_enabled = 0
> -> Now Externel interrupt happens, there we set PACA_IRQ_EE in irq_happened, Also clears EE in SRR1 and rfi. So interrupts are hard disabled. No more other interrupt gated by MSR.EE can happen. Looks like the idea here is to not let a device keep on inserting interrupt till the interrupt condition on device is cleared, right?
I don't understand "the interrupt condition on device is cleared" here.
I think regardless if you clear the device interrupt status, the system still
receive a pending interrupt once EE or GS = 1.
> -> local_irq_enable() - This checks that irq_happened is set, and replays
ret_from_except also check to replay.
>
> Now the case 2)
> Case 2)
> -> Local_irq_disable() will set soft_enabled = 0
> -> Now DEC interrupt happens. We set PACA_IRQ_DEC in irq_happened, But do not clear EE in SRR1 and rfi. So interrupts are not hard disabled.
> -> Now say EE interrupt happens, there we set PACA_IRQ_EE in irq_happened, Also clears EE in SRR1 and rfi. So interrupts are hard disabled.
> -> local_irq_enable() - This checks that irq_happened is set.
> IIUC, it replays only one interrupt? is not it?
After anyone is replayed in arch_local_irq_restore(), we will set soft/hard
interrupt there:
set_soft_enabled(1);
__hard_irq_enable();
Then any pending interrupt can be executed now.
Additionally, ret_from_except probably check to replay all.
Tiejun
^ permalink raw reply
* RE: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: Bhushan Bharat-R65777 @ 2013-05-09 10:00 UTC (permalink / raw)
To: tiejun.chen
Cc: Caraman Mihai Claudiu-B02008, kvm@vger.kernel.org,
Wood Scott-B07421, agraf@suse.de, kvm-ppc@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <518B7014.1090508@windriver.com>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdGllanVuLmNoZW4gW21h
aWx0bzp0aWVqdW4uY2hlbkB3aW5kcml2ZXIuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgTWF5IDA5
LCAyMDEzIDM6MTUgUE0NCj4gVG86IEJodXNoYW4gQmhhcmF0LVI2NTc3Nw0KPiBDYzogQ2FyYW1h
biBNaWhhaSBDbGF1ZGl1LUIwMjAwODsgV29vZCBTY290dC1CMDc0MjE7IGxpbnV4cHBjLQ0KPiBk
ZXZAbGlzdHMub3psYWJzLm9yZzsgYWdyYWZAc3VzZS5kZTsga3ZtLXBwY0B2Z2VyLmtlcm5lbC5v
cmc7DQo+IGt2bUB2Z2VyLmtlcm5lbC5vcmcNCj4gU3ViamVjdDogUmU6IFtSRkNdW0tWTV1bUEFU
Q0ggMS8xXSBrdm06cHBjOmJvb2tlLTY0OiBzb2Z0LWRpc2FibGUgaW50ZXJydXB0cw0KPiANCj4g
T24gMDUvMDkvMjAxMyAwNDoyMyBQTSwgQmh1c2hhbiBCaGFyYXQtUjY1Nzc3IHdyb3RlOg0KPiA+
DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogTGludXhw
cGMtZGV2IFttYWlsdG86bGludXhwcGMtZGV2LQ0KPiA+PiBib3VuY2VzK2JoYXJhdC5iaHVzaGFu
PWZyZWVzY2FsZS5jb21AbGlzdHMub3psYWJzLm9yZ10gT24gQmVoYWxmIE9mDQo+ID4+IGJvdW5j
ZXMrQ2FyYW1hbg0KPiA+PiBNaWhhaSBDbGF1ZGl1LUIwMjAwOA0KPiA+PiBTZW50OiBXZWRuZXNk
YXksIE1heSAwOCwgMjAxMyA2OjQ0IFBNDQo+ID4+IFRvOiBXb29kIFNjb3R0LUIwNzQyMTsgdGll
anVuLmNoZW4NCj4gPj4gQ2M6IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOyBhZ3JhZkBz
dXNlLmRlOw0KPiA+PiBrdm0tcHBjQHZnZXIua2VybmVsLm9yZzsga3ZtQHZnZXIua2VybmVsLm9y
Zw0KPiA+PiBTdWJqZWN0OiBSRTogW1JGQ11bS1ZNXVtQQVRDSCAxLzFdIGt2bTpwcGM6Ym9va2Ut
NjQ6IHNvZnQtZGlzYWJsZQ0KPiA+PiBpbnRlcnJ1cHRzDQo+ID4+DQo+ID4+Pj4gVGhpcyBvbmx5
IGRpc2FibGUgc29mdCBpbnRlcnJ1cHQgZm9yIGt2bXBwY19yZXN0YXJ0X2ludGVycnVwdCgpDQo+
ID4+Pj4gdGhhdCByZXN0YXJ0cyBpbnRlcnJ1cHRzIGlmIHRoZXkgd2VyZSBtZWFudCBmb3IgdGhl
IGhvc3Q6DQo+ID4+Pj4NCj4gPj4+PiBhLiBTT0ZUX0RJU0FCTEVfSU5UUygpIG9ubHkgZm9yIEJP
T0tFX0lOVEVSUlVQVF9FWFRFUk5BTCB8DQo+ID4+Pj4gQk9PS0VfSU5URVJSVVBUX0RFQ1JFTUVO
VEVSIHwgQk9PS0VfSU5URVJSVVBUX0RPT1JCRUxMDQo+ID4+Pg0KPiA+Pj4gVGhvc2UgYXJlbid0
IHRoZSBvbmx5IGV4Y2VwdGlvbnMgdGhhdCBjYW4gZW5kIHVwIGdvaW5nIHRvIHRoZSBob3N0Lg0K
PiA+Pj4gV2UgY291bGQgZ2V0IGEgVExCIG1pc3MgdGhhdCByZXN1bHRzIGluIGEgaGVhdnl3ZWln
aHQgTU1JTyBleGl0LCBldGMuDQo+ID4+Pg0KPiA+Pj4+IEFuZCBzaG91bGRuJ3Qgd2UgaGFuZGxl
IGt2bXBwY19yZXN0YXJ0X2ludGVycnVwdCgpIGxpa2UgdGhlDQo+ID4+Pj4gb3JpZ2luYWwgSE9T
VCBmbG93Pw0KPiA+Pj4+DQo+ID4+Pj4gI2RlZmluZSBNQVNLQUJMRV9FWENFUFRJT04odHJhcG51
bSwgaW50bnVtLCBsYWJlbCwgaGRsciwNCj4gPj4+PiBhY2spICAgICAgICAgICBcDQo+ID4+Pj4N
Cj4gPj4+PiBTVEFSVF9FWENFUFRJT04obGFiZWwpOyAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgXA0KPiA+Pj4+ICAgICAgICAgIE5PUk1BTF9FWENFUFRJT05fUFJPTE9H
KHRyYXBudW0sIGludG51bSwNCj4gPj4+PiBQUk9MT0dfQURESVRJT05fTUFTS0FCTEUpXA0KPiA+
Pj4+ICAgICAgICAgIEVYQ0VQVElPTl9DT01NT04odHJhcG51bSwgUEFDQV9FWEdFTiwNCj4gPj4+
PiAqSU5UU19ESVNBQkxFKikgICAgICAgICAgICAgXA0KPiA+Pj4+IAkuLi4NCj4gPj4+DQo+ID4+
PiBDb3VsZCB5b3UgZWxhYm9yYXRlIG9uIHdoYXQgeW91IG1lYW4/DQo+ID4+DQo+ID4+IEkgdGhp
bmsgVGllanVuIHdhcyBzYXlpbmcgdGhhdCBob3N0IGhhcyBmbGFncyBhbmQgcmVwbGF5cyBvbmx5
DQo+ID4+IEVFL0RFQy9EQkVMTCBpbnRlcnJ1cHRzLiBUaGVyZSBpcyBzcGVjaWFsIG1hY3JvDQo+
ID4+IG1hc2tlZF9pbnRlcnJ1cHRfYm9vazNlIGluIHRob3NlIGV4Y2VwdGlvbiBoYW5kbGVycyB0
aGF0IHNldHMgcGFjYS0NCj4gPmlycV9oYXBwZW5lZC4NCj4gPj4NCj4gPj4gVGhlIGxpc3Qgb2Yg
cmVwbGllZCBpbnRlcnJ1cHRzIGlzIGxpbWl0ZWQgdG8gYXN5bmNocm9ub3VzIG5vbmNyaXRpY2Fs
DQo+ID4+IGludGVycnVwdHMgd2hpY2ggY2FuIGJlIG1hc2tlZCBieSBNU1JbRUVdICh0aGVyZWZv
cmUgbm8gVExCIG1pc3MpLg0KPiA+PiBOb3cgb24gS1ZNIGJvb2szZSB3ZSBkb24ndCB3YW50IHRv
IHB1dCB0aGVtIGluIHRoZSBpcnFfaGFwcGVuZWQgbGF6eQ0KPiA+PiBzdGF0ZSBidXQgcmF0aGVy
IHRvIGV4ZWN1dGUgdGhlbSBkaXJlY3RseSwgc28gdGhlcmUgaXMgbm8gcmVhc29uIGZvcg0KPiA+
PiBleGNlcHRpb24gaGFuZGxpbmcgc3ltbWV0cnkgYmV0d2VlbiBob3N0IGFuZCBndWVzdC4NCj4g
Pg0KPiA+DQo+ID4gQW5vdGhlciBRdWVzdGlvbjoNCj4gPg0KPiA+IFRoZSBjYXNlIGlzOg0KPiA+
DQo+IA0KPiBBY3R1YWxseSBpbiB0aGUgY2FzZSBHUz0xIGV2ZW4gaWYgRUU9MCwgRVhUL0RFQy9E
QkVMTCBzdGlsbCBvY2N1ciBhcyBJIHJlY2FsbC4NCj4gDQo+ID4gQ2FzZSAxKQ0KPiA+ICAgLT4g
TG9jYWxfaXJxX2Rpc2FibGUoKSAgd2lsbCBzZXQgc29mdF9lbmFibGVkID0gMA0KPiA+ICAgLT4g
Tm93IEV4dGVybmVsIGludGVycnVwdCBoYXBwZW5zLCB0aGVyZSB3ZSBzZXQgUEFDQV9JUlFfRUUg
aW4gaXJxX2hhcHBlbmVkLA0KPiBBbHNvIGNsZWFycyBFRSBpbiBTUlIxIGFuZCByZmkuIFNvIGlu
dGVycnVwdHMgYXJlIGhhcmQgZGlzYWJsZWQuIE5vIG1vcmUgb3RoZXINCj4gaW50ZXJydXB0IGdh
dGVkIGJ5IE1TUi5FRSBjYW4gaGFwcGVuLiBMb29rcyBsaWtlIHRoZSBpZGVhIGhlcmUgaXMgdG8g
bm90IGxldCBhDQo+IGRldmljZSBrZWVwIG9uIGluc2VydGluZyBpbnRlcnJ1cHQgdGlsbCB0aGUg
aW50ZXJydXB0IGNvbmRpdGlvbiBvbiBkZXZpY2UgaXMNCj4gY2xlYXJlZCwgcmlnaHQ/DQo+IA0K
PiBJIGRvbid0IHVuZGVyc3RhbmQgInRoZSBpbnRlcnJ1cHQgY29uZGl0aW9uIG9uIGRldmljZSBp
cyBjbGVhcmVkIiBoZXJlLg0KPiANCj4gSSB0aGluayByZWdhcmRsZXNzIGlmIHlvdSBjbGVhciB0
aGUgZGV2aWNlIGludGVycnVwdCBzdGF0dXMsIHRoZSBzeXN0ZW0gc3RpbGwNCj4gcmVjZWl2ZSBh
IHBlbmRpbmcgaW50ZXJydXB0IG9uY2UgRUUgb3IgR1MgPSAxLg0KDQpPbmNlIHllcywgYnV0IEkg
dGhpbmsgdG8gYXZvaWQgZmxvb2Qgb2YgZGV2aWNlIGludGVycnVwdCB3ZSBkaXNhYmxlIE1TUi5F
RSB3aGVuIHNvZnQtZGlzYWJsZWQuDQoNCj4gDQo+ID4gICAtPiBsb2NhbF9pcnFfZW5hYmxlKCkg
LSBUaGlzIGNoZWNrcyB0aGF0IGlycV9oYXBwZW5lZCBpcyBzZXQsIGFuZA0KPiA+IHJlcGxheXMN
Cj4gDQo+IHJldF9mcm9tX2V4Y2VwdCBhbHNvIGNoZWNrIHRvIHJlcGxheS4NCj4gDQo+ID4NCj4g
PiBOb3cgdGhlIGNhc2UgMikNCj4gPiBDYXNlIDIpDQo+ID4gLT4gTG9jYWxfaXJxX2Rpc2FibGUo
KSAgd2lsbCBzZXQgc29mdF9lbmFibGVkID0gMA0KPiA+ICAgLT4gTm93IERFQyBpbnRlcnJ1cHQg
aGFwcGVucy4gV2Ugc2V0IFBBQ0FfSVJRX0RFQyBpbiBpcnFfaGFwcGVuZWQsIEJ1dCBkbw0KPiBu
b3QgY2xlYXIgRUUgaW4gU1JSMSBhbmQgcmZpLiBTbyBpbnRlcnJ1cHRzIGFyZSBub3QgaGFyZCBk
aXNhYmxlZC4NCj4gPiAgIC0+IE5vdyBzYXkgRUUgaW50ZXJydXB0IGhhcHBlbnMsIHRoZXJlIHdl
IHNldCBQQUNBX0lSUV9FRSBpbiBpcnFfaGFwcGVuZWQsDQo+IEFsc28gY2xlYXJzIEVFIGluIFNS
UjEgYW5kIHJmaS4gU28gaW50ZXJydXB0cyBhcmUgaGFyZCBkaXNhYmxlZC4NCj4gPiAgIC0+IGxv
Y2FsX2lycV9lbmFibGUoKSAtIFRoaXMgY2hlY2tzIHRoYXQgaXJxX2hhcHBlbmVkIGlzIHNldC4N
Cj4gPiBJSVVDLCBpdCByZXBsYXlzIG9ubHkgb25lIGludGVycnVwdD8gaXMgbm90IGl0Pw0KPiAN
Cj4gQWZ0ZXIgYW55b25lIGlzIHJlcGxheWVkIGluIGFyY2hfbG9jYWxfaXJxX3Jlc3RvcmUoKSwg
d2Ugd2lsbCBzZXQgc29mdC9oYXJkDQo+IGludGVycnVwdCB0aGVyZToNCj4gDQo+IHNldF9zb2Z0
X2VuYWJsZWQoMSk7DQo+IF9faGFyZF9pcnFfZW5hYmxlKCk7DQo+IA0KPiBUaGVuIGFueSBwZW5k
aW5nIGludGVycnVwdCBjYW4gYmUgZXhlY3V0ZWQgbm93Lg0KDQpEbyB5b3UgbWVhbiB0aGF0IHRo
ZSBpbnRlcnJ1cHQgc2hvdWxkIGZpcmUgYWdhaW4/DQoNCj4gDQo+IEFkZGl0aW9uYWxseSwgcmV0
X2Zyb21fZXhjZXB0IHByb2JhYmx5IGNoZWNrIHRvIHJlcGxheSBhbGwuDQoNCkxvY2FsX2lycV9l
bmFibGUoKSB3aWxsIG5vdCB0YWtlIHVzIHRvIHJldF9mcm9tX2V4Y2VwdC4NCg0KLUJoYXJhdA0K
DQo+IA0KPiBUaWVqdW4NCg0K
^ permalink raw reply
* Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: tiejun.chen @ 2013-05-09 10:18 UTC (permalink / raw)
To: Bhushan Bharat-R65777
Cc: Caraman Mihai Claudiu-B02008, kvm@vger.kernel.org,
Wood Scott-B07421, agraf@suse.de, kvm-ppc@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D0700E85D@039-SN2MPN1-011.039d.mgd.msft.net>
On 05/09/2013 06:00 PM, Bhushan Bharat-R65777 wrote:
>
>
>> -----Original Message-----
>> From: tiejun.chen [mailto:tiejun.chen@windriver.com]
>> Sent: Thursday, May 09, 2013 3:15 PM
>> To: Bhushan Bharat-R65777
>> Cc: Caraman Mihai Claudiu-B02008; Wood Scott-B07421; linuxppc-
>> dev@lists.ozlabs.org; agraf@suse.de; kvm-ppc@vger.kernel.org;
>> kvm@vger.kernel.org
>> Subject: Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
>>
>> On 05/09/2013 04:23 PM, Bhushan Bharat-R65777 wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Linuxppc-dev [mailto:linuxppc-dev-
>>>> bounces+bharat.bhushan=freescale.com@lists.ozlabs.org] On Behalf Of
>>>> bounces+Caraman
>>>> Mihai Claudiu-B02008
>>>> Sent: Wednesday, May 08, 2013 6:44 PM
>>>> To: Wood Scott-B07421; tiejun.chen
>>>> Cc: linuxppc-dev@lists.ozlabs.org; agraf@suse.de;
>>>> kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
>>>> Subject: RE: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable
>>>> interrupts
>>>>
>>>>>> This only disable soft interrupt for kvmppc_restart_interrupt()
>>>>>> that restarts interrupts if they were meant for the host:
>>>>>>
>>>>>> a. SOFT_DISABLE_INTS() only for BOOKE_INTERRUPT_EXTERNAL |
>>>>>> BOOKE_INTERRUPT_DECREMENTER | BOOKE_INTERRUPT_DOORBELL
>>>>>
>>>>> Those aren't the only exceptions that can end up going to the host.
>>>>> We could get a TLB miss that results in a heavyweight MMIO exit, etc.
>>>>>
>>>>>> And shouldn't we handle kvmppc_restart_interrupt() like the
>>>>>> original HOST flow?
>>>>>>
>>>>>> #define MASKABLE_EXCEPTION(trapnum, intnum, label, hdlr,
>>>>>> ack) \
>>>>>>
>>>>>> START_EXCEPTION(label); \
>>>>>> NORMAL_EXCEPTION_PROLOG(trapnum, intnum,
>>>>>> PROLOG_ADDITION_MASKABLE)\
>>>>>> EXCEPTION_COMMON(trapnum, PACA_EXGEN,
>>>>>> *INTS_DISABLE*) \
>>>>>> ...
>>>>>
>>>>> Could you elaborate on what you mean?
>>>>
>>>> I think Tiejun was saying that host has flags and replays only
>>>> EE/DEC/DBELL interrupts. There is special macro
>>>> masked_interrupt_book3e in those exception handlers that sets paca-
>>> irq_happened.
>>>>
>>>> The list of replied interrupts is limited to asynchronous noncritical
>>>> interrupts which can be masked by MSR[EE] (therefore no TLB miss).
>>>> Now on KVM book3e we don't want to put them in the irq_happened lazy
>>>> state but rather to execute them directly, so there is no reason for
>>>> exception handling symmetry between host and guest.
>>>
>>>
>>> Another Question:
>>>
>>> The case is:
>>>
>>
>> Actually in the case GS=1 even if EE=0, EXT/DEC/DBELL still occur as I recall.
>>
>>> Case 1)
>>> -> Local_irq_disable() will set soft_enabled = 0
>>> -> Now Externel interrupt happens, there we set PACA_IRQ_EE in irq_happened,
>> Also clears EE in SRR1 and rfi. So interrupts are hard disabled. No more other
>> interrupt gated by MSR.EE can happen. Looks like the idea here is to not let a
>> device keep on inserting interrupt till the interrupt condition on device is
>> cleared, right?
>>
>> I don't understand "the interrupt condition on device is cleared" here.
>>
>> I think regardless if you clear the device interrupt status, the system still
>> receive a pending interrupt once EE or GS = 1.
>
> Once yes, but I think to avoid flood of device interrupt we disable MSR.EE when soft-disabled.
But we neither ACK nor send EOI to that irq in the interrupt controller, so that
should be in pending state.
>
>>
>>> -> local_irq_enable() - This checks that irq_happened is set, and
>>> replays
>>
>> ret_from_except also check to replay.
>>
>>>
>>> Now the case 2)
>>> Case 2)
>>> -> Local_irq_disable() will set soft_enabled = 0
>>> -> Now DEC interrupt happens. We set PACA_IRQ_DEC in irq_happened, But do
>> not clear EE in SRR1 and rfi. So interrupts are not hard disabled.
>>> -> Now say EE interrupt happens, there we set PACA_IRQ_EE in irq_happened,
>> Also clears EE in SRR1 and rfi. So interrupts are hard disabled.
>>> -> local_irq_enable() - This checks that irq_happened is set.
>>> IIUC, it replays only one interrupt? is not it?
>>
>> After anyone is replayed in arch_local_irq_restore(), we will set soft/hard
>> interrupt there:
>>
>> set_soft_enabled(1);
>> __hard_irq_enable();
>>
>> Then any pending interrupt can be executed now.
>
> Do you mean that the interrupt should fire again?
I means the pending exception including external interrupt, the decrementer
exception and the doorbell exception, can trap CPU once EE=1 with
__hard_irq_enable() here. Then the kernel can handle those exception since soft
enable is also 1 now.
>
>>
>> Additionally, ret_from_except probably check to replay all.
>
> Local_irq_enable() will not take us to ret_from_except.
Yes. I just say ret_from_except can provide an approach to replay all :)
Tiejun
^ permalink raw reply
* Re: [v1][KVM][PATCH 1/1] kvm:ppc:booehv: direct ISI exception to Guest
From: tiejun.chen @ 2013-05-09 10:23 UTC (permalink / raw)
To: Caraman Mihai Claudiu-B02008
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org, agraf@suse.de,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
In-Reply-To: <518A1AD8.3090103@windriver.com>
On 05/08/2013 05:28 PM, tiejun.chen wrote:
> On 05/08/2013 05:20 PM, Caraman Mihai Claudiu-B02008 wrote:
>>> -----Original Message-----
>>> From: kvm-owner@vger.kernel.org [mailto:kvm-owner@vger.kernel.org] On
>>> Behalf Of tiejun.chen
>>> Sent: Wednesday, May 08, 2013 4:54 AM
>>> To: Wood Scott-B07421
>>> Cc: agraf@suse.de; kvm-ppc@vger.kernel.org; kvm@vger.kernel.org;
>>> linuxppc-dev@lists.ozlabs.org
>>> Subject: Re: [v1][KVM][PATCH 1/1] kvm:ppc:booehv: direct ISI exception to
>>> Guest
>>>
>>> On 05/08/2013 07:40 AM, Scott Wood wrote:
>>>> On 05/07/2013 06:06:30 AM, Tiejun Chen wrote:
>>>>> We also can direct ISI exception to Guest like DSI.
>>>>>
>>>>> Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
>>>>> ---
>>>>> arch/powerpc/kvm/booke_emulate.c | 3 +++
>>>>> arch/powerpc/kvm/e500mc.c | 3 ++-
>>>>> 2 files changed, 5 insertions(+), 1 deletion(-)
>>>>
>>>> Are you seeing a real performance improvement from this? This will
>>> interfere
>>>
>>> No. But after we reduce the exit to host, shouldn't this improve
>>> performance?
>>
>> We lose some flexibility for this so it make sense only if we gain
>> measurable improvements.
>
> Sounds we have much more works to do.
>
>>
>>>
>>>> somewhat with using the VF bit, if we were to ever do so, since VF only
>>> affects
>>>
>>> Sorry, what is the VF you said?
>>
>> VF stands for virtualization fault see MAS8[VF] and we may use it for virtualized
>
> I almost forget this point :)
Looks KVM PPC have no this mechanism currently since I don't find MAS8_VF is
used in kernel, right?
If I'm missing something please correct me.
Tiejun
>
>> MMIO. The hypervisor should deny execute access on pages marked with VF.
>> Accordingly
>> in this case guest ISI exceptions should be handled by the hypervisor.
>
^ permalink raw reply
* [PATCH 20/21] powerpc/ps3: remove inline marking of EXPORT_SYMBOL functions
From: Denis Efremov @ 2013-05-09 10:36 UTC (permalink / raw)
To: Geoff Levand
Cc: ldv-project, trivial, Denis Efremov, linuxppc-dev, linux-kernel
In-Reply-To: <1368086241-9357-1-git-send-email-yefremov.denis@gmail.com>
EXPORT_SYMBOL and inline directives are contradictory to each other.
The patch fixes this inconsistency.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Denis Efremov <yefremov.denis@gmail.com>
---
arch/powerpc/platforms/ps3/spu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/ps3/spu.c b/arch/powerpc/platforms/ps3/spu.c
index e17fa14..a0bca05 100644
--- a/arch/powerpc/platforms/ps3/spu.c
+++ b/arch/powerpc/platforms/ps3/spu.c
@@ -143,7 +143,7 @@ static void _dump_areas(unsigned int spe_id, unsigned long priv2,
pr_debug("%s:%d: shadow: %lxh\n", func, line, shadow);
}
-inline u64 ps3_get_spe_id(void *arg)
+u64 ps3_get_spe_id(void *arg)
{
return spu_pdata(arg)->spe_id;
}
--
1.8.1.4
^ permalink raw reply related
* Re: [PATCH] powerpc/fsl: add property 'reg' to pcie@0 node
From: Kevin Hao @ 2013-05-09 10:41 UTC (permalink / raw)
To: Minghuan Lian; +Cc: linuxppc-dev, Zang Roy-R61911
In-Reply-To: <1368004641-12405-1-git-send-email-Minghuan.Lian@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 2976 bytes --]
On Wed, May 08, 2013 at 05:17:21PM +0800, Minghuan Lian wrote:
> The property 'reg' is used to identify the PCIe device. if there is
> no 'reg' the PCI driver can not find PCI device node corresponding
> to PCI controller, and can not map the interrupts. So all the INTx
> interrupts can not be used.
The fix for this issue has already been merged into upstream kernel.
commit 9e2ecdbba3b0745f9ed454ab86961e3ccf9dc224
Author: Kevin Hao <haokexin@gmail.com>
Date: Sun Apr 14 13:40:13 2013 +0800
powerpc/fsl-booke: add the reg prop for pci bridge device node for T4/B4
The reg property in the pci bridge device node is used to bind this
device node to the pci bridge device. Then all the pci devices under
this bridge could use the interrupt maps defined in this device node
to do the irq translation. So if this property is missed, the pci
traditional irq mechanism will not work.
Signed-off-by: Kevin Hao <haokexin@gmail.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Thanks,
Kevin
>
> Signed-off-by: Minghuan Lian <Minghuan.Lian@freescale.com>
> ---
> arch/powerpc/boot/dts/fsl/b4si-post.dtsi | 1 +
> arch/powerpc/boot/dts/fsl/t4240si-post.dtsi | 4 ++++
> 2 files changed, 5 insertions(+)
>
> diff --git a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
> index 7399154..d82c8da 100644
> --- a/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
> +++ b/arch/powerpc/boot/dts/fsl/b4si-post.dtsi
> @@ -49,6 +49,7 @@
> interrupts = <20 2 0 0>;
> fsl,iommu-parent = <&pamu0>;
> pcie@0 {
> + reg = <0 0 0 0 0>;
> #interrupt-cells = <1>;
> #size-cells = <2>;
> #address-cells = <3>;
> diff --git a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
> index bd611a9..3a6179f 100644
> --- a/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
> +++ b/arch/powerpc/boot/dts/fsl/t4240si-post.dtsi
> @@ -48,6 +48,7 @@
> bus-range = <0x0 0xff>;
> interrupts = <20 2 0 0>;
> pcie@0 {
> + reg = <0 0 0 0 0>;
> #interrupt-cells = <1>;
> #size-cells = <2>;
> #address-cells = <3>;
> @@ -74,6 +75,7 @@
> bus-range = <0 0xff>;
> interrupts = <21 2 0 0>;
> pcie@0 {
> + reg = <0 0 0 0 0>;
> #interrupt-cells = <1>;
> #size-cells = <2>;
> #address-cells = <3>;
> @@ -100,6 +102,7 @@
> bus-range = <0x0 0xff>;
> interrupts = <22 2 0 0>;
> pcie@0 {
> + reg = <0 0 0 0 0>;
> #interrupt-cells = <1>;
> #size-cells = <2>;
> #address-cells = <3>;
> @@ -126,6 +129,7 @@
> bus-range = <0x0 0xff>;
> interrupts = <23 2 0 0>;
> pcie@0 {
> + reg = <0 0 0 0 0>;
> #interrupt-cells = <1>;
> #size-cells = <2>;
> #address-cells = <3>;
> --
> 1.8.1.2
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* RE: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: Bhushan Bharat-R65777 @ 2013-05-09 11:21 UTC (permalink / raw)
To: tiejun.chen
Cc: Caraman Mihai Claudiu-B02008, kvm@vger.kernel.org,
Wood Scott-B07421, agraf@suse.de, kvm-ppc@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <518B77E5.9020809@windriver.com>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogdGllanVuLmNoZW4gW21h
aWx0bzp0aWVqdW4uY2hlbkB3aW5kcml2ZXIuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgTWF5IDA5
LCAyMDEzIDM6NDggUE0NCj4gVG86IEJodXNoYW4gQmhhcmF0LVI2NTc3Nw0KPiBDYzogQ2FyYW1h
biBNaWhhaSBDbGF1ZGl1LUIwMjAwODsgV29vZCBTY290dC1CMDc0MjE7IGxpbnV4cHBjLQ0KPiBk
ZXZAbGlzdHMub3psYWJzLm9yZzsgYWdyYWZAc3VzZS5kZTsga3ZtLXBwY0B2Z2VyLmtlcm5lbC5v
cmc7DQo+IGt2bUB2Z2VyLmtlcm5lbC5vcmcNCj4gU3ViamVjdDogUmU6IFtSRkNdW0tWTV1bUEFU
Q0ggMS8xXSBrdm06cHBjOmJvb2tlLTY0OiBzb2Z0LWRpc2FibGUgaW50ZXJydXB0cw0KPiANCj4g
T24gMDUvMDkvMjAxMyAwNjowMCBQTSwgQmh1c2hhbiBCaGFyYXQtUjY1Nzc3IHdyb3RlOg0KPiA+
DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogdGllanVu
LmNoZW4gW21haWx0bzp0aWVqdW4uY2hlbkB3aW5kcml2ZXIuY29tXQ0KPiA+PiBTZW50OiBUaHVy
c2RheSwgTWF5IDA5LCAyMDEzIDM6MTUgUE0NCj4gPj4gVG86IEJodXNoYW4gQmhhcmF0LVI2NTc3
Nw0KPiA+PiBDYzogQ2FyYW1hbiBNaWhhaSBDbGF1ZGl1LUIwMjAwODsgV29vZCBTY290dC1CMDc0
MjE7IGxpbnV4cHBjLQ0KPiA+PiBkZXZAbGlzdHMub3psYWJzLm9yZzsgYWdyYWZAc3VzZS5kZTsg
a3ZtLXBwY0B2Z2VyLmtlcm5lbC5vcmc7DQo+ID4+IGt2bUB2Z2VyLmtlcm5lbC5vcmcNCj4gPj4g
U3ViamVjdDogUmU6IFtSRkNdW0tWTV1bUEFUQ0ggMS8xXSBrdm06cHBjOmJvb2tlLTY0OiBzb2Z0
LWRpc2FibGUNCj4gPj4gaW50ZXJydXB0cw0KPiA+Pg0KPiA+PiBPbiAwNS8wOS8yMDEzIDA0OjIz
IFBNLCBCaHVzaGFuIEJoYXJhdC1SNjU3Nzcgd3JvdGU6DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+PiAt
LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4+IEZyb206IExpbnV4cHBjLWRldiBbbWFp
bHRvOmxpbnV4cHBjLWRldi0NCj4gPj4+PiBib3VuY2VzK2JoYXJhdC5iaHVzaGFuPWZyZWVzY2Fs
ZS5jb21AbGlzdHMub3psYWJzLm9yZ10gT24gQmVoYWxmIE9mDQo+ID4+Pj4gYm91bmNlcytDYXJh
bWFuDQo+ID4+Pj4gTWloYWkgQ2xhdWRpdS1CMDIwMDgNCj4gPj4+PiBTZW50OiBXZWRuZXNkYXks
IE1heSAwOCwgMjAxMyA2OjQ0IFBNDQo+ID4+Pj4gVG86IFdvb2QgU2NvdHQtQjA3NDIxOyB0aWVq
dW4uY2hlbg0KPiA+Pj4+IENjOiBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsgYWdyYWZA
c3VzZS5kZTsNCj4gPj4+PiBrdm0tcHBjQHZnZXIua2VybmVsLm9yZzsga3ZtQHZnZXIua2VybmVs
Lm9yZw0KPiA+Pj4+IFN1YmplY3Q6IFJFOiBbUkZDXVtLVk1dW1BBVENIIDEvMV0ga3ZtOnBwYzpi
b29rZS02NDogc29mdC1kaXNhYmxlDQo+ID4+Pj4gaW50ZXJydXB0cw0KPiA+Pj4+DQo+ID4+Pj4+
PiBUaGlzIG9ubHkgZGlzYWJsZSBzb2Z0IGludGVycnVwdCBmb3Iga3ZtcHBjX3Jlc3RhcnRfaW50
ZXJydXB0KCkNCj4gPj4+Pj4+IHRoYXQgcmVzdGFydHMgaW50ZXJydXB0cyBpZiB0aGV5IHdlcmUg
bWVhbnQgZm9yIHRoZSBob3N0Og0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IGEuIFNPRlRfRElTQUJMRV9J
TlRTKCkgb25seSBmb3IgQk9PS0VfSU5URVJSVVBUX0VYVEVSTkFMIHwNCj4gPj4+Pj4+IEJPT0tF
X0lOVEVSUlVQVF9ERUNSRU1FTlRFUiB8IEJPT0tFX0lOVEVSUlVQVF9ET09SQkVMTA0KPiA+Pj4+
Pg0KPiA+Pj4+PiBUaG9zZSBhcmVuJ3QgdGhlIG9ubHkgZXhjZXB0aW9ucyB0aGF0IGNhbiBlbmQg
dXAgZ29pbmcgdG8gdGhlIGhvc3QuDQo+ID4+Pj4+IFdlIGNvdWxkIGdldCBhIFRMQiBtaXNzIHRo
YXQgcmVzdWx0cyBpbiBhIGhlYXZ5d2VpZ2h0IE1NSU8gZXhpdCwgZXRjLg0KPiA+Pj4+Pg0KPiA+
Pj4+Pj4gQW5kIHNob3VsZG4ndCB3ZSBoYW5kbGUga3ZtcHBjX3Jlc3RhcnRfaW50ZXJydXB0KCkg
bGlrZSB0aGUNCj4gPj4+Pj4+IG9yaWdpbmFsIEhPU1QgZmxvdz8NCj4gPj4+Pj4+DQo+ID4+Pj4+
PiAjZGVmaW5lIE1BU0tBQkxFX0VYQ0VQVElPTih0cmFwbnVtLCBpbnRudW0sIGxhYmVsLCBoZGxy
LA0KPiA+Pj4+Pj4gYWNrKSAgICAgICAgICAgXA0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFNUQVJUX0VY
Q0VQVElPTihsYWJlbCk7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBc
DQo+ID4+Pj4+PiAgICAgICAgICAgTk9STUFMX0VYQ0VQVElPTl9QUk9MT0codHJhcG51bSwgaW50
bnVtLA0KPiA+Pj4+Pj4gUFJPTE9HX0FERElUSU9OX01BU0tBQkxFKVwNCj4gPj4+Pj4+ICAgICAg
ICAgICBFWENFUFRJT05fQ09NTU9OKHRyYXBudW0sIFBBQ0FfRVhHRU4sDQo+ID4+Pj4+PiAqSU5U
U19ESVNBQkxFKikgICAgICAgICAgICAgXA0KPiA+Pj4+Pj4gCS4uLg0KPiA+Pj4+Pg0KPiA+Pj4+
PiBDb3VsZCB5b3UgZWxhYm9yYXRlIG9uIHdoYXQgeW91IG1lYW4/DQo+ID4+Pj4NCj4gPj4+PiBJ
IHRoaW5rIFRpZWp1biB3YXMgc2F5aW5nIHRoYXQgaG9zdCBoYXMgZmxhZ3MgYW5kIHJlcGxheXMg
b25seQ0KPiA+Pj4+IEVFL0RFQy9EQkVMTCBpbnRlcnJ1cHRzLiBUaGVyZSBpcyBzcGVjaWFsIG1h
Y3JvDQo+ID4+Pj4gbWFza2VkX2ludGVycnVwdF9ib29rM2UgaW4gdGhvc2UgZXhjZXB0aW9uIGhh
bmRsZXJzIHRoYXQgc2V0cyBwYWNhLQ0KPiA+Pj4gaXJxX2hhcHBlbmVkLg0KPiA+Pj4+DQo+ID4+
Pj4gVGhlIGxpc3Qgb2YgcmVwbGllZCBpbnRlcnJ1cHRzIGlzIGxpbWl0ZWQgdG8gYXN5bmNocm9u
b3VzDQo+ID4+Pj4gbm9uY3JpdGljYWwgaW50ZXJydXB0cyB3aGljaCBjYW4gYmUgbWFza2VkIGJ5
IE1TUltFRV0gKHRoZXJlZm9yZSBubyBUTEINCj4gbWlzcykuDQo+ID4+Pj4gTm93IG9uIEtWTSBi
b29rM2Ugd2UgZG9uJ3Qgd2FudCB0byBwdXQgdGhlbSBpbiB0aGUgaXJxX2hhcHBlbmVkDQo+ID4+
Pj4gbGF6eSBzdGF0ZSBidXQgcmF0aGVyIHRvIGV4ZWN1dGUgdGhlbSBkaXJlY3RseSwgc28gdGhl
cmUgaXMgbm8NCj4gPj4+PiByZWFzb24gZm9yIGV4Y2VwdGlvbiBoYW5kbGluZyBzeW1tZXRyeSBi
ZXR3ZWVuIGhvc3QgYW5kIGd1ZXN0Lg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBBbm90aGVyIFF1ZXN0
aW9uOg0KPiA+Pj4NCj4gPj4+IFRoZSBjYXNlIGlzOg0KPiA+Pj4NCj4gPj4NCj4gPj4gQWN0dWFs
bHkgaW4gdGhlIGNhc2UgR1M9MSBldmVuIGlmIEVFPTAsIEVYVC9ERUMvREJFTEwgc3RpbGwgb2Nj
dXIgYXMgSQ0KPiByZWNhbGwuDQo+ID4+DQo+ID4+PiBDYXNlIDEpDQo+ID4+PiAgICAtPiBMb2Nh
bF9pcnFfZGlzYWJsZSgpICB3aWxsIHNldCBzb2Z0X2VuYWJsZWQgPSAwDQo+ID4+PiAgICAtPiBO
b3cgRXh0ZXJuZWwgaW50ZXJydXB0IGhhcHBlbnMsIHRoZXJlIHdlIHNldCBQQUNBX0lSUV9FRSBp
bg0KPiA+Pj4gaXJxX2hhcHBlbmVkLA0KPiA+PiBBbHNvIGNsZWFycyBFRSBpbiBTUlIxIGFuZCBy
ZmkuIFNvIGludGVycnVwdHMgYXJlIGhhcmQgZGlzYWJsZWQuIE5vDQo+ID4+IG1vcmUgb3RoZXIg
aW50ZXJydXB0IGdhdGVkIGJ5IE1TUi5FRSBjYW4gaGFwcGVuLiBMb29rcyBsaWtlIHRoZSBpZGVh
DQo+ID4+IGhlcmUgaXMgdG8gbm90IGxldCBhIGRldmljZSBrZWVwIG9uIGluc2VydGluZyBpbnRl
cnJ1cHQgdGlsbCB0aGUNCj4gPj4gaW50ZXJydXB0IGNvbmRpdGlvbiBvbiBkZXZpY2UgaXMgY2xl
YXJlZCwgcmlnaHQ/DQo+ID4+DQo+ID4+IEkgZG9uJ3QgdW5kZXJzdGFuZCAidGhlIGludGVycnVw
dCBjb25kaXRpb24gb24gZGV2aWNlIGlzIGNsZWFyZWQiIGhlcmUuDQo+ID4+DQo+ID4+IEkgdGhp
bmsgcmVnYXJkbGVzcyBpZiB5b3UgY2xlYXIgdGhlIGRldmljZSBpbnRlcnJ1cHQgc3RhdHVzLCB0
aGUNCj4gPj4gc3lzdGVtIHN0aWxsIHJlY2VpdmUgYSBwZW5kaW5nIGludGVycnVwdCBvbmNlIEVF
IG9yIEdTID0gMS4NCj4gPg0KPiA+IE9uY2UgeWVzLCBidXQgSSB0aGluayB0byBhdm9pZCBmbG9v
ZCBvZiBkZXZpY2UgaW50ZXJydXB0IHdlIGRpc2FibGUgTVNSLkVFDQo+IHdoZW4gc29mdC1kaXNh
YmxlZC4NCj4gDQo+IEJ1dCB3ZSBuZWl0aGVyIEFDSyBub3Igc2VuZCBFT0kgdG8gdGhhdCBpcnEg
aW4gdGhlIGludGVycnVwdCBjb250cm9sbGVyLCBzbyB0aGF0DQo+IHNob3VsZCBiZSBpbiBwZW5k
aW5nIHN0YXRlLg0KPiANCj4gPg0KPiA+Pg0KPiA+Pj4gICAgLT4gbG9jYWxfaXJxX2VuYWJsZSgp
IC0gVGhpcyBjaGVja3MgdGhhdCBpcnFfaGFwcGVuZWQgaXMgc2V0LCBhbmQNCj4gPj4+IHJlcGxh
eXMNCj4gPj4NCj4gPj4gcmV0X2Zyb21fZXhjZXB0IGFsc28gY2hlY2sgdG8gcmVwbGF5Lg0KPiA+
Pg0KPiA+Pj4NCj4gPj4+IE5vdyB0aGUgY2FzZSAyKQ0KPiA+Pj4gQ2FzZSAyKQ0KPiA+Pj4gLT4g
TG9jYWxfaXJxX2Rpc2FibGUoKSAgd2lsbCBzZXQgc29mdF9lbmFibGVkID0gMA0KPiA+Pj4gICAg
LT4gTm93IERFQyBpbnRlcnJ1cHQgaGFwcGVucy4gV2Ugc2V0IFBBQ0FfSVJRX0RFQyBpbg0KPiA+
Pj4gaXJxX2hhcHBlbmVkLCBCdXQgZG8NCj4gPj4gbm90IGNsZWFyIEVFIGluIFNSUjEgYW5kIHJm
aS4gU28gaW50ZXJydXB0cyBhcmUgbm90IGhhcmQgZGlzYWJsZWQuDQo+ID4+PiAgICAtPiBOb3cg
c2F5IEVFIGludGVycnVwdCBoYXBwZW5zLCB0aGVyZSB3ZSBzZXQgUEFDQV9JUlFfRUUgaW4NCj4g
Pj4+IGlycV9oYXBwZW5lZCwNCj4gPj4gQWxzbyBjbGVhcnMgRUUgaW4gU1JSMSBhbmQgcmZpLiBT
byBpbnRlcnJ1cHRzIGFyZSBoYXJkIGRpc2FibGVkLg0KPiA+Pj4gICAgLT4gbG9jYWxfaXJxX2Vu
YWJsZSgpIC0gVGhpcyBjaGVja3MgdGhhdCBpcnFfaGFwcGVuZWQgaXMgc2V0Lg0KPiA+Pj4gSUlV
QywgaXQgcmVwbGF5cyBvbmx5IG9uZSBpbnRlcnJ1cHQ/IGlzIG5vdCBpdD8NCj4gPj4NCj4gPj4g
QWZ0ZXIgYW55b25lIGlzIHJlcGxheWVkIGluIGFyY2hfbG9jYWxfaXJxX3Jlc3RvcmUoKSwgd2Ug
d2lsbCBzZXQNCj4gPj4gc29mdC9oYXJkIGludGVycnVwdCB0aGVyZToNCj4gPj4NCj4gPj4gc2V0
X3NvZnRfZW5hYmxlZCgxKTsNCj4gPj4gX19oYXJkX2lycV9lbmFibGUoKTsNCj4gPj4NCj4gPj4g
VGhlbiBhbnkgcGVuZGluZyBpbnRlcnJ1cHQgY2FuIGJlIGV4ZWN1dGVkIG5vdy4NCj4gPg0KPiA+
IERvIHlvdSBtZWFuIHRoYXQgdGhlIGludGVycnVwdCBzaG91bGQgZmlyZSBhZ2Fpbj8NCj4gDQo+
IEkgbWVhbnMgdGhlIHBlbmRpbmcgZXhjZXB0aW9uIGluY2x1ZGluZyBleHRlcm5hbCBpbnRlcnJ1
cHQsIHRoZSBkZWNyZW1lbnRlcg0KPiBleGNlcHRpb24gYW5kIHRoZSBkb29yYmVsbCBleGNlcHRp
b24sIGNhbiB0cmFwIENQVSBvbmNlIEVFPTEgd2l0aA0KPiBfX2hhcmRfaXJxX2VuYWJsZSgpIGhl
cmUuIFRoZW4gdGhlIGtlcm5lbCBjYW4gaGFuZGxlIHRob3NlIGV4Y2VwdGlvbiBzaW5jZSBzb2Z0
DQo+IGVuYWJsZSBpcyBhbHNvIDEgbm93Lg0KPiANCj4gPg0KPiA+Pg0KPiA+PiBBZGRpdGlvbmFs
bHksIHJldF9mcm9tX2V4Y2VwdCBwcm9iYWJseSBjaGVjayB0byByZXBsYXkgYWxsLg0KPiA+DQo+
ID4gTG9jYWxfaXJxX2VuYWJsZSgpIHdpbGwgbm90IHRha2UgdXMgdG8gcmV0X2Zyb21fZXhjZXB0
Lg0KPiANCj4gWWVzLiBJIGp1c3Qgc2F5IHJldF9mcm9tX2V4Y2VwdCBjYW4gcHJvdmlkZSBhbiBh
cHByb2FjaCB0byByZXBsYXkgYWxsIDopDQoNCl9fcmVwbGF5X2ludGVycnVwdCgpIGZyb20gYXJj
aF9sb2NhbF9pcnFfZW5hYmxlKCkgd2lsbCB0YWtlIHVzIHRvIHJldF9mcm9tX2V4Y2VwdC9saXRl
IDopDQpUaGVyZSBhbGwgcGVuZGluZyBpbnRlcnJ1cHRzIGFyZSByZXBsYXllZCBvbmUgYnkgb25l
IGJlZm9yZSB3ZSBoYXJkLWVuYWJsZSBhbmQgc29mdC1lbmFibGUgaW50ZXJydXB0cy4NCg0KLUJo
YXJhdA0KDQo+IA0KPiBUaWVqdW4NCg0K
^ permalink raw reply
* RE: [v1][KVM][PATCH 1/1] kvm:ppc:booehv: direct ISI exception to Guest
From: Caraman Mihai Claudiu-B02008 @ 2013-05-09 11:34 UTC (permalink / raw)
To: tiejun.chen
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org, agraf@suse.de,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
In-Reply-To: <518B7913.6010302@windriver.com>
PiA+PiBWRiBzdGFuZHMgZm9yIHZpcnR1YWxpemF0aW9uIGZhdWx0IHNlZSBNQVM4W1ZGXSBhbmQg
d2UgbWF5IHVzZSBpdCBmb3INCj4gdmlydHVhbGl6ZWQNCj4gDQo+IExvb2tzIEtWTSBQUEMgaGF2
ZSBubyB0aGlzIG1lY2hhbmlzbSBjdXJyZW50bHkgc2luY2UgSSBkb24ndCBmaW5kIE1BUzhfVkYN
Cj4gaXMNCj4gdXNlZCBpbiBrZXJuZWwsIHJpZ2h0Pw0KDQpZZXMgYnV0ICd3ZSBtYXkgdXNlIGl0
JyBpbiB0aGUgZmVhdHVyZSwgSSBoYXZlIGEgZnVuY3Rpb25hbCBQT0Mgd2l0aCBWRi4NCk5vdyB3
ZSBjYXB0dXJlIHZpcnR1YWxpemVkIE1NSU8gYWNjZXNzZXMgYXMgVExCIG1pc3NlcyAod2UgZG9u
J3Qgd3JpdGUNCmludG8gSFcgVExCIGd1ZXN0IHRyYW5zbGF0aW9uIG91dHNpZGUgdmlzaWJsZSBt
ZW1zbG90cykuDQoNCi1NaWtlDQo=
^ permalink raw reply
* Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: tiejun.chen @ 2013-05-09 11:35 UTC (permalink / raw)
To: Bhushan Bharat-R65777
Cc: Caraman Mihai Claudiu-B02008, kvm@vger.kernel.org,
Wood Scott-B07421, agraf@suse.de, kvm-ppc@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <6A3DF150A5B70D4F9B66A25E3F7C888D0700E9C1@039-SN2MPN1-011.039d.mgd.msft.net>
On 05/09/2013 07:21 PM, Bhushan Bharat-R65777 wrote:
>
>
>> -----Original Message-----
>> From: tiejun.chen [mailto:tiejun.chen@windriver.com]
>> Sent: Thursday, May 09, 2013 3:48 PM
>> To: Bhushan Bharat-R65777
>> Cc: Caraman Mihai Claudiu-B02008; Wood Scott-B07421; linuxppc-
>> dev@lists.ozlabs.org; agraf@suse.de; kvm-ppc@vger.kernel.org;
>> kvm@vger.kernel.org
>> Subject: Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
>>
>> On 05/09/2013 06:00 PM, Bhushan Bharat-R65777 wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: tiejun.chen [mailto:tiejun.chen@windriver.com]
>>>> Sent: Thursday, May 09, 2013 3:15 PM
>>>> To: Bhushan Bharat-R65777
>>>> Cc: Caraman Mihai Claudiu-B02008; Wood Scott-B07421; linuxppc-
>>>> dev@lists.ozlabs.org; agraf@suse.de; kvm-ppc@vger.kernel.org;
>>>> kvm@vger.kernel.org
>>>> Subject: Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable
>>>> interrupts
>>>>
>>>> On 05/09/2013 04:23 PM, Bhushan Bharat-R65777 wrote:
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Linuxppc-dev [mailto:linuxppc-dev-
>>>>>> bounces+bharat.bhushan=freescale.com@lists.ozlabs.org] On Behalf Of
>>>>>> bounces+Caraman
>>>>>> Mihai Claudiu-B02008
>>>>>> Sent: Wednesday, May 08, 2013 6:44 PM
>>>>>> To: Wood Scott-B07421; tiejun.chen
>>>>>> Cc: linuxppc-dev@lists.ozlabs.org; agraf@suse.de;
>>>>>> kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
>>>>>> Subject: RE: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable
>>>>>> interrupts
>>>>>>
>>>>>>>> This only disable soft interrupt for kvmppc_restart_interrupt()
>>>>>>>> that restarts interrupts if they were meant for the host:
>>>>>>>>
>>>>>>>> a. SOFT_DISABLE_INTS() only for BOOKE_INTERRUPT_EXTERNAL |
>>>>>>>> BOOKE_INTERRUPT_DECREMENTER | BOOKE_INTERRUPT_DOORBELL
>>>>>>>
>>>>>>> Those aren't the only exceptions that can end up going to the host.
>>>>>>> We could get a TLB miss that results in a heavyweight MMIO exit, etc.
>>>>>>>
>>>>>>>> And shouldn't we handle kvmppc_restart_interrupt() like the
>>>>>>>> original HOST flow?
>>>>>>>>
>>>>>>>> #define MASKABLE_EXCEPTION(trapnum, intnum, label, hdlr,
>>>>>>>> ack) \
>>>>>>>>
>>>>>>>> START_EXCEPTION(label); \
>>>>>>>> NORMAL_EXCEPTION_PROLOG(trapnum, intnum,
>>>>>>>> PROLOG_ADDITION_MASKABLE)\
>>>>>>>> EXCEPTION_COMMON(trapnum, PACA_EXGEN,
>>>>>>>> *INTS_DISABLE*) \
>>>>>>>> ...
>>>>>>>
>>>>>>> Could you elaborate on what you mean?
>>>>>>
>>>>>> I think Tiejun was saying that host has flags and replays only
>>>>>> EE/DEC/DBELL interrupts. There is special macro
>>>>>> masked_interrupt_book3e in those exception handlers that sets paca-
>>>>> irq_happened.
>>>>>>
>>>>>> The list of replied interrupts is limited to asynchronous
>>>>>> noncritical interrupts which can be masked by MSR[EE] (therefore no TLB
>> miss).
>>>>>> Now on KVM book3e we don't want to put them in the irq_happened
>>>>>> lazy state but rather to execute them directly, so there is no
>>>>>> reason for exception handling symmetry between host and guest.
>>>>>
>>>>>
>>>>> Another Question:
>>>>>
>>>>> The case is:
>>>>>
>>>>
>>>> Actually in the case GS=1 even if EE=0, EXT/DEC/DBELL still occur as I
>> recall.
>>>>
>>>>> Case 1)
>>>>> -> Local_irq_disable() will set soft_enabled = 0
>>>>> -> Now Externel interrupt happens, there we set PACA_IRQ_EE in
>>>>> irq_happened,
>>>> Also clears EE in SRR1 and rfi. So interrupts are hard disabled. No
>>>> more other interrupt gated by MSR.EE can happen. Looks like the idea
>>>> here is to not let a device keep on inserting interrupt till the
>>>> interrupt condition on device is cleared, right?
>>>>
>>>> I don't understand "the interrupt condition on device is cleared" here.
>>>>
>>>> I think regardless if you clear the device interrupt status, the
>>>> system still receive a pending interrupt once EE or GS = 1.
>>>
>>> Once yes, but I think to avoid flood of device interrupt we disable MSR.EE
>> when soft-disabled.
>>
>> But we neither ACK nor send EOI to that irq in the interrupt controller, so that
>> should be in pending state.
>>
>>>
>>>>
>>>>> -> local_irq_enable() - This checks that irq_happened is set, and
>>>>> replays
>>>>
>>>> ret_from_except also check to replay.
>>>>
>>>>>
>>>>> Now the case 2)
>>>>> Case 2)
>>>>> -> Local_irq_disable() will set soft_enabled = 0
>>>>> -> Now DEC interrupt happens. We set PACA_IRQ_DEC in
>>>>> irq_happened, But do
>>>> not clear EE in SRR1 and rfi. So interrupts are not hard disabled.
>>>>> -> Now say EE interrupt happens, there we set PACA_IRQ_EE in
>>>>> irq_happened,
>>>> Also clears EE in SRR1 and rfi. So interrupts are hard disabled.
>>>>> -> local_irq_enable() - This checks that irq_happened is set.
>>>>> IIUC, it replays only one interrupt? is not it?
>>>>
>>>> After anyone is replayed in arch_local_irq_restore(), we will set
>>>> soft/hard interrupt there:
>>>>
>>>> set_soft_enabled(1);
>>>> __hard_irq_enable();
>>>>
>>>> Then any pending interrupt can be executed now.
>>>
>>> Do you mean that the interrupt should fire again?
>>
>> I means the pending exception including external interrupt, the decrementer
>> exception and the doorbell exception, can trap CPU once EE=1 with
>> __hard_irq_enable() here. Then the kernel can handle those exception since soft
>> enable is also 1 now.
>>
>>>
>>>>
>>>> Additionally, ret_from_except probably check to replay all.
>>>
>>> Local_irq_enable() will not take us to ret_from_except.
>>
>> Yes. I just say ret_from_except can provide an approach to replay all :)
>
> __replay_interrupt() from arch_local_irq_enable() will take us to ret_from_except/lite :)
> There all pending interrupts are replayed one by one before we hard-enable and soft-enable interrupts.
Yes, but a point needs to be corrected,
_replay_interrupt() is following set_soft_enabled(1), so __replay_interrupt()
can go the exception entry to call the handler.
Tiejun
^ permalink raw reply
* Re: [PATCH 20/21] powerpc/ps3: remove inline marking of EXPORT_SYMBOL functions
From: Geoff Levand @ 2013-05-09 11:35 UTC (permalink / raw)
To: Denis Efremov; +Cc: ldv-project, trivial, linuxppc-dev, linux-kernel
In-Reply-To: <1368095819-11011-9-git-send-email-yefremov.denis@gmail.com>
On Thu, 2013-05-09 at 14:36 +0400, Denis Efremov wrote:
> EXPORT_SYMBOL and inline directives are contradictory to each other.
> The patch fixes this inconsistency.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Denis Efremov <yefremov.denis@gmail.com>
> ---
> arch/powerpc/platforms/ps3/spu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Looks good, thanks.
Acked-by: Geoff Levand <geoff@infradead.org>
^ permalink raw reply
* Re: [v1][KVM][PATCH 1/1] kvm:ppc:booehv: direct ISI exception to Guest
From: tiejun.chen @ 2013-05-09 11:40 UTC (permalink / raw)
To: Caraman Mihai Claudiu-B02008
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org, agraf@suse.de,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
In-Reply-To: <300B73AA675FCE4A93EB4FC1D42459FF3F7FBE@039-SN2MPN1-012.039d.mgd.msft.net>
On 05/09/2013 07:34 PM, Caraman Mihai Claudiu-B02008 wrote:
>>>> VF stands for virtualization fault see MAS8[VF] and we may use it for
>> virtualized
>>
>> Looks KVM PPC have no this mechanism currently since I don't find MAS8_VF
>> is
>> used in kernel, right?
>
> Yes but 'we may use it' in the feature, I have a functional POC with VF.
Any IO performance to be improved with this POC?
> Now we capture virtualized MMIO accesses as TLB misses (we don't write
> into HW TLB guest translation outside visible memslots).
Yes.
Tiejun
^ permalink raw reply
* Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: Benjamin Herrenschmidt @ 2013-05-09 12:26 UTC (permalink / raw)
To: Kevin Hao
Cc: Wood Scott-B07421, kvm@vger.kernel.org,
Caraman Mihai Claudiu-B02008, agraf@suse.de,
kvm-ppc@vger.kernel.org, tiejun.chen, Bhushan Bharat-R65777,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20130509082112.GE2263@pek-khao-d1.corp.ad.wrs.com>
On Thu, 2013-05-09 at 16:21 +0800, Kevin Hao wrote:
> > Is it because that we cannot afford to lose perfmon interrupt for
> more accurate capturing of data ?
>
> Yes, I think this will definitely improve the perf sample quality.
This is one of the primary reason why we implemented lazy disabling in
the first place and why I recently reworked it to decrease the periods
where we are hard disabled.
The other reasons are that storing bytes to the PACA is faster than
manipulating EE on many processors.
Cheers,
Ben.
^ permalink raw reply
* RE: [v1][KVM][PATCH 1/1] kvm:ppc:booehv: direct ISI exception to Guest
From: Caraman Mihai Claudiu-B02008 @ 2013-05-09 12:36 UTC (permalink / raw)
To: tiejun.chen
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org, agraf@suse.de,
kvm-ppc@vger.kernel.org, kvm@vger.kernel.org
In-Reply-To: <518B8B2A.1020103@windriver.com>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0aWVqdW4uY2hlbiBbbWFpbHRv
OnRpZWp1bi5jaGVuQHdpbmRyaXZlci5jb21dDQo+IFNlbnQ6IFRodXJzZGF5LCBNYXkgMDksIDIw
MTMgMjo0MCBQTQ0KPiBUbzogQ2FyYW1hbiBNaWhhaSBDbGF1ZGl1LUIwMjAwOA0KPiBDYzogV29v
ZCBTY290dC1CMDc0MjE7IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOyBhZ3JhZkBzdXNl
LmRlOyBrdm0tDQo+IHBwY0B2Z2VyLmtlcm5lbC5vcmc7IGt2bUB2Z2VyLmtlcm5lbC5vcmcNCj4g
U3ViamVjdDogUmU6IFt2MV1bS1ZNXVtQQVRDSCAxLzFdIGt2bTpwcGM6Ym9vZWh2OiBkaXJlY3Qg
SVNJIGV4Y2VwdGlvbiB0bw0KPiBHdWVzdA0KPiANCj4gT24gMDUvMDkvMjAxMyAwNzozNCBQTSwg
Q2FyYW1hbiBNaWhhaSBDbGF1ZGl1LUIwMjAwOCB3cm90ZToNCj4gPj4+PiBWRiBzdGFuZHMgZm9y
IHZpcnR1YWxpemF0aW9uIGZhdWx0IHNlZSBNQVM4W1ZGXSBhbmQgd2UgbWF5IHVzZSBpdA0KPiBm
b3INCj4gPj4gdmlydHVhbGl6ZWQNCj4gPj4NCj4gPj4gTG9va3MgS1ZNIFBQQyBoYXZlIG5vIHRo
aXMgbWVjaGFuaXNtIGN1cnJlbnRseSBzaW5jZSBJIGRvbid0IGZpbmQNCj4gTUFTOF9WRg0KPiA+
PiBpcw0KPiA+PiB1c2VkIGluIGtlcm5lbCwgcmlnaHQ/DQo+ID4NCj4gPiBZZXMgYnV0ICd3ZSBt
YXkgdXNlIGl0JyBpbiB0aGUgZmVhdHVyZSwgSSBoYXZlIGEgZnVuY3Rpb25hbCBQT0Mgd2l0aA0K
PiBWRi4NCj4gDQo+IEFueSBJTyBwZXJmb3JtYW5jZSB0byBiZSBpbXByb3ZlZCB3aXRoIHRoaXMg
UE9DPw0KDQpWRiBhcHByb2FjaCBwdXRzIG1vcmUgc3RyZXNzIG9uIEhXIFRMQiBzbyBJIGRpZCBu
b3QgYWR2YW5jZSB3aXRoIHBlcmZvcm1hbmNlDQptZWFzdXJlbWVudHMgdGhvdWdoIGl0IG1heSB3
b3J0aCB0byBkbyBpdC4NCg0KLU1pa2UNCg==
^ permalink raw reply
* Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: Benjamin Herrenschmidt @ 2013-05-09 12:37 UTC (permalink / raw)
To: tiejun.chen
Cc: Caraman Mihai Claudiu-B02008, kvm@vger.kernel.org,
Wood Scott-B07421, agraf@suse.de, kvm-ppc@vger.kernel.org,
Bhushan Bharat-R65777, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <518B7014.1090508@windriver.com>
On Thu, 2013-05-09 at 17:44 +0800, tiejun.chen wrote:
>
> Actually in the case GS=1 even if EE=0, EXT/DEC/DBELL still occur as I
> recall.
Only if directed to the hypervisor.
> > Case 1)
> > -> Local_irq_disable() will set soft_enabled = 0
> > -> Now Externel interrupt happens, there we set PACA_IRQ_EE in
> irq_happened, Also clears EE in SRR1 and rfi. So interrupts are hard
> disabled. No more other interrupt gated by MSR.EE can happen. Looks
> like the idea here is to not let a device keep on inserting interrupt
> till the interrupt condition on device is cleared, right?
The external interrupt line is level sensitive normally, so we have to
mask MSR:EE in that case or the interrupt would keep re-occurring (note
that FSL has this concept of auto-acked interrupts via the on die MPIC
for which you can potentially use PACA_IRQ_EE_EDGE instead and avoid
having to mask MSR:EE).
> I don't understand "the interrupt condition on device is cleared"
> here.
Well, the external interrupt line will remain asserted until the device
(via the PIC) stops interrupting the processor :-) Either because we
mask at the PIC level (or raise the priority) or because the condition
goes away.
> I think regardless if you clear the device interrupt status, the
> system still receive a pending interrupt once EE or GS = 1.
Why ? Depends on your PIC actually but if it's a sane one, it won't
"remember" a level interrupt that is gone. An edge interrupt is a
different matter and is latched.
Some MPIC implementations tend to generate a spurrious IRQ in the case
of level IRQs going away. IE. they still remember an event occurred and
interrupt the processor, but on IACK return the spurious vector. However
that isn't guaranteed to be the case and it is perfectly ok (and a good
idea) for the PIC to just stop asserting the external interrupt line if
the original device interrupt goes away (and it's configured as level
sensitive).
You might notice that we try to re-hard-enable (while still soft
disabled) as soon as we have gone get_irq in do_IRQ. This is because
fetching the interrupt normally also masks it (either by masking at the
source or by raisin the processor interrupt priority depending on the
specific PIC) so we know we can re-hard enable.
> > -> local_irq_enable() - This checks that irq_happened is set, and
> replays
>
> ret_from_except also check to replay.
ret_from_except checks because it essentially can act as an implicit
local_irq_enable.
> > Now the case 2)
> > Case 2)
> > -> Local_irq_disable() will set soft_enabled = 0
> > -> Now DEC interrupt happens. We set PACA_IRQ_DEC in irq_happened,
> But do not clear EE in SRR1 and rfi. So interrupts are not hard
> disabled.
Right. We move the decrementer to its maximum value however since on
most implementations, it will continue interrupting the processor while
it's top bit is set (and effectively act as a level sensitive
interrupt).
Again, the goal here is to run as much as possible with interrupts hard
enabled which allow better perf sampling.
> > -> Now say EE interrupt happens, there we set PACA_IRQ_EE in
> irq_happened, Also clears EE in SRR1 and rfi. So interrupts are hard
> disabled.
> > -> local_irq_enable() - This checks that irq_happened is set.
> > IIUC, it replays only one interrupt? is not it?
It replays one interrupt, but interrupt are still disabled during the
replay. Upon return from the replayed interrupt, the ret_from_except
will see the other one and replay it too.
> After anyone is replayed in arch_local_irq_restore(), we will set
> soft/hard
> interrupt there:
>
> set_soft_enabled(1);
> __hard_irq_enable();
>
> Then any pending interrupt can be executed now.
>
> Additionally, ret_from_except probably check to replay all.
>
> Tiejun
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: David Laight @ 2013-05-09 13:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt, tiejun.chen
Cc: Caraman Mihai Claudiu-B02008, kvm, Wood Scott-B07421, agraf,
kvm-ppc, Bhushan Bharat-R65777, linuxppc-dev
In-Reply-To: <1368103062.25488.193.camel@pasglop>
> Some MPIC implementations tend to generate a spurrious IRQ in the case
> of level IRQs going away. IE. they still remember an event occurred =
and
> interrupt the processor, but on IACK return the spurious vector. =
However
> that isn't guaranteed to be the case and it is perfectly ok (and a =
good
> idea) for the PIC to just stop asserting the external interrupt line =
if
> the original device interrupt goes away (and it's configured as level
> sensitive).
That will happen if the IRQ goes away while the cpu is performing
the IACK sequence.
If the IRQ goes away while the cpu has interrupts masked then
the cpu won't start the interrupt sequence and then try to
read a vector when no interrupt is pending.
David
^ permalink raw reply
* RE: [PATCH] powerpc/pci: Support per-aperture memory offset
From: Sethi Varun-B16395 @ 2013-05-09 13:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev
Cc: Thomas Petazzoni, Wood Scott-B07421, linux-pci@vger.kernel.org,
Bjorn Helgaas, Andrew Murray
In-Reply-To: <1367823016.15842.22.camel@pasglop>
DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmVuamFtaW4gSGVycmVu
c2NobWlkdCBbbWFpbHRvOmJlbmhAa2VybmVsLmNyYXNoaW5nLm9yZ10NCj4gU2VudDogTW9uZGF5
LCBNYXkgMDYsIDIwMTMgMTI6MjAgUE0NCj4gVG86IGxpbnV4cHBjLWRldg0KPiBDYzogS3VtYXIg
R2FsYTsgV29vZCBTY290dC1CMDc0MjE7IFNldGhpIFZhcnVuLUIxNjM5NTsgVGhvbWFzIFBldGF6
em9uaTsNCj4gQW5kcmV3IE11cnJheTsgQmpvcm4gSGVsZ2FhczsgbGludXgtcGNpQHZnZXIua2Vy
bmVsLm9yZw0KPiBTdWJqZWN0OiBbUEFUQ0hdIHBvd2VycGMvcGNpOiBTdXBwb3J0IHBlci1hcGVy
dHVyZSBtZW1vcnkgb2Zmc2V0DQo+IA0KPiBUaGUgUENJIGNvcmUgc3VwcG9ydHMgYW4gb2Zmc2V0
IHBlciBhcGVydHVyZSBub3dhZGF5cyBidXQgb3VyIGFyY2ggY29kZQ0KPiBzdGlsbCBoYXMgYSBz
aW5nbGUgb2Zmc2V0IHBlciBob3N0IGJyaWRnZSByZXByZXNlbnRpbmcgdGhlIGRpZmZlcmVuY2UN
Cj4gYmV0d2VuIENQVSBtZW1vcnkgYWRkcmVzc2VzIGFuZCBQQ0kgTU1JTyBhZGRyZXNzZXMuDQo+
IA0KPiBUaGlzIGlzIGEgcHJvYmxlbSBhcyBuZXcgbWFjaGluZXMgYW5kIGh5cGVydmlzb3IgdmVy
c2lvbnMgYXJlIGNvbWluZyBvdXQNCj4gd2hlcmUgdGhlIDY0LWJpdCB3aW5kb3dzIHdpbGwgaGF2
ZSBhIGRpZmZlcmVudCBvZmZzZXQgKGJhc2ljYWxseSBtYXBwZWQNCj4gMToxKSBmcm9tIHRoZSAz
Mi1iaXQgd2luZG93cy4NCj4gDQo+IFRoaXMgZml4ZXMgaXQgYnkgdXNpbmcgc2VwYXJhdGUgb2Zm
c2V0cy4gSW4gdGhlIGxvbmcgcnVuLCB3ZSBwcm9iYWJseQ0KPiB3YW50IHRvIGdldCByaWQgb2Yg
dGhhdCBpbnRlcm1lZGlhcnkgc3RydWN0IHBjaV9jb250cm9sbGVyIGFuZCBoYXZlIHRob3NlDQo+
IGRpcmVjdGx5IHN0b3JlZCBpbnRvIHRoZSBwY2lfaG9zdF9icmlkZ2UgYXMgdGhleSBhcmUgcGFy
c2VkIGJ1dCB0aGlzIHdpbGwNCj4gYmUgYSBtb3JlIGludmFzaXZlIGNoYW5nZS4NCj4gDQo+IFNp
Z25lZC1vZmYtYnk6IEJlbmphbWluIEhlcnJlbnNjaG1pZHQgPGJlbmhAa2VybmVsLmNyYXNoaW5n
Lm9yZz4NCj4gLS0tDQo+IA0KPiBOb3csIHRoaXMgaXMgYSBiaWcgb25lIGJ1dCBJJ2QgbGlrZSB0
byBzdGlsbCBtZXJnZSBpdCBmb3IgMy4xMCBiZWNhdXNlDQo+IHdlJ3JlIGhhdmluZyBuZXcgbWFj
aGluZSBjb21pbmcgdXAgKGFuZCBuZXcgdmVyc2lvbnMgb2YgcEh5cCBvbiBleGlzdGluZw0KPiBt
YWNoaW5lcykgdGhhdCBhcmUgZ29pbmcgdG8gZXhwb3NlIE1NSU8gd2luZG93cyB3aXRoIGRpZmZl
cmVudCBvZmZzZXRzDQo+IChiYXNpY2FsbHkgb3VyIDY0LWJpdCB3aW5kb3dzIGFyZSAxOjEgYW5k
IG91ciAzMi1iaXQgd2luZG93cyByZW1hcHBlZCkuDQo+IA0KPiBJJ20gbm90IGV4cGVjdGluZyBh
bnkgbWFqb3IgaXNzdWUgd2l0aCB0aGUgcGF0Y2gsIEkndmUgdGVzdGVkIGl0IG9uIHNvbWUNCj4g
b2Ygb3VyIG1hY2hpbmVzIGhlcmUgYW5kIHdpbGwgdGVzdCBpdCBtb3JlIGR1cmluZyB0aGUgbmV4
dCBjb3VwbGUgb2YgZGF5cw0KPiB0aGUgbm90YWJsZSB0aGluZyBpcyB0aGUgcmVtb3ZhbCBvZiBh
ICJ3b3JrYXJvdW5kIiAvIGZhbGxiYWNrIG9uIDMyLWJpdA0KPiB0aGF0IEkgc3VzcGVjdCBvbmx5
IGV2ZXIgbWF0dGVyZWQgZm9yIG1hY2hpbmVzIGxvbmcgdW5zdXBwb3J0ZWQgKFBSZVAgPykNCj4g
YXMgSSBkb24ndCB0aGluayB3ZSBoYXZlIGFueXRoaW5nIHRoYXQgZG9lc24ndCBwb3B1bGF0ZSB0
aGUgYnJpZGdlDQo+IHJlc291cmNlcyBhbmQgZXhwZWN0cyB0byB3b3JrIG5vd2FkYXlzIChvdGhl
ciBzdHVmZiB3b3VsZCBicmVhayBhbnl3YXkpLg0KPiANCj4gVGhpcyBpcyBhbHNvIHdoeSBJJ20g
TkFLJ2luZyB0aGUgcGF0Y2ggbWFraW5nDQo+IHBjaV9wcm9jZXNzX2JyaWRnZV9PRl9yYW5nZXMo
KSBnZW5lcmljIHNpbmNlIEkgbmVlZCB0byBjaGFuZ2UgaXQgZm9yDQo+IHBvd2VycGMgYW5kIHRo
aXMgaXNuJ3QgdGhlIHJpZ2h0IGxvbmcgdGVybSBhcHByb2FjaCAod2Ugc2hvdWxkICJtZXJnZSIN
Cj4gcGNpX2NvbnRyb2xsZXIgJiBwY2lfaG9zdF9icmlkZ2UgaW5zdGVhZCBhbmQgZGlyZWN0bHkg
cG9wdWxhdGUgdGhlDQo+IHBjaV9ob3N0X2JyaWRnZSBhcGVydHVyZXMpLg0KPiANCj4gSWYgSSBz
ZWUgbm8gbWFqb3IgaXNzdWUgd2l0aCB0aGUgcGF0Y2ggZHVyaW5nIHRoZSBuZXh0IGZldyBkYXlz
LCBJJ2xsDQo+IHNlbmQgaXQgdG8gTGludXMgd2l0aCBteSBuZXh0IHB1bGwgcmVxdWVzdCwgcHJv
YmFibHkgYXQgLXJjMS4NCj4gDQo+IEt1bWFyLCBTY290dCwgU2V0aGksIHBsZWFzZSB0ZXN0IG9u
IEZTTCBIVy4gSSdsbCB0YWtlIGNhcmUgb2YgbWFjcyBhbmQNCj4gNHh4IGluIGFkZGl0aW9uIHRv
IHRoZSB2YXJpb3VzIElCTSBwcGM2NCBwbGF0Zm9ybXMuDQo+IA0KW1NldGhpIFZhcnVuLUIxNjM5
NV0gVGVzdGVkIHBhdGNoIG9uIEZTTCBUNDI0MCwgUDQwODAsIFA1MDQwIGFuZCBQMTAyMCBib2Fy
ZHMuDQoNCi1WYXJ1bg0K
^ permalink raw reply
* RE: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
From: Chen, Tiejun @ 2013-05-09 14:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Caraman Mihai Claudiu-B02008, kvm@vger.kernel.org,
Wood Scott-B07421, agraf@suse.de, kvm-ppc@vger.kernel.org,
Bhushan Bharat-R65777, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1368103062.25488.193.camel@pasglop>
> -----Original Message-----
> From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org]=20
> Sent: Thursday, May 09, 2013 8:38 PM
> To: Chen, Tiejun
> Cc: Bhushan Bharat-R65777; Caraman Mihai Claudiu-B02008; Wood=20
> Scott-B07421; linuxppc-dev@lists.ozlabs.org; agraf@suse.de;=20
> kvm-ppc@vger.kernel.org; kvm@vger.kernel.org
> Subject: Re: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64:=20
> soft-disable interrupts
>=20
> On Thu, 2013-05-09 at 17:44 +0800, tiejun.chen wrote:
> >=20
> > Actually in the case GS=3D1 even if EE=3D0, EXT/DEC/DBELL still=20
> occur as I=20
> > recall.
>=20
> Only if directed to the hypervisor.
Yes, this is our current booehv design with EPCR[EXTGS] =3D 0.
>=20
> > > Case 1)
> > > -> Local_irq_disable() will set soft_enabled =3D 0
> > > -> Now Externel interrupt happens, there we set PACA_IRQ_EE in
> > irq_happened, Also clears EE in SRR1 and rfi. So interrupts=20
> are hard=20
> > disabled. No more other interrupt gated by MSR.EE can happen. Looks=20
> > like the idea here is to not let a device keep on inserting=20
> interrupt=20
> > till the interrupt condition on device is cleared, right?
>=20
> The external interrupt line is level sensitive normally, so=20
> we have to mask MSR:EE in that case or the interrupt would=20
> keep re-occurring (note that FSL has this concept of=20
> auto-acked interrupts via the on die MPIC for which you can=20
> potentially use PACA_IRQ_EE_EDGE instead and avoid having to=20
> mask MSR:EE).
>=20
> > I don't understand "the interrupt condition on device is cleared"
> > here.
>=20
> Well, the external interrupt line will remain asserted until=20
> the device (via the PIC) stops interrupting the processor :-)=20
Yes, the device keeps on interrupting the interrupt until the device clear =
its interrupted condition.
> Either because we mask at the PIC level (or raise the=20
> priority) or because the condition goes away.
> =20
> > I think regardless if you clear the device interrupt status, the=20
> > system still receive a pending interrupt once EE or GS =3D 1.
>=20
> Why ? Depends on your PIC actually but if it's a sane one, it=20
> won't "remember" a level interrupt that is gone. An edge=20
> interrupt is a different matter and is latched.
But the interrupt controller like MPIC should leave this irq as pending if =
we don't ACK/EOI this irq at all if we just clear the device, right?
>=20
> Some MPIC implementations tend to generate a spurrious IRQ in=20
> the case of level IRQs going away. IE. they still remember an=20
> event occurred and interrupt the processor, but on IACK=20
> return the spurious vector. However that isn't guaranteed to=20
Yes, this is just what I mean. No matter if this vector is still valid, the=
external interrupt exception always occur once EE =3D 1 again.
> be the case and it is perfectly ok (and a good
> idea) for the PIC to just stop asserting the external=20
> interrupt line if the original device interrupt goes away=20
> (and it's configured as level sensitive).
I don't remember MPIC can work with this way. So I'd like to look the manua=
l again :)
Tiejun=
^ 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