| Message ID | 20201221143423.23607-1-thuth@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v4] tests/acceptance: Add a test with the Fedora 31 kernel and initrd | expand |
On Mon, 21 Dec 2020 15:34:23 +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> > --- > v4: > - Run lscss twice, just to be sure > > tests/acceptance/machine_s390_ccw_virtio.py | 110 ++++++++++++++++++++ > 1 file changed, 110 insertions(+) LGTM; but can I entice anyone to (re-)add a T-b/R-b before I queue this?
On Mon, Dec 21, 2020 at 11:34 AM 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> > --- > v4: > - Run lscss twice, just to be sure > > tests/acceptance/machine_s390_ccw_virtio.py | 110 ++++++++++++++++++++ > 1 file changed, 110 insertions(+) > Reviewed-by: Willian Rampazzo <willianr@redhat.com> Tested-by: Willian Rampazzo <willianr@redhat.com> AVOCADO tests/acceptance Fetching asset from tests/acceptance/machine_s390_ccw_virtio.py:S390CCWVirtioMachine.test_s390x_devices Fetching asset from tests/acceptance/machine_s390_ccw_virtio.py:S390CCWVirtioMachine.test_s390x_devices Fetching asset from tests/acceptance/machine_s390_ccw_virtio.py:S390CCWVirtioMachine.test_s390x_fedora Fetching asset from tests/acceptance/machine_s390_ccw_virtio.py:S390CCWVirtioMachine.test_s390x_fedora JOB ID : 211012b25fa008d0ab1be9edef0dfaa79856ba1f JOB LOG : /home/linux1/src/qemu.dev/build/tests/results/job-2020-12-21T11.27-211012b/job.log (1/2) tests/acceptance/machine_s390_ccw_virtio.py:S390CCWVirtioMachine.test_s390x_devices: PASS (7.46 s) (2/2) tests/acceptance/machine_s390_ccw_virtio.py:S390CCWVirtioMachine.test_s390x_fedora: PASS (22.80 s) RESULTS : PASS 2 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 | CANCEL 0 JOB TIME : 31.89 s
On 12/21/20 11:34 AM, Thomas Huth 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> > --- > v4: > - Run lscss twice, just to be sure > > tests/acceptance/machine_s390_ccw_virtio.py | 110 ++++++++++++++++++++ > 1 file changed, 110 insertions(+) Reviewed-by: Wainer dos Santos Moschetta <wainersm@redhat.com> > > diff --git a/tests/acceptance/machine_s390_ccw_virtio.py b/tests/acceptance/machine_s390_ccw_virtio.py > index abe25a08f0..0f81af9950 100644 > --- a/tests/acceptance/machine_s390_ccw_virtio.py > +++ b/tests/acceptance/machine_s390_ccw_virtio.py > @@ -9,10 +9,13 @@ > # 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 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 +153,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 > + """ > + > + 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: > + self.log.info("Test whether QEMU 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, 'lscss', '0.1.9876') > + exec_command_and_wait_for_pattern(self, 'lscss', '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. > + self.log.info("Test screendump of virtio-gpu device") > + 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') > + with tempfile.NamedTemporaryFile(suffix='.ppm', > + prefix='qemu-scrdump-') as ppmfile: > + self.vm.command('screendump', filename=ppmfile.name) > + ppmfile.seek(0) > + line = ppmfile.readline() > + self.assertEqual(line, b"P6\n") > + line = ppmfile.readline() > + self.assertEqual(line, b"1024 768\n") > + line = ppmfile.readline() > + self.assertEqual(line, b"255\n") > + line = ppmfile.readline() > + self.assertEqual(line, b"The quick fox jumps over a lazy dog\n") > + > + # Hot-plug a virtio-crypto device and see whether it gets accepted > + self.log.info("Test hot-plug virtio-crypto device") > + 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', devno='fe.0.2342') > + exec_command_and_wait_for_pattern(self, > + 'while ! (dmesg -c | grep Accelerator.device) ; do' > + ' sleep 1 ; done', 'Accelerator device is ready') > + exec_command_and_wait_for_pattern(self, 'lscss', '0.0.2342') > + 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.')
On Mon, 21 Dec 2020 15:34:23 +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> > --- > v4: > - Run lscss twice, just to be sure > > tests/acceptance/machine_s390_ccw_virtio.py | 110 ++++++++++++++++++++ > 1 file changed, 110 insertions(+) Thanks, applied.
diff --git a/tests/acceptance/machine_s390_ccw_virtio.py b/tests/acceptance/machine_s390_ccw_virtio.py index abe25a08f0..0f81af9950 100644 --- a/tests/acceptance/machine_s390_ccw_virtio.py +++ b/tests/acceptance/machine_s390_ccw_virtio.py @@ -9,10 +9,13 @@ # 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 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 +153,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 + """ + + 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: + self.log.info("Test whether QEMU 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, 'lscss', '0.1.9876') + exec_command_and_wait_for_pattern(self, 'lscss', '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. + self.log.info("Test screendump of virtio-gpu device") + 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') + with tempfile.NamedTemporaryFile(suffix='.ppm', + prefix='qemu-scrdump-') as ppmfile: + self.vm.command('screendump', filename=ppmfile.name) + ppmfile.seek(0) + line = ppmfile.readline() + self.assertEqual(line, b"P6\n") + line = ppmfile.readline() + self.assertEqual(line, b"1024 768\n") + line = ppmfile.readline() + self.assertEqual(line, b"255\n") + line = ppmfile.readline() + self.assertEqual(line, b"The quick fox jumps over a lazy dog\n") + + # Hot-plug a virtio-crypto device and see whether it gets accepted + self.log.info("Test hot-plug virtio-crypto device") + 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', devno='fe.0.2342') + exec_command_and_wait_for_pattern(self, + 'while ! (dmesg -c | grep Accelerator.device) ; do' + ' sleep 1 ; done', 'Accelerator device is ready') + exec_command_and_wait_for_pattern(self, 'lscss', '0.0.2342') + 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.')
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> --- v4: - Run lscss twice, just to be sure tests/acceptance/machine_s390_ccw_virtio.py | 110 ++++++++++++++++++++ 1 file changed, 110 insertions(+)