On Mon, 25 Jun 2018 12:56:03 +0100, Christoffer Dall <christoffer.dall@xxxxxxx> wrote: > > 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? That's exactly the kind of thing I had in mind when I suggested to bump up the IIDR. It allows us to push the knowledge of the quirks to both the guest and userspace, instead of adding more esoteric API features. Thanks, M. -- Jazz is not dead, it just smell funny. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
