WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] irq_guest_eoi_timer interaction with MSI

To: Jan Beulich <jbeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] irq_guest_eoi_timer interaction with MSI
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
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <491C4D90.76E4.0078.0@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AclFoWfIpiwVjrGUEd2N7wAX8io7RQ==
Thread-topic: [Xen-devel] irq_guest_eoi_timer interaction with MSI
User-agent: Microsoft-Entourage/11.4.0.080122
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