Re: Again: UML on s390 (31Bit)
From: Martin Schwidefsky
Date: Thu Apr 28 2005 - 03:50:21 EST
Bodo Stroesser <bstroesser@xxxxxxxxxxxxxxxxxxx> wrote on 04/27/2005
10:21:58 PM:
> I'm sending this mail again, because unfortunately I didn't receive
> any reply. It was sent the first time at April, 5th.
Sorry, I put it on the to-do pile and promptly forgot about it.
> currently I'm porting UML to s390 31-bit.
Nice...
> 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.
This one isn't a problem. I'll add it to the repository.
> 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
> ==============================================================================
This patch is not good. !entryexit indicates that you want to change the trap
indication on the first of the two calls of syscall_trace for a system call. The
second condition is gprs[2] < 0 but that can be true for a normal system call as
well, like sys_exit(-1). It might even be true for user addresses if we really
extent the virtual address space to full 64 bit one day (and the hardware can do
it with a 5 level paging table). To change regs->trap to -1 with the current
condition is definitly wrong.
Independent from that it do not understand why you need it at all. If the
uml host intercepted and invalidated the guest system call the system restart
indication bit _TIF_RESTART_SVC shouldn't be set because the guest didn't
execute a system call.
blue skies,
Martin
Martin Schwidefsky
Linux for zSeries Development & Services
IBM Deutschland Entwicklung GmbH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/