aprint_debug(): if a hypercall fail, print the return code.

Remove useless info from debug printf, fix format warning on i386

- msipic_construct_msix_pic(): set mp_table_base to memaddr (without
table_offset), this is what Xen wants
while there use pci_conf_write16() in msi_set_msictl_enablebit() too,
for consistency (it seems that Xen accepts the 32bit write at this point,
but this may change).

- xen_map_msix_pirq(): don't forget to set map_irq.table_base in the
MSI-X case, otherwise Xen maps it as MSI
- call pic_hwunmask() after pirq_establish() in msi/msix case, to make sure
the msi-x vector is unmasked.

Now MSI-X works with Xen so stop disabling it in pci_attach_hook().

Work in progress on MSI/MSI-X on Xen (MSI works on my hardware, more work
needed for MSI-X):
- Xen silently rejects 32 bits writes to MSI configuration registers
(especially when setting PCI_MSI_CTL_MSI_ENABLE/PCI_MSIX_CTL_ENABLE),
it expects 16 bits writes. So introduce a pci_conf_write16(),
only available on XENPV (and working only for mode 1 without
PCI_OVERRIDE_CONF_WRITE) and use it to enable MSI or MSI-X on XENPV.
- for multi-MSI vectors, Xen allocates all of them in a single hypercall,
so it's not convenient to do it at intr_establish() time.
So do it at alloc() time and register the pirqs in the msipic structure.
xen_pic_to_gsi() now just returns the values cached in the msipic.
As a bonus, if the PHYSDEVOP_map_pirq hypercall fails we can fail
the alloc() and we don't need the xen_pci_msi*_probe() hacks.

options NO_PCI_MSI_MSIX still on by default for XEN3_DOM0.

adjust includes to pull __HAVE_PCI_MSI_MSIX properly

add #ifdef __HAVE_PCI_MSI_MSIX so this still compiles with NO_PCI_MSI_MSIX

for Xen MSI, fallback to INTx when PHYSDEVOP_map_pirq fails for the device

apparently Xen requires VT-d to be enabled in BIOS for PHYSDEVOP_map_pirq
to work, this change makes it work on systems with VT-d disabled or missing

adresses the panic part of PR port-xen/55285 by Patrick Welche

switch back to PHYSDEVOP_alloc_irq_vector for non-MSI interrupts - on my
computer it works the same as PHYSDEVOP_map_pirq, but seems it doesn't
on other systems

fixes PR port-xen/55285 for Patrick Welche, but not yet for another system
by Frank Kardel

use short for irq2port[] to save memory (4KB), it only needs to store
numbers <= NR_EVENT_CHANNELS (2048)

only call PHYSDEVOP_map_pirq for a shared interrupt once, same as previous code

fixes boot problem reported privately by Frank Kardel and Patrick Welche

add support for using MSI for XenPV Dom0

use PHYSDEVOP_map_pirq to get the pirq/gsi for MSI/MSI-X, switch also INTx
to use it instead of PHYSDEVOP_alloc_irq_vector

MSI confirmed working with single-vector MSI for wm(4), ahcisata(4), bge(4)

XXX added some provision for MSI-X, but it doesn't actually work (no interrupts
delivered), needs some further investigation; disable MSI-X for XENPV
via flag in x86/pci/pci_machdep.c

Merge the bouyer-xenpvh branch, bringing in Xen PV drivers support under HVM
guests in GENERIC.
Xen support can be disabled at runtime with
boot -c
disable hypervisor

convert to newer HYPERVISOR_physdev_op() interface, now command and the
arg are separate arguments - this is needed for newer physdev_op commands

remove code for PHYSDEVOP_IRQ_UNMASK_NOTIFY, it is obsolete since
interface version 0x00030202 and is unsupported by newer versions of Xen

confirmed working on amd64 Dom0, i386 compile-tested only

branches: 1.11.2;
remove <sys/malloc.h> include, not used here

Catchup with struct intrstub; unification.

This should fix dom0 build breakage.

Do not export the 'irq<->vector' abstraction outside of pintr.c
anymore. We now think of them as a unified thing called 'gsi',
which is generated by mpacpi/mpbios

Since GSIs are invented by the mpbios/mpacpi interrupt routing probe code,
it's possible for shared GSIs to popup even outside the original
legacy_irq range.

Relax this latter, older assumption.

Thanks to Brad Spencer for extensive trialing on interesting hardware.

Switch over to a "GSI" concept for guest irqs.

On XEN there is a namespace called GSI which includes:

i) legacy_irq (0 - 16)
ii) "gsi" (16-nr_irqs_gsi)
iii) msi

We try to mirror this in guest space, but are mindful that legacy_irq
is 1:1 bound to actual hardware legacy_irq. Apart from this, XEN doesn't
really care what number scheme we use, as long as it doesn't encroach
on the MSI space, which is TBD for us.

Thus we trust the mpbios.c/mpacpi.c code to correctly map the pic,pin
tuples into the correct global gsi space, which we then register with
xen. As we now do, we allow for duplicate gsi registrations, in case
any hardware shares the same (pic,pin);

This enables us to now use the (pic,pin) tuple as the canonical reference
for device interrupt addresses, and leave any global mappings to specific
code. Thus xen_pic_to_gsi().

Note that this requires separate support for MSI, which I will get around to
once things stabilise - however the API change facilitates this nicely.

I note that the msi addroute() function does not use the "pin" parameter.
This can be made use of, to encode the gsi number, for XEN. This is however
TBD.

We further tweak the xen_vec_alloc() code to be uniform for the NIOAPICS
and other cases, and ensure that i8259.c DTRT wrt to route().

This will allow us to use pic->pic_addroute() without needing to worry about
pic specific issues.

The next step is to consolidate the pic_addroute() XEN related #ifdefs into
a -DXEN specific file, so that we don't clutter x86/ code with #ifdef XENs.

This change has functional implications, and there is likely breakage coming
especially on bespoke platforms that I haven't been able to test yet.

I am especially interested in bug reports from platforms with legacy (esp. i386)
and with multiple ioapics.

Change the name of xen_pirq_alloc() to xen_vec_alloc() to reflect
its actual job.

The idea is that we will strip this down until it is as close to
idt_vec_alloc() as possible.

Move the pic->pic_addroute() call from within pintr.c:xen_pirq_alloc() to
intr.c:intr_establish_xname()

xen_pirq_alloc() now returns a vector value, as is intended by
the semantics of the call to the hypervisor, PHYSDEVOP_ASSIGN_VECTOR.

This also brings our usage closer to native.

Teach intr_establish_xname() for XEN to tolerate shared legacy_irq
registrations.

The current XEN code has not been able to tolerate shared legacy_irq
requests in xen_pirq_alloc(). This was never a problem because:

i) The only potential callpath with shared legacy_irq was
isa_intr_establish_xname().
ii) The other callpath, namely pci_intr_establish_xname() passed
legacy_irq to intr_establish_xname(). However, this was ignored,
and a value of zero was passed to xen_pirq_alloc() which in
turn, allocated a new irq value, thus effectively demultiplexing
any shared legacy_irq value intended across randomly allocated
new irq values.
iii) Presumably on all platforms that XEN runs on, the isa callpath
mentioned in i) never had shared irqs, and thus this was never
a problem.

Except:
We now use a unified path for both isa_intr_establish_xname() and
pci_intr_establish_xname(). This means that now, intr_establish_xname()
which is a callee of both, needs to have a way to discern who the caller
was, and decide to pass on or discard the legacy_irq value, to preserve
the old semantics. However, this is impossible to do so, because the
callpath doesn't explicitly provide a mechanism for this discernment.

This is however not a problem, because from XEN's point of view, a
repeat registration of an irq is only a warning. legacy_irq is the only
case in which this repeat should occur, per the current implementation of
xen_pirq_alloc(). We thus tweak the KASSERT()s to tolerate a repeat value
in the legacy_irq, while maintaining the original intent of the KASSERT()
which was to ensure that existing unrelated irq registrations should never
be overwritten.

Once we re-organise XEN specific code and unify with the native
intr_establish_xname() path, we will not run into this problem, because
legacy_irq will be treated as the pin number of the i8259 pic
exactly as it is now treated in native.

In short, this commit should fix some of the panics being seen on
-current for certain configurations of hardware on which dom0 runs.

branches: 1.3.2; 1.3.4;
Rename i8259_stubs -> legacy_stubs. We will want the entries to have the
same name, eg:

legacy_stubs
-> Xintr_legacy0, Xrecurse_legacy0, Xresume_legacy0
-> Xintr_legacy1, Xrecurse_legacy1, Xresume_legacy1
...

Fixes for physical interrupts on Xen:
- do not cast int * to intr_handle_t *, they're not the same size
- legacy_irq is not always -1 for ioapic interrupts, test pic_type instead
- change irq2port[] to hold (port + 1) so that 0 is an invalid value
- add KASSERTs to make sure vect, port or irq values extracted from arrays are
valid (or that they are invalid before write)
- for the !ioapic case, we still need to do PHYSDEVOP_ASSIGN_VECTOR and
bind_pirq_to_evtch().

now XEN3_DOM0 boots again

branches: 1.1.2;
On XEN dom0, the function xen/x86/intr.c:xen_intr_map() is used to map
hardware interrupts to XEN callbacks called 'events'. This function
combines both the allocation and the binding.

This change is the first part of breaking up that combination into
xen_pirq_alloc() and the binding will happen as part of the
pic_addroute() callback of a new pseudo PIC_XEN

This code will be added later on.

Remove useless info from debug printf, fix format warning on i386

- msipic_construct_msix_pic(): set mp_table_base to memaddr (without
table_offset), this is what Xen wants
while there use pci_conf_write16() in msi_set_msictl_enablebit() too,
for consistency (it seems that Xen accepts the 32bit write at this point,
but this may change).

- xen_map_msix_pirq(): don't forget to set map_irq.table_base in the
MSI-X case, otherwise Xen maps it as MSI
- call pic_hwunmask() after pirq_establish() in msi/msix case, to make sure
the msi-x vector is unmasked.

