From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: irq_guest_eoi_timer interaction with MSI Date: Fri, 14 Nov 2008 13:00:13 +0000 Message-ID: <491D846D.76E4.0078.0@novell.com> References: <491D52E8.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 14.11.08 10:42 >>> >On 14/11/08 09:28, "Jan Beulich" wrote: > >>> So we'd add a pirq-indexed bitmap to mitigate that. Whether we use >>> PHYSDEVOP_irq_eoi or EVTCHNOP_unmask, we need a new shared-memory = bitmap, >>> right? Might as well use irq_eoi and index by pirq, I'd say. >>=20 >> Hmm, I'm still not convinced: With what you propose, it's unclear to me = who >> would when clear the bit in that bitmap for the 'temporarily masked' = case. >> Anyway, unless you get to implement your version earlier (and thus >> convince me that things will work out correctly), I'll try to get = implemented >> what I would think should be appropriate here once I find time to do = so. > >Perhaps if we go your route we can make PHYSDEVOP_irq_eoi obsolete? It's >only really called where we also do an unmask, and it's pointless to have >two hypercalls where one will do. So a guest that detects the new bitmap >could then know it only needs to unmask-by-hypercall, rather than use >PHYSDEVOP_irq_eoi at all. Yes, folding the potentially two hypercalls into one was a parallel idea. Jan