[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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. :)

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?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.