We currently put the initrd at the smaller of:
* 128MB into RAM
* halfway into the RAM
(with the dtb following it).
However for large kernels this might mean that the kernel
overlaps the initrd. For some kinds of kernel (self-decompressing
32-bit kernels, and ELF images with a BSS section at the end)
we don't know the exact size, but even there we have a
minimum size. Put the initrd at least further into RAM than
that. For image formats that can give us an exact kernel size, this
will mean that we definitely avoid overlaying kernel and initrd.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Message-id: 20190516144733.32399-4-peter.maydell@linaro.org
We calculate the locations in memory where we want to put the
initrd and the DTB based on the size of the kernel, since they
come after it. Add some explicit checks that these aren't off the
end of RAM entirely.
(At the moment the way we calculate the initrd_start means that
it can't ever be off the end of RAM, but that will change with
the next commit.)
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Message-id: 20190516144733.32399-3-peter.maydell@linaro.org
In the Arm kernel/initrd loading code, in some places we make the
incorrect assumption that info->ram_size can be treated as the
address of the end of RAM, as for instance when we calculate the
available space for the initrd using "info->ram_size - info->initrd_start".
This is wrong, because many Arm boards (including "virt") specify
a non-zero info->loader_start to indicate that their RAM area
starts at a non-zero physical address.
Correct the places which make this incorrect assumption.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Message-id: 20190516144733.32399-2-peter.maydell@linaro.org
A bunch of minor fixes all over the place.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
-----BEGIN PGP SIGNATURE-----
iQEcBAABAgAGBQJdBqqnAAoJECgfDbjSjVRp7isIAK7kmHhPtGNhv+7Nz35Dk5fo
de2OQO8Luqv58yAbqIIo8JVH/AAN+EZAx1gyI4lW1lzV8DFxCaim9JBriXVchc8l
1I1oaRh62nVhJnzP+9U1AiAYW/3L/4N1dkGVqSPfAN4P+TxBH4MbavlwUPDJhao/
iNHF9sxG4fxcBzN/IGbNuSnHAf1Kadd0Lf7hX7ltAHItsrLM7DUy/nT0WikoDVhO
vT7eDv/9B1Cgzt2mx5pyud+zLsjW/2RIxMDZFc40R5DhqPtnoHxm1zRkXIwvfGNO
oBoZ05P36kUt0jcRYEcsrz9vDfmBBWp7CtOT4oZW58K4VMGZRoUlU6bnjBf1B2Q=
=nes2
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging
virtio, acpi: fixes, cleanups
A bunch of minor fixes all over the place.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
# gpg: Signature made Sun 16 Jun 2019 21:46:31 BST
# gpg: using RSA key 281F0DB8D28D5469
# gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [full]
# gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [full]
# Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67
# Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469
* remotes/mst/tags/for_upstream:
tests/rebuild-expected-aml.sh: blow out difflist
q35: update DSDT
q35: fix mmconfig and PCI0._CRS
hw/acpi: extract acpi_add_rom_blob()
vhost: fix vhost_log size overflow during migration
docs/vhost-user.json: some firmware.json copy leftovers
vhost-user-gpu: initialize msghdr & iov at declaration
vhost-user-input: check ioctl(EVIOCGNAME) return value
vhost-user: improve error report
vhost-user: check unix_listen() return value
vhost-user-gpu: do not send scanout update if no GPU socket
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
https://github.com/tianocore/edk2/releases/tag/edk2-stable201905
Advance QEMU's edk2 submodule to edk2-stable201905, and rebuild the
firmware binaries. This should be the edk2 release that goes into QEMU
4.1.
Launchpad: https://bugs.launchpad.net/qemu/+bug/1831477
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABCAAGBQJdA/75AAoJENOdpx4NSWz6YtEP/iEW2F2CXtGmOmBoL67vvbXT
kFbVyto2Z4agMS4C7TSQyoDQ3eWbDQoaupnKfAhmpLzi9bNOvT53YaO+5vKty7P6
9uD+G0obdUTTrn510EE6Np5ph5eHakaEnhwSJv0sNQhYA1xgD1ZHmkxQS1swbSA0
NSWxWpI6puzJyvVO4YNzulVTt7RFoo2jXw2gvyOaJ0KPACigKO0LQpNfmX0CPAGQ
4RSVajuMSZAhLGnKk5ctt0+ucbi/KYmdy7SP3aifoHm9KvIdqkovH67YGdkVrfCL
/pwlpmFgkzxXSovOAEJPjmdYvJzWG9GN2Y6ichOLy/2d8ZHh5cFR4mhYa/x16nAV
eb3EmM1CqqTlmqCJ6Q2NIar8ADD4YsUGX7/s/ETdP5SaWM4dR1oKZe8c3gKDt47T
vbP/yCIETsYWztS7tSTMnUWEDoZfucUd1PyiKyt9TMmbI8wHRFtVGjLT7HvMUqqk
+rs9zRbwbOlHWusvjInMX2XDDlfqVfGsZq5EWgXUd0m/yK3/lE36wE3X3KXwva/h
uYOhUQDvegdvIjg043FX9GNCIm7JRZ1tWhMIujXW0WSqWSiPOqcv6BeC3MbU3WZQ
TMAjNMRWyBWGbMEfGyBMGkVsv5UkY+pEMwyxuJAcN9oXpeMjYZaSou1CregRt+Sn
ApLrzSrCkMMCokFuIrPX
=2MB6
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/lersek/tags/edk2-pull-2019-06-14' into staging
edk2-stable201905 was released on 2019-06-06:
https://github.com/tianocore/edk2/releases/tag/edk2-stable201905
Advance QEMU's edk2 submodule to edk2-stable201905, and rebuild the
firmware binaries. This should be the edk2 release that goes into QEMU
4.1.
Launchpad: https://bugs.launchpad.net/qemu/+bug/1831477
# gpg: Signature made Fri 14 Jun 2019 21:09:29 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-06-14:
pc-bios: update the README file with edk2-stable201905 information
pc-bios: refresh edk2 build artifacts for edk2-stable201905
roms/Makefile.edk2: update input file list for "pc-bios/edk2-licenses.txt"
roms/Makefile.edk2: remove edk2-stable201903 network feature test macros
roms/edk2: update submodule from edk2-stable201903 to edk2-stable201905
roms/Makefile.edk2: define edk2-stable201905 network feature test macros
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
As expected files have been updated, make sure we
do not forget to remove them from the allowed
diff list.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
update expected files and drop them from allowed diff list.
Fixes: 4a4418369d ("q35: fix mmconfig and PCI0._CRS")
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
This patch changes the handling of the mmconfig area. Thanks to the
pci(e) expander devices we already have the logic to exclude address
ranges from PCI0._CRS. We can simply add the mmconfig address range
to the list get it excluded as well.
With that in place we can go with a fixed pci hole which covers the
whole area from the end of (low) ram to the ioapic.
This will make the whole logic alot less fragile. No matter where the
firmware places the mmconfig xbar, things should work correctly. The
guest also gets a bit more PCI address space (seabios boot):
# cat /proc/iomem
[ ... ]
7ffdd000-7fffffff : reserved
80000000-afffffff : PCI Bus 0000:00 <<-- this is new
b0000000-bfffffff : PCI MMCONFIG 0000 [bus 00-ff]
b0000000-bfffffff : reserved
c0000000-febfffff : PCI Bus 0000:00
f8000000-fbffffff : 0000:00:01.0
[ ... ]
So this is a guest visible change.
Cc: László Érsek <lersek@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
Message-Id: <20190607073429.3436-1-kraxel@redhat.com>
arm and i386 has almost the same function acpi_add_rom_blob(), except
giving different FWCfgCallback function.
This patch moves acpi_add_rom_blob() to utils.c by passing
FWCfgCallback to it.
Signed-off-by: Wei Yang <richardw.yang@linux.intel.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
v7:
* rebase on top of current master because of conflict
v6:
* change author from Igor to Michael
v5:
* remove unnecessary header glib/gprintf.h
* rearrange include header to make it more suitable
v4:
* extract -> moves
* adjust comment in source to make checkpatch happy
v3:
* put acpi_add_rom_blob() to hw/acpi/utils.c
v2:
* remove unused header in original source file
Message-Id: <20190610011830.28398-1-richardw.yang@linux.intel.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
When a guest which doesn't support multiqueue is migrated with a multi queues
vhost-user-blk deivce, a crash will occur like:
0 qemu_memfd_alloc (name=<value optimized out>, size=562949953421312, seals=<value optimized out>, fd=0x7f87171fe8b4, errp=0x7f87171fe8a8) at util/memfd.c:153
1 0x00007f883559d7cf in vhost_log_alloc (size=70368744177664, share=true) at hw/virtio/vhost.c:186
2 0x00007f88355a0758 in vhost_log_get (listener=0x7f8838bd7940, enable=1) at qemu-2-12/hw/virtio/vhost.c:211
3 vhost_dev_log_resize (listener=0x7f8838bd7940, enable=1) at hw/virtio/vhost.c:263
4 vhost_migration_log (listener=0x7f8838bd7940, enable=1) at hw/virtio/vhost.c:787
5 0x00007f88355463d6 in memory_global_dirty_log_start () at memory.c:2503
6 0x00007f8835550577 in ram_init_bitmaps (f=0x7f88384ce600, opaque=0x7f8836024098) at migration/ram.c:2173
7 ram_init_all (f=0x7f88384ce600, opaque=0x7f8836024098) at migration/ram.c:2192
8 ram_save_setup (f=0x7f88384ce600, opaque=0x7f8836024098) at migration/ram.c:2219
9 0x00007f88357a419d in qemu_savevm_state_setup (f=0x7f88384ce600) at migration/savevm.c:1002
10 0x00007f883579fc3e in migration_thread (opaque=0x7f8837530400) at migration/migration.c:2382
11 0x00007f8832447893 in start_thread () from /lib64/libpthread.so.0
12 0x00007f8832178bfd in clone () from /lib64/libc.so.6
This is because vhost_get_log_size() returns a overflowed vhost-log size.
In this function, it uses the uninitialized variable vqs->used_phys and
vqs->used_size to get the vhost-log size.
Signed-off-by: Li Hangjing <lihangjing@baidu.com>
Reviewed-by: Xie Yongji <xieyongji@baidu.com>
Reviewed-by: Chai Wen <chaiwen@baidu.com>
Message-Id: <20190603061524.24076-1-lihangjing@baidu.com>
Cc: qemu-stable@nongnu.org
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20190605131221.29432-1-marcandre.lureau@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
This should fix uninitialized fields found by coverity CID 1401762.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20190605145829.7674-6-marcandre.lureau@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
This should fix coverity CID 1401704.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20190605145829.7674-5-marcandre.lureau@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
g_printerr() needs a trailing \n
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20190605145829.7674-4-marcandre.lureau@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
This check shouldn't be necessary, since &error_fatal is given as
argument and will exit() on failure. However, this change should
silence coverity CID 1401761 & 1401705.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20190605145829.7674-3-marcandre.lureau@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Should fix coverity CID 1401760.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20190605145829.7674-2-marcandre.lureau@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Refresh the "pc-bios/README" file with edk2, OpenSSL, and Berkeley
SoftFloat release info, matching the edk2-stable201905 firmware images
added in the previous patch.
Cc: Philippe Mathieu-Daud <philmd@redhat.com>
Ref: https://bugs.launchpad.net/qemu/+bug/1831477
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daud <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daud <philmd@redhat.com>
Rebuild the pc-bios/edk2-*.fd.bz2 binaries, and regenerate
pc-bios/edk2-licenses.txt, based on the edk2-stable201905 release.
Cc: Philippe Mathieu-Daud <philmd@redhat.com>
Ref: https://bugs.launchpad.net/qemu/+bug/1831477
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daud <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daud <philmd@redhat.com>
(1) For TianoCore Bugzilla
https://bugzilla.tianocore.org/show_bug.cgi?id=1373
the majority of the edk2 tree was relicensed under the
BSD-2-Clause-Patent license:
https://spdx.org/licenses/BSD-2-Clause-Patent.html>
Edk2 commit f53de8aecb12 ("edk2: Add License-History.txt", 2019-04-09)
added a new file called "License-History.txt", describing license and
contributor agreement changes over time.
(2) For advacing edk2's OpenSSL git submodule to the 1.1.1b release, a
more up-to-date ArmSoftFloatLib instance became necessary, on 32-bit
ARM. Therefore, the embedded (and by now, obsolete) Berkeley SoftFloat
library was replaced with a git submodule of the same, checked out at
the latest release ("3e", plus a typo fix on top -- commit
b64af41c3276). This was implemented for TianoCore Bugzilla
https://bugzilla.tianocore.org/show_bug.cgi?id=1845
in edk2 commit range b6cfa686e42d..371e7001e8d5.
Include the edk2 project's "License-History.txt" file, and the Berkeley
SoftFloat library's "COPYING.txt", in our generated
"pc-bios/edk2-licenses.txt" text file.
Cc: Philippe Mathieu-Daud <philmd@redhat.com>
Ref: https://bugs.launchpad.net/qemu/+bug/1831477
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daud <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daud <philmd@redhat.com>
At tag "edk2-stable201905", the build flags HTTP_BOOT_ENABLE and
TLS_ENABLE have become useless. Their roles have been taken by
NETWORK_HTTP_BOOT_ENABLE and NETWORK_TLS_ENABLE, respectively. Remove the
old build flags.
Cc: Philippe Mathieu-Daud <philmd@redhat.com>
Ref: https://bugs.launchpad.net/qemu/+bug/1831477
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daud <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daud <philmd@redhat.com>
Due to edk2 commits 631195044ff0 ("OvmfPkg: Update DSC/FDF to use
NetworkPkg's include fragment file.", 2019-05-16) and 157a3b1aa50f
("ArmVirtPkg: Update DSC/FDF to use NetworkPkg's include fragment file.",
2019-05-16), we'll have to pefix the HTTP_BOOT_ENABLE and TLS_ENABLE build
flags with "NETWORK_", for building edk2 at tag "edk2-stable201905".
Right now the new flags are no-ops, so we can insert them separately,
before advancing our edk2 submodule reference. We will remove the old
flags afterwards.
Cc: Philippe Mathieu-Daud <philmd@redhat.com>
Ref: https://bugs.launchpad.net/qemu/+bug/1831477
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daud <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daud <philmd@redhat.com>
- Allow blockdev-backup from nodes that are not in qemu's main AIO
context to newly added nodes
- Add salvaging mode to qemu-img convert
- Minor fixes to tests, documentation, and for less Valgrind annoyance
-----BEGIN PGP SIGNATURE-----
iQFGBAABCAAwFiEEkb62CjDbPohX0Rgp9AfbAGHVz0AFAl0Do0MSHG1yZWl0ekBy
ZWRoYXQuY29tAAoJEPQH2wBh1c9AYfAH/3Z4Ua5Pwown99TH57jdfHBzdWnhwQV6
fEJs1viFOufb9RS/3UB3JlPZ71Jf+4y97g9NrRY05BQ3ZJPwlm9moSdM7GPQ6Ni3
OVqHP6shnOHlBHI897JRDPjpLGEujIVk59EE9wB7e/T8rpGo21yJ91u5Ha4T9M2/
jsHwL/1NPCe8OxdCMSNJmIPA2PqouBjvEGdbCwa6sOVNe+pFJnhStEZOjnP+rmmb
wt5vk+NR40rdsuAoUZ7mTr0GhUDtJAL9vkJgW1uH7b9mzAsxklsWpct6oxDwEYJL
BURVLsT2g8QQwX7pebaOkys0ktPGkegtv785yh8KhPf2Yf6S8L1vS4M=
=o8kg
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/maxreitz/tags/pull-block-2019-06-14' into staging
Block patches:
- Allow blockdev-backup from nodes that are not in qemu's main AIO
context to newly added nodes
- Add salvaging mode to qemu-img convert
- Minor fixes to tests, documentation, and for less Valgrind annoyance
# gpg: Signature made Fri 14 Jun 2019 14:38:11 BST
# gpg: using RSA key 91BEB60A30DB3E8857D11829F407DB0061D5CF40
# gpg: issuer "mreitz@redhat.com"
# gpg: Good signature from "Max Reitz <mreitz@redhat.com>" [full]
# Primary key fingerprint: 91BE B60A 30DB 3E88 57D1 1829 F407 DB00 61D5 CF40
* remotes/maxreitz/tags/pull-block-2019-06-14:
iotests: Test qemu-img convert -C --salvage
iotests: Test qemu-img convert --salvage
blkdebug: Inject errors on .bdrv_co_block_status()
blkdebug: Add "none" event
blkdebug: Add @iotype error option
qemu-img: Add salvaging mode to convert
qemu-img: Move quiet into ImgConvertState
blockdev: Overlays are not snapshots
qapi/block-core: Overlays are not snapshots
qemu-img: Fix options leakage in img_rebase()
iotests: restrict 254 to support only qcow2
hw/block/fdc: floppy command FIFO memory initialization
iotests: Fix intermittent failure in 219
iotests: Filter 175's allocation information
event_match: always match on None value
iotests: add iotest 256 for testing blockdev-backup across iothread contexts
iotests.py: rewrite run_job to be pickier
QEMUMachine: add events_wait method
iotests.py: do not use infinite waits
blockdev-backup: don't check aio_context too early
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
We do not support this combination (yet), so this should yield an error
message.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Tested-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20190507203508.18026-8-mreitz@redhat.com
Signed-off-by: Max Reitz <mreitz@redhat.com>
This test converts a simple image to another, but blkdebug injects
block_status and read faults at some offsets. The resulting image
should be the same as the input image, except that sectors that could
not be read have to be 0.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20190507203508.18026-7-mreitz@redhat.com
Tested-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
[mreitz: Dropped superfluous printf from _filter_offsets, as suggested
by Vladimir; disable test for VDI and IMGOPTSSYNTAX]
Signed-off-by: Max Reitz <mreitz@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20190507203508.18026-6-mreitz@redhat.com
Signed-off-by: Max Reitz <mreitz@redhat.com>
Together with @iotypes and @sector, this can be used to trap e.g. the
first read or write access to a certain sector without having to know
what happens internally in the block layer, i.e. which "real" events
happen right before such an access.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20190507203508.18026-5-mreitz@redhat.com
Signed-off-by: Max Reitz <mreitz@redhat.com>
This new error option allows users of blkdebug to inject errors only on
certain kinds of I/O operations. Users usually want to make a very
specific operation fail, not just any; but right now they simply hope
that the event that triggers the error injection is followed up with
that very operation. That may not be true, however, because the block
layer is changing (including blkdebug, which may increase the number of
types of I/O operations on which to inject errors).
The new option's default has been chosen to keep backwards
compatibility.
Note that similar to the internal representation, we could choose to
expose this option as a list of I/O types. But there is no practical
use for this, because as described above, users usually know exactly
which kind of operation they want to make fail, so there is no need to
specify multiple I/O types at once. In addition, exposing this option
as a list would require non-trivial changes to qemu_opts_absorb_qdict().
Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20190507203508.18026-4-mreitz@redhat.com
Signed-off-by: Max Reitz <mreitz@redhat.com>
This adds a salvaging mode (--salvage) to qemu-img convert which ignores
read errors and treats the respective areas as containing only zeroes.
This can be used for instance to at least partially recover the data
from terminally corrupted qcow2 images.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20190507203508.18026-3-mreitz@redhat.com
Signed-off-by: Max Reitz <mreitz@redhat.com>
Move img_convert()'s quiet flag into the ImgConvertState so it is
accessible by nested functions. -q dictates that it suppresses anything
but errors, so if those functions want to emit warnings, they need to
query this flag first. (There currently are no such warnings, but there
will be as of the next patch.)
Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20190507203508.18026-2-mreitz@redhat.com
Signed-off-by: Max Reitz <mreitz@redhat.com>
There are error messages which refer to an overlay node as the snapshot.
That is wrong, those are two different things.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20190603202236.1342-3-mreitz@redhat.com
Reviewed-by: John Snow <jsnow@redhat.com>
Reviewed-by: Alberto Garcia <berto@igalia.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
A snapshot is something that reflects the state of something at a
certain point in time. It does not change.
The file our snapshot commands create (or the node they install) is not
a snapshot, as it does change over time. It is an overlay. We cannot
do anything about the parameter names, but we can at least adjust the
descriptions to reflect that fact.
Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Message-id: 20190603202236.1342-2-mreitz@redhat.com
Reviewed-by: John Snow <jsnow@redhat.com>
Reviewed-by: Alberto Garcia <berto@igalia.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
img_rebase() can leak a QDict in two occasions. Fix it.
Coverity: CID 1401416
Fixes: d16699b646
Fixes: 330c729571
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20190528195338.12376-1-mreitz@redhat.com
Reviewed-by: John Snow <jsnow@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
Test fails at least for qcow, because of different cluster sizes in
base and top (and therefore different granularities of bitmaps we are
trying to merge).
The test aim is to check block-dirty-bitmap-merge between different
nodes functionality, no needs to check all formats. So, let's just drop
support for anything except qcow2.
Reported-by: Max Reitz <mreitz@redhat.com>
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-id: 20190605155405.104384-1-vsementsov@virtuozzo.com
Signed-off-by: Max Reitz <mreitz@redhat.com>
The uninitialized memory allocated for the command FIFO of the
floppy controller during the VM hardware initialization incurs
many unwanted reports by Valgrind when VM state is being saved.
That verbosity hardens a search for the real memory issues when
the iotests run. Particularly, the patch eliminates 20 unnecessary
reports of the Valgrind tool in the iotest #169.
Signed-off-by: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com>
Message-id: 1559154027-282547-1-git-send-email-andrey.shinkevich@virtuozzo.com
Reviewed-by: John Snow <jsnow@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
In 219, we wait for the job to make progress before we emit its status.
This makes the output reliable. We do not wait for any more progress if
the job's current-progress already matches its total-progress.
Unfortunately, there is a bug: Right after the job has been started,
it's possible that total-progress is still 0. In that case, we may skip
the first progress-making step and keep ending up 64 kB short.
To fix that bug, we can simply wait for total-progress to reach 4 MB
(the image size) after starting the job.
Reported-by: Karen Mezick <kmezick@redhat.com>
Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1686651
Signed-off-by: Max Reitz <mreitz@redhat.com>
Message-id: 20190516161114.27596-1-mreitz@redhat.com
Reviewed-by: John Snow <jsnow@redhat.com>
[mreitz: Adjusted commit message as per John's proposal]
Signed-off-by: Max Reitz <mreitz@redhat.com>
It is possible for an empty file to take up blocks on a filesystem, for
example:
$ qemu-img create -f raw test.img 1G
Formatting 'test.img', fmt=raw size=1073741824
$ mkfs.ext4 -I 128 -q test.img
$ mkdir test-mount
$ sudo mount -o loop test.img test-mount
$ sudo touch test-mount/test-file
$ stat -c 'blocks=%b' test-mount/test-file
blocks=8
These extra blocks (one cluster) are apparently used for metadata,
because they are always there, on top of blocks used for data:
$ sudo dd if=/dev/zero of=test-mount/test-file bs=1M count=1
1+0 records in
1+0 records out
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.00135339 s, 775 MB/s
$ stat -c 'blocks=%b' test-mount/test-file
blocks=2056
Make iotest 175 take this into account.
Reported-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Nir Soffer <nsoffer@redhat.com>
Message-id: 20190516144319.12570-1-mreitz@redhat.com
Signed-off-by: Max Reitz <mreitz@redhat.com>
Before, event_match didn't always recurse if the event value was not a
dictionary, and would instead check for equality immediately.
By delaying equality checking to post-recursion, we can allow leaf
values like "5" to match "None" and take advantage of the generic
None-returns-True clause.
This makes the matching a little more obviously consistent at the
expense of being able to check for explicit None values, which is
probably not that important given what this function is used for.
Signed-off-by: John Snow <jsnow@redhat.com>
Message-id: 20190528183857.26167-1-jsnow@redhat.com
Signed-off-by: Max Reitz <mreitz@redhat.com>
Signed-off-by: John Snow <jsnow@redhat.com>
Message-id: 20190523170643.20794-6-jsnow@redhat.com
Reviewed-by: Max Reitz <mreitz@redhat.com>
[mreitz: Moved from 250 to 256]
Signed-off-by: Max Reitz <mreitz@redhat.com>
Don't pull events out of the queue that don't belong to us;
be choosier so that we can use this method to drive jobs that
were launched by transactions that may have more jobs.
Signed-off-by: John Snow <jsnow@redhat.com>
Message-id: 20190523170643.20794-5-jsnow@redhat.com
Reviewed-by: Max Reitz <mreitz@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
Instead of event_wait which looks for a single event, add an events_wait
which can look for any number of events simultaneously. However, it
will still only return one at a time, whichever happens first.
Signed-off-by: John Snow <jsnow@redhat.com>
Message-id: 20190523170643.20794-4-jsnow@redhat.com
Reviewed-by: Max Reitz <mreitz@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
Cap waits to 60 seconds so that iotests can fail gracefully if something
goes wrong.
Signed-off-by: John Snow <jsnow@redhat.com>
Message-id: 20190523170643.20794-3-jsnow@redhat.com
Reviewed-by: Max Reitz <mreitz@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
in blockdev_backup_prepare, we check to make sure that the target is
associated with a compatible aio context. However, do_blockdev_backup is
called later and has some logic to move the target to a compatible
aio_context. The transaction version will fail certain commands
needlessly early as a result.
Allow blockdev_backup_prepare to simply call do_blockdev_backup, which
will ultimately decide if the contexts are compatible or not.
Note: the transaction version has always disallowed this operation since
its initial commit bd8baecd (2014), whereas the version of
qmp_blockdev_backup at the time, from commit c29c1dd312, tried to
enforce the aio_context switch instead. It's not clear, and I can't see
from the mailing list archives at the time, why the two functions take a
different approach. It wasn't until later in efd7556708 (2016) that the
standalone version tried to determine if it could set the context or
not.
Reported-by: aihua liang <aliang@redhat.com>
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1683498
Signed-off-by: John Snow <jsnow@redhat.com>
Message-id: 20190523170643.20794-2-jsnow@redhat.com
Reviewed-by: Max Reitz <mreitz@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
The code used to assign an interrupt index/subindex to an
eventfd is duplicated many times. Let's introduce an helper that
allows to set/unset the signaling for an ACTION_TRIGGER,
ACTION_MASK or ACTION_UNMASK action.
In the error message, we now use errno in case of any
VFIO_DEVICE_SET_IRQS ioctl failure.
Signed-off-by: Eric Auger <eric.auger@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Li Qiang <liq3ea@gmail.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
The MSI-X relocation code can sometimes be used to work around bogus
MSI-X capabilities, but this test for whether the PBA is outside of
the specified BAR causes the device to error before we can apply a
relocation. Let it proceed if we intend to relocate MSI-X anyway.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
The resizable BAR capability is currently exposed read-only from the
kernel and we don't yet implement a protocol for virtualizing it to
the VM. Exposing it to the guest read-only introduces poor behavior
as the guest has no reason to test that a control register write is
accepted by the hardware. This can lead to cases where the guest OS
assumes the BAR has been resized, but it hasn't. This has been
observed when assigning AMD Vega GPUs.
Note, this does not preclude future enablement of resizable BARs, but
it's currently incorrect to expose this capability as read-only, so
better to not expose it at all.
Reported-by: James Courtier-Dutton <james.dutton@gmail.com>
Tested-by: James Courtier-Dutton <james.dutton@gmail.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
No reason to keep it separate, it differs from others block driver
behavior and therefore confuses. Instead of generic
'state = (State*)bs->opaque' we have to use special helper.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20190611102720.86114-4-vsementsov@virtuozzo.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
No reason for keeping driver handlers realization separate from driver
structure. We can get rid of extra header file.
While being here, fix comments style, restore forgotten comments for
NBD_FOREACH_REPLY_CHUNK and nbd_reply_chunk_iter_receive, remove extra
includes.
Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Message-Id: <20190611102720.86114-3-vsementsov@virtuozzo.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
