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 15:28:10 +0000 Message-ID: <491C559A.76E4.0078.0@novell.com> References: <491C4D90.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 Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> Keir Fraser 13.11.08 16:06 >>> >On 13/11/08 14:53, "Jan Beulich" 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. But then there'd be a hypercall for each MSI instance, most of the time without any real need. With a high interrupt rate I'm afraid this does matter. Jan