Re: Weird altp2m behaviour when switching early to a new view

From: George Dunlap <george.dunlap@citrix.com>
To: Razvan Cojocaru <rcojocaru@bitdefender.com>,
	xen-devel@lists.xenproject.org
Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>,
	"Tian, Kevin" <kevin.tian@intel.com>,
	Tamas K Lengyel <tamas@tklengyel.com>, Tim Deegan <tim@xen.org>,
	Jun Nakajima <jun.nakajima@intel.com>
Subject: Re: Weird altp2m behaviour when switching early to a new view
Date: Mon, 9 Apr 2018 15:12:48 +0100	[thread overview]
Message-ID: <d0ae9d3e-31ee-a03b-dc9d-b86ceb92fe52@citrix.com> (raw)
In-Reply-To: <a592fcb3-c2c6-bd83-01a4-0ac7ba9f3fa5@bitdefender.com>

On 04/08/2018 09:38 PM, Razvan Cojocaru wrote:
> 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.

The obvious place to look is the logdirtyvram functionality, which is
used to make it easier for QEMU to figure out which bits of the display
buffer have been modified.  One of the big reasons the altp2m
functionality is still considered "experimental" is that these sorts of
interactions were never carefully thought out.

 -George

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