From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] IRQ: Group IRQ_MOVE_CLEANUP_VECTOR with other hypervisor IPIs Date: Thu, 8 Sep 2011 10:33:53 +0100 Message-ID: <4E688C01.8050005@citrix.com> References: <4E6886A3.3060402@citrix.com> <4E68A5120200007800055400@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4E68A5120200007800055400@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jan Beulich Cc: "xen-devel@lists.xensource.com" , Keir Fraser , "xiantao.zhang@intel.com" List-Id: xen-devel@lists.xenproject.org On 08/09/11 10:20, Jan Beulich wrote: >>>> On 08.09.11 at 11:10, Andrew Cooper wrote: >> On 08/09/11 09:15, Keir Fraser wrote: >>> On 08/09/2011 08:39, "Jan Beulich" wrote: >>> >>>>>>> On 07.09.11 at 18:56, Keir Fraser wrote: >>>>> On 07/09/2011 17:03, "Jan Beulich" wrote: >>>>> >>>>>>>>> On 07.09.11 at 17:03, Andrew Cooper wrote: >>>>>> Are you sure this is correct? I'm suspicious that this may intentionally >>>>>> have been the lowest priority vector... >>>>> I can't see why? >>>> Perhaps to get all "real" interrupts serviced first, and then do a single, >>>> consolidated run through everything that needs cleaning up? All the >>>> more since smp_irq_move_cleanup_interrupt() may re-issue the >>>> interrupt to the local CPU. >>> Ah, hm, that's a good point. We obviously livelock if we make >>> IRQ_MOVE_CLEANUP_VECTOR higher priority than the vector that >>> smp_irq_move_cleanup_interrupt() is attempting to retry. >>> >>> Andrew: I think we have to leave this vector where it is, but you could add >>> a comment explaining why it is so, in your cleanup patchset. >>> >>> -- Keir >> Wow I was having a slow day - I was thinking that >> IRQ_MOVE_CLEANUP_VECTOR was the first high priority vector. >> >> In which case it should probably stay at its current vector, but >> FIRST_DYNAMIC_VECTOR should probably be bumped up, as it is no longer a >> vector dynamically allocated to guests. > But that's merely cosmetic then, isn't it? > > Jan Yes and No. Changing NR_DYNAMIC_VECTORS removes an entry from the pending EOI stack, and alters an assert in __do_IRQ_guest(), both of which are sensible things to do. Having said that, 0x80 and 0x82 are right in the middle of the dynamic vector region, and moving them out is not really something which should be done. (It also occurs to me that now we assign randomly in the dynamic vector region, it is pot luck as to whether you MSI is going to pre-empt a hypercall or not. I don't know if this matters particularly, however) -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com