Re: [TF-A] 1023 spurious interrupt - TF-A

3 Feb 2021

      Hi,
Stepping back to the initial thread, I now miss the rationale for routing interrupts to EL3.
"I have successfully implement a Linux driver that allows me to dump kernel page tables and memory; however, I cannot see user page tables (even after running a CPU intensive program ).  I believe the only way to view user page tables is to have interrupts routed to EL3 – a Linux driver is not sufficient."
If your intent is to dump user process page tables, that's something to do using the linux kernel mm framework, and not necessarily at EL3. Not sure why a "linux driver is not sufficient". More inputs on this may be beneficial.
Nevertheless if you need a service in EL3 to do "introspection", you would rather write a form of SiP service accessed through SMC (not necessarily routing interrupts through FIQ).
As for the code snippets, replacing vbar_el3 with your own vector table looks wrong.
This will break any service call back into EL3 when linux is booted (e.g. PSCI calls....)
If you really want to route interrupts to EL3 you shall use the Interrupt Handling Framework as Manish suggested.
e.g.
uint64_t fiq_handler(uint32_t id, uint32_t flags, void *handle, void *cookie)
{
    [...]
    return 0;
}
void register_my_interrupt(void)
{
    int32_t rc, flags = 0;
plat_ic_set_interrupt_type(intid, INTR_TYPE_EL3);
    set_interrupt_rm_flag(flags, NON_SECURE);
    rc = register_interrupt_type_handler(INTR_TYPE_EL3, fiq_handler, flags);
    NOTICE("register_interrupt_type_handler %d\n", rc);
}
Regards,
Olivier.
________________________________________
From: TF-A tf-a-bounces@lists.trustedfirmware.org on behalf of AT&T via TF-A tf-a@lists.trustedfirmware.org
Sent: 03 February 2021 02:15
To: tf-a@lists.trustedfirmware.org
Subject: Re: [TF-A] 1023 spurious interrupt
Yep, I had an O not a zero.  Don’t see a difference yet, but that definitely needed to be fixed. Thank you.
Ian Burres
Cybersecurity R&D
...
On Feb 2, 2021, at 3:53 PM, tf-a-request@lists.trustedfirmware.org wrote:
Send TF-A mailing list submissions to
   tf-a@lists.trustedfirmware.org
To subscribe or unsubscribe via the World Wide Web, visit
   https://lists.trustedfirmware.org/mailman/listinfo/tf-a
or, via email, send a message with subject or body 'help' to
   tf-a-request@lists.trustedfirmware.org
You can reach the person managing the list at
   tf-a-owner@lists.trustedfirmware.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of TF-A digest..."
Today's Topics:

Re: Spurious interrupt 1023 (Ian Burres)
Re: Spurious interrupt 1023 (Manish Pandey2)

Message: 1
Date: Tue, 2 Feb 2021 14:03:05 -0700
From: Ian Burres iburres@att.net
To: Olivier Deprez Olivier.Deprez@arm.com,
   "tf-a@lists.trustedfirmware.org" tf-a@lists.trustedfirmware.org
Subject: Re: [TF-A] Spurious interrupt 1023
Message-ID: 20210202210320.2C48741B32@lists.trustedfirmware.org
Content-Type: text/plain; charset="utf-8"
UPDATE:   I managed to get the Pi to complete the boot process, which is a major hurdle I have been trying to overcome.
As for your questions Olivier:
The vector table is loaded during bl31 (its called in the bl31_main.c  main() function, right after bl31_platform_setup()).   The Pi 4B uses GICv2 (your assumption was correct) and the BCM2711 chip.
Right now both my irq and fiq handlers use:    ID = gicv2_get_pending_interrupt_id();  to read the INTID.
Neither handler does anything else other than print the ID, which returns 1023 for fiq only, using HS_DEBUG().  Nothing returns for irq.
Build options are:  PLAT=rpi4 DEBUG=1 LOG_LEVEL=50 RUNTIME_UART=2 GICV2_GO_FOR_EL3=1
Wasn’t trying to route the UART RX interrupt to EL3, though that’s not a bad idea (FIFO, right?) .   However, I have been exploring the idea of generating an ARM timer interrupt (not system timer), but I couldn’t get past the boot issue, which seems to have now been resolved.
Questions:  Do you see any reason why loading the vector table during the boot process will prevent interrupts from being routed to EL3 correctly?  If you do not, then I think I can take it from here.
Sent from Mail for Windows 10
From: Olivier Deprez
Sent: Monday, February 1, 2021 2:36 AM
To: tf-a@lists.trustedfirmware.org; AT&T
Subject: Re: [TF-A] Spurious interrupt 1023
Hi Ian,
I guess we'll need a bit more details in order to help you.
Which platform are you using? which GIC version is it using (looks like GICv2?) ?
How did you built TF-A for this platform (command line arguments)?
What is executing on your platform (e.g. linux in the non-secure world)? Is there any component in the SWd (apart from EL3 monitor) like a TEE?
Are you trying to route the UART RX interrupt to EL3?
Is this UART instance only owned by the SWd?
How did you setup the interrupt handler?
Which function are you using to read the INTID?
Regards,
Olivier.

From: TF-A tf-a-bounces@lists.trustedfirmware.org on behalf of AT&T via TF-A tf-a@lists.trustedfirmware.org
Sent: 29 January 2021 21:08
To: tf-a@lists.trustedfirmware.org
Subject: [TF-A] Spurious interrupt 1023
I asked a similar question before, but I have since made some headway concerning routing fiq interrupts to EL3.  I placed an HS_DEBUG command to print the ID, which returns 1023.  The RX signal on one of the attached UARTs causes a solid red light and the debug message continuously loops. When I use the functions from gicv2.h, I receive an assertion error regarding MAX_SPI_ID, but the looping stops.
I think the 1023 ID suggests non-secure is receiving a secure interrupt OR I’m dealing with a possible race condition. Any thoughts? Should I attach my code?
Ian Burres
Cybersecurity R&D
--
TF-A mailing list
TF-A@lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a