Add report on support for new x86 platform features

DMAR, VT-d featuers, x2APIC, EOI suppression, and more.

Approved by:	hrs (mentor, implicit)
This commit is contained in:
Benjamin Kaduk 2015-04-15 01:38:41 +00:00
parent 80c088579c
commit ee9622fa4c
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=46551

View file

@ -1713,4 +1713,93 @@ WITHOUT_FORTH=y</pre>
</task>
</help>
</project>
<project cat='kern'>
<title>Modern x86 platform support and VT-d</title>
<contact>
<person>
<name>
<given>Konstantin</given>
<common>Belousov</common>
</name>
<email>kib@FreeBSD.org</email>
</person>
</contact>
<body>
<p>Modern x86 platforms include a number of architectural
enhancements. Work is ongoing to support these features in
&os;.</p>
<p>Starting with SandyBridge CPUs, Intel introduced an
enchanced local interrupt controller (APIC) mode, called x2APIC.
Instead of using a mapped page, registers are now accessed using
special Model-Specific Registers (MSR) read and write
instructions. This is intended to support virtualization. The
access overhead is also reduced by not requiring serialization,
and by simplification of Inter-Process Interrups (IPI)
generation. The main commit introducing the feature was
r278473, with fixes following on.</p>
<p>End Of Interrupt (EOI) suppression is a mode of EOI
delivery to Input/Output Interrupt Controllers (IO-APICs) where
the EOI message for a level-triggered interrupt is not broadcast
by an EOI write to the local APIC, but instead an explicit EOI
command is sent to the source IO-APIC. The optimization reduces
the number of APIC messages that must be broadcast. It should
be used on all modern Intel systems. Support for EOI
suppression was committed in r279319.</p>
<p>VT-d Interrupt Remapping (IR) is provided by hardware
with the VT-d feature. It translates interrupt messages on the
way from the root complex to the north bridge and allows control
of interrupt delivery without reprogramming MSI/MSI-X registers
or IO-APICs. The original intent was to allow hypervisors to
safely delegate interrupt programming for devices owned by
guests to the guest OS. But IR is also needed to avoid some
limitations in IO-APICs and to make interrupt rebalancing atomic
and transparent. Support has been committed as r280260.</p>
<p>Both x2APIC mode and IR are required to send IPIs and
device interrupts to processors with LAPIC ID greater then 254.
It is believed that the only missing platform code to handle big
machines is parsing the "Processor Local x2APIC Structure" and
"Local x2APIC NMI Structure" from the ACPI Multiple APIC
Description Table (MADT), which report LAPIC IDs > 255, and
handling boot on such systems with the x2APIC mode enabled by
firmware. The work to complete that is expected to be
relatively trivial, and can be done with access to a real
high-core-count machine. But an audit of the common
machine-independent code must be finished to ensure that large
CPU IDs are handled correctly, before such support can
safely be enabled..</p>
<p>Additional work remains in progress: split domains and
contexts for DMA Remapper Unit (DMAR) driver. Right now, the
DMAR driver is only used to implement busdma(9), which is done
by assigning a dedicated domain to each translation context.
Some devices could issue PCIe Transaction Laeyer Packets (TLPs)
with several originators IDs, e.g., PCIe/PCI bridges, or
phantom functions of PCIe devices, or such TLPs could occur just
due to hardware bugs. To handle them, a single domain (which
shares the translation page tables) must handle several
contexts.</p>
<p>Splitting domains and contexts is also required for the
DMAR driver to start handling PCI pass-through in bhyve, instead
of the less complete implementation which is currently provided
by bhyve itself. All PCIe devices passed to the guest must
share a domain. The splitting patch is written and is being
tested, and external interfaces to manage domains are being
formed.</p>
<p>Stability work for the VT-d code is ongoing. In
particular, nvme(4) and ixgbe(4)'s use of busdma interfaces was
debugged and improved, and tested on a very large-memory
machine.</p>
</body>
<sponsor>The &os; Foundation</sponsor>
</project>
</report>