Re: [Xen-devel] Fix VGA logdirty related display freezes with altp2m

[Tamas K Lengyel <tamas.k.lengyel@xxxxxxxxx>]

On Thu, Oct 25, 2018 at 8:24 AM Razvan Cojocaru
<rcojocaru@xxxxxxxxxxxxxxx> wrote:
>
> On 10/24/18 8:52 PM, Tamas K Lengyel wrote:
> > On Wed, Oct 24, 2018 at 11:31 AM Tamas K Lengyel
> > <tamas.k.lengyel@xxxxxxxxx> wrote:
> >>
> >> On Wed, Oct 24, 2018 at 11:20 AM Razvan Cojocaru
> >> <rcojocaru@xxxxxxxxxxxxxxx> wrote:
> >>>
> >>> On 10/24/18 8:09 PM, Tamas K Lengyel wrote:
> >>>> On Tue, Oct 23, 2018 at 6:37 AM Razvan Cojocaru
> >>>> <rcojocaru@xxxxxxxxxxxxxxx> wrote:
> >>>>>
> >>>>> Tamas, could you please give this a spin?
> >>>>>
> >>>>> https://github.com/razvan-cojocaru/xen/tree/altp2m-logdirty-take2
> >>>>>
> >>>>> It _should_ solve the crashes.
> >>>>
> >>>> Indeed, I no longer see the crash. However, there might be some
> >>>> locking issue present because the whole system freezes up shortly
> >>>> after starting DRAKVUF on a domain - within a couple seconds. I mean
> >>>> Xen itself locks up: no response on the serial, dom0 screen frozen,
> >>>> etc.
> >>>
> >>> Do you have any type of log / backtrace / way I could reproduce it
> >>> without Drakvuf? All the ways I've tested it were fine (including
> >>> xen-access).
> >>
> >> I don't have a standalone test that produces that error. With DRAKVUF
> >> it is easily reproducible though. If you have a Windows guest
> >> installed, setting up DRAKVUF should really not be much trouble. With
> >> xen-access it indeed doesn't lock up but since the guest is pretty
> >> much unresponsive during that test I can't verify whether the VGA
> >> issue is now resolved or not. Also the xen-access tests are fairly
> >> limited and don't use all aspects of altp2m.
> >>
> >
> > What I see from the DRAKVUF log is that the last thing it prints is
> > sending a vm_event response that both enables singlestepping and
> > switches altp2m view. This looks to be consistent. It didn't matter if
> > the guest had 1 or 2 vCPUs, the freeze occurs just the same. It's
> > definitely racey because it doesn't happen right away, the system
> > works as expected for a couple seconds.
>
> After having to install clang because my GCC couldn't build Drakvuf:
>
> ../../src/plugins/plugins.h:188:1: sorry, unimplemented: non-trivial
> designated initializers not supported

Please follow the instruction for compiling it, clang is a
requirement. I don't even know how you got pass the ./configure stage
without clang being installed. You could also just copy-paste things
from the travis script directly:
https://github.com/tklengyel/drakvuf/blob/master/.travis.yml#L51

>
> then rekall via pip, then having to mount my Windows disk to do "rekal
> peinfo", I finally gave up when "rekall fetch_pdb" couldn't find the
> debug files on the Microsoft server. :)

If your version if Windows is that brand new then yes, Microsoft takes
a couple days to publish their debug information and you will just
have to wait or use an older version of Windows.

>
> So if you could find a way to reproduce the issue with a simple
> libxc-based application alone (or at least with something
> libvmi-related, which I do have set up), I'd really appreciate it.
>
> Or maybe try to hack around with patch no 3 of the series (for a start,
> just revert it and see if the problem persists - of course the display
> will freeze) and see if there's an easy fix?

Unfortunately I won't have time to do either of these any time soon.
If you are having that much trouble setting it up I can perhaps send
you a pre-compiled version with a version of Windows for which
Microsoft already published the debug info for.

Tamas

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