Now MSI-X works with Xen so stop disabling it in pci_attach_hook().

Work in progress on MSI/MSI-X on Xen (MSI works on my hardware, more work
needed for MSI-X):
- Xen silently rejects 32 bits writes to MSI configuration registers
(especially when setting PCI_MSI_CTL_MSI_ENABLE/PCI_MSIX_CTL_ENABLE),
it expects 16 bits writes. So introduce a pci_conf_write16(),
only available on XENPV (and working only for mode 1 without
PCI_OVERRIDE_CONF_WRITE) and use it to enable MSI or MSI-X on XENPV.
- for multi-MSI vectors, Xen allocates all of them in a single hypercall,
so it's not convenient to do it at intr_establish() time.
So do it at alloc() time and register the pirqs in the msipic structure.
xen_pic_to_gsi() now just returns the values cached in the msipic.
As a bonus, if the PHYSDEVOP_map_pirq hypercall fails we can fail
the alloc() and we don't need the xen_pci_msi*_probe() hacks.

options NO_PCI_MSI_MSIX still on by default for XEN3_DOM0.

adjust includes to pull __HAVE_PCI_MSI_MSIX properly

add #ifdef __HAVE_PCI_MSI_MSIX so this still compiles with NO_PCI_MSI_MSIX

for Xen MSI, fallback to INTx when PHYSDEVOP_map_pirq fails for the device

apparently Xen requires VT-d to be enabled in BIOS for PHYSDEVOP_map_pirq
to work, this change makes it work on systems with VT-d disabled or missing

adresses the panic part of PR port-xen/55285 by Patrick Welche

switch back to PHYSDEVOP_alloc_irq_vector for non-MSI interrupts - on my
computer it works the same as PHYSDEVOP_map_pirq, but seems it doesn't
on other systems

fixes PR port-xen/55285 for Patrick Welche, but not yet for another system
by Frank Kardel

use short for irq2port[] to save memory (4KB), it only needs to store
numbers <= NR_EVENT_CHANNELS (2048)

only call PHYSDEVOP_map_pirq for a shared interrupt once, same as previous code

fixes boot problem reported privately by Frank Kardel and Patrick Welche

add support for using MSI for XenPV Dom0

use PHYSDEVOP_map_pirq to get the pirq/gsi for MSI/MSI-X, switch also INTx
to use it instead of PHYSDEVOP_alloc_irq_vector

MSI confirmed working with single-vector MSI for wm(4), ahcisata(4), bge(4)

XXX added some provision for MSI-X, but it doesn't actually work (no interrupts
delivered), needs some further investigation; disable MSI-X for XENPV
via flag in x86/pci/pci_machdep.c

Merge the bouyer-xenpvh branch, bringing in Xen PV drivers support under HVM
guests in GENERIC.
Xen support can be disabled at runtime with
boot -c
disable hypervisor

convert to newer HYPERVISOR_physdev_op() interface, now command and the
arg are separate arguments - this is needed for newer physdev_op commands

remove code for PHYSDEVOP_IRQ_UNMASK_NOTIFY, it is obsolete since
interface version 0x00030202 and is unsupported by newer versions of Xen

confirmed working on amd64 Dom0, i386 compile-tested only

branches: 1.11.2;
remove <sys/malloc.h> include, not used here

Catchup with struct intrstub; unification.

This should fix dom0 build breakage.

Do not export the 'irq<->vector' abstraction outside of pintr.c
anymore. We now think of them as a unified thing called 'gsi',
which is generated by mpacpi/mpbios

Since GSIs are invented by the mpbios/mpacpi interrupt routing probe code,
it's possible for shared GSIs to popup even outside the original
legacy_irq range.

Relax this latter, older assumption.

Thanks to Brad Spencer for extensive trialing on interesting hardware.

Switch over to a "GSI" concept for guest irqs.

On XEN there is a namespace called GSI which includes:

i) legacy_irq (0 - 16)
ii) "gsi" (16-nr_irqs_gsi)
iii) msi

We try to mirror this in guest space, but are mindful that legacy_irq
is 1:1 bound to actual hardware legacy_irq. Apart from this, XEN doesn't
really care what number scheme we use, as long as it doesn't encroach
on the MSI space, which is TBD for us.

Thus we trust the mpbios.c/mpacpi.c code to correctly map the pic,pin
tuples into the correct global gsi space, which we then register with
xen. As we now do, we allow for duplicate gsi registrations, in case
any hardware shares the same (pic,pin);

This enables us to now use the (pic,pin) tuple as the canonical reference
for device interrupt addresses, and leave any global mappings to specific
code. Thus xen_pic_to_gsi().

Note that this requires separate support for MSI, which I will get around to
once things stabilise - however the API change facilitates this nicely.

I note that the msi addroute() function does not use the "pin" parameter.
This can be made use of, to encode the gsi number, for XEN. This is however
TBD.

We further tweak the xen_vec_alloc() code to be uniform for the NIOAPICS
and other cases, and ensure that i8259.c DTRT wrt to route().

This will allow us to use pic->pic_addroute() without needing to worry about
pic specific issues.

The next step is to consolidate the pic_addroute() XEN related #ifdefs into
a -DXEN specific file, so that we don't clutter x86/ code with #ifdef XENs.

This change has functional implications, and there is likely breakage coming
especially on bespoke platforms that I haven't been able to test yet.

I am especially interested in bug reports from platforms with legacy (esp. i386)
and with multiple ioapics.

Change the name of xen_pirq_alloc() to xen_vec_alloc() to reflect
its actual job.

The idea is that we will strip this down until it is as close to
idt_vec_alloc() as possible.

Move the pic->pic_addroute() call from within pintr.c:xen_pirq_alloc() to
intr.c:intr_establish_xname()

xen_pirq_alloc() now returns a vector value, as is intended by
the semantics of the call to the hypervisor, PHYSDEVOP_ASSIGN_VECTOR.

This also brings our usage closer to native.

Teach intr_establish_xname() for XEN to tolerate shared legacy_irq
registrations.

The current XEN code has not been able to tolerate shared legacy_irq
requests in xen_pirq_alloc(). This was never a problem because:

i) The only potential callpath with shared legacy_irq was
isa_intr_establish_xname().
ii) The other callpath, namely pci_intr_establish_xname() passed
legacy_irq to intr_establish_xname(). However, this was ignored,
and a value of zero was passed to xen_pirq_alloc() which in
turn, allocated a new irq value, thus effectively demultiplexing
any shared legacy_irq value intended across randomly allocated
new irq values.
iii) Presumably on all platforms that XEN runs on, the isa callpath
mentioned in i) never had shared irqs, and thus this was never
a problem.

Except:
We now use a unified path for both isa_intr_establish_xname() and
pci_intr_establish_xname(). This means that now, intr_establish_xname()
which is a callee of both, needs to have a way to discern who the caller
was, and decide to pass on or discard the legacy_irq value, to preserve
the old semantics. However, this is impossible to do so, because the
callpath doesn't explicitly provide a mechanism for this discernment.

This is however not a problem, because from XEN's point of view, a
repeat registration of an irq is only a warning. legacy_irq is the only
case in which this repeat should occur, per the current implementation of
xen_pirq_alloc(). We thus tweak the KASSERT()s to tolerate a repeat value
in the legacy_irq, while maintaining the original intent of the KASSERT()
which was to ensure that existing unrelated irq registrations should never
be overwritten.

Once we re-organise XEN specific code and unify with the native
intr_establish_xname() path, we will not run into this problem, because
legacy_irq will be treated as the pin number of the i8259 pic
exactly as it is now treated in native.

In short, this commit should fix some of the panics being seen on
-current for certain configurations of hardware on which dom0 runs.

branches: 1.3.2; 1.3.4;
Rename i8259_stubs -> legacy_stubs. We will want the entries to have the
same name, eg:

legacy_stubs
-> Xintr_legacy0, Xrecurse_legacy0, Xresume_legacy0
-> Xintr_legacy1, Xrecurse_legacy1, Xresume_legacy1
...

Fixes for physical interrupts on Xen:
- do not cast int * to intr_handle_t *, they're not the same size
- legacy_irq is not always -1 for ioapic interrupts, test pic_type instead
- change irq2port[] to hold (port + 1) so that 0 is an invalid value
- add KASSERTs to make sure vect, port or irq values extracted from arrays are
valid (or that they are invalid before write)
- for the !ioapic case, we still need to do PHYSDEVOP_ASSIGN_VECTOR and
bind_pirq_to_evtch().

now XEN3_DOM0 boots again

branches: 1.1.2;
On XEN dom0, the function xen/x86/intr.c:xen_intr_map() is used to map
hardware interrupts to XEN callbacks called 'events'. This function
combines both the allocation and the binding.

This change is the first part of breaking up that combination into
xen_pirq_alloc() and the binding will happen as part of the
pic_addroute() callback of a new pseudo PIC_XEN

This code will be added later on.

adjust includes to pull __HAVE_PCI_MSI_MSIX properly

add #ifdef __HAVE_PCI_MSI_MSIX so this still compiles with NO_PCI_MSI_MSIX

for Xen MSI, fallback to INTx when PHYSDEVOP_map_pirq fails for the device

apparently Xen requires VT-d to be enabled in BIOS for PHYSDEVOP_map_pirq
to work, this change makes it work on systems with VT-d disabled or missing

adresses the panic part of PR port-xen/55285 by Patrick Welche

switch back to PHYSDEVOP_alloc_irq_vector for non-MSI interrupts - on my
computer it works the same as PHYSDEVOP_map_pirq, but seems it doesn't
on other systems

fixes PR port-xen/55285 for Patrick Welche, but not yet for another system
by Frank Kardel

use short for irq2port[] to save memory (4KB), it only needs to store
numbers <= NR_EVENT_CHANNELS (2048)

only call PHYSDEVOP_map_pirq for a shared interrupt once, same as previous code

fixes boot problem reported privately by Frank Kardel and Patrick Welche

add support for using MSI for XenPV Dom0

