[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.