Paolo Bonzini <pbonzini@xxxxxxxxxx> writes: > 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. Thank you very much, this clears it. pte & 7 makes sense now. Xiao, as Paolo suggested, I can just remove the non FNAME version and directly do pte & PT_PRESENT_MASK at the two call sites. I hope that will future proof it. Thanks, Bandan > Paolo -- 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
