Volume 3B System Programming Guide_ Part 2 (794104), страница 70
Текст из файла (страница 70)
The VMM needs to comprehend these virtual local APIC mask settings as programmed by the guest in additionto the guest virtual processor interruptibility state (when injecting APIC routedexternal virtual interrupts to a guest VM).VMX provides several features which help the VMM to virtualize the local APIC. Thesefeatures allow many of guest TPR accesses (using CR8 only) to occur without VMexits to the VMM:•The VMCS contains a 'Virtual-APIC page address' field. This 64-bit field is thephysical address of the 4-KByte virtual APIC page (4-KByte aligned).
The virtualAPIC page contains a TPR shadow, which is accessed by the MOV CR8 instruction.The TPR shadow comprises bits 7:4 in byte 80H of the virtual-APIC page.•The TPR threshold: bits 3:0 of this 32-bit field determine the threshold belowwhich the TPR shadow cannot fall. A VM exit will occur after an execution of MOVCR8 that reduces the TPR shadow below this value.•The processor-based VM-execution controls field contains a 'Use TPR shadow' bitand a 'CR8-store exiting' bit. If 'Use TPR shadow' is set and 'CR8-store exiting' iscleared, then a MOV from CR8 reads from the TPR shadow. If the 'CR8-storeexiting' VM-execution control is set, then MOV from CR8 causes a VM exit. 'UseTPR shadow' is ignored in this case.•The processor-based VM-execution controls field contains a 'CR8-load exiting'bit. If 'Use TPR shadow' is set and 'CR8-load exiting' is clear, then MOV to CR8writes to the 'TPR shadow'.
A VM exit will occur after this write if the value writtenis below the TPR threshold. If 'CR8-load exiting' is set, then MOV to CR8 causes aVM exit. 'Use TPR shadow' is ignored in this case.27.3.2.4I/O APIC VirtualizationThe I/O APIC registers are typically mapped to a 1 MByte region where each I/O APICis allocated a 4K address window within this range. The VMM may utilize physicalmemory virtualization to trap guest accesses to the virtual I/O APIC memorymapped registers. The I/O APIC virtualization needs to emulate the various I/O APICoperations and registers such as identification/version registers, indirect-I/O-accessregisters, EOI register, and the I/O redirection table.
I/O APIC virtualization alsoVol. 3 27-7HANDLING BOUNDARY CONDITIONS IN A VIRTUAL MACHINE MONITORneed to emulate various redirection table entry settings such as delivery mode,destination mode, delivery status, polarity, masking, and trigger mode programmedby the guest and track remote-IRR state on guest EOI writes to various virtual localAPICs.27.3.2.5Virtualization of Message Signaled InterruptsThe PCI Local Bus Specification (Rev. 2.2) introduces the concept of messagesignaled interrupts (MSI).
MSI enable PCI devices to request service by writing asystem-specified message to a system specified address. The transaction addressspecifies the message destination while the transaction data specifies the interruptvector, trigger mode and delivery mode. System software is expected to configurethe message data and address during MSI device configuration, allocating one ormore no-shared messages to MSI capable devices. Chapter 8, “Advanced Programmable Interrupt Controller (APIC),” specifies the MSI message address and dataregister formats to be followed on Intel 64 and IA-32 platforms.
While MSI is optionalfor conventional PCI devices, it is the preferred interrupt mechanism for PCI-Expressdevices.Since the MSI address and data are configured through PCI configuration space, tocontrol these physical interrupts the VMM needs to assume ownership of PCI configuration space. This allows the VMM to capture the guest configuration of messageaddress and data for MSI-capable virtual and assigned guest devices. PCI configuration transactions on PC-compatible systems are generated by software through twodifferent methods:1. The standard CONFIG_ADDRESS/CONFIG_DATA register mechanism(CFCH/CF8H ports) as defined in the PCI Local Bus Specification.2.
The enhanced flat memory-mapped (MEMCFG) configuration mechanism asdefined in the PCI-Express Base Specification (Rev. 1.0a.).The CFCH/CF8H configuration access from guests can be trapped by the VMMthrough use of I/O-bitmap VM-execution controls. The memory-mapped PCI-ExpressMEMCFG guest configuration accesses can be trapped by VMM through physicalmemory virtualization.27.3.3Examples of Handling of External InterruptsThe following sections illustrate interrupt processing in a VMM (when used to supportthe external interrupt virtualization requirements).27.3.3.1Guest SetupThe VMM sets up the guest to cause a VM exit to the VMM on external interrupts.
Thisis done by setting the “external-interrupt exiting” VM-execution control in the guestcontrolling-VMCS.27-8 Vol. 3HANDLING BOUNDARY CONDITIONS IN A VIRTUAL MACHINE MONITOR27.3.3.2Processor Treatment of External InterruptInterrupts are automatically masked by hardware in the processor on VM exit byclearing RFLAGS.IF. The exit-reason field in VMCS is set to 1 to indicate an externalinterrupt as the exit reason.If the VMM is utilizing the acknowledge-on-exit feature (by setting the acknowledgeinterrupt-on-exit bit in guest VM-exit control field), the processor acknowledges theinterrupt, retrieves the host vector, and saves the interrupt in the exit-interruptioninformation field (in the VM-exit information region of the VMCS) before transitioningcontrol to the VMM.27.3.3.3Processing of External Interrupts by VMMUpon VM exit, the VMM can determine the exit cause of an external interrupt bychecking the exit-reason field (value = 1) in VMCS.
If the acknowledge-interrupt-onexit control (see Section 20.7.1) is enabled, the VMM can use the saved host vector(in the exit-interruption-information field) to switch to the appropriate interrupthandler. If acknowledge-interrupt-on-exit is not enabled, the VMM may re-enableinterrupts (by setting RFLAGS.IF) to allow vectoring of external interrupts throughthe monitor/host IDT.The following steps may need to be performed by the VMM to process an externalinterrupt:•Host Owned I/O Devices: For host-owned I/O devices, the interrupting deviceis owned by the VMM (or hosting OS in a hosted VMM). In this model, theinterrupt service routine in the VMM/host driver is invoked and, upon ISRcompletion, the appropriate write sequences (TPR updates, EOI etc.) torespective interrupt controllers are performed as normal.
If the work completionindicated by the driver implies virtual device activity, the VMM runs the virtualdevice emulation. Depending on the device class, physical device activity couldimply activity by multiple virtual devices mapped over the device. For eachaffected virtual device, the VMM injects a virtual external interrupt event torespective guest virtual machines. The guest driver interacts with the emulatedvirtual device to process the virtual interrupt. The interrupt controller emulationin the VMM supports various guest accesses to the VMM’s virtual interruptcontroller.•Guest Assigned I/O Devices: For assigned I/O devices, either the VMM uses asoftware proxy or it can directly map the physical device to the assigned VM.
Inboth cases, servicing of the interrupt condition on the physical device is initiatedby the driver running inside the guest VM. With host control of externalinterrupts, interrupts from assigned physical devices cause VM exits to the VMMand vectoring through the host IDT to the registered VMM interrupt handler. Tounblock delivery of other low priority platform interrupts, the VMM interrupthandler must mask the interrupt source (for level triggered interrupts) and issuethe appropriate EOI write sequences.Vol. 3 27-9HANDLING BOUNDARY CONDITIONS IN A VIRTUAL MACHINE MONITOROnce the physical interrupt source is masked and the platform EOI generated, theVMM can map the host vector to its corresponding guest vector to inject the virtualinterrupt into the assigned VM. The guest software does EOI write sequences to itsvirtual interrupt controller after completing interrupt processing.
For level triggeredinterrupts, these EOI writes to the virtual interrupt controller may be trapped by theVMM which may in turn unmask the previously masked interrupt source.27.3.3.4Generation of Virtual Interrupt Events by VMMThe following provides some of the general steps that need to be taken by VMMdesigns when generating virtual interrupts:1. Check virtual processor interruptibility state. The virtual processor interruptibilitystate is reflected in the guest RFLAGS.IF flag and the processor interruptibilitystate saved in the guest state area of the controlling-VMCS. If RFLAGS.IF is setand the interruptibility state indicates readiness to take external interrupts (STImasking and MOV-SS/POP-SS-masking bits are clear), the guest virtualprocessor is ready to take external interrupts.
If the VMM design supports nonactive guest sleep states, the VMM needs to make sure the current guest sleepstate allows injection of external interrupt events.2. If the guest virtual processor state is currently not interruptible, a VMM mayutilize the “interrupt-window exiting” VM-execution to notify the VM (through aVM exit) when the virtual processor state changes to interruptible state.3.
Check the virtual interrupt controller state. If the guest VM exposes a virtual localAPIC, the current value of its processor priority register specifies if guestsoftware allows dispensing an external virtual interrupt with a specific priority tothe virtual processor. If the virtual interrupt is routed through the local vectortable (LVT) entry of the local APIC, the mask bits in the corresponding LVT entryspecifies if the interrupt is currently masked. Similarly, the virtual interruptcontroller’s current mask (IO-APIC or PIC) and priority settings reflect gueststate to accept specific external interrupts. The VMM needs to check both thevirtual processor and interrupt controller states to verify its guest interruptibilitystate. If the guest is currently interruptible, the VMM can inject the virtualinterrupt.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
