AMD 4.4.5 Switch User Manual


 
AMD Confidential
User Manual November 21
st
, 2008
184 Appendix A
A.5 Known Issues
A.5.1 FSAVE/FRSTOR and FSTENV/FLDENV
When the simulator is executing FSAVE/FRSTOR and FSTENV/FLDENV in real-mode
it is using the 16-bit protected-mode memory format.
A.5.2 Triple Faulting
If the processor encounters an exception while trying to invoke the double fault (#DF)
exception handler, a triple fault exception occurs. This can rarely occur, but is possible.
For example, if the invocation of a double fault exception causes the stack to overflow,
then this would cause a triple fault. When this happens, the CPU will triple fault and
cause a shutdown-cycle to occur. This special cycle should be interpreted by the
motherboard hardware, which then pulls RESET, which ultimately resets the CPU and
the computer.
However, the simulator does not simulate triple faults. In case a triple fault occurs, the
simulator stops the simulation. The simulation cannot be restarted until a reset is asserted
but the simulation state can be inspected with the simulators debugger.
A.5.3 Performance-Monitoring Counter Extensions
Setting CR4.PCE (bit 8) to 1 allows software running at any privilege level to use the
RDPMC instruction. Software uses the RDPMC instruction to read the four performance-
monitoring MSRs, PerfCTR[3:0]. Clearing PCE to 0 allows only the most-privileged
software (CPL=0) to use the RDPMC instruction.
The simulator does support the RDPMC instruction but there is no logic behind the
simulated performance counter MSRs.
A.5.4 Microcode Patching
Microcode patches do not affect the simulated machine behavior. This may have
unintended consequences.
A.5.5 Instruction Coherency
Instruction coherency does not work when code pages have multiple virtual-mappings.
Here is an example that would not work right:
1. There is an x86 physical page that has code on it.
2. This page is mapped by two different virtual addresses, A and B
3. There is a store to virtual page A
4. We execute code from page B
5. We store again to A, modifying some of the x86 code that we executed in step 4
6. We execute the code from step 4 again