On Wed, 2013-11-06 at 13:44 +0100, Igor Mammedov wrote: > On Tue, 5 Nov 2013 12:20:29 +0200 > Vasilis Liaskovitis <vasilis.liaskovitis@xxxxxxxxxxxxxxxx> wrote: > > > Hi Toshi, > > > > On Mon, Nov 04, 2013 at 01:26:14PM -0700, Toshi Kani wrote: > > > On Mon, 2013-11-04 at 11:51 +0100, Vasilis Liaskovitis wrote: > > > > Any comment on this? > > > > > > > > On Fri, Oct 25, 2013 at 11:32:10AM +0200, Vasilis Liaskovitis wrote: > > > > > This patch adds a _PXM object to seabios CPU objects. The _PXM value is derived > > > > > from CPU SRAT entries, so build_ssdt needs to be called after build_srat for > > > > > this to work. > > > > > > > > > > The motivation for this patch is a CPU hot-unplug/hot-plug bug observed when > > > > > using seabios and a 3.11 linux guest kernel on a multi-NUMA node qemu/kvm VM. > > > > > The linux guest kernel parses the SRAT CPU entries at boot time and stores them > > > > > in the array __apicid_to_node. When a CPU is hot-removed, the linux guest kernel > > > > > resets the removed CPU's __apicid_to_node entry to NO_NUMA_NODE (kernel commit > > > > > c4c60524). When the removed cpu is hot-added again, the linux kernel looks up > > > > > the hot-added cpu object's _PXM value instead of somehow re-using the SRAT > > > > > entry info (acpi_map_cpu2node calls acpi_get_node which calls acpi_get_pxm). If > > > > > the _PXM value is not found, the CPU is assumed to be on node 0, and it is > > > > > hot-plugged in the wrong NUMA node. > > > > > > > > > > Which is the preferred OSPM way of looking up a CPU's proximity info at hotplug > > > > > time? Is it the CPU object's _PXM value, or the already-parsed CPU SRAT entry? > > > > > Or maybe both ways are valid? > > > > > > SRAT describes proximity values at boot-time. During hotplug, the > > > kernel is supposed to obtain the current proximity value from _PXM > > > method. > quoting ACPI spec 5.0 (5.2.16 System Resource Affinity Table (SRAT)): > "If the Local APIC ID / Local SAPIC ID / Local x2APIC ID > of a dynamically added processor is not present in the SRAT, a _PXM object must exist for the > processor’s device or one of its ancestors in the ACPI Namespace." > > so _PXM in not MUST have if there is entry for device in SRAT table and it seems Seabios > builds table with possible CPUs included, so kernel just don't use already present info. > Perhaps kernel should be fixed (i.e take affinity from SRAT table first and > override value with _PXM if present). I think the above statement is to emphasize the need of _PXM for hotplug, but I will check the intention of the statement. Here is a quote from ACPI 5.0, which restates what I said before. === 17.2.1 System Resource Affinity Table Definition This optional System Resource Affinity Table (SRAT) provides the boot time description of the processor and memory ranges belonging to a system locality. OSPM will consume the SRAT only at boot time. OSPM should use _PXM for any devices that are hot-added into the system after boot up. ==== Thanks, -Toshi -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html