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

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

On 9/3/18 4:27 PM, Jan Beulich wrote:
>>>> On 03.09.18 at 10:25, <rcojocaru@xxxxxxxxxxxxxxx> 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;
> 
> Wouldn't you, as a prereq to this, first need to make sure global
> changes leading to EPT misconfig exits get mirrored to all altp2m-s?
> The prime example is p2m_memory_type_changed(), which only
> acts on the hostp2m as well.

Right, I think that might be needed as well. There's always a corner
case there too, I think: the userspace agent may always activate altp2m
on a domain _after_ the misconfiguration has already happened (on the
hostp2m only), so nothing got propagated when it should have.

Ideally all the code would be updated to use the active (alt)p2m instead
of the hostp2m. However, altp2ms are second-class citizens in Xen - for
example the current code pays no attention to altp2m->logdirty_ranges
(which is only allocated in p2m_init_hostp2m(), and left as 0 - or NULL
- by p2m_init_altp2m()).

I think what we need is:

1. Create altp2ms with as much information as the hostp2m.

2. On switch, copy over all relevant information from the currently
active p2m (which may or may not be the host p2m).

This can get very subtle, since one approach would be to duplicate
information in altp2ms, another would be to share (and thus have to
synchronize access to) that information between views (i.e.
pointer-to-struct). logdirty_ranges is the best example of that - it
should have the exact same contents for all views as far as I can tell.
The EPT information for misconfigurations is another example.

Clearly this is quite complicated code, hopefully George will chime in
when he gets a chance.


Thanks,
Razvan

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