Re: [PATCH for-4.9] x86/vioapic: allow holes in the GSI range for PVH Dom0

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 18/04/2017 09:49, Roger Pau Monne wrote:
> On Tue, Apr 18, 2017 at 02:39:34AM -0600, Jan Beulich wrote:
>>>>> On 17.04.17 at 18:09, <roger.pau@citrix.com> wrote:
>>> @@ -601,7 +587,12 @@ int vioapic_init(struct domain *d)
>>>          nr_gsis += nr_pins;
>>>      }
>>>  
>>> -    ASSERT(hvm_domain_irq(d)->nr_gsis == nr_gsis);
>>> +    /*
>>> +     * NB: hvm_domain_irq(d)->nr_gsis is actually the highest GSI + 1, but
>>> +     * there might be holes in this range (ie: GSIs that don't belong to any
>>> +     * vIO APIC).
>>> +     */
>>> +    ASSERT(hvm_domain_irq(d)->nr_gsis >= nr_gsis);
>> This becomes too weak then, as you want to index the array using
>> the GSI (and not some compressed representation with the holes
>> squashed). Which in turn means the nr_gsis calculation in this
>> function is now wrong - you need to accumulate the maximum
>> base_gsi + nr_pins value here instead. With that >= will actually
>> be fine to use here.
> Is the array of IO APICs guaranteed to be ordered from lower GSI to highest
> one?

I would certainly not bet on it.

>   So far it seems like it is on all the machines I've tested, but I'm not
> sure this is a guarantee, thus I'm going to use:
>
> nr_gsis = max(nr_gsis, base_gsi + nr_pins);

This is indeed the right thing to do.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel