On Sat, 13 Oct 2018, Marc Zyngier wrote: > On Fri, 12 Oct 2018 19:59:16 +0100, > Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote: > > > > > > > > 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. > > One thing I know for sure is that if you use a tap (such as macvtap) I don't have macvtap compiled. The board is also used as a router and the virtual machine bridge uses the same routing tables and iptables rules as anything else. > to give networking to your VMs, the Ethernet driver on the 8040 (such > as on your MacchiatoBin) will happily corrupt memory (you can witness > that without running KVM at all). Something to do with the sbk being > freed early. > > I've reported this issue several times, only to hear the wind > blowing. At this stage, I've shelved it. There is enough decent and > maintained platforms around not to worry about the unmaintained stuff. > > Now, if you can give me a reproducer, I'll happily investigate. I haven't reproduced it so far :-( > Thanks, > > M. Mikulas _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
