Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should not MMIO region be Uncacheable (not WriteBack)? #31

Closed
tandasat opened this issue Sep 6, 2016 · 3 comments
Closed

Should not MMIO region be Uncacheable (not WriteBack)? #31

tandasat opened this issue Sep 6, 2016 · 3 comments

Comments

@tandasat
Copy link
Owner

tandasat commented Sep 6, 2016

Capturing a question in a thread #29.

@tandasat tandasat changed the title Should not MMIO region be Uncacheable (not WriteBack) Should not MMIO region be Uncacheable (not WriteBack)? Sep 6, 2016
@tandasat
Copy link
Owner Author

tandasat commented Sep 6, 2016

@ionescu007

It seems fine to use WriteBack EPT settings for MMIO.

28.2.6.2 Memory Type Used for Translated Guest-Physical Addresses explains how the effective memory type of a memory access using a guest-physical address is determined. According to it,
when CR0.CD = 0 and ignore_pat_memory_type (the value of bit 6 of the last EPT paging-structure entry) is 0, the effective memory type is determined by the EPT (instead of MTRR) and PAT as explained in Table 11-7. Effective Page-Level Memory Types for Pentium III and More Recent Processor Families.

The table shows that regardless of the MTRR memory type, which equals to the EPT memory type in our case, always PAT entry value is used for the effective memory type. Hence, setting WriteBack to the EPT memory type should be no problem and the UC memory type should be used for MMIO regions if a guest configured so.

@tandasat tandasat closed this as completed Sep 6, 2016
@ionescu007
Copy link

Based on Intel answer and thorough reading section 2C in SDM, it clearly says that MTRRs are ignored when using EPT. Therefore, blindly setting pages to WB can cause issues with special MMIO regions that do not tolerate WB, and whose data is only in the MTRRs and not PAT.

@tandasat
Copy link
Owner Author

tandasat commented Mar 26, 2017

@ionescu007

I am not sure there is a case where PAT does not exist. My understanding is that as long as a processor supports PAT (all modern processors do), a processor always looks up PTE or PDE and determines PAT.

Regardless, blindly setting WB to EPT is problematic as you pointed out. EPT overwrites a memory type via MTRR as denoted in Memory Type Used for Translated Guest-Physical Addresses which results in a different effective memory type. For example, when an original MTRR is UC and PAT is either WT, WB, or WP, the effective memory type is supposed to be UC, but it is going to be different EPT is configured as WB.

I had misunderstood what the table explained and replied wrong here. Thank you for catching the issue and remind me! I have a fix locally and will apply it after some tests.

tandasat added a commit that referenced this issue Apr 3, 2017
This update fixes a system hang and power callback issues seen on
Kaby Lake systems.

The root cause was that a memory type set for EPT PTE did not respect
MTRR and overwriting UC set in MTRR with WB, which led to WB memory
type for MMIO regions.

This update is to read and store all MTRRs at initialization, and
consult them when EPT entries are built.

Signed-off-by: Satoshi Tanda <tanda.sat@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants