Re: [Qemu-devel] [PATCH] MIPS interrupts and -icount

[Aurelien Jarno <aurelien@aurel32.net>]

On Sun, Jul 25, 2010 at 09:21:48AM +0200, Edgar E. Iglesias wrote:
> On Sun, Jul 25, 2010 at 07:52:18AM +0200, Edgar E. Iglesias wrote:
> > On Sun, Jul 25, 2010 at 06:44:41AM +0200, Aurelien Jarno wrote:
> > > On Sun, Jul 25, 2010 at 05:08:07AM +0200, Aurelien Jarno wrote:
> > > > On Sun, Jul 25, 2010 at 02:07:54AM +0200, Edgar E. Iglesias wrote:
> > > > > On Sun, Jul 25, 2010 at 12:55:45AM +0200, Aurelien Jarno wrote:
> > > > > > On Thu, Jul 22, 2010 at 01:32:18PM +0200, Edgar E. Iglesias wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > I'm seeing an error when emulating MIPS guests with -icount.
> > > > > > > In cpu_interrupt:
> > > > > > >   cpu_abort(env, "Raised interrupt while not in I/O function");
> > > > > > 
> > > > > > I am not able to reproduce the issue. Do you have more details how to
> > > > > > reproduce the problem?
> > > > > 
> > > > > You need a machine with devices that raise the hw interrupts. I didn't
> > > > > see the error on the images on the wiki though. But I've got a machine
> > > > > here that trigs it easily. Will check if I can publish it and an image.
> > > > > 
> > > > 
> > > > That would be nice if you can share it.
> > > > 
> > > > > > > It seems to me like the MIPS interrupt glue logic between interrupt
> > > > > > > controllers and the MIPS core is not modeled correctly.
> > > > > > 
> > > > > > It seems indeed that sometimes interrupt are triggered while not in 
> > > > > > I/O functions, your patch addresses part of the problem.
> > > > > > 
> > > > > > > When hw interrupt pending bits in CP0_Cause are set, the CPU should
> > > > > > > see the hw interrupt line as active. The CPU may or may not take the
> > > > > > > interrupt based on internal state (global irq mask etc) but the glue
> > > > > > > logic shouldn't care about that. Am I missing something here?
> > > > > > 
> > > > > > I don't think it is correct. On the real hardware, the interrupt line is
> > > > > > actually active only when all conditions are fulfilled.
> > > > > > 
> > > > > > The thing to remember is that the interrupts are level triggered. So if
> > > > > > an interrupt is masked, it should be rejected by the CPU, but could be
> > > > > > triggered again as soon as the interrupt mask is changed.
> > > > > 
> > > > > Agreed, that behaviour is what I'm trying to acheive. The problem now
> > > > > is that the the level triggered line, prior to CPU masking is beeing masked
> > > > > by external logic. IMO it shouldnt. See hw/mips_int.c and cpu-exec.c prior
> > > > > to the patch.
> > > > 
> > > > Actually all depends if you consider the MIPS interrupt controller part
> > > > of the CPU or not. It could be entirely modeled in the CPU, that is in 
> > > > cpu-exec.c or entirely modeled as a separate controller, that is in 
> > > > mips_int.c.
> > > >
> > > 
> > > If we choose having the interrupt controller as part of the CPU, which
> > > seems to be what you have chosen, the following patch should fix the
> > > remaining issues (and prepare the work for vector interrupt support):
> > 
> > Thanks,
> > 
> > That looks nice, specially the removing of the helper_interrupt_restart
> > parts :)
> > 
> > I'll test it on my side and send you an ACK.
> 
> 
> I've tested this with the same images as before, they still work.
> I also created a synthetic testcase for the 2 software interrupt
> lines and they seem to behave OK. Our linux port was not so
> happy about seeing those raised though, so I had to hack a bit
> to see them in action :)
> 
> Acked-by: Edgar E. Iglesias <edgar@axis.com>
> Tested-by: Edgar E. Iglesias <edgar@axis.com>
> 
> Would you mind applying your patch on top of mine?
> 

Thanks for the tests, I have just applied it.

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net