Unfortunately this is the wrong way to fix the issue: Xen has a range of
allowed pirq for each domain and we don't know exactly what is the
maximum pirq (see my patch "xen: get the maximum number of pirqs from
xen" [1]).
Considering that we might use the irq number returned by
find_unbound_irq through xen_allocate_pirq as pirq number in some cases,
starting from the highest value could be unsafe.
In practice it should be impossible to see this issue because it can
only happen if the irq returned by xen_allocate_pirq is higher than the
max pirq in xen. However AFAIK when we call xen_allocate_pirq with the
intention of using the return value as pirq we always fall in the if
(identity_mapped_irq(gsi) || !xen_initial_domain()) that avoid calling
find_unbound_irq.
In any case I still think that it is a good idea to try to avoid the problem.
In order to solve this issue you can:
- add a static offset to get_nr_hw_irqs in case of pv domains;
- use the patch "xen: get the maximum number of pirqs from
xen" [1] to get the highest possible pirq number from xen so that we can be
sure we are using an allowed value;
- if the xen interface allows it, disjoin the concept of pirq from the
concept of linux irq; then you can let xen choose any pirq number it
wants (see my patch "xen: support pirq != irq" [2] and how you can exploit
it in the patch "xen: implement xen_hvm_register_pirq" [3]).
Of course this doesn't help if it must be linux the one that chooses the
pirq number.
Feel free to pick up any of the patches I sent as part of the "PV on
HVM: receive interrupts as xen events" series.
References:
[1] http://lkml.org/lkml/2010/8/30/177
[2] http://lkml.org/lkml/2010/8/30/171
[3] http://lkml.org/lkml/2010/8/30/172
--
