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

* [Qemu-devel] using which notification for guest about GHES error
       [not found]     ` <20171001063010-mutt-send-email-mst@kernel.org>
@ 2017-10-16  6:10       ` gengdongjiu
  2017-10-16  9:33         ` Igor Mammedov
  0 siblings, 1 reply; 6+ messages in thread
From: gengdongjiu @ 2017-10-16  6:10 UTC (permalink / raw)
  To: Michael S. Tsirkin, James Morse
  Cc: imammedo, Laszlo Ersek, QEMU Developers, Wuquanming, Huangshaoyu

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.
and suggested using Polled notification. About above two notifications, do you think which is better? and could you give us some suggestion? thanks.

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));
>>>> }
>>>
>>> .
>>>
> 
> .
> 

^ permalink raw reply	[flat|nested] 6+ messages in thread