aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
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-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-04Merge remote-tracking branch ↵Peter Maydell
'remotes/pmaydell/tags/pull-target-arm-20200703' into staging target-arm queue: * i.MX6UL EVK board: put PHYs in the correct places * hw/arm/virt: Let the virtio-iommu bypass MSIs * target/arm: kvm: Handle DABT with no valid ISS * hw/arm/virt-acpi-build: Only expose flash on older machine types * target/arm: Fix temp double-free in sve ldr/str * hw/display/bcm2835_fb.c: Initialize all fields of struct * hw/arm/spitz: Code cleanup to fix Coverity-detected memory leak * Deprecate TileGX port # gpg: Signature made Fri 03 Jul 2020 17:53:05 BST # gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE # gpg: issuer "peter.maydell@linaro.org" # gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>" [ultimate] # gpg: aka "Peter Maydell <pmaydell@gmail.com>" [ultimate] # gpg: aka "Peter Maydell <pmaydell@chiark.greenend.org.uk>" [ultimate] # Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE * remotes/pmaydell/tags/pull-target-arm-20200703: (34 commits) Deprecate TileGX port Replace uses of FROM_SSI_SLAVE() macro with QOM casts hw/arm/spitz: Provide usual QOM macros for corgi-ssp and spitz-lcdtg hw/arm/pxa2xx_pic: Use LOG_GUEST_ERROR for bad guest register accesses hw/arm/spitz: Use LOG_GUEST_ERROR for bad guest register accesses hw/gpio/zaurus.c: Use LOG_GUEST_ERROR for bad guest register accesses hw/arm/spitz: Encapsulate misc GPIO handling in a device hw/misc/max111x: Create header file for documentation, TYPE_ macros hw/misc/max111x: Use GPIO lines rather than max111x_set_input() hw/arm/spitz: Use max111x properties to set initial values ssi: Add ssi_realize_and_unref() hw/misc/max111x: Don't use vmstate_register() hw/misc/max111x: provide QOM properties for setting initial values hw/arm/spitz: Implement inbound GPIO lines for bit5 and power signals hw/arm/spitz: Keep pointers to scp0, scp1 in SpitzMachineState hw/arm/spitz: Keep pointers to MPU and SSI devices in SpitzMachineState hw/arm/spitz: Create SpitzMachineClass abstract base class hw/arm/spitz: Detabify hw/display/bcm2835_fb.c: Initialize all fields of struct target/arm: Fix temp double-free in sve ldr/str ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-07-04Merge remote-tracking branch ↵Peter Maydell
'remotes/dgilbert/tags/pull-migration-20200703a' into staging virtiofsd+migration pull 2020-07-03 A couple of small migration fixes, and some capability rework for virtiofsd. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> # gpg: Signature made Fri 03 Jul 2020 16:26:35 BST # gpg: using RSA key 45F5C71B4A0CB7FB977A9FA90516331EBC5BFDE7 # gpg: Good signature from "Dr. David Alan Gilbert (RH2) <dgilbert@redhat.com>" [full] # Primary key fingerprint: 45F5 C71B 4A0C B7FB 977A 9FA9 0516 331E BC5B FDE7 * remotes/dgilbert/tags/pull-migration-20200703a: migration: Count new_dirty instead of real_dirty migration: postcopy take proper error return virtiofsd: Allow addition or removal of capabilities virtiofsd: Check capability calls virtiofsd: Terminate capability list Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-07-04Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20200703' into stagingPeter Maydell
s390 update: - various fixes - cleanup in the s390x-ccw bios # gpg: Signature made Fri 03 Jul 2020 11:04:08 BST # gpg: using RSA key C3D0D66DC3624FF6A8C018CEDECF6B93C6F02FAF # gpg: issuer "cohuck@redhat.com" # gpg: Good signature from "Cornelia Huck <conny@cornelia-huck.de>" [marginal] # gpg: aka "Cornelia Huck <huckc@linux.vnet.ibm.com>" [full] # gpg: aka "Cornelia Huck <cornelia.huck@de.ibm.com>" [full] # gpg: aka "Cornelia Huck <cohuck@kernel.org>" [marginal] # gpg: aka "Cornelia Huck <cohuck@redhat.com>" [marginal] # Primary key fingerprint: C3D0 D66D C362 4FF6 A8C0 18CE DECF 6B93 C6F0 2FAF * remotes/cohuck/tags/s390x-20200703: s390x/pci: fix set_ind_atomic virtio-ccw: fix virtio_set_ind_atomic target/s390x: Fix SQXBR pc-bios/s390: Update s390-ccw bios binaries with the latest changes pc-bios/s390-ccw: Generate and include dependency files in the Makefile pc-bios: s390x: Make u32 ptr check explicit pc-bios: s390x: Use ebcdic2ascii table pc-bios: s390x: Move panic() into header and add infinite loop pc-bios: s390x: Use PSW masks where possible and introduce PSW_MASK_SHORT_ADDR pc-bios: s390x: Rename PSW_MASK_ZMODE to PSW_MASK_64 pc-bios: s390x: Get rid of magic offsets into the lowcore pc-bios: s390x: Move sleep and yield to helper.h pc-bios: s390x: Consolidate timing functions into time.h pc-bios: s390x: cio.c cleanup and compile fix Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-07-03Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into stagingPeter Maydell
Block layer patches: - qemu-img convert: Don't pre-zero images (removes nowadays counterproductive optimisation) - qemu-storage-daemon: Fix object-del, cleaner shutdown - vvfat: Check that the guest doesn't escape the given host directory with read-write vvfat drives - vvfat: Fix crash by out-of-bounds array writes for read-write drives - iotests fixes # gpg: Signature made Fri 03 Jul 2020 10:20:46 BST # gpg: using RSA key DC3DEB159A9AF95D3D7456FE7F09B272C88F2FD6 # gpg: issuer "kwolf@redhat.com" # gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>" [full] # Primary key fingerprint: DC3D EB15 9A9A F95D 3D74 56FE 7F09 B272 C88F 2FD6 * remotes/kevin/tags/for-upstream: iotests: Fix 051 output after qdev_init_nofail() removal iotests.py: Do not wait() before communicate() vvfat: Fix array_remove_slice() vvfat: Check that updated filenames are valid qemu-storage-daemon: add missing cleanup calls qemu-storage-daemon: remember to add qemu_object_opts qemu-img convert: Don't pre-zero images Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-07-03Deprecate TileGX portPeter Maydell
Deprecate our TileGX target support: * we have no active maintainer for it * it has had essentially no contributions (other than tree-wide cleanups and similar) since it was first added * the Linux kernel dropped support in 2018, as has glibc Note the deprecation in the manual, but don't try to print a warning when QEMU runs -- printing unsuppressable messages is more obtrusive for linux-user mode than it would be for system-emulation mode, and it doesn't seem worth trying to invent a new suppressible-error system for linux-user just for this. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-id: 20200619154831.26319-1-peter.maydell@linaro.org
2020-07-03Replace uses of FROM_SSI_SLAVE() macro with QOM castsPeter Maydell
The FROM_SSI_SLAVE() macro predates QOM and is used as a typesafe way to cast from an SSISlave* to the instance struct of a subtype of TYPE_SSI_SLAVE. Switch to using the QOM cast macros instead, which have the same effect (by writing the QOM macros if the types were previously missing them.) (The FROM_SSI_SLAVE() macro allows the SSISlave member of the subtype's struct to be anywhere as long as it is named "ssidev", whereas a QOM cast macro insists that it is the first thing in the subtype's struct. This is true for all the types we convert here.) This removes all the uses of FROM_SSI_SLAVE() so we can delete the definition. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200628142429.17111-18-peter.maydell@linaro.org
2020-07-03hw/arm/spitz: Provide usual QOM macros for corgi-ssp and spitz-lcdtgPeter Maydell
The QOM types "spitz-lcdtg" and "corgi-ssp" are missing the usual QOM TYPE and casting macros; provide and use them. In particular, we can safely use the QOM cast macros instead of FROM_SSI_SLAVE() because in both cases the 'ssidev' field of the instance state struct is the first field in it. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200628142429.17111-17-peter.maydell@linaro.org
2020-07-03hw/arm/pxa2xx_pic: Use LOG_GUEST_ERROR for bad guest register accessesPeter Maydell
Instead of using printf() for logging guest accesses to invalid register offsets in the pxa2xx PIC device, use the usual qemu_log_mask(LOG_GUEST_ERROR,...). This was the only user of the REG_FMT macro in pxa.h, so we can remove that. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200628142429.17111-16-peter.maydell@linaro.org
2020-07-03hw/arm/spitz: Use LOG_GUEST_ERROR for bad guest register accessesPeter Maydell
Instead of logging guest accesses to invalid register offsets in the Spitz flash device with zaurus_printf() (which just prints to stderr), use the usual qemu_log_mask(LOG_GUEST_ERROR,...). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200628142429.17111-15-peter.maydell@linaro.org
2020-07-03hw/gpio/zaurus.c: Use LOG_GUEST_ERROR for bad guest register accessesPeter Maydell
Instead of logging guest accesses to invalid register offsets in this device using zaurus_printf() (which just prints to stderr), use the usual qemu_log_mask(LOG_GUEST_ERROR,...). Since this was the only use of the zaurus_printf() macro outside spitz.c, we can move the definition of that macro from sharpsl.h to spitz.c. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200628142429.17111-14-peter.maydell@linaro.org
2020-07-03hw/arm/spitz: Encapsulate misc GPIO handling in a devicePeter Maydell
Currently we have a free-floating set of IRQs and a function spitz_out_switch() which handle some miscellaneous GPIO lines for the spitz board. Encapsulate this behaviour in a simple QOM device. At this point we can finally remove the 'max1111' global, because the ADC battery-temperature value is now handled by the misc-gpio device writing the value to its outbound "adc-temp" GPIO, which the board code wires up to the appropriate inbound GPIO line on the max1111. This commit also fixes Coverity issue CID 1421913 (which pointed out that the 'outsignals' in spitz_scoop_gpio_setup() were leaked), because it removes the use of the qemu_allocate_irqs() API from this code entirely. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200628142429.17111-13-peter.maydell@linaro.org
2020-07-03hw/misc/max111x: Create header file for documentation, TYPE_ macrosPeter Maydell
Create a header file for the hw/misc/max111x device, in the usual modern style for QOM devices: * definition of the TYPE_ constants and macros * definition of the device's state struct so that it can be embedded in other structs if desired * documentation of the interface This allows us to use TYPE_MAX_1111 in the spitz.c code rather than the string "max1111". Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200628142429.17111-12-peter.maydell@linaro.org
2020-07-03hw/misc/max111x: Use GPIO lines rather than max111x_set_input()Peter Maydell
The max111x ADC device model allows other code to set the level on the 8 ADC inputs using the max111x_set_input() function. Replace this with generic qdev GPIO inputs, which also allow inputs to be set to arbitrary values. Using GPIO lines will make it easier for board code to wire things up, so that if device A wants to set the ADC input it doesn't need to have a direct pointer to the max111x but can just set that value on its output GPIO, which is then wired up by the board to the appropriate max111x input. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200628142429.17111-11-peter.maydell@linaro.org
2020-07-03hw/arm/spitz: Use max111x properties to set initial valuesPeter Maydell
Use the new max111x qdev properties to set the initial input values rather than calling max111x_set_input(); this means that on system reset the inputs will correctly return to their initial values. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200628142429.17111-10-peter.maydell@linaro.org
2020-07-03ssi: Add ssi_realize_and_unref()Peter Maydell
Add an ssi_realize_and_unref(), for the benefit of callers who want to be able to create an SSI device, set QOM properties on it, and then do the realize-and-unref afterwards. The API works on the same principle as the recently added qdev_realize_and_undef(), sysbus_realize_and_undef(), etc. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200628142429.17111-9-peter.maydell@linaro.org
2020-07-03hw/misc/max111x: Don't use vmstate_register()Peter Maydell
The max111x is a proper qdev device; we can use dc->vmsd rather than directly calling vmstate_register(). It's possible that this is a migration compat break, but the only boards that use this device are the spitz-family ('akita', 'borzoi', 'spitz', 'terrier'). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200628142429.17111-8-peter.maydell@linaro.org
2020-07-03hw/misc/max111x: provide QOM properties for setting initial valuesPeter Maydell
Add some QOM properties to the max111x ADC device to allow the initial values to be configured. Currently this is done by board code calling max111x_set_input() after it creates the device, which doesn't work on system reset. This requires us to implement a reset method for this device, so while we're doing that make sure we reset the other parts of the device state. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200628142429.17111-7-peter.maydell@linaro.org
2020-07-03hw/arm/spitz: Implement inbound GPIO lines for bit5 and power signalsPeter Maydell
Currently the Spitz board uses a nasty hack for the GPIO lines that pass "bit5" and "power" information to the LCD controller: the lcdtg realize function sets a global variable to point to the instance it just realized, and then the functions spitz_bl_power() and spitz_bl_bit5() use that to find the device they are changing the internal state of. There is a comment reading: FIXME: Implement GPIO properly and remove this hack. which was added in 2009. Implement GPIO properly and remove this hack. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200628142429.17111-6-peter.maydell@linaro.org
2020-07-03hw/arm/spitz: Keep pointers to scp0, scp1 in SpitzMachineStatePeter Maydell
Keep pointers to scp0, scp1 in SpitzMachineState, and just pass that to spitz_scoop_gpio_setup(). (We'll want to use some of the other fields in SpitzMachineState in that function in the next commit.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200628142429.17111-5-peter.maydell@linaro.org
2020-07-03hw/arm/spitz: Keep pointers to MPU and SSI devices in SpitzMachineStatePeter Maydell
Keep pointers to the MPU and the SSI devices in SpitzMachineState. We're going to want to make GPIO connections between some of the SSI devices and the SCPs, so we want to keep hold of a pointer to those; putting the MPU into the struct allows us to pass just one thing to spitz_ssp_attach() rather than two. We have to retain the setting of the global "max1111" variable for the moment as it is used in spitz_adc_temp_on(); later in this series of commits we will be able to remove it. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200628142429.17111-4-peter.maydell@linaro.org
2020-07-03hw/arm/spitz: Create SpitzMachineClass abstract base classPeter Maydell
For the four Spitz-family machines (akita, borzoi, spitz, terrier) create a proper abstract class SpitzMachineClass which encapsulates the common behaviour, rather than having them all derive directly from TYPE_MACHINE: * instead of each machine class setting mc->init to a wrapper function which calls spitz_common_init() with parameters, put that data in the SpitzMachineClass and make spitz_common_init the SpitzMachineClass machine-init function * move the settings of mc->block_default_type and mc->ignore_memory_transaction_failures into the SpitzMachineClass class init rather than repeating them in each machine's class init (The motivation is that we're going to want to keep some state in the SpitzMachineState so we can connect GPIOs between devices created in one sub-function of the machine init to devices created in a different sub-function.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200628142429.17111-3-peter.maydell@linaro.org
2020-07-03hw/arm/spitz: DetabifyPeter Maydell
The spitz board has been around a long time, and still has a fair number of hard-coded tab characters in it. We're about to do some work on this source file, so start out by expanding out the tabs. This commit is a pure whitespace only change. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200628142429.17111-2-peter.maydell@linaro.org
2020-07-03hw/display/bcm2835_fb.c: Initialize all fields of structPeter Maydell
In bcm2835_fb_mbox_push(), Coverity complains (CID 1429989) that we pass a pointer to a local struct to another function without initializing all its fields. This is a real bug: bcm2835_fb_reconfigure() copies the whole of our new BCM2385FBConfig struct into s->config, so any fields we don't initialize will corrupt the state of the device. Copy the two fields which we don't want to update (pixo and alpha) from the existing config so we don't accidentally change them. Fixes: cfb7ba983857e40e88 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200628195436.27582-1-peter.maydell@linaro.org
2020-07-03target/arm: Fix temp double-free in sve ldr/strRichard Henderson
The temp that gets assigned to clean_addr has been allocated with new_tmp_a64, which means that it will be freed at the end of the instruction. Freeing it earlier leads to assertion failure. The loop creates a complication, in which we allocate a new local temp, which does need freeing, and the final code path is shared between the loop and non-loop. Fix this complication by adding new_tmp_a64_local so that the new local temp is freed at the end, and can be treated exactly like the non-loop path. Fixes: bba87d0a0f4 Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200702175605.1987125-1-richard.henderson@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>