qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v3 3/6] tests/acceptance: Add test_mips_4kc_malt


From: Philippe Mathieu-Daudé
Subject: Re: [Qemu-devel] [PATCH v3 3/6] tests/acceptance: Add test_mips_4kc_malta in BootLinuxConsole
Date: Sat, 20 Oct 2018 11:57:36 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0

On 20/10/2018 00:51, Cleber Rosa wrote:
> 
> 
> On 10/19/18 5:17 PM, Cleber Rosa wrote:
>>
>>
>> On 10/19/18 2:41 PM, Philippe Mathieu-Daudé wrote:
>>> On 19/10/2018 19:42, Cleber Rosa wrote:
>>>>
>>>>
>>>> On 10/13/18 11:15 AM, Philippe Mathieu-Daudé wrote:
>>>>> Similar to the test_x86_64_pc test, this boots a Linux kernel on a
>>>>> Malta board (MIPS 4Kc big-endian) and verify the serial is working.
>>>>>
>>>>> This test requires the dpkg-deb tool (apt/dnf install dpkg) to
>>>>> extract the kernel from the Debian package.
>>>>>
>>>>
>>>> Debian packages are really "ar" archives, with a control.tar.gz and
>>>> data.tar.gz in them.  More on that later.
>>>>
>>>>>   $ avocado --show=console run -p arch=mips 
>>>>> tests/acceptance/boot_linux_console.py
>>>>>   console: [    0.000000] Initializing cgroup subsys cpuset
>>>>>   console: [    0.000000] Initializing cgroup subsys cpu
>>>>>   console: [    0.000000] Linux version 2.6.32-5-4kc-malta (Debian 
>>>>> 2.6.32-48) (address@hidden) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 Sat 
>>>>> Feb 16 12:43:42 UTC 2013
>>>>>   console: [    0.000000]
>>>>>   console: [    0.000000] LINUX started...
>>>>>   console: [    0.000000] bootconsole [early0] enabled
>>>>>   console: [    0.000000] CPU revision is: 00019300 (MIPS 24Kc)
>>>>>   console: [    0.000000] FPU revision is: 00739300
>>>>>   console: [    0.000000] Determined physical RAM map:
>>>>>   console: [    0.000000]  memory: 00001000 @ 00000000 (reserved)
>>>>>   console: [    0.000000]  memory: 000ef000 @ 00001000 (ROM data)
>>>>>   console: [    0.000000]  memory: 005b7000 @ 000f0000 (reserved)
>>>>>   console: [    0.000000]  memory: 03958000 @ 006a7000 (usable)
>>>>>   console: [    0.000000] Wasting 54496 bytes for tracking 1703 unused 
>>>>> pages
>>>>>   console: [    0.000000] Initrd not found or empty - disabling initrd
>>>>>   console: [    0.000000] Zone PFN ranges:
>>>>>   console: [    0.000000]   DMA      0x00000000 -> 0x00001000
>>>>>   console: [    0.000000]   Normal   0x00001000 -> 0x00003fff
>>>>>   console: [    0.000000] Movable zone start PFN for each node
>>>>>   console: [    0.000000] early_node_map[1] active PFN ranges
>>>>>   console: [    0.000000]     0: 0x00000000 -> 0x00003fff
>>>>>   console: [    0.000000] Built 1 zonelists in Zone order, mobility 
>>>>> grouping on.  Total pages: 16255
>>>>>   console: [    0.000000] Kernel command line: console=ttyS0 printk.time=0
>>>>>
>>>>> Signed-off-by: Philippe Mathieu-Daudé <address@hidden>
>>>>> ---
>>>>>  tests/acceptance/boot_linux_console.py | 46 ++++++++++++++++++++++++++
>>>>>  1 file changed, 46 insertions(+)
>>>>>
>>>>> diff --git a/tests/acceptance/boot_linux_console.py 
>>>>> b/tests/acceptance/boot_linux_console.py
>>>>> index 3aa4dbe5f9..81c96fc338 100644
>>>>> --- a/tests/acceptance/boot_linux_console.py
>>>>> +++ b/tests/acceptance/boot_linux_console.py
>>>>> @@ -9,6 +9,7 @@
>>>>>  # later.  See the COPYING file in the top-level directory.
>>>>>  
>>>>>  import logging
>>>>> +import subprocess
>>>>
>>>> It's definitely your call, but I like to think that
>>>> avocado.utils.process provides simpler and more capable functions:
>>>>
>>>> https://avocado-framework.readthedocs.io/en/65.0/api/utils/avocado.utils.html#avocado.utils.process.run
>>>
>>> OK
>>>
>>>>
>>>>>  
>>>>>  from avocado_qemu import Test
>>>>>  
>>>>> @@ -47,3 +48,48 @@ class BootLinuxConsole(Test):
>>>>>                  break
>>>>>              if 'Kernel panic - not syncing' in msg:
>>>>>                  self.fail("Kernel panic reached")
>>>>> +
>>>>> +    def test_mips_4kc_malta(self):
>>>>> +        """
>>>>> +        This test requires the dpkg-deb tool (apt/dnf install dpkg) to 
>>>>> extract
>>>>> +        the kernel from the Debian package.
>>>>> +
>>>>> +        The kernel can be rebuilt using this Debian kernel source [1] and
>>>>> +        following the instructions on [2].
>>>>> +
>>>>> +        [1] 
>>>>> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official
>>>>> +        [2] 
>>>>> http://snapshot.debian.org/package/linux-2.6/2.6.32-48/#linux-source-2.6.32_2.6.32-48
>>>>> +
>>>>> +        :avocado: tags=arch:mips
>>>>> +        """
>>>>> +        if self.arch != 'mips': # FIXME use 'arch' tag in parent class?
>>>>> +            self.cancel('Currently specific to the %s target arch' % 
>>>>> self.arch)
>>>>> +
>>>>
>>>> I missed how the arch tag in the parent class (common to all tests here)
>>>> would be useful for this specific test.
>>>
>>> I probably forgot to remove it.
>>>
>>
>> I think I now know what you meant.  With the current approach we have:
>>
>> $ avocado run -p arch=x86_64 tests/acceptance/boot_linux_console.py
>> JOB ID     : 3209c26bceffc372f245b121d6ac77a7e36e7134
>> JOB LOG    :
>> /home/cleber/avocado/job-results/job-2018-10-19T16.58-3209c26/job.log
>>  (1/2)
>> tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_x86_64_pc:
>> PASS (2.05 s)
>>  (2/2)
>> tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_mips_4kc_malta:
>> CANCEL: Currently specific to the x86_64 target arch (0.00 s)
>> RESULTS    : PASS 1 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 |
>> CANCEL 1
>> JOB TIME   : 2.21 s
>>
>> There's a bug in the CANCEL message, because the test is "mips" specific
>> and not specific to the arch parameter given.  I believe you'd like to
>> reuse the arch given in the "tags=", right?
>>
> 
> Continuing on this assumption (that it can be useful to access the tags
> during the test) I prototype this:
> 
> https://github.com/clebergnu/avocado/commit/7c5b04ed76bad5570f05e24ce168c8477283424d
> 
> And with that, this on top of this commit:
> 
> https://github.com/clebergnu/qemu/commit/359b8b4e10575646a2efa1bcb58ab74053233514
> 
> Basically, it allows one to run many arch specific tests at once,
> without specifying/restricting one arch:
> 
> $ avocado run tests/acceptance/boot_linux_console.py
> JOB ID     : 3ade8b6c547f853e1b169cd1846f69f5221fd9f0
> JOB LOG    :
> /home/cleber/avocado/job-results/job-2018-10-19T18.30-3ade8b6/job.log
>  (1/2)
> tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_x86_64_pc:
> PASS (2.00 s)
>  (2/2)
> tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_mips_4kc_malta:
> PASS (0.53 s)
> RESULTS    : PASS 2 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 |
> CANCEL 0
> JOB TIME   : 2.70 s
> 
> And the proper behavior when setting a arch:
> 
> $ avocado run -p arch=mips tests/acceptance/boot_linux_console.py
> JOB ID     : 75902f6b02707c9c0d509229f092e14e8b2f3933
> JOB LOG    :
> /home/cleber/avocado/job-results/job-2018-10-19T18.50-75902f6/job.log
>  (1/2)
> tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_x86_64_pc:
> CANCEL: Currently specific to the targets: x86_64 (0.00 s)
>  (2/2)
> tests/acceptance/boot_linux_console.py:BootLinuxConsole.test_mips_4kc_malta:
> PASS (0.54 s)
> RESULTS    : PASS 1 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 |
> CANCEL 1
> JOB TIME   : 0.71 s
> 
> How does that look?

