Date: Wed, 15 Apr 2015 01:38:42 +0000 (UTC) From: Benjamin Kaduk <bjk@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r46551 - head/en_US.ISO8859-1/htdocs/news/status Message-ID: <201504150138.t3F1cg0U033459@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: bjk Date: Wed Apr 15 01:38:41 2015 New Revision: 46551 URL: https://svnweb.freebsd.org/changeset/doc/46551 Log: Add report on support for new x86 platform features DMAR, VT-d featuers, x2APIC, EOI suppression, and more. Approved by: hrs (mentor, implicit) Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2015-01-2015-03.xml Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2015-01-2015-03.xml ============================================================================== --- head/en_US.ISO8859-1/htdocs/news/status/report-2015-01-2015-03.xml Wed Apr 15 01:06:05 2015 (r46550) +++ head/en_US.ISO8859-1/htdocs/news/status/report-2015-01-2015-03.xml Wed Apr 15 01:38:41 2015 (r46551) @@ -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>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201504150138.t3F1cg0U033459>