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: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] irq_guest_eoi_timer interaction with MSI
From: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Date: Thu, 13 Nov 2008 11:07:56 +0000
Cc:
Delivery-date: Fri, 14 Nov 2008 02:44:29 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C541A723.1F2DF%keir.fraser@xxxxxxxxxxxxx>
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>
References: <491BFFED.76E4.0078.0@xxxxxxxxxx> <C541A723.1F2DF%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 13.11.08 10:42 >>>
>A perfectly reasonable fix if you are not worried about guest-initiated irq
>storms (e.g. because all devices are controlled by dom0) would be to remove
>the eoi_timer logic.

No, that doesn't seem like a good idea to me.

>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 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?

Jan


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