On 11/16/18 3:05 PM, George Dunlap wrote: > Now take change_type_range. The global effect of change_type_range > should be that reads of the p2m which happen afterwards should have the > new, changed value. > > In case A, change_type_range will write invalid entries up to > max_remapped_pfn, leaving the range between max_remapped_pfn and > hostp2m->max_mapped_pfn invalid. When a gfn in this range is read, an > EPT fault will happen, p2m_altp2m_lazy_copy() will be called, and the > new (correct) value copied from the hostp2m. > > In case B, change_type_range will write invalid entries up until > hostp2m->max_mapped_pfn. When a gfn in this range is accessed, a > MISCONFIG fault will happen, and the correct value will be calculated in > resolve_misconfig.
Or, no: resolve_misconfig() will read the current type in the altp2m, which will be p2m_invalid; p2m_recalc_type() will then return p2m_invalid, and then set the entry to a "plain" invalid without the reserved bit set. Then the fault will happen again, taking the normal HAP fault path (calling p2m_altp2m_lazy_copy()), at which point... > And at this point, I realize that my previous analysis was probably > wrong, because at this point altp2m->max_remapped_gfn will be wrong: > entries above max_remapped_gfn will have become valid without going > through p2m_altp2m_lazy_copy(). ...altp2m->max_remapped_gfn will be set appropriately. I think. :-/ -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
