point of confusion w.r.t. Virtual APIC page

point of confusion w.r.t. Virtual APIC page

I think I understand the sections in 3b 22.2 to mean that the virtualise APIC access exit control allows the vmm to trap accesses to the physical page of the actual CPU APIC, but is not on its own useful for implementing a virtual APIC for a virtual guest CPU since the second footnote in 22.2.1.1 seems to indicate that the APIC page is checked after EPT translations have occurred.

What is the role of the virtual APIC page? It is ONLY used to shadow the TPR?

Sorry, just getting a bit lost in the choose your own adventure style documentation on this point.

3 Beiträge / 0 neu
Letzter Beitrag
Nähere Informationen zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.

I think I mis-understood the virtualize APIC controls somewhat. The APIC address they cause exits from can be controlled by the VMCS_APIC_ADDRESS_FULL value. I guess I was under the impression that the value was the one in the IA32_APIC_BASE MSR.

I think however I'm still a bit confused as to the role of the virtual APIC page.

Here is a reply I received from a colleague:

It is correct that the only function of the virtual-APIC page is to shadow the TPR.

There are three address of interest, all of which are physical addresses (meaning that they are not subject to any kind of translation).

1. IA32_APIC_BASE. This address is contained in an MSR. This is the address at which that actual hardware APIC is mapped. Accesses to this physical address (e.g., if this physical address is the output of paging) will access the memory-mapped registers of the actual hardware APIC. It is expected that a VMM will not map this physical address into the address space of any guest. That means the following: (1) if EPT is in use, no EPT PTE should contain this address; (2) if EPT is not in use, no ordinary PTE should have this address while a guest is running. (See #2 below for an exception.) It is also expected that the VMM will not allow any guest software to access the IA32_APIC_BASE MSR.

2. APIC-access address. This is the address of the APIC-access page and is programmed via a field in the VMCS. The CPU will treat specially guest accesses to physical addresses on this page. For most cases, such accesses cause VM exits. The only exceptions are reads and writes of offset 080H (TPR) on the page. See item #3 for how they are treated. The relevant accesses are defined as follows: (1) if EPT is in use, accesses that use an EPT PTE that contains the APIC-address; (2) if EPT is not in use, accesses that use an ordinary PTE that contains the APIC-access address. NOTE: the APIC-access address take priority over the address in IA32_APIC_BASE. If both have the same value and are programmed into a PTE, accesses through that PTE are virtualized (cause VM exits in most cases) and do not access the actual hardware APIC. This is an exception to statements in #1 (that the address in IA32_APIC_BASE not appear in PTEs while a guest is running).

3. Virtual-APIC address. This is the address of the virtual-APIC page and is programmed via a field in the VMCS. The CPU uses this field in three situations: (1) MOV to/from CR8; (2) RDMSR/WRMSR to MSR 808H; and (3) for accesses to offset 080H (TPR) on the APIC-access page. If the CPU detects an access to offset 080H on the APIC-access page (see above), it will redirect the access to offset 080H on the virtual-APIC page. It is expected that a VMM will not map this physical address into the address space of any guest, except guests for which the virtual-APIC address is identical to the APIC-access address.

The APIC-access address and the virtual-APIC address were made distinct from each other to support guests with multiple virtual processors. In such a situation, the virtual processors could all be supported with a single hierarchy of EPT paging structures. This hierarchy would include an EPT PTE with an address that is the APIC-access address for all the virtual processors. That is, the VMCS of each virtual processor would include this address as its APIC-access address. But these VMCS's would each have its own virtual-APIC address.

In this way, the virtual processors of a single guest can be supported by a single hierarchy of EPT paging structures while each having its own virtual APIC.

David Ott

Kommentar hinterlassen

Bitte anmelden, um einen Kommentar hinzuzufügen. Sie sind noch nicht Mitglied? Jetzt teilnehmen