Hi Hanjun, > -----Original Message----- > From: Hanjun Guo [mailto:hanjun.guo@xxxxxxxxxx] > Sent: 03 March 2017 04:20 > To: Shiju Jose; James Morse > Cc: christoffer.dall@xxxxxxxxxx; marc.zyngier@xxxxxxx; > pbonzini@xxxxxxxxxx; rkrcmar@xxxxxxxxxx; linux@xxxxxxxxxxxxxxx; > catalin.marinas@xxxxxxx; will.deacon@xxxxxxx; rjw@xxxxxxxxxxxxx; > lenb@xxxxxxxxxx; matt@xxxxxxxxxxxxxxxxxxx; robert.moore@xxxxxxxxx; > lv.zheng@xxxxxxxxx; nkaje@xxxxxxxxxxxxxx; zjzhang@xxxxxxxxxxxxxx; > mark.rutland@xxxxxxx; akpm@xxxxxxxxxxxxxxxxxxxx; > eun.taik.lee@xxxxxxxxxxx; sandeepa.s.prabhu@xxxxxxxxx; > labbott@xxxxxxxxxx; shijie.huang@xxxxxxx; rruigrok@xxxxxxxxxxxxxx; > paul.gortmaker@xxxxxxxxxxxxx; tn@xxxxxxxxxxxx; fu.wei@xxxxxxxxxx; > rostedt@xxxxxxxxxxx; bristot@xxxxxxxxxx; linux-arm- > kernel@xxxxxxxxxxxxxxxxxxx; kvmarm@xxxxxxxxxxxxxxxxxxxxx; > kvm@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; linux- > acpi@xxxxxxxxxxxxxxx; linux-efi@xxxxxxxxxxxxxxx; devel@xxxxxxxxxx; > Suzuki.Poulose@xxxxxxx; punit.agrawal@xxxxxxx; astone@xxxxxxxxxx; > harba@xxxxxxxxxxxxxx; Tyler Baicar; joe@xxxxxxxxxxx; John Garry; > Gabriele Paoloni; Guohanjun (Hanjun Guo); wangxiongfeng (C); Zhengqiang > (turing) > Subject: Re: [RFC PATCH V1 v4.10-rc3 1/1] acpi: apei: handle GSIV > notification type > > 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. Ok. I will do this. > > Thanks > Hanjun _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
