From: Igor Mammedov <imammedo@redhat.com>
To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
Cc: "peter.maydell@linaro.org" <peter.maydell@linaro.org>,
"shannon.zhaosl@gmail.com" <shannon.zhaosl@gmail.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Linuxarm <linuxarm@huawei.com>,
Auger Eric <eric.auger@redhat.com>,
"qemu-arm@nongnu.org" <qemu-arm@nongnu.org>,
"xuwei \(O\)" <xuwei5@huawei.com>
Subject: Re: [Qemu-arm] [RFC PATCH 1/4] hw:acpi: Make ACPI IO address space configurable
Date: Thu, 28 Feb 2019 17:44:24 +0100 [thread overview]
Message-ID: <20190228174424.1cae71b8@redhat.com> (raw)
In-Reply-To: <5FC3163CFD30C246ABAA99954A238FA8392D7AB9@lhreml524-mbs.china.huawei.com>
On Thu, 28 Feb 2019 16:09:48 +0000
Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com> wrote:
> Hi Eric,
>
> > -----Original Message-----
> > From: Auger Eric [mailto:eric.auger@redhat.com]
> > Sent: 27 February 2019 17:53
> > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>;
> > shannon.zhaosl@gmail.com; peter.maydell@linaro.org;
> > imammedo@redhat.com; qemu-devel@nongnu.org; qemu-arm@nongnu.org
> > Cc: xuwei (O) <xuwei5@huawei.com>; Linuxarm <linuxarm@huawei.com>
> > Subject: Re: [RFC PATCH 1/4] hw:acpi: Make ACPI IO address space
> > configurable
> >
> > Hi Shameer,
> > On 1/28/19 12:05 PM, Shameer Kolothum wrote:
> > > This is in preparation for adding support for ARM64 platforms where it
> > > doesn't use port mapped IO for ACPI IO space.
> > >
> > > Also add a flag to identify hw reduced ACPI platforms as they might
> > > use GPIO hw for signaling ACPI platform events.
> > >
> > > Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> > > ---
> > > hw/acpi/memory_hotplug.c | 13 ++++++++-----
> > > hw/i386/acpi-build.c | 3 ++-
> > > include/hw/acpi/memory_hotplug.h | 6 ++++--
> > > 3 files changed, 14 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/hw/acpi/memory_hotplug.c b/hw/acpi/memory_hotplug.c index
> > > 921cad2..05f1d45 100644
> > > --- a/hw/acpi/memory_hotplug.c
> > > +++ b/hw/acpi/memory_hotplug.c
> > > @@ -34,7 +34,7 @@
> > > #define MEMORY_HOTPLUG_IO_LEN 24
> > > #define MEMORY_DEVICES_CONTAINER "\\_SB.MHPC"
> > >
> > > -static uint16_t memhp_io_base;
> > > +static hwaddr memhp_io_base;
> > >
> > > static ACPIOSTInfo *acpi_memory_device_status(int slot, MemStatus
> > > *mdev) { @@ -208,7 +208,7 @@ static const MemoryRegionOps
> > > acpi_memory_hotplug_ops = { };
> > >
> > > void acpi_memory_hotplug_init(MemoryRegion *as, Object *owner,
> > > - MemHotplugState *state, uint16_t
> > io_base)
> > > + MemHotplugState *state, hwaddr
> > io_base)
> > > {
> > > MachineState *machine = MACHINE(qdev_get_machine());
> > >
> > > @@ -279,7 +279,9 @@ void acpi_memory_plug_cb(HotplugHandler
> > *hotplug_dev, MemHotplugState *mem_st,
> > > mdev->is_enabled = true;
> > > if (dev->hotplugged) {
> > > mdev->is_inserting = true;
> > > - acpi_send_event(DEVICE(hotplug_dev),
> > ACPI_MEMORY_HOTPLUG_STATUS);
> > > + if (!mem_st->hw_reduced_acpi) {
> > > + acpi_send_event(DEVICE(hotplug_dev),
> > ACPI_MEMORY_HOTPLUG_STATUS);
> > > + }
> > > }
> > > }
> > >
> > > @@ -341,7 +343,8 @@ const VMStateDescription
> > vmstate_memory_hotplug =
> > > {
> > >
> > > void build_memory_hotplug_aml(Aml *table, uint32_t nr_mem,
> > > const char *res_root,
> > > - const char *event_handler_method)
> > > + const char *event_handler_method,
> > > + AmlRegionSpace rs)
> > > {
> > > int i;
> > > Aml *ifctx;
> > > @@ -371,7 +374,7 @@ void build_memory_hotplug_aml(Aml *table,
> > uint32_t nr_mem,
> > > aml_append(mem_ctrl_dev, aml_name_decl("_CRS", crs));
> > >
> > > aml_append(mem_ctrl_dev, aml_operation_region(
> > > - MEMORY_HOTPLUG_IO_REGION, AML_SYSTEM_IO,
> > > + MEMORY_HOTPLUG_IO_REGION, rs,
> > > aml_int(memhp_io_base), MEMORY_HOTPLUG_IO_LEN)
> > Given the change in the datatype (memhp_io_base) is it OK to keep the
> > aml_int() cast.
>
> Hmm...aml_int() has uint64_t but not sure hwaddr will cause any unwarranted effects on
> other platforms. Do you see any potential issues here?
aml_int encodes it according to the value so it should e fine
>
> > Also we have
> > "
> > aml_append(crs,
> > aml_io(AML_DECODE16, memhp_io_base, memhp_io_base, 0,
> > MEMORY_HOTPLUG_IO_LEN)
> > );
> > " where we have aml_io being used + AML_decode16. Shouldn't we have
> > aml_*_memory depending on rs?
>
> That looks like a valid point, but then I wonder how this worked. I will double check.
maybe use aml_memory32_fixed() or aml_[dq]word_memory()
> > I am not knowledged enough about the aml description but just in case.
>
> Same here :).
>
> Thanks,
> Shameer
>
>
> > Thanks
> >
> > Eric
> >
> > > );
> > >
> > > diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c index
> > > 2e21a31..b62c1a3 100644
> > > --- a/hw/i386/acpi-build.c
> > > +++ b/hw/i386/acpi-build.c
> > > @@ -1852,7 +1852,8 @@ build_dsdt(GArray *table_data, BIOSLinker
> > *linker,
> > > build_cpus_aml(dsdt, machine, opts, pm->cpu_hp_io_base,
> > > "\\_SB.PCI0", "\\_GPE._E02");
> > > }
> > > - build_memory_hotplug_aml(dsdt, nr_mem, "\\_SB.PCI0",
> > "\\_GPE._E03");
> > > + build_memory_hotplug_aml(dsdt, nr_mem, "\\_SB.PCI0",
> > > + "\\_GPE._E03", AML_SYSTEM_IO);
> > >
> > > scope = aml_scope("_GPE");
> > > {
> > > diff --git a/include/hw/acpi/memory_hotplug.h
> > > b/include/hw/acpi/memory_hotplug.h
> > > index 77c6576..ec56579 100644
> > > --- a/include/hw/acpi/memory_hotplug.h
> > > +++ b/include/hw/acpi/memory_hotplug.h
> > > @@ -26,10 +26,11 @@ typedef struct MemHotplugState {
> > > uint32_t selector;
> > > uint32_t dev_count;
> > > MemStatus *devs;
> > > + bool hw_reduced_acpi; /*true for hw reduced acpi platform */
> > > } MemHotplugState;
> > >
> > > void acpi_memory_hotplug_init(MemoryRegion *as, Object *owner,
> > > - MemHotplugState *state, uint16_t
> > io_base);
> > > + MemHotplugState *state, hwaddr
> > > + io_base);
> > >
> > > void acpi_memory_plug_cb(HotplugHandler *hotplug_dev,
> > MemHotplugState *mem_st,
> > > DeviceState *dev, Error **errp); @@ -48,5
> > > +49,6 @@ void acpi_memory_ospm_status(MemHotplugState *mem_st,
> > > ACPIOSTInfoList ***list);
> > >
> > > void build_memory_hotplug_aml(Aml *table, uint32_t nr_mem,
> > > const char *res_root,
> > > - const char *event_handler_method);
> > > + const char *event_handler_method,
> > > + AmlRegionSpace rs);
> > > #endif
> > >
WARNING: multiple messages have this Message-ID (diff)
From: Igor Mammedov <imammedo@redhat.com>
To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
Cc: Auger Eric <eric.auger@redhat.com>,
"shannon.zhaosl@gmail.com" <shannon.zhaosl@gmail.com>,
"peter.maydell@linaro.org" <peter.maydell@linaro.org>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"qemu-arm@nongnu.org" <qemu-arm@nongnu.org>,
"xuwei (O)" <xuwei5@huawei.com>, Linuxarm <linuxarm@huawei.com>
Subject: Re: [Qemu-devel] [RFC PATCH 1/4] hw:acpi: Make ACPI IO address space configurable
Date: Thu, 28 Feb 2019 17:44:24 +0100 [thread overview]
Message-ID: <20190228174424.1cae71b8@redhat.com> (raw)
In-Reply-To: <5FC3163CFD30C246ABAA99954A238FA8392D7AB9@lhreml524-mbs.china.huawei.com>
On Thu, 28 Feb 2019 16:09:48 +0000
Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com> wrote:
> Hi Eric,
>
> > -----Original Message-----
> > From: Auger Eric [mailto:eric.auger@redhat.com]
> > Sent: 27 February 2019 17:53
> > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>;
> > shannon.zhaosl@gmail.com; peter.maydell@linaro.org;
> > imammedo@redhat.com; qemu-devel@nongnu.org; qemu-arm@nongnu.org
> > Cc: xuwei (O) <xuwei5@huawei.com>; Linuxarm <linuxarm@huawei.com>
> > Subject: Re: [RFC PATCH 1/4] hw:acpi: Make ACPI IO address space
> > configurable
> >
> > Hi Shameer,
> > On 1/28/19 12:05 PM, Shameer Kolothum wrote:
> > > This is in preparation for adding support for ARM64 platforms where it
> > > doesn't use port mapped IO for ACPI IO space.
> > >
> > > Also add a flag to identify hw reduced ACPI platforms as they might
> > > use GPIO hw for signaling ACPI platform events.
> > >
> > > Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> > > ---
> > > hw/acpi/memory_hotplug.c | 13 ++++++++-----
> > > hw/i386/acpi-build.c | 3 ++-
> > > include/hw/acpi/memory_hotplug.h | 6 ++++--
> > > 3 files changed, 14 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/hw/acpi/memory_hotplug.c b/hw/acpi/memory_hotplug.c index
> > > 921cad2..05f1d45 100644
> > > --- a/hw/acpi/memory_hotplug.c
> > > +++ b/hw/acpi/memory_hotplug.c
> > > @@ -34,7 +34,7 @@
> > > #define MEMORY_HOTPLUG_IO_LEN 24
> > > #define MEMORY_DEVICES_CONTAINER "\\_SB.MHPC"
> > >
> > > -static uint16_t memhp_io_base;
> > > +static hwaddr memhp_io_base;
> > >
> > > static ACPIOSTInfo *acpi_memory_device_status(int slot, MemStatus
> > > *mdev) { @@ -208,7 +208,7 @@ static const MemoryRegionOps
> > > acpi_memory_hotplug_ops = { };
> > >
> > > void acpi_memory_hotplug_init(MemoryRegion *as, Object *owner,
> > > - MemHotplugState *state, uint16_t
> > io_base)
> > > + MemHotplugState *state, hwaddr
> > io_base)
> > > {
> > > MachineState *machine = MACHINE(qdev_get_machine());
> > >
> > > @@ -279,7 +279,9 @@ void acpi_memory_plug_cb(HotplugHandler
> > *hotplug_dev, MemHotplugState *mem_st,
> > > mdev->is_enabled = true;
> > > if (dev->hotplugged) {
> > > mdev->is_inserting = true;
> > > - acpi_send_event(DEVICE(hotplug_dev),
> > ACPI_MEMORY_HOTPLUG_STATUS);
> > > + if (!mem_st->hw_reduced_acpi) {
> > > + acpi_send_event(DEVICE(hotplug_dev),
> > ACPI_MEMORY_HOTPLUG_STATUS);
> > > + }
> > > }
> > > }
> > >
> > > @@ -341,7 +343,8 @@ const VMStateDescription
> > vmstate_memory_hotplug =
> > > {
> > >
> > > void build_memory_hotplug_aml(Aml *table, uint32_t nr_mem,
> > > const char *res_root,
> > > - const char *event_handler_method)
> > > + const char *event_handler_method,
> > > + AmlRegionSpace rs)
> > > {
> > > int i;
> > > Aml *ifctx;
> > > @@ -371,7 +374,7 @@ void build_memory_hotplug_aml(Aml *table,
> > uint32_t nr_mem,
> > > aml_append(mem_ctrl_dev, aml_name_decl("_CRS", crs));
> > >
> > > aml_append(mem_ctrl_dev, aml_operation_region(
> > > - MEMORY_HOTPLUG_IO_REGION, AML_SYSTEM_IO,
> > > + MEMORY_HOTPLUG_IO_REGION, rs,
> > > aml_int(memhp_io_base), MEMORY_HOTPLUG_IO_LEN)
> > Given the change in the datatype (memhp_io_base) is it OK to keep the
> > aml_int() cast.
>
> Hmm...aml_int() has uint64_t but not sure hwaddr will cause any unwarranted effects on
> other platforms. Do you see any potential issues here?
aml_int encodes it according to the value so it should e fine
>
> > Also we have
> > "
> > aml_append(crs,
> > aml_io(AML_DECODE16, memhp_io_base, memhp_io_base, 0,
> > MEMORY_HOTPLUG_IO_LEN)
> > );
> > " where we have aml_io being used + AML_decode16. Shouldn't we have
> > aml_*_memory depending on rs?
>
> That looks like a valid point, but then I wonder how this worked. I will double check.
maybe use aml_memory32_fixed() or aml_[dq]word_memory()
> > I am not knowledged enough about the aml description but just in case.
>
> Same here :).
>
> Thanks,
> Shameer
>
>
> > Thanks
> >
> > Eric
> >
> > > );
> > >
> > > diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c index
> > > 2e21a31..b62c1a3 100644
> > > --- a/hw/i386/acpi-build.c
> > > +++ b/hw/i386/acpi-build.c
> > > @@ -1852,7 +1852,8 @@ build_dsdt(GArray *table_data, BIOSLinker
> > *linker,
> > > build_cpus_aml(dsdt, machine, opts, pm->cpu_hp_io_base,
> > > "\\_SB.PCI0", "\\_GPE._E02");
> > > }
> > > - build_memory_hotplug_aml(dsdt, nr_mem, "\\_SB.PCI0",
> > "\\_GPE._E03");
> > > + build_memory_hotplug_aml(dsdt, nr_mem, "\\_SB.PCI0",
> > > + "\\_GPE._E03", AML_SYSTEM_IO);
> > >
> > > scope = aml_scope("_GPE");
> > > {
> > > diff --git a/include/hw/acpi/memory_hotplug.h
> > > b/include/hw/acpi/memory_hotplug.h
> > > index 77c6576..ec56579 100644
> > > --- a/include/hw/acpi/memory_hotplug.h
> > > +++ b/include/hw/acpi/memory_hotplug.h
> > > @@ -26,10 +26,11 @@ typedef struct MemHotplugState {
> > > uint32_t selector;
> > > uint32_t dev_count;
> > > MemStatus *devs;
> > > + bool hw_reduced_acpi; /*true for hw reduced acpi platform */
> > > } MemHotplugState;
> > >
> > > void acpi_memory_hotplug_init(MemoryRegion *as, Object *owner,
> > > - MemHotplugState *state, uint16_t
> > io_base);
> > > + MemHotplugState *state, hwaddr
> > > + io_base);
> > >
> > > void acpi_memory_plug_cb(HotplugHandler *hotplug_dev,
> > MemHotplugState *mem_st,
> > > DeviceState *dev, Error **errp); @@ -48,5
> > > +49,6 @@ void acpi_memory_ospm_status(MemHotplugState *mem_st,
> > > ACPIOSTInfoList ***list);
> > >
> > > void build_memory_hotplug_aml(Aml *table, uint32_t nr_mem,
> > > const char *res_root,
> > > - const char *event_handler_method);
> > > + const char *event_handler_method,
> > > + AmlRegionSpace rs);
> > > #endif
> > >
next prev parent reply other threads:[~2019-02-28 16:44 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-28 11:05 [Qemu-arm] [RFC PATCH 0/4] ARM virt: ACPI memory hotplug support Shameer Kolothum
2019-01-28 11:05 ` [Qemu-devel] " Shameer Kolothum
2019-01-28 11:05 ` [Qemu-arm] [RFC PATCH 1/4] hw:acpi: Make ACPI IO address space configurable Shameer Kolothum
2019-01-28 11:05 ` [Qemu-devel] " Shameer Kolothum
2019-02-27 16:27 ` [Qemu-arm] " Igor Mammedov
2019-02-27 16:27 ` [Qemu-devel] " Igor Mammedov
2019-02-28 12:14 ` [Qemu-arm] " Shameerali Kolothum Thodi
2019-02-28 12:14 ` [Qemu-devel] " Shameerali Kolothum Thodi
2019-02-27 17:52 ` Auger Eric
2019-02-27 17:52 ` Auger Eric
2019-02-28 16:09 ` [Qemu-arm] " Shameerali Kolothum Thodi
2019-02-28 16:09 ` [Qemu-devel] " Shameerali Kolothum Thodi
2019-02-28 16:44 ` Igor Mammedov [this message]
2019-02-28 16:44 ` Igor Mammedov
2019-01-28 11:05 ` [Qemu-arm] [RFC PATCH 2/4] hw/arm/virt: Add GPIO based pcdimm hotplug ACPI event support Shameer Kolothum
2019-01-28 11:05 ` [Qemu-devel] " Shameer Kolothum
2019-02-27 16:44 ` Igor Mammedov
2019-02-27 16:44 ` Igor Mammedov
2019-01-28 11:05 ` [Qemu-arm] [RFC PATCH 3/4] hw/arm/virt: Enable pc-dimm hotplug support Shameer Kolothum
2019-01-28 11:05 ` [Qemu-devel] " Shameer Kolothum
2019-02-27 17:14 ` [Qemu-arm] " Igor Mammedov
2019-02-27 17:14 ` Igor Mammedov
2019-02-28 9:57 ` [Qemu-arm] " Auger Eric
2019-02-28 9:57 ` Auger Eric
2019-02-28 12:44 ` [Qemu-arm] " Igor Mammedov
2019-02-28 12:44 ` Igor Mammedov
2019-02-28 12:27 ` [Qemu-arm] " Shameerali Kolothum Thodi
2019-02-28 12:27 ` Shameerali Kolothum Thodi
2019-03-01 9:12 ` [Qemu-arm] " Igor Mammedov
2019-03-01 9:12 ` Igor Mammedov
2019-03-01 9:23 ` Shameerali Kolothum Thodi
2019-03-01 9:23 ` Shameerali Kolothum Thodi
2019-03-01 10:26 ` [Qemu-arm] " Igor Mammedov
2019-03-01 10:26 ` Igor Mammedov
2019-03-01 10:33 ` [Qemu-arm] " Igor Mammedov
2019-03-01 10:33 ` Igor Mammedov
2019-03-01 10:51 ` [Qemu-arm] " Shameerali Kolothum Thodi
2019-03-01 10:51 ` Shameerali Kolothum Thodi
2019-03-01 13:09 ` Igor Mammedov
2019-03-01 13:09 ` Igor Mammedov
2019-02-22 16:03 ` [Qemu-arm] [RFC PATCH 0/4] ARM virt: ACPI memory " Auger Eric
2019-02-22 16:03 ` [Qemu-devel] " Auger Eric
2019-02-22 19:11 ` [Qemu-arm] " Laszlo Ersek
2019-02-22 19:11 ` [Qemu-devel] " Laszlo Ersek
2019-02-25 9:54 ` [Qemu-arm] " Shameerali Kolothum Thodi
2019-02-25 9:54 ` [Qemu-devel] " Shameerali Kolothum Thodi
2019-02-27 12:55 ` [Qemu-arm] " Shameerali Kolothum Thodi
2019-02-27 12:55 ` [Qemu-devel] " Shameerali Kolothum Thodi
2019-02-27 16:42 ` Igor Mammedov
2019-02-27 16:42 ` Igor Mammedov
2019-02-27 20:14 ` [Qemu-arm] " Laszlo Ersek
2019-02-27 20:14 ` [Qemu-devel] " Laszlo Ersek
2019-02-28 10:12 ` [Qemu-arm] " Auger Eric
2019-02-28 10:12 ` [Qemu-devel] " Auger Eric
2019-02-28 12:04 ` [Qemu-arm] " Shameerali Kolothum Thodi
2019-02-28 12:04 ` [Qemu-devel] " Shameerali Kolothum Thodi
2019-02-28 12:27 ` [Qemu-arm] " Laszlo Ersek
2019-02-28 12:27 ` [Qemu-devel] " Laszlo Ersek
2019-02-28 13:32 ` [Qemu-arm] " Auger Eric
2019-02-28 13:32 ` [Qemu-devel] " Auger Eric
2019-02-28 13:43 ` [Qemu-arm] " Igor Mammedov
2019-02-28 13:43 ` [Qemu-devel] " Igor Mammedov
2019-02-28 14:02 ` [Qemu-arm] " Shameerali Kolothum Thodi
2019-02-28 14:02 ` [Qemu-devel] " Shameerali Kolothum Thodi
2019-03-01 13:49 ` Laszlo Ersek
2019-03-01 13:49 ` Laszlo Ersek
2019-03-01 17:39 ` [Qemu-arm] " Igor Mammedov
2019-03-01 17:39 ` [Qemu-devel] " Igor Mammedov
2019-03-05 12:14 ` [Qemu-arm] " Laszlo Ersek
2019-03-05 12:14 ` [Qemu-devel] " Laszlo Ersek
2019-02-25 9:47 ` [Qemu-arm] " Shameerali Kolothum Thodi
2019-02-25 9:47 ` [Qemu-devel] " 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=20190228174424.1cae71b8@redhat.com \
--to=imammedo@redhat.com \
--cc=eric.auger@redhat.com \
--cc=linuxarm@huawei.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--cc=qemu-devel@nongnu.org \
--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: link
Be 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.