use PHYSDEVOP_map_pirq to get the pirq/gsi for MSI/MSI-X, switch also INTx
to use it instead of PHYSDEVOP_alloc_irq_vector

MSI confirmed working with single-vector MSI for wm(4), ahcisata(4), bge(4)

XXX added some provision for MSI-X, but it doesn't actually work (no interrupts
delivered), needs some further investigation; disable MSI-X for XENPV
via flag in x86/pci/pci_machdep.c

Merge the bouyer-xenpvh branch, bringing in Xen PV drivers support under HVM
guests in GENERIC.
Xen support can be disabled at runtime with
boot -c
disable hypervisor

convert to newer HYPERVISOR_physdev_op() interface, now command and the
arg are separate arguments - this is needed for newer physdev_op commands

remove code for PHYSDEVOP_IRQ_UNMASK_NOTIFY, it is obsolete since
interface version 0x00030202 and is unsupported by newer versions of Xen

confirmed working on amd64 Dom0, i386 compile-tested only

branches: 1.11.2;
remove <sys/malloc.h> include, not used here

Catchup with struct intrstub; unification.

This should fix dom0 build breakage.

Do not export the 'irq<->vector' abstraction outside of pintr.c
anymore. We now think of them as a unified thing called 'gsi',
which is generated by mpacpi/mpbios

Since GSIs are invented by the mpbios/mpacpi interrupt routing probe code,
it's possible for shared GSIs to popup even outside the original
legacy_irq range.

Relax this latter, older assumption.

Thanks to Brad Spencer for extensive trialing on interesting hardware.

Switch over to a "GSI" concept for guest irqs.

On XEN there is a namespace called GSI which includes:

i) legacy_irq (0 - 16)
ii) "gsi" (16-nr_irqs_gsi)
iii) msi

We try to mirror this in guest space, but are mindful that legacy_irq
is 1:1 bound to actual hardware legacy_irq. Apart from this, XEN doesn't
really care what number scheme we use, as long as it doesn't encroach
on the MSI space, which is TBD for us.

Thus we trust the mpbios.c/mpacpi.c code to correctly map the pic,pin
tuples into the correct global gsi space, which we then register with
xen. As we now do, we allow for duplicate gsi registrations, in case
any hardware shares the same (pic,pin);

This enables us to now use the (pic,pin) tuple as the canonical reference
for device interrupt addresses, and leave any global mappings to specific
code. Thus xen_pic_to_gsi().

Note that this requires separate support for MSI, which I will get around to
once things stabilise - however the API change facilitates this nicely.

I note that the msi addroute() function does not use the "pin" parameter.
This can be made use of, to encode the gsi number, for XEN. This is however
TBD.

We further tweak the xen_vec_alloc() code to be uniform for the NIOAPICS
and other cases, and ensure that i8259.c DTRT wrt to route().

This will allow us to use pic->pic_addroute() without needing to worry about
pic specific issues.

The next step is to consolidate the pic_addroute() XEN related #ifdefs into
a -DXEN specific file, so that we don't clutter x86/ code with #ifdef XENs.

This change has functional implications, and there is likely breakage coming
especially on bespoke platforms that I haven't been able to test yet.

I am especially interested in bug reports from platforms with legacy (esp. i386)
and with multiple ioapics.

Change the name of xen_pirq_alloc() to xen_vec_alloc() to reflect
its actual job.

The idea is that we will strip this down until it is as close to
idt_vec_alloc() as possible.

Move the pic->pic_addroute() call from within pintr.c:xen_pirq_alloc() to
intr.c:intr_establish_xname()

xen_pirq_alloc() now returns a vector value, as is intended by
the semantics of the call to the hypervisor, PHYSDEVOP_ASSIGN_VECTOR.

This also brings our usage closer to native.

Teach intr_establish_xname() for XEN to tolerate shared legacy_irq
registrations.

The current XEN code has not been able to tolerate shared legacy_irq
requests in xen_pirq_alloc(). This was never a problem because:

i) The only potential callpath with shared legacy_irq was
isa_intr_establish_xname().
ii) The other callpath, namely pci_intr_establish_xname() passed
legacy_irq to intr_establish_xname(). However, this was ignored,
and a value of zero was passed to xen_pirq_alloc() which in
turn, allocated a new irq value, thus effectively demultiplexing
any shared legacy_irq value intended across randomly allocated
new irq values.
iii) Presumably on all platforms that XEN runs on, the isa callpath
mentioned in i) never had shared irqs, and thus this was never
a problem.

Except:
We now use a unified path for both isa_intr_establish_xname() and
pci_intr_establish_xname(). This means that now, intr_establish_xname()
which is a callee of both, needs to have a way to discern who the caller
was, and decide to pass on or discard the legacy_irq value, to preserve
the old semantics. However, this is impossible to do so, because the
callpath doesn't explicitly provide a mechanism for this discernment.

This is however not a problem, because from XEN's point of view, a
repeat registration of an irq is only a warning. legacy_irq is the only
case in which this repeat should occur, per the current implementation of
xen_pirq_alloc(). We thus tweak the KASSERT()s to tolerate a repeat value
in the legacy_irq, while maintaining the original intent of the KASSERT()
which was to ensure that existing unrelated irq registrations should never
be overwritten.

Once we re-organise XEN specific code and unify with the native
intr_establish_xname() path, we will not run into this problem, because
legacy_irq will be treated as the pin number of the i8259 pic
exactly as it is now treated in native.

In short, this commit should fix some of the panics being seen on
-current for certain configurations of hardware on which dom0 runs.

branches: 1.3.2; 1.3.4;
Rename i8259_stubs -> legacy_stubs. We will want the entries to have the
same name, eg:

legacy_stubs
-> Xintr_legacy0, Xrecurse_legacy0, Xresume_legacy0
-> Xintr_legacy1, Xrecurse_legacy1, Xresume_legacy1
...

Fixes for physical interrupts on Xen:
- do not cast int * to intr_handle_t *, they're not the same size
- legacy_irq is not always -1 for ioapic interrupts, test pic_type instead
- change irq2port[] to hold (port + 1) so that 0 is an invalid value
- add KASSERTs to make sure vect, port or irq values extracted from arrays are
valid (or that they are invalid before write)
- for the !ioapic case, we still need to do PHYSDEVOP_ASSIGN_VECTOR and
bind_pirq_to_evtch().

now XEN3_DOM0 boots again

branches: 1.1.2;
On XEN dom0, the function xen/x86/intr.c:xen_intr_map() is used to map
hardware interrupts to XEN callbacks called 'events'. This function
combines both the allocation and the binding.

This change is the first part of breaking up that combination into
xen_pirq_alloc() and the binding will happen as part of the
pic_addroute() callback of a new pseudo PIC_XEN

This code will be added later on.

add #ifdef __HAVE_PCI_MSI_MSIX so this still compiles with NO_PCI_MSI_MSIX

for Xen MSI, fallback to INTx when PHYSDEVOP_map_pirq fails for the device

apparently Xen requires VT-d to be enabled in BIOS for PHYSDEVOP_map_pirq
to work, this change makes it work on systems with VT-d disabled or missing

adresses the panic part of PR port-xen/55285 by Patrick Welche

switch back to PHYSDEVOP_alloc_irq_vector for non-MSI interrupts - on my
computer it works the same as PHYSDEVOP_map_pirq, but seems it doesn't
on other systems

fixes PR port-xen/55285 for Patrick Welche, but not yet for another system
by Frank Kardel

use short for irq2port[] to save memory (4KB), it only needs to store
numbers <= NR_EVENT_CHANNELS (2048)

only call PHYSDEVOP_map_pirq for a shared interrupt once, same as previous code

fixes boot problem reported privately by Frank Kardel and Patrick Welche

add support for using MSI for XenPV Dom0

use PHYSDEVOP_map_pirq to get the pirq/gsi for MSI/MSI-X, switch also INTx
to use it instead of PHYSDEVOP_alloc_irq_vector

MSI confirmed working with single-vector MSI for wm(4), ahcisata(4), bge(4)

XXX added some provision for MSI-X, but it doesn't actually work (no interrupts
delivered), needs some further investigation; disable MSI-X for XENPV
via flag in x86/pci/pci_machdep.c

Merge the bouyer-xenpvh branch, bringing in Xen PV drivers support under HVM
guests in GENERIC.
Xen support can be disabled at runtime with
boot -c
disable hypervisor

convert to newer HYPERVISOR_physdev_op() interface, now command and the
arg are separate arguments - this is needed for newer physdev_op commands

remove code for PHYSDEVOP_IRQ_UNMASK_NOTIFY, it is obsolete since
interface version 0x00030202 and is unsupported by newer versions of Xen

confirmed working on amd64 Dom0, i386 compile-tested only

branches: 1.11.2;
remove <sys/malloc.h> include, not used here

Catchup with struct intrstub; unification.

This should fix dom0 build breakage.

Do not export the 'irq<->vector' abstraction outside of pintr.c
anymore. We now think of them as a unified thing called 'gsi',
which is generated by mpacpi/mpbios

Since GSIs are invented by the mpbios/mpacpi interrupt routing probe code,
it's possible for shared GSIs to popup even outside the original
legacy_irq range.

Relax this latter, older assumption.

Thanks to Brad Spencer for extensive trialing on interesting hardware.

Switch over to a "GSI" concept for guest irqs.

On XEN there is a namespace called GSI which includes:

i) legacy_irq (0 - 16)
ii) "gsi" (16-nr_irqs_gsi)
iii) msi

We try to mirror this in guest space, but are mindful that legacy_irq
is 1:1 bound to actual hardware legacy_irq. Apart from this, XEN doesn't
really care what number scheme we use, as long as it doesn't encroach
on the MSI space, which is TBD for us.

Thus we trust the mpbios.c/mpacpi.c code to correctly map the pic,pin
tuples into the correct global gsi space, which we then register with
xen. As we now do, we allow for duplicate gsi registrations, in case
any hardware shares the same (pic,pin);

