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

Re: [Xen-devel] irq_guest_eoi_timer interaction with MSI


  • To: Jan Beulich <jbeulich@xxxxxxxxxx>
  • From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Date: Thu, 13 Nov 2008 15:06:29 +0000
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 13 Nov 2008 07:06:56 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AclFoWfIpiwVjrGUEd2N7wAX8io7RQ==
  • Thread-topic: [Xen-devel] irq_guest_eoi_timer interaction with MSI

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.