Re: [Xen-devel] irq_guest_eoi_timer interaction with MSI

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

On 13/11/08 14:53, "Jan Beulich" <jbeulich@xxxxxxxxxx> wrote:

> Avoiding the EOI query is certainly a secondary issue. What I was asking
> was rather a means for the guest to know whether Xen started that EOI
> timer, so that it could indicate to Xen to terminate it and unmask the
> respective IRQ. This shouldn't require always using PHYSDEVOP_eoi, and
> from an abstract point of view also would belong there, but rather in
> unmask_evtchn(). Since it would be an obvious thing that if you unmask
> an event channel, you also want the underlying PIRQ unmasked, this
> could be a compatible addition to the existing EVTCHNOP_unmask. The
> only thing missing is a way for the guest to know when to actually use
> the hypercall based unmasking - that's what I wanted to add a vector
> for.

PHYSDEVOP_eoi and unmask happen at the same time for pirqs. The fact that we
only need this new mechanism for pirqs, and that we already have a gated
hypercall for pirq eoi (and can gate it further if need be) is an argument
for hanging this off PHYSDEVOP_eoi imo.

>> 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.
> 
> Like this you mean? Lightly tested it appears to work (but not tested on a
> problem system, yet).

Yes, a patch like this would be a good thing.

 -- Keir



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel