[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |