-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Thu, Jul 28, 2016 at 07:42:29PM -0400, Chris Laprise wrote:
> 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).
As far I understand, no. At least not easily (without additional kernel
modification/module).
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBCAAGBQJXmpykAAoJENuP0xzK19cs9sMH/2w1o/lm/7pIe6kS2ZMXM6hP
K8caCD5OGtIi5eXloULkFgFfQSEyDXbGYJh9kJm2NwP9mX+BhCdPENZLFTQzrqZG
UsRFQSAZiKws5FYxWGh/w92vtoyLuAl6QUnmT9M/ci9q9BnCyuKT6FGlUL8OaErr
RVRUgqsuvkuFRV8GmJl6822YUo7wdbNERaAysx3wQzT4C6NkRBBtiGBun7jxpViB
9QsCnjdanwCQ/QAPAzJ4qAaqhwY4HWSTb0X0IV9mBrw6jEoFc5O+dTiHbT2fhJV8
4Zrk4ykhJHyYtdL0KYBgnog1ykPi/XKY/wn+ioBCfelFB4mgl3ExAAApgf4oR7E=
=+Nzv
-----END PGP SIGNATURE-----
--
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/20160729000035.GJ32095%40mail-itl.
For more options, visit https://groups.google.com/d/optout.
