Re: [PATCH 3/3] powerpc/pseries: Expose post-migration in kernel device tree update to drmgr

2015-03-03 Thread Tyrel Datwyler
On 03/02/2015 10:24 PM, Michael Ellerman wrote:
 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?

The problem is that this sysfs entry was originally added with the
remainder of the in kernel device tree update code in 2.6.37, but drmgr
was never modified to use it. By the time I started looking at the
in-kernel device tree code I found it very broken. I had bunch of fixes
to get it working that went into 3.12.

So, if somebody were to use a newer version of drmgr that simply checks
for the existence of the migration sysfs entry on a pre-3.12 kernel
their device-tree update experience is going to be sub-par.

The approach taken here is identical to what was done in 9da3489 when we
hooked the device tree update code into the suspend code. However, in
that case we were already using the sysfs entry to trigger the suspend
and legitimately needed a way to tell drmgr the kernel was now taking
care of updating the device tree. Here we are really just trying to
inform drmgr that it is running on a new enough kernel that the kernel
device tree code actually works properly.

Now, I don't really care for this approach, but the only other thought I
had was to change the sysfs entry from migration to migrate.

-Tyrel

 
 cheers
 
 

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 3/3] powerpc/pseries: Expose post-migration in kernel device tree update to drmgr

2015-03-02 Thread Michael Ellerman
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


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH 3/3] powerpc/pseries: Expose post-migration in kernel device tree update to drmgr

2015-02-27 Thread Tyrel Datwyler
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.

Signed-off-by: Tyrel Datwyler tyr...@linux.vnet.ibm.com
---
 arch/powerpc/platforms/pseries/mobility.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/platforms/pseries/mobility.c 
b/arch/powerpc/platforms/pseries/mobility.c
index 0b1f70e..a689f74 100644
--- a/arch/powerpc/platforms/pseries/mobility.c
+++ b/arch/powerpc/platforms/pseries/mobility.c
@@ -40,6 +40,9 @@ struct update_props_workarea {
 
 #define MIGRATION_SCOPE(1)
 
+#define USER_DT_UPDATE  0
+#define KERN_DT_UPDATE  1
+
 static int mobility_rtas_call(int token, char *buf, s32 scope)
 {
int rc;
@@ -339,7 +342,13 @@ static ssize_t migrate_store(struct class *class, struct 
class_attribute *attr,
return count;
 }
 
-static CLASS_ATTR(migration, S_IWUSR, NULL, migrate_store);
+static ssize_t migrate_show(struct class *class, struct class_attribute *attr,
+   char *buf)
+{
+   return sprintf(buf, %d\n, KERN_DT_UPDATE);
+}
+
+static CLASS_ATTR(migration, S_IWUSR | S_IRUGO, migrate_show, migrate_store);
 
 static int __init mobility_sysfs_init(void)
 {
-- 
1.7.12.2

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev