aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-07-06pc_basic_device_init: drop has_pit argGerd Hoffmann
Now that we pass pcms anyway, we don't need the has_pit arg any more. No functional change. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20200702132525.6849-13-kraxel@redhat.com
2020-07-06pc_basic_device_init: pass PCMachineStateGerd Hoffmann
Need access to pcms for pcspk initialization. Just preparation, no functional change. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20200702132525.6849-12-kraxel@redhat.com
2020-07-06audio: deprecate -soundhw hdaGerd Hoffmann
Add deprecation message to the audio init function. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20200702132525.6849-11-kraxel@redhat.com
2020-07-06audio: deprecate -soundhw sb16Gerd Hoffmann
Switch to deprecated_register_soundhw(). Remove the now obsolete init function. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20200702132525.6849-10-kraxel@redhat.com
2020-07-06audio: deprecate -soundhw gusGerd Hoffmann
Switch to deprecated_register_soundhw(). Remove the now obsolete init function. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20200702132525.6849-9-kraxel@redhat.com
2020-07-06audio: deprecate -soundhw cs4231aGerd Hoffmann
Switch to deprecated_register_soundhw(). Remove the now obsolete init function. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20200702132525.6849-8-kraxel@redhat.com
2020-07-06audio: deprecate -soundhw adlibGerd Hoffmann
Switch to deprecated_register_soundhw(). Remove the now obsolete init function. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20200702132525.6849-7-kraxel@redhat.com
2020-07-06audio: deprecate -soundhw es1370Gerd Hoffmann
Switch to deprecated_register_soundhw(). Remove the now obsolete init function. Add an alias so both es1370 and ES1370 are working with -device. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20200702132525.6849-6-kraxel@redhat.com
2020-07-06audio: deprecate -soundhw ac97Gerd Hoffmann
Switch to deprecated_register_soundhw(). Remove the now obsolete init function. Add an alias so both ac97 and AC97 are working with -device. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20200702132525.6849-5-kraxel@redhat.com
2020-07-06audio: add deprecated_register_soundhwGerd Hoffmann
Add helper function for -soundhw deprecation. It can replace the simple init functions which just call {isa,pci}_create_simple() with a hardcoded type. It also prints a deprecation message. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20200702132525.6849-4-kraxel@redhat.com
2020-07-06stubs: add pci_create_simpleGerd Hoffmann
Needed for -soundhw cleanup. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200702132525.6849-3-kraxel@redhat.com
2020-07-06stubs: add isa_create_simpleGerd Hoffmann
Needed for -soundhw cleanup. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200702132525.6849-2-kraxel@redhat.com
2020-07-06Merge remote-tracking branch ↵Peter Maydell
'remotes/vivier2/tags/linux-user-for-5.1-pull-request' into staging linux-user pull request 2020-07-02 Update linux-user maintainer Improve strace output for some syscalls Display contents of ioctl() parameters Fix sparc64 flushw operation # gpg: Signature made Sat 04 Jul 2020 17:25:21 BST # gpg: using RSA key CD2F75DDC8E3A4DC2E4F5173F30C38BD3F2FBE3C # gpg: issuer "laurent@vivier.eu" # gpg: Good signature from "Laurent Vivier <lvivier@redhat.com>" [full] # gpg: aka "Laurent Vivier <laurent@vivier.eu>" [full] # gpg: aka "Laurent Vivier (Red Hat) <lvivier@redhat.com>" [full] # Primary key fingerprint: CD2F 75DD C8E3 A4DC 2E4F 5173 F30C 38BD 3F2F BE3C * remotes/vivier2/tags/linux-user-for-5.1-pull-request: MAINTAINERS: update linux-user maintainer linux-user: Add strace support for printing arguments of ioctl() linux-user: Add thunk argument types for SIOCGSTAMP and SIOCGSTAMPNS linux-user: Add strace support for printing arguments of fallocate() linux-user: Add strace support for printing arguments of chown()/lchown() linux-user: Add strace support for printing arguments of lseek() linux-user: Add strace support for printing argument of syscalls used for extended attributes linux-user: Add strace support for a group of syscalls linux-user: Extend strace support to enable argument printing after syscall execution linux-user: syscall: ioctls: support DRM_IOCTL_VERSION linux-user/sparc64: Fix the handling of window spill trap target/sparc: Translate flushw opcode Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-07-06qed: Simplify backing readsEric Blake
The other four drivers that support backing files (qcow, qcow2, parallels, vmdk) all rely on the block layer to populate zeroes when reading beyond EOF of a short backing file. We can simplify the qed code by doing likewise. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20200528094405.145708-11-vsementsov@virtuozzo.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-07-06block: drop unallocated_blocks_are_zeroVladimir Sementsov-Ogievskiy
Currently this field only set by qed and qcow2. But in fact, all backing-supporting formats (parallels, qcow, qcow2, qed, vmdk) share these semantics: on unallocated blocks, if there is no backing file they just memset the buffer with zeroes. So, document this behavior for .supports_backing and drop .unallocated_blocks_are_zero Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20200528094405.145708-10-vsementsov@virtuozzo.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-07-06block/vhdx: drop unallocated_blocks_are_zeroVladimir Sementsov-Ogievskiy
vhdx doesn't have .bdrv_co_block_status handler, so DATA|ALLOCATED is always assumed for it in bdrv_co_block_status(). unallocated_blocks_are_zero is useless (it doesn't affect the only user of the field: bdrv_co_block_status()), drop it. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20200528094405.145708-9-vsementsov@virtuozzo.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-07-06block/file-posix: drop unallocated_blocks_are_zeroVladimir Sementsov-Ogievskiy
raw_co_block_status() in block/file-posix.c never returns 0, so unallocated_blocks_are_zero is useless (it doesn't affect the only user of the field: bdrv_co_block_status()). Drop it. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20200528094405.145708-8-vsementsov@virtuozzo.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-07-06block/iscsi: drop unallocated_blocks_are_zeroVladimir Sementsov-Ogievskiy
We set bdi->unallocated_blocks_are_zero = iscsilun->lbprz, but iscsi_co_block_status doesn't return 0 in case of iscsilun->lbprz, it returns ZERO when appropriate. So actually unallocated_blocks_are_zero is useless (it doesn't affect the only user of the field: bdrv_co_block_status()). Drop it now. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20200528094405.145708-7-vsementsov@virtuozzo.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-07-06block/crypto: drop unallocated_blocks_are_zeroVladimir Sementsov-Ogievskiy
It's false by default, no needs to set it. We are going to drop this variable at all, so drop it now here, it doesn't hurt. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20200528094405.145708-6-vsementsov@virtuozzo.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-07-06block/vpc: return ZERO block-status when appropriateVladimir Sementsov-Ogievskiy
In case when get_image_offset() returns -1, we do zero out the corresponding chunk of qiov. So, this should be reported as ZERO. Note that this changes visible output of "qemu-img map --output=json" and "qemu-io -c map" commands. For qemu-img map, the change is obvious: we just mark as zero what is really zero. For qemu-io it's less obvious: what was unallocated now is allocated. There is an inconsistency in understanding of unallocated regions in Qemu: backing-supporting format-drivers return 0 block-status to report go-to-backing logic for this area. Some protocol-drivers (iscsi) return 0 to report fs-unallocated-non-zero status (i.e., don't occupy space on disk, read result is undefined). BDRV_BLOCK_ALLOCATED is defined as something more close to go-to-backing logic. Still it is calculated as ZERO | DATA, so 0 from iscsi is treated as unallocated. It doesn't influence backing-chain behavior, as iscsi can't have backing file. But it does influence "qemu-io -c map". We should solve this inconsistency at some future point. Now, let's just make backing-not-supporting format drivers (vdi in the previous patch and vpc now) to behave more like backing-supporting drivers and not report 0 block-status. More over, returning ZERO status is absolutely valid thing, and again, corresponds to how the other format-drivers (backing-supporting) work. After block-status update, it never reports 0, so setting unallocated_blocks_are_zero doesn't make sense (as the only user of it is bdrv_co_block_status and it checks unallocated_blocks_are_zero only for unallocated areas). Drop it. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20200528094405.145708-5-vsementsov@virtuozzo.com> [mreitz: qemu-io -c map as used by iotest 146 now reports everything as allocated; in order to make the test do something useful, we use qemu-img map --output=json now] Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-07-06tests/acceptance: Add a test for the sun4u sparc64 machineThomas Huth
We can use the image from the advent calendar 2018 to test the sun4u machine. It's not using the "QEMU advent calendar" string, so we can not use the do_test_advcal_2018() from boot_linux_console.py, thus let's also put it into a separate file to also be able to add an entry to the MAINTAINERS file. Message-Id: <20200704173519.26087-1-thuth@redhat.com> Tested-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-07-06hw/m68k/mcf5206: Replace remaining hw_error()s by qemu_log_mask()Thomas Huth
hw_error() dumps the CPU state and exits QEMU. This is ok during initial code development (to see where the guest code is currently executing), but it is certainly not the desired behavior that we want to present to normal users, and it can also cause trouble when e.g. fuzzing devices. Thus let's replace these hw_error()s by qemu_log_mask()s instead. Message-Id: <20200611055807.15921-1-huth@tuxfamily.org> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
2020-07-06block/vdi: return ZERO block-status when appropriateVladimir Sementsov-Ogievskiy
In case of !VDI_IS_ALLOCATED[], we do zero out the corresponding chunk of qiov. So, this should be reported as ZERO. Note that this changes visible output of "qemu-img map --output=json" and "qemu-io -c map" commands. For qemu-img map, the change is obvious: we just mark as zero what is really zero. For qemu-io it's less obvious: what was unallocated now is allocated. There is an inconsistency in understanding of unallocated regions in Qemu: backing-supporting format-drivers return 0 block-status to report go-to-backing logic for this area. Some protocol-drivers (iscsi) return 0 to report fs-unallocated-non-zero status (i.e., don't occupy space on disk, read result is undefined). BDRV_BLOCK_ALLOCATED is defined as something more close to go-to-backing logic. Still it is calculated as ZERO | DATA, so 0 from iscsi is treated as unallocated. It doesn't influence backing-chain behavior, as iscsi can't have backing file. But it does influence "qemu-io -c map". We should solve this inconsistency at some future point. Now, let's just make backing-not-supporting format drivers (vdi at this patch and vpc with the following) to behave more like backing-supporting drivers and not report 0 block-status. More over, returning ZERO status is absolutely valid thing, and again, corresponds to how the other format-drivers (backing-supporting) work. After block-status update, it never reports 0, so setting unallocated_blocks_are_zero doesn't make sense (as the only user of it is bdrv_co_block_status and it checks unallocated_blocks_are_zero only for unallocated areas). Drop it. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20200528094405.145708-4-vsementsov@virtuozzo.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-07-06block: inline bdrv_unallocated_blocks_are_zero()Vladimir Sementsov-Ogievskiy
The function has only one user: bdrv_co_block_status(). Inline it to simplify reviewing of the following patches, which will finally drop unallocated_blocks_are_zero field too. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20200528094405.145708-3-vsementsov@virtuozzo.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-07-06qemu-img: convert: don't use unallocated_blocks_are_zeroVladimir Sementsov-Ogievskiy
qemu-img convert wants to distinguish ZERO which comes from short backing files. unallocated_blocks_are_zero field of bdi is unrelated: space after EOF is always considered to be zero anyway. So, just make post_backing_zero true in case of short backing file. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20200528094405.145708-2-vsementsov@virtuozzo.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-07-06iotests: add tests for blockdev-amendMaxim Levitsky
This commit adds two tests that cover the new blockdev-amend functionality of luks and qcow2 driver Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> [mreitz: Let 295 verify that LUKS works; drop 295 and 296 from the auto group] Signed-off-by: Max Reitz <mreitz@redhat.com> Message-Id: <20200625125548.870061-20-mreitz@redhat.com>
2020-07-06block/qcow2: implement blockdev-amendMaxim Levitsky
Currently the implementation only supports amending the encryption options, unlike the qemu-img version Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Message-Id: <20200608094030.670121-14-mlevitsk@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-07-06block/crypto: implement blockdev-amendMaxim Levitsky
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Message-Id: <20200608094030.670121-13-mlevitsk@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-07-06block/core: add generic infrastructure for x-blockdev-amend qmp commandMaxim Levitsky
blockdev-amend will be used similiar to blockdev-create to allow on the fly changes of the structure of the format based block devices. Current plan is to first support encryption keyslot management for luks based formats (raw and embedded in qcow2) Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20200608094030.670121-12-mlevitsk@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-07-06iotests: qemu-img tests for luks key managementMaxim Levitsky
This commit adds two tests, which test the new amend interface of both luks raw images and qcow2 luks encrypted images. Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> [mreitz: Let 293 verify that LUKS works; drop $(seq) usage from 293; drop 293 and 294 from the auto group] Signed-off-by: Max Reitz <mreitz@redhat.com> Message-Id: <20200625125548.870061-16-mreitz@redhat.com>
2020-07-06block/qcow2: extend qemu-img amend interface with crypto optionsMaxim Levitsky
Now that we have all the infrastructure in place, wire it in the qcow2 driver and expose this to the user. Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Message-Id: <20200608094030.670121-9-mlevitsk@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-07-06block/crypto: implement the encryption key managementMaxim Levitsky
This implements the encryption key management using the generic code in qcrypto layer and exposes it to the user via qemu-img This code adds another 'write_func' because the initialization write_func works directly on the underlying file, and amend works on instance of luks device. This commit also adds a 'hack/workaround' I and Kevin Wolf (thanks) made to make the driver both support write sharing (to avoid breaking the users), and be safe against concurrent metadata update (the keyslots) Eventually the write sharing for luks driver will be deprecated and removed together with this hack. The hack is that we ask (as a format driver) for BLK_PERM_CONSISTENT_READ and then when we want to update the keys, we unshare that permission. So if someone else has the image open, even readonly, encryption key update will fail gracefully. Also thanks to Daniel Berrange for the idea of unsharing read, rather that write permission which allows to avoid cases when the other user had opened the image read-only. Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Message-Id: <20200608094030.670121-8-mlevitsk@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-07-06block/crypto: rename two functionsMaxim Levitsky
rename the write_func to create_write_func, and init_func to create_init_func. This is preparation for other write_func that will be used to update the encryption keys. No functional changes Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20200608094030.670121-7-mlevitsk@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-07-06block/amend: refactor qcow2 amend optionsMaxim Levitsky
Some qcow2 create options can't be used for amend. Remove them from the qcow2 create options and add generic logic to detect such options in qemu-img Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> [mreitz: Dropped some iotests reference output hunks that became unnecessary thanks to "iotests: Make _filter_img_create more active"] Signed-off-by: Max Reitz <mreitz@redhat.com> Message-Id: <20200625125548.870061-12-mreitz@redhat.com>
2020-07-06block/amend: separate amend and create options for qemu-imgMaxim Levitsky
Some options are only useful for creation (or hard to be amended, like cluster size for qcow2), while some other options are only useful for amend, like upcoming keyslot management options for luks Since currently only qcow2 supports amend, move all its options to a common macro and then include it in each action option list. In future it might be useful to remove some options which are not supported anyway from amend list, which currently cause an error message if amended. Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Message-Id: <20200608094030.670121-5-mlevitsk@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-07-06block/amend: add 'force' optionMaxim Levitsky
'force' option will be used for some unsafe amend operations. This includes things like erasing last keyslot in luks based formats (which destroys the data, unless the master key is backed up by external means), but that _might_ be desired result. Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Message-Id: <20200608094030.670121-4-mlevitsk@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-07-06qcrypto/luks: implement encryption key managementMaxim Levitsky
Next few patches will expose that functionality to the user. Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20200608094030.670121-3-mlevitsk@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-07-06qcrypto/core: add generic infrastructure for crypto options amendmentMaxim Levitsky
This will be used first to implement luks keyslot management. block_crypto_amend_opts_init will be used to convert qemu-img cmdline to QCryptoBlockAmendOptions Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20200608094030.670121-2-mlevitsk@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-07-06iotests: Check whether luks worksMax Reitz
Whenever running an iotest for the luks format, we should check whether luks actually really works. Tests that try to create luks-encrypted qcow2 images should do the same. Signed-off-by: Max Reitz <mreitz@redhat.com> Message-Id: <20200625125548.870061-7-mreitz@redhat.com> Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
2020-07-06iotests.py: Add (verify|has)_working_luks()Max Reitz
Similar to _require_working_luks for bash tests, these functions can be used to check whether our luks driver can actually create images. Signed-off-by: Max Reitz <mreitz@redhat.com> Message-Id: <20200625125548.870061-6-mreitz@redhat.com> Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
2020-07-06iotests.py: Add qemu_img_pipe_and_status()Max Reitz
This function will be used by the next patch, which intends to check both the exit code and qemu-img's output. Signed-off-by: Max Reitz <mreitz@redhat.com> Message-Id: <20200625125548.870061-5-mreitz@redhat.com> Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com> [mreitz: Rebased on 49438972b8c2e] Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-07-06iotests/common.rc: Add _require_working_luksMax Reitz
That the luks driver is present is little indication on whether it is actually working. Without the crypto libraries linked in, it does not work. So add this function, which tries to create a luks image to see whether that actually works. Signed-off-by: Max Reitz <mreitz@redhat.com> Message-Id: <20200625125548.870061-4-mreitz@redhat.com> Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
2020-07-06iotests: filter few more luks specific create optionsMaxim Levitsky
This allows more tests to be able to have same output on both qcow2 luks encrypted images and raw luks images Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com> Message-Id: <20200625125548.870061-3-mreitz@redhat.com>
2020-07-06iotests: Make _filter_img_create more activeMax Reitz
Right now, _filter_img_create just filters out everything that looks format-dependent, and applies some filename filters. That means that we have to add another filter line every time some format gets a new creation option. This can be avoided by instead discarding everything and just keeping what we know is format-independent (format, size, backing file, encryption information[1], preallocation) or just interesting to have in the reference output (external data file path). Furthermore, we probably want to sort these options. Format drivers are not required to define them in any specific order, so the output is effectively random (although this has never bothered us until now). We need a specific order for our reference outputs, though. Unfortunately, just using a plain "sort" would change a lot of existing reference outputs, so we have to pre-filter the option keys to keep our existing order (fmt, size, backing*, data, encryption info, preallocation). Finally, this makes it difficult for _filter_img_create to automagically work for QMP output. Thus, this patch adds a separate _filter_img_create_for_qmp function that echos every line verbatim that does not start with "Formatting", and pipes those "Formatting" lines to _filter_img_create. [1] Actually, the only thing that is really important is whether encryption is enabled or not. A patch by Maxim thus removes all other "encrypt.*" options from the output: https://lists.nongnu.org/archive/html/qemu-block/2020-06/msg00339.html But that patch needs to come later so we can get away with changing as few reference outputs in this patch here as possible. Signed-off-by: Max Reitz <mreitz@redhat.com> Message-Id: <20200625125548.870061-2-mreitz@redhat.com> Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
2020-07-06qcow2: Fix preallocation on images with unaligned sizesAlberto Garcia
When resizing an image with qcow2_co_truncate() using the falloc or full preallocation modes the code assumes that both the old and new sizes are cluster-aligned. There are two problems with this: 1) The calculation of how many clusters are involved does not always get the right result. Example: creating a 60KB image and resizing it (with preallocation=full) to 80KB won't allocate the second cluster. 2) No copy-on-write is performed, so in the previous example if there is a backing file then the first 60KB of the first cluster won't be filled with data from the backing file. This patch fixes both issues. Signed-off-by: Alberto Garcia <berto@igalia.com> Message-Id: <20200617140036.20311-1-berto@igalia.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-07-06block/block-copy: block_copy_dirty_clusters: fix failure checkVladimir Sementsov-Ogievskiy
ret may be > 0 on success path at this point. Fix assertion, which may crash currently. Fixes: 4ce5dd3e9b5ee0fac18625860eb3727399ee965e Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20200526181347.489557-1-vsementsov@virtuozzo.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-07-06configure / util: Auto-detect the availability of openpty()Thomas Huth
Recent versions of Solaris (v11.4) now feature an openpty() function, too, causing a build failure since we ship our own implementation of openpty() for Solaris in util/qemu-openpty.c so far. Since there are now both variants available in the wild, with and without this function (and illumos is said to not have this function yet), let's introduce a proper HAVE_OPENPTY define for this to fix the build failure. Message-Id: <20200702143955.678-1-thuth@redhat.com> Tested-by: Michele Denber <denber@mindspring.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-07-06tests/qtest: Unify the test for the xenfv and xenpv machinesThomas Huth
We have the same check in three places. Let's unify it in a central place instead. Message-Id: <20200622104339.21000-1-thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-07-06fuzz: do not use POSIX shm for coverage bitmapAlexander Bulekov
We used shm_open with mmap to share libfuzzer's coverage bitmap with child (runner) processes. The same functionality can be achieved with MAP_SHARED | MAP_ANONYMOUS, since we do not care about naming or permissioning the shared memory object. Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Message-Id: <20200622165040.15121-1-alxndr@bu.edu> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-07-06fuzz: fix broken qtest check at rcu_disable_atforkAlexander Bulekov
The qtest_enabled check introduced in d6919e4 always returns false, as it is called prior to configure_accelerators(). Instead of trying to skip rcu_disable_atfork in qemu_main, simply call rcu_enable_atfork in the fuzzer, after qemu_main returns. Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Message-Id: <20200618160516.2817-1-alxndr@bu.edu> Signed-off-by: Thomas Huth <thuth@redhat.com>