Change Details

I have EL3 type interrupt handler which does simple staff (log, print), and at the end of the interrupt handler, SDEI dispatch registered event. I observe userspace process DataAbort exception in the next scenario: Userspace process passes control to the kernel via write into sysfs The kernel does SMC to ATF In the middle of SMC handling while in ATF, interrupt was raised EL3 type interrupt The interrupt handler finished normally and SDEI dispatch was finished normally too. SDEI transfer control as usual to kernel and back. After interrupt handled SMC resumed and finished and return control back to the kernel module. Kernel module did all remained work and finished. Userspace process gets control back into libc and I observe MMU data abort exception. If SDEI dispatch commented out from handler the issue disappear. If SDEI dispatch did not execute at handler but just instruct to be executed later in time via timer issue invisible. I suppose that it can be expected behavior, but because of a lack of expertise, I would like to ask. Thanks for advance.

I have EL3 type IRQ and interrupt handler which does simple staff (log, print), and at the end of the interrupt handler, SDEI dispatch registered event. I observe userspace process DataAbort exception in the next scenario: Userspace process passes control to the kernel via write into sysfs The kernel does SMC to ATF (SMC is SMC_TYPE_FAST) In the middle of SMC handling while in ATF, an interrupt was raised. The interrupt handler finished normally and SDEI dispatch was finished normally too. SDEI transfer control as usual to kernel and back ATF. Interrupted SMC resumed and finished and return control back to the kernel module. Kernel module did all remained work and finished. Userspace process gets control back into libc and I observe MMU data abort exception. It seems like the preserved context was corrupted. I suppose that dispatch SDEI from interrupted SMC context provokes data corruption. SDEI dispatch has normal priority. SMC is a fast type. From the documentation, I understand that yield SMC type can be interrupted by non-secure IRQ and the special handling required. In this test case: EL3 IRQ and fast SMC. If SDEI dispatch commented out from handler the issue disappear. If SDEI dispatch did not execute at handler but just instruct to be executed later in time via timer issue invisible. I suppose that it can be expected behavior, but because of a lack of expertise, I would like to ask. Thanks for advance.

I have EL3 type IRQ and interrupt handler which does simple staff (log, print), and at the end of the interrupt handler, SDEI dispatch registered event. I observe userspace process DataAbort exception in the next scenario: Userspace process passes control to the kernel via write into sysfs The kernel does SMC to ATF (SMC is SMC_TYPE_FAST) In the middle of SMC handling while in ATF, an interrupt was raised EL3 type interrupt. The interrupt handler finished normally and SDEI dispatch was finished normally too. SDEI transfer control as usual to kernel and back ATF. After iInterrupt handleded SMC resumed and finished and return control back to the kernel module. Kernel module did all remained work and finished. Userspace process gets control back into libc and I observe MMU data abort exception. It seems like the preserved context was corrupted. I suppose that dispatch SDEI from interrupted SMC context provokes data corruption. SDEI dispatch has normal priority. SMC is a fast type. From the documentation, I understand that yield SMC type can be interrupted by non-secure IRQ and the special handling required. In this test case: EL3 IRQ and fast SMC. If SDEI dispatch commented out from handler the issue disappear. If SDEI dispatch did not execute at handler but just instruct to be executed later in time via timer issue invisible. I suppose that it can be expected behavior, but because of a lack of expertise, I would like to ask. Thanks for advance.