On Fri, 29 Jun 2018 10:28:16 +0100, Christoffer Dall <christoffer.dall@xxxxxxx> wrote: > > On Fri, Jun 29, 2018 at 10:11:27AM +0100, Marc Zyngier wrote: > > 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: > > > > 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. > > > > The problem with that is that upgrading the kernel (but not QEMU) on > your destination machine now breaks migration. Is that acceptable? Each time we add a new sysreg, we do break migration as well (in the other direction though), and I'm not sure we can do much about it (that's a QEMU policy, and not the kernel's). What we could do is to allow IIDR to be written from userspace, and pick one behaviour or the other. This would allow compatibility in the forward direction, at least, and we have the ITS as a precedent for this behaviour. Thanks, M. -- Jazz is not dead, it just smell funny. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
