> On 15 Jun 2020, at 22:32, Stefano Stabellini <sstabell...@kernel.org> wrote:
>
> On Mon, 15 Jun 2020, CodeWiz2280 wrote:
>> On Wed, Jun 10, 2020 at 5:46 PM Julien Grall <julien.grall....@gmail.com>
>> wrote:
>>>
>>> Hi Marc,
>>>
>>> On Tue, 9 Jun 2020 at 18:45, Marc Zyngier <m...@kernel.org> 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
