Upgrading the minimum required s390x CPU to z10?

[Aurelien Jarno]

Hi all,

The Debian s390x port currently defaults to the z900 instruction set. It
appears that an increasing but small number of packages use z10 assembly
code, and need to be patched to be built on Debian. I therefore wonder if
it is time to switch the default ISA to z10 (which is the maximum we can
do with out current build daemons and porterbox). Of course that will be
done in testing/unstable, so people using older machines can still use
jessie.

Any opinion on that?

Aurelien

[Stephen Powell]

Post by Aurelien Jarno
Hi all,
The Debian s390x port currently defaults to the z900 instruction set. It
appears that an increasing but small number of packages use z10 assembly
code, and need to be patched to be built on Debian. I therefore wonder if
it is time to switch the default ISA to z10 (which is the maximum we can
do with out current build daemons and porterbox). Of course that will be
done in testing/unstable, so people using older machines can still use
jessie.
Any opinion on that?

That would count me out. The latest release of Hercules appears to support
the z10 instructions, but my employer's real mainframe, on which we run
Debian images (both jessie and stretch) is a z890. An instruction not supported
by a z890 would instantly crash the server.

Even zIPL has been rewritten in C now. Why are these new packages using
assembly language? And if they are wanting to use an instruction which is
not supported on all z/Architecture processors, why don't they do a facility
check first, like they are supposed to, to check to see if the facility required
to support the instruction is installed? That's the "right" way to do it.
And that's what the kernel does.

[Aurelien Jarno]

Post by Stephen Powell

Post by Aurelien Jarno
Hi all,
The Debian s390x port currently defaults to the z900 instruction set. It
appears that an increasing but small number of packages use z10 assembly
code, and need to be patched to be built on Debian. I therefore wonder if
it is time to switch the default ISA to z10 (which is the maximum we can
do with out current build daemons and porterbox). Of course that will be
done in testing/unstable, so people using older machines can still use
jessie.
Any opinion on that?

That would count me out. The latest release of Hercules appears to support
the z10 instructions, but my employer's real mainframe, on which we run
Debian images (both jessie and stretch) is a z890. An instruction not supported
by a z890 would instantly crash the server.

Ok, good to know we still have users on such hardware.

Post by Stephen Powell
Even zIPL has been rewritten in C now. Why are these new packages using
assembly language? And if they are wanting to use an instruction which is
not supported on all z/Architecture processors, why don't they do a facility
check first, like they are supposed to, to check to see if the facility required
to support the instruction is installed? That's the "right" way to do it.
And that's what the kernel does.

That's indeed the right way to do it (and to fix the issue), but the
point is that developers using GCC defaulting to z10 or higher don't
realize they can't use the corresponding instructions, so that has to
be fixed later. Latest example is openssl.

Aurelien

[Stephen Powell]

Post by Aurelien Jarno
That's indeed the right way to do it (and to fix the issue), but the
point is that developers using GCC defaulting to z10 or higher don't
realize they can't use the corresponding instructions, so that has to
be fixed later. Latest example is openssl.

Hmm. I see two possibilities here.

(1) The source code package uses a GCC option that specifies that the
compiled object code is to run on a z10 processor. The fix here is
rather simple and straightforward: change the GCC option to specify a
z800/z900, then re-build the package. The compiler will now generate
object code that is compatible with all z/Architecture processors.

