Re: [Qemu-devel] [PATCH v2 6/8] cpu: make CPU_INTERRUPT_RESET available on all targets

[Paolo Bonzini]

Il 24/05/2014 17:54, Peter Maydell ha scritto:
> On 24 May 2014 13:59, Paolo Bonzini <address@hidden> wrote:
> > Il 24/05/2014 10:30, Peter Maydell ha scritto:
> > > Well, I'm planning to move the bodies of all the ifdefs into
> > > a cpu_check_interrupts() provided by the target's cpu.h[*].
> > > This x86 bit is just awkward because it means there's
> > > x86 stuff both before and after the generic reset code.
> >
> > What about
> >
> >         if (interrupt_request & CPU_INTERRUPT_DEBUG) {
> >             cpu->interrupt_request &= ~CPU_INTERRUPT_DEBUG;
> >             cpu->exception_index = EXCP_DEBUG;
> >             cpu_loop_exit(cpu);
> >         }
> >         if (!cpu_check_interrupts(...)) {
> >             if (interrupt_request & CPU_INTERRUPT_HALT) {
> >                 cpu->interrupt_request &= ~CPU_INTERRUPT_HALT;
> >                 cpu->halted = 1;
> >                 cpu->exception_index = EXCP_HLT;
> >                 cpu_loop_exit(cpu);
> >             }
> >             if (interrupt_request & CPU_INTERRUPT_RESET) {
> >                 cpu_reset(cpu);
> >             }
> >         }
> >
> > Then:
> > - only X86 returns 1 for CPU_INTERRUPT_RESET
> > - all except ARM/SPARC/MIPS/PPC/Alpha/cris/MicroBlaze/LM32/Unicore32
> > return 1 for CPU_INTERRUPT_HALT
>
> That last point sounds wrong, at least -- halt should work
> the same way for everything. If the target doesn't want
> to halt it should never set the HALT bit in interrupt_request.

Yes, you're right.  Those targets simply do not use CPU_INTERRUPT_HALT 
to halt the VPU.

> > We have that already for cc->do_interrupt, which could be
> > "devirtualized" if you add a check_interrupts method...  In
> > the end you'd be adding a function pointer call for all
> > interrupt requests but removing one for CPU_INTERRUPT_HARD
> > (and FIQ too on ARM).  That should be a wash.
>
> But we only call cc->do_interrupt if we're going to actually
> *take* an interrupt, in which case the bulk of the cost is
> actually doing the work. I don't want to call via a pointer
> just for the other end to say "actually PSTATE_I is set
> because the guest has interrupts blocked, so don't do
> anything".

Isn't the cost of exiting the translated code (such as the hash table 
lookup and qemu_cpu_kick itself) orders of magnitude higher than the 
cost of the indirect call?

Furthermore, if this were a problem, you could latch the interrupt when 
you get CPU_INTERRUPT_HARD, and trigger it in the instruction that 
resets PSTATE_I.  This would avoid examining cpu->interrupt_request on 
all TB exits between generation of the interrupt and clearing of PSTATE_I.

Paolo