From mboxrd@z Thu Jan 1 00:00:00 1970 From: Segher Boessenkool Subject: Re: [PATCH 10/13] kvm/powerpc: Add support for Book3S processors in hypervisor mode Date: Fri, 27 May 2011 22:59:41 +0200 Message-ID: References: <20110511103443.GA2837@brick.ozlabs.ibm.com> <20110511104456.GK2837@brick.ozlabs.ibm.com> <20110516055809.GA3590@drongo> <20110527103334.GA4236@brick.ozlabs.ibm.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: Linuxppc-dev , KVM list , kvm-ppc@vger.kernel.org, Alexander Graf To: Paul Mackerras Return-path: In-Reply-To: <20110527103334.GA4236@brick.ozlabs.ibm.com> Sender: kvm-ppc-owner@vger.kernel.org List-Id: kvm.vger.kernel.org >>> I do the check there because I was having problems where, if the HDEC >>> goes negative before we do the partition switch, we would >>> occasionally >>> not get the HDEC interrupt at all until the next time HDEC went >>> negative, ~ 8.4 seconds later. >> >> Yikes - so HDEC is edge and doesn't even keep the interrupt line up? >> That sounds like a serious hardware limitation. What if you only use >> HDEC and it triggers while interrupts are off in a critical section? >> Is the hardware really that broken? > > If HDEC expires when interrupts are off, the HDEC interrupt stays > pending until interrupts get re-enabled. I'm not sure exactly what > the conditions are that cause an HDEC interrupt to get lost, but they > seem to involve at least a partition switch. On some CPUs, if the top bit of the decrementer is 0 again when you re-enable the interrupt, the interrupt is lost (so it is actually level-triggered). The arch books talk a bit about this AFAIR. Segher From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 41997B6F7C for ; Sat, 28 May 2011 06:58:04 +1000 (EST) In-Reply-To: <20110527103334.GA4236@brick.ozlabs.ibm.com> References: <20110511103443.GA2837@brick.ozlabs.ibm.com> <20110511104456.GK2837@brick.ozlabs.ibm.com> <20110516055809.GA3590@drongo> <20110527103334.GA4236@brick.ozlabs.ibm.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: From: Segher Boessenkool Subject: Re: [PATCH 10/13] kvm/powerpc: Add support for Book3S processors in hypervisor mode Date: Fri, 27 May 2011 22:59:41 +0200 To: Paul Mackerras Cc: Linuxppc-dev , kvm-ppc@vger.kernel.org, KVM list , Alexander Graf List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , >>> I do the check there because I was having problems where, if the HDEC >>> goes negative before we do the partition switch, we would >>> occasionally >>> not get the HDEC interrupt at all until the next time HDEC went >>> negative, ~ 8.4 seconds later. >> >> Yikes - so HDEC is edge and doesn't even keep the interrupt line up? >> That sounds like a serious hardware limitation. What if you only use >> HDEC and it triggers while interrupts are off in a critical section? >> Is the hardware really that broken? > > If HDEC expires when interrupts are off, the HDEC interrupt stays > pending until interrupts get re-enabled. I'm not sure exactly what > the conditions are that cause an HDEC interrupt to get lost, but they > seem to involve at least a partition switch. On some CPUs, if the top bit of the decrementer is 0 again when you re-enable the interrupt, the interrupt is lost (so it is actually level-triggered). The arch books talk a bit about this AFAIR. Segher From mboxrd@z Thu Jan 1 00:00:00 1970 From: Segher Boessenkool Date: Fri, 27 May 2011 20:59:41 +0000 Subject: Re: [PATCH 10/13] kvm/powerpc: Add support for Book3S processors in hypervisor mode Message-Id: List-Id: References: <20110511103443.GA2837@brick.ozlabs.ibm.com> <20110511104456.GK2837@brick.ozlabs.ibm.com> <20110516055809.GA3590@drongo> <20110527103334.GA4236@brick.ozlabs.ibm.com> In-Reply-To: <20110527103334.GA4236@brick.ozlabs.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Paul Mackerras Cc: Linuxppc-dev , KVM list , kvm-ppc@vger.kernel.org, Alexander Graf >>> I do the check there because I was having problems where, if the HDEC >>> goes negative before we do the partition switch, we would >>> occasionally >>> not get the HDEC interrupt at all until the next time HDEC went >>> negative, ~ 8.4 seconds later. >> >> Yikes - so HDEC is edge and doesn't even keep the interrupt line up? >> That sounds like a serious hardware limitation. What if you only use >> HDEC and it triggers while interrupts are off in a critical section? >> Is the hardware really that broken? > > If HDEC expires when interrupts are off, the HDEC interrupt stays > pending until interrupts get re-enabled. I'm not sure exactly what > the conditions are that cause an HDEC interrupt to get lost, but they > seem to involve at least a partition switch. On some CPUs, if the top bit of the decrementer is 0 again when you re-enable the interrupt, the interrupt is lost (so it is actually level-triggered). The arch books talk a bit about this AFAIR. Segher