From: Vasilis Liaskovitis <vasilis.liaskovitis@profitbricks.com>
To: Toshi Kani <toshi.kani@hp.com>
Cc: seabios@seabios.org, linux-acpi@vger.kernel.org,
kevin@koconnor.net, rjw@sisk.pl, wency@cn.fujitsu.com,
thilo.fromm@profitbricks.com
Subject: Re: [RFC PATCH][SeaBIOS] Add _PXM to CPU objects for NUMA hot-plug
Date: Tue, 5 Nov 2013 12:20:29 +0200 [thread overview]
Message-ID: <20131105102029.GA3933@shadowkeep> (raw)
In-Reply-To: <1383596774.1847.12.camel@misato.fc.hp.com>
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.
thanks for the clarification.
>
> > > This issue may require a kernel fix alternatively or additionally to the seabios
> > > fix: The kernel can save the originally parsed SRAT entry info somewhere before
> > > it resets it at hot-remove time, and use that info on hot-plug time if the _PXM
> > > value is missing for the hot-plugged CPU BIOS object. This way CPU hot-plug
> > > works well against a BIOS with no CPU _PXM info.
>
> To support CPU hotplug, seabios needs to implement _PXM to CPU or its
> parent device object when the system has multiple nodes.
ok, so no linux kernel changes are needed. Only adding PXM to seabios CPUs
objects should be enough, which is what this RFC patch does.
thanks,
- Vasilis
>
>
>
>
next prev parent reply other threads:[~2013-11-05 10:20 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-25 9:32 [RFC PATCH][SeaBIOS] Add _PXM to CPU objects for NUMA hot-plug Vasilis Liaskovitis
2013-11-04 10:51 ` Vasilis Liaskovitis
2013-11-04 20:26 ` Toshi Kani
2013-11-05 10:20 ` Vasilis Liaskovitis [this message]
2013-11-06 12:44 ` [SeaBIOS] [RFC PATCH] " Igor Mammedov
2013-11-06 16:30 ` Toshi Kani
2013-11-06 12:54 ` Igor Mammedov
2013-11-06 2:52 ` Kevin O'Connor
2013-11-07 10:11 ` [RFC PATCH][SeaBIOS] " Vasilis Liaskovitis
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=20131105102029.GA3933@shadowkeep \
--to=vasilis.liaskovitis@profitbricks.com \
--cc=kevin@koconnor.net \
--cc=linux-acpi@vger.kernel.org \
--cc=rjw@sisk.pl \
--cc=seabios@seabios.org \
--cc=thilo.fromm@profitbricks.com \
--cc=toshi.kani@hp.com \
--cc=wency@cn.fujitsu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).