On 11/15/18 8:51 PM, Razvan Cojocaru wrote:
> On 11/15/18 10:26 PM, George Dunlap wrote:
>>
>>
>>> On Nov 14, 2018, at 8:40 PM, Razvan Cojocaru <rcojoc...@bitdefender.com> 
>>> wrote:
>>>
>>> When an new altp2m view is created very early on guest boot, the
>>> display will freeze (although the guest will run normally). This
>>> may also happen on resizing the display. The reason is the way
>>> Xen currently (mis)handles logdirty VGA: it intentionally
>>> misconfigures VGA pages so that they will fault.
>>>
>>> The problem is that it only does this in the host p2m. Once we
>>> switch to a new altp2m, the misconfigured entries will no longer
>>> fault, so the display will not be updated.
>>>
>>> This patch:
>>> * updates ept_handle_misconfig() to use the active altp2m instead
>>>  of the hostp2m;
>>> * modifies p2m_change_entry_type_global(), p2m_memory_type_changed
>>>  and p2m_change_type_range() to propagate their changes to all
>>>  valid altp2ms.
>>>
>>> With the introduction of altp2m fields in p2m_memory_type_changed()
>>> the whole function has been put under CONFIG_HVM.
>>
>> Sorry — actually, I think there’s yet another issue lurking here:  
>> p2m_finish_type_change(). I’ll poke around a bit more tomorrow.
> 
> OK, I'll wait for your recommendation before working on the last patch
> of the series.

It looks like you'll want to do the same thing to
p2m_finish_type_change() that you did for p2m_change_type_range():
create a finish_type_change() function which loops over the appropriate
range calling p2m->recalc(), and then have p2m_finish_type_change()
first call this on the hostp2m, then one-by-one on all valid altp2ms.

In finish_type_change() you'll want to clip first_gfn and max_nr to fit
within p2m->min_remapped_gfn and p2m->max_remapped_gfn for altp2ms.

I think that should do the trick.

 -George

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

Reply via email to