[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

>>> On 16.11.18 at 16:52, <george.dunlap@xxxxxxxxxx> wrote:
> 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. :-/

And I think I can follow your analysis now, which in turn means I
think your two patches are going to help, but for a proper review
I'd prefer them to be inline in a mail, rather than attachments.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.