powerpc: Implement RTAS event log support

[ivy]

Summary

The IBM Run-Time Abstract Services (RTAS) provides support for an
event log that allows the OS to receive hardware and firmware events.

Two types of event log are provided: a general log that needs to be
scanned at regular intervals (typically once per second), and an
exception log which is interrupt-triggered. Handle the log scan in
rtasdev itself. For the exception logs, add a new rtas_esrc driver
which attaches to each event source.

For most event types, we just log the event. For shutdown request
events, call shutdown_nice(RB_POWEROFF), which allows pSeries VM
shutdown requests to work.

This implementation is based on "Linux on Power Architecture Reference"
revision 2.9 (August 12, 2020).

MFC after: 2 weeks

[ivy]

fix big-endian systems

also, remove some dead code

[adrian]

sys/powerpc/include/rtas.h

133

is "unsigned" guaranteed to always be a byte here?

[ivy]

use uint8_t for bitfields

i'm not sure how much difference it makes in practice, but since we're treating
these fields as individual bytes anyway, it's probably more correct.

[jhibbits]

sys/powerpc/pseries/rtas_dev.c

591–594

Do you expect to need to extend this in the future, adding other event type handling? If so, maybe consider a jump table struct, or a switch here, to make it easier.

Also, that buffer pointer math looks error prone, so consider simplifying that. You could simply pass the whole buffer down instead, and use a union to get the vendor data you need.

672

Is the EPOW shutdown request a request, or an order? Unless this is the hypervisor saying that the partition will be shut down, I think this could instead be propagated up to devd (devctl_notify()) to let the user decide how to handle it, and add an entry to devd.conf (or, better yet, create a pseries devd.conf) to default to shutdown.

[ivy]

sys/powerpc/pseries/rtas_dev.c

591–594

the only other one i think we definitely want to handle is hotplug events, but i'm not planning on looking at that any time soon. so a jump table is probably over kill, but i'll try a switch and see if it looks nicer.

672

it depends on the type/reason code, but i think in all cases, the user will want to shut down here:

• if the user interacted with the power button or the BMC, they obviously want the system to shut down
• if a temperature threshold is exceeded or the UPS requested a shutdown, we are going to turn off anyway (because either the hardware is about to melt or the UPS battery is about to run out), so we should do it cleanly
• if the VM host is shutting down / rebooting, we are going to turn off anyway, so as above

i'm not opposed to making this a devd event, but i don't think any other architecture works that way, and we'd want to make sure the event was at least roughly portable between platforms, so it's probably out of scope for this diff.

incidentally, OPAL does this the same way, see sys/powerpc/powernv/opal_dev.c:opal_handle_shutdown_message().

cc: @imp

[jhibbits]

sys/powerpc/pseries/rtas_dev.c

672

OPAL does it this way because the message is reporting that the machine is going down shortly, there's no way to stop it. The only safe thing to do in that case is to shutdown from the kernel, and hope that it cleans up before power is removed.

[ivy]

rf

re: pointer arithmetic, i have a better idea of how to do this, but let's
see if this is a better way to handle shutdown in the mean time.

[ivy]

improve buffer handling

instead of parsing the buffer in rtas_handle_epow(), add a new function
to find a section by ID within the buffer. check the entire log event
fits within the buffer before doing anything else.

also, stylise and fix some endianness confusion in the platform structs.

[ivy]

remove an unused prototype

[adrian]

ship it, thanks!

[adrian]

sys/powerpc/pseries/rtas_dev.c

573

as mentioned on irc, yeah, you likely can just put this whole chunk into a task and schedule it on the existing taskqueue (which if I'm not mistaken is the global taskqueue.)

577

ok, so it looks like you're using contigmalloc, vtophys, cpu_flush_dcache, etc instead of using busdma to do all of this.
Which I'm ok with for now, but it really should be using busdma in the future (and you can do that in a subsequent commit. I'm a big believer in iterating on working code in tree, rather than waiting for something perfect. :-) )

Since you're not allocating temporary memory/mapping via busdma, I think you should also add a comment in the softc definition above that the memory is pre-allocated /only/ for handling the interrupt notification and must not be used for anything else, nor overlapping calls to this task/function.

581

What's "6" and "1" here? it looks like this driver is full of them, so it would be nice for a follow-up commit turning them into define'd values with some description about what they are (my guess is '6' here is the method id.)

I currently have no idea where to go look to find the method ids, so a link to a PDF and section in the PDF would be good too.
(but again, in a follow-up commit.)

[ivy]

sys/powerpc/pseries/rtas_dev.c

581

this is the standard Open Firmware calling convention: you pass the function to call, the number of inputs and outputs, and then the input and output values. RTAS is only slightly different because you have to do a token lookup first rather than just passing the function name (see line 426), which is what sc_token is.