This enables us to now use the (pic,pin) tuple as the canonical reference
for device interrupt addresses, and leave any global mappings to specific
code. Thus xen_pic_to_gsi().

Note that this requires separate support for MSI, which I will get around to
once things stabilise - however the API change facilitates this nicely.

I note that the msi addroute() function does not use the "pin" parameter.
This can be made use of, to encode the gsi number, for XEN. This is however
TBD.

We further tweak the xen_vec_alloc() code to be uniform for the NIOAPICS
and other cases, and ensure that i8259.c DTRT wrt to route().

This will allow us to use pic->pic_addroute() without needing to worry about
pic specific issues.

The next step is to consolidate the pic_addroute() XEN related #ifdefs into
a -DXEN specific file, so that we don't clutter x86/ code with #ifdef XENs.

This change has functional implications, and there is likely breakage coming
especially on bespoke platforms that I haven't been able to test yet.

I am especially interested in bug reports from platforms with legacy (esp. i386)
and with multiple ioapics.

Change the name of xen_pirq_alloc() to xen_vec_alloc() to reflect
its actual job.

The idea is that we will strip this down until it is as close to
idt_vec_alloc() as possible.

Move the pic->pic_addroute() call from within pintr.c:xen_pirq_alloc() to
intr.c:intr_establish_xname()

xen_pirq_alloc() now returns a vector value, as is intended by
the semantics of the call to the hypervisor, PHYSDEVOP_ASSIGN_VECTOR.

This also brings our usage closer to native.

Teach intr_establish_xname() for XEN to tolerate shared legacy_irq
registrations.

The current XEN code has not been able to tolerate shared legacy_irq
requests in xen_pirq_alloc(). This was never a problem because:

i) The only potential callpath with shared legacy_irq was
isa_intr_establish_xname().
ii) The other callpath, namely pci_intr_establish_xname() passed
legacy_irq to intr_establish_xname(). However, this was ignored,
and a value of zero was passed to xen_pirq_alloc() which in
turn, allocated a new irq value, thus effectively demultiplexing
any shared legacy_irq value intended across randomly allocated
new irq values.
iii) Presumably on all platforms that XEN runs on, the isa callpath
mentioned in i) never had shared irqs, and thus this was never
a problem.

Except:
We now use a unified path for both isa_intr_establish_xname() and
pci_intr_establish_xname(). This means that now, intr_establish_xname()
which is a callee of both, needs to have a way to discern who the caller
was, and decide to pass on or discard the legacy_irq value, to preserve
the old semantics. However, this is impossible to do so, because the
callpath doesn't explicitly provide a mechanism for this discernment.

This is however not a problem, because from XEN's point of view, a
repeat registration of an irq is only a warning. legacy_irq is the only
case in which this repeat should occur, per the current implementation of
xen_pirq_alloc(). We thus tweak the KASSERT()s to tolerate a repeat value
in the legacy_irq, while maintaining the original intent of the KASSERT()
which was to ensure that existing unrelated irq registrations should never
be overwritten.

Once we re-organise XEN specific code and unify with the native
intr_establish_xname() path, we will not run into this problem, because
legacy_irq will be treated as the pin number of the i8259 pic
exactly as it is now treated in native.

In short, this commit should fix some of the panics being seen on
-current for certain configurations of hardware on which dom0 runs.

branches: 1.3.2; 1.3.4;
Rename i8259_stubs -> legacy_stubs. We will want the entries to have the
same name, eg:

legacy_stubs
-> Xintr_legacy0, Xrecurse_legacy0, Xresume_legacy0
-> Xintr_legacy1, Xrecurse_legacy1, Xresume_legacy1
...

Fixes for physical interrupts on Xen:
- do not cast int * to intr_handle_t *, they're not the same size
- legacy_irq is not always -1 for ioapic interrupts, test pic_type instead
- change irq2port[] to hold (port + 1) so that 0 is an invalid value
- add KASSERTs to make sure vect, port or irq values extracted from arrays are
valid (or that they are invalid before write)
- for the !ioapic case, we still need to do PHYSDEVOP_ASSIGN_VECTOR and
bind_pirq_to_evtch().

now XEN3_DOM0 boots again

branches: 1.1.2;
On XEN dom0, the function xen/x86/intr.c:xen_intr_map() is used to map
hardware interrupts to XEN callbacks called 'events'. This function
combines both the allocation and the binding.

This change is the first part of breaking up that combination into
xen_pirq_alloc() and the binding will happen as part of the
pic_addroute() callback of a new pseudo PIC_XEN

This code will be added later on.

switch back to PHYSDEVOP_alloc_irq_vector for non-MSI interrupts - on my
computer it works the same as PHYSDEVOP_map_pirq, but seems it doesn't
on other systems

fixes PR port-xen/55285 for Patrick Welche, but not yet for another system
by Frank Kardel

use short for irq2port[] to save memory (4KB), it only needs to store
numbers <= NR_EVENT_CHANNELS (2048)

only call PHYSDEVOP_map_pirq for a shared interrupt once, same as previous code

fixes boot problem reported privately by Frank Kardel and Patrick Welche

add support for using MSI for XenPV Dom0

use PHYSDEVOP_map_pirq to get the pirq/gsi for MSI/MSI-X, switch also INTx
to use it instead of PHYSDEVOP_alloc_irq_vector

MSI confirmed working with single-vector MSI for wm(4), ahcisata(4), bge(4)

XXX added some provision for MSI-X, but it doesn't actually work (no interrupts
delivered), needs some further investigation; disable MSI-X for XENPV
via flag in x86/pci/pci_machdep.c

Merge the bouyer-xenpvh branch, bringing in Xen PV drivers support under HVM
guests in GENERIC.
Xen support can be disabled at runtime with
boot -c
disable hypervisor

convert to newer HYPERVISOR_physdev_op() interface, now command and the
arg are separate arguments - this is needed for newer physdev_op commands

remove code for PHYSDEVOP_IRQ_UNMASK_NOTIFY, it is obsolete since
interface version 0x00030202 and is unsupported by newer versions of Xen

confirmed working on amd64 Dom0, i386 compile-tested only

branches: 1.11.2;
remove <sys/malloc.h> include, not used here

Catchup with struct intrstub; unification.

This should fix dom0 build breakage.

Do not export the 'irq<->vector' abstraction outside of pintr.c
anymore. We now think of them as a unified thing called 'gsi',
which is generated by mpacpi/mpbios

Since GSIs are invented by the mpbios/mpacpi interrupt routing probe code,
it's possible for shared GSIs to popup even outside the original
legacy_irq range.

Relax this latter, older assumption.

Thanks to Brad Spencer for extensive trialing on interesting hardware.

Switch over to a "GSI" concept for guest irqs.

On XEN there is a namespace called GSI which includes:

i) legacy_irq (0 - 16)
ii) "gsi" (16-nr_irqs_gsi)
iii) msi

We try to mirror this in guest space, but are mindful that legacy_irq
is 1:1 bound to actual hardware legacy_irq. Apart from this, XEN doesn't
really care what number scheme we use, as long as it doesn't encroach
on the MSI space, which is TBD for us.

Thus we trust the mpbios.c/mpacpi.c code to correctly map the pic,pin
tuples into the correct global gsi space, which we then register with
xen. As we now do, we allow for duplicate gsi registrations, in case
any hardware shares the same (pic,pin);

This enables us to now use the (pic,pin) tuple as the canonical reference
for device interrupt addresses, and leave any global mappings to specific
code. Thus xen_pic_to_gsi().

Note that this requires separate support for MSI, which I will get around to
once things stabilise - however the API change facilitates this nicely.

I note that the msi addroute() function does not use the "pin" parameter.
This can be made use of, to encode the gsi number, for XEN. This is however
TBD.

We further tweak the xen_vec_alloc() code to be uniform for the NIOAPICS
and other cases, and ensure that i8259.c DTRT wrt to route().

This will allow us to use pic->pic_addroute() without needing to worry about
pic specific issues.

The next step is to consolidate the pic_addroute() XEN related #ifdefs into
a -DXEN specific file, so that we don't clutter x86/ code with #ifdef XENs.

This change has functional implications, and there is likely breakage coming
especially on bespoke platforms that I haven't been able to test yet.

I am especially interested in bug reports from platforms with legacy (esp. i386)
and with multiple ioapics.

Change the name of xen_pirq_alloc() to xen_vec_alloc() to reflect
its actual job.

The idea is that we will strip this down until it is as close to
idt_vec_alloc() as possible.

Move the pic->pic_addroute() call from within pintr.c:xen_pirq_alloc() to
intr.c:intr_establish_xname()

xen_pirq_alloc() now returns a vector value, as is intended by
the semantics of the call to the hypervisor, PHYSDEVOP_ASSIGN_VECTOR.

This also brings our usage closer to native.

Teach intr_establish_xname() for XEN to tolerate shared legacy_irq
registrations.

The current XEN code has not been able to tolerate shared legacy_irq
requests in xen_pirq_alloc(). This was never a problem because:

i) The only potential callpath with shared legacy_irq was
isa_intr_establish_xname().
ii) The other callpath, namely pci_intr_establish_xname() passed
legacy_irq to intr_establish_xname(). However, this was ignored,
and a value of zero was passed to xen_pirq_alloc() which in
turn, allocated a new irq value, thus effectively demultiplexing
any shared legacy_irq value intended across randomly allocated
new irq values.
iii) Presumably on all platforms that XEN runs on, the isa callpath
mentioned in i) never had shared irqs, and thus this was never
a problem.

Except:
We now use a unified path for both isa_intr_establish_xname() and
pci_intr_establish_xname(). This means that now, intr_establish_xname()
which is a callee of both, needs to have a way to discern who the caller
was, and decide to pass on or discard the legacy_irq value, to preserve
the old semantics. However, this is impossible to do so, because the
callpath doesn't explicitly provide a mechanism for this discernment.

This is however not a problem, because from XEN's point of view, a
repeat registration of an irq is only a warning. legacy_irq is the only
case in which this repeat should occur, per the current implementation of
xen_pirq_alloc(). We thus tweak the KASSERT()s to tolerate a repeat value
in the legacy_irq, while maintaining the original intent of the KASSERT()
which was to ensure that existing unrelated irq registrations should never
be overwritten.

