Hello,

By default any SError interrupt will halt the kernel.

SErrors may be caused by e.g. writes to read-only device registers or ECC errors.

With this patch SErrors can instead be reported as a VM data fault for the
currently running task. Because SError is asynchronous it is not assured
that the faulting task caused the error.

With ARMv8.2 there is a new RAS feature which solves the SError problem
for common cases: This patch does not use that, our hardware is v8.0,
we need another solution for the SError problem.

We would rather log the SError and continue than halt the whole system.

As SError is easily triggered by device drivers, halting the whole system would make user-space device drivers not much more reliable than in-kernel
ones. I do not know if VMs can also cause SErrors in seL4. However, that
seems likely, in which case guest OSes can also halt the whole system.

One thing I'm not sure about:

SError is edge-triggered, while handleVMFaultEvent() does a MCS_DO_IF_BUDGET check. Does this means that if the current task has no budget, the SError
IRQ will be lost? Or are pending faults saved by the schedule code?

For us missing the SError would be better than halting the kernel, so it
doesn't really matter, but I would like to know.

I have an Atlassian account, but it seems you can't attach patches there, so I'm not sure how else to send this patch, other than creating a Github
account. What is the preferred way to submit patches as an outsider?

Best regards,

Indan
_______________________________________________
Devel mailing list -- devel@sel4.systems
To unsubscribe send an email to devel-leave@sel4.systems

Reply via email to