[RFC PATCH 00/45] KVM: arm/arm64: Rework virtual GIC emulation

[christoffer.dall@linaro.org (Christoffer Dall)]

On Wed, Apr 13, 2016 at 05:07:56PM +0100, Andr? Przywara wrote:
> 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?

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?
> 

I'll do this when you've posted a new version. Sound ok?

-Christoffer