From: Michael Ellerman <mpe@ellerman•id.au>
To: Tyrel Datwyler <tyreld@linux•vnet.ibm.com>
Cc: linuxppc-dev@lists•ozlabs.org, cyrilbur@gmail•com,
nfont@linux•vnet.ibm.com
Subject: Re: [PATCH 3/3] powerpc/pseries: Expose post-migration in kernel device tree update to drmgr
Date: Tue, 03 Mar 2015 17:24:03 +1100 [thread overview]
Message-ID: <1425363843.20929.2.camel@ellerman.id.au> (raw)
In-Reply-To: <1425090283-27694-4-git-send-email-tyreld@linux.vnet.ibm.com>
On Fri, 2015-02-27 at 18:24 -0800, Tyrel Datwyler wrote:
> Traditionally after a migration operation drmgr has coordinated the device tree
> update with the kernel in userspace via the ugly /proc/ppc64/ofdt interface. This
> can be better done fully in the kernel where support already exists. Currently,
> drmgr makes a faux ibm,suspend-me RTAS call which we intercept in the kernel so
> that we can check VASI state for suspendability. After the LPAR resumes and
> returns to drmgr that is followed by the necessary update-nodes and
> update-properties RTAS calls which are parsed and communitated back to the kernel
> through /proc/ppc64/ofdt for the device tree update. The drmgr tool should
> instead initiate the migration using the already existing
> /sysfs/kernel/mobility/migration entry that performs all this work in the kernel.
>
> This patch adds a show function to the sysfs "migration" attribute that returns
> 1 to indicate the kernel will perform the device tree update after a migration
> operation and that drmgr should initiated the migration through the sysfs
> "migration" attribute.
I don't understand why we need this?
Can't drmgr just check if /sysfs/kernel/mobility/migration exists, and if so it
knows it should use it and that the kernel will handle the whole procedure?
cheers
next prev parent reply other threads:[~2015-03-03 6:24 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-28 2:24 [PATCH 0/3] powerpc/pseries: Fixes and cleanup of suspend/migration code Tyrel Datwyler
2015-02-28 2:24 ` [PATCH 1/3] powerpc/pseries: Simplify check for suspendability during suspend/migration Tyrel Datwyler
2015-03-02 4:19 ` Cyril Bur
2015-03-02 21:30 ` Tyrel Datwyler
2015-03-03 6:15 ` Michael Ellerman
2015-03-03 20:16 ` Tyrel Datwyler
2015-03-04 15:58 ` Nathan Fontenot
2015-02-28 2:24 ` [PATCH 2/3] powerpc/pseries: Little endian fixes for post mobility device tree update Tyrel Datwyler
2015-03-02 5:20 ` Cyril Bur
2015-03-02 21:49 ` Tyrel Datwyler
2015-03-03 23:15 ` Tyrel Datwyler
2015-03-04 1:20 ` Cyril Bur
2015-03-04 1:41 ` Tyrel Datwyler
2015-02-28 2:24 ` [PATCH 3/3] powerpc/pseries: Expose post-migration in kernel device tree update to drmgr Tyrel Datwyler
2015-03-03 6:24 ` Michael Ellerman [this message]
2015-03-03 21:18 ` Tyrel Datwyler
2015-03-03 6:10 ` [PATCH 0/3] powerpc/pseries: Fixes and cleanup of suspend/migration code Michael Ellerman
2015-03-03 20:37 ` Tyrel Datwyler
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=1425363843.20929.2.camel@ellerman.id.au \
--to=mpe@ellerman$(echo .)id.au \
--cc=cyrilbur@gmail$(echo .)com \
--cc=linuxppc-dev@lists$(echo .)ozlabs.org \
--cc=nfont@linux$(echo .)vnet.ibm.com \
--cc=tyreld@linux$(echo .)vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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