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:
parent
80c088579c
commit
ee9622fa4c
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=46551
1 changed files with 89 additions and 0 deletions
|
@ -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>
|
||||
|
|
Loading…
Reference in a new issue