[RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
Kevin Hao
haokexin at gmail.com
Thu May 9 18:08:13 EST 2013
On Thu, May 09, 2013 at 07:51:09AM +0000, Bhushan Bharat-R65777 wrote:
>
>
> > -----Original Message-----
> > From: tiejun.chen [mailto:tiejun.chen at windriver.com]
> > Sent: Thursday, May 09, 2013 1:18 PM
> > To: Bhushan Bharat-R65777
> > Cc: Caraman Mihai Claudiu-B02008; Wood Scott-B07421; linuxppc-
> > dev at lists.ozlabs.org; agraf at suse.de; kvm-ppc at vger.kernel.org;
> > kvm at 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 at 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 at lists.ozlabs.org; agraf at suse.de;
> > >> kvm-ppc at vger.kernel.org; kvm at 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 at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20130509/44fcb93a/attachment-0001.sig>
More information about the Linuxppc-dev
mailing list