On 31/03/16 19:30, Christoffer Dall wrote: > On Fri, Mar 25, 2016 at 02:04:23AM +0000, Andre Przywara wrote: >> This series is a joint effort to re-implement KVM's GIC emulation. >> >> While the current implementation is centered around providing >> efficient MMIO emulation, the hot path for most guests is actually >> the guest entry and exit, which currently is rather costly. >> Also the existing emulation has a global distributor lock, which >> quickly becomes a bottleneck once the number of VCPUs increases. >> Additionally the emulation was originally designed for GICv2, adding >> GICv3 ITS emulation support to this proved to be rather painful. >> Last, but not least the existing code became less and less >> maintainable, with many special cases handled explicitly. >> >> The new implementation is build around a struct vgic_irq data data >> structure, which holds all information about a virtual interrupt. >> Interruts which should be injected are hold in a per-VCPU list, this >> make the entry/exit path much more efficient. Also the new structure >> allows to have more fine grained locking - per IRQ and per VCPU - >> getting rid of the global distributor lock. >> As a result of the new design ITS emulation fits in more nicely, the >> respective code will be provided as a follow-up series. >> >> This series implements the same feature set as the existing emulation, >> as a goodie we now implement priorities correctly. >> To allow an easy transition with good test coverage, but still maintain >> stability, both implementations live side by side, selectable via a >> Kconfig option. The default is the new implementation. >> If this code proves to be reliable, we will later remove the current >> implementation with an extra patch set. >> >> Please have a look at the series, review it and give the code some >> serious testing (and possibly debugging). All feedback is appreciated. >> > > Hmph, starting a guest a couple of times and running hackbench inside > the guest actually gave me (twice) the following error: > > NMI watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/0:0:4] On the host or in the guest? Can you reproduce it easily? If yes, can you add some lock debugging to see if we are stuck in a spinlock? Cheers, Andre. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
