On Fri, Oct 19, 2018 at 15:29:32 -0400, Emilio G. Cota wrote: > On Fri, Oct 19, 2018 at 18:01:18 +0200, Paolo Bonzini wrote: > > > Given that we need a per-CPU lock anyway to remove the BQL from the > > > CPU loop, extending this lock to protect cpu->interrupt_request is > > > a simple solution that keeps the current logic and allows for > > > greater scalability. > > > > Sure, I was just curious what the problem was. KVM uses OR+kick with no > > problems. > > I never found exactly where things break. The hangs happen > pretty early when booting a large (-smp > 16) x86_64 Ubuntu guest. > Booting never completes (ssh unresponsive) if I don't have the > console output (I suspect the console output slows things down > enough to hide some races). I only see a few threads busy: > a couple of vCPU threads, and the I/O thread. > > I didn't have time to debug any further, so I moved on > to an alternative approach. > > So it is possible that it was my implementation, and not the approach, > what was at fault :-)
I've just observed a similar hang after adding the "BQL pushdown" patches on top of this series. So it's likely that the hangs come from those patches, and not from the work on cpu->interrupt_request. I just confirmed with the prior series, and removing the pushdown patches fixes the hangs there as well. Thanks, Emilio