Once we re-organise XEN specific code and unify with the native
intr_establish_xname() path, we will not run into this problem, because
legacy_irq will be treated as the pin number of the i8259 pic
exactly as it is now treated in native.

In short, this commit should fix some of the panics being seen on
-current for certain configurations of hardware on which dom0 runs.

branches: 1.3.2; 1.3.4;
Rename i8259_stubs -> legacy_stubs. We will want the entries to have the
same name, eg:

legacy_stubs
-> Xintr_legacy0, Xrecurse_legacy0, Xresume_legacy0
-> Xintr_legacy1, Xrecurse_legacy1, Xresume_legacy1
...

Fixes for physical interrupts on Xen:
- do not cast int * to intr_handle_t *, they're not the same size
- legacy_irq is not always -1 for ioapic interrupts, test pic_type instead
- change irq2port[] to hold (port + 1) so that 0 is an invalid value
- add KASSERTs to make sure vect, port or irq values extracted from arrays are
valid (or that they are invalid before write)
- for the !ioapic case, we still need to do PHYSDEVOP_ASSIGN_VECTOR and
bind_pirq_to_evtch().

now XEN3_DOM0 boots again

branches: 1.1.2;
On XEN dom0, the function xen/x86/intr.c:xen_intr_map() is used to map
hardware interrupts to XEN callbacks called 'events'. This function
combines both the allocation and the binding.

This change is the first part of breaking up that combination into
xen_pirq_alloc() and the binding will happen as part of the
pic_addroute() callback of a new pseudo PIC_XEN

This code will be added later on.

use short for irq2port[] to save memory (4KB), it only needs to store
numbers <= NR_EVENT_CHANNELS (2048)

only call PHYSDEVOP_map_pirq for a shared interrupt once, same as previous code

fixes boot problem reported privately by Frank Kardel and Patrick Welche

add support for using MSI for XenPV Dom0

use PHYSDEVOP_map_pirq to get the pirq/gsi for MSI/MSI-X, switch also INTx
to use it instead of PHYSDEVOP_alloc_irq_vector

MSI confirmed working with single-vector MSI for wm(4), ahcisata(4), bge(4)

XXX added some provision for MSI-X, but it doesn't actually work (no interrupts
delivered), needs some further investigation; disable MSI-X for XENPV
via flag in x86/pci/pci_machdep.c

Merge the bouyer-xenpvh branch, bringing in Xen PV drivers support under HVM
guests in GENERIC.
Xen support can be disabled at runtime with
boot -c
disable hypervisor

convert to newer HYPERVISOR_physdev_op() interface, now command and the
arg are separate arguments - this is needed for newer physdev_op commands

remove code for PHYSDEVOP_IRQ_UNMASK_NOTIFY, it is obsolete since
interface version 0x00030202 and is unsupported by newer versions of Xen

confirmed working on amd64 Dom0, i386 compile-tested only

branches: 1.11.2;
remove <sys/malloc.h> include, not used here

Catchup with struct intrstub; unification.

This should fix dom0 build breakage.

Do not export the 'irq<->vector' abstraction outside of pintr.c
anymore. We now think of them as a unified thing called 'gsi',
which is generated by mpacpi/mpbios

Since GSIs are invented by the mpbios/mpacpi interrupt routing probe code,
it's possible for shared GSIs to popup even outside the original
legacy_irq range.

Relax this latter, older assumption.

Thanks to Brad Spencer for extensive trialing on interesting hardware.

Switch over to a "GSI" concept for guest irqs.

On XEN there is a namespace called GSI which includes:

i) legacy_irq (0 - 16)
ii) "gsi" (16-nr_irqs_gsi)
iii) msi

We try to mirror this in guest space, but are mindful that legacy_irq
is 1:1 bound to actual hardware legacy_irq. Apart from this, XEN doesn't
really care what number scheme we use, as long as it doesn't encroach
on the MSI space, which is TBD for us.

Thus we trust the mpbios.c/mpacpi.c code to correctly map the pic,pin
tuples into the correct global gsi space, which we then register with
xen. As we now do, we allow for duplicate gsi registrations, in case
any hardware shares the same (pic,pin);

This enables us to now use the (pic,pin) tuple as the canonical reference
for device interrupt addresses, and leave any global mappings to specific
code. Thus xen_pic_to_gsi().

Note that this requires separate support for MSI, which I will get around to
once things stabilise - however the API change facilitates this nicely.

I note that the msi addroute() function does not use the "pin" parameter.
This can be made use of, to encode the gsi number, for XEN. This is however
TBD.

We further tweak the xen_vec_alloc() code to be uniform for the NIOAPICS
and other cases, and ensure that i8259.c DTRT wrt to route().

This will allow us to use pic->pic_addroute() without needing to worry about
pic specific issues.

The next step is to consolidate the pic_addroute() XEN related #ifdefs into
a -DXEN specific file, so that we don't clutter x86/ code with #ifdef XENs.

This change has functional implications, and there is likely breakage coming
especially on bespoke platforms that I haven't been able to test yet.

I am especially interested in bug reports from platforms with legacy (esp. i386)
and with multiple ioapics.

Change the name of xen_pirq_alloc() to xen_vec_alloc() to reflect
its actual job.

The idea is that we will strip this down until it is as close to
idt_vec_alloc() as possible.

Move the pic->pic_addroute() call from within pintr.c:xen_pirq_alloc() to
intr.c:intr_establish_xname()

xen_pirq_alloc() now returns a vector value, as is intended by
the semantics of the call to the hypervisor, PHYSDEVOP_ASSIGN_VECTOR.

This also brings our usage closer to native.

Teach intr_establish_xname() for XEN to tolerate shared legacy_irq
registrations.

The current XEN code has not been able to tolerate shared legacy_irq
requests in xen_pirq_alloc(). This was never a problem because:

i) The only potential callpath with shared legacy_irq was
isa_intr_establish_xname().
ii) The other callpath, namely pci_intr_establish_xname() passed
legacy_irq to intr_establish_xname(). However, this was ignored,
and a value of zero was passed to xen_pirq_alloc() which in
turn, allocated a new irq value, thus effectively demultiplexing
any shared legacy_irq value intended across randomly allocated
new irq values.
iii) Presumably on all platforms that XEN runs on, the isa callpath
mentioned in i) never had shared irqs, and thus this was never
a problem.

Except:
We now use a unified path for both isa_intr_establish_xname() and
pci_intr_establish_xname(). This means that now, intr_establish_xname()
which is a callee of both, needs to have a way to discern who the caller
was, and decide to pass on or discard the legacy_irq value, to preserve
the old semantics. However, this is impossible to do so, because the
callpath doesn't explicitly provide a mechanism for this discernment.

This is however not a problem, because from XEN's point of view, a
repeat registration of an irq is only a warning. legacy_irq is the only
case in which this repeat should occur, per the current implementation of
xen_pirq_alloc(). We thus tweak the KASSERT()s to tolerate a repeat value
in the legacy_irq, while maintaining the original intent of the KASSERT()
which was to ensure that existing unrelated irq registrations should never
be overwritten.

Once we re-organise XEN specific code and unify with the native
intr_establish_xname() path, we will not run into this problem, because
legacy_irq will be treated as the pin number of the i8259 pic
exactly as it is now treated in native.

In short, this commit should fix some of the panics being seen on
-current for certain configurations of hardware on which dom0 runs.

branches: 1.3.2; 1.3.4;
Rename i8259_stubs -> legacy_stubs. We will want the entries to have the
same name, eg:

legacy_stubs
-> Xintr_legacy0, Xrecurse_legacy0, Xresume_legacy0
-> Xintr_legacy1, Xrecurse_legacy1, Xresume_legacy1
...

Fixes for physical interrupts on Xen:
- do not cast int * to intr_handle_t *, they're not the same size
- legacy_irq is not always -1 for ioapic interrupts, test pic_type instead
- change irq2port[] to hold (port + 1) so that 0 is an invalid value
- add KASSERTs to make sure vect, port or irq values extracted from arrays are
valid (or that they are invalid before write)
- for the !ioapic case, we still need to do PHYSDEVOP_ASSIGN_VECTOR and
bind_pirq_to_evtch().

now XEN3_DOM0 boots again

branches: 1.1.2;
On XEN dom0, the function xen/x86/intr.c:xen_intr_map() is used to map
hardware interrupts to XEN callbacks called 'events'. This function
combines both the allocation and the binding.

This change is the first part of breaking up that combination into
xen_pirq_alloc() and the binding will happen as part of the
pic_addroute() callback of a new pseudo PIC_XEN

This code will be added later on.

add support for using MSI for XenPV Dom0

use PHYSDEVOP_map_pirq to get the pirq/gsi for MSI/MSI-X, switch also INTx
to use it instead of PHYSDEVOP_alloc_irq_vector

MSI confirmed working with single-vector MSI for wm(4), ahcisata(4), bge(4)

XXX added some provision for MSI-X, but it doesn't actually work (no interrupts
delivered), needs some further investigation; disable MSI-X for XENPV
via flag in x86/pci/pci_machdep.c

Merge the bouyer-xenpvh branch, bringing in Xen PV drivers support under HVM
guests in GENERIC.
Xen support can be disabled at runtime with
boot -c
disable hypervisor

convert to newer HYPERVISOR_physdev_op() interface, now command and the
arg are separate arguments - this is needed for newer physdev_op commands

remove code for PHYSDEVOP_IRQ_UNMASK_NOTIFY, it is obsolete since
interface version 0x00030202 and is unsupported by newer versions of Xen

confirmed working on amd64 Dom0, i386 compile-tested only

branches: 1.11.2;
remove <sys/malloc.h> include, not used here

Catchup with struct intrstub; unification.

This should fix dom0 build breakage.

Do not export the 'irq<->vector' abstraction outside of pintr.c
anymore. We now think of them as a unified thing called 'gsi',
which is generated by mpacpi/mpbios

