Re: Keystone Issue

[Marc Zyngier <maz@xxxxxxxxxx>]

On 2020-06-10 13:39, CodeWiz2280 wrote:

[...]

> The problem is that a hack may be my only solution to getting this
> working on this platform.  If TI says that they don't support it then
> i'm stuck.  Just to summarize the problem, we believe that the GIC is
> seeing secure accesses from dom0 when they should be non-secure.  This
Not necessarily just dom0. The hypothesis is that accesses to the GICV
and/or GICD regions from a non-secure guest are treated as secure.
My hunch is that it is only GICV that gets messed with, as you seem
to solve it by writing to GICC.

> is causing the VGIC ack to be non-functional from dom0.   We would
> need a firmware that supports both secure and non-secure accesses.
Not exactly. You'd need the bridge between the CPU and the GIC to honor
NS bit passed on the bus (AXI or otherwise). That is assuming that:
- the NS attribute is actually present on the interconnect
- the HW is configurable
- our "finger in the air" analysis is actually correct

As for the last point, only someone with access to the RTL could
tell you...

> The Xen code gets to "gicv2_guest_irq_end()" where it executes
> "gicv2_eoi_irq()", but then we had to add the deactivate
> "gicv2_dir_irq" to clear the virtual interrupt manually to get things
> going again.
Also known as "priority drop" and "deactivation". You may want to
use architectural terms when explaining this to HW people.

        M.
--
Jazz is not dead. It just smells funny...