qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: Willian Rampazzo <willianr@redhat.com>,
	qemu-s390x@nongnu.org, qemu-devel@nongnu.org,
	Wainer dos Santos Moschetta <wainersm@redhat.com>,
	Cleber Rosa <crosa@redhat.com>
Subject: Re: [PATCH v2] tests/acceptance: Add a test with the Fedora 31 kernel and initrd
Date: Fri, 18 Dec 2020 14:38:03 +0100	[thread overview]
Message-ID: <20201218143803.0c5eecf6.cohuck@redhat.com> (raw)
In-Reply-To: <20201217085334.211772-1-thuth@redhat.com>

On Thu, 17 Dec 2020 09:53:34 +0100
Thomas Huth <thuth@redhat.com> wrote:

> This initrd contains a virtio-net and a virtio-gpu kernel module,
> so we can check that we can set a MAC address for the network device
> and whether we can hot-plug and -unplug a virtio-crypto device.
> But the most interesting part is maybe that we can also successfully
> write some stuff into the emulated framebuffer of the virtio-gpu
> device and make sure that we can read back that data from a screenshot.
> 
> Signed-off-by: Thomas Huth <thuth@redhat.com>
> ---
>  Based-on: 20201215183623.110128-1-thuth@redhat.com
> 
>  v2:
>  - Uncompress the initrd on the host already to speed up the test
>  - Disable plymouth to seepd up the test
>  - Check for device numbers
>  - Added virtio-crypto test
>  - Added ":avocado: tags=device:" lines
> 
>  tests/acceptance/machine_s390_ccw_virtio.py | 111 ++++++++++++++++++++
>  1 file changed, 111 insertions(+)
> 
> diff --git a/tests/acceptance/machine_s390_ccw_virtio.py b/tests/acceptance/machine_s390_ccw_virtio.py
> index abe25a08f0..a9a0f8a8e2 100644
> --- a/tests/acceptance/machine_s390_ccw_virtio.py
> +++ b/tests/acceptance/machine_s390_ccw_virtio.py
> @@ -9,10 +9,14 @@
>  # 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
> +import re
> +import tempfile
>  
>  from avocado_qemu import Test
>  from avocado_qemu import exec_command_and_wait_for_pattern
>  from avocado_qemu import wait_for_console_pattern
> +from avocado.utils import archive
>  
>  class S390CCWVirtioMachine(Test):
>      KERNEL_COMMON_COMMAND_LINE = 'printk.time=0 '
> @@ -150,3 +154,110 @@ class S390CCWVirtioMachine(Test):
>          self.vm.command('human-monitor-command', command_line='balloon 128')
>          exec_command_and_wait_for_pattern(self, 'head -n 1 /proc/meminfo',
>                                            'MemTotal:         115640 kB')
> +
> +
> +    def test_s390x_fedora(self):
> +
> +        """
> +        :avocado: tags=arch:s390x
> +        :avocado: tags=machine:s390-ccw-virtio
> +        :avocado: tags=device:virtio-gpu
> +        :avocado: tags=device:virtio-crypto
> +        :avocado: tags=device:virtio-net

Hm. I'm wondering whether we should add some of these device: tags to
the other test in this file as well?

> +        """
> +
> +        kernel_url = ('https://archives.fedoraproject.org/pub/archive'
> +                      '/fedora-secondary/releases/31/Server/s390x/os'
> +                      '/images/kernel.img')
> +        kernel_hash = 'b93d1efcafcf29c1673a4ce371a1f8b43941cfeb'
> +        kernel_path = self.fetch_asset(kernel_url, asset_hash=kernel_hash)
> +
> +        initrd_url = ('https://archives.fedoraproject.org/pub/archive'
> +                      '/fedora-secondary/releases/31/Server/s390x/os'
> +                      '/images/initrd.img')
> +        initrd_hash = '3de45d411df5624b8d8ef21cd0b44419ab59b12f'
> +        initrd_path_xz = self.fetch_asset(initrd_url, asset_hash=initrd_hash)
> +        initrd_path = os.path.join(self.workdir, 'initrd-raw.img')
> +        archive.lzma_uncompress(initrd_path_xz, initrd_path)
> +
> +        self.vm.set_console()
> +        kernel_command_line = (self.KERNEL_COMMON_COMMAND_LINE + ' audit=0 '
> +                              'rd.plymouth=0 plymouth.enable=0 rd.rescue')
> +        self.vm.add_args('-nographic',
> +                         '-smp', '4',
> +                         '-m', '512',
> +                         '-name', 'Some Guest Name',
> +                         '-uuid', '30de4fd9-b4d5-409e-86a5-09b387f70bfa',
> +                         '-kernel', kernel_path,
> +                         '-initrd', initrd_path,
> +                         '-append', kernel_command_line,
> +                         '-device', 'zpci,uid=7,target=n',
> +                         '-device', 'virtio-net-pci,id=n,mac=02:ca:fe:fa:ce:12',
> +                         '-device', 'virtio-rng-ccw,devno=fe.1.9876',
> +                         '-device', 'virtio-gpu-ccw,devno=fe.2.5432')
> +        self.vm.launch()
> +        self.wait_for_console_pattern('Entering emergency mode')
> +
> +        # Some tests to see whether the CLI options have been considered:
> +        exec_command_and_wait_for_pattern(self, 'lspci',
> +                             '0007:00:00.0 Class 0200: Device 1af4:1000')
> +        exec_command_and_wait_for_pattern(self,
> +                             'cat /sys/class/net/enP7p0s0/address',
> +                             '02:ca:fe:fa:ce:12')
> +        exec_command_and_wait_for_pattern(self, 'ls /sys/bus/ccw/devices/',

Does the Fedora image have lscss? (As it seems to have lspci.) If yes,
you could use it here; I only looked directly at the sysfs entry in the
tests above because the environment there is rather minimal.

(We can easily change that on top.)

> +                             '0.1.9876')
> +        exec_command_and_wait_for_pattern(self, 'ls /sys/bus/ccw/devices/',
> +                             '0.2.5432')
> +        exec_command_and_wait_for_pattern(self, 'cat /proc/cpuinfo',
> +                             'processors    : 4')
> +        exec_command_and_wait_for_pattern(self, 'grep MemTotal /proc/meminfo',
> +                             'MemTotal:         499848 kB')
> +        exec_command_and_wait_for_pattern(self, 'grep Name /proc/sysinfo',
> +                             'Extended Name:   Some Guest Name')
> +        exec_command_and_wait_for_pattern(self, 'grep UUID /proc/sysinfo',
> +                             '30de4fd9-b4d5-409e-86a5-09b387f70bfa')
> +
> +        # Disable blinking cursor, then write some stuff into the framebuffer.
> +        # QEMU's PPM screendumps contain uncompressed 24-bit values, while the
> +        # framebuffer uses 32-bit, so we pad our text with some spaces when
> +        # writing to the framebuffer. Since the PPM is uncompressed, we then
> +        # can simply read the written "magic bytes" back from the PPM file to
> +        # check whether the framebuffer is working as expected.
> +        exec_command_and_wait_for_pattern(self,
> +            'echo -e "\e[?25l" > /dev/tty0', ':/#')
> +        exec_command_and_wait_for_pattern(self, 'for ((i=0;i<250;i++)); do '
> +            'echo " The  qu ick  fo x j ump s o ver  a  laz y d og" >> fox.txt;'
> +            'done',
> +            ':/#')
> +        exec_command_and_wait_for_pattern(self,
> +            'dd if=fox.txt of=/dev/fb0 bs=1000 oflag=sync,nocache ; rm fox.txt',
> +            '12+0 records out')
> +        tmpfile = tempfile.NamedTemporaryFile(suffix='.ppm',
> +                                              prefix='qemu-scrdump-')
> +        self.vm.command('screendump', filename=tmpfile.name)
> +        ppmfile = open(tmpfile.name, "r")
> +        tmpfile.close
> +        line = ppmfile.readline()
> +        self.assertEqual(line, "P6\n")
> +        line = ppmfile.readline()
> +        self.assertEqual(line, "1024 768\n")
> +        line = ppmfile.readline()
> +        self.assertEqual(line, "255\n")
> +        line = ppmfile.readline()
> +        self.assertEqual(line, "The quick fox jumps over a lazy dog\n")
> +        ppmfile.close
> +
> +        # Hot-plug a virtio-crypto device and see whether it gets accepted
> +        self.clear_guest_dmesg()
> +        self.vm.command('object-add', qom_type='cryptodev-backend-builtin',
> +                        id='cbe0')
> +        self.vm.command('device_add', driver='virtio-crypto-ccw', id='crypdev0',
> +                        cryptodev='cbe0')

