Re: Upgrading the minimum required s390x CPU to z10?

[Kurt Roeckx]

On Wed, Jun 01, 2016 at 05:51:56AM +0200, Kurt Roeckx wrote:
> On Tue, May 31, 2016 at 07:23:00PM -0400, Stephen Powell wrote:
> > On Tue, May 31, 2016, at 18:25, Aurelien Jarno wrote:
> > > 
> > > 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

Re: Upgrading the minimum required s390x CPU to z10?

[Kurt Roeckx]

On Tue, May 31, 2016 at 07:23:00PM -0400, Stephen Powell wrote:
> On Tue, May 31, 2016, at 18:25, Aurelien Jarno wrote:
> > 
> > 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

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


-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#825931: s390-netdevice virtio interface choice misleading

[Viktor Mihajlovski]

Package: s390-netdevice
Version: 0.0.44
Severity: normal
Tags: d-i patch
X-Debbugs-CC: debian-s390@lists.debian.org, brueck...@linux.vnet.ibm.com

Dear Maintainer,

if an installation is attempted on a system with a PCI network interface
only, it is necessary to select virtio as network interface to continue
with the installation. This works because the virtio choice is
effectively a NOP and both PCI and virtio interfaces don't need
additional configuration. But it's also confusing.
I'd like to suggest to replace the 'virtio' choice with 'other' for a
better user experience (see attached patch).
This has of course an impact on existing preseed configurations with
s390-netdevice/choose_networktype=virtio but in the long run it might be
better to accept the migration pain than to live with a multitude of
semantically equivalent choices (kvm, pci, ...).

-- 

Mit freundlichen Grüßen/Kind Regards
   Viktor Mihajlovski

IBM Deutschland Research & Development GmbH
Vorsitzender des Aufsichtsrats: Martina Köderitz
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294

>From f7150c9d0c57f918b7f627423846bd43f2b964bc Mon Sep 17 00:00:00 2001
From: Viktor Mihajlovski 
Date: Mon, 30 May 2016 15:33:50 +0200
Subject: [PATCH] s390-netdevice: replace "virtio" by "other"

With the advent of PCI network device in z Systems a certain shortcoming
of the s390-netdevice module shows:
1. There's no PCI choice
2. A PCI choice doesn't exactly make sense, as nothing needs to be
   done for PCI.
3. Same thing for virtio

This change replaces the "virtio" selection with "other" in order
to support all kinds of network interfaces not needing configuration
in s390 environments, e.g. because a different d-i module is
configuring the interface.

Signed-off-by: Viktor Mihajlovski 
Acked-by: Hendrik Brueckner 
---
 debian/s390-netdevice.templates | 8 +---
 netdevice.c | 8 
 2 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/debian/s390-netdevice.templates b/debian/s390-netdevice.templates
index 39fc0b7..04db5bf 100644
--- a/debian/s390-netdevice.templates
+++ b/debian/s390-netdevice.templates
@@ -1,16 +1,18 @@
 Template: s390-netdevice/choose_networktype
 Type: select
-Choices-C: ctc, qeth, iucv, virtio
+Choices-C: ctc, qeth, iucv, other
 # Note to translators : Please keep your translations of the choices
 # below a 65 columns limit (which means 65 characters 
 # in single-byte languages) including the initial path
 # :sl5:
-__Choices: ctc: Channel to Channel (CTC) or ESCON connection, qeth: OSA-Express in QDIO mode / HiperSockets, iucv: Inter-User Communication Vehicle - available for VM guests only, virtio: KVM VirtIO
+__Choices: ctc: Channel to Channel (CTC) or ESCON connection, qeth: OSA-Express in QDIO mode / HiperSockets, iucv: Inter-User Communication Vehicle - available for VM guests only, other: other interface types like PCI or virtio
 # :sl5:
 _Description: Network device type:
  Please choose the type of your primary network interface that you
  will need for installing the Debian system (via NFS or HTTP). Only
- the listed devices are supported.
+ the listed devices are supported. If you chose "other", the interface
+ must not require additional configuration (i.e., it is configured
+ by a different installer module).
 
 Template: s390-netdevice/ctc/choose_read
 Type: select
diff --git a/netdevice.c b/netdevice.c
index c886170..64ec72e 100644
--- a/netdevice.c
+++ b/netdevice.c
@@ -97,7 +97,7 @@ enum
 	TYPE_CTC,
 	TYPE_IUCV,
 	TYPE_QETH,
-	TYPE_VIRTIO,
+	TYPE_OTHER,
 }
 type = TYPE_NONE;
 
@@ -308,8 +308,8 @@ static enum state_wanted get_networktype (void)
 		type = TYPE_CTC;
 	else if (!strncmp (ptr, "iucv", 4))
 		type = TYPE_IUCV;
-	else if (!strncmp (ptr, "virtio", 6))
-		type = TYPE_VIRTIO;
+	else if (!strncmp (ptr, "other", 5))
+		type = TYPE_OTHER;
 	else
 		return WANT_ERROR;
 
@@ -884,7 +884,7 @@ int main (int argc __attribute__ ((unused)), char *argv[] __attribute__ ((unused
 			case TYPE_IUCV:
 state = GET_IUCV_DEVICE;
 break;
-			case TYPE_VIRTIO:
+			case TYPE_OTHER:
 // no further configuration needed
 state = FINISH;
 break;
-- 
1.9.1