On 5 July 2016 at 09:59, Andre Przywara <andre.przywara@xxxxxxx> wrote: > Ah, OK, so you _do_ the address setup _after_ the INIT. > My understanding of the KVM API was that this isn't allowed, as with the > INIT _everything_ should have been setup. kvmtool works this way. > > So we obviously can't change this for GICv3, but I wonder if we should > make this explicit with the ITS: > 1) Create the device > 2) setup _all_ parameters (address, number of ...) > 3) call INIT, any setup calls from here on are denied > > That sounds like the proper setup sequence to me. So we shouldn't necessarily let QEMU drive the kernel API design here, but: (1) consistency with GICv2-with-explicit-init and GICv3 seems worth preserving (2) there is a coherent model here which maps onto QEMU's device model: (i) create device (ii) configure device (iii) explicitly finish init of device (in QEMU's object model this is called "realize") (iv) wire completed device into the system, by plugging in its IRQs, mapping its memory regions into the address space, etc (v) at this point it is ok to either read/write registers or to start vcpus Which I think is why "set register base addresses" looks like an odd-one-out from the kernel's point of view. So I think for the ITS we should continue to do the same thing we do for GICv2 and v3 (but not the GICv2 "explicit completion of init is optional" part). I'd forgotten exactly how this worked; sorry for any confusion in my earlier email. thanks -- PMM -- 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
