qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 5/6] [RFC] Emulation of Leon3.


From: Blue Swirl
Subject: Re: [Qemu-devel] [PATCH 5/6] [RFC] Emulation of Leon3.
Date: Mon, 20 Dec 2010 20:09:23 +0000

On Mon, Dec 20, 2010 at 9:40 AM, Fabien Chouteau <address@hidden> wrote:
> On 12/20/2010 07:46 AM, Edgar E. Iglesias wrote:
>>
>> On Fri, Dec 17, 2010 at 07:14:20PM +0000, Blue Swirl wrote:
>>>
>>> On Wed, Dec 15, 2010 at 5:47 PM, Fabien Chouteau<address@hidden>
>>>  wrote:
>>>>
>>>> On 12/13/2010 07:18 PM, Blue Swirl wrote:
>>>>>
>>>>> On Mon, Dec 13, 2010 at 3:51 PM, Fabien Chouteau<address@hidden>
>>>>>  wrote:
>>>>>>
>>>>>> On 12/11/2010 10:56 AM, Blue Swirl wrote:
>>>>>>>
>>>>>>> On Tue, Dec 7, 2010 at 11:40 AM, Fabien
>>>>>>> Chouteau<address@hidden>
>>>>>>>  wrote:
>>>>>>>>
>>>>>>>> On 12/06/2010 06:53 PM, Blue Swirl wrote:
>>>>>>>>>
>>>>>>>>> On Mon, Dec 6, 2010 at 9:26 AM, Fabien
>>>>>>>>> Chouteau<address@hidden>
>>>>>>>>>  wrote:
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Fabien Chouteau<address@hidden>
>>>>>>>>>> ---
>>
>> ...
>>
>>>>>>>>>>  #ifdef DEBUG_PCALL
>>>>>>>>>>     if (qemu_loglevel_mask(CPU_LOG_INT)) {
>>>>>>>>>>         static int count;
>>>>>>>>>> @@ -4135,6 +4153,14 @@ void do_interrupt(CPUState *env)
>>>>>>>>>>     env->pc = env->tbr;
>>>>>>>>>>     env->npc = env->pc + 4;
>>>>>>>>>>     env->exception_index = -1;
>>>>>>>>>> +
>>>>>>>>>> +#if !defined(CONFIG_USER_ONLY)
>>>>>>>>>> +    /* IRQ acknowledgment for Leon3 */
>>>>>>>>>> +    if (env->version == 0xf3000000&&        (intno&        ~15)
>>>>>>>>>> ==
>>>>>>>>>> TT_EXTINT)
>>>>>>>>>> {
>>>>>>>>>> +        grlib_irqmp_ack (env, intno);
>>>>>>>>>> +        leon3_cache_control_int();
>>>>>>>>>> +    }
>>>>>>>>>
>>>>>>>>> Like this. I don't think a CPU should immediately ack any incoming
>>>>>>>>> interrupts.
>>>>>>>>
>>>>>>>> Leon3 does...
>>>>>>>
>>>>>>> Strange. Then this should be handled at board level (leon3.c).
>>>>>>
>>>>>> Well, it's a CPU feature not a board feature.
>>>>>
>>>>> Maybe, but we don't want to clutter interrupt handling with this.
>>>>
>>>> I don't see what you expect here... How can I get the acknowledgment
>>>> information without changing the do_interrupt function?
>>>
>>> Board can acknowledge the interrupt just before calling cpu_interrupt().
>>
>> Hi,
>>
>> I don't think that will work properly. IIUC, the leon acks the irq when it
>> is actually taken by the CPU. Due to CPU internal masking, that may be at
>> a later point than when the irq is signalled to the CPU.
>
> Exactly I've forget to mention that. Raising the interrupt do not mean that
> the
> CPU will handle it directly, for example if traps are disabled or if the CPU
> handles an higher priority interrupt at the moment.

I think there is no way to avoid the performance penalty then.

>> IMO, what is needed is something along the lines of what Fabien coded but
>> with some level of indirection so that the CPU doesn't call directly into
>> the irqmp model. Maybe through ack function pointers or through a
>> qemu_irq ack line or some other way. The board should then setup the
>> connection between the ack mechanism and the irqmp model.
>>
>
> The function pointer is a good idea, something like:
>
> if (env->qemu_irq_ack != NULL) {
>    env->qemu_irq_ack(intno);
> }
>
> And actually this will help me to implement others machines (erc32 and
> leon2).

OK. Alternatively there could be a stub function which is used in
place of NULL, so that the if () can be avoided, but maybe this is
better.

If direct interrupt acks would be interesting also for x86 LAPIC, then
a more generic solution could be to introduce a new
env->interrupt_request flag,  CPU_INTERRUPT_ACK, which could be tested
in common code of cpu-exec.c.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]