On 06/24/2016 02:46 PM, Paolo Bonzini wrote:
On 24/06/2016 06:50, Bandan Das wrote:
I am tempted to remove the FNAME version altogether and change
is_present_gpte()
to return (pte & PT_PRESENT_MASK) || (shadow_xonly_valid && (pte & 4)). This
will take care of all cases. Hope I am not missing something :)
Please rename the non-FNAME version to pae_is_present_pdpte or just inline
it in the two callers.
I am still not sure why the FNAME version is needed, specifically the PTTYPE_EPT
specific check. Why can't we just check for execonly and the corresponding
bit in the non FNAME version ?
The FNAME version encodes the right semantics:
1) for non-EPT page tables, bit 1 indicates present.
2) for EPT page tables, setting any bit 0-2 indicates present.
It's perfectly fine to find that a PTE is invalid *after* judging that
it is present. There is no difference between setting bit 51 on a PTE,
and having the invalid -W- combination on an EPT page table entry. In
both cases, the page is present but the PTE is invalid.
The SDM is very clear about it: "If bits 2:0 of an EPT paging-structure
entry are all 0, the entry is not present". So if bits 2:0 are -W- the
entry is present but invalid, and causes an EPT misconfiguration vmexit.
A non-present entry will cause an EPT violation instead.
Yes, i agree. Actually i have pointed it out in my previous comment:
"
For !shadow_xonly_valid guest, 100b on gpte can not pass FNAME(is_present_gpte)
so that we can get a error code without RSVD, finally a EPT-violation is injected
rather than EPT-misconfig.
"
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
