MFC 303886: Add additional constants.

- Add constants for the fields in the root-entry table address register,
namely the root type type (RTT) and root table address (RTA) mask.
- Add macros for the bitmask of the domain ID field in the second word
of context table entries as well as a helper macro (DMAR_CTX2_GET_DID)
to extract the domain ID from a context table entry.

Sponsored by: Chelsio Communications

MFC r286777:
Comment only change, fix grammar and somewhat clarify the action.

MFC r283735:
Remove several write-only variables.

MFC r283692:
Explicitely enable queued invalidation completion interrupt.

MFC r281254:
Account for the offset of the page run when allocating the
dmar_map_entry.

MFC r280435:
When mapping an allocated entry, use the entry size, instead of the
requested size. If tag restrictions caused split entry, its size is
less then requsted.

MFC r280434:
Assert that the mapping loop makes progress.

MFC r280254:
Provide definitions for all descriptors types in the DMAR invalidation
queue.

MFC r280196:
Recheck that boundary is not crossed after the move to satisfy boundary
restriction.

MFC r280195:
When inserting new entry into the address map, ensure that not only
next entry does not intersect with the tail of the new entry, but also
that previous entry is also before new entry start.

MFC r280253:
Fix syntax error.

MFC r276949:
(only to ease merging of r279117).

MFC r279117:
Revert r276949 and redo the fix for PCIe/PCI bridges, which do not
follow specification and do not provide PCIe capability.

MFC r276948:
Print rid when announcing DMAR context creation. Print sid when fault
occurs.

MFC r276867:
Fix DMAR context allocations for the devices behind PCIe->PCI bridges
after dmar driver was converted to use rids. The bus component to
calculate context page must be taken from the requestor rid, which is
a bridge, and not from the device bus number.

MFC r264007,r264008,r264009,r264011,r264012,r264013

MFC support for PCI Alternate RID Interpretation. ARI is an optional PCIe
feature that allows PCI devices to present up to 256 functions on a bus.
This is effectively a prerequisite for PCI SR-IOV support.

r264007:
Add a method to get the PCI RID for a device.

Reviewed by: kib
MFC after: 2 months
Sponsored by: Sandvine Inc.

r264008:
Re-implement the DMAR I/O MMU code in terms of PCI RIDs

Under the hood the VT-d spec is really implemented in terms of
PCI RIDs instead of bus/slot/function, even though the spec makes
pains to convert back to bus/slot/function in examples. However
working with bus/slot/function is not correct when PCI ARI is
in use, so convert to using RIDs in most cases. bus/slot/function
will only be used when reporting errors to a user.

Reviewed by: kib
MFC after: 2 months
Sponsored by: Sandvine Inc.

r264009:
Re-write bhyve's I/O MMU handling in terms of PCI RID.

Reviewed by: neel
MFC after: 2 months
Sponsored by: Sandvine Inc.

r264011:
Add support for PCIe ARI

PCIe Alternate RID Interpretation (ARI) is an optional feature that
allows devices to have up to 256 different functions. It is
implemented by always setting the PCI slot number to 0 and
re-purposing the 5 bits used to encode the slot number to instead
contain the function number. Combined with the original 3 bits
allocated for the function number, this allows for 256 functions.

This is enabled by default, but it's expected to be a no-op on currently
supported hardware. It's a prerequisite for supporting PCI SR-IOV, and
I want the ARI support to go in early to help shake out any bugs in it.
ARI can be disabled by setting the tunable hw.pci.enable_ari=0.

Reviewed by: kib
MFC after: 2 months
Sponsored by: Sandvine Inc.

r264012:
Print status of ARI capability in pciconf -c

Teach pciconf how to print out the status (enabled/disabled) of the ARI
capability on PCI Root Complexes and Downstream Ports.

MFC after: 2 months
Sponsored by: Sandvine Inc.

r264013:
Add missing copyright date.

MFC after: 2 months

MFC r278606:
Registers definitions for the new capabilities.

MFC r278605:
vm_page_lookup() accepts read-locked object.

MFC r277023:
Avoid excessive flushing and do missed neccessary flushing in the IOMMU
page table update code.

MFC r263306:
Add some support for the PCI(e)-PCI bridges to the Intel VT-d driver.

MFC r263305:
Provide a workaround by identity mapping the 32 pages after the bogus
entry start, which seems to be enough for the reported BIOS.

MFC r263304:
Trim at EOL.

MFC r258779,r258780,r258787,r258822:

Fix undefined behavior: (1 << 31) is not defined as 1 is an int and this
shifts into the sign bit. Instead use (1U << 31) which gets the
expected result.

Similar to the (1 << 31) case it is not defined to do (2 << 30).

This fix is not ideal as it assumes a 32 bit int, but does fix the issue
for most cases.

A similar change was made in OpenBSD.

MFC DMAR busdma implementation.

MFC r257251:
Import the driver for VT-d DMAR hardware. Implement the busdma(9) using DMARs.

MFC r257512:
Add support for queued invalidation.

MFC miscellaneous follow-ups to r257251.

MFC r257266:
Remove redundand assignment to error variable and check for its value.

MFC r257308:
Remove redundand declaration.

MFC r257511:
Return BUS_PROBE_NOWILDCARD from the DMAR probe method.

MFC r257860,r257896,r257900,r257902,r257903 (by dim):
Fixes for gcc compilation.

Import the driver for VT-d DMAR hardware, as specified in the revision
1.3 of Intelб╝ Virtualization Technology for Directed I/O Architecture
Specification. The Extended Context and PASIDs from the rev. 2.2 are
not supported, but I am not aware of any released hardware which
implements them. Code does not use queued invalidation, see comments
for the reason, and does not provide interrupt remapping services.

Code implements the management of the guest address space per domain
and allows to establish and tear down arbitrary mappings, but not
partial unmapping. The superpages are created as needed, but not
promoted. Faults are recorded, fault records could be obtained
programmatically, and printed on the console.

Implement the busdma(9) using DMARs. This busdma backend avoids
bouncing and provides security against misbehaving hardware and driver
bad programming, preventing leaks and corruption of the memory by wild
DMA accesses.

By default, the implementation is compiled into amd64 GENERIC kernel
but disabled; to enable, set hw.dmar.enable=1 loader tunable. Code is
written to work on i386, but testing there was low priority, and
driver is not enabled in GENERIC. Even with the DMAR turned on,
individual devices could be directed to use the bounce busdma with the
hw.busdma.pci<domain>:<bus>:<device>:<function>.bounce=1 tunable. If
DMARs are capable of the pass-through translations, it is used,
otherwise, an identity-mapping page table is constructed.

The driver was tested on Xeon 5400/5500 chipset legacy machine,
Haswell desktop and E5 SandyBridge dual-socket boxes, with ahci(4),
ata(4), bce(4), ehci(4), mfi(4), uhci(4), xhci(4) devices. It also
works with em(4) and igb(4), but there some fixes are needed for
drivers, which are not committed yet. Intel GPUs do not work with
DMAR (yet).

Many thanks to John Baldwin, who explained me the newbus integration;
Peter Holm, who did all testing and helped me to discover and
understand several incredible bugs; and to Jim Harris for the access
to the EDS and BWG and for listening when I have to explain my
findings to somebody.

Sponsored by: The FreeBSD Foundation
MFC after: 1 month