x86/xen: fix accounted interrupt time

The current addition to the interrupt nesting level in
xen_arch_intr_handle_upcall() needs to be compensated in
xen_intr_handle_upcall(), otherwise interrupts dispatched by the upcall handler
end up seeing a td_intr_nesting_level of 2 or more, which makes them assume
there's been an interrupt nesting.

Such extra interrupt nesting count lead to statclock() reporting idle time as
interrupt, as the call from interrupt context will always be seen as a nested
one (td->td_intr_nesting_level >= 2) due to the nesting count increase done by
both xen_arch_intr_handle_upcall() and intr_execute_handlers().

Fix this by adjusting the nested interrupt count before dispatching interrupts
from xen_intr_handle_upcall().

PR: 277231
Reported by: Matthew Grooms <mgrooms@shrew.net>
Fixes: af610cabf1f4 ('xen/intr: adjust xen_intr_handle_upcall() to match driver filter')
Sponsored by: Cloud Software Group
Reviewed by: Elliott Mitchell <ehem+freebsd@m5p.com>

x86/xen: fix out of bounds access to the event channel masks on resume

When resuming from migration or suspension all regular event channels ports are
reset to the INVALID_EVTCHN value, and drivers should re-initialize them
according to the new value provided by the other end of the connection.

However, the driver would first attempt to unbind the event channel handler
before attempting to bind it using the newly provided port. This unbind uses
the stale event channel port that has been set to INVALID_EVTCHN for some
operations (notably as a result of the handler removal the interrupt subsystem
ends up calling disable intr and source PIC hooks).

This was fine when INVALID_EVTCHN was 0, as then the operation would just
result in pointless setting of the 0 bit in the different event channel related
control arrays (evtchn_{pending,mask} for example). However with the change to
define INVALID_EVTCHN as ~0 the write is no longer pointless, and we end up
triggering a page-fault, or corrupting random data that happens to be mapped at
the array position + ~0 bits.

In hindsight the change of INVALID_EVTCHN from 0 to ~0 was way more risky than
initially assessed, and I believe has end up resulting in more fragile code for
no real benefit.

Fix the disable intr and source wrappers to check whether the event channel is
valid before attempting to use it.

Also introduce some extra KASSERTs in several array accesses in order to avoid
out of bounds accesses if INVALID_EVTCHN ever reaches those functions.

Fixes: 1797ff962769 ('xen/intr: cleanup event channel number use')
MFC after: 1 week
Sponsored by: Cloud Software Group
Reviewed by: markj
Differential revision: https://reviews.freebsd.org/D43928

xen: add atomic #defines to accomodate differing xen_ulong_t sizes

Alas, ARM declared xen_ulong_t to be 64-bits long, unlike i386 where
it matches the word size. As a result, compatibility wrappers are
needed for Xen atomic operations.

Reviewed by: royger

xen/intr: correct type of evtchn_enabled

evtchn_enabled needs to match the type of Xen's evtchn_mask. As Xen's
headers have a type for this, use Xen's type.

Reviewed by: royger

xen/intr: remove xenpci headers

These were needed in the past, since that time the interrupt code has
been successfully isolated from the Xen/PCI code. As such a bit of
straightforward cleanup.

Differential Revision: https://reviews.freebsd.org/D32923
Reviewed by: royger

xen/intr: correct misuses of Xen handle pointer type

Fix a few spots where handle pointers were incorrectly used. Luckily
these appear rarely triggered given how long they've been lurking.

Fixes: 76acc41fb7c7 ("Implement vector callback for PVHVM and unify event channel implementations")
Fixes: 9f40021f288c ("Introduce a new, HVM compatible, paravirtualized timer driver for Xen.")
MFC after: 2 weeks
Reviewed by: royger

sys: Remove $FreeBSD$: one-line .c pattern

Remove /^[\s*]*__FBSDID\("\$FreeBSD\$"\);?\s*\n/

xen/intr: move sys/x86/xen/xen_intr.c to sys/dev/xen/bus/

The event channel source code or equivalent is needed on all
architectures. Since much of this is viable to share, get this moved out
of x86-land. Each interrupt interface then needs a distinct back-end
implementation.

Reviewed by: royger
Submitted by: Elliott Mitchell <ehem+freebsd@m5p.com>
Original implementation: Julien Grall <julien@xen.org>, 2014-01-13 17:41:04
Differential Revision: https://reviews.freebsd.org/D30236