Re: Keystone Issue

[Bertrand Marquis <Bertrand.Marquis@xxxxxxx>]

> On 15 Jun 2020, at 22:32, Stefano Stabellini <sstabellini@xxxxxxxxxx> wrote:
> 
> On Mon, 15 Jun 2020, CodeWiz2280 wrote:
>> On Wed, Jun 10, 2020 at 5:46 PM Julien Grall <julien.grall.oss@xxxxxxxxx> 
>> wrote:
>>> 
>>> Hi Marc,
>>> 
>>> On Tue, 9 Jun 2020 at 18:45, Marc Zyngier <maz@xxxxxxxxxx> wrote:
>>>>> I was wondering if you heard about any potential issue with guest EOI
>>>>> not forwarded to the host. This is on TI Keystone (Cortex A-15).
>>>> 
>>>> Not that I know of. A-15 definitely works (TC2, Tegra-K1, Calxeda Midway
>>>> all run just fine with guest EOI), and GIC-400 is a pretty solid piece
>>>> of kit (it is just sloooooow...).
>>>> 
>>>> Thinking of it, you would see something like that if the GIC was seeing
>>>> the writes coming from the guest as secure instead of NS (cue the early
>>>> firmware on XGene that exposed the wrong side of GIC-400).
>>> 
>>> Ah, I remember that one.  We used to carry an hack in Xen [1] for
>>> X-Gene. Thankfully they fixed the firmware!
>>> 
>>> If it is a similar issue, then the firmware path would definitely be
>>> my preference.
>>> 
>>> Thank you for the input!
>> 
>> Thank you all for the information.  If I pull the changes to use the
>> maintenance interrupt for the X-Gene back into the latest build of Xen
>> then my issue with the Edge and Level interrupts is resolved.  My
>> ethernet and other devices work fine again for the Keystone in dom0.
>> Are there any concerns over operating this way, meaning with the
>> maintenance interrupt workaround rather than the EOI?  Is this safe?
> 
> It should be fine, a small impact on performance, that's all.

Agree, this is safe but you will have an overhead (one context switch back to 
Xen on interrupt ack in Dom0 in your case).

> 
> 
>> Also, the latest linux kernel still has the X-Gene storm distributor
>> address as "0x78010000" in the device tree, which is what the Xen code
>> considers a match with the old firmware.  What were the addresses for
>> the device tree supposed to be changed to?  Is my understanding
>> correct that there is a different base address required to access the
>> "non-secure" region instead of the "secure" 0x78010000 region?  I'm
>> trying to see if there are corresponding different addresses for the
>> keystone K2E, but haven't found them yet in the manuals.
> 
> I went through the old emails archive but couldn't find a mention of the
> other address, sorry.

I think there is no other address as even though there would be one the Secure 
status reported by the core would still say that you are running in secure mode.
I would really suggest to try to contact directly TI on that part to get an 
official answer from them as they might have a workaround.

Cheers
Bertrand