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

From: Alexey G <x1917x@gmail.com>
To: Razvan Cojocaru <rcojocaru@bitdefender.com>
Cc: "Tian, Kevin" <kevin.tian@intel.com>,
	Tamas K Lengyel <tamas@tklengyel.com>,
	Andrew Cooper <Andrew.Cooper3@citrix.com>,
	Tim Deegan <tim@xen.org>,
	George Dunlap <george.dunlap@citrix.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	xen-devel@lists.xenproject.org
Subject: Re: Weird altp2m behaviour when switching early to a new view
Date: Tue, 10 Apr 2018 01:40:13 +1000	[thread overview]
Message-ID: <20180410014013.00005ee1@gmail.com> (raw)
In-Reply-To: <a592fcb3-c2c6-bd83-01a4-0ac7ba9f3fa5@bitdefender.com>

On Sun, 8 Apr 2018 23:38:31 +0300
Razvan Cojocaru <rcojocaru@bitdefender.com> wrote:
>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 difference between starting the domain paused and switching altp2m
views later (in this particular case) is likely the fact whether
the emulated LFB backing storage (aka VRAM) was "deployed" to the guest
domain or not.

QEMU uses special ranges to maintain the state of some emulated
devices with memories. These are VRAM and Option ROMs, but latter are
emulated as MMIO currently for some reason (either a bug or
intentionally). VRAM area is used to hold the LFB content for the
emulated videocard (stdvga/cirrus/etc) and its usage depends on whether
the emulated LFB is currently mapped or not.

When you start the domain paused, VRAM is not mapped to the guest
address space yet -- it is allocated to the location outside the guest
memory map, known to QEMU. In order to map VRAM to the guest's address
space, the emulated QEMU videocard needs to be initialized, which
happens when hvmloader or guest OS allocates MMIO BARs for the emulated
videocard.
Upon writing the corresponding BAR register, the VRAM area is relocated
to the guest's visible address space (via add_to_physmap hypercall).
Disabling MMIO decoding may cause to relocate the VRAM range back
to its hidden backing storage (again via add_to_physmap).

So, it's basically the same appearance of the problem of different
Xen/QEMU views on guest's memory layout.

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