[0/5] sys_move_pages() updates

[0/5] sys_move_pages() updates

[Christoph Lameter]

These patches are against 2.6.17-rc4-mm3 and complete
the implementation of sys_move_pages().

1. Fix brokenness in follow_page introduced with the dirty pages patch.

2. Extract common permissions check

3. Fixups sys_move_pages()

4. x86_64 support

5. 32 bit support for i386, x86_64 and ia64.

[1/5] follow_page: do not put_page if FOLL_GET not specified.

[Christoph Lameter]

follow: no put_page() if FOLL_GET not specified.

Seems that one of the side effects of the dirty pages patch in
2.6.17-rc4-mm3 is that follow_pages does a page_put if FOLL_GET is
not set in the flags passed to it. This breaks sys_move_pages()
page status determination.

Only put_page if we did a get_page() before.

Signed-off-by: Christoph Lameter <clameter@sgi.com>
Index: linux-2.6.17-rc4-mm3/mm/memory.c
=================================--- linux-2.6.17-rc4-mm3.orig/mm/memory.c	2006-05-22 18:03:32.280767264 -0700
+++ linux-2.6.17-rc4-mm3/mm/memory.c	2006-05-23 10:01:48.917295988 -0700
@@ -964,7 +964,7 @@ struct page *follow_page(struct vm_area_
 			set_page_dirty(page);
 		mark_page_accessed(page);
 	}
-	if (!(flags & FOLL_GET))
+	if (!(flags & FOLL_GET) && (flags & FOLL_TOUCH))
 		put_page(page);
 	goto out;
 

[2/5] extract common code to have_task_perm()

[Christoph Lameter]

Extract have_task_perm()

Various kernel function check if they are allowed to do something to another
task. The ones that I have found are

1. The check for kill permissions

2. sys_migrate_pages() checking if a process is allowed to
   migrate the pages of another process.

3. sys_move_pages() checking if a process is allowed to
   migrate individual pages that are part of another process.

Extract the common code in these checks to form a new function
in kernel/signal.c have_task_perm(task, capability). The check
is successful if

1. The current process has the indicated capability

2. The current effective userid is equal to the suid or uid
   of the target process.

3. The current userid is equal to the suid or uid of the
   target process.

Note that there are similar checks for uid/gid/euid that are
stored in a variety of structures in the kernel. Maybe those may also
be extracted by a similar function that would not take a task parameter
but an explicit specification of permission ids?

ptrace() has a variation on the have_task_perm() check in may_attach().
ptrace checks for uid equal to euid, suid, uid or gid equal to
egid sgid,gid. So one may not be able to kill a process explicyly
but be able to ptrace() (and then PTRACE_KILL it) if one is a member
of the same group? Weird.

Plus ptrace does not support eid comparision. So explicit rights
for ptracing cannot be set via the super user bit.

Maybe we could consolidate all these checks and make them work in
a coherent way? I dont think I am deep enough into this issue to
takle that though.

Signed-off-by: Christoph Lameter <clameter@sgi.com>

Index: linux-2.6.17-rc4-mm3/mm/mempolicy.c
=================================--- linux-2.6.17-rc4-mm3.orig/mm/mempolicy.c	2006-05-22 18:03:32.283696770 -0700
+++ linux-2.6.17-rc4-mm3/mm/mempolicy.c	2006-05-23 08:55:24.371254745 -0700
@@ -926,15 +926,7 @@ asmlinkage long sys_migrate_pages(pid_t 
 	if (!mm)
 		return -EINVAL;
 
-	/*
-	 * Check if this process has the right to modify the specified
-	 * process. The right exists if the process has administrative
-	 * capabilities, superuser privileges or the same
-	 * userid as the target process.
-	 */
-	if ((current->euid != task->suid) && (current->euid != task->uid) &&
-	    (current->uid != task->suid) && (current->uid != task->uid) &&
-	    !capable(CAP_SYS_NICE)) {
+	if (!have_task_perm(task, CAP_SYS_NICE)) {
 		err = -EPERM;
 		goto out;
 	}
Index: linux-2.6.17-rc4-mm3/mm/migrate.c
=================================--- linux-2.6.17-rc4-mm3.orig/mm/migrate.c	2006-05-22 18:03:32.286626275 -0700
+++ linux-2.6.17-rc4-mm3/mm/migrate.c	2006-05-23 08:55:24.372231247 -0700
@@ -781,15 +781,7 @@ asmlinkage long sys_move_pages(int pid, 
 	if (!mm)
 		return -EINVAL;
 
-	/*
-	 * Check if this process has the right to modify the specified
-	 * process. The right exists if the process has administrative
-	 * capabilities, superuser privileges or the same
-	 * userid as the target process.
-	 */
-	if ((current->euid != task->suid) && (current->euid != task->uid) &&
-	    (current->uid != task->suid) && (current->uid != task->uid) &&
-	    !capable(CAP_SYS_NICE)) {
+	if (!have_task_perm(task, CAP_SYS_NICE)) {
 		err = -EPERM;
 		goto out2;
 	}
Index: linux-2.6.17-rc4-mm3/kernel/signal.c
=================================--- linux-2.6.17-rc4-mm3.orig/kernel/signal.c	2006-05-22 18:03:32.211435632 -0700
+++ linux-2.6.17-rc4-mm3/kernel/signal.c	2006-05-23 09:11:44.323266538 -0700
@@ -567,6 +567,25 @@ static int rm_from_queue(unsigned long m
 }
 
 /*
+ * Check if this process has the rights to do something
+ * with another process.
+ *
+ * The right exists if either
+ * 1. The current process has the indicated capability
+ * 2. The current effective user id is the user or superuser
+ * 	id of the other process.
+ * 3. The current user id is the user or superuser id of the other process.
+ */
+int have_task_perm(struct task_struct *t, int capability)
+{
+	if (capable(capability))
+		return 1;
+
+	return (current->euid = t->suid || current->euid = t->uid ||
+		  current->uid = t->suid || current->uid = t->uid);
+}
+
+/*
  * Bad permissions for sending the signal
  */
 static int check_kill_permission(int sig, struct siginfo *info,
@@ -579,9 +598,7 @@ static int check_kill_permission(int sig
 	if ((info = SEND_SIG_NOINFO || (!is_si_special(info) && SI_FROMUSER(info)))
 	    && ((sig != SIGCONT) ||
 		(current->signal->session != t->signal->session))
-	    && (current->euid ^ t->suid) && (current->euid ^ t->uid)
-	    && (current->uid ^ t->suid) && (current->uid ^ t->uid)
-	    && !capable(CAP_KILL))
+	    && !have_task_perm(t, CAP_KILL))
 		return error;
 
 	error = security_task_kill(t, info, sig);
Index: linux-2.6.17-rc4-mm3/include/linux/signal.h
=================================--- linux-2.6.17-rc4-mm3.orig/include/linux/signal.h	2006-05-22 18:03:31.841341429 -0700
+++ linux-2.6.17-rc4-mm3/include/linux/signal.h	2006-05-23 08:55:24.393714292 -0700
@@ -267,6 +267,8 @@ extern int sigprocmask(int, sigset_t *, 
 struct pt_regs;
 extern int get_signal_to_deliver(siginfo_t *info, struct k_sigaction *return_ka, struct pt_regs *regs, void *cookie);
 
+extern int have_task_perm(struct task_struct *, int);
+
 #endif /* __KERNEL__ */
 
 #endif /* _LINUX_SIGNAL_H */

[3/5] move_pages: lots of fixups

[Christoph Lameter]

Fix up sys_move_pages()

1. Update comments and documentation.
2. Make the page array passed to sys_move_pages void **
3. Check for boundary conditions on the size of the pm array.
4. Use vmalloc for page array instead of kmalloc().
5. Process parameters before taking mmap_sem
6. Add the required call to migrate_prep().
7. Extract a couple of functions to simplify the function.
8. Add function prototype in include/linux/syscalls.h
9. Disambiguify the page status codes and the return code
   of the function.
10. Do not migrate reserved pages (zero pages etc)

Updated description of the function call:

move_pages() is used to move individual pages of a process. The function can
be used to determine the location of pages and to move them onto the desired
node. move_pages() returns status information for each page.

long move_pages(pid, number_of_pages_to_move,
		addresses_of_pages[],
		nodes[] or NULL,
		status[],
		flags);

The addresses of pages is an array of void * pointing to the
pages to be moved.

The nodes array contains the node numbers that the pages should be moved
to. If a NULL is passed instead of an array then no pages are moved but
the status array is updated. The status request may be used to determine
the page state before issuing another move_pages() to move pages.

The status array will contain the state of all individual page migration
attempts when the function terminates. The status array is only valid if
move_pages() completed successfullly.

Possible page states in status[]:

0..MAX_NUMNODES	The page is now on the indicated node.

-ENOENT		Page is not present

-EACCES		Page is mapped by multiple processes and can only
		be moved if MPOL_MF_MOVE_ALL is specified.

-EPERM		The page has been mlocked by a process/driver and
		cannot be moved.

-EBUSY		Page is busy and cannot be moved. Try again later.

-EFAULT		Invalid address (no VMA or zero page).

-ENOMEM		Unable to allocate memory on target node.

-EIO		Unable to write back page. The page must be written
		back in order to move it since the page is dirty and the
		filesystem does not provide a migration function that
		would allow the moving of dirty pages.

-EINVAL		A dirty page cannot be moved. The filesystem does not provide
		a migration function and has no ability to write back pages.

The flags parameter indicates what types of pages to move:

MPOL_MF_MOVE	Move pages that are only mapped by the process.

MPOL_MF_MOVE_ALL Also move pages that are mapped by multiple processes.
		Requires sufficient capabilities.

Possible return codes from move_pages()

-ENOENT		No pages found that would require moving. All pages
		are either already on the target node, not present, had an
		invalid address or could not be moved because they were
		mapped by multiple processes.

-EINVAL		Flags other than MPOL_MF_MOVE(_ALL) specified or an attempt
		to migrate pages in a kernel thread.

-EPERM		MPOL_MF_MOVE_ALL specified without sufficient priviledges.
		or an attempt to move a process belonging to another user.

-EACCES		One of the target nodes is not allowed by the current cpuset.

-ENODEV		One of the target nodes is not online.

-ESRCH		Process does not exist.

-E2BIG		Too many pages to move.

-ENOMEM		Not enough memory to allocate control array.

-EFAULT		Parameters could not be accessed.

A test program for move_pages() may be found with the patches
on ftp.kernel.org:/pub/linux/kernel/people/christoph/pmig/patches-2.6.17-rc4-mm3

Signed-off-by: Christoph Lameter <clameter@sgi.com>

Index: linux-2.6.17-rc4-mm3/mm/migrate.c
=================================--- linux-2.6.17-rc4-mm3.orig/mm/migrate.c	2006-05-23 10:03:29.156194729 -0700
+++ linux-2.6.17-rc4-mm3/mm/migrate.c	2006-05-23 10:09:50.473360098 -0700
@@ -26,6 +26,7 @@
 #include <linux/cpuset.h>
 #include <linux/writeback.h>
 #include <linux/mempolicy.h>
+#include <linux/vmalloc.h>
 
 #include "internal.h"
 
@@ -63,9 +64,8 @@ int isolate_lru_page(struct page *page, 
 }
 
 /*
- * migrate_prep() needs to be called after we have compiled the list of pages
- * to be migrated using isolate_lru_page() but before we begin a series of calls
- * to migrate_pages().
+ * migrate_prep() needs to be called before we start compiling a list of pages
+ * to be migrated using isolate_lru_page().
  */
 int migrate_prep(void)
 {
@@ -723,6 +723,7 @@ out:
  * Move a list of individual pages
  */
 struct page_to_node {
+	unsigned long addr;
 	struct page *page;
 	int node;
 	int status;
@@ -733,10 +734,10 @@ static struct page *new_page_node(struct
 {
 	struct page_to_node *pm = (struct page_to_node *)private;
 
-	while (pm->page && pm->page != p)
+	while (pm->node != MAX_NUMNODES && pm->page != p)
 		pm++;
 
-	if (!pm->page)
+	if (pm->node = MAX_NUMNODES)
 		return NULL;
 
 	*result = &pm->status;
@@ -745,11 +746,122 @@ static struct page *new_page_node(struct
 }
 
 /*
+ * Move a set of pages as indicated in the pm array. The addr
+ * field must be set to the virtual address of the page to be moved
+ * and the node number must contain a valid target node.
+ */
+static int do_move_pages(struct mm_struct *mm, struct page_to_node *pm,
+				int migrate_all)
+{
+	int err;
+	struct page_to_node *pp;
+	LIST_HEAD(pagelist);
+
+	down_read(&mm->mmap_sem);
+
+	/*
+	 * Build a list of pages to migrate
+	 */
+	migrate_prep();
+	for (pp = pm; pp->node != MAX_NUMNODES; pp++) {
+		struct vm_area_struct *vma;
+		struct page *page;
+
+		/*
+		 * A valid page pointer that will not match any of the
+		 * pages that will be moved.
+		 */
+		pp->page = ZERO_PAGE(0);
+
+		err = -EFAULT;
+		vma = find_vma(mm, pp->addr);
+		if (!vma)
+			goto set_status;
+
+		page = follow_page(vma, pp->addr, FOLL_GET);
+		err = -ENOENT;
+		if (!page)
+			goto set_status;
+
+		if (PageReserved(page))		/* Check for zero page */
+			goto put_and_set;
+
+		pp->page = page;
+		err = page_to_nid(page);
+
+		if (err = pp->node)
+			/*
+			 * Node already in the right place
+			 */
+			goto put_and_set;
+
+		err = -EACCES;
+		if (page_mapcount(page) > 1 &&
+				!migrate_all)
+			goto put_and_set;
+
+		err = isolate_lru_page(page, &pagelist);
+put_and_set:
+		/*
+		 * Either remove the duplicate refcount from
+		 * isolate_lru_page() or drop the page ref if it was
+		 * not isolated.
+		 */
+		put_page(page);
+set_status:
+		pp->status = err;
+	}
+
+	if (!list_empty(&pagelist))
+		err = migrate_pages(&pagelist, new_page_node,
+				(unsigned long)pm);
+	else
+		err = -ENOENT;
+
+	up_read(&mm->mmap_sem);
+	return err;
+}
+
+/*
+ * Determine the nodes of a list of pages. The addr in the pm array
+ * must have been set to the virtual address of which we want to determine
+ * the node number.
+ */
+static int do_pages_stat(struct mm_struct *mm, struct page_to_node *pm)
+{
+	down_read(&mm->mmap_sem);
+
+	for ( ; pm->node != MAX_NUMNODES; pm++) {
+		struct vm_area_struct *vma;
+		struct page *page;
+		int err;
+
+		err = -EFAULT;
+		vma = find_vma(mm, pm->addr);
+		if (!vma)
+			goto set_status;
+
+		page = follow_page(vma, pm->addr, 0);
+		err = -ENOENT;
+		/* Use PageReserved to check for zero page */
+		if (!page || PageReserved(page))
+			goto set_status;
+
+		err = page_to_nid(page);
+set_status:
+		pm->status = err;
+	}
+
+	up_read(&mm->mmap_sem);
+	return 0;
+}
+
+/*
  * Move a list of pages in the address space of the currently executing
  * process.
  */
-asmlinkage long sys_move_pages(int pid, unsigned long nr_pages,
-			const unsigned long __user *pages,
+asmlinkage long sys_move_pages(pid_t pid, unsigned long nr_pages,
+			const void __user * __user *pages,
 			const int __user *nodes,
 			int __user *status, int flags)
 {
@@ -759,7 +871,6 @@ asmlinkage long sys_move_pages(int pid, 
 	nodemask_t task_nodes;
 	struct mm_struct *mm;
 	struct page_to_node *pm = NULL;
-	LIST_HEAD(pagelist);
 
 	/* Check flags */
 	if (flags & ~(MPOL_MF_MOVE|MPOL_MF_MOVE_ALL))
@@ -787,99 +898,64 @@ asmlinkage long sys_move_pages(int pid, 
 	}
 
 	task_nodes = cpuset_mems_allowed(task);
-	pm = kmalloc(GFP_KERNEL, (nr_pages + 1) * sizeof(struct page_to_node));
+
+	/* Limit nr_pages so that the multiplication may not overflow */
+	if (nr_pages >= ULONG_MAX / sizeof(struct page_to_node) - 1) {
+		err = -E2BIG;
+		goto out2;
+	}
+
+	pm = vmalloc((nr_pages + 1) * sizeof(struct page_to_node));
 	if (!pm) {
 		err = -ENOMEM;
 		goto out2;
 	}
 
-	down_read(&mm->mmap_sem);
-
-	for(i = 0 ; i < nr_pages; i++) {
-		unsigned long addr;
-		int node;
-		struct vm_area_struct *vma;
-		struct page *page;
-
-		pm[i].page = ZERO_PAGE(0);
+	/*
+	 * Get parameters from user space and initialize the pm
+	 * array. Return various errors if the user did something wrong.
+	 */
+	for (i = 0; i < nr_pages; i++) {
+		const void *p;
 
 		err = -EFAULT;
-		if (get_user(addr, pages + i))
-			goto putback;
-
-		vma = find_vma(mm, addr);
-		if (!vma)
-			goto set_status;
+		if (get_user(p, pages + i))
+			goto out;
 
-		page = follow_page(vma, addr, FOLL_GET);
-		err = -ENOENT;
-		if (!page)
-			goto set_status;
-
-		pm[i].page = page;
-		if (!nodes) {
-			err = page_to_nid(page);
-			put_page(page);
-			goto set_status;
-		}
+		pm[i].addr = (unsigned long)p;
+		if (nodes) {
+			int node;
 
-		err = -EPERM;
-		if (page_mapcount(page) > 1 &&
-				!(flags & MPOL_MF_MOVE_ALL)) {
-			put_page(page);
-			goto set_status;
-		}
-
-
-		err = isolate_lru_page(page, &pagelist);
-		__put_page(page);
-		if (err)
-			goto remove;
-
-		err = -EFAULT;
-		if (get_user(node, nodes + i))
-			goto remove;
-
-		err = -ENOENT;
-		if (!node_online(node))
-			goto remove;
+			if (get_user(node, nodes + i))
+				goto out;
 
-		err = -EPERM;
-		if (!node_isset(node, task_nodes))
-			goto remove;
+			err = -ENODEV;
+			if (!node_online(node))
+				goto out;
 
-		pm[i].node = node;
-		err = -EAGAIN;
-		if (node != page_to_nid(page))
-			goto set_status;
+			err = -EACCES;
+			if (!node_isset(node, task_nodes))
+				goto out;
 
-		err = node;
-remove:
-		list_del(&page->lru);
-		move_to_lru(page);
-set_status:
-		pm[i].status = err;
+			pm[i].node = node;
+		}
 	}
-	err = 0;
-	if (!nodes || list_empty(&pagelist))
-		goto out;
+	/* End marker */
+	pm[nr_pages].node = MAX_NUMNODES;
 
-	pm[nr_pages].page = NULL;
-
-	err = migrate_pages(&pagelist, new_page_node, (unsigned long)pm);
-	goto out;
-
-putback:
-	putback_lru_pages(&pagelist);
+	if (nodes)
+		err = do_move_pages(mm, pm, flags & MPOL_MF_MOVE_ALL);
+	else
+		err = do_pages_stat(mm, pm);
 
-out:
-	up_read(&mm->mmap_sem);
 	if (err >= 0)
 		/* Return status information */
-		for(i = 0; i < nr_pages; i++)
-			put_user(pm[i].status, status +i);
+		for (i = 0; i < nr_pages; i++)
+			if (put_user(pm[i].status, status + i))
+				err = -EFAULT;
 
-	kfree(pm);
+out:
+	vfree(pm);
 out2:
 	mmput(mm);
 	return err;
Index: linux-2.6.17-rc4-mm3/Documentation/vm/page_migration
=================================--- linux-2.6.17-rc4-mm3.orig/Documentation/vm/page_migration	2006-05-22 18:03:26.500852784 -0700
+++ linux-2.6.17-rc4-mm3/Documentation/vm/page_migration	2006-05-23 10:03:36.021003240 -0700
@@ -26,8 +26,13 @@ a process are located. See also the numa
 Manual migration is useful if for example the scheduler has relocated
 a process to a processor on a distant node. A batch scheduler or an
 administrator may detect the situation and move the pages of the process
-nearer to the new processor. At some point in the future we may have
-some mechanism in the scheduler that will automatically move the pages.
+nearer to the new processor. The kernel itself does only provide
+manual page migration support. Automatic page migration may be implemented
+through user space processes that move pages. A special function call
+"move_pages" allows the moving of individual pages within a process.
+A NUMA profiler may f.e. obtain a log showing frequent off node
+accesses and may use the result to move pages to more advantageous
+locations.
 
 Larger installations usually partition the system using cpusets into
 sections of nodes. Paul Jackson has equipped cpusets with the ability to
@@ -62,22 +67,14 @@ A. In kernel use of migrate_pages()
    It also prevents the swapper or other scans to encounter
    the page.
 
-2. Generate a list of newly allocates pages. These pages will contain the
-   contents of the pages from the first list after page migration is
-   complete.
+2. We need to have a function of type new_page_t that can be
+   passed to migrate_pages(). This function should figure out
+   how to allocate the correct new page given the old page.
 
 3. The migrate_pages() function is called which attempts
-   to do the migration. It returns the moved pages in the
-   list specified as the third parameter and the failed
-   migrations in the fourth parameter. When the function
-   returns the first list will contain the pages that could still be retried.
-
-4. The leftover pages of various types are returned
-   to the LRU using putback_to_lru_pages() or otherwise
-   disposed of. The pages will still have the refcount as
-   increased by isolate_lru_pages() if putback_to_lru_pages() is not
-   used! The kernel may want to handle the various cases of failures in
-   different ways.
+   to do the migration. It will call the function to allocate
+   the new page for each page that is considered for
+   moving.
 
 B. How migrate_pages() works
 ----------------------------
Index: linux-2.6.17-rc4-mm3/include/linux/syscalls.h
=================================--- linux-2.6.17-rc4-mm3.orig/include/linux/syscalls.h	2006-05-22 18:03:31.876495496 -0700
+++ linux-2.6.17-rc4-mm3/include/linux/syscalls.h	2006-05-23 10:03:36.022956244 -0700
@@ -515,6 +515,11 @@ asmlinkage long sys_set_mempolicy(int mo
 asmlinkage long sys_migrate_pages(pid_t pid, unsigned long maxnode,
 				const unsigned long __user *from,
 				const unsigned long __user *to);
+asmlinkage long sys_move_pages(pid_t pid, unsigned long nr_pages,
+				const void __user * __user *pages,
+				const int __user *nodes,
+				int __user *status,
+				int flags);
 asmlinkage long sys_mbind(unsigned long start, unsigned long len,
 				unsigned long mode,
 				unsigned long __user *nmask,

[4/5] move_pages: x86_64 support

[Christoph Lameter]

sys_move_pages support for x86_64

Only compile-tested.

Signed-off-by: Christoph Lameter <clameter@sgi.com>

Index: linux-2.6.17-rc4-mm1/include/asm-x86_64/unistd.h
=================================--- linux-2.6.17-rc4-mm1.orig/include/asm-x86_64/unistd.h	2006-05-21 00:18:04.000000000 +1000
+++ linux-2.6.17-rc4-mm1/include/asm-x86_64/unistd.h	2006-05-21 00:19:33.000000000 +1000
@@ -617,10 +617,12 @@
 __SYSCALL(__NR_sync_file_range, sys_sync_file_range)
 #define __NR_vmsplice		278
 __SYSCALL(__NR_vmsplice, sys_vmsplice)
+#define __NR_move_pages		279
+__SYSCALL(__NR_move_pages, sys_move_pages)
 
 #ifdef __KERNEL__
 
-#define __NR_syscall_max __NR_vmsplice
+#define __NR_syscall_max __NR_move_pages
 
 #ifndef __NO_STUBS
 

[5/5] move_pages: 32bit support (i386,x86_64 and ia64)

[Christoph Lameter]

sys_move_pages() support for 32bit (i386 plus ia64 and x86_64 compat layers)

Add support for move_pages() on i386 and also add the
compat functions necessary to run 32 bit binaries on x86_64 and ia64.

Add compat_sys_move_pages to both the x86_64 and the ia64 32bit binary
layer. Note that both are not up to date so I added the missing pieces.
Not sure if this is done the right way.

This probably needs some fixups:

1. What about sys_vmsplice on x86_64?

2. There is a whole range of syscalls missing for ia64 that I basically
   interpolated from elsewhere.

Signed-off-by: Christoph Lameter <clameter@sgi.com>

Index: linux-2.6.17-rc4-mm3/arch/i386/kernel/syscall_table.S
=================================--- linux-2.6.17-rc4-mm3.orig/arch/i386/kernel/syscall_table.S	2006-05-11 16:31:53.000000000 -0700
+++ linux-2.6.17-rc4-mm3/arch/i386/kernel/syscall_table.S	2006-05-23 10:15:43.789358191 -0700
@@ -315,3 +315,5 @@ ENTRY(sys_call_table)
 	.long sys_splice
 	.long sys_sync_file_range
 	.long sys_tee			/* 315 */
+	.long sys_ni_syscall		/* vmsplice */
+	.long sys_move_pages
Index: linux-2.6.17-rc4-mm3/arch/x86_64/ia32/ia32entry.S
=================================--- linux-2.6.17-rc4-mm3.orig/arch/x86_64/ia32/ia32entry.S	2006-05-22 18:03:26.298716900 -0700
+++ linux-2.6.17-rc4-mm3/arch/x86_64/ia32/ia32entry.S	2006-05-23 10:15:43.791311196 -0700
@@ -699,4 +699,5 @@ ia32_sys_call_table:
 	.quad sys_sync_file_range
 	.quad sys_tee
 	.quad compat_sys_vmsplice
+	.quad compat_sys_move_pages
 ia32_syscall_end:		
Index: linux-2.6.17-rc4-mm3/include/asm-i386/unistd.h
=================================--- linux-2.6.17-rc4-mm3.orig/include/asm-i386/unistd.h	2006-05-22 18:03:30.090473603 -0700
+++ linux-2.6.17-rc4-mm3/include/asm-i386/unistd.h	2006-05-23 10:15:43.792287698 -0700
@@ -322,10 +322,11 @@
 #define __NR_sync_file_range	314
 #define __NR_tee		315
 #define __NR_vmsplice		316
+#define __NR_move_pages		317
 
 #ifdef __KERNEL__
 
-#define NR_syscalls 317
+#define NR_syscalls 318
 
 /*
  * user-visible error numbers are in the range -1 - -128: see
Index: linux-2.6.17-rc4-mm3/kernel/compat.c
=================================--- linux-2.6.17-rc4-mm3.orig/kernel/compat.c	2006-05-11 16:31:53.000000000 -0700
+++ linux-2.6.17-rc4-mm3/kernel/compat.c	2006-05-23 10:15:43.793264200 -0700
@@ -21,6 +21,7 @@
 #include <linux/unistd.h>
 #include <linux/security.h>
 #include <linux/timex.h>
+#include <linux/migrate.h>
 
 #include <asm/uaccess.h>
 
@@ -934,3 +935,25 @@ asmlinkage long compat_sys_adjtimex(stru
 
 	return ret;
 }
+
+#ifdef CONFIG_NUMA
+asmlinkage long compat_sys_move_pages(pid_t pid, unsigned long nr_pages,
+		void __user *pages32,
+		const int __user *nodes,
+		int __user *status,
+		int flags)
+{
+	const void __user * __user *pages;
+	int i;
+
+	pages = compat_alloc_user_space(nr_pages * sizeof(void *));
+	for (i = 0; i < nr_pages; i++) {
+		compat_uptr_t p;
+
+		if (get_user(p, (compat_uptr_t *)(pages32 + i)) ||
+			put_user(compat_ptr(p), pages + i))
+			return -EFAULT;
+	}
+	return sys_move_pages(pid, nr_pages, pages, nodes, status, flags);
+}
+#endif
Index: linux-2.6.17-rc4-mm3/include/linux/syscalls.h
=================================--- linux-2.6.17-rc4-mm3.orig/include/linux/syscalls.h	2006-05-23 10:03:36.022956244 -0700
+++ linux-2.6.17-rc4-mm3/include/linux/syscalls.h	2006-05-23 10:15:43.794240702 -0700
@@ -520,6 +520,11 @@ asmlinkage long sys_move_pages(pid_t pid
 				const int __user *nodes,
 				int __user *status,
 				int flags);
+asmlinkage long compat_sys_move_pages(pid_t pid, unsigned long nr_page,
+				void __user *pages,
+				const int __user *nodes,
+				int __user *status,
+				int flags);
 asmlinkage long sys_mbind(unsigned long start, unsigned long len,
 				unsigned long mode,
 				unsigned long __user *nmask,
Index: linux-2.6.17-rc4-mm3/arch/ia64/ia32/ia32_entry.S
=================================--- linux-2.6.17-rc4-mm3.orig/arch/ia64/ia32/ia32_entry.S	2006-05-11 16:31:53.000000000 -0700
+++ linux-2.6.17-rc4-mm3/arch/ia64/ia32/ia32_entry.S	2006-05-23 10:15:43.796193706 -0700
@@ -495,6 +495,39 @@ ia32_syscall_table:
   	data8 compat_sys_mq_getsetattr
 	data8 sys_ni_syscall		/* reserved for kexec */
 	data8 compat_sys_waitid
+	data8 sys_ni_syscall		/* 285: sys_altroot */
+	data8 sys_add_key
+	data8 sys_request_key
+	data8 sys_keyctl
+	data8 sys_ioprio_set
+	data8 sys_ioprio_get		/* 290 */
+	data8 sys_inotify_init
+	data8 sys_inotify_add_watch
+	data8 sys_inotify_rm_watch
+	data8 sys_migrate_pages
+	data8 compat_sys_openat		/* 295 */
+	data8 sys_mkdirat
+	data8 sys_mknodat
+	data8 sys_fchownat
+	data8 compat_sys_futimesat
+	data8 sys_ni_syscall		/* broken: sys_fstatat 300 */
+	data8 sys_unlinkat
+	data8 sys_renameat
+	data8 sys_linkat
+	data8 sys_symlinkat
+	data8 sys_readlinkat		/* 305 */
+	data8 sys_fchmodat
+	data8 sys_faccessat
+	data8 sys_ni_syscall		/* pselect6 */
+	data8 sys_ni_syscall		/* ppoll */
+	data8 sys_unshare               /* 310 */
+	data8 compat_sys_set_robust_list
+	data8 compat_sys_get_robust_list
+	data8 sys_splice
+	data8 sys_sync_file_range
+	data8 sys_tee			/* 315 */
+	data8 compat_sys_vmsplice
+	data8 compat_sys_move_pages
 
 	// guard against failures to increase IA32_NR_syscalls
 	.org ia32_syscall_table + 8*IA32_NR_syscalls
Index: linux-2.6.17-rc4-mm3/include/asm-ia64/ia32.h
=================================--- linux-2.6.17-rc4-mm3.orig/include/asm-ia64/ia32.h	2006-05-22 18:03:30.107074135 -0700
+++ linux-2.6.17-rc4-mm3/include/asm-ia64/ia32.h	2006-05-23 10:15:43.796193706 -0700
@@ -5,7 +5,7 @@
 #include <asm/ptrace.h>
 #include <asm/signal.h>
 
-#define IA32_NR_syscalls		285	/* length of syscall table */
+#define IA32_NR_syscalls		318	/* length of syscall table */
 #define IA32_PAGE_SHIFT			12	/* 4KB pages */
 
 #ifndef __ASSEMBLY__

Re: [1/5] follow_page: do not put_page if FOLL_GET not specified.

[Peter Zijlstra]

On Tue, 2006-05-23 at 10:43 -0700, Christoph Lameter wrote:
> follow: no put_page() if FOLL_GET not specified.
> 
> Seems that one of the side effects of the dirty pages patch in
> 2.6.17-rc4-mm3 is that follow_pages does a page_put if FOLL_GET is
> not set in the flags passed to it. This breaks sys_move_pages()
> page status determination.
> 
> Only put_page if we did a get_page() before.
> 
> Signed-off-by: Christoph Lameter <clameter@sgi.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>

However, Andrew dropped the patches from -mm. I'll do a new series that
incorporates the suggestions from Hugh.

> Index: linux-2.6.17-rc4-mm3/mm/memory.c
> =================================> --- linux-2.6.17-rc4-mm3.orig/mm/memory.c	2006-05-22 18:03:32.280767264 -0700
> +++ linux-2.6.17-rc4-mm3/mm/memory.c	2006-05-23 10:01:48.917295988 -0700
> @@ -964,7 +964,7 @@ struct page *follow_page(struct vm_area_
>  			set_page_dirty(page);
>  		mark_page_accessed(page);
>  	}
> -	if (!(flags & FOLL_GET))
> +	if (!(flags & FOLL_GET) && (flags & FOLL_TOUCH))
>  		put_page(page);
>  	goto out;
>  

RE: [5/5] move_pages: 32bit support (i386,x86_64 and ia64)

[Luck, Tony]

> 2. There is a whole range of syscalls missing for ia64 that I basically
>   interpolated from elsewhere.

I've been thinking of dropping CONFIG_IA32_SUPPORT completely from ia64.
I've heard no complaints that new syscalls are not being added to the
ia32 compat side ... which is an indication that people are not
actively using this.  Some OSDs have been building with this
turned off for a while now (perhaps in preparation for "Montecito"
which no longer has h/w support for the x86 instruction set, or
perhaps because it represnts a huge block of lightly/barely tested
code that will have its share of support issues).

I suppose I should do this by adding an entry to
 Documentation/feature-removal-schedule.txt

Any thoughts on the timeline for this?  Is Dec 31, 2006 too soon?
(or not soon enough!?).

-Tony

Re: [5/5] move_pages: 32bit support (i386,x86_64 and ia64)

[Andrew Morton]

"Luck, Tony" <tony.luck@intel.com> wrote:
>
> > 2. There is a whole range of syscalls missing for ia64 that I basically
> >   interpolated from elsewhere.
> 
> I've been thinking of dropping CONFIG_IA32_SUPPORT completely from ia64.
> I've heard no complaints that new syscalls are not being added to the
> ia32 compat side ... which is an indication that people are not
> actively using this.  Some OSDs have been building with this
> turned off for a while now (perhaps in preparation for "Montecito"
> which no longer has h/w support for the x86 instruction set, or
> perhaps because it represnts a huge block of lightly/barely tested
> code that will have its share of support issues).
> 
> I suppose I should do this by adding an entry to
>  Documentation/feature-removal-schedule.txt

I don't think people actively look in there.  You'd also need to do
something like mark it CONFIG_BROKEN, which will wake people up and might
make them go look to see what happened.  Updating the now-BROKEN help text
would make that nice and easy for them.

> Any thoughts on the timeline for this?  Is Dec 31, 2006 too soon?
> (or not soon enough!?).

You'd know better than we..

RE: [5/5] move_pages: 32bit support (i386,x86_64 and ia64)

[Christoph Lameter]

On Wed, 24 May 2006, Luck, Tony wrote:

> Any thoughts on the timeline for this?  Is Dec 31, 2006 too soon?
> (or not soon enough!?).

If it does not work then remove it now. Are there any users left?

I vaguely remember some BIOS code having to be executed in ia32 mode in 
order to make some device drives work?

If that is the case then we cannot drop ia32 support at all.

RE: [5/5] move_pages: 32bit support (i386,x86_64 and ia64)

[Luck, Tony]

> If it does not work then remove it now.
It still works ... it just isn't complete as most of the syscalls
added in the past 18 months haven't been included.

> Are there any users left?
I've no idea.  Two OSDs have been shipping the Intel s/w emulator for
a while now, one installs it by default.  So the number of users is
probably diminishing.  When people upgrade to Montecito, s/w emulation
is the only option, which will further reduce the user population.

> I vaguely remember some BIOS code having to be executed in ia32 mode in 
> order to make some device drives work?
> If that is the case then we cannot drop ia32 support at all.
The kernel doesn't handle BIOS code execution ... so the value of
CONFIG_IA32_SUPPORT makes no difference to this.

-Tony

If this thread continues, I'll drop all the innocent bystanders from
the Cc: list and just leave linux-ia64 from future replies.

Re: [5/5] move_pages: 32bit support (i386,x86_64 and ia64)

[Andrew Morton]

Christoph Lameter <clameter@sgi.com> wrote:
>
> sys_move_pages() support for 32bit (i386 plus ia64 and x86_64 compat layers)
> 
> Add support for move_pages() on i386 and also add the
> compat functions necessary to run 32 bit binaries on x86_64 and ia64.
> 
> Add compat_sys_move_pages to both the x86_64 and the ia64 32bit binary
> layer. Note that both are not up to date so I added the missing pieces.
> Not sure if this is done the right way.
> 
> This probably needs some fixups:
> 
> 1. What about sys_vmsplice on x86_64?
> 
> 2. There is a whole range of syscalls missing for ia64 that I basically
>    interpolated from elsewhere.

I dropped the ia64 bits - looks like that's all on death row anyway.

The omission of sys_vmsplice() from the x86 syscall table does appear to
be, umm, a glaring omission.  Jens, what's up?

Re: [5/5] move_pages: 32bit support (i386,x86_64 and ia64)

[Jens Axboe]

On Wed, May 24 2006, Andrew Morton wrote:
> Christoph Lameter <clameter@sgi.com> wrote:
> >
> > sys_move_pages() support for 32bit (i386 plus ia64 and x86_64 compat layers)
> > 
> > Add support for move_pages() on i386 and also add the
> > compat functions necessary to run 32 bit binaries on x86_64 and ia64.
> > 
> > Add compat_sys_move_pages to both the x86_64 and the ia64 32bit binary
> > layer. Note that both are not up to date so I added the missing pieces.
> > Not sure if this is done the right way.
> > 
> > This probably needs some fixups:
> > 
> > 1. What about sys_vmsplice on x86_64?
> > 
> > 2. There is a whole range of syscalls missing for ia64 that I basically
> >    interpolated from elsewhere.
> 
> I dropped the ia64 bits - looks like that's all on death row anyway.
> 
> The omission of sys_vmsplice() from the x86 syscall table does appear to
> be, umm, a glaring omission.  Jens, what's up?

Uhm yes...

[PATCH] Add vmsplice syscall to x86 table

Signed-off-by: Jens Axboe <axboe@suse.de>

diff --git a/arch/i386/kernel/syscall_table.S b/arch/i386/kernel/syscall_table.S
index f48bef1..af56987 100644
--- a/arch/i386/kernel/syscall_table.S
+++ b/arch/i386/kernel/syscall_table.S
@@ -315,3 +315,4 @@ ENTRY(sys_call_table)
 	.long sys_splice
 	.long sys_sync_file_range
 	.long sys_tee			/* 315 */
+	.long sys_vmsplice

-- 
Jens Axboe

Re: dropping CONFIG_IA32_SUPPORT from ia64

[Bjorn Helgaas]

On Wednesday 24 May 2006 12:45, Luck, Tony wrote:
> I've been thinking of dropping CONFIG_IA32_SUPPORT completely from ia64.
> I've heard no complaints that new syscalls are not being added to the
> ia32 compat side ... which is an indication that people are not
> actively using this.

Or maybe the people using ia32 compatibility are just running big
apps like Firefox or Open Office that are non-trivial to build for
ia64, but may not care as much about shiny new syscalls.

Later, Tony wrote:
> > Are there any users left?
> I've no idea.  Two OSDs have been shipping the Intel s/w emulator for
> a while now, one installs it by default.  So the number of users is
> probably diminishing.  When people upgrade to Montecito, s/w emulation
> is the only option, which will further reduce the user population.

I'm a bit worried about this.  As I understand it, the Intel
software emulator is not open-source.  There may be distros
like Debian and customer environments where that's not a viable
alternative.

If we remove CONFIG_IA32_SUPPORT, every ia64 box will require
the Intel emulator (or QEMU or some other ill-defined solution)
in order to run ia32 code, even though every processor in the
field today supports ia32 in hardware.

It doesn't feel right to me to remove functionality from machines
in the field and offer only a proprietary alternative.

Bjorn

RE: dropping CONFIG_IA32_SUPPORT from ia64

[Luck, Tony]

Cc: list pruned to stop annoying the innocent bystanders ...

> > I've been thinking of dropping CONFIG_IA32_SUPPORT completely from ia64.
> > I've heard no complaints that new syscalls are not being added to the
> > ia32 compat side ... which is an indication that people are not
> > actively using this.
>
> Or maybe the people using ia32 compatibility are just running big
> apps like Firefox or Open Office that are non-trivial to build for
> ia64, but may not care as much about shiny new syscalls.

Firefox has been ported ... it came as a native ia64 binary
rpm on the last OSD install disk that I put on my workstation.
Dunno about Open office though.

> > I've no idea.  Two OSDs have been shipping the Intel s/w emulator for
> > a while now, one installs it by default.  So the number of users is
> > probably diminishing.  When people upgrade to Montecito, s/w emulation
> > is the only option, which will further reduce the user population.
> 
> I'm a bit worried about this.  As I understand it, the Intel
> software emulator is not open-source.  There may be distros
> like Debian and customer environments where that's not a viable
> alternative.

The instruction emulating part of the Intel solution is indeed
closed source (the syscall emulation part is open, so you could
rip out the closed source part and replace it with something else,
but so far nobody has cared enough to do so ... perhaps someone
will step up to the plate when they get a Montecito and still
want to run x86 binaries on it).

> If we remove CONFIG_IA32_SUPPORT, every ia64 box will require
> the Intel emulator (or QEMU or some other ill-defined solution)
> in order to run ia32 code, even though every processor in the
> field today supports ia32 in hardware.

But how many of the in-the-field systems are still being updated
with the latest kernels?  I know there are a few die-hards determined
to use their BigSur boxes until they eventually fail.  But this
does tell me that I should be looking at a much longer timescale
to drop this.  A new Madison box bought today should be usable
for some years to come.

> It doesn't feel right to me to remove functionality from machines
> in the field and offer only a proprietary alternative.

The alternative to dropping support for CONFIG_IA32_SUPPORT is
to find someone to maintain it ... right now it doesn't get much
of my time, so it is a ticking quagmire of untested code.

-Tony

Re: dropping CONFIG_IA32_SUPPORT from ia64

[Jeff Hanson]

Luck, Tony wrote:
> Cc: list pruned to stop annoying the innocent bystanders ...
> 
>>> I've been thinking of dropping CONFIG_IA32_SUPPORT completely from ia64.
>>> I've heard no complaints that new syscalls are not being added to the
>>> ia32 compat side ... which is an indication that people are not
>>> actively using this.
>> Or maybe the people using ia32 compatibility are just running big
>> apps like Firefox or Open Office that are non-trivial to build for
>> ia64, but may not care as much about shiny new syscalls.
> 
> Firefox has been ported ... it came as a native ia64 binary
> rpm on the last OSD install disk that I put on my workstation.
> Dunno about Open office though.

Native port of Open Office is supposed to be very hard because the
UNO bridge code is specific to each architecture.
-- 
-----------------------------------------------------------------------
Jeff Hanson - jhanson@sgi.com - Field Technical Analyst

You can choose a ready guide in some celestial voice.
If you choose not to decide, you still have made a choice.
You can choose from phantom fears and kindness that can kill;
I will choose a path that's clear
I will choose freewill. - Lee/Lifeson/Peart

RE: dropping CONFIG_IA32_SUPPORT from ia64

[Peter Chubb]

>>>>> "Tony" = Tony Luck <Luck> writes:

BH>> 
BH>> Or maybe the people using ia32 compatibility are just running big
BH>> apps like Firefox or Open Office that are non-trivial to build for
BH>> ia64, but may not care as much about shiny new syscalls.

Tony> Firefox has been ported ... it came as a native ia64 binary rpm
Tony> on the last OSD install disk that I put on my workstation.
Tony> Dunno about Open office though.

Acrobat is the only thing I use it for...  and firefox when I *have*
to view flash movies.

I think that IA32 support is important for those (few) of us who use
Zx2000 or similar as workstations on Debian.  And I'm hoping that that
number will increase now that some of the 2nd generation clusters are
reaching eol, so there should be starting to be zx6000 on the 2nd hand
market relatively cheap.  I've seen a few here for $1300AUD --- and
even as old (1.2GHz) machines they beat the pants off anything else
you can buy here at that price.

The new system calls are irrelevant for most apps.

--
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
http://www.ertos.nicta.com.au           ERTOS within National ICT Australia

Re: dropping CONFIG_IA32_SUPPORT from ia64

[Rich Altmaier]

I will offer the opinion that support of the IA32 ABI is
important.  That is, the ability to install and run
an IA32 binary (doesn't matter how, just matters it is
the same binary as used on an IA32 machine).
And I am certainly happy with the IA32-EL approach.

This feature provides a bridge for a customer with certainly
a lot more IA32 machines in their shop.  No customer will
have a dominate number of IA64 systems.  Hence the
ability for the IA64 to fit it and blend it, and run
any code there, and in addition do its special work,
is a much, much easier sell.
The reverse story, that IA64 runs only IA64 binaries,
is a tough sell.

Thanks!!
Rich
Rich Altmaier
VP of Engineering, SGI
richa@sgi.com


Peter Chubb wrote:

>>>>>>"Tony" = Tony Luck <Luck> writes:
> 
> 
> BH>> 
> BH>> Or maybe the people using ia32 compatibility are just running big
> BH>> apps like Firefox or Open Office that are non-trivial to build for
> BH>> ia64, but may not care as much about shiny new syscalls.
> 
> Tony> Firefox has been ported ... it came as a native ia64 binary rpm
> Tony> on the last OSD install disk that I put on my workstation.
> Tony> Dunno about Open office though.
> 
> Acrobat is the only thing I use it for...  and firefox when I *have*
> to view flash movies.
> 
> I think that IA32 support is important for those (few) of us who use
> Zx2000 or similar as workstations on Debian.  And I'm hoping that that
> number will increase now that some of the 2nd generation clusters are
> reaching eol, so there should be starting to be zx6000 on the 2nd hand
> market relatively cheap.  I've seen a few here for $1300AUD --- and
> even as old (1.2GHz) machines they beat the pants off anything else
> you can buy here at that price.
> 
> The new system calls are irrelevant for most apps.
> 
> --
> Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
> http://www.ertos.nicta.com.au           ERTOS within National ICT Australia
> -
> To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: dropping CONFIG_IA32_SUPPORT from ia64

[Matthew Wilcox]

On Wed, May 24, 2006 at 02:23:18PM -0700, Luck, Tony wrote:
> > It doesn't feel right to me to remove functionality from machines
> > in the field and offer only a proprietary alternative.
> 
> The alternative to dropping support for CONFIG_IA32_SUPPORT is
> to find someone to maintain it ... right now it doesn't get much
> of my time, so it is a ticking quagmire of untested code.

A twist on that theme is to merge the parts of ia32 emulation in the
ia64 kernel with the x86_64 architecture.  Where that makes sense,
anyway.  Large portions of the ia32 emulation are already common with
other CONFIG_COMPAT architectures, so reducing the amount of code
reduces the amount of potentially buggy code ;-)

A first step on that road would be to create one syscall table for
i386/ia32 emulation.  Take a look at arch/parisc/kernel/syscall_table.S
for one approach to this.  The interesting part to this is that some
syscalls seem to require different treatment on ia64 and x86_64 (last
time I looked at doing this anyway).  That can be handled with some
additional ENTRY_ types.

I've been meaning to get round to this for a while, but somehow I never
quite have time.

RE: dropping CONFIG_IA32_SUPPORT from ia64

[Luck, Tony]

> A twist on that theme is to merge the parts of ia32 emulation in the
> ia64 kernel with the x86_64 architecture.  Where that makes sense,
> anyway.  Large portions of the ia32 emulation are already common with
> other CONFIG_COMPAT architectures, so reducing the amount of code
> reduces the amount of potentially buggy code ;-)

That would be good ... currently there is 5674 lines below arch/ia64/ia32/
If the majority of that were shared with x86_64 (which has a much
bigger testing population than ia64), it would help enormously.

> I've been meaning to get round to this for a while, but somehow I never
> quite have time.

That's always a problem.

-Tony

Re: dropping CONFIG_IA32_SUPPORT from ia64

[Kyle McMartin]

On Wed, May 24, 2006 at 02:23:18PM -0700, Luck, Tony wrote:
> 
> The alternative to dropping support for CONFIG_IA32_SUPPORT is
> to find someone to maintain it ... right now it doesn't get much
> of my time, so it is a ticking quagmire of untested code.
>

I'll give it some love. I've got an old BigSur proto and a rx5670 running
Debian so it shouldn't be very hard to keep an i386 chroot tested.

That and I already pay attention to syscall additions when I update
the parisc syscall table. 

Cheers,
	Kyle

Re: dropping CONFIG_IA32_SUPPORT from ia64

[Matt Taggart]

Bjorn Helgaas writes...

> If we remove CONFIG_IA32_SUPPORT, every ia64 box will require
> the Intel emulator (or QEMU or some other ill-defined solution)
> in order to run ia32 code, even though every processor in the
> field today supports ia32 in hardware.
> 
> It doesn't feel right to me to remove functionality from machines
> in the field and offer only a proprietary alternative.

Debian is looking at implementing "multiarch", a way to have libraries
for multiple binary targets install in the same system root.

  http://wiki.debian.org/multiarch

After amd64 systems, ia64 can benefit the most from multiarch. It would
be a shame to see this not happen.

I also agree with Bjorn that the propriatary tool shouldn't be the only
way. To the Intel people on the lists that work on this, what is Intel's
position on open sourcing this technology?

Thanks,

-- 
Matt Taggart
taggart@debian.org

Re: dropping CONFIG_IA32_SUPPORT from ia64

[Andi Kleen]

> I'm a bit worried about this.  As I understand it, the Intel
> software emulator is not open-source.  There may be distros
> like Debian and customer environments where that's not a viable
> alternative.
> 
> If we remove CONFIG_IA32_SUPPORT, every ia64 box will require
> the Intel emulator (or QEMU or some other ill-defined solution)
> in order to run ia32 code, even though every processor in the
> field today supports ia32 in hardware.
> 
> It doesn't feel right to me to remove functionality from machines
> in the field and offer only a proprietary alternative.

You could just freeze the code down to "security fixes only". 
This means new system calls wouldn't need to be added and most programs
fallback if they don't see the latest and great syscalls anyways.
On the other hand it is usually not very hard to add new syscalls
and most of the other code is shared now anyways.

-Andi

RE: dropping CONFIG_IA32_SUPPORT from ia64

[Luck, Tony]

> I'll give it some love. I've got an old BigSur proto and a rx5670 running
> Debian so it shouldn't be very hard to keep an i386 chroot tested.
>
> That and I already pay attention to syscall additions when I update
> the parisc syscall table. 

A volunteer!  Thank you, thank you!

-Tony

RE: dropping CONFIG_IA32_SUPPORT from ia64

[Luck, Tony]

> I also agree with Bjorn that the propriatary tool shouldn't be the only
> way. To the Intel people on the lists that work on this, what is Intel's
> position on open sourcing this technology?

Open-sourcing this code has been discussed many times inside Intel, but
(AFAIK) the answer is still "no".

-Tony

Re: dropping CONFIG_IA32_SUPPORT from ia64

[David Mosberger-Tang]

On 5/25/06, Luck, Tony <tony.luck@intel.com> wrote:
> > I also agree with Bjorn that the propriatary tool shouldn't be the only
> > way. To the Intel people on the lists that work on this, what is Intel's
> > position on open sourcing this technology?
>
> Open-sourcing this code has been discussed many times inside Intel, but
> (AFAIK) the answer is still "no".

I try to stay away from legal questions as far as possible but one
nugget that may be worth pointing out is that Intel's ia32 engine is
very much a stand-alone "module", just like the ia32 hardware-engine
in the pre-Montecito IPF CPUs.  AFAIK, the exact same binary is even
used both for the Windows and Linux versions of IA32EL.  Thus, Debian
ought to be able to treat the issue similar to the msttcorefonts.
That is, if you installed the (not-yet-existing) ia32el Debian
package, you'd install all the open-source pieces directly from
Debian, and then go out and fetch the proprietary ia32 engine from
Intel's web-site.  IIRC, some tweaks may be needed to Intel's
website/license to really enable that but I think the key to making
this work would be to view Intel's ia32 engine as a CPU which happens
to be implemented in software.

  --david
-- 
Mosberger Consulting LLC, http://www.mosberger-consulting.com/

RE: dropping CONFIG_IA32_SUPPORT from ia64

[Luck, Tony]

> in the pre-Montecito IPF CPUs.  AFAIK, the exact same binary is even
> used both for the Windows and Linux versions of IA32EL.

That's how it was explained to me too.  Looking at the binary blob
part of the ia32-el package:

$ file /usr/lib/ia32el/ia32exec.bin
/usr/lib/ia32el/ia32exec.bin: MS-DOS executable (EXE), OS/2 or MS Windows

it seems that the implementation matches the slideware :-)

The rest of the ia32-el package is open source ... which should
provide enough documentation on how the OS-level code interfaces
to the instruction execution engine to allow it to be replaced.

-Tony

Re: dropping CONFIG_IA32_SUPPORT from ia64

[Kyle McMartin]

On Thu, May 25, 2006 at 08:40:48AM -0700, Luck, Tony wrote:
> > in the pre-Montecito IPF CPUs.  AFAIK, the exact same binary is even
> > used both for the Windows and Linux versions of IA32EL.
>
<snip>
> The rest of the ia32-el package is open source ... which should
> provide enough documentation on how the OS-level code interfaces
> to the instruction execution engine to allow it to be replaced.
> 

Possibly a stupid question, but I couldn't find any information in the
(afaik) only released Montecito documentation (the Optimization guide).

Has the br.ia completer been removed from the architecture? Or will
it generate a trap which can be caught and the translator invoked?

The doc only references added insns, not those removed from the arch.

Cheers,
	Kyle

RE: dropping CONFIG_IA32_SUPPORT from ia64

[Luck, Tony]

> Has the br.ia completer been removed from the architecture? Or will
> it generate a trap which can be caught and the translator invoked?

Linux on Montecito will set the psr.di bit which will cause br.ia's and
jmpe's to create the disabled instruction set transition fault.

-Tony

Re: dropping CONFIG_IA32_SUPPORT from ia64

[dann frazier]

On Wed, May 24, 2006 at 02:23:18PM -0700, Luck, Tony wrote:
> But how many of the in-the-field systems are still being updated
> with the latest kernels?  I know there are a few die-hards determined
> to use their BigSur boxes until they eventually fail.  But this
> does tell me that I should be looking at a much longer timescale
> to drop this.  A new Madison box bought today should be usable
> for some years to come.

Just for clarity, what platforms would be affected by this?  I thought
the non-free software was needed for Montecito+, and that Madison
worked fine w/o it.

My vote is not to drop the "free" kernel support, though I'm also not
offering to take over maintenance so it probably doesn't count for
much.

-- 
dann frazier

Re: dropping CONFIG_IA32_SUPPORT from ia64

[Jes Sorensen]

>>>>> "Tony" = Luck, Tony <tony.luck@intel.com> writes:

Tony> Cc: list pruned to stop annoying the innocent bystanders ...
>> Or maybe the people using ia32 compatibility are just running big
>> apps like Firefox or Open Office that are non-trivial to build for
>> ia64, but may not care as much about shiny new syscalls.

Tony> Firefox has been ported ... it came as a native ia64 binary rpm
Tony> on the last OSD install disk that I put on my workstation.
Tony> Dunno about Open office though.

Yup, Firefox runs nicely, now we just need gnash to get there so it
can display some of those %#@%#$$@# sites that insist on using flash.

I took a look at trying to build Open Office about two month ago. All
I can say is YUCK! The build system is disgusting and the arch
specific bits are a nightmare to try and mess with - after wasting a
day on it I concluded that it wasn't worth waking up in the middle of
the night shaking and all soaked in sweat over it. Back to using
ia32el for it, which unfortunately makes an already utterly slow
application seem like it's running on my old C64.

Anyone who manages to get Open Office building natively is very brave
:)

Cheers,
Jes

Re: dropping CONFIG_IA32_SUPPORT from ia64

[Andreas Schwab]

Jes Sorensen <jes@sgi.com> writes:

> Yup, Firefox runs nicely, now we just need gnash to get there so it
> can display some of those %#@%#$$@# sites that insist on using flash.

Konqueror can run flash (or any other 32bit plugin) via an external
helper.  Works pretty well.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: dropping CONFIG_IA32_SUPPORT from ia64

[Christoph Hellwig]

On Fri, May 26, 2006 at 03:11:03AM -0400, Jes Sorensen wrote:
> Yup, Firefox runs nicely, now we just need gnash to get there so it
> can display some of those %#@%#$$@# sites that insist on using flash.
> 
> I took a look at trying to build Open Office about two month ago. All
> I can say is YUCK! The build system is disgusting and the arch
> specific bits are a nightmare to try and mess with - after wasting a
> day on it I concluded that it wasn't worth waking up in the middle of
> the night shaking and all soaked in sweat over it. Back to using
> ia32el for it, which unfortunately makes an already utterly slow
> application seem like it's running on my old C64.
> 
> Anyone who manages to get Open Office building natively is very brave
> :)

Indeed.  In addition to your list ooo out of the sun cvs isn't even
64bit clean.  RH and Novell people are working on that though.

RE: dropping CONFIG_IA32_SUPPORT from ia64

[Luck, Tony]

> Just for clarity, what platforms would be affected by this?  I thought
> the non-free software was needed for Montecito+, and that Madison
> worked fine w/o it.

You are correct.  All cpu implementations prior to "Montecito" have
h/w support for x86 instructions.  "Montecito" does not.  You'll
have to make your own bets and guesses about whether this would ever
be re-introduced.

> My vote is not to drop the "free" kernel support, though I'm also not
> offering to take over maintenance so it probably doesn't count for
> much.

"Freeze" is pretty much where it has been for a while.  This thread was
started by a patch that caught up all the missing x86 system calls. Even
though the handlers all point into generic code, I'm always a bit twitchy
about including code that hasn't been exercised even once.  This would be
a lot easier if people adding system calls provided at least an example
program that uses the call ... even better would be an actual test-suite
that runs through all the options and failure cases for the call.  But
the recent slew of new syscalls have mostly lacked any such trimmings.

-Tony