Re: irq_guest_eoi_timer interaction with MSI

[Keir Fraser <keir.fraser@eu.citrix.com>]

On 13/11/08 11:07, "Jan Beulich" <jbeulich@novell.com> wrote:

>> Otherwise we could relax it some (e.g., require N IRQs
>> to get stacked up rather than just 1; or add explicit rate limiting).
> 
> For the main problem at hand, that would just reduce the likelihood of the
> device refusing to work. For the performance issue, that would be an
> option, as would be reducing the timeout value. However, I would also
> consider making EVTCHNOP_unmask clear that state, and then perhaps
> find a way to tell the guest that it should call this even if unmask_evtchn()
> finds the event channel to be bound to the local CPU. The obvious thing
> would be to either extend shared_info or have the guest register an
> address with Xen where per-event-channel overflow status would be
> reported by Xen.

We already have PHYSDEVOP_eoi. We can force guests to always use that. It'll
be no slower than level-triggered IO-APIC IRQs, which we've been using since
forever with no complaints. And yeah, as an extension we could have a
shared-memory pirq bitmap to indicate dynamically whether eoi is required.
Quite a secondary concern though, I would say.

>> We only disable MSI when the device does not support masking. Perhaps we
>> should make disable/enable no-ops in that case?
> 
> Yes, but don't we need an alternative way to avoid storms then?

We should be delaying LAPIC EOI, just as we do for level-triggered IO-APIC
IRQs (in that case, because masking RTEs in some cases has stupid side
effects on some damn stupid chipsets). All that logic exists, just needs
plumbing in for this particular class of non-maskable MSI.

 -- Keir