[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Keystone Issue



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...



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.