mirror of https://github.com/xemu-project/xemu.git
Testing and doc updates:
- Only probe if docker or podman binaries in path - reduce console noise for aspeed avocado tests - update documents on maintainer roles and process - raise timeout for ppc64 avocado tests - integrate coverage reports into gitlab -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEZoWumedRZ7yvyN81+9DbCVqeKkQFAmN8nE0ACgkQ+9DbCVqe KkShJQf/UXmesO6kdrW+IcKme3usea18Nvwqav5QYkiKF2TU1aU4Fguqfz+2bJ1V 81ej3aUYR5pAxLL4pExoJkXbxB59B4gWPkL2QS8OZvNJVqGz/37LZBEY/nZOJ2kS rPAiCVDnKE/mUrK08DdAQst4PmT8SB09oHX+1WCEdylenT2cmEDNKOGkX6X/XNKU GOAtV1lzzD4L18rWV6ejV0uowICoNgjvvbHqIV7efwAEeKOctdesPx427xyhGeN9 0iWglby5TGxdsZCk01zeiAvlvfEr57d7uU7AF/nNxka+F8FpuBcB7pMxtw8rupTX eHjfN4XZ+hUZ4BXplc6RLR27H4Nk4Q== =jgXs -----END PGP SIGNATURE----- Merge tag 'pull-misc-for-7.2-221122-1' of https://gitlab.com/stsquad/qemu into staging Testing and doc updates: - Only probe if docker or podman binaries in path - reduce console noise for aspeed avocado tests - update documents on maintainer roles and process - raise timeout for ppc64 avocado tests - integrate coverage reports into gitlab # -----BEGIN PGP SIGNATURE----- # # iQEzBAABCgAdFiEEZoWumedRZ7yvyN81+9DbCVqeKkQFAmN8nE0ACgkQ+9DbCVqe # KkShJQf/UXmesO6kdrW+IcKme3usea18Nvwqav5QYkiKF2TU1aU4Fguqfz+2bJ1V # 81ej3aUYR5pAxLL4pExoJkXbxB59B4gWPkL2QS8OZvNJVqGz/37LZBEY/nZOJ2kS # rPAiCVDnKE/mUrK08DdAQst4PmT8SB09oHX+1WCEdylenT2cmEDNKOGkX6X/XNKU # GOAtV1lzzD4L18rWV6ejV0uowICoNgjvvbHqIV7efwAEeKOctdesPx427xyhGeN9 # 0iWglby5TGxdsZCk01zeiAvlvfEr57d7uU7AF/nNxka+F8FpuBcB7pMxtw8rupTX # eHjfN4XZ+hUZ4BXplc6RLR27H4Nk4Q== # =jgXs # -----END PGP SIGNATURE----- # gpg: Signature made Tue 22 Nov 2022 04:54:21 EST # gpg: using RSA key 6685AE99E75167BCAFC8DF35FBD0DB095A9E2A44 # gpg: Good signature from "Alex Bennée (Master Work Key) <alex.bennee@linaro.org>" [unknown] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 6685 AE99 E751 67BC AFC8 DF35 FBD0 DB09 5A9E 2A44 * tag 'pull-misc-for-7.2-221122-1' of https://gitlab.com/stsquad/qemu: gitlab: integrate coverage report tests/avocado: skip aarch64 cloud TCG tests in CI tests/avocado: introduce alpine virt test for CI tests/avocado: Raise timeout for boot_linux.py:BootLinuxPPC64.test_pseries_tcg docs/devel: try and improve the language around patch review docs/devel: simplify the minimal checklist docs/devel: make language a little less code centric docs/devel: add a maintainers section to development process tests/docker: allow user to override check target tests/avocado/machine_aspeed.py: Reduce noise on the console for SDK tests Run docker probe only if docker or podman are available Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
This commit is contained in:
Stefan Hajnoczi
commit
d3e9c79acc
|
|
@ -494,7 +494,17 @@ check-gprof-gcov:
|
|||
IMAGE: ubuntu2004
|
||||
MAKE_CHECK_ARGS: check
|
||||
after_script:
|
||||
- ${CI_PROJECT_DIR}/scripts/ci/coverage-summary.sh
|
||||
- cd build
|
||||
- gcovr --xml-pretty --exclude-unreachable-branches --print-summary
|
||||
-o coverage.xml --root ${CI_PROJECT_DIR} . *.p
|
||||
coverage: /^\s*lines:\s*\d+.\d+\%/
|
||||
artifacts:
|
||||
name: ${CI_JOB_NAME}-${CI_COMMIT_REF_NAME}-${CI_COMMIT_SHA}
|
||||
expire_in: 2 days
|
||||
reports:
|
||||
coverage_report:
|
||||
coverage_format: cobertura
|
||||
path: build/coverage.xml
|
||||
|
||||
build-oss-fuzz:
|
||||
extends: .native_build_job_template
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ Descriptions of section entries:
|
|||
W: Web-page with status/info
|
||||
Q: Patchwork web based patch tracking system site
|
||||
T: SCM tree type and location. Type is one of: git, hg, quilt, stgit.
|
||||
S: Status, one of the following:
|
||||
S: Status, one of the following (keep in sync with docs/devel/maintainers.rst):
|
||||
Supported: Someone is actually paid to look after this.
|
||||
Maintained: Someone actually looks after it.
|
||||
Odd Fixes: It has a maintainer but they don't have time to do
|
||||
|
|
|
|||
|
|
@ -1780,7 +1780,7 @@ fi
|
|||
# functions to probe cross compilers
|
||||
|
||||
container="no"
|
||||
if test $use_containers = "yes"; then
|
||||
if test $use_containers = "yes" && (has "docker" || has "podman"); then
|
||||
case $($python "$source_path"/tests/docker/docker.py probe) in
|
||||
*docker) container=docker ;;
|
||||
podman) container=podman ;;
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
.. _code_of_conduct:
|
||||
|
||||
Code of Conduct
|
||||
===============
|
||||
|
||||
|
|
|
|||
|
|
@ -8,6 +8,7 @@ Notes about how to interact with the community and how and where to submit patch
|
|||
|
||||
code-of-conduct
|
||||
conflict-resolution
|
||||
maintainers
|
||||
style
|
||||
submitting-a-patch
|
||||
trivial-patches
|
||||
|
|
|
|||
|
|
@ -0,0 +1,107 @@
|
|||
.. _maintainers:
|
||||
|
||||
The Role of Maintainers
|
||||
=======================
|
||||
|
||||
Maintainers are a critical part of the project's contributor ecosystem.
|
||||
They come from a wide range of backgrounds from unpaid hobbyists
|
||||
working in their spare time to employees who work on the project as
|
||||
part of their job. Maintainer activities include:
|
||||
|
||||
- reviewing patches and suggesting changes
|
||||
- collecting patches and preparing pull requests
|
||||
- tending to the long term health of their area
|
||||
- participating in other project activities
|
||||
|
||||
They are also human and subject to the same pressures as everyone else
|
||||
including overload and burnout. Like everyone else they are subject
|
||||
to project's :ref:`code_of_conduct` and should also be exemplars of
|
||||
excellent community collaborators.
|
||||
|
||||
The MAINTAINERS file
|
||||
--------------------
|
||||
|
||||
The `MAINTAINERS
|
||||
<https://gitlab.com/qemu-project/qemu/-/blob/master/MAINTAINERS>`__
|
||||
file contains the canonical list of who is a maintainer. The file
|
||||
is machine readable so an appropriately configured git (see
|
||||
:ref:`cc_the_relevant_maintainer`) can automatically Cc them on
|
||||
patches that touch their area of code.
|
||||
|
||||
The file also describes the status of the area of code to give an idea
|
||||
of how actively that section is maintained.
|
||||
|
||||
.. list-table:: Meaning of support status in MAINTAINERS
|
||||
:widths: 25 75
|
||||
:header-rows: 1
|
||||
|
||||
* - Status
|
||||
- Meaning
|
||||
* - Supported
|
||||
- Someone is actually paid to look after this.
|
||||
* - Maintained
|
||||
- Someone actually looks after it.
|
||||
* - Odd Fixes
|
||||
- It has a maintainer but they don't have time to do
|
||||
much other than throw the odd patch in.
|
||||
* - Orphan
|
||||
- No current maintainer.
|
||||
* - Obsolete
|
||||
- Old obsolete code, should use something else.
|
||||
|
||||
Please bear in mind that even if someone is paid to support something
|
||||
it does not mean they are paid to support you. This is open source and
|
||||
the code comes with no warranty and the project makes no guarantees
|
||||
about dealing with bugs or features requests.
|
||||
|
||||
|
||||
|
||||
Becoming a reviewer
|
||||
-------------------
|
||||
|
||||
Most maintainers start by becoming subsystem reviewers. While anyone
|
||||
is welcome to review code on the mailing list getting added to the
|
||||
MAINTAINERS file with a line like::
|
||||
|
||||
R: Random Hacker <rhacker@example.com>
|
||||
|
||||
marks you as a 'designated reviewer' - expected to provide regular
|
||||
spontaneous feedback. This will ensure that patches touching a given
|
||||
subsystem will automatically be CC'd to you.
|
||||
|
||||
Becoming a maintainer
|
||||
---------------------
|
||||
|
||||
Maintainers are volunteers who put themselves forward or have been
|
||||
asked by others to keep an eye on an area of code. They have generally
|
||||
demonstrated to the community, usually via contributions and code
|
||||
reviews, that they have a good understanding of the subsystem. They
|
||||
are also trusted to make a positive contribution to the project and
|
||||
work well with the other contributors.
|
||||
|
||||
The process is simple - simply send a patch to the list that updates
|
||||
the ``MAINTAINERS`` file. Sometimes this is done as part of a larger
|
||||
series when a new sub-system is being added to the code base. This can
|
||||
also be done by a retiring maintainer who nominates their replacement
|
||||
after discussion with other contributors.
|
||||
|
||||
Once the patch is reviewed and merged the only other step is to make
|
||||
sure your GPG key is signed.
|
||||
|
||||
.. _maintainer_keys:
|
||||
|
||||
Maintainer GPG Keys
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
GPG is used to sign pull requests so they can be identified as really
|
||||
coming from the maintainer. If your key is not already signed by
|
||||
members of the QEMU community, you should make arrangements to attend
|
||||
a `KeySigningParty <https://wiki.qemu.org/KeySigningParty>`__ (for
|
||||
example at KVM Forum) or make alternative arrangements to have your
|
||||
key signed by an attendee. Key signing requires meeting another
|
||||
community member **in person** [#]_ so please make appropriate
|
||||
arrangements.
|
||||
|
||||
.. [#] In recent pandemic times we have had to exercise some
|
||||
flexibility here. Maintainers still need to sign their pull
|
||||
requests though.
|
||||
|
|
@ -3,34 +3,27 @@
|
|||
Submitting a Patch
|
||||
==================
|
||||
|
||||
QEMU welcomes contributions of code (either fixing bugs or adding new
|
||||
functionality). However, we get a lot of patches, and so we have some
|
||||
guidelines about submitting patches. If you follow these, you'll help
|
||||
make our task of code review easier and your patch is likely to be
|
||||
committed faster.
|
||||
QEMU welcomes contributions to fix bugs, add functionality or improve
|
||||
the documentation. However, we get a lot of patches, and so we have
|
||||
some guidelines about submitting them. If you follow these, you'll
|
||||
help make our task of contribution review easier and your change is
|
||||
likely to be accepted and committed faster.
|
||||
|
||||
This page seems very long, so if you are only trying to post a quick
|
||||
one-shot fix, the bare minimum we ask is that:
|
||||
|
||||
- You **must** provide a Signed-off-by: line (this is a hard
|
||||
requirement because it's how you say "I'm legally okay to contribute
|
||||
this and happy for it to go into QEMU", modeled after the `Linux kernel
|
||||
<http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=f6f94e2ab1b33f0082ac22d71f66385a60d8157f#n297>`__
|
||||
policy.) ``git commit -s`` or ``git format-patch -s`` will add one.
|
||||
- All contributions to QEMU must be **sent as patches** to the
|
||||
qemu-devel `mailing list <https://wiki.qemu.org/Contribute/MailingLists>`__.
|
||||
Patch contributions should not be posted on the bug tracker, posted on
|
||||
forums, or externally hosted and linked to. (We have other mailing lists too,
|
||||
but all patches must go to qemu-devel, possibly with a Cc: to another
|
||||
list.) ``git send-email`` (`step-by-step setup
|
||||
guide <https://git-send-email.io/>`__ and `hints and
|
||||
tips <https://elixir.bootlin.com/linux/latest/source/Documentation/process/email-clients.rst>`__)
|
||||
works best for delivering the patch without mangling it, but
|
||||
attachments can be used as a last resort on a first-time submission.
|
||||
- You must read replies to your message, and be willing to act on them.
|
||||
Note, however, that maintainers are often willing to manually fix up
|
||||
first-time contributions, since there is a learning curve involved in
|
||||
making an ideal patch submission.
|
||||
.. list-table:: Minimal Checklist for Patches
|
||||
:widths: 35 65
|
||||
:header-rows: 1
|
||||
|
||||
* - Check
|
||||
- Reason
|
||||
* - Patches contain Signed-off-by: Real Name <author@email>
|
||||
- States you are legally able to contribute the code. See :ref:`patch_emails_must_include_a_signed_off_by_line`
|
||||
* - Sent as patch emails to ``qemu-devel@nongnu.org``
|
||||
- The project uses an email list based workflow. See :ref:`submitting_your_patches`
|
||||
* - Be prepared to respond to review comments
|
||||
- Code that doesn't pass review will not get merged. See :ref:`participating_in_code_review`
|
||||
|
||||
You do not have to subscribe to post (list policy is to reply-to-all to
|
||||
preserve CCs and keep non-subscribers in the loop on the threads they
|
||||
|
|
@ -229,6 +222,19 @@ bisection doesn't land on a known-broken state.
|
|||
Submitting your Patches
|
||||
-----------------------
|
||||
|
||||
The QEMU project uses a public email based workflow for reviewing and
|
||||
merging patches. As a result all contributions to QEMU must be **sent
|
||||
as patches** to the qemu-devel `mailing list
|
||||
<https://wiki.qemu.org/Contribute/MailingLists>`__. Patch
|
||||
contributions should not be posted on the bug tracker, posted on
|
||||
forums, or externally hosted and linked to. (We have other mailing
|
||||
lists too, but all patches must go to qemu-devel, possibly with a Cc:
|
||||
to another list.) ``git send-email`` (`step-by-step setup guide
|
||||
<https://git-send-email.io/>`__ and `hints and tips
|
||||
<https://elixir.bootlin.com/linux/latest/source/Documentation/process/email-clients.rst>`__)
|
||||
works best for delivering the patch without mangling it, but
|
||||
attachments can be used as a last resort on a first-time submission.
|
||||
|
||||
.. _if_you_cannot_send_patch_emails:
|
||||
|
||||
If you cannot send patch emails
|
||||
|
|
@ -314,10 +320,12 @@ git repository to fetch the original commit.
|
|||
Patch emails must include a ``Signed-off-by:`` line
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
For more information see `SubmittingPatches 1.12
|
||||
<http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=f6f94e2ab1b33f0082ac22d71f66385a60d8157f#n297>`__.
|
||||
This is vital or we will not be able to apply your patch! Please use
|
||||
your real name to sign a patch (not an alias or acronym).
|
||||
Your patches **must** include a Signed-off-by: line. This is a hard
|
||||
requirement because it's how you say "I'm legally okay to contribute
|
||||
this and happy for it to go into QEMU". The process is modelled after
|
||||
the `Linux kernel
|
||||
<http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=f6f94e2ab1b33f0082ac22d71f66385a60d8157f#n297>`__
|
||||
policy.
|
||||
|
||||
If you wrote the patch, make sure your "From:" and "Signed-off-by:"
|
||||
lines use the same spelling. It's okay if you subscribe or contribute to
|
||||
|
|
@ -327,6 +335,11 @@ include a "From:" line in the body of the email (different from your
|
|||
envelope From:) that will give credit to the correct author; but again,
|
||||
that author's Signed-off-by: line is mandatory, with the same spelling.
|
||||
|
||||
There are various tooling options for automatically adding these tags
|
||||
include using ``git commit -s`` or ``git format-patch -s``. For more
|
||||
information see `SubmittingPatches 1.12
|
||||
<http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches?id=f6f94e2ab1b33f0082ac22d71f66385a60d8157f#n297>`__.
|
||||
|
||||
.. _include_a_meaningful_cover_letter:
|
||||
|
||||
Include a meaningful cover letter
|
||||
|
|
@ -397,9 +410,19 @@ Participating in Code Review
|
|||
----------------------------
|
||||
|
||||
All patches submitted to the QEMU project go through a code review
|
||||
process before they are accepted. Some areas of code that are well
|
||||
maintained may review patches quickly, lesser-loved areas of code may
|
||||
have a longer delay.
|
||||
process before they are accepted. This will often mean a series will
|
||||
go through a number of iterations before being picked up by
|
||||
:ref:`maintainers<maintainers>`. You therefore should be prepared to
|
||||
read replies to your messages and be willing to act on them.
|
||||
|
||||
Maintainers are often willing to manually fix up first-time
|
||||
contributions, since there is a learning curve involved in making an
|
||||
ideal patch submission. However for the best results you should
|
||||
proactively respond to suggestions with changes or justifications for
|
||||
your current approach.
|
||||
|
||||
Some areas of code that are well maintained may review patches
|
||||
quickly, lesser-loved areas of code may have a longer delay.
|
||||
|
||||
.. _stay_around_to_fix_problems_raised_in_code_review:
|
||||
|
||||
|
|
@ -411,14 +434,20 @@ developers will identify bugs, or suggest a cleaner approach, or even
|
|||
just point out code style issues or commit message typos. You'll need to
|
||||
respond to these, and then send a second version of your patches with
|
||||
the issues fixed. This takes a little time and effort on your part, but
|
||||
if you don't do it then your changes will never get into QEMU. It's also
|
||||
just polite -- it is quite disheartening for a developer to spend time
|
||||
reviewing your code and suggesting improvements, only to find that
|
||||
you're not going to do anything further and it was all wasted effort.
|
||||
if you don't do it then your changes will never get into QEMU.
|
||||
|
||||
Remember that a maintainer is under no obligation to take your
|
||||
patches. If someone has spent the time reviewing your code and
|
||||
suggesting improvements and you simply re-post without either
|
||||
addressing the comment directly or providing additional justification
|
||||
for the change then it becomes wasted effort. You cannot demand others
|
||||
merge and then fix up your code after the fact.
|
||||
|
||||
When replying to comments on your patches **reply to all and not just
|
||||
the sender** -- keeping discussion on the mailing list means everybody
|
||||
can follow it.
|
||||
can follow it. Remember the spirit of the :ref:`code_of_conduct` and
|
||||
keep discussions respectful and collaborative and avoid making
|
||||
personal comments.
|
||||
|
||||
.. _pay_attention_to_review_comments:
|
||||
|
||||
|
|
|
|||
|
|
@ -53,14 +53,10 @@ series) and that "make check" passes before sending out the pull
|
|||
request. As a submaintainer you're one of QEMU's lines of defense
|
||||
against bad code, so double check the details.
|
||||
|
||||
**All pull requests must be signed**. If your key is not already signed
|
||||
by members of the QEMU community, you should make arrangements to attend
|
||||
a `KeySigningParty <https://wiki.qemu.org/KeySigningParty>`__ (for
|
||||
example at KVM Forum) or make alternative arrangements to have your key
|
||||
signed by an attendee. Key signing requires meeting another community
|
||||
member \*in person\* so please make appropriate arrangements. By
|
||||
"signed" here we mean that the pullreq email should quote a tag which is
|
||||
a GPG-signed tag (as created with 'gpg tag -s ...').
|
||||
**All pull requests must be signed**. By "signed" here we mean that
|
||||
the pullreq email should quote a tag which is a GPG-signed tag (as
|
||||
created with 'gpg tag -s ...'). See :ref:`maintainer_keys` for
|
||||
details.
|
||||
|
||||
**Pull requests not for master should say "not for master" and have
|
||||
"PULL SUBSYSTEM whatever" in the subject tag**. If your pull request is
|
||||
|
|
|
|||
|
|
@ -58,6 +58,9 @@ class BootLinuxX8664(LinuxTest):
|
|||
self.launch_and_wait(set_up_ssh_connection=False)
|
||||
|
||||
|
||||
# For Aarch64 we only boot KVM tests in CI as the TCG tests are very
|
||||
# heavyweight. There are lighter weight distros which we use in the
|
||||
# machine_aarch64_virt.py tests.
|
||||
class BootLinuxAarch64(LinuxTest):
|
||||
"""
|
||||
:avocado: tags=arch:aarch64
|
||||
|
|
@ -73,7 +76,8 @@ class BootLinuxAarch64(LinuxTest):
|
|||
self.vm.add_args('-device', 'virtio-rng-pci,rng=rng0')
|
||||
self.vm.add_args('-object', 'rng-random,id=rng0,filename=/dev/urandom')
|
||||
|
||||
def test_virt_tcg_gicv2(self):
|
||||
@skipIf(os.getenv('GITLAB_CI'), 'Running on GitLab')
|
||||
def test_fedora_cloud_tcg_gicv2(self):
|
||||
"""
|
||||
:avocado: tags=accel:tcg
|
||||
:avocado: tags=cpu:max
|
||||
|
|
@ -86,7 +90,8 @@ class BootLinuxAarch64(LinuxTest):
|
|||
self.add_common_args()
|
||||
self.launch_and_wait(set_up_ssh_connection=False)
|
||||
|
||||
def test_virt_tcg_gicv3(self):
|
||||
@skipIf(os.getenv('GITLAB_CI'), 'Running on GitLab')
|
||||
def test_fedora_cloud_tcg_gicv3(self):
|
||||
"""
|
||||
:avocado: tags=accel:tcg
|
||||
:avocado: tags=cpu:max
|
||||
|
|
@ -116,7 +121,7 @@ class BootLinuxPPC64(LinuxTest):
|
|||
:avocado: tags=arch:ppc64
|
||||
"""
|
||||
|
||||
timeout = 180
|
||||
timeout = 360
|
||||
|
||||
def test_pseries_tcg(self):
|
||||
"""
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
# Functional test that boots a Linux kernel and checks the console
|
||||
# Functional test that boots a various Linux systems and checks the
|
||||
# console output.
|
||||
#
|
||||
# Copyright (c) 2022 Linaro Ltd.
|
||||
#
|
||||
|
|
@ -8,19 +9,62 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-or-later
|
||||
|
||||
import time
|
||||
import os
|
||||
|
||||
from avocado_qemu import QemuSystemTest
|
||||
from avocado_qemu import wait_for_console_pattern
|
||||
from avocado_qemu import exec_command
|
||||
from avocado_qemu import BUILD_DIR
|
||||
|
||||
class Aarch64VirtMachine(QemuSystemTest):
|
||||
KERNEL_COMMON_COMMAND_LINE = 'printk.time=0 '
|
||||
timeout = 360
|
||||
|
||||
def wait_for_console_pattern(self, success_message, vm=None):
|
||||
wait_for_console_pattern(self, success_message,
|
||||
failure_message='Kernel panic - not syncing',
|
||||
vm=vm)
|
||||
|
||||
# This tests the whole boot chain from EFI to Userspace
|
||||
# We only boot a whole OS for the current top level CPU and GIC
|
||||
# Other test profiles should use more minimal boots
|
||||
def test_alpine_virt_tcg_gic_max(self):
|
||||
"""
|
||||
:avocado: tags=arch:aarch64
|
||||
:avocado: tags=machine:virt
|
||||
:avocado: tags=accel:tcg
|
||||
"""
|
||||
iso_url = ('https://dl-cdn.alpinelinux.org/'
|
||||
'alpine/v3.16/releases/aarch64/'
|
||||
'alpine-virt-3.16.3-aarch64.iso')
|
||||
|
||||
# Alpine use sha256 so I recalculated this myself
|
||||
iso_sha1 = '0683bc089486d55c91bf6607d5ecb93925769bc0'
|
||||
iso_path = self.fetch_asset(iso_url, asset_hash=iso_sha1)
|
||||
|
||||
self.vm.set_console()
|
||||
kernel_command_line = (self.KERNEL_COMMON_COMMAND_LINE +
|
||||
'console=ttyAMA0')
|
||||
self.require_accelerator("tcg")
|
||||
|
||||
self.vm.add_args("-accel", "tcg")
|
||||
self.vm.add_args("-cpu", "max,pauth-impdef=on")
|
||||
self.vm.add_args("-machine",
|
||||
"virt,acpi=on,"
|
||||
"virtualization=on,"
|
||||
"mte=on,"
|
||||
"gic-version=max,iommu=smmuv3")
|
||||
self.vm.add_args("-smp", "2", "-m", "1024")
|
||||
self.vm.add_args('-bios', os.path.join(BUILD_DIR, 'pc-bios',
|
||||
'edk2-aarch64-code.fd'))
|
||||
self.vm.add_args("-drive", f"file={iso_path},format=raw")
|
||||
self.vm.add_args('-device', 'virtio-rng-pci,rng=rng0')
|
||||
self.vm.add_args('-object', 'rng-random,id=rng0,filename=/dev/urandom')
|
||||
|
||||
self.vm.launch()
|
||||
self.wait_for_console_pattern('Welcome to Alpine Linux 3.16')
|
||||
|
||||
|
||||
def test_aarch64_virt(self):
|
||||
"""
|
||||
:avocado: tags=arch:aarch64
|
||||
|
|
|
|||
|
|
@ -12,6 +12,7 @@ from avocado_qemu import QemuSystemTest
|
|||
from avocado_qemu import wait_for_console_pattern
|
||||
from avocado_qemu import exec_command
|
||||
from avocado_qemu import exec_command_and_wait_for_pattern
|
||||
from avocado_qemu import interrupt_interactive_console_until_pattern
|
||||
from avocado.utils import archive
|
||||
from avocado import skipIf
|
||||
|
||||
|
|
@ -182,6 +183,8 @@ class AST2x00Machine(QemuSystemTest):
|
|||
|
||||
class AST2x00MachineSDK(QemuSystemTest):
|
||||
|
||||
EXTRA_BOOTARGS = ' quiet'
|
||||
|
||||
# FIXME: Although these tests boot a whole distro they are still
|
||||
# slower than comparable machine models. There may be some
|
||||
# optimisations which bring down the runtime. In the meantime they
|
||||
|
|
@ -194,7 +197,7 @@ class AST2x00MachineSDK(QemuSystemTest):
|
|||
failure_message='Kernel panic - not syncing',
|
||||
vm=vm)
|
||||
|
||||
def do_test_arm_aspeed_sdk_start(self, image, cpu_id):
|
||||
def do_test_arm_aspeed_sdk_start(self, image):
|
||||
self.require_netdev('user')
|
||||
self.vm.set_console()
|
||||
self.vm.add_args('-drive', 'file=' + image + ',if=mtd,format=raw',
|
||||
|
|
@ -202,9 +205,13 @@ class AST2x00MachineSDK(QemuSystemTest):
|
|||
self.vm.launch()
|
||||
|
||||
self.wait_for_console_pattern('U-Boot 2019.04')
|
||||
self.wait_for_console_pattern('## Loading kernel from FIT Image')
|
||||
interrupt_interactive_console_until_pattern(
|
||||
self, 'Hit any key to stop autoboot:', 'ast#')
|
||||
exec_command_and_wait_for_pattern(
|
||||
self, 'setenv bootargs ${bootargs}' + self.EXTRA_BOOTARGS, 'ast#')
|
||||
exec_command_and_wait_for_pattern(
|
||||
self, 'boot', '## Loading kernel from FIT Image')
|
||||
self.wait_for_console_pattern('Starting kernel ...')
|
||||
self.wait_for_console_pattern('Booting Linux on physical CPU ' + cpu_id)
|
||||
|
||||
@skipIf(os.getenv('GITLAB_CI'), 'Running on GitLab')
|
||||
def test_arm_ast2500_evb_sdk(self):
|
||||
|
|
@ -221,7 +228,7 @@ class AST2x00MachineSDK(QemuSystemTest):
|
|||
archive.extract(image_path, self.workdir)
|
||||
|
||||
self.do_test_arm_aspeed_sdk_start(
|
||||
self.workdir + '/ast2500-default/image-bmc', '0x0')
|
||||
self.workdir + '/ast2500-default/image-bmc')
|
||||
self.wait_for_console_pattern('ast2500-default login:')
|
||||
|
||||
@skipIf(os.getenv('GITLAB_CI'), 'Running on GitLab')
|
||||
|
|
@ -243,7 +250,7 @@ class AST2x00MachineSDK(QemuSystemTest):
|
|||
self.vm.add_args('-device',
|
||||
'ds1338,bus=aspeed.i2c.bus.5,address=0x32');
|
||||
self.do_test_arm_aspeed_sdk_start(
|
||||
self.workdir + '/ast2600-default/image-bmc', '0xf00')
|
||||
self.workdir + '/ast2600-default/image-bmc')
|
||||
self.wait_for_console_pattern('ast2600-default login:')
|
||||
exec_command_and_wait_for_pattern(self, 'root', 'Password:')
|
||||
exec_command_and_wait_for_pattern(self, '0penBmc', 'root@ast2600-default:~#')
|
||||
|
|
|
|||
|
|
@ -184,6 +184,7 @@ docker:
|
|||
@echo ' TARGET_LIST=a,b,c Override target list in builds.'
|
||||
@echo ' EXTRA_CONFIGURE_OPTS="..."'
|
||||
@echo ' Extra configure options.'
|
||||
@echo ' TEST_COMMAND="..." Override the default `make check` target.'
|
||||
@echo ' IMAGES="a b c ..": Restrict available images to subset.'
|
||||
@echo ' TESTS="x y z .." Restrict available tests to subset.'
|
||||
@echo ' J=[0..9]* Overrides the -jN parameter for make commands'
|
||||
|
|
@ -230,6 +231,7 @@ docker-run: docker-qemu-src
|
|||
$(if $(NETWORK),$(if $(subst $(NETWORK),,1),--net=$(NETWORK)),--net=none) \
|
||||
-e TARGET_LIST=$(subst $(SPACE),$(COMMA),$(TARGET_LIST)) \
|
||||
-e EXTRA_CONFIGURE_OPTS="$(EXTRA_CONFIGURE_OPTS)" \
|
||||
-e TEST_COMMAND="$(TEST_COMMAND)" \
|
||||
-e V=$V -e J=$J -e DEBUG=$(DEBUG) \
|
||||
-e SHOW_ENV=$(SHOW_ENV) \
|
||||
$(if $(NOUSER),, \
|
||||
|
|
|
|||
|
|
@ -63,12 +63,12 @@ check_qemu()
|
|||
{
|
||||
# default to make check unless the caller specifies
|
||||
if [ $# = 0 ]; then
|
||||
INVOCATION="check"
|
||||
INVOCATION="${TEST_COMMAND:-make $MAKEFLAGS check}"
|
||||
else
|
||||
INVOCATION="$@"
|
||||
INVOCATION="make $MAKEFLAGS $@"
|
||||
fi
|
||||
|
||||
make $MAKEFLAGS $INVOCATION
|
||||
$INVOCATION
|
||||
}
|
||||
|
||||
test_fail()
|
||||
|
|
|
|||
Loading…
Reference in New Issue