Re: [PATCH V7 3/5] x86/altp2m: fix display frozen when switching to a new view early

["Jan Beulich" <JBeulich@suse.com>]

>>> On 19.11.18 at 18:26, <rcojocaru@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(), p2m_change_type_range() and
>   p2m_finish_type_change() 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.
> 
> Signed-off-by: Razvan Cojocaru <rcojocaru@bitdefender.com>
> Suggested-by: George Dunlap <george.dunlap@citrix.com>

Judging from George's earlier analysis I wonder whether the patch
ordering is correct: I've got the impression that the patch here should
be last in the series, for it to be correct and efficient in all cases.

Furthermore (minor, but this appears to recur), may I ask that you
switch around tags like the above ones in the future? As previously
expressed (in other contexts) I'm of the opinion that the sequence
of tags should represent the flow of events, and a bug report as
much as a suggestion of a change can't have happened before the
writing of a patch.

Jan



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