YES! This is _exactly_ what I wanted and how I plan to use this framework :)

> 
> - Cleber.
> 
>> - Cleber.
>>
>>>>
>>>>> +        deb_url = 
>>>>> ('http://snapshot.debian.org/archive/debian/20130217T032700Z/'
>>>>> +                   'pool/main/l/linux-2.6/'
>>>>> +                   'linux-image-2.6.32-5-4kc-malta_2.6.32-48_mips.deb')
>>>>> +        deb_hash = 'a8cfc28ad8f45f54811fc6cf74fc43ffcfe0ba04'
>>>>> +        deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash)
>>>>> +        subprocess.check_call(['dpkg-deb', '--extract', deb_path, 
>>>>> self.workdir]) # FIXME move to avocado ...
>>>>
>>>> This could become:
>>>>
>>>>  # from avocado.utils.process import run
>>>>  run("ar p %s data.tar.gz | tar zxf - -C %s
>>>> ./boot/vmlinux-2.6.32-5-4kc-malta" % (deb_path, self.workdir), shell=True)
>>>
>>> OK!
>>>
>>>>
>>>>> +        kernel_path = self.workdir + '/boot/vmlinux-2.6.32-5-4kc-malta'  
>>>>>         # FIXME ... and use from assets?
>>>>> +
>>>>
>>>> Putting produced/processed files back into the cache would be nice
>>>> addition to the asset fetcher (or related tools).  Not there yet, though.
>>>
>>> OK :/
>>>
>>>>
>>>>> +        self.vm.set_arch(self.arch)
>>>>> +        self.vm.set_machine('malta')
>>>>> +        self.vm.set_console("") # XXX this disable isa-serial to use 
>>>>> -serial ...
>>>>
>>>> See the comments on the previous patch.  Basically, if a machine doesn't
>>>> need an explicit console device to be added, set_console() should do
>>>> just that (not add one).  The ideal API would be to call set_console()
>>>> without any explicit parameter IMO.
>>>
>>> Sure.
>>>
>>>>
>>>> That assumes, what I believe to be true, that we don't want to setup
>>>> multiple *console* devices per QEMUMachine, right?
>>>
>>> There might be weird corner-cases but usually machines only have one
>>> type of (default) console.
>>>
>>>>
>>>> Regards,
>>>> - Cleber.
>>>>
>>>>> +        kernel_command_line = 'console=ttyS0 printk.time=0'
>>>>> +        self.vm.add_args('-m', "64",
>>>>> +                         '-serial', "chardev:console", # XXX ... here.
>>>>> +                         '-kernel', kernel_path,
>>>>> +                         '-append', kernel_command_line)
>>>>> +
>>>>> +        # FIXME below to parent class?
>>>>> +        self.vm.launch()
>>>>> +        console = self.vm.console_socket.makefile()
>>>>> +        console_logger = logging.getLogger('console')
>>>>> +        while True:
>>>>> +            msg = console.readline()
>>>>> +            console_logger.debug(msg.strip())
>>>>> +            if 'Kernel command line: %s' % kernel_command_line in msg:
>>>>> +                break
>>>>> +            if 'Kernel panic - not syncing' in msg:
>>>>> +                self.fail("Kernel panic reached")
>>>>>
>>>>
>>
> 



reply via email to

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