Re: [Xen-devel] [PATCH V6 4/4] x86/altp2m: fix display frozen when switching to a new view early

[George Dunlap <george.dunlap@xxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel