Volume 2 System Programming (794096), страница 101
Текст из файла (страница 101)
As the DEV_OP and DEV_DATA registers are accessed through PCI config space (ports0CF8h–0CFFh), they may be secured from unauthorized access by software executing on theprocessor by appropriate settings in the SVM I/O protection bitmap. These registers are also protectedby the host bridge from external access as described in “Config Space Accesses” on page 398.15.23.6 DEV Control and Status RegistersThe DEV control and status registers are accessible by means of the indirection mechanism; theseregisters are not directly visible in PCI config space.DEV_CAP Register.
Read-only register; holds implementation specific information: the number ofprotection domains supported, the number of DEV_MAP registers (which map device/unit IDs todomain numbers), and the revision ID.3124Reserved, RAZ231615N_MAPS87N_DOMAINS0REVISIONFigure 15-7. Format of DEV_CAP Register (in PCI Config Space)The initial implementation provide four domains and three map registers.DEV_CR Register. This is the main control register for the DEV mechanism; it is cleared to zero byRESET.Table 15-12. DEV_CR Control RegisterBit(s)31-7DefinitionReserved, MBZ6DEV table walk probe disable.0 = Use probe on DEV walk; 1 = Do not use probe5SL_DEV_EN. Enable bit for limited memory protection, see Section 15.23.8 onpage 403.
Set to “1” by SKINIT instruction, can be cleared by software.4Invalidate DEV cache. Software must set this bit to 1 to invalidate the DEV cache;cleared by hardware when invalidation is complete.3Enable MCE reporting.0 = Do not generate MCE; 1 = Generate MCE on errors.2I/O space protection enable (IOSPEN)0 = Allow upstream I/O cycles; 1 = Block.1Memory clear disable.
If non-zero, memory-clearing on reset is disabled.This bit is not writable until the memory is enabled.0DEV global enable bit. If zero, DEV protection is turned off.Secure Virtual Machine401AMD64 Technology24593—Rev. 3.13—July 2007DEV_BASE Address/Limit Registers. The DEV base address registers (one set per domain) eachpoint to the physical address of a DEV table corresponding to a protection domain.
The address andsize are encoded in a pair (high/low) of 32-bit registers. The N_DOMAINS field in DEV_CAPindicates how many (pairs of) DEV_BASE registers are implemented. The register format is as shownin Figures 15-8 and 15-9 on page 402.317Reserved. MBZFigure 15-8.BASEADDRESS[39–32]Format of DEV_BASE_HI[n] Registers3112BASEADDRESS[31–12]Figure 15-9.01176Reserved, MBZ2SIZE10PVFormat of DEV_BASE_LO[n] RegistersFields of the DEV_BASE_HI and DEV_BASE_LO registers are defined as follows:Valid (V)—Bit 0. Indicates whether a DEV table has been defined for the given protection domain;if this bit is clear, software can leave the other fields undefined, and no protection checks areperformed for memory references in this domain.Protect (P)—Bit 1.
Indicates whether accesses to addresses beyond the address range covered bythe DEV are legal (P=0) or illegal (P=1).SIZE—Bits 6–2. Specifies how much memory the DEV covers, expressed increments of 4GB *2size. In other words, a DEV table covers a minimum of 4GB, and can expand by powers of two.•••DEV_MAP Registers. The DEV_MAP registers assign protection domain numbers to deviceoriginated requests by matching the device ID (HT bus and unit number) associated with the requestagainst bus and unit numbers in the registers.
If no match is found in any of the registers, a domainnumber of zero is returned. The number of DEV_MAP registers implemented by the chip is indicatedby the N_MAPS field in DEV_CAP.The format of the DEV_MAP registers is shown in Figure 15-10.3126DOM12520DOM01912BUSNO11V1106UNIT15V040UNIT0Figure 15-10. Format of DEV_MAP[n] Registers402Secure Virtual Machine24593—Rev. 3.13—July 2007AMD64 TechnologyThe fields of the DEV_MAP[n] registers are defined as follows:•••••••UNIT0—Bits 4–0. Specifies the first of two HyperTransport link unit numbers on the bus numberspecified by the BUSNO field.V0—Bit 5.
Indicates whether UNIT0 is valid (no matches occur on invalid entries).UNIT1—Bits 10–6. Specifies the second of two HyperTransport link unit numbers on the busnumber specified by the BUSNO field.V1—Bit 11. Indicates whether UNIT1 is valid (no matches occur on invalid entries).BUSNO—Bits 19–12. Specifies a HyperTransport link bus number.DOM0—Bits 25–20. Specifies the protection domain for the first HyperTransport link unit.DOM1—Bits 31–26.
Specifies the protection domain for the second HyperTransport link unit.15.23.7 Unauthorized Access LoggingAny attempted unauthorized access by devices to DEV-protected memory is logged by the host bridgein the DEV_Error_Status and DEV_Error_Address registers for possible inspection by the VMM.15.23.8 Secure Initialization SupportThe host bridge contains additional logic that operates in conjunction with the SKINIT instruction toprovide a limited form of memory protection during the secure startup protocol. This providesprotection for a Secure Loader image in memory, allowing it to, among other things, set up full DEVprotection.
(See “Secure Startup with SKINIT” on page 411 for detailed operation of SKINIT.)The host bridge logic includes a hidden (not accessible to software) SL_DEV_BASE address register.SL_DEV_BASE points to a 64KB-aligned 64KB region of physical memory. When SL_DEV_EN is1, the 64KB region defined by SL_DEV_BASE is protected from external access (as if it wereprotected by the DEV), as well as from any access (both CPU and external accesses) via GARTtranslated addresses.
Additionally, the SL_DEV mechanism, when enabled, blocks all device accessesto PCI Configuration space.15.24Nested PagingThe optional SVM nested paging feature provides for two levels of address translation, thuseliminating the need for the VMM to maintain shadow page tables.15.24.1 Traditional Paging versus Nested PagingFigure 15-11 on page 404 shows how a page in the linear address space is mapped to a page in thephysical address space in traditional (single-level) address translation. Control register CR3 containsthe physical address of the base of the page tables (PT, represented by the shaded box in the figure),which governs the address translation.Secure Virtual Machine403AMD64 Technology24593—Rev.
3.13—July 20070Linear SpaceCR30PTFigure 15-11.Address Translation with Traditional PagingWith nested paging enabled, two levels of address translation are applied; refer to Figure 15-12 below.••••Both guest and host levels have their own copy of CR3, referred to as gCR3 and nCR3,respectively.Guest page tables (gPT) map guest linear addresses to guest physical addresses. The guest pagetables are in guest physical memory, and are pointed to by gCR3.Nested page tables (nPT) map guest physical addresses to system physical addresses. The nestedpage tables are in system physical memory, and are pointed to by nCR3.The most-recently used translations from guest linear to system physical address are cached in theTLB and used on subsequent guest accesses.It is important to note that gCR3 and the guest page table entries contain guest physical addresses, notsystem physical addresses.
Hence, before accessing a guest page table entry, the table walker firsttranslates that entry’s guest physical address into a system physical address.404Secure Virtual Machine24593—Rev. 3.13—July 2007AMD64 Technology0pagedbgCyR3Guest LineargCR30Guest PhysicalTLBEntry0nCR3nCR3ypaged bnCR3paged bygPT0nPT gPTVMMHost Lineard bypage ’s CR3MMthe VSystem PhysicalCR3 (used by VMM)PTFigure 15-12. Address Translation with Nested PagingThe VMM can give each guest a different ASID, so that TLB entries from different guests can coexistin the TLB. The ASID value of zero is reserved for the host; if the VMM attempts to execute VMRUNwith a guest ASID of zero, the result is #VMEXIT(VMEXIT_INVALID).15.24.2 Replicated StateMost processor state affecting paging is replicated for host and guest.
This includes the pagingregisters CR0, CR3, CR4, EFER and PAT. CR2 is not replicated but is loaded by VMRUN. TheMTRRs are not replicated.While nested paging is enabled, all (guest) references to the state of the paging registers by x86 code(MOV to/from CRn, etc.) read and write the guest copy of the registers; the VMM's versions of theregisters are untouched and continue to control the second level translations from guest physical tosystem physical addresses.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
