RE: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts

From: "Chen, Tiejun" <Tiejun.Chen@windriver.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Bhushan Bharat-R65777 <R65777@freescale.com>,
	Caraman Mihai Claudiu-B02008 <B02008@freescale.com>,
	Wood Scott-B07421 <B07421@freescale.com>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"agraf@suse.de" <agraf@suse.de>,
	"kvm-ppc@vger.kernel.org" <kvm-ppc@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: RE: [RFC][KVM][PATCH 1/1] kvm:ppc:booke-64: soft-disable interrupts
Date: Thu, 9 May 2013 14:13:54 +0000	[thread overview]
Message-ID: <82C960D7DF4A1F47B94FC1C67A29BEE36694AC3C@ALA-MBB.corp.ad.wrs.com> (raw)
In-Reply-To: <1368103062.25488.193.camel@pasglop>

> -----Original Message-----
> From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org] 
> Sent: Thursday, May 09, 2013 8:38 PM
> To: Chen, Tiejun
> Cc: Bhushan Bharat-R65777; 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 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.

Yes, this is our current booehv design with EPCR[EXTGS] = 0.

> 
> > > 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 :-) 

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 
> 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.

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?

> 
> 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 

Yes, this is just what I mean. No matter if this vector is still valid, the external interrupt exception always occur once EE = 1 again.

> 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).

I don't remember MPIC can work with this way. So I'd like to look the manual again :)

Tiejun