On Wed, 1 May 2019 at 13:25, Shameerali Kolothum Thodi <shameerali.kolothum.th...@huawei.com> wrote: > > Hi Ard, > > > -----Original Message----- > > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > > Sent: 01 May 2019 12:10 > > To: Shameerali Kolothum Thodi <shameerali.kolothum.th...@huawei.com> > > Cc: QEMU Developers <qemu-devel@nongnu.org>; qemu-arm > > <qemu-...@nongnu.org>; Auger Eric <eric.au...@redhat.com>; Igor > > Mammedov <imamm...@redhat.com>; Peter Maydell > > <peter.mayd...@linaro.org>; shannon.zha...@gmail.com; > > sa...@linux.intel.com; sebastien.bo...@intel.com; xuwei (O) > > <xuw...@huawei.com>; Laszlo Ersek <ler...@redhat.com>; Linuxarm > > <linux...@huawei.com> > > Subject: Re: [PATCH v4 3/8] hw/acpi: Add ACPI Generic Event Device Support > > > > On Tue, 9 Apr 2019 at 12:31, Shameer Kolothum > > <shameerali.kolothum.th...@huawei.com> wrote: > > > > > > From: Samuel Ortiz <sa...@linux.intel.com> > > > > > > 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 <sa...@linux.intel.com> > > > Signed-off-by: Sebastien Boeuf <sebastien.bo...@intel.com> > > > Signed-off-by: Shameer Kolothum <shameerali.kolothum.th...@huawei.com> > > > > 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.
