On 09/17/2012 08:18 PM, Gilles Chanteperdrix wrote:
> On 09/17/2012 08:15 PM, Jan Kiszka wrote:
>
>> On 2012-09-17 20:12, Jan Kiszka wrote:
>>> On 2012-09-17 20:08, Gilles Chanteperdrix wrote:
>>>> On 09/17/2012 08:05 PM, Jan Kiszka wrote:
>>>>
>>>>> On 2012-09-17 19:46, Gilles Chanteperdrix wrote:
>>>>>> ipipe_end is a nop when called from primary domain, yes, but this is not
>>>>>> very different from edge irqs. Also, fasteoi become a bit like MSI: in
>>>>>> the same way as we can not mask MSI from primary domain, we should not
>>>>>> mask IO-APIC fasteoi irqs, because the cost is too prohibitive. If we
>>>>>> can live with MSI without masking them in primary mode, I guess we can
>>>>>> do the same with fasteoi irqs.
>>>>>
>>>>> MSIs are edge triggered, fasteois are still level-based. They require
>>>>> masking at the point you defer them - what we do and what Linux may even
>>>>> extend beyond that. If you mask them by raising the task priority, you
>>>>> have to keep it raised until Linux finally handled the IRQ.
>>>>
>>>>
>>>> Yes.
>>>>
>>>>> Or you
>>>>> decide to mask it at IO-APIC level again.
>>>>
>>>>
>>>> We do not want that.
>>>>
>>>>> If you keep the TPR raised,
>>>>> you will block more than what Linux wants to block.
>>>>
>>>>
>>>> The point is that if the TPR keeps raised, it means that primary domain
>>>> has preempted Linux, so, we want it to keep that way. Otherwise the TPR
>>>> gets lowered when Linux has handled the interrupt.
>>>>
>>>> A week-end of testing made me sure of one thing: it works. I assure you.
>>>
>>> Probably, in the absence of IRQF_ONESHOT Linux interrupts. No longer if
>>> you face threaded IRQs - I assure you.
>>
>> Well, it may work (if mask/unmask callbacks work as native) but the
>> benefit is gone: masking at IO-APIC level will be done again. Given that
>> threaded IRQs become increasingly popular, it will also be hard to avoid
>> them in common setups.
>
>
> The thing is, if we no longer use the IO-APIC spinlock from primary
> domain, we may not have to turn it into an ipipe_spinlock, and may be
> able to preempt the IO-APIC masking.
>
No, we need it in ack_apic_level in the IO-APIC erratum case.
--
Gilles.
_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
http://www.xenomai.org/mailman/listinfo/xenomai
