Re: [RFC PATCH V1 v4.10-rc3 1/1] acpi: apei: handle GSIV notification type

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2017/3/2 21:45, Shiju Jose wrote:
Hi James,


Hi Hanjun,

On 01/03/17 08:27, Hanjun Guo wrote:
On 2017/2/28 21:22, James Morse wrote:
On 27/02/17 18:19, Shiju Jose wrote:
Add a new GHES error source handling function for GSIV(Global
System
Interrupt Vector).
If an error source's notification type is GSIV, then this handling
function can be registered into the GSIV handler and it can parse
and report error information when they occur.

I'm missing some of the story here, but how is GSIV different from
'External Interrupt'? I'm guessing something other than the CPU
takes this 'interrupt'...

Yes, it's the same from CPU side (they are interrupts!), but there is
history behind them and the usage is different.

I think External Interrupt was introduced before ACPI is available on
ARM (hardware reduced platforms), so I guess it was used for errors
reported to OS which were not using SCI mechanism, for example, some
IO error reporting.

For External Interrupt, we don't use the ACPI event system, so for
the
firmware, it just report the errors associate with the interrupt
number, the kernel map the interrupt number and install the irq
handler for it.

For GSIV based event, it was introduced for hardware reduced platform
in recent ACPI revision, and ARM64 is one of its consumers. When
errors are reported via GSIV, ACPI event notification needs to be
implemented and requires the platform to define a hardware error
device
(PNP0C33) in ACPI namespace, and also a generic event device ACPI0013.

Okay, so for APEI this really means PNP0C33 was Notify()d. 'SCI' means
the same but the route they take to get into APEI is different.


For example, if we are using SPI (ARM GIC) 100 to report errors,
there
is a ACPI0013 driver in drivers/acpi/evged.c to register the irq,
when

Aha, this is where the interrupt-magic happens.


error happened and trigger the interrupt, ACPI0013 driver will notify
the error device (PNP0C33), then error device driver
(drivers/acpi/hed.c) will process the error data form APEI table...


The GHES GSIV code below is identical to the behaviour of the SCI
Notification type... are these two names for the same thing? (I'm
confused!)

SCI is also an 'interrupt' but it's a special irq number for ACPI
event, and it has GPE (general purpose event) registers behind it,
which is used only on Intel platforms. SCI based event use
Method(\_GPE._L0x) to notify the error device (PNP0C33), but GSIV is
used for HW-reduced platform which has no GPEs.

Hope it can clarify something :)

Yes thanks! (the mist is slowly clearing...)

If ACPI_HEST_NOTIFY_SCI and ACPI_HEST_NOTIFY_GSIV both mean 'receive
notification from PNP0C33', is there any point having separate lists
and add/remove functions for them?

Instead, could we rename Linux's ghes_notifier_sci() and ghes_sci list
to describe 'hed' instead, then group the two case statements together?
There would be no need to add a selectable CONFIG_ACPI_APEI_GSIV, as
SCI is already built-in and this way the code added is tiny. The only
thing we would lose is the name 'GSIV' in the not-supported error
message which we don't need if its always supported.

This method was tested ok. However we were not sure about reusing/changing the
existing ghes_notifier_sci() for gsiv will be accepted.

For now a notify (SCI/GSIV/GPIO) will trigger the process of all the
ghes data even they are on different list, so add them on a single
list and process them will have the same effect.

Thus added a separate handling function ghes_notifier_gsiv() for gsiv.

I think we can prepare the patch and send out for review.

Thanks
Hanjun
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm



[Index of Archives]     [Linux KVM]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux