On 07/28/2016 05:06 PM, Marek Marczykowski-Górecki wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Thu, Jul 28, 2016 at 06:32:00PM +0000, HW42 wrote:
Hi,
as described in #1028 the window content of VM windows get sometimes
trashed.
The problem is that the pages with the windows content need to be pinned
to a physical page when being mapped with xc_map_foreign_pages. To
archive this the current code calls mlock(). Unfortunately this only
ensures that the page doesn't get swapped out but the kernel can still
move the page.
From [0]:
A page that has been locked into memory with a call like mlock() is
required to always be physically present in the system's RAM. [...].
But there is nothing that requires a locked page to always be present
in the same place; the kernel is free to move a locked page if the
need arises.
So when a VM window looks corrupted the VM kernel has moved the page and
it has now a new physical address and in dom0 you now see the new
content of the old physical page.
Wow, thanks for finding this out!
If you want to monitor the effect you can use the attached script. It
shows the mapping of virtual addresses to physical addresses of a given
memory range for a given process. So call strace on Xorg to get the
mlock() call and pass those arguments to the script. Now either wait
until you have "luck" or provoke it by
'echo 1 > /proc/sys/vm/compact_memory'
Unfortunately the patch from [0] didn't got into the kernel, so there
is no easy way to pin a page similar to mlock().
One workaround is to disable memory compactation of unevictable (i.e.
mlocked) pages:
echo 0 > /proc/sys/vm/compact_unevictable_allowed
This has two downsides:
a) While I didn't observed the effect anymore with this setting I'm not
sure if this prevents all cases in which the kernel moves pages. (A
bit grepping suggest that it ignores this flag when allocating
hugepages but I'm not sure about this.)
b) Given that VMs in Qubes are often low on memory I'm a bit uneasy to
change memory management options without knowing the side effects.
I think we can live with those downsides for now.
Properly pinning is not that easy since there seems to be no way to flag
a page as unmovable. The common way seems to be to call
get_user_pages() to increment the reference counter and thereby pin it.
The problem is that then the u2mfn module needs to be changed
significantly to track allocation and deallocation since else the pages
never get freed.
If somebody (who is familiar with the linux kernel) knows another
solution this would be great.
#2185 mentions that you want do get rid of u2mfn anyway. How does the
new solution should work?
u2mfn module is needed to get page mfn, because otherwise kernel doesn't
provide this information to user space. But in HVM/PVH, it should be
enough to look at /proc/PID/pagemap. For PV this file contains pfn
("guest-specific pseudo-physical frame number"), which is not what we
need. So this problem will still apply.
So this problem will still apply. Proper solution would require
switching from xc_map_foreign_pages, to grant tables. But since this
require pages to be initially allocated using grant tables API, it
require substantial changes to video driver or even patching X server
itself.
But on the other hand, it should make this issue go away. And also will
be probably required for separate GUI domain.
As an alternative, would it be possible to detect eviction events and
then tell the guest to refresh the window (as manually refreshing the
window is already a sort of workaround to the display garbage problem).
Chris
Unless somebody knows a better way to lock pages the best thing for R3.2
is probably to use the above mentioned work-around and implement a
better solution in R4.
HW42
[0]: https://lwn.net/Articles/600502/
- --
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/7498feaa-846b-e192-ab21-6316310b45a1%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.