Since GSIs are invented by the mpbios/mpacpi interrupt routing probe code,
it's possible for shared GSIs to popup even outside the original
legacy_irq range.

Relax this latter, older assumption.

Thanks to Brad Spencer for extensive trialing on interesting hardware.

Switch over to a "GSI" concept for guest irqs.

On XEN there is a namespace called GSI which includes:

i) legacy_irq (0 - 16)
ii) "gsi" (16-nr_irqs_gsi)
iii) msi

We try to mirror this in guest space, but are mindful that legacy_irq
is 1:1 bound to actual hardware legacy_irq. Apart from this, XEN doesn't
really care what number scheme we use, as long as it doesn't encroach
on the MSI space, which is TBD for us.

Thus we trust the mpbios.c/mpacpi.c code to correctly map the pic,pin
tuples into the correct global gsi space, which we then register with
xen. As we now do, we allow for duplicate gsi registrations, in case
any hardware shares the same (pic,pin);

This enables us to now use the (pic,pin) tuple as the canonical reference
for device interrupt addresses, and leave any global mappings to specific
code. Thus xen_pic_to_gsi().

Note that this requires separate support for MSI, which I will get around to
once things stabilise - however the API change facilitates this nicely.

I note that the msi addroute() function does not use the "pin" parameter.
This can be made use of, to encode the gsi number, for XEN. This is however
TBD.

We further tweak the xen_vec_alloc() code to be uniform for the NIOAPICS
and other cases, and ensure that i8259.c DTRT wrt to route().

This will allow us to use pic->pic_addroute() without needing to worry about
pic specific issues.

The next step is to consolidate the pic_addroute() XEN related #ifdefs into
a -DXEN specific file, so that we don't clutter x86/ code with #ifdef XENs.

This change has functional implications, and there is likely breakage coming
especially on bespoke platforms that I haven't been able to test yet.

I am especially interested in bug reports from platforms with legacy (esp. i386)
and with multiple ioapics.

Change the name of xen_pirq_alloc() to xen_vec_alloc() to reflect
its actual job.

The idea is that we will strip this down until it is as close to
idt_vec_alloc() as possible.

Move the pic->pic_addroute() call from within pintr.c:xen_pirq_alloc() to
intr.c:intr_establish_xname()

xen_pirq_alloc() now returns a vector value, as is intended by
the semantics of the call to the hypervisor, PHYSDEVOP_ASSIGN_VECTOR.

This also brings our usage closer to native.

Teach intr_establish_xname() for XEN to tolerate shared legacy_irq
registrations.

The current XEN code has not been able to tolerate shared legacy_irq
requests in xen_pirq_alloc(). This was never a problem because:

i) The only potential callpath with shared legacy_irq was
isa_intr_establish_xname().
ii) The other callpath, namely pci_intr_establish_xname() passed
legacy_irq to intr_establish_xname(). However, this was ignored,
and a value of zero was passed to xen_pirq_alloc() which in
turn, allocated a new irq value, thus effectively demultiplexing
any shared legacy_irq value intended across randomly allocated
new irq values.
iii) Presumably on all platforms that XEN runs on, the isa callpath
mentioned in i) never had shared irqs, and thus this was never
a problem.

Except:
We now use a unified path for both isa_intr_establish_xname() and
pci_intr_establish_xname(). This means that now, intr_establish_xname()
which is a callee of both, needs to have a way to discern who the caller
was, and decide to pass on or discard the legacy_irq value, to preserve
the old semantics. However, this is impossible to do so, because the
callpath doesn't explicitly provide a mechanism for this discernment.

This is however not a problem, because from XEN's point of view, a
repeat registration of an irq is only a warning. legacy_irq is the only
case in which this repeat should occur, per the current implementation of
xen_pirq_alloc(). We thus tweak the KASSERT()s to tolerate a repeat value
in the legacy_irq, while maintaining the original intent of the KASSERT()
which was to ensure that existing unrelated irq registrations should never
be overwritten.

Once we re-organise XEN specific code and unify with the native
intr_establish_xname() path, we will not run into this problem, because
legacy_irq will be treated as the pin number of the i8259 pic
exactly as it is now treated in native.

In short, this commit should fix some of the panics being seen on
-current for certain configurations of hardware on which dom0 runs.

branches: 1.3.2; 1.3.4;
Rename i8259_stubs -> legacy_stubs. We will want the entries to have the
same name, eg:

legacy_stubs
-> Xintr_legacy0, Xrecurse_legacy0, Xresume_legacy0
-> Xintr_legacy1, Xrecurse_legacy1, Xresume_legacy1
...

Fixes for physical interrupts on Xen:
- do not cast int * to intr_handle_t *, they're not the same size
- legacy_irq is not always -1 for ioapic interrupts, test pic_type instead
- change irq2port[] to hold (port + 1) so that 0 is an invalid value
- add KASSERTs to make sure vect, port or irq values extracted from arrays are
valid (or that they are invalid before write)
- for the !ioapic case, we still need to do PHYSDEVOP_ASSIGN_VECTOR and
bind_pirq_to_evtch().

now XEN3_DOM0 boots again

branches: 1.1.2;
On XEN dom0, the function xen/x86/intr.c:xen_intr_map() is used to map
hardware interrupts to XEN callbacks called 'events'. This function
combines both the allocation and the binding.

This change is the first part of breaking up that combination into
xen_pirq_alloc() and the binding will happen as part of the
pic_addroute() callback of a new pseudo PIC_XEN

This code will be added later on.

Merge the bouyer-xenpvh branch, bringing in Xen PV drivers support under HVM
guests in GENERIC.
Xen support can be disabled at runtime with
boot -c
disable hypervisor

convert to newer HYPERVISOR_physdev_op() interface, now command and the
arg are separate arguments - this is needed for newer physdev_op commands

remove code for PHYSDEVOP_IRQ_UNMASK_NOTIFY, it is obsolete since
interface version 0x00030202 and is unsupported by newer versions of Xen

confirmed working on amd64 Dom0, i386 compile-tested only

branches: 1.11.2;
remove <sys/malloc.h> include, not used here

Catchup with struct intrstub; unification.

This should fix dom0 build breakage.

Do not export the 'irq<->vector' abstraction outside of pintr.c
anymore. We now think of them as a unified thing called 'gsi',
which is generated by mpacpi/mpbios

Since GSIs are invented by the mpbios/mpacpi interrupt routing probe code,
it's possible for shared GSIs to popup even outside the original
legacy_irq range.

Relax this latter, older assumption.

Thanks to Brad Spencer for extensive trialing on interesting hardware.

Switch over to a "GSI" concept for guest irqs.

On XEN there is a namespace called GSI which includes:

i) legacy_irq (0 - 16)
ii) "gsi" (16-nr_irqs_gsi)
iii) msi

We try to mirror this in guest space, but are mindful that legacy_irq
is 1:1 bound to actual hardware legacy_irq. Apart from this, XEN doesn't
really care what number scheme we use, as long as it doesn't encroach
on the MSI space, which is TBD for us.

Thus we trust the mpbios.c/mpacpi.c code to correctly map the pic,pin
tuples into the correct global gsi space, which we then register with
xen. As we now do, we allow for duplicate gsi registrations, in case
any hardware shares the same (pic,pin);

This enables us to now use the (pic,pin) tuple as the canonical reference
for device interrupt addresses, and leave any global mappings to specific
code. Thus xen_pic_to_gsi().

Note that this requires separate support for MSI, which I will get around to
once things stabilise - however the API change facilitates this nicely.

I note that the msi addroute() function does not use the "pin" parameter.
This can be made use of, to encode the gsi number, for XEN. This is however
TBD.

We further tweak the xen_vec_alloc() code to be uniform for the NIOAPICS
and other cases, and ensure that i8259.c DTRT wrt to route().

This will allow us to use pic->pic_addroute() without needing to worry about
pic specific issues.

The next step is to consolidate the pic_addroute() XEN related #ifdefs into
a -DXEN specific file, so that we don't clutter x86/ code with #ifdef XENs.

This change has functional implications, and there is likely breakage coming
especially on bespoke platforms that I haven't been able to test yet.

I am especially interested in bug reports from platforms with legacy (esp. i386)
and with multiple ioapics.

Change the name of xen_pirq_alloc() to xen_vec_alloc() to reflect
its actual job.

The idea is that we will strip this down until it is as close to
idt_vec_alloc() as possible.

Move the pic->pic_addroute() call from within pintr.c:xen_pirq_alloc() to
intr.c:intr_establish_xname()

xen_pirq_alloc() now returns a vector value, as is intended by
the semantics of the call to the hypervisor, PHYSDEVOP_ASSIGN_VECTOR.

This also brings our usage closer to native.

Teach intr_establish_xname() for XEN to tolerate shared legacy_irq
registrations.

The current XEN code has not been able to tolerate shared legacy_irq
requests in xen_pirq_alloc(). This was never a problem because:

i) The only potential callpath with shared legacy_irq was
isa_intr_establish_xname().
ii) The other callpath, namely pci_intr_establish_xname() passed
legacy_irq to intr_establish_xname(). However, this was ignored,
and a value of zero was passed to xen_pirq_alloc() which in
turn, allocated a new irq value, thus effectively demultiplexing
any shared legacy_irq value intended across randomly allocated
new irq values.
iii) Presumably on all platforms that XEN runs on, the isa callpath
mentioned in i) never had shared irqs, and thus this was never
a problem.

Except:
We now use a unified path for both isa_intr_establish_xname() and
pci_intr_establish_xname(). This means that now, intr_establish_xname()
which is a callee of both, needs to have a way to discern who the caller
was, and decide to pass on or discard the legacy_irq value, to preserve
the old semantics. However, this is impossible to do so, because the
callpath doesn't explicitly provide a mechanism for this discernment.

