qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: gengdongjiu <gengdongjiu@huawei.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
	James Morse <james.morse@arm.com>,
	Wuquanming <wuquanming@huawei.com>,
	Laszlo Ersek <lersek@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	Huangshaoyu <huangshaoyu@huawei.com>,
	Andrew Jones <drjones@redhat.com>
Subject: Re: [Qemu-devel] using which notification for guest about GHES error
Date: Mon, 16 Oct 2017 11:33:24 +0200	[thread overview]
Message-ID: <20171016113324.14e549c9@nial.brq.redhat.com> (raw)
In-Reply-To: <49d576f3-454f-05f4-7afd-9ca8b5fb0706@huawei.com>

On Mon, 16 Oct 2017 14:10:05 +0800
gengdongjiu <gengdongjiu@huawei.com> 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));
> >>>> }  
> >>>
> >>> .
> >>>  
> > 
> > .
> >   
> 
> 

  reply	other threads:[~2017-10-16  9:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <8ba7e693-4e32-7873-70bf-4efbf57f9cf5@huawei.com>
     [not found] ` <20170928011407-mutt-send-email-mst@kernel.org>
     [not found]   ` <405bbc99-1a43-aa8b-37e9-9599480f4c06@huawei.com>
     [not found]     ` <20171001063010-mutt-send-email-mst@kernel.org>
2017-10-16  6:10       ` [Qemu-devel] using which notification for guest about GHES error gengdongjiu
2017-10-16  9:33         ` Igor Mammedov [this message]
2017-10-16 14:33           ` [Qemu-devel] 答复: " gengdongjiu
2017-10-16 16:59             ` James Morse
2017-10-16 17:25               ` Laszlo Ersek
2017-10-17  1:31               ` [Qemu-devel] " gengdongjiu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171016113324.14e549c9@nial.brq.redhat.com \
    --to=imammedo@redhat.com \
    --cc=drjones@redhat.com \
    --cc=gengdongjiu@huawei.com \
    --cc=huangshaoyu@huawei.com \
    --cc=james.morse@arm.com \
    --cc=lersek@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=wuquanming@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).