Re: [Qemu-arm] [Qemu-devel] [PATCH v4 3/8] hw/acpi: Add ACPI Generic Event Device Support

[Igor Mammedov]

On Thu, 2 May 2019 09:22:35 +0200
Ard Biesheuvel <address@hidden> wrote:

> On Wed, 1 May 2019 at 13:25, Shameerali Kolothum Thodi
> <address@hidden> wrote:
> >
> > Hi Ard,
> >
> > > -----Original Message-----
> > > From: Ard Biesheuvel [mailto:address@hidden
> > > Sent: 01 May 2019 12:10
> > > To: Shameerali Kolothum Thodi <address@hidden>
> > > Cc: QEMU Developers <address@hidden>; qemu-arm
> > > <address@hidden>; Auger Eric <address@hidden>; Igor
> > > Mammedov <address@hidden>; Peter Maydell
> > > <address@hidden>; address@hidden;
> > > address@hidden; address@hidden; xuwei (O)
> > > <address@hidden>; Laszlo Ersek <address@hidden>; Linuxarm
> > > <address@hidden>
> > > Subject: Re: [PATCH v4 3/8] hw/acpi: Add ACPI Generic Event Device Support
> > >
> > > On Tue, 9 Apr 2019 at 12:31, Shameer Kolothum
> > > <address@hidden> wrote:
> > > >
> > > > From: Samuel Ortiz <address@hidden>
> > > >
> > > > The ACPI Generic Event Device (GED) is a hardware-reduced specific
> > > > device[ACPI v6.1 Section 5.6.9] that handles all platform events,
> > > > including the hotplug ones.This patch generates the AML code that
> > > > defines GEDs.
> > > >
> > > > Platforms need to specify their own GedEvent array to describe what
> > > > kind of events they want to support through GED.  Also this uses a
> > > > a single interrupt for the  GED device, relying on IO memory region
> > > > to communicate the type of device affected by the interrupt. This
> > > > way, we can support up to 32 events with a unique interrupt.
> > > >
> > > > This supports only memory hotplug for now.
> > > >
> > > > Signed-off-by: Samuel Ortiz <address@hidden>
> > > > Signed-off-by: Sebastien Boeuf <address@hidden>
> > > > Signed-off-by: Shameer Kolothum <address@hidden>
> > >
> > > Apologies if this question has been raised before, but do we really
> > > need a separate device for this? We already handle the power button
> > > via _AEI/_Exx on the GPIO device, and I think we should be able to add
> > > additional events using that interface, rather than have two event
> > > signalling methods/devices on the same platform.
> >
> > Right. The initial RFC was based on GPIO device[1] and later Igor commented
> > here[2] that,
> >
> > " ARM boards were first to use ACPI hw-reduced profile so they picked up
> > available back then GPIO based way to deliver hotplug event, later spec
> > introduced Generic Event Device for that means to use with hw-reduced
> > profile, which NEMU implemented[1], so I'd use that rather than ad-hoc
> > GPIO mapping. I'd guess it will more compatible with various contemporary
> > guests and we could reuse the same code for both x86/arm virt boards) "
> >
> 
> On mach-virt, we already use the GPIO controller for the ACPI event
> involving the power button, so by aligning with virt-x86, we end up in
> the opposite situation for mach-virt.
> 
> The problem with the GED device is that it only supports GSI
> interrupts, while the GPIO device supports arbitrary interrupts (such
> as GPIO signalled ones). This means that mach-virt will be stuck with
> having two different methods of signalling ACPI events, unless we
> rewire the power button not to use a GPIO interrupt but use a GSI
> directly.

we can rewire power button then.


> In general, I think the ACPI event delivery mechanism doesn't really
> have to be aligned: the ACPI event is ultimately converted into a AML
> notification to the right device, and how we end up there can remain
> platform specific.

Reasoning for using GED is to reduce code duplication with x86
and not creating zoo of different approached (if it could be avoided).