Volume 2 System Programming (794096), страница 96
Текст из файла (страница 96)
All other exceptions are checked after the SVM intercept check.I/O Intercept Information. When an IOIO intercept triggers, the following information (describingthe intercepted operation in order to facilitate emulation) is saved in the VMCB’s EXITINFO1 field:3116 15PORTBits31–1615–10987654321MnemonicPORTReserved, SBZA64A32A16SZ32SZ16SZ8REPSTR00TYPE10 9Reserved87654321S S S R SA A AZ Z Z E T64 32 1632 16 8 P R00TYPEDescriptionIntercepted I/O port64-bit address32-bit address16-bit address32-bit operand size16-bit operand size8-bit operand sizeRepeated port accessString based port access (INS, OUTS)Access Type (0 = OUT instruction, 1 = IN instruction)Figure 15-2.EXITINFO1 for IOIO InterceptThe rIP of the instruction following the IN/OUT is saved in EXITINFO2, so that the VMM can easilyresume the guest after I/O emulation.Secure Virtual Machine379AMD64 Technology15.1024593—Rev.
3.13—July 2007MSR InterceptsThe VMM can intercept RDMSR and WRMSR instructions by means of the SVM MSR permissionsmap (MSRPM) on a per-MSR basis.MSR Permissions Map. The MSR permissions bitmap consists of a number of smaller separatebitmaps of 2K bytes each covering a defined range of 8K MSRs. Four of these smaller bitmaps residein two physical pages (8KB, covering 32K MSRs). One 8Kbyte range is used for the Pentium®compatible MSRs, the next 8K range is used for the AMD sixth generation x86 processor (AMD-K6®)MSRs, and the third 8K range for the AMD seventh and eighth generation x86 processors (e.g., theAMD Athlon™ and AMD Opteron™) MSRs.
If the MSR_PROT intercept is active, any attempt toread or write an MSR not covered by the bitmap will automatically cause an intercept.The MSRPM is accessed by physical address, and should reside in memory that is mapped aswriteback (WB). The MSRPM must be aligned on a 4KB boundary. The physical base address of theMSRPM is specified in MSRPM_BASE_PA field in the VMCB and is loaded into the processor by theVMRUN instruction. The VMRUN instruction ignores the lower 12 bits of the address specified in theVMCB, and if the address of the last byte in the table is greater than or equal to the maximumsupported physical address, this is treated as illegal VMCB state and causes a#VMEXIT(VMEXIT_INVALID).Table 15-3.Ranges of MSR Permissions MapByte OffsetMSR Range000h–7FFh0000_0000h–0000_1FFFhCurrent UsagePentium®-compatible MSRs800h–FFFhC000_0000h–C000_1FFFhAMD Sixth Generation x86 Processor MSRs and SYSCALL1000h–17FFh C001_0000h–C001_1FFFhAMD Seventh and Eighth Generation Processor MSRs1800h–1FFFh XXXX_XXXX–XXXX_XXXXreservedTable 15-3 defines the ranges of the MSR permissions map.
For each MSR mapped by the table, twobits are allocated—the lower order of the two bits controls read access to the MSR, and the higherorder of the two bits controls write access. A bit value of 1 indicates that the operation is intercepted.RDMSR and WRMSR Behavior. If the MSR_PROT bit in the VMCB’s intercept vector is clear,RDMSR/WRMSR instructions are not intercepted.RDMSR and WRMSR instructions check for exceptions and intercepts in the following order:•••Exceptions common to all MSRs (e.g., #GP if not at CPL-0)Check SVM intercepts in the MSR permission map, if the MSR_PROT intercept is requested.Exceptions specific to a given MSR (including password protection, unimplemented MSRs,reserved bits, etc.)MSR Intercept Information.
On #VMEXIT, the processor indicates in the VMCB’s EXITINFO1whether a RDMSR (EXITINFO1 = 0) or WRMSR (EXITINFO1 = 1) was intercepted.380Secure Virtual Machine24593—Rev. 3.13—July 200715.11AMD64 TechnologyException InterceptsWhen intercepting exceptions that define an error code (normally pushed onto the exception stack), theSVM hardware delivers that error code in the VMCB’s EXITINFO1 field; the exception vectornumber can be derived from the EXITCODE.
The CS.SEL and rIP saved in the VMCB on anexception-intercept match those that would otherwise have been pushed onto the exception stackframe, except that when an interrupt-based instruction causes an intercept, the rIP of the instruction isstored in the VMCB, rather than the rIP of the next instruction. The interrupt-based instructions areINT3 (opcode CC), INTO, and BOUND.Unless otherwise noted below, no special registers are written before an exception is intercepted. Fordetails on guest state saved in the VMCB, see Section 15.7.1.External interrupts and software interrupts (INTn instruction) do not check the exception intercepts,even when they use a vector in the range 0 to 31.Exceptions that occur during the handling of a prior exception are checked for intercepts before beingcombined with the prior exception (e.g., into a double-fault). If the result of combining exceptions is adouble-fault or shutdown, the processor checks whether those are intercepted before attemptingdelivery.Example: Assume that the VMM intercepts #GP and #DF exceptions, and the guest raises a (non-intercepted) #NP, during the delivery of which it also gets a #GP (e.g., due to an illegal IDT entry)—asituation that, according to x86 semantics, results in a #DF.
In this case, #VMEXIT signals anintercepted #GP, not an intercepted #DF and fills EXITINTINFO with the #NP fault. On the otherhand, if only the #DF intercept were active in this scenario, #VMEXIT would signal an intercepted#DF.The following subsections detail the individual intercepts.#DE (Divide By Zero)The EXITINFO1 and EXITINFO2 fields are undefined.#DB (Debug)The #DB exception can have fault-type (e.g., instruction breakpoint) or trap-type (e.g., databreakpoint) behavior; accordingly the intercept differs in what state is saved in the VMCB (see “StateSaved on Exit” on page 373).
In either case, however, the value saved for DR6 and DR7 matches whatwould be visible to a #DB exception handler (i.e., both #DB faults and traps are permitted to writeDR6 and DR7 before the intercept). The EXITINFO1 and EXITINFO2 fields are undefined.Fault-type #DB exceptions, whether indicated in EXITCODE or EXITINTINFO, cause the CS:rIPsaved in the VMCB to indicate the instruction that caused the #DB exception. Trap-type #DBexceptions cause the VMCB’s CS:rIP to indicate the instruction following the instruction that causedthe exception.
A vector 1 exception generated by the single byte INT1 instruction (also known asSecure Virtual Machine381AMD64 Technology24593—Rev. 3.13—July 2007ICEBP) does not trigger the #DB intercept. Software should use the dedicated ICEBP intercept tointercept ICEBP (see “Instruction Intercepts” on page 376).15.11.1 Vector 2 (Reserved)This intercept bit is not implemented; use the NMI intercept (Section 15.12.2) instead. The effect ofsetting this bit is undefined.15.11.2 #BP (Breakpoint)This intercept applies to the trap raised by the single byte INT3 (opcode CCh) instruction. TheEXITINFO1 and EXITINFO2 fields are undefined.
The CS:rIP reported on #VMEXIT are those of theINT3 instruction.15.11.3 #OF (Overflow)This intercept applies to the trap raised by the INTO (opcode CEh) instruction. The EXITINFO1 andEXITINFO2 fields are undefined.15.11.4 #BR (Bound-Range)This intercept applies to the fault raised by the BOUND instruction.
The EXITINFO1 andEXITINFO2 fields are undefined.15.11.5 #UD (Invalid Opcode)The EXITINFO1 and EXITINFO2 fields are undefined.15.11.6 #NM (Device-Not-Available)The EXITINFO1 and EXITINFO2 fields are undefined.15.11.7 #DF (Double Fault)The EXITINFO1 and EXITINFO2 fields are undefined. The rIP value saved in the VMCB isundefined (as is the case for the rIP value pushed on the stack for #DF exceptions). If a double fault isintercepted, the exceptions leading up to the double fault will have written any status registersnormally written by those exceptions.15.11.8 Vector 9 (Reserved)This intercept is not implemented. The effect of setting this bit is undefined.15.11.9 #TS (Invalid TSS)The EXITINFO1 and EXITINFO2 fields are undefined.
The rIP value saved in the VMCB may pointto either the instruction causing the task switch, or to the first instruction of the incoming task. See“Task Switch Intercept” on page 386 for information in the EXITINFO1 and EXITINFO2 fields.382Secure Virtual Machine24593—Rev. 3.13—July 2007AMD64 Technology15.11.10 #NP (Segment Not Present)The EXITINFO1 field contains the error code that would be pushed on the stack by a #NP exception.The EXITINFO2 field is undefined.15.11.11 #SS (Stack Fault)The EXITINFO1 field contains the error code that would be pushed on the stack by a #SS exception.The EXITINFO2 field is undefined.15.11.12 #GP (General Protection)The EXITINFO1 field contains the error code that would be pushed on the stack by a #GP exception.15.11.13 #PF (Page Fault)This intercept is tested before CR2 is written by the exception.
The error code saved in EXITINFO1 isthe same as would be pushed onto the stack by a non-intercepted #PF exception in protected mode.The faulting address is saved in the EXITINFO2 field in the VMCB. Even when the guest is running inpaged real mode, the processor will deliver the (protected-mode) page-fault error code in EXITINFO1,for the VMM to use in analyzing the intercepted #PF.15.11.14 #MF (X87 Floating Point)This intercept is tested after the floating point status word has been written, as is the case for a normalFP exception. The EXITINFO1 and EXITINFO2 fields are undefined.15.11.15 #AC (Alignment Check)The EXITINFO1 field contains the error code that would be pushed on the stack by an #AC exception.The EXITINFO2 field is undefined.15.11.16 #MC (Machine Check)The SVM intercept is checked after all #MC-specific registers have been written, but before otherguest state is modified.
When #MC is being intercepted, a machine-check exits to the VMM, wheneverpossible, and shuts down the processor only when this is not a reasonable option. The EXITINFO1 andEXITINFO2 fields are undefined.15.11.17 #XF (SIMD Floating Point)This intercept is tested after the SIMD status word (MXCSR) has been written, as is the case for anormal FP exception. The EXITINFO1 and EXITINFO2 fields are undefined.Secure Virtual Machine383AMD64 Technology15.1224593—Rev. 3.13—July 2007Interrupt InterceptsExternal interrupts, when intercepted, cause a #VMEXIT; the interrupt is held pending so that theinterrupt can eventually be taken in the VMM.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