This is however not a problem, because from XEN's point of view, a
repeat registration of an irq is only a warning. legacy_irq is the only
case in which this repeat should occur, per the current implementation of
xen_pirq_alloc(). We thus tweak the KASSERT()s to tolerate a repeat value
in the legacy_irq, while maintaining the original intent of the KASSERT()
which was to ensure that existing unrelated irq registrations should never
be overwritten.

Once we re-organise XEN specific code and unify with the native
intr_establish_xname() path, we will not run into this problem, because
legacy_irq will be treated as the pin number of the i8259 pic
exactly as it is now treated in native.

In short, this commit should fix some of the panics being seen on
-current for certain configurations of hardware on which dom0 runs.

branches: 1.3.2; 1.3.4;
Rename i8259_stubs -> legacy_stubs. We will want the entries to have the
same name, eg:

legacy_stubs
-> Xintr_legacy0, Xrecurse_legacy0, Xresume_legacy0
-> Xintr_legacy1, Xrecurse_legacy1, Xresume_legacy1
...

Fixes for physical interrupts on Xen:
- do not cast int * to intr_handle_t *, they're not the same size
- legacy_irq is not always -1 for ioapic interrupts, test pic_type instead
- change irq2port[] to hold (port + 1) so that 0 is an invalid value
- add KASSERTs to make sure vect, port or irq values extracted from arrays are
valid (or that they are invalid before write)
- for the !ioapic case, we still need to do PHYSDEVOP_ASSIGN_VECTOR and
bind_pirq_to_evtch().

now XEN3_DOM0 boots again

branches: 1.1.2;
On XEN dom0, the function xen/x86/intr.c:xen_intr_map() is used to map
hardware interrupts to XEN callbacks called 'events'. This function
combines both the allocation and the binding.

This change is the first part of breaking up that combination into
xen_pirq_alloc() and the binding will happen as part of the
pic_addroute() callback of a new pseudo PIC_XEN

This code will be added later on.

convert to newer HYPERVISOR_physdev_op() interface, now command and the
arg are separate arguments - this is needed for newer physdev_op commands

remove code for PHYSDEVOP_IRQ_UNMASK_NOTIFY, it is obsolete since
interface version 0x00030202 and is unsupported by newer versions of Xen

confirmed working on amd64 Dom0, i386 compile-tested only

remove <sys/malloc.h> include, not used here

Catchup with struct intrstub; unification.

This should fix dom0 build breakage.

Do not export the 'irq<->vector' abstraction outside of pintr.c
anymore. We now think of them as a unified thing called 'gsi',
which is generated by mpacpi/mpbios

Since GSIs are invented by the mpbios/mpacpi interrupt routing probe code,
it's possible for shared GSIs to popup even outside the original
legacy_irq range.

Relax this latter, older assumption.

Thanks to Brad Spencer for extensive trialing on interesting hardware.

Switch over to a "GSI" concept for guest irqs.

On XEN there is a namespace called GSI which includes:

i) legacy_irq (0 - 16)
ii) "gsi" (16-nr_irqs_gsi)
iii) msi

We try to mirror this in guest space, but are mindful that legacy_irq
is 1:1 bound to actual hardware legacy_irq. Apart from this, XEN doesn't
really care what number scheme we use, as long as it doesn't encroach
on the MSI space, which is TBD for us.

Thus we trust the mpbios.c/mpacpi.c code to correctly map the pic,pin
tuples into the correct global gsi space, which we then register with
xen. As we now do, we allow for duplicate gsi registrations, in case
any hardware shares the same (pic,pin);

This enables us to now use the (pic,pin) tuple as the canonical reference
for device interrupt addresses, and leave any global mappings to specific
code. Thus xen_pic_to_gsi().

Note that this requires separate support for MSI, which I will get around to
once things stabilise - however the API change facilitates this nicely.

I note that the msi addroute() function does not use the "pin" parameter.
This can be made use of, to encode the gsi number, for XEN. This is however
TBD.

We further tweak the xen_vec_alloc() code to be uniform for the NIOAPICS
and other cases, and ensure that i8259.c DTRT wrt to route().

This will allow us to use pic->pic_addroute() without needing to worry about
pic specific issues.

The next step is to consolidate the pic_addroute() XEN related #ifdefs into
a -DXEN specific file, so that we don't clutter x86/ code with #ifdef XENs.

This change has functional implications, and there is likely breakage coming
especially on bespoke platforms that I haven't been able to test yet.

I am especially interested in bug reports from platforms with legacy (esp. i386)
and with multiple ioapics.

Change the name of xen_pirq_alloc() to xen_vec_alloc() to reflect
its actual job.

The idea is that we will strip this down until it is as close to
idt_vec_alloc() as possible.

Move the pic->pic_addroute() call from within pintr.c:xen_pirq_alloc() to
intr.c:intr_establish_xname()

xen_pirq_alloc() now returns a vector value, as is intended by
the semantics of the call to the hypervisor, PHYSDEVOP_ASSIGN_VECTOR.

This also brings our usage closer to native.

Teach intr_establish_xname() for XEN to tolerate shared legacy_irq
registrations.

The current XEN code has not been able to tolerate shared legacy_irq
requests in xen_pirq_alloc(). This was never a problem because:

i) The only potential callpath with shared legacy_irq was
isa_intr_establish_xname().
ii) The other callpath, namely pci_intr_establish_xname() passed
legacy_irq to intr_establish_xname(). However, this was ignored,
and a value of zero was passed to xen_pirq_alloc() which in
turn, allocated a new irq value, thus effectively demultiplexing
any shared legacy_irq value intended across randomly allocated
new irq values.
iii) Presumably on all platforms that XEN runs on, the isa callpath
mentioned in i) never had shared irqs, and thus this was never
a problem.

Except:
We now use a unified path for both isa_intr_establish_xname() and
pci_intr_establish_xname(). This means that now, intr_establish_xname()
which is a callee of both, needs to have a way to discern who the caller
was, and decide to pass on or discard the legacy_irq value, to preserve
the old semantics. However, this is impossible to do so, because the
callpath doesn't explicitly provide a mechanism for this discernment.

This is however not a problem, because from XEN's point of view, a
repeat registration of an irq is only a warning. legacy_irq is the only
case in which this repeat should occur, per the current implementation of
xen_pirq_alloc(). We thus tweak the KASSERT()s to tolerate a repeat value
in the legacy_irq, while maintaining the original intent of the KASSERT()
which was to ensure that existing unrelated irq registrations should never
be overwritten.

Once we re-organise XEN specific code and unify with the native
intr_establish_xname() path, we will not run into this problem, because
legacy_irq will be treated as the pin number of the i8259 pic
exactly as it is now treated in native.

In short, this commit should fix some of the panics being seen on
-current for certain configurations of hardware on which dom0 runs.

branches: 1.3.2; 1.3.4;
Rename i8259_stubs -> legacy_stubs. We will want the entries to have the
same name, eg:

legacy_stubs
-> Xintr_legacy0, Xrecurse_legacy0, Xresume_legacy0
-> Xintr_legacy1, Xrecurse_legacy1, Xresume_legacy1
...

Fixes for physical interrupts on Xen:
- do not cast int * to intr_handle_t *, they're not the same size
- legacy_irq is not always -1 for ioapic interrupts, test pic_type instead
- change irq2port[] to hold (port + 1) so that 0 is an invalid value
- add KASSERTs to make sure vect, port or irq values extracted from arrays are
valid (or that they are invalid before write)
- for the !ioapic case, we still need to do PHYSDEVOP_ASSIGN_VECTOR and
bind_pirq_to_evtch().

now XEN3_DOM0 boots again

branches: 1.1.2;
On XEN dom0, the function xen/x86/intr.c:xen_intr_map() is used to map
hardware interrupts to XEN callbacks called 'events'. This function
combines both the allocation and the binding.

This change is the first part of breaking up that combination into
xen_pirq_alloc() and the binding will happen as part of the
pic_addroute() callback of a new pseudo PIC_XEN

This code will be added later on.

remove <sys/malloc.h> include, not used here

Catchup with struct intrstub; unification.

This should fix dom0 build breakage.

Do not export the 'irq<->vector' abstraction outside of pintr.c
anymore. We now think of them as a unified thing called 'gsi',
which is generated by mpacpi/mpbios

Since GSIs are invented by the mpbios/mpacpi interrupt routing probe code,
it's possible for shared GSIs to popup even outside the original
legacy_irq range.

Relax this latter, older assumption.

Thanks to Brad Spencer for extensive trialing on interesting hardware.

Switch over to a "GSI" concept for guest irqs.

On XEN there is a namespace called GSI which includes:

i) legacy_irq (0 - 16)
ii) "gsi" (16-nr_irqs_gsi)
iii) msi

We try to mirror this in guest space, but are mindful that legacy_irq
is 1:1 bound to actual hardware legacy_irq. Apart from this, XEN doesn't
really care what number scheme we use, as long as it doesn't encroach
on the MSI space, which is TBD for us.

Thus we trust the mpbios.c/mpacpi.c code to correctly map the pic,pin
tuples into the correct global gsi space, which we then register with
xen. As we now do, we allow for duplicate gsi registrations, in case
any hardware shares the same (pic,pin);

This enables us to now use the (pic,pin) tuple as the canonical reference
for device interrupt addresses, and leave any global mappings to specific
code. Thus xen_pic_to_gsi().

Note that this requires separate support for MSI, which I will get around to
once things stabilise - however the API change facilitates this nicely.

I note that the msi addroute() function does not use the "pin" parameter.
This can be made use of, to encode the gsi number, for XEN. This is however
TBD.

We further tweak the xen_vec_alloc() code to be uniform for the NIOAPICS
and other cases, and ensure that i8259.c DTRT wrt to route().

This will allow us to use pic->pic_addroute() without needing to worry about
pic specific issues.

The next step is to consolidate the pic_addroute() XEN related #ifdefs into
a -DXEN specific file, so that we don't clutter x86/ code with #ifdef XENs.

This change has functional implications, and there is likely breakage coming
especially on bespoke platforms that I haven't been able to test yet.

I am especially interested in bug reports from platforms with legacy (esp. i386)
and with multiple ioapics.

