[PATCH v7 10/17] KVM: arm64: introduce new KVM ITS device

[Peter Maydell]

On 5 July 2016 at 09:59, Andre Przywara <andre.przywara at arm.com> 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