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

[Roger Pau Monne <roger.pau@xxxxxxxxxx>]

On Tue, Apr 18, 2017 at 02:39:34AM -0600, Jan Beulich wrote:
> >>> On 17.04.17 at 18:09, <roger.pau@xxxxxxxxxx> 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?  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);

Just in case.

Thanks, Roger.


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