Change the name of xen_pirq_alloc() to xen_vec_alloc() to reflect
its actual job.

The idea is that we will strip this down until it is as close to
idt_vec_alloc() as possible.

Move the pic->pic_addroute() call from within pintr.c:xen_pirq_alloc() to
intr.c:intr_establish_xname()

xen_pirq_alloc() now returns a vector value, as is intended by
the semantics of the call to the hypervisor, PHYSDEVOP_ASSIGN_VECTOR.

This also brings our usage closer to native.

Teach intr_establish_xname() for XEN to tolerate shared legacy_irq
registrations.

The current XEN code has not been able to tolerate shared legacy_irq
requests in xen_pirq_alloc(). This was never a problem because:

i) The only potential callpath with shared legacy_irq was
isa_intr_establish_xname().
ii) The other callpath, namely pci_intr_establish_xname() passed
legacy_irq to intr_establish_xname(). However, this was ignored,
and a value of zero was passed to xen_pirq_alloc() which in
turn, allocated a new irq value, thus effectively demultiplexing
any shared legacy_irq value intended across randomly allocated
new irq values.
iii) Presumably on all platforms that XEN runs on, the isa callpath
mentioned in i) never had shared irqs, and thus this was never
a problem.

Except:
We now use a unified path for both isa_intr_establish_xname() and
pci_intr_establish_xname(). This means that now, intr_establish_xname()
which is a callee of both, needs to have a way to discern who the caller
was, and decide to pass on or discard the legacy_irq value, to preserve
the old semantics. However, this is impossible to do so, because the
callpath doesn't explicitly provide a mechanism for this discernment.

This is however not a problem, because from XEN's point of view, a
repeat registration of an irq is only a warning. legacy_irq is the only
case in which this repeat should occur, per the current implementation of
xen_pirq_alloc(). We thus tweak the KASSERT()s to tolerate a repeat value
in the legacy_irq, while maintaining the original intent of the KASSERT()
which was to ensure that existing unrelated irq registrations should never
be overwritten.

Once we re-organise XEN specific code and unify with the native
intr_establish_xname() path, we will not run into this problem, because
legacy_irq will be treated as the pin number of the i8259 pic
exactly as it is now treated in native.

In short, this commit should fix some of the panics being seen on
-current for certain configurations of hardware on which dom0 runs.

branches: 1.3.2; 1.3.4;
Rename i8259_stubs -> legacy_stubs. We will want the entries to have the
same name, eg:

legacy_stubs
-> Xintr_legacy0, Xrecurse_legacy0, Xresume_legacy0
-> Xintr_legacy1, Xrecurse_legacy1, Xresume_legacy1
...

Fixes for physical interrupts on Xen:
- do not cast int * to intr_handle_t *, they're not the same size
- legacy_irq is not always -1 for ioapic interrupts, test pic_type instead
- change irq2port[] to hold (port + 1) so that 0 is an invalid value
- add KASSERTs to make sure vect, port or irq values extracted from arrays are
valid (or that they are invalid before write)
- for the !ioapic case, we still need to do PHYSDEVOP_ASSIGN_VECTOR and
bind_pirq_to_evtch().

now XEN3_DOM0 boots again

branches: 1.1.2;
On XEN dom0, the function xen/x86/intr.c:xen_intr_map() is used to map
hardware interrupts to XEN callbacks called 'events'. This function
combines both the allocation and the binding.

This change is the first part of breaking up that combination into
xen_pirq_alloc() and the binding will happen as part of the
pic_addroute() callback of a new pseudo PIC_XEN

This code will be added later on.

Catchup with struct intrstub; unification.

This should fix dom0 build breakage.

Do not export the 'irq<->vector' abstraction outside of pintr.c
anymore. We now think of them as a unified thing called 'gsi',
which is generated by mpacpi/mpbios

Since GSIs are invented by the mpbios/mpacpi interrupt routing probe code,
it's possible for shared GSIs to popup even outside the original
legacy_irq range.

Relax this latter, older assumption.

Thanks to Brad Spencer for extensive trialing on interesting hardware.

Switch over to a "GSI" concept for guest irqs.

On XEN there is a namespace called GSI which includes:

i) legacy_irq (0 - 16)
ii) "gsi" (16-nr_irqs_gsi)
iii) msi

We try to mirror this in guest space, but are mindful that legacy_irq
is 1:1 bound to actual hardware legacy_irq. Apart from this, XEN doesn't
really care what number scheme we use, as long as it doesn't encroach
on the MSI space, which is TBD for us.

Thus we trust the mpbios.c/mpacpi.c code to correctly map the pic,pin
tuples into the correct global gsi space, which we then register with
xen. As we now do, we allow for duplicate gsi registrations, in case
any hardware shares the same (pic,pin);

This enables us to now use the (pic,pin) tuple as the canonical reference
for device interrupt addresses, and leave any global mappings to specific
code. Thus xen_pic_to_gsi().

Note that this requires separate support for MSI, which I will get around to
once things stabilise - however the API change facilitates this nicely.

I note that the msi addroute() function does not use the "pin" parameter.
This can be made use of, to encode the gsi number, for XEN. This is however
TBD.

We further tweak the xen_vec_alloc() code to be uniform for the NIOAPICS
and other cases, and ensure that i8259.c DTRT wrt to route().

This will allow us to use pic->pic_addroute() without needing to worry about
pic specific issues.

The next step is to consolidate the pic_addroute() XEN related #ifdefs into
a -DXEN specific file, so that we don't clutter x86/ code with #ifdef XENs.

This change has functional implications, and there is likely breakage coming
especially on bespoke platforms that I haven't been able to test yet.

I am especially interested in bug reports from platforms with legacy (esp. i386)
and with multiple ioapics.

Change the name of xen_pirq_alloc() to xen_vec_alloc() to reflect
its actual job.

The idea is that we will strip this down until it is as close to
idt_vec_alloc() as possible.

Move the pic->pic_addroute() call from within pintr.c:xen_pirq_alloc() to
intr.c:intr_establish_xname()

xen_pirq_alloc() now returns a vector value, as is intended by
the semantics of the call to the hypervisor, PHYSDEVOP_ASSIGN_VECTOR.

This also brings our usage closer to native.

Teach intr_establish_xname() for XEN to tolerate shared legacy_irq
registrations.

The current XEN code has not been able to tolerate shared legacy_irq
requests in xen_pirq_alloc(). This was never a problem because:

i) The only potential callpath with shared legacy_irq was
isa_intr_establish_xname().
ii) The other callpath, namely pci_intr_establish_xname() passed
legacy_irq to intr_establish_xname(). However, this was ignored,
and a value of zero was passed to xen_pirq_alloc() which in
turn, allocated a new irq value, thus effectively demultiplexing
any shared legacy_irq value intended across randomly allocated
new irq values.
iii) Presumably on all platforms that XEN runs on, the isa callpath
mentioned in i) never had shared irqs, and thus this was never
a problem.

Except:
We now use a unified path for both isa_intr_establish_xname() and
pci_intr_establish_xname(). This means that now, intr_establish_xname()
which is a callee of both, needs to have a way to discern who the caller
was, and decide to pass on or discard the legacy_irq value, to preserve
the old semantics. However, this is impossible to do so, because the
callpath doesn't explicitly provide a mechanism for this discernment.

This is however not a problem, because from XEN's point of view, a
repeat registration of an irq is only a warning. legacy_irq is the only
case in which this repeat should occur, per the current implementation of
xen_pirq_alloc(). We thus tweak the KASSERT()s to tolerate a repeat value
in the legacy_irq, while maintaining the original intent of the KASSERT()
which was to ensure that existing unrelated irq registrations should never
be overwritten.

Once we re-organise XEN specific code and unify with the native
intr_establish_xname() path, we will not run into this problem, because
legacy_irq will be treated as the pin number of the i8259 pic
exactly as it is now treated in native.

In short, this commit should fix some of the panics being seen on
-current for certain configurations of hardware on which dom0 runs.

branches: 1.3.2;
Rename i8259_stubs -> legacy_stubs. We will want the entries to have the
same name, eg:

legacy_stubs
-> Xintr_legacy0, Xrecurse_legacy0, Xresume_legacy0
-> Xintr_legacy1, Xrecurse_legacy1, Xresume_legacy1
...

Fixes for physical interrupts on Xen:
- do not cast int * to intr_handle_t *, they're not the same size
- legacy_irq is not always -1 for ioapic interrupts, test pic_type instead
- change irq2port[] to hold (port + 1) so that 0 is an invalid value
- add KASSERTs to make sure vect, port or irq values extracted from arrays are
valid (or that they are invalid before write)
- for the !ioapic case, we still need to do PHYSDEVOP_ASSIGN_VECTOR and
bind_pirq_to_evtch().

now XEN3_DOM0 boots again

branches: 1.1.2;
On XEN dom0, the function xen/x86/intr.c:xen_intr_map() is used to map
hardware interrupts to XEN callbacks called 'events'. This function
combines both the allocation and the binding.

This change is the first part of breaking up that combination into
xen_pirq_alloc() and the binding will happen as part of the
pic_addroute() callback of a new pseudo PIC_XEN

This code will be added later on.

Fixes for physical interrupts on Xen:
- do not cast int * to intr_handle_t *, they're not the same size
- legacy_irq is not always -1 for ioapic interrupts, test pic_type instead
- change irq2port[] to hold (port + 1) so that 0 is an invalid value
- add KASSERTs to make sure vect, port or irq values extracted from arrays are
valid (or that they are invalid before write)
- for the !ioapic case, we still need to do PHYSDEVOP_ASSIGN_VECTOR and
bind_pirq_to_evtch().

now XEN3_DOM0 boots again

branches: 1.1.2;
On XEN dom0, the function xen/x86/intr.c:xen_intr_map() is used to map
hardware interrupts to XEN callbacks called 'events'. This function
combines both the allocation and the binding.

This change is the first part of breaking up that combination into
xen_pirq_alloc() and the binding will happen as part of the
pic_addroute() callback of a new pseudo PIC_XEN

This code will be added later on.