All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Huth <thuth@redhat.com>
To: Cornelia Huck <cohuck@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: Mon, 21 Dec 2020 14:05:56 +0100	[thread overview]
Message-ID: <b209fc32-4c66-ebac-af85-4ddc2e21ee06@redhat.com> (raw)
In-Reply-To: <20201218143803.0c5eecf6.cohuck@redhat.com>

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)

>> +        """
>> +
>> +        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...

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

>> +        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	other threads:[~2020-12-21 13:07 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
2020-12-21 13:05   ` Thomas Huth [this message]
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=b209fc32-4c66-ebac-af85-4ddc2e21ee06@redhat.com \
    --to=thuth@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=crosa@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.