As far as I understand Figure 1 in GICv3 architecture document the interrupts from device goes to the distributor and from it to the re-distributors or from the deices via the ITS to the re-distributors.
So eventually ITS should be part of the GIC. That is if the ITS is a different entity how do you see it work with the rest of the GIC?
On Wednesday, October 21, 2015, Pavel Fedin <
address@hidden> wrote:
Hello!
>> Or do you have some explicit reasons to have everything as a monolith?
> No I just didn't want to have 3 stub files spi, its and its_control.
> Do you suggest that I'll split it to 3 files?
You didn't understand my question. It's not about internal structure of ITS implementation. It is about GIC and ITS connection.
Please review my KVM ITS RFC: http://lists.nongnu.org/archive/html/qemu-devel/2015-10/msg04613.html. You'll see that ITS is a separate object of a separate class, which can even be omitted at all, if machine model doesn't need it for some reason. So, i suggest that all the ITS code should go there, and it would be a completely separate entity, and a separate patch set, after your GICv3 is accepted. I will help you with this.
Peter, i know you can be very busy, but, could you at least take a glance at my vITS v2 RFC structure and judge us? Should ITS + GICv3 be a monolithic object, or is my suggestion better?
By the way, gicv3_init_irqs_and_mmio() expects only two regions, so it will not even pay attention to your stubs. You could patch it, of course, but... I don't think it's the good thing to do.
Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia