Hi, 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 <p.fe...@samsung.com> 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 > > >
