From: Igor Mammedov <imammedo@redhat.com> To: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>, Peter Maydell <peter.maydell@linaro.org>, "sameo@linux.intel.com" <sameo@linux.intel.com>, "shannon.zhaosl@gmail.com" <shannon.zhaosl@gmail.com>, QEMU Developers <qemu-devel@nongnu.org>, Linuxarm <linuxarm@huawei.com>, Auger Eric <eric.auger@redhat.com>, qemu-arm <qemu-arm@nongnu.org>, "xuwei (O)" <xuwei5@huawei.com>, "sebastien.boeuf@intel.com" <sebastien.boeuf@intel.com>, Laszlo Ersek <lersek@redhat.com> Subject: Re: [Qemu-devel] [PATCH v4 3/8] hw/acpi: Add ACPI Generic Event Device Support Date: Thu, 2 May 2019 17:24:18 +0200 [thread overview] Message-ID: <20190502172418.2b7d6d84@Igors-MacBook-Pro> (raw) In-Reply-To: <CAKv+Gu9yw6s=N+LkKmQ+0d5ZQBJ+5tE0_cKtZAYHh_cTXnjyCQ@mail.gmail.com> On Thu, 2 May 2019 09:22:35 +0200 Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > On Wed, 1 May 2019 at 13:25, Shameerali Kolothum Thodi > <shameerali.kolothum.thodi@huawei.com> wrote: > > > > Hi Ard, > > > > > -----Original Message----- > > > From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] > > > Sent: 01 May 2019 12:10 > > > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com> > > > Cc: QEMU Developers <qemu-devel@nongnu.org>; qemu-arm > > > <qemu-arm@nongnu.org>; Auger Eric <eric.auger@redhat.com>; Igor > > > Mammedov <imammedo@redhat.com>; Peter Maydell > > > <peter.maydell@linaro.org>; shannon.zhaosl@gmail.com; > > > sameo@linux.intel.com; sebastien.boeuf@intel.com; xuwei (O) > > > <xuwei5@huawei.com>; Laszlo Ersek <lersek@redhat.com>; Linuxarm > > > <linuxarm@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.thodi@huawei.com> wrote: > > > > > > > > From: Samuel Ortiz <sameo@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 <sameo@linux.intel.com> > > > > Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com> > > > > Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@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. 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).
WARNING: multiple messages have this Message-ID (diff)
From: Igor Mammedov <imammedo@redhat.com> To: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Peter Maydell <peter.maydell@linaro.org>, "sameo@linux.intel.com" <sameo@linux.intel.com>, Auger Eric <eric.auger@redhat.com>, QEMU Developers <qemu-devel@nongnu.org>, Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>, Linuxarm <linuxarm@huawei.com>, "shannon.zhaosl@gmail.com" <shannon.zhaosl@gmail.com>, qemu-arm <qemu-arm@nongnu.org>, "xuwei \(O\)" <xuwei5@huawei.com>, "sebastien.boeuf@intel.com" <sebastien.boeuf@intel.com>, Laszlo Ersek <lersek@redhat.com> Subject: Re: [Qemu-devel] [PATCH v4 3/8] hw/acpi: Add ACPI Generic Event Device Support Date: Thu, 2 May 2019 17:24:18 +0200 [thread overview] Message-ID: <20190502172418.2b7d6d84@Igors-MacBook-Pro> (raw) Message-ID: <20190502152418.lR0zao2Vzlx4O5IP4kZpJer9TuR-Nzo1lLMpzrmZdqM@z> (raw) In-Reply-To: <CAKv+Gu9yw6s=N+LkKmQ+0d5ZQBJ+5tE0_cKtZAYHh_cTXnjyCQ@mail.gmail.com> On Thu, 2 May 2019 09:22:35 +0200 Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > On Wed, 1 May 2019 at 13:25, Shameerali Kolothum Thodi > <shameerali.kolothum.thodi@huawei.com> wrote: > > > > Hi Ard, > > > > > -----Original Message----- > > > From: Ard Biesheuvel [mailto:ard.biesheuvel@linaro.org] > > > Sent: 01 May 2019 12:10 > > > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com> > > > Cc: QEMU Developers <qemu-devel@nongnu.org>; qemu-arm > > > <qemu-arm@nongnu.org>; Auger Eric <eric.auger@redhat.com>; Igor > > > Mammedov <imammedo@redhat.com>; Peter Maydell > > > <peter.maydell@linaro.org>; shannon.zhaosl@gmail.com; > > > sameo@linux.intel.com; sebastien.boeuf@intel.com; xuwei (O) > > > <xuwei5@huawei.com>; Laszlo Ersek <lersek@redhat.com>; Linuxarm > > > <linuxarm@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.thodi@huawei.com> wrote: > > > > > > > > From: Samuel Ortiz <sameo@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 <sameo@linux.intel.com> > > > > Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com> > > > > Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@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. 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).
next prev parent reply other threads:[~2019-05-02 15:24 UTC|newest] Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-04-09 10:29 [Qemu-devel] [PATCH v4 0/8] ARM virt: ACPI memory hotplug support Shameer Kolothum 2019-04-09 10:29 ` Shameer Kolothum 2019-04-09 10:29 ` [Qemu-devel] [PATCH v4 1/8] hw/acpi: Make ACPI IO address space configurable Shameer Kolothum 2019-04-09 10:29 ` Shameer Kolothum 2019-04-09 10:29 ` [Qemu-devel] [PATCH v4 2/8] hw/acpi: Do not create memory hotplug method when handler is not defined Shameer Kolothum 2019-04-09 10:29 ` Shameer Kolothum 2019-04-09 10:29 ` [Qemu-devel] [PATCH v4 3/8] hw/acpi: Add ACPI Generic Event Device Support Shameer Kolothum 2019-04-09 10:29 ` Shameer Kolothum 2019-04-30 15:49 ` Auger Eric 2019-04-30 15:49 ` Auger Eric 2019-05-01 10:40 ` Shameerali Kolothum Thodi 2019-05-01 10:40 ` Shameerali Kolothum Thodi 2019-05-02 7:10 ` Auger Eric 2019-05-02 7:10 ` Auger Eric 2019-05-01 11:10 ` Ard Biesheuvel 2019-05-01 11:10 ` Ard Biesheuvel 2019-05-01 11:25 ` Shameerali Kolothum Thodi 2019-05-01 11:25 ` Shameerali Kolothum Thodi 2019-05-02 7:22 ` Ard Biesheuvel 2019-05-02 7:22 ` Ard Biesheuvel 2019-05-02 15:24 ` Igor Mammedov [this message] 2019-05-02 15:24 ` Igor Mammedov 2019-05-02 16:12 ` Igor Mammedov 2019-05-02 16:12 ` Igor Mammedov 2019-05-03 12:45 ` Shameerali Kolothum Thodi 2019-05-03 12:45 ` Shameerali Kolothum Thodi 2019-05-03 15:10 ` Igor Mammedov 2019-05-03 15:10 ` Igor Mammedov 2019-05-07 9:01 ` Shameerali Kolothum Thodi 2019-05-09 14:50 ` Igor Mammedov 2019-05-13 11:53 ` Shameerali Kolothum Thodi 2019-05-13 17:00 ` Shameerali Kolothum Thodi 2019-05-17 8:41 ` Igor Mammedov 2019-05-17 10:31 ` Shameerali Kolothum Thodi 2019-04-09 10:29 ` [Qemu-devel] [PATCH v4 4/8] hw/arm/virt: Add memory hotplug framework Shameer Kolothum 2019-04-09 10:29 ` Shameer Kolothum 2019-05-02 16:19 ` Igor Mammedov 2019-05-02 16:19 ` Igor Mammedov 2019-05-03 12:47 ` Shameerali Kolothum Thodi 2019-05-03 12:47 ` Shameerali Kolothum Thodi 2019-04-09 10:29 ` [Qemu-devel] [PATCH v4 5/8] hw/arm/virt: Enable device memory cold/hot plug with ACPI boot Shameer Kolothum 2019-04-09 10:29 ` Shameer Kolothum 2019-04-30 16:34 ` Auger Eric 2019-04-30 16:34 ` Auger Eric 2019-05-01 10:49 ` Shameerali Kolothum Thodi 2019-05-01 10:49 ` Shameerali Kolothum Thodi 2019-05-09 15:20 ` Igor Mammedov 2019-04-09 10:29 ` [Qemu-devel] [PATCH v4 6/8] hw/arm/virt-acpi-build: Add PC-DIMM in SRAT Shameer Kolothum 2019-04-09 10:29 ` Shameer Kolothum 2019-04-09 10:29 ` [Qemu-devel] [PATCH v4 7/8] hw/arm/boot: Add "hotpluggable" property to DT memory node Shameer Kolothum 2019-04-09 10:29 ` Shameer Kolothum 2019-04-09 10:29 ` [Qemu-devel] [PATCH v4 8/8] hw/arm/boot: Expose the PC-DIMM nodes in the DT Shameer Kolothum 2019-04-09 10:29 ` Shameer Kolothum 2019-04-09 15:08 ` Laszlo Ersek 2019-04-09 15:08 ` Laszlo Ersek 2019-04-10 8:49 ` Shameerali Kolothum Thodi 2019-04-10 8:49 ` Shameerali Kolothum Thodi 2019-05-03 13:35 ` Shameerali Kolothum Thodi 2019-05-03 13:35 ` Shameerali Kolothum Thodi 2019-05-03 14:13 ` Laszlo Ersek 2019-05-03 14:13 ` Laszlo Ersek 2019-05-08 10:30 ` Shameerali Kolothum Thodi
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=20190502172418.2b7d6d84@Igors-MacBook-Pro \ --to=imammedo@redhat.com \ --cc=ard.biesheuvel@linaro.org \ --cc=eric.auger@redhat.com \ --cc=lersek@redhat.com \ --cc=linuxarm@huawei.com \ --cc=peter.maydell@linaro.org \ --cc=qemu-arm@nongnu.org \ --cc=qemu-devel@nongnu.org \ --cc=sameo@linux.intel.com \ --cc=sebastien.boeuf@intel.com \ --cc=shameerali.kolothum.thodi@huawei.com \ --cc=shannon.zhaosl@gmail.com \ --cc=xuwei5@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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.