qemu-s390x
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2] tests/acceptance: Add a test with the Fedora 31 kernel an


From: Cornelia Huck
Subject: Re: [PATCH v2] tests/acceptance: Add a test with the Fedora 31 kernel and initrd
Date: Mon, 21 Dec 2020 14:32:21 +0100

On Mon, 21 Dec 2020 14:05:56 +0100
Thomas Huth <thuth@redhat.com> wrote:

> On 18/12/2020 14.38, Cornelia Huck wrote:
> > 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?  
> 
> Yes, we could do that (in a separate patch later)

Nod.

> 
> >> +        """
> >> +
> >> +        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.  
> 
> Seems like lscss is available indeed. I'll try to change this...

I think you want to check for the devno only in that case (i.e. not for
the subchannel number... we cannot guarantee that QEMU's algorithm will
assign the same subchannel number in all eternity.)

> 
> >   
> >> +                             '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?  
> 
> I don't think that this is strictly necessary here, indeed, since the
> "Accelerator device is ready" already means that the device has been
> detected correctly.

Yes. It might only ease debugging (e.g. the CRW was received correctly,
but for some reason the device was not properly set up.) Not sure if it
is worth the extra hassle.

> 
> >> +        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.')  
> >   
> 
>  Thomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]