Re: Keystone Issue

[Julien Grall <julien@xxxxxxx>]

On 10/06/2020 13:39, CodeWiz2280 wrote:
> > > > So the only way to solve this is actually to do the interrupt
> > > > deactivate inside Xen (using a maintenance interrupt).
> > > That's a terrible hack, and one that would encourage badly integrated HW.
> > > I appreciate the need to "make things work", but I'd be wary of putting
> > > this in released SW. Broken HW must die. I have written more than my share
> > > of these terrible hacks (see TX1 support), and I deeply regret it, as
> > > it has only given Si vendors an excuse not to fix things.
> > Fully agree and I also had to do some hacks for the TX1 ;-)
> >
> > > > I remember that I also had to do something specific for the
> > > > configuration of edge/level and priorities to have an almost proper
> > > > behaviour.
> > > Well, the moment the GIC observes secure accesses when they should be
> > > non-secure, all bets are off and you have to resort to the above hacks.
> > > The fun part is that if you have secure SW running on this platform,
> > > you can probably DoS it from non-secure. It's good, isn't it?
> > Definitely is but if I remember correctly they have 2 kind of SoC: one that can 
> > be only used in non-secure and an other which is meant to be use with secure 
> > and non secure.
> >
> > Bertrand
> >
> > > > Sadly I have no access to the code anymore, so I would need to guess
> > > > back what that was..
> > > I'd say this *is* a good thing.
> 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.
OOI, what's your end goal for Xen on Keystone?

Cheers,

--
Julien Grall