Volume 2 System Programming (794096), страница 102
Текст из файла (страница 102)
In contrast, when nested paging is disabled, the VMM's paging controlregisters are stored in the host state save area and the paging control registers from the guest VMCBare the only active versions of those registers.Secure Virtual Machine405AMD64 Technology24593—Rev.
3.13—July 200715.24.3 Enabling Nested PagingThe VMRUN instruction enables nested paging when the NP_ENABLE bit in the VMCB is set to 1.The VMCB contains the hCR3 value for the page tables for the extra translation. The extra translationuses the same paging mode as the VMM used when it executed the most recent VMRUN.Nested paging is automatically disabled by #VMEXIT.Nested paging is allowed only if the host has paging enabled. CPUID function 8000_000A.EDX[0]indicates that nested paging is available. If VMRUN is executed with hCR0.PG cleared to zero andNP_ENABLE set to 1, VMRUN terminates with #VMEXIT(VMEXIT_INVALID).15.24.4 Nested Paging and VMRUN/#VMEXITWhen VMRUN is executed with nested paging enabled (NP_ENABLE = 1), the paging registers areaffected as follows:•••VMRUN saves the VMM’s CR3 in the host save area.VMRUN loads the guest paging state from the guest VMCB into the guest registers (i.e., VMRUNloads CR3 with the VMCB CR3 field, etc.).
The guest PAT register is loaded from G_PAT field inthe VMCB.VMRUN loads nCR3, the version of CR3 to be used while the nested-paging guest is running,from the N_CR3 field in the VMCB. The other host paging-control bits (hCR4.PAE, etc.) remainthe same as they were in the VMM at the time VMRUN was executed.When VMRUN is executed with nested paging enabled (NP_ENABLE = 1), the following conditionsare considered illegal state combinations, in addition to those mentioned in “Canonicalization andConsistency Checks” on page 371:••Any MBZ bit of nCR3 is set.Any G_PAT.PA field has an unsupported type encoding or any reserved field in G_PAT has a nonzero value. (See Section 7.8.1, “PAT Register,” on page 191.)When #VMEXIT occurs with nested paging enabled:••#VMEXIT writes the guest paging state (gCR3, gCR0, etc.) back into the VMCB.
nCR3 is notsaved back into the VMCB.#VMEXIT need not reload any host paging state other than CR3 from the host save area, though animplementation is free to do so.15.24.5 Nested Table WalkWhen the guest is running with nested paging enabled, a TLB miss causes several nested table walks:•Guest Page Tables—the gCR3 register specifies a guest physical address, as do the entries in theguest's page tables. These guest physical addresses must be translated to system physical addressesusing the nested page tables. Nested page table level faults can occur on these accesses, includingwrite faults due to setting of accessed and dirty bits in the nested page table.406Secure Virtual Machine24593—Rev.
3.13—July 2007•AMD64 TechnologyFinal Guest-Physical Page—once a guest linear to guest physical mapping is known, guestpermissions can be checked. If the guest page tables allow the access, the guest physical address iswalked in the nested page tables to find the system physical address.Table walks for guest page tables are always treated as user writes at the nested page table level.
Forthis reason,••the page must be writable by user at the nested page table level, or else a #VMEXIT(NPF) israised, andthe dirty and accessed bits are always set in the nested page table entries that were touched duringnested page table walks for guest page table entries.A table walk for the guest page itself is always treated as a user access at the nested page table level,but is treated as a data read, data write, or code read, depending on the guest access.If the guest has paging disabled (gCR0.PG = 0), there are no guest page table entries to be translated inthe nested page tables. In this case, the final guest-physical address is equal to the guest-linear address,and is still translated in the nested page tables.15.24.6 Nested versus Guest Page Faults, Fault OrderingIn nested paging, page faults can be raised at either the guest or nested page table level.
Nested walksproceed in the following order; faults are generated in the same order:1. Walk the guest page table entries in the nested page table. Dirty/Accessed bits are set as needed inthe nested page table. Any nested page table faults result in #VMEXIT(NPF).2. As the guest page table walk proceeds from the top of the page table to the last entry, any notpresent entries or reserved bits in the guest page table entries at each level of the guest walk cause#PF in the guest. Guest dirty and accessed bits are set as needed in the guest page tables during thewalk. Steps 1 and 2 are repeated for each level of the guest page table that is traversed.3.
Once the guest physical address for the guest access has been determined, check the guestpermissions; any fault at this point causes a #PF in the guest.4. Perform the final translation from guest physical to system physical using the nested page table;any fault during this translation results in a #VMEXIT(NPF).Nested page faults are entirely a function of the nested page table and VMM processor mode. Nestedfaults cause a #VMEXIT(NPF) to the VMM. The faulting guest physical address is saved in theVMCB's EXITINFO2 field; EXITINFO1 delivers an error code similar to a #PF error code:••••Bit 0 (P)—cleared to 0 if the nested page was not present, 1 otherwiseBit 1 (RW)—set to 1 if the nested page table level access was a write.
Note that host table walks forguest page tables are always treated as data writes.Bit 2 (US)—always 1, since all guest accesses are treated as user accesses at the nested levelBit 3 (RSV)—set to 1 if reserved bits were set in the corresponding nested page table entrySecure Virtual Machine407AMD64 Technology•24593—Rev. 3.13—July 2007Bit 4 (ID)—set to 1 if the nested page table level access was a code read.
Note that nested tablewalks for guest page tables are always treated as data writes, even if the access itself is a code readGuest faults are entirely a function of the guest page tables and processor mode; they are delivered tothe guest as normal #PF exceptions without any VMM intervention, unless the VMM is interceptingguest #PF exceptions.15.24.7 Combining Nested and Guest AttributesAny access to guest physical memory is subjected to a permission check by examining the mapping ofthe guest physical address in the nested page table.A page is considered writable by the guest only if it is marked writable at both the guest and nestedpage table levels.
Note that the guest’s gCR0.WP affects only the interpretation of the guest page tableentry; setting gCR0.WP cannot make a page writable at any CPL in the guest, if the page is markedread-only in the nested page table. The host hCR0.WP bit is ignored under nested paging.A page is considered executable by the guest only if it is marked executable at both the guest andnested page table levels. If the EFER.NXE bit is cleared for the guest, all guest pages are executable atthe guest level.
Similarly, if the EFER.NXE bit is cleared for the host, all nested page table mappingsare executable at the underlying nested level.Some attributes are taken from the guest page tables and operating modes only. A page is consideredglobal within the guest only if is marked global in the guest page tables; the nested page table entry andhost hCR4.PGE are irrelevant. Global pages are only global within their ASID.A page is considered user in the guest only if it is marked as user at the guest level. The page must bemarked user in the nested page table to allow any guest access at all.15.24.8 Combining Memory Types, MTRRsThe processor combines guest and nested page table memory types; registers that affect memory typesinclude:••••••The PCD/PWT/PATi bits in the nested and guest page table entries.The PCD/PWT bits in the nested CR3 and guest CR3 registers.The guest PAT type (obtained by appropriately indexing the gPAT register).The host PAT type (obtained by appropriately indexing the host’s PAT register).The MTRRs (which are referenced based only on system physical address).gCR0.CD and hCR0.CD.Note that there is no hardware support for guest MTRRs; the VMM can simulate their effect byaltering the memory types in the nested page tables.
Note that the MTRRs are only applied to systemphysical addresses.The rules for combining memory types when constructing a guest TLB entry are:408Secure Virtual Machine24593—Rev. 3.13—July 2007•••AMD64 TechnologyNested and guest PAT types are combined according to Table 15-13 on page 409, producing a“combined PAT type”the combined PAT type is further combined with the MTRR type according to Table 15-14 onpage 410, where the relevant MTRRs are determined by the system physical address.either gCR0.CD or hCR0.CD can disable cachingMemory Consistency Issues.
Because the guest uses extra fields to determine the memory type, theVMM may use a different memory type to access a given piece of memory than does the guest. If oneaccess is cacheable and the other is not, the VMM and guest could observe different memory images,which is undesirable. (MP systems are particularly sensitive to this problem when the VMM desires tomigrate a virtual processor from one physical processor to another.)To address this issue, the following mechanisms are provided:•••VMRUN and #VMEXIT flush the write combiners.
This ensures that all writes to WC memory bythe guest are visible to the host (or vice-versa) regardless of memory type. (It does not ensure thatcacheable writes by one agent are properly observed by WC reads or writes by the other agent.)A new memory type WC+ is introduced. WC+ is an uncacheable memory type, and combineswrites in write-combining buffers like WC. Unlike WC (but like the CD memory type), accesses toWC+ memory also snoop the caches on all processors (including self-snooping the caches of theprocessor issuing the request) to maintain coherency.
This ensures that cacheable writes areobserved by WC+ accesses.When combining nested and guest memory types that are incompatible with respect to caching, theWC+ memory type is used instead of WC (and Table 15-14 on page 410 ensures that the snoopingbehavior is retained regardless of the host MTRR settings). Refer to Table 15-13 on page 409 ordetails.Table 15-13 on page 409 shows how guest and host PAT types are combined into an effective PATtype. When interpreting this table, recall that the intent is for the VMM to use its PAT type to simulateguest MTRRs.Table 15-13. Combining Guest and Host PAT TypesGuest PAT TypeHost PAT TypeUCUC–WCWPWTWBUCUCUCUCUCUCUCUC–UCUCWCUCUCUCWCWCWCWCWC+WC+WC+WPUCUCUCWPUCWPWTUCUCUCUCWTWTWBUCUCWCWPWTWBSecure Virtual Machine409AMD64 Technology24593—Rev.
3.13—July 2007The existing AMD64 table that defines how PAT types are combined with the physical MTRRs isextended to handle CD and WC+ PAT types as shown in Table 15-14.Table 15-14. Combining PAT and MTRR TypesEffective PAT TypeMTRR TypeUCWCWPWTWBUCUCCDCDCDCDUC–UCWCCDCDCDWCWCWCWCWCWCWC+WCWCWC+WC+WC+WPUCCDWPCDWPWTUCCDCDWTWTWBUCWCWPWTWB15.24.9 Page SplinteringWhen an address is mapped by guest and nested page table entries with different page sizes, the TLBentry that is created matches the size of the smaller page.15.24.10 Legacy PAE ModeThe behavior of PAE mode in a nested-paging guest differs slightly from the behavior of (host-only)legacy PAE mode, in that the guest’s four PDPEs are not loaded into the processor at the time CR3 iswritten. Instead, the PDPEs are accessed on demand as part of a table walk. This has the side-effectthat illegal bit combinations in the PDPEs are not signaled at the time that CR3 is written, but insteadwhen the faulty PDPE is accessed as part of a table walk.This means that an operating system cannot rely on the behavior when the in-memory PDPEs aredifferent than the in-processor copy.15.24.11 A20 MaskingThere is no provision for applying A20 masking to guest physical addresses; the VMM can emulateA20 masking by changing the nested page mappings accordingly.15.24.12 Detecting Nested Paging SupportNested Paging is an optional feature of SVM and is not available in all implementations of SVMcapable processors.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
