EPT write back memory type and Machine Check exception

devstf

Wed, 08/24/2011 - 04:29

Hello, I'm having trouble with EPT on Core i3 550 and Core i3 370M (only available hardwar for my tests). I'm developping a bare metal hypervisor dedicated to one VM. The following behavior happens while the VM is running with EPT configured in WB mode. EPT mappings area identity mappings from the VM physical memory to the system one. A Machine Check exception is raised by the CPU wherever we are into the VMM or the VM and whichever the current instruction is. It originally happened on a "wbinvd" and i thought it was related to cache coherency or something like that, but on the Core i3 370M the #MCE is raised upon a "cld" which does not make any sense to me. The fact is that when i configure EPT mappings using UC memory type, the #MCE is never raised. Enabling or disabling MTRRs in the host/guest, does not change anything. When inspecting the different MSRs related to MCE/MCA, i have been able to collect these values: P5_ADDR 0x0 P5_TYPE 0x800
MCE cap 0xc09
MC0_STS 0x0
MC1_STS 0x800
MC2_STS 0x0
MC3_STS 0x0
MC4_STS 0x0
MC5_STS 0x0
MC6_STS 0x0
MC7_STS 0x0
MC8_STS 0xf

As you can seen, no MCi seems to be valid and no error code seems to have a particular meaning. The hypervisor is running under bochs 2.4.6 and well supported on real hardware using AMD cpu. This is just to say that the "concept" is working and i think i'm having a specific issue on a "real" Intel CPU, in my opinion. Do you have any experience at Intel labs about #MCE related to EPT or virtualization. Is there any problem with EPT/Core i3 "westmer" ? thanks in advance stf

6 posts / 0 new

Last post

For more complete information about compiler optimizations, see our Optimization Notice.

devstf

Mon, 08/29/2011 - 08:43

The problem came from missconfiguration of EPT mem type. I needed to replicate MTRRs to EPT entries as well as IA32_PAT msr.

David Ott (Intel)

Mon, 08/29/2011 - 13:52

When EPT is enabled, MTRRs are not used for memory-typing by Intel CPUs. (Refer to EPT documentation in IA-32 Software Developers' Manual Volume 3B.)

It is possible thatall memory (including MMIO space) is being mapped as WB through EPT. And since MTRRs are not used, when guest tries to access some MMIO region, it is attempted by hardware as WB (which is illegal), resulting in the machine-check.

When setting up EPT paging structures, software should make sure the EPT memory-type in the EPT entry matches the MTRR value for the respective address range.

David Ott

devstf

Tue, 08/30/2011 - 03:34

Hello David, Thanks for your answer. I think some cache lines, when invalidated, were related to MMIO and so that's why i had the #MC on "wbinvd" due to EPT set up as WB. I totally agree with you. I have browsed the forum and found an anwer of you pointing to the Xen mailing list and detailing the same issue. By the way, why the #MC MSRs were not properly filled ? Is it my interpretation or they were left empty with irrelevant values ? Thanks again for your technical involvement stf

David Ott (Intel)

Fri, 09/30/2011 - 15:55

Received the following comment/question from a colleague:

"It should update the appropriate #MC MSRs corresponding to the error. So, we will need more info on what the user means by not properly filled? Is he not seeingvalid statusfor the#MC bank MSR's status?"

David Ott

devstf

Mon, 10/10/2011 - 04:28

"Is he not seeingvalid statusfor the#MC bank MSR's status?" Absolutely. The 1st message of the thread provides the #MC MSR values as read into the VMM upon #MC exception. They seem invalid to me. Maybe i miss-interpreted them. Do you think the following values are related to a #MC for a write-back access on mm i/o ? P5_ADDR 0x0 P5_TYPE 0x800
MCE cap 0xc09
MC0_STS 0x0
MC1_STS 0x800
MC2_STS 0x0
MC3_STS 0x0
MC4_STS 0x0
MC5_STS 0x0
MC6_STS 0x0
MC7_STS 0x0
MC8_STS 0xf thank you

Back to original post

Intel® Developer Zone

EPT write back memory type and Machine Check exception

EPT write back memory type and Machine Check exception

Login to leave a comment.