On 08/09/11 10:20, Jan Beulich wrote:
>>>> On 08.09.11 at 11:10, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 08/09/11 09:15, Keir Fraser wrote:
>>> On 08/09/2011 08:39, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>>>
>>>>>>> On 07.09.11 at 18:56, Keir Fraser <keir.xen@xxxxxxxxx> wrote:
>>>>> On 07/09/2011 17:03, "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>>>>>
>>>>>>>>> On 07.09.11 at 17:03, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home