On 4 July 2016 at 15:27, Auger Eric <eric.auger@xxxxxxxxxx> wrote: > Andre, > > On 04/07/2016 16:05, Andre Przywara wrote: >> Hi, >> >> On 04/07/16 10:00, Auger Eric wrote: >>> From a QEMU integration point of view this means the init sequence used >>> for KVM GIC interrupt controllers cannot be reused for ITS and more >>> importantly this is not straightforward to have the proper sequence >>> ordering (hence the previously reported case). >> >> I am confused, can you please elaborate what the problem is? >> Or alternatively sketch what you ideally would the ITS init sequence to >> look like? I am totally open to any changes, just need to know what >> you/QEMU needs. > > in QEMU the address setting is done on a so-called qemu > "machine_init_done_notifier", ie. a callback that is registered at ITS > device init, to be called once the virt machine code has executed. This > callback calls kvm_device_ioctl(kd->dev_fd, KVM_SET_DEVICE_ATTR, attr); > > In case the userspace needs to explicitly "init" the ITS (actually ~ > map_resources) this must happen after the KVM_SET_DEVICE_ATTR. So you > also must register a callback in the same way. However there is a > framework existing to register kvm device addresses but this does not > exist to set other attributes than device addresses. > > This is feasible I think but this does not fit qemu nicely. So can't the > map_resources happen implicitly on the first VCPU run? I'm not clear what you think the problem here for QEMU is. We definitely want the API for the kernel to be: create device set attributes explicitly complete init of the device [attribute setting after this is illegal] run CPUs so I'm not sure why QEMU would care if the kernel does things at "final init" rather than "run CPUs". This is how the GICv3 init works and how the ITS should work too; we don't want to extend the GICv2 mistake of "no explicit complete init" to anything else, because then you end up with ad-hoc "do this when we first run the vCPU; oh, but also do it if userspace tries to write a register content; and also if...". 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
