On Mon, Jun 25, 2018 at 12:13:47PM +0200, Christoffer Dall wrote: > On Mon, Jun 25, 2018 at 10:52:41AM +0100, Peter Maydell wrote: > > On 24 June 2018 at 23:10, Christoffer Dall <christoffer.dall@xxxxxxx> wrote: > > > This small series addresses a peculiarity of the current VGIC > > > implementation, namely that we don't support interrupt grouping. > > > > > > KVM either implements a GICv2 without support for the security > > > extensions, or a GICv3 with DS=1. For GICv2, on systems without the > > > security extensions, group 0 interrupts can be configured to be either > > > signalled as FIQs or as IRQs by the VM, whereas group 1 interrupts are > > > always IRQs. For GICv3, with DS=1, group 1 interrupts are always IRQs > > > and group 0 interrupts are always FIQs, and there is no concept of > > > secure vs. non-secure group 1 interrupts when DS=1. > > > > > > We were treating all interrupts on GICv2 as group 0, but yet telling the > > > geust that they were group 1. The first patch changes this behavior, > > > which seems to have no effect on no known guests, but still. > > > > > > The remaining patches introduce proper interrupt grouping support, along > > > with MMIO accessors for the VM and userspace to retrieve and set the > > > which group SGIs, PPIs, and SPIs belong to. LPIs are always group 1 > > > interrupts as per the architecture, and there is no way to modify this > > > configuration (no IGROUPR registers for LPIs or equivalent ITS > > > commands). > > > > How do we handle migration compatibility here? For instance if > > we have a guest running on an old kernel with GICv2, presumably > > it reports the GICD_IGROUPRn to userspace as being all-1 (but > > they behave as group 0); then when we load on the new kernel > > the new kernel will honour the IGROUPRn values and the interrupts > > will start behaving like group 1 ? Maybe this works because the > > guest is expecting them to be signalled as IRQ either way... > > > > Interesting. For GICv2, I think this will actually break, and the > migrated Linux guest won't see any interrupts anymore (Linux only sets > bit 0 in GICD_CTLR). For GICv3, everything stays group 1 unless the > guest is specifically trying to configure group 0 for something. > > I suppose this means we need to let userspace request > ARCH_COMPLIANT_GICV2 and otherwise ignore userspace writes to IGROUPR? > Alternatively, we could deny (fail) migration where the GICD_IIDR.Revision does not match the source, and just let userspace fix things up. Thoughts? Thanks, -Christoffer _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
