These functions take irq_data as an argument and avoid a redundant
lookup in the sparse irq case.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Converted with coccinelle.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>

drivers/xen/events.c:396: error: 'struct irq_data' has no member named 'affinity'
Reported-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

One of those spin_lock() calls should be an unlock...
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Running out of IRQs need not be fatal to the machine as a whole.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

With the introduction of e7bcecb7 "genirq: Make nr_irqs runtime expandable"
nr_irqs can grow as necessary to accommodate our allocation requests.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

There isn't really much relationship between the two, other than
nr_irqs often being the larger of the two.

Allows us to remove a nr_irqs sized array, the only users of this
array are MSI setup and restore, neither of which are particularly
performance critical.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Removes nr_irq sized array allocation at start of day.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

In a PVHVM kernel not all interrupts are Xen interrupts (APIC interrupts can also be present).

Currently we get away with walking over all interrupts because the
lookup in the irq_info array simply returns IRQT_UNBOUND and we ignore
it. However this array will be going away in a future patch so we need
to manually track which interrupts have been allocated by the Xen
events infrastructure.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Encapsulate setup of XXX_to_irq array in the relevant
xen_irq_info_*_init function.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

I can't see any reason why it isn't already.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Following the example set by xen_allocate_pirq_msi and
xen_bind_pirq_msi_to_irq:

xen_allocate_pirq becomes xen_allocate_pirq_gsi and now only allocates
a pirq number and does not bind it.

xen_map_pirq_gsi becomes xen_bind_pirq_gsi_to_irq and binds an
existing pirq.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

There is nothing per-cpu about this function.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

I was unable to find any user of these functions in either the
functionality pending for 2.6.39 or the xen/next-2.6.32 branch of
xen.git

An exception to this was xen_gsi_from_irq which did appear to be used
in xen/next-2.6.32's pciback. However in the 2.6.39 version of pciback
xen_pirq_from_irq is, correctly AFAICT, used instead.

Only a minority of functions in events.h use "extern" so drop it from
those places for consistency.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Fix initial value of irq so that first goto out (if pirq or gsi
arguments are too large) actually returns an error.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

It is never valid assume any particular relationship between a Xen
PIRQ number and and Linux IRQ number so there is no need to hedge when
saying so.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Clarifies which bit the comment applies to.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Signed-off-by: NKeir Fraser <keir.fraser@citrix.com>
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
[ijc: forward ported from linux-2.6.18-xen.hg 991:9ba6d9f3fbc0]
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

(except for starting l2 word, which we scan in two parts).
Signed-off-by: NKeir Fraser <keir.fraser@citrix.com>
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
[ijc: forward ported from linux-2.6.18-xen.hg 990:427276ac595d]
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Also fixes a couple of boundary cases.
Signed-off-by: NKeir Fraser <keir.fraser@citrix.com>
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
[ijc: forward ported from linux-2.6.18-xen.hg 988:c88a02a22a05]
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
[ijc: forward ported from linux-2.6.18-xen.hg 325:b2768401db94]
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Avoids fairness issue resulting from domain 0 processing lowest
numbered event channel first.

Fixes bug #1115 "Event channel port scanning unfair".

Bugzilla: http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1115Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
[ijc: forward ported from linux-2.6.18-xen.hg 324:7fe1c6d02a2b
 various variables have different names in this tree:
  l1  -> pending_words
  l2  -> pending_bits
  l1i -> word_idx
  l2i -> bit_idx]
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

The function name does not distinguish it from xen_allocate_pirq_msi
(which operates on domU and pvhvm domains rather than dom0).

Hoist domain 0 specific functionality up into the only caller leaving
functionality common to all guest types in xen_bind_pirq_msi_to_irq.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Makes the tail end of this function look even more like
xen_bind_pirq_msi_to_irq.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

I don't think this was a deliberate ommision.

Makes the tail end of this function look even more like
xen_bind_pirq_msi_to_irq.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Calling PHYSDEVOP_map_pirq earlier simplifies error handling and
starts to make the tail end of this function look like
xen_bind_pirq_msi_to_irq.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Split the binding aspect of xen_allocate_pirq_msi out into a new
xen_bind_pirq_to_irq function.

In xen_hvm_setup_msi_irq when allocating a pirq write the MSI message
to signal the PIRQ as soon as the pirq is obtained. There is no way to
free the pirq back so if the subsequent binding to an IRQ fails we
want to ensure that we will reuse the PIRQ next time rather than leak
it.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

The find_unbound_pirq is called only from xen_allocate_pirq_msi and
only if alloc_pirq is true. The only caller which does this is
xen_hvm_setup_msi_irqs. The use of this function is gated, in
pci_xen_hvm_init, on XENFEAT_hvm_pirqs.

The PHYSDEVOP_get_free_pirq interfaces was added to the hypervisor in
22410:be96f6058c05 while XENFEAT_hvm_pirqs was added a couple of
minutes prior in 22409:6663214f06ac. Therefore we do not need to
concern ourselves with hypervisors which support XENFEAT_hvm_pirqs but
not PHYSDEVOP_get_free_pirq.

This eliminates the fallback path in find_unbound_pirq which walks to
pirq_to_irq array looking for a free pirq. Unlike the
PHYSDEVOP_get_free_pirq interface this fallback only looks up a free
pirq but does not reserve it. Removing this fallback will simplify
locking in the future.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

consistent with other similar functions.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

All callers pass this flag so it is pointless.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Cc: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: xen-devel@lists.xensource.com
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

We only did this for PV guests that are xen_initial_domain() but
there is not reason not to do this for other cases. The other
case is only exercised when you pass in a PCI device to a PV guest
_and_ the device in question.
Reviewed-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Mark the IRQF_NO_SUSPEND interrupts IRQF_FORCE_RESUME and remove the extra
walk through the interrupt descriptors.
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

drivers/xen/events.c: In function 'ack_pirq':
drivers/xen/events.c:568: error: implicit declaration of function 'irq_move_irq'
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Convert Xen to the new irq_chip functions. Brings us closer to enable
CONFIG_GENERIC_HARDIRQS_NO_DEPRECATED
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

irq_chip.end got obsolete with the removal of __do_IRQ()
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
Acked-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

c514d00c8057 "xen: events: add xen_allocate_irq_{dynamic, gsi} and
xen_free_irq" correctly avoids reallocating legacy IRQs (which are
managed by the arch core) but erroneously did not prevent them being
freed.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

There are three cases which we need to care about, PV guest, PV domain
0 and HVM guest.

The PV guest case is simple since it has no access to ACPI or real
APICs and therefore has no GSIs therefore we simply dynamically
allocate all IRQs. The potentially interesting case here is PIRQ type
event channels associated with passed through PCI devices. However
even in this case the guest has no direct interaction with the
physical GSI since that happens in the PCI backend.

The PV domain 0 and HVM guest cases are actually the same. In domain 0
case the kernel sees the host ACPI and GSIs (although it only sees the
APIC indirectly via the hypervisor) and in the HVM guest case it sees
the virtualised ACPI and emulated APICs. In these cases we start
allocating dynamic IRQs at nr_irqs_gsi so that they cannot clash with
any GSI.

Currently xen_allocate_irq_dynamic starts at nr_irqs and works
backwards looking for a free IRQ in order to (try and) avoid clashing
with GSIs used in domain 0 and in HVM guests. This change avoids that
although we retain the behaviour of allowing dynamic IRQs to encroach
on the GSI range if no suitable IRQs are available since a future IRQ
clash is deemed preferable to failure right now.
Signed-off-by: NIan Campbell <ian.campbell@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>