From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GWTGh-00027P-CS for qemu-devel@nongnu.org; Sun, 08 Oct 2006 03:40:15 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GWTGf-00027A-NA for qemu-devel@nongnu.org; Sun, 08 Oct 2006 03:40:14 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GWTGf-000277-KP for qemu-devel@nongnu.org; Sun, 08 Oct 2006 03:40:13 -0400 Received: from [66.249.82.228] (helo=wx-out-0506.google.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GWTNw-00064E-Su for qemu-devel@nongnu.org; Sun, 08 Oct 2006 03:47:45 -0400 Received: by wx-out-0506.google.com with SMTP id r21so1675886wxc for ; Sun, 08 Oct 2006 00:40:12 -0700 (PDT) Message-ID: <84e41160610080040o383825a4o255df0ff8cc228d7@mail.gmail.com> Date: Sun, 8 Oct 2006 15:40:12 +0800 From: "Donald Liew" Subject: Re: [Qemu-devel] why do qem/arm not clear CPU_INTERRUPT_HARD bit of env->interrupt_request automatically? In-Reply-To: <200610080323.21706.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_148913_19521978.1160293212763" References: <84e41160610071115t75b4ec55vbe656630d5ab9373@mail.gmail.com> <200610080323.21706.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org ------=_Part_148913_19521978.1160293212763 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline i see. you are right, thanks very much 2006/10/8, Paul Brook : > > On Saturday 07 October 2006 19:15, Donald Liew wrote: > > i'm reading qemu-system-arm code and trying to add some more > > evaluation boards support for it. in the 0.8.2 source code i found > > something i can't understand, when handling interrupts all other > > targets clears this bit after calling do_interrupt, however the arm > > target doesn't do this, why? won't this cause problems like redundant > > interrupts? any special consideration about this? > > I this this is the correct behavior. The nIRQ line is level triggered. > spurious interrupts are avoided because do_interrupt sets the CPSR_I flag. > > During normal operation theguest OS will clear the IRQ condition (by > masking > the interrupt on the PIC or device) before clearing the CPSE_I flag, so it > doesn't matter what we do. > > Consider the case where the guest OS were to clear CPSR_F without touching > the > IRQ line. In this case we would expect annother IRQ exception to be taken > immediately. If (as you suggest above) we cleared CPU_INTERRUPT_HARD in > cpu_exec then the IRQ would not be taken until something re-raised the IRQ > line. > > Paul > ------=_Part_148913_19521978.1160293212763 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline i see. you are right, thanks very much

2006/10/8, Paul Brook <paul@codesourcery.com>:
On Saturday 07 October 2006 19:15, Donald Liew wrote:
> i'm reading qemu-system-arm code and trying to add some more
> evaluation boards support for it. in the 0.8.2 source code i found
> something i can't understand, when handling interrupts all other
> targets clears this bit after calling do_interrupt, however the arm
> target doesn't do this, why? won't this cause problems like redundant
> interrupts? any special consideration about this?

I this this is the correct behavior. The nIRQ line is level triggered.
spurious interrupts are avoided because do_interrupt sets the CPSR_I flag.

During normal operation theguest OS will clear the IRQ condition (by masking
the interrupt on the PIC or device) before clearing the CPSE_I flag, so it
doesn't matter what we do.

Consider the case where the guest OS were to clear CPSR_F without touching the
IRQ line. In this case we would expect annother IRQ exception to be taken
immediately. If (as you suggest above) we cleared CPU_INTERRUPT_HARD in
cpu_exec then the IRQ would not be taken until something re-raised the IRQ
line.

Paul

------=_Part_148913_19521978.1160293212763--