[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] MIPS interrupts and -icount
From: |
Aurelien Jarno |
Subject: |
Re: [Qemu-devel] [PATCH] MIPS interrupts and -icount |
Date: |
Sun, 25 Jul 2010 16:58:36 +0200 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
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 <address@hidden>
> Tested-by: Edgar E. Iglesias <address@hidden>
>
> Would you mind applying your patch on top of mine?
>
Thanks for the tests, I have just applied it.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
address@hidden http://www.aurel32.net