Bug 1449265

(In reply to Thomas Huth from comment #0)
> Since s390x does not have an ISA bus, the 'isa-serial' device can not be
> used here. I suggest to map the <serial> tag to the 'virtio-serial' device
> on s390x instead.

There's a danger of missing vital early debugging if we do this.

(In reply to Richard W.M. Jones from comment #2)
> (In reply to Thomas Huth from comment #0)
> > Since s390x does not have an ISA bus, the 'isa-serial' device can not be
> > used here. I suggest to map the <serial> tag to the 'virtio-serial' device
> > on s390x instead.
> 
> There's a danger of missing vital early debugging if we do this.

Early debugging text should go to the <console> on s390x, not to the <serial> device, and the <console> tag is already working as expected, so I don't think there is any danger here.

(In reply to Thomas Huth from comment #3)
> (In reply to Richard W.M. Jones from comment #2)
> > (In reply to Thomas Huth from comment #0)
> > > Since s390x does not have an ISA bus, the 'isa-serial' device can not be
> > > used here. I suggest to map the <serial> tag to the 'virtio-serial' device
> > > on s390x instead.
> > 
> > There's a danger of missing vital early debugging if we do this.
> 
> Early debugging text should go to the <console> on s390x, not to the
> <serial> device, and the <console> tag is already working as expected, so I
> don't think there is any danger here.

Yup, I've confirmed this is true on the s/390x machine too, thanks.

can we get devel and qa acks on this bug.

Patch series upstream, which fixes the behaviour of serial consoles on non-x86 architectures:
https://www.redhat.com/archives/libvir-list/2017-November/msg00545.html

(In reply to Pino Toscano from comment #9)
> Patch series upstream, which fixes the behaviour of serial consoles on
> non-x86 architectures:
> https://www.redhat.com/archives/libvir-list/2017-November/msg00545.html

v2 of the work:
https://www.redhat.com/archives/libvir-list/2017-November/msg00831.html

Is this fixed? Please move to MODIFIED.

(In reply to Ann Marie Rubin from comment #12)
> Is this fixed? Please move to MODIFIED.

Not yet ready upstream, v3 under review
https://www.redhat.com/archives/libvir-list/2017-November/msg01027.html

This is fixed upstream with commit:

commit 21332bf6587c23409fecb06ab81dbc14dd52c10b
Author: Pino Toscano <ptoscano>
Date:   Tue Nov 14 16:27:04 2017 +0100

    conf: add VIR_DOMAIN_CHR_SERIAL_TARGET_TYPE_SCLP
    
    Introduce specific a target types with two models for the console
    devices (sclp and sclplm) used in s390 and s390x guests, so isa-serial
    is no more used for them.
    
    This makes <serial> usable on s390 and s390x guests, with at most only
    a single sclpconsole and one sclplmconsole devices usable in a single
    guest (due to limitations in QEMU, which will enforce already at
    runtime).
    
    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1449265
    
    Signed-off-by: Pino Toscano <ptoscano>
    Reviewed-by: Andrea Bolognani <abologna>
    Reviewed-by: Pavel Hrdina <phrdina>

Also some more commits are required for it.

Test packages:

libvirt-3.9.0-5.el7.s390x
qemu-kvm-ma-2.10.0-11.el7.s390x
kernel-4.14.0-18.el7a.s390x


Case1: sclpconsole
Edit guest below and start guest OK

    <serial type='pty'>
    </serial>

qemu: 
-chardev pty,id=charserial0 -device sclpconsole,chardev=charserial0,id=serial0 

# virsh dumpxml vm1|grep serial -A7
    <serial type='pty'>
      <source path='/dev/pts/1'/>
      <target type='sclp-serial' port='0'>
        <model name='sclpconsole'/>
      </target>
      <alias name='serial0'/>
    </serial>
    <console type='pty' tty='/dev/pts/1'>
      <source path='/dev/pts/1'/>
      <target type='serial' port='0'/>
      <alias name='serial0'/>
    </console>

sclpconsole console can be connected and operated.

Case 2:  sclpconsole + virtio console
Guest can start with below setting. 
    <serial type='pty'>
        <target type='sclp-serial' port='0'>
        <model name='sclpconsole'/>
      </target>
    </serial>
    <console type='pty'>
    </console>
    <console type='pty'>
      <target type='virtio' port='1'/>
    </console>

qemu: -chardev pty,id=charserial0 -device sclpconsole,chardev=charserial0,id=serial0 -chardev pty,id=charconsole1 -device virtconsole,chardev=charconsole1,id=console1

Case 3: sclpconsole + sclplmconsole + virtio console
Guest can start with below setting.
    <serial type='pty'>
      <target type='sclp-serial' port='0'>
        <model name='sclpconsole'/>
      </target>
    </serial>
    <serial type='pty'>
      <target type='sclp-serial' port='1'>
        <model name='sclplmconsole'/>
      </target>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <console type='pty'>
      <target type='virtio' port='1'/>
    </console>

qemu: 
-chardev pty,id=charserial0 -device sclpconsole,chardev=charserial0,id=serial0 -chardev pty,id=charserial1 -device sclplmconsole,chardev=charserial1,id=serial1 -chardev pty,id=charconsole1 -device virtconsole,chardev=charconsole1,id=console1 

Case 4:  sclplmconsole (better use s390 machine, not s390x)
Guest can start with below setting.
    <serial type='pty'>
      <target type='sclp-serial' port='0'>
        <model name='sclplmconsole'/>
      </target>
    </serial>

Dumpxml:
    <serial type='pty'>
      <target type='sclp-serial' port='0'>
        <model name='sclplmconsole'/>
      </target>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
qemu:
chardev pty,id=charserial0 -device sclplmconsole,chardev=charserial0,id=serial0 -
sclplmconsole can be connected.

All tests are PASS.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2018:0704