From owner-svn-doc-all@FreeBSD.ORG Wed Apr 15 01:38:42 2015 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4B11D88A; Wed, 15 Apr 2015 01:38:42 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2CECB102; Wed, 15 Apr 2015 01:38:42 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.9/8.14.9) with ESMTP id t3F1cg2H033460; Wed, 15 Apr 2015 01:38:42 GMT (envelope-from bjk@FreeBSD.org) Received: (from bjk@localhost) by svn.freebsd.org (8.14.9/8.14.9/Submit) id t3F1cg0U033459; Wed, 15 Apr 2015 01:38:42 GMT (envelope-from bjk@FreeBSD.org) Message-Id: <201504150138.t3F1cg0U033459@svn.freebsd.org> X-Authentication-Warning: svn.freebsd.org: bjk set sender to bjk@FreeBSD.org using -f From: Benjamin Kaduk Date: Wed, 15 Apr 2015 01:38:42 +0000 (UTC) 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 X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 01:38:42 -0000 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 + + + Modern x86 platform support and VT-d + + + + + Konstantin + Belousov + + kib@FreeBSD.org + + + + +

Modern x86 platforms include a number of architectural + enhancements. Work is ongoing to support these features in + &os;.

+ +

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.

+ +

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.

+ +

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.

+ +

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..

+ +

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.

+ +

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.

+ +

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.

+ + + The &os; Foundation +