msi: Support APIC Extended Destination IDs

[cperciva]

Summary

Without an IOMMU, the APIC standard only allow 8 bits of Destination ID
for MSI messages, limiting us to 256 CPUs. While IOMMUs can allow for
more than 256 CPUs to be supported, they are not necessarily desireable
in virtualized environments.

Implement the Extended Destination ID standard authored by David
Woodhouse, which uses 7 "Reserved" bits for the high bits of a 15-bit
Extended Destination ID: http://david.woodhou.se/ExtDestId.pdf

This standard is implemented on the host side in Xen, Hyper-V, KVM,
and Bhyve; future commits will add code to detect and enable it
automatically but in the mean time it can be enabled via the loader
tunable machdep.msi_ext_dest_id.

MFC after: 2 weeks

[cperciva]

Made ext_dest_id static

[kib]

sys/x86/x86/msi.c

100

Should it be SYSCTL_BOOL?

[cperciva]

sys/x86/x86/msi.c

100

I'm actually about to change this to be tri-state, with -1 meaning "autodetect", so that the loader tunable can set this in either direction. So yes it probably should have been, but no it shouldn't be after that change.

[kib]

sys/x86/x86/msi.c

666

This line seems to be over-indented by one space.

[cperciva]

Switch machdep.msi_ext_dest_id to tristate

-1 (default) means autodetect

Setting the loader tunable to 0 or 1 forces the state off or on.

[kib]

sys/x86/x86/msi.c

105

Too much indentation for this line too.

[cperciva]

sys/x86/x86/msi.c

105

That indentation was there in the original INTEL_ADDR which I copied. Although perhaps the second line (which I added) should have the same extra half-indent?

666

That was deliberate based on the nesting of parentheses; I thought it was clearer this way.

[kib]

sys/x86/x86/msi.c

105

I believe all lines after the first must have the same indent, per style.

666

Style(9) does not say anything about increasing indent for nested expressions. It is plain +4 spaces, same for all continuation lines.