Do you want to add a device number and check for it here as well? And
maybe wait for the CRWs here and below, although that might not be
strictly needed?

> +        exec_command_and_wait_for_pattern(self,
> +                        'while ! (dmesg -c | grep Accelerator.device) ; do'
> +                        ' sleep 1 ; done', 'Accelerator device is ready')
> +        self.vm.command('device_del', id='crypdev0')
> +        self.vm.command('object-del', id='cbe0')
> +        exec_command_and_wait_for_pattern(self,
> +                        'while ! (dmesg -c | grep Start.virtcrypto_remove) ; do'
> +                        ' sleep 1 ; done', 'Start virtcrypto_remove.')



  reply	other threads:[~2020-12-18 13:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-17  8:53 [PATCH v2] tests/acceptance: Add a test with the Fedora 31 kernel and initrd Thomas Huth
2020-12-18 13:38 ` Cornelia Huck [this message]
2020-12-21 13:05   ` Thomas Huth
2020-12-21 13:32     ` Cornelia Huck
2020-12-18 15:05 ` Wainer dos Santos Moschetta
2020-12-21 13:27   ` Thomas Huth
2020-12-18 18:23 ` Willian Rampazzo
2020-12-21 12:59   ` Cornelia Huck
2020-12-21 13:24     ` Thomas Huth
2020-12-21 15:10     ` Willian Rampazzo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201218143803.0c5eecf6.cohuck@redhat.com \
    --to=cohuck@redhat.com \
    --cc=crosa@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=thuth@redhat.com \
    --cc=wainersm@redhat.com \
    --cc=willianr@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).