(2) The so-called "C" source code bails out to assembly language in places,
and some instructions are used which aren't supported on a z800/z900.
(I've mainly seen this in s390-specific kernel modules.) In this case, the
fix is more involved. You have to find the offending code, insert a
facility check to make sure the instruction is supported first, then
decide how to handle the case where it isn't. This is much more labor
intensive.

Which case are you talking about? (I must confess that I haven't looked
at the source code for openssl.)

[Kurt Roeckx]

Post by Stephen Powell

Post by Aurelien Jarno
That's indeed the right way to do it (and to fix the issue), but the
point is that developers using GCC defaulting to z10 or higher don't
realize they can't use the corresponding instructions, so that has to
be fixed later. Latest example is openssl.

Hmm. I see two possibilities here.
(1) The source code package uses a GCC option that specifies that the
compiled object code is to run on a z10 processor. The fix here is
rather simple and straightforward: change the GCC option to specify a
z800/z900, then re-build the package. The compiler will now generate
object code that is compatible with all z/Architecture processors.
(2) The so-called "C" source code bails out to assembly language in places,
and some instructions are used which aren't supported on a z800/z900.
(I've mainly seen this in s390-specific kernel modules.) In this case, the
fix is more involved. You have to find the offending code, insert a
facility check to make sure the instruction is supported first, then
decide how to handle the case where it isn't. This is much more labor
intensive.
Which case are you talking about? (I must confess that I haven't looked
at the source code for openssl.)

OpenSSL has a lot of hand written assembler. It's actually the
linker that complained about it.

That should obviously be the assembler, not linker.


Kurt

[Kurt Roeckx]

Post by Stephen Powell

Post by Aurelien Jarno
That's indeed the right way to do it (and to fix the issue), but the
point is that developers using GCC defaulting to z10 or higher don't
realize they can't use the corresponding instructions, so that has to
be fixed later. Latest example is openssl.

Hmm. I see two possibilities here.
(1) The source code package uses a GCC option that specifies that the
compiled object code is to run on a z10 processor. The fix here is
rather simple and straightforward: change the GCC option to specify a
z800/z900, then re-build the package. The compiler will now generate
object code that is compatible with all z/Architecture processors.
(2) The so-called "C" source code bails out to assembly language in places,
and some instructions are used which aren't supported on a z800/z900.
(I've mainly seen this in s390-specific kernel modules.) In this case, the
fix is more involved. You have to find the offending code, insert a
facility check to make sure the instruction is supported first, then
decide how to handle the case where it isn't. This is much more labor
intensive.
Which case are you talking about? (I must confess that I haven't looked
at the source code for openssl.)

OpenSSL has a lot of hand written assembler. It's actually the
linker that complained about it.

On various arches we do detect on which CPU we're running, not
sure we already do that, or need to, on s390x.


Kurt

[R P Herrold]

Post by Stephen Powell

Post by Aurelien Jarno
That's indeed the right way to do it (and to fix the issue), but the
point is that developers using GCC defaulting to z10 or higher

Hmm. I see two possibilities here.
(1) The source code package uses a GCC option that specifies that the
compiled object code is to run on a z10 processor. The fix here is
rather simple and straightforward: change the GCC option to specify a
z800/z900, then re-build the package.

IBM upstream has moved the 'enterprise' distributions to the
even later z196 level about three years ago, via the -march
option. They made no secret of their intention to 'end the
life' of earlier hardware main-line support, even if it was
not well communicated outside of 'enterprise' circles

One could speculate why, but ... why bother. Chopping off the
legacy tail gets rid of easy conversions and substitution
replacement by Hercules rather than zPDT, and so drives more
of the remaining 'paying customer' pot either off of Z (to
Power, or distributed)

-- Russ herrold

[Stephen Powell]

Post by R P Herrold
IBM upstream has moved the 'enterprise' distributions to the
even later z196 level about three years ago, via the -march
option. They made no secret of their intention to 'end the
life' of earlier hardware main-line support, even if it was
not well communicated outside of 'enterprise' circles
One could speculate why, but ... why bother. Chopping off the
legacy tail gets rid of easy conversions and substitution
replacement by Hercules rather than zPDT, and so drives more
of the remaining 'paying customer' pot either off of Z (to
Power, or distributed)

Less than a year ago, I reported a problem to IBM regarding a kernel
crash on pre-z10 processors, and they produced a fix for it.

(See https://git.kernel.org/cgit/linux/kernel/git/s390/linux.git/patch/?id=0b991f5cdcd6201e5401f83ca3a672343c3bfc49.)

So, for Linux they are still supporting the entire z/Architecture line.
Of course, it's no secret that they want their customers to keep
buying their newer models every few years. For their own proprietary
64-bit operating systems, such as z/VM, they start cutting off
older hardware. We still run z/VM 5.4.0 because it is the last
release of z/VM that still supports our z/890. Starting with
z/VM 6.1.0, a z10 or newer is required.

[Kurt Roeckx]

Post by Aurelien Jarno
That's indeed the right way to do it (and to fix the issue), but the
point is that developers using GCC defaulting to z10 or higher don't
realize they can't use the corresponding instructions, so that has to
be fixed later. Latest example is openssl.

Note that I got a patch for that within 15 minutes of reporting
the issue.


Kurt