[Xen-devel] Weird altp2m behaviour when switching early to a new view

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

Hello,

I've noticed altp2m behaviour I can't explain yet - I'm not all that
familiar with all the ways the new views corellate with the previous
EPT-based "view 0".

In short, if we create a new view and simply switch to it early in the
boot process of the guest, something goes wrong and the guest either
freezes, becomes unresponsive to input, or has something wrong with the
display (most often the latter, with a black band on top of the image):

https://ibb.co/eUPJ6c
https://ibb.co/etCXXH

That guest is a 64-bit Windows 7 system with nothing special about it.
It's easy to reproduce this:

1. Start the guest paused (I've used "xl create -p myguest.conf").
2. Patch xen-access like this: https://pastebin.com/67PpQ9fu (just
remove the part of the code that modifies the new view before switching
to it).
3. Hook xen-access to the guest ("./xen-access <domid> altp2m_write").
4. Unpause the guest ("xl unpause <domid>").

I think that's a valid scenario and supposed to work.

I've also noticed that if I wait to do this until the OS is
up-and-running (e.g. after logging into Windows), there seems to be no
problem. I don't know if this is just coincidence (as is bound to happen
with race-condition situations), or means something, but I can get the
problems every time when switching views early, and never when switching
the views late.

Suggestions on what the problem could be are, as always, greatly
appreciated.


Thanks,
Razvan

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