Re: [Qemu-devel] using which notification for guest about GHES error

[Igor Mammedov]

On Mon, 16 Oct 2017 14:10:05 +0800
gengdongjiu <address@hidden> wrote:

> Hi Igor/Michael,
>    I am very sorry to disturb you again.
> Now we use Qemu to create APEI table and record CPER for guest,
> After QEMU recorded a asynchronous CPER error, we needs to notify guest using 
> interrupt or Polled notification.
> For the asynchronous error. I think using GPIO-signaled notification may be 
> better in the Qemu, and also which is suggested by APEI spec.
> James worried that old guest OS may not support GPIO or GSIV notification for 
> GHES, because GPIO or GSIV notification is supported in OS since about kernel 
> version 4.10.

How APEI support is fairly new on ARM (kernel), isn't it still in state of 
development?
Do we really care about old guests in this case?

We'd like to stick to ACPI spec as much as possible and also to
http://infocenter.arm.com/help/topic/com.arm.doc.den0044b/DEN0044B_Server_Base_Boot_Requirements.pdf
which mandates GPIO in platform (QEMU)
"
4.5 Hardware Requirements Imposed on the Platform by ACPI
...
Platforms compliant with this specification must provide the following 
GPIO-Signaled platform events:
...
"

> and suggested using Polled notification. About above two notifications, do 
> you think which is better? and could you give us some suggestion? thanks.
how polling is supposed to be implemented in QEMU?

> 
> 
> Hi James,
>   Below is APEI spec, From the spec, it suggested using GPIO interrupt or 
> GPIO-signaled events in ARM64 [1]. If using Polled notification for GHES, I 
> do not sure whether it is reasonable.
> In the Qemu, X86 does not using Polled notification. it mainly use SCI. Until 
> now, I do not found there is peopled using Polled notification in qemu. if 
> implemented polled notification, I
> do not know how much work effort need to do. Now I have already implemented 
> the GPIO-Signal notification using GPIO pin.
> 
> 
> [1]
> HW-reduced ACPI platforms signal the error using a GPIO interrupt or another 
> interrupt declared under a generic event device (Section 5.6.9). In the case 
> of GPIO-signaled events,
> an _AEI object lists the appropriate GPIO pin, while for Interrupt-signaled 
> events a _CRS object is used to list the interrupt:
>       • The OSPM evaluates the control method associated with this event as 
> indicated in Section 5.6.5.3 and Section 5.6.9.3.
>       • OSPM responds to this notification by checking the error status block 
> of all generic error sources with the GPIO-Signal notification or 
> Interrupt-signaled notification types to identify the
>         source reporting the error.
> 
> 
> 
> 
> 
> On 2017/10/1 11:30, Michael S. Tsirkin wrote:
> > On Thu, Sep 28, 2017 at 06:10:05PM +0800, gengdongjiu wrote:  
> >>
> >>
> >> On 2017/9/28 6:15, Michael S. Tsirkin wrote:  
> >>> On Wed, Sep 27, 2017 at 07:32:35PM +0800, gengdongjiu wrote:  
> >>>> Hi Igor/Laszlo
> >>>>
> >>>>    I am very sorry to disturb you. I have a question that want to 
> >>>> consult with you.
> >>>> Now In ARM64 platform I need to send a IRQ notification to guest OS 
> >>>> through Qemu, so that guest OS can receive a IRQ notification and parse 
> >>>> the APEI table.
> >>>> but Now I do not find a proper API to send the IRQ notification to 
> >>>> guest, seems X86 mainly uses the API "acpi_send_gpe_event"
> >>>> in the ARM64 platform, whether we have existed API that can send IRQ 
> >>>> notification to guest? thank you very much in advance.  
> >>>
> >>> ACPI events fundamentally go through the GPE mechanism. As the spec
> >>> says:
> >>>
> >>>   ACPI Event Programming Model
> >>>   The ACPI event programming model is based on the SCI interrupt and 
> >>> General-Purpose Event
> >>>   (GPE) register.  
> >>
> >> got it, thanks Michael  
> > 
> > As Igor pointed out, the next spec sentence states that reduced HW
> > configurations use GPIO.
> >   
> >>>
> >>>  
> >>>>
> >>>> [1]
> >>>> void acpi_send_gpe_event(ACPIREGS *ar, qemu_irq irq,
> >>>>                          AcpiEventStatusBits status)
> >>>> {
> >>>>     ar->gpe.sts[0] |= status;
> >>>>     acpi_update_sci(ar, irq);
> >>>> }
> >>>>
> >>>> void acpi_update_sci(ACPIREGS *regs, qemu_irq irq)
> >>>> {
> >>>>     int sci_level, pm1a_sts;
> >>>>
> >>>>     pm1a_sts = acpi_pm1_evt_get_sts(regs);
> >>>>
> >>>>     sci_level = ((pm1a_sts &
> >>>>                   regs->pm1.evt.en & ACPI_BITMASK_PM1_COMMON_ENABLED) != 
> >>>> 0) ||
> >>>>                 ((regs->gpe.sts[0] & regs->gpe.en[0]) != 0);
> >>>>
> >>>>     qemu_set_irq(irq, sci_level);
> >>>>
> >>>>     /* schedule a timer interruption if needed */
> >>>>     acpi_pm_tmr_update(regs,
> >>>>                        (regs->pm1.evt.en & ACPI_BITMASK_TIMER_ENABLE) &&
> >>>>                        !(pm1a_sts & ACPI_BITMASK_TIMER_STATUS));
> >>>> }  
> >>>
> >>> .
> >>>  
> > 
> > .
> >   
> 
>