From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: irq_guest_eoi_timer interaction with MSI Date: Thu, 13 Nov 2008 11:07:56 +0000 Message-ID: <491C189C.76E4.0078.0@novell.com> References: <491BFFED.76E4.0078.0@novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> Keir Fraser 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