Hello!
> This patch includes a placeholder code for future spi and its
> implementation.
Forgot to comment on this. I see that here you are building an ITS into GIC as
a monolithic thing. This can be wrong because we
could want to emulate platforms which have GICv3 but don't have ITS. I would
Hello!
> I just added a placeholder, I didn't add any functionality.
I see. Just wanted to say, that if we accept my proposal (implementing ITS as
a separate object), then the only thing we would do with this placeholder is to
remove it. It should go then to something like hw/intc/arm_gicv3_i
On Wednesday, October 21, 2015, Pavel Fedin wrote:
> Hello!
>
> > I just added a placeholder, I didn't add any functionality.
>
> I see. Just wanted to say, that if we accept my proposal (implementing
> ITS as a separate object), then the only thing we would do with this
> placeholder is to rem
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
Hello!
> For QEMU we could in theory do either; I was leaning towards
> direct connection just because on the KVM side the in-kernel
> GIC isn't going to separate them out as two distinct things.
I'd say this is not entirely true. With KVM you still can have vGIC without
vITS. Just don't set K
Hi,
I just added a placeholder, I didn't add any functionality.
On Wednesday, October 21, 2015, Pavel Fedin wrote:
> Hello!
>
> > This patch includes a placeholder code for future spi and its
> > implementation.
>
> Forgot to comment on this. I see that here you are building an ITS into
> GIC
On 21 October 2015 at 15:41, Pavel Fedin wrote:
> Hello!
>
>> I just wanted to understand. I don't have any preferences.
>
> In other words, in short: spec says that ITS is optional, so
> we can implement it as a separate component, which gets attached
> to the GIC using some specified interface
Hello!
> I just wanted to understand. I don't have any preferences.
In other words, in short: spec says that ITS is optional, so we can implement
it as a separate component, which gets attached to the GIC using some specified
interface. It's not a problem to design such an interface. Actually
I just wanted to understand. I don't have any preferences.
On Wednesday, October 21, 2015, Pavel Fedin wrote:
> Hello!
>
> > 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 dei
Hello!
> 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
> diffe
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
From: Shlomo Pongratz
This patch includes a placeholder code for future spi and its
implementation.
Signed-off-by: Shlomo Pongratz
---
hw/intc/Makefile.objs | 1 +
hw/intc/arm_gicv3_spi_its.c | 359
hw/intc/arm_gicv3_spi_its.h | 11 ++
3 fi
12 matches
Mail list logo
