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/19/18 4:17 PM, Razvan Cojocaru wrote:
> On 11/19/18 5:58 PM, George Dunlap wrote:
>> On 11/17/18 6:58 PM, Razvan Cojocaru wrote:
>>> On 11/16/18 9:50 PM, Razvan Cojocaru wrote:
>>>> On 11/16/18 7:59 PM, George Dunlap wrote:
>>>>> On the other hand, we want the logdirty rangesets to actually match the
>>>>> host's rangesets; using altp2m->max_mapped_pfn for this is clearly
>>>>> wrong. The easiest fix would be just to explicitly use the host's
>>>>> max_mapped_pfn when calculating the clipping.  A more complete fix would
>>>>> involve calculating two different ranges -- a "rangeset" range and a
>>>>> "invalidate" range, the second of which would be clipped on altp2ms by
>>>>> {min,max}_remapped_gfn.
>>>>>
>>>>> Something like the attached (compile-tested only).  I'm partial to
>>>>> having both patches applied, but I'd be open to arguments that we should
>>>>> only use the first.
>>>>
>>>> Thanks! I haven't yet been able to think in depth about the logic, but I
>>>> did manage to apply them. Just applying the first one allows me to set
>>>> p2m->max_mapped_pfn = 0; without the ASSERT() crashing the hypervisor,
>>>> and everything appears to work well.
>>>>
>>>> With both patches applies, the display remains frozen (things appear to
>>>> behave - externally - in the same way as before the series).
>>>
>>> Right, I know why the second patch keeps the display frozen. It's
>>> because for altp2ms (where it matters most), the patch basically does
>>> invalidate_start = max(invalidate_start, p2m->min_remapped_gfn) and
>>> invalidate_end = min(invalidate_end, p2m->max_remapped_gfn).
>>>
>>> However, as previously requested, I've now made p2m->max_remapped_gfn
>>> begin life as 0 for altp2ms, and p2m->min_remapped_gfn is initialized to
>>> INVALID_GFN, which is decimal 18446744073709551615. So we get
>>> invalidate_end: 0, invalidate_start: 18446744073709551615,
>>> invalidate_end < invalidate_start, resulting in nothing being done for
>>> altp2ms, which is functionally back to square one.
>>
>> But this doesn't explain why my reasoning was wrong; and it's always
>> dangerous to use a system whose behavior you don't really understand,
>> even if it seems to work.
>>
>> It turns out I'd made a mistake in saying that altp2m->max_mapped_pfn ==
>> alt2m->max_remapped_gfn.  The first is the highest gfn present in the
>> altp2m, either copied from the hostp2m or changed; the second is the
>> highest value changed (via p2m_altp2m_change_gfn()).
>>
>> What about using the attached patch instead?
> 
> The attached patch does work, thanks! Shall I append them both to the
> end of the series and send out V7?

Yes, please.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel