On 25/11/2020 14.58, Cornelia Huck wrote:
> This adds a very basic test for checking that we present devices
> in a way that Linux can consume: boot with both virtio-net-ccw and
> virtio-net-pci attached and then verify that Linux is able to see
> and detect these devices.
Thanks for tackling it!
> Signed-off-by: Cornelia Huck <coh...@redhat.com>
> ---
>
> A very basic test, but it would have caught the recent zPCI regression.
>
> If anyone has a better idea than using early debug shells in the Debian
> install image, please let me know. At least it's quick, as we can check
> for the devices quite early in the boot sequence.
>
> Not sure if running under both kvm and tcg on an s390 host would add
> useful extra coverage. Also not sure if this needs fencing on any of the
> public CIs (have not tried yet).
We're only running the acceptance tests in the gitlab-CI, no worries about
the others.
> ---
> tests/acceptance/s390_devices.py | 68 ++++++++++++++++++++++++++++++++
> 1 file changed, 68 insertions(+)
> create mode 100644 tests/acceptance/s390_devices.py
>
> diff --git a/tests/acceptance/s390_devices.py
> b/tests/acceptance/s390_devices.py
> new file mode 100644
> index 000000000000..6ce47061f35d
> --- /dev/null
> +++ b/tests/acceptance/s390_devices.py
s390x_devices.py ?
Or maybe even machine_s390x.py instead, like the other machine*.py files?
> @@ -0,0 +1,68 @@
> +# Functional test that boots an s390x Linux guest with ccw and PCI devices
> +# attached and checks whether the devices are recognized by Linux
> +#
> +# Copyright (c) 2020 Red Hat, Inc.
> +#
> +# Author:
> +# Cornelia Huck <coh...@redhat.com>
> +#
> +# This work is licensed under the terms of the GNU GPL, version 2 or
> +# later. See the COPYING file in the top-level directory.
> +
> +
> +import os
> +
> +from avocado_qemu import Test
> +from avocado_qemu import exec_command_and_wait_for_pattern
> +from avocado_qemu import wait_for_console_pattern
> +
> +class CheckS390xDevices(Test):
> + KERNEL_COMMON_COMMAND_LINE = 'printk.time=0 '
> +
> + def wait_for_console_pattern(self, success_message, vm=None):
> + wait_for_console_pattern(self, success_message,
> + failure_message='Kernel panic - not
> syncing',
> + vm=vm)
> +
> + timeout = 60
Running on public CIs can be slow ... I'd maybe directly start with 90 or
120 here.
> + def test(self):
> +
> + """
> + :avocado: tags=arch:s390x
> + :avocado: tags=machine:s390-ccw-virtio
> + """
> +
> + # XXX: switch to https when debian fixes their certificate
> + kernel_url = ('http://archive.debian.org/debian/dists/jessie/main'
> +
> '/installer-s390x/current/images/generic/kernel.debian')
> + kernel_hash = '5af1aa839754f4d8817fb5878b4d55dfc887f45d'
> + kernel_path = self.fetch_asset(kernel_url, asset_hash=kernel_hash)
> +
> + initrd_url = ('http://archive.debian.org/debian/dists/jessie/main'
> +
> '/installer-s390x/current/images/generic/initrd.debian')
> + initrd_hash = '99252b28306184b876f979585e2d4bfe96b27464'
> + initrd_path = self.fetch_asset(initrd_url, asset_hash=initrd_hash)
> +
> + self.vm.set_console()
> + kernel_command_line = (self.KERNEL_COMMON_COMMAND_LINE +
> + 'console=sclp0 root=/dev/ram0 BOOT_DEBUG=3')
> + self.vm.add_args('-nographic',
> + '-kernel', kernel_path,
> + '-initrd', initrd_path,
> + '-append', kernel_command_line,
> + '-device', 'virtio-net-ccw,devno=fe.1.1111',
> + '-device', 'virtio-net-pci')
Maybe use '-device', 'virtio-net-pci,addr=6' or something similar to check a
non-default PCI address, too?
> + self.vm.launch()
> +
> + shell_ready = "sh: can't access tty; job control turned off"
> + self.wait_for_console_pattern(shell_ready)
> + # first debug shell is too early, we need to wait for device
> detection
> + exec_command_and_wait_for_pattern(self, 'exit', shell_ready)
> +
> + ccw_bus_id="0.1.1111"
> + pci_bus_id="0000:00:00.0"
> + exec_command_and_wait_for_pattern(self, 'ls /sys/bus/ccw/devices/',
> + ccw_bus_id)
> + exec_command_and_wait_for_pattern(self, 'ls /sys/bus/pci/devices/',
> + pci_bus_id)
>
Additional ideas (likely for later patches): Set a custom mac address for
the virtio-net devices and check whether they show up correctly in the
guest... Use "ping" to send some packets around (with -netdev user)...
Thomas
