linux-kernel - Re: [ACPIHP PATCH part1 1/4] ACPIHP: introduce a framework for ACPI based system device hotplug

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAErSpo6RQk+sdeOF7c+G2qp5iYgrnQcx+rD0f8eVNRPLRoLpdg@mail.gmail.com>
Date:	Mon, 5 Nov 2012 14:05:24 -0700
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Jiang Liu <liuj97@...il.com>
Cc:	"Rafael J . Wysocki" <rjw@...k.pl>,
	Yinghai Lu <yinghai@...nel.org>,
	Tony Luck <tony.luck@...el.com>,
	Yasuaki Ishimatsu <isimatu.yasuaki@...fujitsu.com>,
	Wen Congyang <wency@...fujitsu.com>,
	Tang Chen <tangchen@...fujitsu.com>,
	Taku Izumi <izumi.taku@...fujitsu.com>,
	Jiang Liu <jiang.liu@...wei.com>,
	Kenji Kaneshige <kaneshige.kenji@...fujitsu.com>,
	Huang Ying <ying.huang@...el.com>,
	Bob Moore <robert.moore@...el.com>,
	Len Brown <lenb@...nel.org>,
	"Srivatsa S . Bhat" <srivatsa.bhat@...ux.vnet.ibm.com>,
	Yijing Wang <wangyijing@...wei.com>,
	Hanjun Guo <guohanjun@...wei.com>,
	linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
	linux-pci@...r.kernel.org, linux-mm@...ck.org,
	Gaohuai Han <hangaohuai@...wei.com>
Subject: Re: [ACPIHP PATCH part1 1/4] ACPIHP: introduce a framework for ACPI
 based system device hotplug

On Sat, Nov 3, 2012 at 10:07 AM, Jiang Liu <liuj97@...il.com> wrote:
> Modern high-end servers may support advanced RAS features, such as
> system device dynamic reconfiguration. On x86 and IA64 platforms,
> system device means processor(CPU), memory device, PCI host bridge
> and even computer node.
>
> The ACPI specifications have provided standard interfaces between
> firmware and OS to support device dynamic reconfiguraiton at runtime.
> This patch series introduces a new framework for system device
> dynamic reconfiguration based on ACPI specification, which will
> replace current existing system device hotplug logic embedded in
> ACPI processor/memory/container device drivers.
>
> The new ACPI based hotplug framework is modelled after the PCI hotplug
> architecture and target to achieve following goals:
> 1) Optimize device configuration order to achieve best performance for
>    hot-added system devices. For best perforamnce, system device should
>    be configured in order of memory -> CPU -> IOAPIC/IOMMU -> PCI HB.
> 2) Resolve dependencies among hotplug slots. You need first to remove
>    the memory device before removing a physical processor if a
>    hotpluggable memory device is connected to a hotpluggable physical
>    processor.

Doesn't the namespace already have a way to communicate these dependencies?

> 3) Provide interface to cancel ongoing hotplug operations. It may take
>    a very long time to remove a memory device, so provide interface to
>    cancel the inprogress hotplug operations.
> 4) Support new advanced RAS features, such as socket/memory migration.
> 5) Provide better user interfaces to access the hotplug functionalities.
> 6) Provide a mechanism to detect hotplug slots by checking existence
>    of ACPI _EJ0 method or by other hardware platform specific methods.

I don't know what "hotplug slot" means for ACPI.  ACPI allows hotplug
of arbitrary devices in the namespace, whether they have EJ0 or not.

> 7) Unify the way to enumerate ACPI based hotplug slots. All hotplug
>    slots will be enumerated by the enumeration driver (acpihp_slot),
>    instead of by individual ACPI device drivers.

Why do we need to enumerate these "slots" specifically?

I think this patch adds things in /sys.  It might help if you
described what they are.

> 8) Unify the way to handle ACPI hotplug events. All ACPI hotplug events
>    for system devices will be handled by a generic ACPI hotplug driver
>    (acpihp_drv) instead of by individual ACPI device drivers.
> 9) Provide better error handling and error recovery.
> 10) Trigger hotplug events/operations by software. This feature is useful
>    for hardware fault management and/or power saving.
>
> The new framework is composed up of three major components:
> 1) A system device hotplug slot enumerator driver, which enumerates
>    hotplug slots in the system and provides platform specific methods
>    to control those slots.
> 2) A system device hotplug driver, which is a platform independent
>    driver to manage all hotplug slots created by the slot enumerator.
>    The hotplug driver implements a state machine for hotplug slots and
>    provides user interfaces to manage hotplug slots.
> 3) Several ACPI device drivers to configure/unconfigure system devices
>    at runtime.
>
> To get rid of inter dependengcy between the slot enumerator and hotplug
> driver, common code shared by them will be built into the kernel. The
> shared code provides some helper routines and a device class named
> acpihp_slot_class with following default sysfs properties:
>         capabilities: RAS capabilities of the hotplug slot
>         state: current state of the hotplug slot state machine
>         status: current health status of the hotplug slot
>         object: ACPI object corresponding to the hotplug slot
>
> Signed-off-by: Jiang Liu <jiang.liu@...wei.com>
> Signed-off-by: Gaohuai Han <hangaohuai@...wei.com>

...
> +static char *acpihp_dev_mem_ids[] = {
> +       "PNP0C80",
> +       NULL
> +};
> +
> +static char *acpihp_dev_pcihb_ids[] = {
> +       "PNP0A03",
> +       NULL
> +};

Why should this driver need to know about these PNP IDs?  We ought to
be able to support hotplug of any device in the namespace, no matter
what its ID.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/