182 fails if qemu has no support for hotplugging of a virtio-blk device.
Using an NBD server instead works just as well for the test, even on
qemus without hotplugging support.
Fixes: 6d0a4a0fb5
Reported-by: Danilo C. L. de Paula <ddepaula@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20190417153005.30096-1-mreitz@redhat.com>
Tested-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Acked-by: Alberto Garcia <berto@igalia.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
For some particular configurations of ext4, sizing an image to 84
sectors + 1 byte causes test failures when the size of the hole is
rounded to a 4k alignment. Let's instead size things to 128 sectors +
1 byte, as the 64k boundary is more likely to work with various hole
granularities.
Reported-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20190506172111.31594-1-eblake@redhat.com>
Tested-by: Thomas Huth <thuth@redhat.com>
The output of qemu-io changed recently - most tests have been fixed in
commit 36b9986b08 ("tests/qemu-iotests: Fix output of qemu-io
related tests") already, but a qcow1, vmdk, and nbd test were still missing.
Fixes: 99e98d7c9f ("qemu-io: Use error_[gs]et_progname()")
Signed-off-by: Thomas Huth <thuth@redhat.com>
Message-Id: <20190501134127.21104-1-thuth@redhat.com>
[eblake: squash in NBD 083 fixes]
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Tested-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
233 generally filters the port, but in two cases does not. If some
other concurrently running application has already taken port 10809,
this will result in an output mismatch. Fix this by applying the
filter in these two cases, too.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20190506160529.6955-1-mreitz@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
* configure: automatically pick python3 is available
(Daniel P. Berrangé)
* tests/acceptance (Cleber Rosa, Philippe Mathieu-Daudé):
* Multi-architecture test support
* Multiple arch-specific boot_linux_console test cases
* Increase verbosity of avocado by default
* docstring improvements
-----BEGIN PGP SIGNATURE-----
iQIcBAABCAAGBQJcy43mAAoJECgHk2+YTcWm7DEQAIWbC47Ux4Mbww+RFFHGiqR0
Add+gvRp+PiAwHFqvE/tmWXlXFefMT6igeMfUmh6Z9SX+aWclX4IHP7NBQ5XeaWp
YPoPzh0aPft40EfI/ncN6YCSRB89knAVbJZzsBjIduVOgRhty0HLo7TcNxGOISMo
bUFGZEq8dFJW2twDBbYOD3ho4BSSw99RcfUcqp7SrIAvOi9b6AxN30MKomqwzZlq
gOjGqhbbOvGllNclnB1VKJOp+3e4G6TuJu//OWgroKTAZMYx0+qmcjnCH9b9noDN
JBhnoJbYGOS53FXNiPmhgz99hjQHSwovyepfwbnqHZgdFhMWceKkV2WbtsgixOba
NKX3DPvQgLybXOWVYGBFpPAc5WwzAgfGuXWcN3Qe6H9YdZruJJVS6ZDy4P41hqrL
1DAsMWVInwojwYT3Q5Xuy2FwUoEFXe1aFLzMc3KB7wDq1VOs9WfvXrECxWY3bo7z
7Ygx721vJzfheRrvLQSlK6o3TgVc9MjWdLInbXpHHZtjyfp65MahjOMUvFz/NXPk
DObg8xn35B955QSH08QsLl/t6uHx2YoEIJyXvHNr330U4+py0Akx3bPYwupKc6ft
6j7KNFB3w15jDE4+WRoWbwCbWfwJ3JmeZAp54rp4tT69b2+gFnCXVp4iS9ARMewo
gO4yr84+4dmHNt/tJp3b
=GuGy
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/ehabkost/tags/python-next-pull-request' into staging
Python queue, 2019-05-02
* configure: automatically pick python3 is available
(Daniel P. Berrangé)
* tests/acceptance (Cleber Rosa, Philippe Mathieu-Daudé):
* Multi-architecture test support
* Multiple arch-specific boot_linux_console test cases
* Increase verbosity of avocado by default
* docstring improvements
# gpg: Signature made Fri 03 May 2019 01:40:06 BST
# gpg: using RSA key 2807936F984DC5A6
# gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>" [full]
# Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6
* remotes/ehabkost/tags/python-next-pull-request:
configure: automatically pick python3 is available
tests/boot_linux_console: add a test for alpha + clipper
tests/boot_linux_console: add a test for s390x + s390-ccw-virtio
tests/boot_linux_console: add a test for arm + virt
tests/boot_linux_console: add a test for aarch64 + virt
tests/boot_linux_console: add a test for mips64el + malta
tests/boot_linux_console: add a test for mips + malta
scripts/qemu.py: support adding a console with the default serial device
tests/boot_linux_console: refactor the console watcher into utility method
tests/boot_linux_console: increase timeout
tests/boot_linux_console: add common kernel command line options
tests/boot_linux_console: update the x86_64 kernel
tests/boot_linux_console: rename the x86_64 after the arch and machine
tests/acceptance: look for target architecture in test tags first
tests/acceptance: use "arch:" tag to filter target specific tests
tests/acceptance: introduce arch parameter and attribute
tests/acceptance: fix doc reference to avocado_qemu directory
tests/acceptance: improve docstring on pick_default_qemu_bin()
tests/acceptance: show avocado test execution by default
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
# Conflicts:
# configure
Rebuild the "bios-tables-test" UEFI boot images with the SMBIOS entry
point reporting that has been added in the previous patch.
Cc: "Philippe Mathieu-Daud" <philmd@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Launchpad: https://bugs.launchpad.net/qemu/+bug/1821884
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Philippe Mathieu-Daud <philmd@redhat.com>
Tested-by: Igor Mammedov <imammedo@redhat.com>
On UEFI systems, the SMBIOS entry point (a.k.a. anchor) structures are
found similarly to the ACPI RSD PTR table(s): by scanning the
ConfigurationTable array in the EFI system table for well-known GUIDs.
Locate the SMBIOS 2.1 (32-bit) and 3.0 (64-bit) anchors in the
BiosTablesTest UEFI application, and report the addresses in new fields
appended to the BIOS_TABLES_TEST structure.
Cc: "Philippe Mathieu-Daud" <philmd@redhat.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Launchpad: https://bugs.launchpad.net/qemu/+bug/1821884
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daud <philmd@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Tested-by: Philippe Mathieu-Daud <philmd@redhat.com>
Tested-by: Igor Mammedov <imammedo@redhat.com>
Similar to the x86_64 + pc test, it boots a Linux kernel on a Malta
board and verify the serial is working. One extra command added to
the QEMU command line is '-vga std', because the kernel used is
known to crash without it.
If alpha is a target being built, "make check-acceptance" will
automatically include this test by the use of the "arch:alpha" tags.
Alternatively, this test can be run using:
$ avocado run -t arch:alpha tests/acceptance
$ avocado run -t machine:clipper tests/acceptance
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Cleber Rosa <crosa@redhat.com>
Reviewed-by: Caio Carrara <ccarrara@redhat.com>
Message-Id: <20190312171824.5134-21-crosa@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Just like the previous tests, boots a Linux kernel on a s390x target
using the s390-ccw-virtio machine.
Because it's not possible to have multiple VT220 consoles,
'-nodefaults' is used, so that the one set with set_console() works
correctly.
Signed-off-by: Cleber Rosa <crosa@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Caio Carrara <ccarrara@redhat.com>
Message-Id: <20190312171824.5134-20-crosa@redhat.com>
[ehabkost: Updated kernel URL to point to fedoraproject.org]
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Just like the previous tests, boots a Linux kernel on an arm target
using the virt machine.
Signed-off-by: Cleber Rosa <crosa@redhat.com>
Reviewed-by: Caio Carrara <ccarrara@redhat.com>
Message-Id: <20190312171824.5134-19-crosa@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Just like the previous tests, boots a Linux kernel on a aarch64 target
using the virt machine.
One special option added is the CPU type, given that the kernel
selected fails to boot on the virt machine's default CPU (cortex-a15).
Signed-off-by: Cleber Rosa <crosa@redhat.com>
Reviewed-by: Caio Carrara <ccarrara@redhat.com>
Message-Id: <20190312171824.5134-18-crosa@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Similar to the x86_64 + pc test, it boots a Linux kernel on a Malta
board and verify the serial is working.
If mips64el is a target being built, "make check-acceptance" will
automatically include this test by the use of the "arch:mips64el"
tags.
Alternatively, this test can be run using:
$ avocado run -t arch:mips64el tests/acceptance
$ avocado run -t machine:malta tests/acceptance
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Cleber Rosa <crosa@redhat.com>
Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com>
Message-Id: <20190312171824.5134-15-crosa@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Similar to the x86_64 + pc test, it boots a Linux kernel on a Malta
board and verify the serial is working. Also, it relies on the serial
device set by the machine itself.
If mips is a target being built, "make check-acceptance" will
automatically include this test by the use of the "arch:mips" tags.
Alternatively, this test can be run using:
$ avocado run -t arch:mips tests/acceptance
$ avocado run -t machine:malta tests/acceptance
$ avocado run -t endian:big tests/acceptance
Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
Signed-off-by: Cleber Rosa <crosa@redhat.com>
Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20190312171824.5134-14-crosa@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
This introduces a utility method that monitors the console device and
looks for either a message that signals the test success or failure.
Signed-off-by: Cleber Rosa <crosa@redhat.com>
Reviewed-by: Caio Carrara <ccarrara@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Message-Id: <20190312171824.5134-12-crosa@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
When running on very low powered environments, some tests may time out
causing false negatives. As a conservative change, and for
considering that human time (investigating false negatives) is worth
more than some extra machine cycles (and time), let's increase the
overall timeout.
CC: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Cleber Rosa <crosa@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Message-Id: <20190312171824.5134-11-crosa@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
The 'printk.time=0' option makes it easier to parse the console
output. Let's set it as a default, and reusable, kernel command line
options for this and future similar tests.
Signed-off-by: Cleber Rosa <crosa@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Message-Id: <20190312171824.5134-10-crosa@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Update to the stock Fedora 29 kernel, from the Fedora 28. New tests
will be added using the 29 kernel, so for consistency, let's also
update it here.
Signed-off-by: Cleber Rosa <crosa@redhat.com>
Reviewed-by: Caio Carrara <ccarrara@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Acked-by: Cornelia Huck <cohuck@redhat.com>
CC: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20190312171824.5134-9-crosa@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Given that the test is specific to x86_64 and pc, and new tests are
going to be added to the same class, let's rename it accordingly.
Also, let's make the class documentation not architecture specific.
Signed-off-by: Cleber Rosa <crosa@redhat.com>
Reviewed-by: Caio Carrara <ccarrara@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Message-Id: <20190312171824.5134-8-crosa@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
A test can, optionally, be tagged for one or many architectures. If a
test has been tagged for a single architecture, there's a high chance
that the test won't run on other architectures. This changes the
default order of choosing a default target architecture to use based
on the 'arch' tag value first.
The precedence order is for choosing a QEMU binary to use for a test
is now:
* qemu_bin parameter
* arch parameter
* arch tag value (for example, x86_64 if "🥑 tags=arch:x86_64
is used)
This means that if one runs:
$ avocado run -p qemu_bin=/usr/bin/qemu-system-x86_64 test.py
No arch parameter or tag will influence the selection of the QEMU
target binary. If one runs:
$ avocado run -p arch=ppc64 test.py
The target binary selection mechanism will attempt to find a binary
such as "ppc64-softmmu/qemu-system-ppc64". And finally, if one runs
a test that is tagged (in its docstring) with "arch:aarch64":
$ avocado run aarch64.py
The target binary selection mechanism will attempt to find a binary
such as "aarch64-softmmu/qemu-system-aarch64".
At this time, no provision is made to cancel the execution of tests if
the arch parameter given (manually) does not match the test "arch"
tag, but it may be a useful default behavior to be added in the
future.
Signed-off-by: Cleber Rosa <crosa@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Message-Id: <20190312171824.5134-7-crosa@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Currently, some tests contains target architecture information, in the
form of a "x86_64" tag. But that tag is not respected in the default
execution, that is, "make check-acceptance" doesn't do anything with
it.
That said, even the target architecture handling currently present in
the "avocado_qemu.Test" class is pretty limited. For instance, by
default, it chooses a target based on the host architecture.
Because the original implementation of the tags feature in Avocado did
not include any time of namespace or "key:val" mechanism, no tag has
relation to another tag. The new implementation of the tags feature
from version 67.0 onwards, allows "key:val" tags, and because of that,
a test can be classified with a tag in a given key. For instance, the
new proposed version of the "boot_linux_console.py" test, which
downloads and attempts to run a x86_64 kernel, is now tagged as:
🥑 tags=arch:x86_64
This means that it can be filtered (out) when no x86_64 target is
available. At the same time, tests that don't have a "arch:" tag,
will not be filtered out.
Signed-off-by: Cleber Rosa <crosa@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Message-Id: <20190312171824.5134-6-crosa@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
It's useful to define the architecture that should be used in
situations such as:
* the intended target of the QEMU binary to be used on tests
* the architecture of code to be run within the QEMU binary, such
as a kernel image or a full blown guest OS image
This commit introduces both a test parameter and a test instance
attribute, that will contain such a value.
Now, when the "arch" test parameter is given, it will influence the
selection of the default QEMU binary, if one is not given explicitly
by means of the "qemu_img" parameter.
Signed-off-by: Cleber Rosa <crosa@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Message-Id: <20190312171824.5134-5-crosa@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Making it clear what is returned by this utility function.
Signed-off-by: Cleber Rosa <crosa@redhat.com>
Reviewed-by: Caio Carrara <ccarrara@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Message-Id: <20190312171824.5134-3-crosa@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
The current version of the "check-acceptance" target will only show
one line for execution of all tests. That's probably OK if the tests
to be run are quick enough and they're always the same.
But, there's already one test alone that takes on average ~5 seconds
to run, we intend to adapt the list of tests to match the user's build
environment (among other choices).
Because of that, let's present the default Avocado UI by default.
Users can always choose a different output by setting the AVOCADO_SHOW
variable.
Signed-off-by: Cleber Rosa <crosa@redhat.com>
Reviewed-by: Caio Carrara <ccarrara@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Message-Id: <20190312171824.5134-2-crosa@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Add a gva2gpa command purely for debug which performs
address translation on the gva, the existing gpa2hva
command can then also be used to find it in the qemu
userspace; e.g.
(qemu) info registers
.... RSP=ffffffff81c03e98
....
(qemu) gva2gpa 0xffffffff81c03e98
gpa: 0x1c03e98
(qemu) gpa2hva 0x1c03e98
Host virtual address for 0x1c03e98 (pc.ram) is 0x7f0599a03e98
(qemu) x/10x 0xffffffff81c03e98
ffffffff81c03e98: 0x81c03eb8 0xffffffff 0x8101ea3f 0xffffffff
ffffffff81c03ea8: 0x81d27b00 0xffffffff 0x00000000 0x00000000
ffffffff81c03eb8: 0x81c03ec8 0xffffffff
gdb -p ...qemu...
(gdb) x/10x 0x7f0599a03e98
0x7f0599a03e98: 0x81c03eb8 0xffffffff 0x8101ea3f 0xffffffff
0x7f0599a03ea8: 0x81d27b00 0xffffffff 0x00000000 0x00000000
0x7f0599a03eb8: 0x81c03ec8 0xffffffff
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20190412152652.827-1-dgilbert@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
qemu-img create allows giving just a format and "-o help" to get a list
of the options supported by that format. Users may not realize that the
protocol level may offer even more options, which they only get to see
by specifying a filename.
This patch adds a note to hint at that fact.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
In the "amend" section of 082, we perform a single "convert" test
(namely "convert -o help"). That does not make sense, especially
because we have done exactly that "convert" test earlier in 082 already.
Replacing "convert" by "amend" yields an error, which is correct because
there is no point in "amend" having a default format. The user has to
either specify the format, or give a file for qemu-img to probe.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Disk sizes close to INT64_MAX cause overflow, for some pretty
ridiculous output:
$ ./nbdkit -U - memory size=$((2**63 - 512)) --run 'qemu-img info $nbd'
image: nbd+unix://?socket=/tmp/nbdkitHSAzNz/socket
file format: raw
virtual size: -8388607T (9223372036854775296 bytes)
disk size: unavailable
But there's no reason to have two separate implementations of integer
to human-readable abbreviation, where one has overflow and stops at
'T', while the other avoids overflow and goes all the way to 'E'. With
this patch, the output now claims 8EiB instead of -8388607T, which
really is the correct rounding of largest file size supported by qemu
(we could go 511 bytes larger if we used byte-accurate sizing instead
of rounding up to the next sector boundary, but that wouldn't change
the human-readable result).
Quite a few iotests need updates to expected output to match.
Reported-by: Richard W.M. Jones <rjones@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Tested-by: Richard W.M. Jones <rjones@redhat.com>
Reviewed-by: Alberto Garcia <berto@igalia.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Tested-by: Max Reitz <mreitz@redhat.com>
One of the recent commits changed the way qemu-io prints out its
errors and warnings - they are now prefixed with the program name.
We've got to adapt the iotests accordingly to prevent that they
are failing.
Fixes: 99e98d7c9f ("qemu-io: Use error_[gs]et_progname()")
Signed-off-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJcsHOvAAoJEC7Z13T+cC21IgoP/37yKOLOuagT4an9L573qWPp
xCS48CJ4rNkpWXP3SHuTe+UHSp20sk+5b6rgM/VkLT2d301WS4gxF/VVu85ZFxGX
tkqDwnljb87MqwTbH5Yj/U4mmq8tZkNg4CqmWuvJhWv4aFe6T/YtAzUkl7y7YCcT
QfKqErl363JJKkL7cz+QWopFn5Gl/hy+mvEhbEtexWLIV1UNZ1i2hPWURfkh8FWH
C1047CAfnC/rEJy0GcwkH4iCem8n4LWkMuf3Zehq+Yx+f2e8FfxMkoOtLJVCoKWj
qoMidAplGqUxLoamZsbU1wEzwH6YH28X+uNUULsgDIIBuyW35ymbGsGTmKmNm6ED
zVM1K7badvLeO3PXBxUkviZk7UFjxjXz3xCQMheY47wPoslfX+EN0xUvQ2gW2MvO
Dhb9oPWsr/PFrMMJ35D2OOFH5kJC8Sj30YiP5lsnRoUBi4ecHCIUSlw6esKuYI+H
JfDAYzxe6QqoGg5cxSNUXP+vAgU/FQq+nGNGHzHnsIR4Udt/JsAtNwxQ9DCbYR0C
LA5qxZZTqkDtLPAHynqOzd8m7AoNaBSAgP2qp7Yp8ItXMyemlW2OIYR7yRxuL5bH
zWO/deGYHp3+j9/Z0quzSUL5G85m0o1xgRJcJe9T2fYjWgsy271WFqaZg1JEvpI6
zHcXEw71B7WQuAFaFO1+
=tJvv
-----END PGP SIGNATURE-----
Merge tag 's390-ccw-bios-2019-04-12' into s390-next-staging
Support for booting from a vfio-ccw passthrough dasd device
# gpg: Signature made Fri 12 Apr 2019 01:17:03 PM CEST
# gpg: using RSA key 2ED9D774FE702DB5
# gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [full]
# gpg: aka "Thomas Huth <thuth@redhat.com>" [undefined]
# gpg: aka "Thomas Huth <huth@tuxfamily.org>" [undefined]
# gpg: aka "Thomas Huth <th.huth@posteo.de>" [unknown]
* tag 's390-ccw-bios-2019-04-12':
pc-bios/s390: Update firmware images
s390-bios: Use control unit type to find bootable devices
s390-bios: Support booting from real dasd device
s390-bios: Add channel command codes/structs needed for dasd-ipl
s390-bios: Use control unit type to determine boot method
s390-bios: Refactor virtio to run channel programs via cio
s390-bios: Factor finding boot device out of virtio code path
s390-bios: Extend find_dev() for non-virtio devices
s390-bios: cio error handling
s390-bios: Support for running format-0/1 channel programs
s390-bios: ptr2u32 and u32toptr
s390-bios: Map low core memory
s390-bios: Decouple channel i/o logic from virtio
s390-bios: Clean up cio.h
s390-bios: decouple common boot logic from virtio
s390-bios: decouple cio setup from virtio
s390 vfio-ccw: Add bootindex property and IPLB data
Signed-off-by: Cornelia Huck <cohuck@redhat.com>
build and capture platform firmware binaries from that release. The
binaries are meant to be used by both end-users and by the "BIOS tables"
unit tests in qtest ("make check").
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABCAAGBQJcvgXYAAoJENOdpx4NSWz6tZMP/jHBTOmKfQhBOupSHl5QUN4/
3NFzyIjZht2Pdn5ckAI7VbWzYqNFnI8C/Ffvs+WGc9+uUj930zR1UaWGWZ+Cpr/Z
DQlKBfGL1BTfyPGZFlJ6alDHV9Ka9RsSyIADsQkAoYsaR5Q+hOrT8YmMsCf6/94I
3wnQQZpIOUTG1PuwQiezvrb4dwdXbSQpMNeirza2ftcDya3ctu7bIfuBj9dCD6xb
dcIMKDBLO047c97ILVQC5rvonk3BZmGi9iY6Wp7uiUoZc4lcVIvqBHYPpOaJj3Ws
x2c+OyVriTMdYEtS7eqWkwu6yhf4ts5L5AdNtE1p3hlPAdJiZ1j5T/y70MD15cQO
UGztNoSekeZRGngLZzOsE9ZfMbGMwYnFgx6MPjJHun2rrYSoHtiaQR5OeV2PIGth
Wk/MRub901B8qqbPCeatdSiIyyzBav/NjA49hUA0HJ4QarbEN+BviALGMZf7wXLL
YRvFCqDfvOEzFjqFTDhv/BwmcbgT68pAjE3vUKplyKisVb4o01aYZ6CNQAYWLnKc
ndVHyapbhe5ZF7JY29D0oWfmu0UYRxyfTyS9AY+D0J+FoJgi927uC9jZk3qpze5i
lljnH5C7iF974YeLB75xsdPfnsARSSC8kehCFFBVWqAa/ZsLR0PEZCUnwyf+QTvk
pej6tCtrEFTwhPcfbvnc
=k5c2
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/lersek/tags/edk2-pull-2019-04-22' into staging
Advance the roms/edk2 submodule to the "edk2-stable201903" release, and
build and capture platform firmware binaries from that release. The
binaries are meant to be used by both end-users and by the "BIOS tables"
unit tests in qtest ("make check").
# gpg: Signature made Mon 22 Apr 2019 19:20:08 BST
# gpg: using RSA key D39DA71E0D496CFA
# gpg: Good signature from "Laszlo Ersek <lersek@redhat.com>" [marginal]
# gpg: WARNING: This key is not certified with sufficiently trusted signatures!
# gpg: It is not certain that the signature belongs to the owner.
# Primary key fingerprint: F5D9 660F 1BA5 F310 A95A C5E0 466A EAE0 6125 3988
# Subkey fingerprint: B3A5 5D3F 88A8 90ED 2E63 3E8D D39D A71E 0D49 6CFA
* remotes/lersek/tags/edk2-pull-2019-04-22:
MAINTAINERS: add the "EDK2 Firmware" subsystem
Makefile: install the edk2 firmware images and their descriptors
tests: add missing dependency to build QTEST_QEMU_BINARY, round 2
pc-bios: document the edk2 firmware images; add firmware descriptors
pc-bios: add edk2 firmware binaries and variable store templates
roms: build edk2 firmware binaries and variable store templates
roms/Makefile: replace the $(EDK2_EFIROM) target with "edk2-basetools"
roms/edk2-funcs.sh: add the qemu_edk2_get_thread_count() function
roms/edk2: advance to tag edk2-stable201903
tests/uefi-test-tools/build.sh: work around TianoCore#1607
roms/edk2-funcs.sh: require gcc-4.8+ for building i386 and x86_64
roms: lift "edk2-funcs.sh" from "tests/uefi-test-tools/build.sh"
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
We commonly want to print to the current monitor if we have one, else
to stdout/stderr. For stderr, have error_printf(). For stdout, all
we have is monitor_vfprintf(), which is rather unwieldy. We often
print to stderr just because error_printf() is easier.
New qemu_printf() and qemu_vprintf() do exactly what's needed. The
next commits will put them to use.
Cc: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Message-Id: <20190417190641.26814-12-armbru@redhat.com>
In commit b94b330e23 ("tests: add missing dependency to build
QTEST_QEMU_BINARY", 2017-07-31), Phil fixed the dependency list of make
target "check-qtest-%". Namely, the recipe would set QTEST_QEMU_BINARY to
the softmmu emulator for the emulation target, but the prerequisites
didn't include the emulator.
The same issue affects the "check-report-qtest-%.tap" make target, which
is the other make target whose recipe sets QTEST_QEMU_BINARY:
> $ make -j4 check-report-qtest-aarch64.tap
> TAP check-report-qtest-aarch64.tap
> sh: /.../aarch64-softmmu/qemu-system-aarch64: No such file or directory
Apply Phil's fix to this make target too.
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Tested-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Philippe Mathieu-Daud <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daud <philmd@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
The edk2-stabe201903 release introduced Python3 support to edk2's
BaseTools; however the Python3 enablement breaks in a corner case (which
is nevertheless supported by the edk2 community), namely the in-module
parallelization that we utilize.
This is tracked under
<https://bugzilla.tianocore.org/show_bug.cgi?id=1607>. For now, work
around the issue (in advance) by forcing Python2. (The workaround is a
no-op before we move to edk2-stabe201903 in the roms/edk2 submodule.)
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daud <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daud <philmd@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Tested-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Extract the dense logic for architecture and toolchain massaging from
"tests/uefi-test-tools/build.sh", to a set of small functions. We'll reuse
these functions for building full platform firmware images.
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daud <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daud <philmd@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Tested-by: Igor Mammedov <imammedo@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Filter the qemu-nbd server output to get rid of a direct reference
to my build directory.
Fixes: e9dce9cb
Reported-by: Max Reitz <mreitz@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
tmpfs does not support O_DIRECT. Detect this case, and skip flipping
@direct if the filesystem does not support it.
Fixes: bf3e50f623
Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Alberto Garcia <berto@igalia.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Make a new routine find_boot_device to locate the boot device for all
cases, not just virtio.
The error message for the case where no boot device has been specified
and a suitable boot device cannot be auto detected was specific to
virtio devices. We update this message to remove virtio specific wording.
Signed-off-by: Jason J. Herne <jjherne@linux.ibm.com>
Reviewed-by: Farhan Ali <alifm@linux.ibm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Message-Id: <1554388475-18329-12-git-send-email-jjherne@linux.ibm.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
drive_new() returns null without setting an error when it provided
help. add_init_drive() assumes null means failure, and crashes trying
to report a null error.
Fixes: c4f26c9f37
Cc: qemu-stable@nongnu.org
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
The test uses the trick:
if (!opts) {
opts = &(QOSGraph...Options) { };
}
in a couple of places, however the temporary created
by the &() {} goes out of scope at the bottom of the if,
and results in a seg or assert when opts-> fields are
used (on fedora 30's gcc 9).
Fixes: fc281c8020
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-Id: <20190405184037.16799-1-dgilbert@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Clean up wrong usage of FALSE and TRUE in places that use "bool" from stdbool.h.
FALSE and TRUE (with capital letters) are the constants defined by glib for
being used with the "gboolean" type of glib. But some parts of the code also use
TRUE and FALSE for variables that are declared as "bool" (the type from <stdbool.h>).
Signed-off-by: Jafar Abdi <cafer.abdi@gmail.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Message-Id: <1553351197-14581-4-git-send-email-cafer.abdi@gmail.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Clean up wrong usage of FALSE and TRUE in places that use "bool" from stdbool.h.
FALSE and TRUE (with capital letters) are the constants defined by glib for
being used with the "gboolean" type of glib. But some parts of the code also use
TRUE and FALSE for variables that are declared as "bool" (the type from <stdbool.h>).
Signed-off-by: Jafar Abdi <cafer.abdi@gmail.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Message-Id: <1553351197-14581-3-git-send-email-cafer.abdi@gmail.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Ensure watch IDs unique within a monitor and avoid integer wraparound
issues when many watches are set & unset over time.
-----BEGIN PGP SIGNATURE-----
iQIcBAABCAAGBQJco1tUAAoJEL6G67QVEE/f9xYP/2OTsAk6dHCcWqc///jXN0JW
OLcnpmjuh5KgUmOrs7NIRYRo2DARrhNDDXckHjDuX2HmnzoTB5p7DXLWMPgAzxj6
o83yxYT0Qqw79wxqbDmJ1y3kUVka1r94wCmmvUmxQZjLbDk8u2ytNUDbEOVlM0VJ
R7T800j8PhbY1pg9PiJJZonm7dxZAVNSCF4AgkrJVIes6MqhvNUhVsck5q/CC3yi
0jkglsiVTyXjKpJsioM9VhQXeqiHfFl3qjcPi0XQ99lVpTMFysNd4UdnVXhNs9NI
Xe52yQ7NG3fEggUivtFBmvVplNOg09K6U2vkyk9z8S1WTLZsbabwvwSvkVPW3Ty0
QaDgI6wNSiBb7Lfl2bbUR6X3j9QXUn8bhlczBsorS4uU4+NdHGyERsZLKLZazYYz
5t+xm4YBGJhtlt8IglNBjtaJFBuqgjrBEuBkfpevB2ocioWnU6APOdwWkKlSe3+r
EuKFUcbhRiRAGO05DjntNkePigb66IVkSiJXd4uSid/+akn5kQ19PSD8tXdfvZ7h
8HYTnWZa3OSLd7tZlwRzimnKuVSIsSnj+NobkIs8HSS3N7oN1t4FC5jH9D6GmK0R
djQs6a5mHQbonrc0dXxlb+P8u6I+ppxznPpfL/aQJ4pFM18V6gmcZEQluhwALNe9
rdPUnCudC/9SUNpMf3rI
=qriK
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/berrange/tags/filemon-next-pull-request' into staging
filemon: various fixes / improvements to file monitor for USB MTP
Ensure watch IDs unique within a monitor and avoid integer wraparound
issues when many watches are set & unset over time.
# gpg: Signature made Tue 02 Apr 2019 13:53:40 BST
# gpg: using RSA key BE86EBB415104FDF
# gpg: Good signature from "Daniel P. Berrange <dan@berrange.com>" [full]
# gpg: aka "Daniel P. Berrange <berrange@redhat.com>" [full]
# Primary key fingerprint: DAF3 A6FD B26B 6291 2D0E 8E3F BE86 EBB4 1510 4FDF
* remotes/berrange/tags/filemon-next-pull-request:
filemon: fix watch IDs to avoid potential wraparound issues
filemon: ensure watch IDs are unique to QFileMonitor scope
tests: refactor file monitor test to make it more understandable
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Watch IDs are allocated from incrementing a int counter against
the QFileMonitor object. In very long life QEMU processes with
a huge amount of USB MTP activity creating & deleting directories
it is just about conceivable that the int counter can wrap
around. This would result in incorrect behaviour of the file
monitor watch APIs due to clashing watch IDs.
Instead of trying to detect this situation, this patch changes
the way watch IDs are allocated. It is turned into an int64_t
variable where the high 32 bits are set from the underlying
inotify "int" ID. This gives an ID that is guaranteed unique
for the directory as a whole, and we can rely on the kernel
to enforce this. QFileMonitor then sets the low 32 bits from
a per-directory counter.
The USB MTP device only sets watches on the directory as a
whole, not files within, so there is no risk of guest
triggered wrap around on the low 32 bits.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The watch IDs are mistakenly only unique within the scope of the
directory being monitored. This is not useful for clients which are
monitoring multiple directories. They require watch IDs to be unique
globally within the QFileMonitor scope.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Tested-by: Bandan Das <bsd@redhat.com>
Reviewed-by: Bandan Das <bsd@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The current file monitor unit tests are too clever for their own good
making it hard to understand the desired output.
Instead of trying to infer the expected events, explicitly list the
events we expect in the operation sequence.
Instead of dynamically building a matrix of tests, just have one giant
operation sequence that validates all scenarios in a single test.
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
