From 922129cad49fe0c79a14e8808ae6216dff2e497a Mon Sep 17 00:00:00 2001 From: "David B. Kinder" Date: Thu, 18 Jun 2020 11:38:09 -0700 Subject: [PATCH] doc: consistent spelling of passthrough Attempt to replace all the variations of "pass-thru", "pass thru", "pass through", and "pass-through" to be "passthrough" (except for doc labels and in code or API uses) Signed-off-by: David B. Kinder --- doc/api/GVT-g_api.rst | 4 +- doc/developer-guides/hld/hld-APL_GVT-g.rst | 28 +++---- doc/developer-guides/hld/hld-devicemodel.rst | 4 +- doc/developer-guides/hld/hld-overview.rst | 16 ++-- .../hld/hld-power-management.rst | 2 +- doc/developer-guides/hld/hv-interrupt.rst | 14 ++-- doc/developer-guides/hld/hv-partitionmode.rst | 78 +++++++++---------- .../hld/hv-virt-interrupt.rst | 14 ++-- doc/developer-guides/modularity.rst | 2 +- doc/developer-guides/sw_design_guidelines.rst | 2 +- doc/glossary.rst | 4 +- doc/introduction/index.rst | 18 ++--- doc/tutorials/debug.rst | 2 +- .../rtvm_workload_design_guideline.rst | 4 +- doc/user-guides/acrn-shell.rst | 4 +- 15 files changed, 98 insertions(+), 98 deletions(-) diff --git a/doc/api/GVT-g_api.rst b/doc/api/GVT-g_api.rst index 76989e807..0c0118e69 100644 --- a/doc/api/GVT-g_api.rst +++ b/doc/api/GVT-g_api.rst @@ -83,8 +83,8 @@ responses to user space modules, notified by vIRQ injections. .. _MPT_interface: -AcrnGT mediated pass-through (MPT) interface -************************************************** +AcrnGT mediated passthrough (MPT) interface +******************************************* AcrnGT receives request from GVT module through MPT interface. Refer to the :ref:`Graphic_mediation` page. diff --git a/doc/developer-guides/hld/hld-APL_GVT-g.rst b/doc/developer-guides/hld/hld-APL_GVT-g.rst index 163ece7f0..76897e6a9 100644 --- a/doc/developer-guides/hld/hld-APL_GVT-g.rst +++ b/doc/developer-guides/hld/hld-APL_GVT-g.rst @@ -17,7 +17,7 @@ SoCs. This document describes: - The different GPU virtualization techniques -- GVT-g mediated pass-through +- GVT-g mediated passthrough - High level design - Key components - GVT-g new architecture differentiation @@ -47,7 +47,7 @@ Background Intel GVT-g is an enabling technology in emerging graphics virtualization scenarios. It adopts a full GPU virtualization approach -based on mediated pass-through technology, to achieve good performance, +based on mediated passthrough technology, to achieve good performance, scalability and secure isolation among Virtual Machines (VMs). A virtual GPU (vGPU), with full GPU features, is presented to each VM so that a native graphics driver can run directly inside a VM. @@ -161,10 +161,10 @@ also suffers from the following intrinsic limitations: exhibit quite different performance, which gives rise to a need for a fine-grained graphics tuning effort. -Direct Pass-Through +Direct Passthrough ------------------- -"Direct pass-through" dedicates the GPU to a single VM, providing full +"Direct passthrough" dedicates the GPU to a single VM, providing full features and good performance, but at the cost of device sharing capability among VMs. Only one VM at a time can use the hardware acceleration capability of the GPU, which is a major limitation of this @@ -177,7 +177,7 @@ solution. Intel GVT-d uses this mechanism. :align: center :name: gvt-pass-through - Pass-Through + Passthrough SR-IOV ------ @@ -188,16 +188,16 @@ with each VF directly assignable to a VM. .. _Graphic_mediation: -Mediated Pass-Through +Mediated Passthrough ********************* Intel GVT-g achieves full GPU virtualization using a "mediated -pass-through" technique. +passthrough" technique. Concept ======= -Mediated pass-through allows a VM to access performance-critical I/O +Mediated passthrough allows a VM to access performance-critical I/O resources (usually partitioned) directly, without intervention from the hypervisor in most cases. Privileged operations from this VM are trapped-and-emulated to provide secure isolation among VMs. @@ -207,7 +207,7 @@ trapped-and-emulated to provide secure isolation among VMs. :align: center :name: mediated-pass-through - Mediated Pass-Through + Mediated Passthrough The Hypervisor must ensure that no vulnerability is exposed when assigning performance-critical resource to each VM. When a @@ -229,7 +229,7 @@ Examples of performance-critical I/O resources include the following: Performance-Critical I/O Resources -The key to implementing mediated pass-through for a specific device is +The key to implementing mediated passthrough for a specific device is to define the right policy for various I/O resources. Virtualization Policies for GPU Resources @@ -317,7 +317,7 @@ High Level Architecture :numref:`gvt-arch` shows the overall architecture of GVT-g, based on the ACRN hypervisor, with Service VM as the privileged VM, and multiple user guests. A GVT-g device model working with the ACRN hypervisor, -implements the policies of trap and pass-through. Each guest runs the +implements the policies of trap and passthrough. Each guest runs the native graphics driver and can directly access performance-critical resources: the Frame Buffer and Command Buffer, with resource partitioning (as presented later). To protect privileged resources, that @@ -331,14 +331,14 @@ concurrently with the CPU scheduler in ACRN to share the physical GPU timeslot among the VMs. GVT-g uses the physical GPU to directly execute all the commands submitted from a VM, so it avoids the complexity of emulating the Render Engine, which is the most complex part of the GPU. -In the meantime, the resource pass-through of both the Frame Buffer and +In the meantime, the resource passthrough of both the Frame Buffer and Command Buffer minimizes the hypervisor's intervention of CPU accesses, while the GPU scheduler guarantees every VM a quantum time-slice for direct GPU execution. With that, GVT-g can achieve near-native performance for a VM workload. In :numref:`gvt-arch`, the yellow GVT device model works as a client on -top of an i915 driver in the Service VM. It has a generic Mediated Pass-Through +top of an i915 driver in the Service VM. It has a generic Mediated Passthrough (MPT) interface, compatible with all types of hypervisors. For ACRN, some extra development work is needed for such MPT interfaces. For example, we need some changes in ACRN-DM to make ACRN compatible with @@ -795,7 +795,7 @@ the shadow PTE entries. Per-VM Shadow PPGTT ------------------- -To support local graphics memory access pass-through, GVT-g implements +To support local graphics memory access passthrough, GVT-g implements per-VM shadow local page tables. The local graphics memory is only accessible from the Render Engine. The local page tables have two-level paging structures, as shown in :numref:`per-vm-shadow`. diff --git a/doc/developer-guides/hld/hld-devicemodel.rst b/doc/developer-guides/hld/hld-devicemodel.rst index 90cccfe55..2545d6f03 100644 --- a/doc/developer-guides/hld/hld-devicemodel.rst +++ b/doc/developer-guides/hld/hld-devicemodel.rst @@ -1189,8 +1189,8 @@ and waits for a resume signal. When the User VM should exit from S3, DM will get a wakeup signal and reset the User VM to emulate the User VM exit from S3. -Pass-through in Device Model +Passthrough in Device Model **************************** -You may refer to :ref:`hv-device-passthrough` for pass-through realization +You may refer to :ref:`hv-device-passthrough` for passthrough realization in device model. diff --git a/doc/developer-guides/hld/hld-overview.rst b/doc/developer-guides/hld/hld-overview.rst index 046aba4f4..20ef016b4 100644 --- a/doc/developer-guides/hld/hld-overview.rst +++ b/doc/developer-guides/hld/hld-overview.rst @@ -61,7 +61,7 @@ for its RT VM: - CAT (Cache Allocation Technology) - MBA (Memory Bandwidth Allocation) -- LAPIC pass-thru +- LAPIC passthrough - Polling mode driver - ART (always running timer) - other TCC features like split lock detection, Pseudo locking for cache @@ -109,7 +109,7 @@ separate instrument cluster VM is started after the User VM is booted. :numref:`overview-arch1.0` shows the architecture of ACRN 1.0 together with the IC VM and Service VM. As shown, the Service VM owns most of platform devices and provides I/O mediation to VMs. Some of the PCIe devices function as a -pass-through mode to User VMs according to VM configuration. In addition, +passthrough mode to User VMs according to VM configuration. In addition, the Service VM could run the IC applications and HV helper applications such as the Device Model, VM manager, etc. where the VM manager is responsible for VM start/stop/pause, virtual CPU pause/resume, etc. @@ -136,7 +136,7 @@ compared to ACRN 1.0 is that: interference between different VMs - ACRN 2.0 supports RT VM for a post-launched User VM, with assistant features like LAPIC - pass-thru and PMD virtio driver + passthrough and PMD virtio driver ACRN 2.0 is still WIP, and some of its features are already merged in the master. @@ -162,12 +162,12 @@ ACRN adopts various approaches for emulating devices for the User VM: - para-virtualized, requiring front-end drivers in the User VM to function. -- **Pass-through device**: A device passed through to the User VM is fully +- **Passthrough device**: A device passed through to the User VM is fully accessible to the User VM without interception. However, interrupts are first handled by the hypervisor before being injected to the User VM. -- **Mediated pass-through device**: A mediated pass-through device is a +- **Mediated passthrough device**: A mediated passthrough device is a hybrid of the previous two approaches. Performance-critical resources (mostly data-plane related) are passed-through to the User VMs and others (mostly control-plane related) are emulated. @@ -275,7 +275,7 @@ used by commercial OS). - On top of vCPUs are three components for device emulation: one for emulation inside the hypervisor, another for communicating with - the Service VM for mediation, and the third for managing pass-through + the Service VM for mediation, and the third for managing passthrough devices. - The highest layer is a VM management module providing @@ -311,7 +311,7 @@ based on command line configurations. Based on a VHM kernel module, DM interacts with VM manager to create the User VM. It then emulates devices through full virtualization on the DM user level, or para-virtualized based on kernel mediator (such as virtio, -GVT), or pass-through based on kernel VHM APIs. +GVT), or passthrough based on kernel VHM APIs. Refer to :ref:`hld-devicemodel` for more details. @@ -592,6 +592,6 @@ Some details about the ACPI table for the User and Service VMs: knows which register the User VM writes to trigger power state transitions. Device Model must register an I/O handler for it. -- The ACPI table in the Service VM is passthru. There is no ACPI parser +- The ACPI table in the Service VM is passthrough. There is no ACPI parser in ACRN HV. The power management related ACPI table is generated offline and hardcoded in ACRN HV. diff --git a/doc/developer-guides/hld/hld-power-management.rst b/doc/developer-guides/hld/hld-power-management.rst index f34529647..2f79f5db7 100644 --- a/doc/developer-guides/hld/hld-power-management.rst +++ b/doc/developer-guides/hld/hld-power-management.rst @@ -19,7 +19,7 @@ for the Device Model to build a virtual ACPI table. The Px/Cx data includes four ACPI objects: _PCT, _PPC, and _PSS for P-state management, and _CST for C-state management. All these ACPI data must be consistent with the -native data because the control method is a kind of pass through. +native data because the control method is a kind of passthrough. These ACPI objects data are parsed by an offline tool and hard-coded in a Hypervisor module named CPU state table: diff --git a/doc/developer-guides/hld/hv-interrupt.rst b/doc/developer-guides/hld/hv-interrupt.rst index feff1ed7f..c7507a84a 100644 --- a/doc/developer-guides/hld/hv-interrupt.rst +++ b/doc/developer-guides/hld/hv-interrupt.rst @@ -11,10 +11,10 @@ to manage interrupts and exceptions, as shown in :numref:`interrupt-modules-overview`. In its native layer, it configures the physical PIC, IOAPIC, and LAPIC to support different interrupt sources from the local timer/IPI to the external INTx/MSI. In its virtual guest -layer, it emulates virtual PIC, virtual IOAPIC, and virtual LAPIC/pass-thru +layer, it emulates virtual PIC, virtual IOAPIC, and virtual LAPIC/passthrough LAPIC. It provides full APIs, allowing virtual interrupt injection from -emulated or pass-thru devices. The contents in this section do not include -the pass-thru LAPIC case. For the pass-thru LAPIC, refer to +emulated or passthrough devices. The contents in this section do not include +the passthrough LAPIC case. For the passthrough LAPIC, refer to :ref:`lapic_passthru` .. figure:: images/interrupt-image3.png @@ -29,10 +29,10 @@ the ACRN hypervisor sets up the physical interrupt in its basic interrupt modules (e.g., IOAPIC/LAPIC/IDT). It dispatches the interrupt in the hypervisor interrupt flow control layer to the corresponding handlers; this could be pre-defined IPI notification, timer, or runtime -registered pass-thru devices. The ACRN hypervisor then uses its VM +registered passthrough devices. The ACRN hypervisor then uses its VM interfaces based on vPIC, vIOAPIC, and vMSI modules, to inject the necessary virtual interrupt into the specific VM, or directly deliver -interrupt to the specific RT VM with pass-thru LAPIC. +interrupt to the specific RT VM with passthrough LAPIC. .. figure:: images/interrupt-image2.png :align: center @@ -100,7 +100,7 @@ Physical Interrupt Initialization After ACRN hypervisor gets control from the bootloader, it initializes all physical interrupt-related modules for all the CPUs. ACRN hypervisor creates a framework to manage the physical interrupt for -hypervisor local devices, pass-thru devices, and IPI between CPUs, as +hypervisor local devices, passthrough devices, and IPI between CPUs, as shown in :numref:`hv-interrupt-init`: .. figure:: images/interrupt-image66.png @@ -323,7 +323,7 @@ there are three different handling flows according to flags: - ``IRQF_LEVEL && IRQF_PT`` - For pass-thru devices, to avoid continuous interrupt triggers, it masks + For passthrough devices, to avoid continuous interrupt triggers, it masks the IOAPIC pin and leaves it unmasked until corresponding vIOAPIC pin gets an explicit EOI ACK from guest. diff --git a/doc/developer-guides/hld/hv-partitionmode.rst b/doc/developer-guides/hld/hv-partitionmode.rst index d5e17c706..68adc4388 100644 --- a/doc/developer-guides/hld/hv-partitionmode.rst +++ b/doc/developer-guides/hld/hv-partitionmode.rst @@ -141,26 +141,26 @@ Port I/O is supported for PCI device config space 0xcfc and 0xcf8, vUART host-bridge at BDF (Bus Device Function) 0.0:0 to each guest. Access to 256 bytes of config space for virtual host bridge is emulated. -I/O - Pass-thru devices -======================= +I/O - Passthrough devices +========================= ACRN, in partition mode, supports passing thru PCI devices on the -platform. All the pass-thru devices are exposed as child devices under +platform. All the passthrough devices are exposed as child devices under the virtual host bridge. ACRN does not support either passing thru -bridges or emulating virtual bridges. Pass-thru devices should be +bridges or emulating virtual bridges. Passthrough devices should be statically allocated to each guest using the guest configuration. ACRN expects the developer to provide the virtual BDF to BDF of the -physical device mapping for all the pass-thru devices as part of each guest +physical device mapping for all the passthrough devices as part of each guest configuration. Runtime ACRN support for guests ******************************* -ACRN, in partition mode, supports an option to pass-thru LAPIC of the +ACRN, in partition mode, supports an option to passthrough LAPIC of the physical CPUs to the guest. ACRN expects developers to specify if the -guest needs LAPIC pass-thru using guest configuration. When guest +guest needs LAPIC passthrough using guest configuration. When guest configures vLAPIC as x2APIC, and if the guest configuration has LAPIC -pass-thru enabled, ACRN passes the LAPIC to the guest. Guest can access +passthrough enabled, ACRN passes the LAPIC to the guest. Guest can access the LAPIC hardware directly without hypervisor interception. During runtime of the guest, this option differentiates how ACRN supports inter-processor interrupt handling and device interrupt handling. This @@ -181,18 +181,18 @@ the Service VM startup in sharing mode. Inter-processor Interrupt (IPI) Handling ======================================== -Guests w/o LAPIC pass-thru --------------------------- +Guests w/o LAPIC passthrough +---------------------------- -For guests without LAPIC pass-thru, IPIs between guest CPUs are handled in +For guests without LAPIC passthrough, IPIs between guest CPUs are handled in the same way as sharing mode in ACRN. Refer to :ref:`virtual-interrupt-hld` for more details. -Guests w/ LAPIC pass-thru -------------------------- +Guests w/ LAPIC passthrough +--------------------------- -ACRN supports pass-thru if and only if the guest is using x2APIC mode -for the vLAPIC. In LAPIC pass-thru mode, writes to the Interrupt Command +ACRN supports passthrough if and only if the guest is using x2APIC mode +for the vLAPIC. In LAPIC passthrough mode, writes to the Interrupt Command Register (ICR) x2APIC MSR is intercepted. Guest writes the IPI info, including vector, and destination APIC IDs to the ICR. Upon an IPI request from the guest, ACRN does a sanity check on the destination processors @@ -204,8 +204,8 @@ corresponding to the destination processor info in the ICR. :align: center -Pass-thru device support -======================== +Passthrough device support +========================== Configuration space access -------------------------- @@ -217,7 +217,7 @@ Address registers (BAR), offsets starting from 0x10H to 0x24H, provide the information about the resources (I/O and MMIO) used by the PCI device. ACRN virtualizes the BAR registers and for the rest of the config space, forwards reads and writes to the physical config space of -pass-thru devices. Refer to the `I/O`_ section below for more details. +passthrough devices. Refer to the `I/O`_ section below for more details. .. figure:: images/partition-image1.png :align: center @@ -226,16 +226,16 @@ pass-thru devices. Refer to the `I/O`_ section below for more details. DMA --- -ACRN developers need to statically define the pass-thru devices for each +ACRN developers need to statically define the passthrough devices for each guest using the guest configuration. For devices to DMA to/from guest -memory directly, ACRN parses the list of pass-thru devices for each +memory directly, ACRN parses the list of passthrough devices for each guest and creates context entries in the VT-d remapping hardware. EPT page tables created for the guest are used for VT-d page tables. I/O --- -ACRN supports I/O for pass-thru devices with two restrictions. +ACRN supports I/O for passthrough devices with two restrictions. 1) Supports only MMIO. Thus, this requires developers to expose I/O BARs as not present in the guest configuration. @@ -244,7 +244,7 @@ ACRN supports I/O for pass-thru devices with two restrictions. As the guest PCI sub-system scans the PCI bus and assigns a Guest Physical Address (GPA) to the MMIO BAR, ACRN maps the GPA to the address in the -physical BAR of the pass-thru device using EPT. The following timeline chart +physical BAR of the passthrough device using EPT. The following timeline chart explains how PCI devices are assigned to guest and BARs are mapped upon guest initialization. @@ -255,14 +255,14 @@ guest initialization. Interrupt Configuration ----------------------- -ACRN supports both legacy (INTx) and MSI interrupts for pass-thru +ACRN supports both legacy (INTx) and MSI interrupts for passthrough devices. INTx support ~~~~~~~~~~~~ ACRN expects developers to identify the interrupt line info (0x3CH) from -the physical BAR of the pass-thru device and build an interrupt entry in +the physical BAR of the passthrough device and build an interrupt entry in the mptable for the corresponding guest. As guest configures the vIOAPIC for the interrupt RTE, ACRN writes the info from the guest RTE into the physical IOAPIC RTE. Upon the guest kernel request to mask the interrupt, @@ -275,8 +275,8 @@ MSI support ~~~~~~~~~~~ Guest reads/writes to PCI configuration space for configuring MSI -interrupts using an address. Data and control registers are pass-thru to -the physical BAR of the pass-thru device. Refer to `Configuration +interrupts using an address. Data and control registers are passthrough to +the physical BAR of the passthrough device. Refer to `Configuration space access`_ for details on how the PCI configuration space is emulated. Virtual device support @@ -291,8 +291,8 @@ writes are discarded. Interrupt delivery ================== -Guests w/o LAPIC pass-thru --------------------------- +Guests w/o LAPIC passthrough +---------------------------- In partition mode of ACRN, interrupts stay disabled after a vmexit. The processor does not take interrupts when it is executing in VMX root @@ -307,10 +307,10 @@ for device interrupts. :align: center -Guests w/ LAPIC pass-thru -------------------------- +Guests w/ LAPIC passthrough +--------------------------- -For guests with LAPIC pass-thru, ACRN does not configure vmexit upon +For guests with LAPIC passthrough, ACRN does not configure vmexit upon external interrupts. There is no vmexit upon device interrupts and they are handled by the guest IDT. @@ -320,15 +320,15 @@ Hypervisor IPI service ACRN needs IPIs for events such as flushing TLBs across CPUs, sending virtual device interrupts (e.g. vUART to vCPUs), and others. -Guests w/o LAPIC pass-thru --------------------------- +Guests w/o LAPIC passthrough +---------------------------- Hypervisor IPIs work the same way as in sharing mode. -Guests w/ LAPIC pass-thru -------------------------- +Guests w/ LAPIC passthrough +--------------------------- -Since external interrupts are pass-thru to the guest IDT, IPIs do not +Since external interrupts are passthrough to the guest IDT, IPIs do not trigger vmexit. ACRN uses NMI delivery mode and the NMI exiting is chosen for vCPUs. At the time of NMI interrupt on the target processor, if the processor is in non-root mode, vmexit happens on the processor @@ -344,8 +344,8 @@ For a guest console in partition mode, ACRN provides an option to pass ``vmid`` as an argument to ``vm_console``. vmid is the same as the one developers use in the guest configuration. -Guests w/o LAPIC pass-thru --------------------------- +Guests w/o LAPIC passthrough +---------------------------- Works the same way as sharing mode. @@ -354,7 +354,7 @@ Hypervisor Console ACRN uses the TSC deadline timer to provide a timer service. The hypervisor console uses a timer on CPU0 to poll characters on the serial device. To -support LAPIC pass-thru, the TSC deadline MSR is pass-thru and the local +support LAPIC passthrough, the TSC deadline MSR is passthrough and the local timer interrupt is also delivered to the guest IDT. Instead of the TSC deadline timer, ACRN uses the VMX preemption timer to poll the serial device. diff --git a/doc/developer-guides/hld/hv-virt-interrupt.rst b/doc/developer-guides/hld/hv-virt-interrupt.rst index 1f1a94e92..12084e06c 100644 --- a/doc/developer-guides/hld/hv-virt-interrupt.rst +++ b/doc/developer-guides/hld/hv-virt-interrupt.rst @@ -8,16 +8,16 @@ management, which includes: - VCPU request for virtual interrupt kick off, - vPIC/vIOAPIC/vLAPIC for virtual interrupt injection interfaces, -- physical-to-virtual interrupt mapping for a pass-thru device, and +- physical-to-virtual interrupt mapping for a passthrough device, and - the process of VMX interrupt/exception injection. A standard VM never owns any physical interrupts; all interrupts received by the Guest OS come from a virtual interrupt injected by vLAPIC, vIOAPIC, or -vPIC. Such virtual interrupts are triggered either from a pass-through +vPIC. Such virtual interrupts are triggered either from a passthrough device or from I/O mediators in the Service VM via hypercalls. The :ref:`interrupt-remapping` section discusses how the hypervisor manages -the mapping between physical and virtual interrupts for pass-through -devices. However, a hard RT VM with LAPIC pass-through does own the physical +the mapping between physical and virtual interrupts for passthrough +devices. However, a hard RT VM with LAPIC passthrough does own the physical maskable external interrupts. On its physical CPUs, interrupts are disabled in VMX root mode, while in VMX non-root mode, physical interrupts will be delivered to RT VM directly. @@ -64,7 +64,7 @@ will send an IPI to kick it out, which leads to an external-interrupt VM-Exit. In some cases, there is no need to send IPI when making a request, because the CPU making the request itself is the target VCPU. For example, the #GP exception request always happens on the current CPU when it -finds an invalid emulation has happened. An external interrupt for a pass-thru +finds an invalid emulation has happened. An external interrupt for a passthrough device always happens on the VCPUs of the VM which this device is belonged to, so after it triggers an external-interrupt VM-Exit, the current CPU is the very target VCPU. @@ -93,7 +93,7 @@ APIs are invoked when an interrupt source from vLAPIC needs to inject an interrupt, for example: - from LVT like LAPIC timer -- from vIOAPIC for a pass-thru device interrupt +- from vIOAPIC for a passthrough device interrupt - from an emulated device for a MSI These APIs will finish by making a vCPU request. @@ -134,7 +134,7 @@ LAPIC passthrough based on vLAPIC LAPIC passthrough is supported based on vLAPIC, the guest OS first boots with vLAPIC in xAPIC mode and then switches to x2APIC mode to enable the LAPIC -pass-through. +passthrough. In case of LAPIC passthrough based on vLAPIC, the system will have the following characteristics. diff --git a/doc/developer-guides/modularity.rst b/doc/developer-guides/modularity.rst index da330f565..ecf838897 100644 --- a/doc/developer-guides/modularity.rst +++ b/doc/developer-guides/modularity.rst @@ -92,7 +92,7 @@ The components are listed as follows. * **Device Emulation** This component implements devices that are emulated in the hypervisor itself, such as the virtual programmable interrupt controllers including vPIC, vLAPIC and vIOAPIC. -* **Passthru Management** This component manages devices that are passed-through +* **Passthrough Management** This component manages devices that are passed-through to specific VMs. * **Extended Device Emulation** This component implements an I/O request mechanism that allow the hypervisor to forward I/O accesses from a User diff --git a/doc/developer-guides/sw_design_guidelines.rst b/doc/developer-guides/sw_design_guidelines.rst index 2b22d9a71..bd3e1e13a 100644 --- a/doc/developer-guides/sw_design_guidelines.rst +++ b/doc/developer-guides/sw_design_guidelines.rst @@ -581,7 +581,7 @@ The following table shows some use cases of module level configuration design: * - Configuration data provided by BSP - This module is used to virtualize LAPIC, and the configuration data is provided by BSP. - For example, some VMs use LAPIC pass-through and the other VMs use + For example, some VMs use LAPIC passthrough and the other VMs use vLAPIC. - If a function pointer is used, the prerequisite is "hv_operation_mode == OPERATIONAL". diff --git a/doc/glossary.rst b/doc/glossary.rst index a202d645d..b2ba20151 100644 --- a/doc/glossary.rst +++ b/doc/glossary.rst @@ -122,9 +122,9 @@ Glossary of Terms OSPM Operating System Power Management - Pass-Through Device + Passthrough Device Physical devices (typically PCI) exclusively assigned to a guest. In - the Project ACRN architecture, pass-through devices are owned by the + the Project ACRN architecture, passthrough devices are owned by the foreground OS. Partition Mode diff --git a/doc/introduction/index.rst b/doc/introduction/index.rst index 037875b31..aeb5e2978 100644 --- a/doc/introduction/index.rst +++ b/doc/introduction/index.rst @@ -585,7 +585,7 @@ hypervisor, or in user space within an independent VM, overhead exists. This overhead is worthwhile as long as the devices need to be shared by multiple guest operating systems. If sharing is not necessary, then there are more efficient methods for accessing devices, for example -"pass-through". +"passthrough". ACRN device model is a placeholder of the User VM. It allocates memory for the User OS, configures and initializes the devices used by the User VM, @@ -635,10 +635,10 @@ ACRN Device model incorporates these three aspects: .. _pass-through: -Device pass through -******************* +Device passthrough +****************** -At the highest level, device pass-through is about providing isolation +At the highest level, device passthrough is about providing isolation of a device to a given guest operating system so that the device can be used exclusively by that guest. @@ -662,8 +662,8 @@ Finally, there may be specialized PCI devices that only one guest domain uses, so they should be passed through to the guest. Individual USB ports could be isolated to a given domain too, or a serial port (which is itself not shareable) could be isolated to a particular guest. In -ACRN hypervisor, we support USB controller Pass through only and we -don't support pass through for a legacy serial port, (for example +ACRN hypervisor, we support USB controller passthrough only and we +don't support passthrough for a legacy serial port, (for example 0x3f8). @@ -671,7 +671,7 @@ Hardware support for device passthrough ======================================= Intel's current processor architectures provides support for device -pass-through with VT-d. VT-d maps guest physical address to machine +passthrough with VT-d. VT-d maps guest physical address to machine physical address, so device can use guest physical address directly. When this mapping occurs, the hardware takes care of access (and protection), and the guest operating system can use the device as if it @@ -694,9 +694,9 @@ Hypervisor support for device passthrough By using the latest virtualization-enhanced processor architectures, hypervisors and virtualization solutions can support device -pass-through (using VT-d), including Xen, KVM, and ACRN hypervisor. +passthrough (using VT-d), including Xen, KVM, and ACRN hypervisor. In most cases, the guest operating system (User -OS) must be compiled to support pass-through, by using +OS) must be compiled to support passthrough, by using kernel build-time options. Hiding the devices from the host VM may also be required (as is done with Xen using pciback). Some restrictions apply in PCI, for example, PCI devices behind a PCIe-to-PCI bridge must be diff --git a/doc/tutorials/debug.rst b/doc/tutorials/debug.rst index 8da973035..d96b9a033 100644 --- a/doc/tutorials/debug.rst +++ b/doc/tutorials/debug.rst @@ -18,7 +18,7 @@ the ``help`` command within the ACRN shell. An example ********** -As an example, we'll show how to obtain the interrupts of a pass-through USB device. +As an example, we'll show how to obtain the interrupts of a passthrough USB device. First, we can get the USB controller BDF number (0:15.0) through the following command in the Service VM console:: diff --git a/doc/tutorials/rtvm_workload_design_guideline.rst b/doc/tutorials/rtvm_workload_design_guideline.rst index 425e5c374..4c721729b 100644 --- a/doc/tutorials/rtvm_workload_design_guideline.rst +++ b/doc/tutorials/rtvm_workload_design_guideline.rst @@ -16,10 +16,10 @@ Run RTVM with dedicated resources/devices For best practice, ACRN allocates dedicated CPU, memory resources, and cache resources (using Intel Resource Directory allocation Technology such as CAT, MBA) to RTVMs. For best real time performance -of I/O devices, we recommend using dedicated (pass-thru) PCIe devices to avoid VM-Exit at run time. +of I/O devices, we recommend using dedicated (passthrough) PCIe devices to avoid VM-Exit at run time. .. note:: - The configuration space for pass-thru PCI devices is still emulated and accessing it will + The configuration space for passthrough PCI devices is still emulated and accessing it will trigger a VM-Exit. RTVM with virtio PMD (Polling Mode Driver) for I/O sharing diff --git a/doc/user-guides/acrn-shell.rst b/doc/user-guides/acrn-shell.rst index 28c4cb94f..9cb3b2f61 100644 --- a/doc/user-guides/acrn-shell.rst +++ b/doc/user-guides/acrn-shell.rst @@ -33,7 +33,7 @@ The ACRN hypervisor shell supports the following commands: * - int - List interrupt information per CPU * - pt - - Show pass-through device information + - Show passthrough device information * - vioapic - Show virtual IOAPIC (vIOAPIC) information for a specific VM * - dump_ioapic @@ -184,7 +184,7 @@ IRQ vector number, etc. pt == -``pt`` provides pass-through detailed information, such as the virtual +``pt`` provides passthrough detailed information, such as the virtual machine number, interrupt type, interrupt request, interrupt vector, trigger mode, etc.