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

[Ard Biesheuvel]

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.

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.