[PATCH V4] powerpc, powernv: Add OPAL platform event driver

[Vipin K Parashar]

Hi Stewart,
          I looked into ACPI and found details about it. But before we 
go into
discussing more details of it, would like to  share a brief about OPAL 
platform
events (EPOW/DPO) work and original design proposed.

As if now OPAL platform events work supports two events:
EPOW (Early Power Off Warning) and DPO (Delayed Power Off).

On FSP based systems FSP notifies OPAL about EPOW and DPO events via mbox
mechanism. Subsequently OPAL sends notifications for these events to 
pkvm kernel.
Original design is to have a kernel driver maintain a queue and add 
these events
to queue upon arrival. pkvm driver also provides a character device for 
host to consume
these events. A daemon is proposed for pkvm host to poll/read these 
events from
char device. This daemon would process these events and take action to log
and shutdown host. Apart from this it would also send these event info 
to VMs
which is handled by OSes running on VMs. Linux on VMs already has code 
in place
to handle these events as it expects this info to reach it in PAPR 
format under
EPOW (Environmental and Power Warnings) category.

EPOW mbox msgs are received for below events:
1. UPS events - UPS Battery Low, UPS Bypassed, UPS Utility Failure, UPS On
2. SPCN events - Configuration Change, Log SPCN Fault, Impending Power 
Failure, Power Incomplete
3. Temprature events - Over Ambient temperature, Over internal temperature.

Now ACPI:

Looked into ACPI and tried to figure out how ACPI userspace/kernel 
framework
can be helpful for our work.

ACPI user space consists of below components.
acpid - ACPI daemon to receive events from kernel
acpid provides events and actions files in /etc/acpi dir to configure 
actions
for various events.

acpi, acpi_listen, acpitool - Commands to query and set various ACPI 
supported parameters.
These tools work with various sysfs files to show/set various parameter 
values.

As if today acpid and other tools don't exist for POWER so would need to 
be ported.
acpid is useful for our work but other tools might not be helpful as 
they look into
various sysfs files created by various ACPI kernel drivers which we 
won't have.
Also we would need to map our EPOW/DPO events to acpid supported events
and few events link SPCN ones won't map straight away and might need to be
added in acpid as new events.

ACPI in kernel has various drivers for fan, battery, laptop buttons etc. 
They handle events
and uses netlink mechanism to sent out these events to userspace. Now 
looking into ACPI
code it seems that we would be reusing a small chunk of acpi code but 
instead end up adding
unnecessary complexity due to support a lot of stuff than needed by us. 
Here too mapping our
  EPOW/DPO events to ACPI defined structures in needed and we would need 
to add
new member varaibles in ACPI event structures for unmapped events like 
SPCN ones.

In nutshell it seems that by using ACPI we would end up adding lot more 
complexity with a little
gain of code reuse.

Netlink:

On technology side netlink seems to be a faster method compared to 
character driver. So that could be
a good alternative to use as a method of communication between our pkvm 
driver and userspace.
But EPOW/DPO events occur at very low rate unlike network subsystem 
which receive data packets
at a very high rate. So probably netlink could be a faster method but 
due to slow EPOW/DPO event
traffic a character driver might be sufficient.

We already have ppc64-diag package which is part of various distros so 
would be used for hosting
daemon code. Thus it takes off overhead of convincing distros for adding 
something extra.

This was my findings and opinions on alternatives. Apologies for a 
little lengthy text :-)

Let me know if i missed out anything and any suggestions that you would 
have.

Regards,
Vipin

On 02/11/2015 10:32 AM, Stewart Smith wrote:
> Vipin K Parashar <vipin at linux.vnet.ibm.com> writes:
>> 	(1) Environmental and Power Warning (EPOW)
>> 	(2) Delayed Power Off (DPO)
>> The user interface for this driver is /dev/opal_event character
>> device file where the user space clients can poll and read for
>> new opal platform events. The expected sequence of events driven
>> from user space should be like the following.
>>
>> 	(1) Open the character device file
>> 	(2) Poll on the file for POLLIN event
>> 	(3) When unblocked, must attempt to read OPAL_PLAT_EVENT_MAX_SIZE size
>> 	(4) Kernel driver will pass at most one opal_plat_event structure
>> 	(5) Poll again for more new events
> A few thoughts from discussing with Michael and Joel:
> - not convinced that a chardev is the most ideal way to notify
>    userspace. It seems like yet-another powerpc specific notification
>    mechanism, which isn't ideal.
> - netlink probably isn't right either (although maybe *sligthtly*
>    better?)
> - it seems that the "standard" way is ACPI, so I wonder if we could emit
>    an ACPI event and essentially fake having ACPI... that would make all
>    existing userspace "just work", right?
>    Looking at acpi_bus_generate_netlink_event call in
>    drivers/acpi/button.c it looks possible that we may be able to
>    (relatively simply) do that?
> - What do UPSs do? It would seem that some common "this is what's about
>    to happen to your power" would almost *have* to exist somewhat
>    generically?
>
> I strongly advocate for anything that doesn't require custom userspace
> that's OPAL/POWER specific (that we then have to get into distros etc etc)
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev