Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261879AbVDESXA (ORCPT ); Tue, 5 Apr 2005 14:23:00 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261861AbVDESJm (ORCPT ); Tue, 5 Apr 2005 14:09:42 -0400 Received: from dgate1.fujitsu-siemens.com ([217.115.66.35]:15135 "EHLO dgate1.fujitsu-siemens.com") by vger.kernel.org with ESMTP id S261858AbVDESIQ (ORCPT ); Tue, 5 Apr 2005 14:08:16 -0400 X-SBRSScore: None X-IronPort-AV: i="3.91,152,1110150000"; d="scan'208"; a="7185001:sNHT22964988" Message-ID: <4252D40C.9070402@fujitsu-siemens.com> Date: Tue, 05 Apr 2005 20:08:12 +0200 From: Bodo Stroesser User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-kernel@vger.kernel.org CC: Martin Schwidefsky , Jeff Dike , user-mode-linux devel Subject: UML on s390 (31Bit) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3353 Lines: 76 Hi, currently I'm porting UML to s390 31-bit. A first 2.6.11 UML system already is running in UML-SKAS0 mode, which normally should run on an unpatched host (no skas3-patch). To make UML build and run on s390, I needed to do these two little changes (the patches are copy and paste. I hope that doesn't hurt, since they are very small): 1) UML includes some of the subarch's (s390) headers. I had to change one of them with the following one-liner, to make this compile. AFAICS, this change doesn't break compilation of s390 itself. ============================================================================== --- linux-2.6.11.orig/include/asm-s390/user.h 2004-12-09 18:45:02.000000000 +0100 +++ linux-2.6.11/include/asm-s390/user.h 2004-12-09 18:48:11.000000000 +0100 @@ -10,7 +10,7 @@ #define _S390_USER_H #include -#include +#include /* Core file format: The core file is written in such a way that gdb can understand it and provide useful information to the user (under linux we use the 'trad-core' bfd). There are quite a number of ============================================================================== 2) UML needs to intercept syscalls via ptrace to invalidate the syscall, read syscall's parameters and write the result with the result of UML's syscall processing. Also, UML needs to make sure, that the host does no syscall restart processing. On i386 for example, this can be done by writing -1 to orig_eax on the 2nd syscall interception (orig_eax is the syscall number, which after the interception is used as a "interrupt was a syscall" flag only. Unfortunately, s390 holds syscall number and syscall result in gpr2 and its "interrupt was a syscall" flag (trap) is unreachable via ptrace. So I changed the host to set trap to -1, if the syscall number is written to a negative value on the first syscall interception. I hope, this adds what UML needs without changing ptrace visibly to other ptrace users. (This isn't tested on a 2.6 host yet, because my host still is a 2.4.21 SuSE. But I've adapted this change to 2.4 and tested, it works.) ============================================================================== --- linux-2.6.11.orig/arch/s390/kernel/ptrace.c 2005-04-04 18:57:38.000000000 +0200 +++ linux-2.6.11/arch/s390/kernel/ptrace.c 2005-04-04 19:01:51.000000000 +0200 @@ -726,6 +726,13 @@ ? 0x80 : 0)); /* + * If debugger has set an invalid syscall number, + * we prepare to skip syscall restart handling + */ + if (!entryexit && (long )regs->gprs[2] < 0 ) + regs->trap = -1; + + /* * this isn't the same as continuing with a signal, but it will do * for normal use. strace only continues with a signal if the * stopping signal is not SIGTRAP. -brl ============================================================================== It would be very helpful for me, if these changes could go into s390 mainline. If there is something wrong with them, please help me find a better solution. Regards, Bodo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/