[Question] How to testing SDEI client driver

[James Morse]

Hi Gavin,

On 30/06/2020 06:17, Gavin Shan wrote:
> I'm currently looking into SDEI client driver and reworking on it so that
> it can provide capability/services to arm64/kvm to get it virtualized.

What do you mean by virtualised? The expectation is the VMM would implement the 'firmware'
side of this. 'events' are most likely to come from the VMM, and having to handshake with
the kernel to work out if the event you want to inject is registered and enabled is
over-complicated. Supporting it in the VMM means you can notify a different vCPU if that
is appropriate, or take a different action if the event isn't registered.

This was all blocked on finding a future-proof way for tools like Qemu to consume
reference code from ATF.


> The
> primary reason is we want to use SDEI to deliver the asynchronous page fault
> notification from host to guest.

As an NMI?! Yuck!
The SDEI handler reads memory, you'd need to stop it being re-entrant. It exits through
the IRQ vector, (which is necessary for forward-progress given a synchronous RAS event,
and for KVM to trigger guest-exit before the 'real' work that is offloaded to an irq
handler can run), its going to be 'fun' to have any guarantee of forward-progress if this
is involved with stage2.


> The code of rework on SDEI client driver, including some cleanup,

Cleanup is always welcome.


> is almost
> done. Currently, I have issues on how to test/verify the client driver.

...

> Any suggestions regarding this are appreciated.

> It seems that TRF (Trusted Firmware) is the only firmware with SDEI service
> implemented and supported.

This project calls itself TF-A. ATF is the other widely used name. (I've never seen TRF
before)


> If so, does it mean I need to install TRF on my bare metal machine? 
> I'm wandering how it can be installed and not sure if
> there is any document about this.

Firmware should come with the platform. You'd need to know intricate details about power
management and initialising parts of the SoC to port it.

ATF has a port for the fast-model/foundation model. I test this with ATF in the fast-model.


> Besides, GHES seems the only user of SDEI in the linux kernel. If so, is
> there a way to inject the relevant errors and how?

It is, and unfortunately last time I checked, upstream ATF doesn't have the firmware-first
stuff for this. Its too SoC specific.

I test this by binding the fast-model's SP804 one-shot interrupt controller as an event,
then plumbing that into GHES. Its more of case-study in why the bindable-irq stuff is
nasty than usable error injection method.
I can push the most recently rebased version of this, but you'd also need to hack-up a
HEST table with GHES entries to actually get it running.


But, unless you are working on EL3 firmare, or a VMM, I don't think SDEI is what you want.
What problem are you trying to solve?


Thanks,

James