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