On Fri, 12 Oct 2018, Marc Zyngier wrote:
> Right. But how is that related to KVM? See below:
>
> > [75476.680725] find_next_and_bit+0xc/0x70
> > [75476.680728] find_busiest_group+0x128/0x938
> > [75476.680730] load_balance+0x148/0x848
> > [75476.680732] pick_next_task_fair+0x1d4/0x568
> > [75476.680734] __schedule+0xe8/0x4b0
> > [75476.680736] schedule+0x38/0xa0
> > [75476.680739] kvm_vcpu_block+0x88/0x180
> > [75476.680742] kvm_handle_wfx+0x80/0xb8
> > [75476.680744] handle_exit+0x138/0x1b8
>
> The guest is exiting because it has executed a blocking WFI, so KVM's
> job is done and we're calling schedule(). The scheduler then starts
> doing its job of picking the next victim.
>
> At this stage, the kernel indeed blows up. But this doesn't immediately
> seem to be KVM's fault. It is far more likely that the scheduler has
> messed something up in its own data structure, which is even worse :-(.
>
> I'd suggest you get in touch with the scheduler guys to see if they have
> any insight. Also, trying to come up with a reproducer would be
> extremely useful.
>
> Thanks,
>
> M.
I use this machine most of the time without KVM - and it crashed when I
started KVM - so I assume that KVM had something to do with it. Perhaps it
corrupts random memory? I may try to run some KVM stress for many days to
test if I reproduce it.
Mikulas
_______________________________________________
kvmarm mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
