summary refs log tree commit diff stats
path: root/scripts/qapi/parser.py (unfollow)
Commit message (Collapse)AuthorFilesLines
2020-07-20docs/system: Briefly document gumstix boardsPeter Maydell3-0/+23
Add skeletal documentation of the gumstix boards ('connex' and 'verdex'). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20200713175746.5936-4-peter.maydell@linaro.org
2020-07-20docs/system: Briefly document collie boardPeter Maydell3-0/+18
Add skeletal documentation of the collie board. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20200713175746.5936-3-peter.maydell@linaro.org
2020-07-20docs/system: Briefly document canon-a1100 boardPeter Maydell3-0/+13
Add skeletal documentation of the canon-a1100 board. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20200713175746.5936-2-peter.maydell@linaro.org
2020-07-20hw/arm/armsse: Assert info->num_cpus is in-bounds in armsse_realize()Peter Maydell1-0/+2
In armsse_realize() we have a loop over [0, info->num_cpus), which indexes into various fixed-size arrays in the ARMSSE struct. This confuses Coverity, which warns that we might overrun those arrays (CID 1430326, 1430337, 1430371, 1430414, 1430430). This can't actually happen, because the info struct is always one of the entries in the armsse_variants[] array and num_cpus is either 1 or 2; we also already assert in armsse_init() that num_cpus is not too large. However, adding an assert to armsse_realize() like the one in armsse_init() should help Coverity figure out that these code paths aren't possible. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20200713143716.9881-1-peter.maydell@linaro.org
2020-07-20qdev: Document GPIO related functionsPeter Maydell1-2/+189
Add documentation comments for the various qdev functions related to creating and connecting GPIO lines. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200711142425.16283-4-peter.maydell@linaro.org
2020-07-20qdev: Document qdev_unrealize()Peter Maydell1-0/+19
Add a doc comment for qdev_unrealize(), to go with the new documentation for the realize part of the qdev lifecycle. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200711142425.16283-3-peter.maydell@linaro.org
2020-07-20qdev: Move doc comments from qdev.c to qdev-core.hPeter Maydell3-33/+70
The doc-comments which document the qdev API are split between the header file and the C source files, because as a project we haven't been consistent about where we put them. Move all the doc-comments in qdev.c to the header files, so that users of the APIs don't have to look at the implementation files for this information. In the process, unify them into our doc-comment format and expand on them in some cases to clarify expected use cases. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200711142425.16283-2-peter.maydell@linaro.org
2020-07-20util: Implement qemu_get_thread_id() for OpenBSDDavid CARLIER1-0/+2
Implement qemu_get_thread_id() for OpenBSD hosts, using getthrid(). Signed-off-by: David Carlier <devnexen@gmail.com> Reviewed-by: Brad Smith <brad@comstyle.com> Message-id: CA+XhMqxD6gQDBaj8tX0CMEj3si7qYKsM8u1km47e_-U7MC37Pg@mail.gmail.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [PMM: tidied up commit message] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-07-20hw/arm/virt: Disable memory hotplug when MTE is enabledRichard Henderson1-0/+5
When MTE is enabled, tag memory must exist for all RAM. It might be possible to simultaneously hot plug tag memory alongside the corresponding normal memory, but for now just disable hotplug. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200713213341.590275-4-richard.henderson@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-07-20hw/arm/virt: Error for MTE enabled with KVMRichard Henderson1-0/+6
While we expect KVM to support MTE at some future point, it certainly won't be ready in time for qemu 5.1. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200713213341.590275-3-richard.henderson@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-07-20hw/arm/virt: Enable MTE via a machine propertyRichard Henderson4-15/+49
Control this cpu feature via a machine property, much as we do with secure=on, since both require specialized support in the machine setup to be functional. Default MTE to off, since this feature implies extra overhead. Signed-off-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20200713213341.590275-2-richard.henderson@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-07-20Makefile: Remove config-devices.mak on "make clean"Peter Maydell1-0/+1
The config-devices.mak files are generated by "make", and so they should be deleted by "make clean". (This is different from config-host.mak and config-all-disas.mak, which are created by "configure" and so only deleted by "make distclean".) If we don't delete these files on "make clean", then the build tree is left in a state where it has the config-devices.mak file but not the config-devices.mak.d file, and make will not realize that it needs to rebuild config-devices.mak if, for instance, hw/sd/Kconfig changes. NB: config-all-devices.mak is also generated by "make", but we already remove it on "make clean". Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200717152508.10272-1-peter.maydell@linaro.org
2020-07-20pseries: Update SLOF firmware imageAlexey Kardashevskiy3-1/+1
This adds tcgbios (this was posted earlier [1] but got lost) and fixes FDT update at ibm,client-architecture-support for huge guests. The full list of changes: Alexey Kardashevskiy (4): make: Define default rule for .c when V=1 or V=2 version: update to 20200513 fdt: Avoid recursion when traversing tree version: update to 20200717 Gustavo Romero (1): board-qemu: Fix comment about SLOF start address Stefan Berger (6): tcgbios: Only write logs for PCRs that are allocated tcgbios: Fix the vendorInfoSize to be of type uint8_t tcgbios: Add support for SHA3 type of algorithms elf: Implement elf_get_file_size to determine size of an ELF image tcgbios: Implement tpm_hash_log_extend_event_buffer tcgbios: Measure the bootloader file read from disk [1] https://patchwork.ozlabs.org/project/qemu-devel/patch/20200513024355.121476-1-aik@ozlabs.ru/ Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-07-20spapr: Add a new level of NUMA for GPUsReza Arbab5-5/+33
NUMA nodes corresponding to GPU memory currently have the same affinity/distance as normal memory nodes. Add a third NUMA associativity reference point enabling us to give GPU nodes more distance. This is guest visible information, which shouldn't change under a running guest across migration between different qemu versions, so make the change effective only in new (pseries > 5.0) machine types. Before, `numactl -H` output in a guest with 4 GPUs (nodes 2-5): node distances: node 0 1 2 3 4 5 0: 10 40 40 40 40 40 1: 40 10 40 40 40 40 2: 40 40 10 40 40 40 3: 40 40 40 10 40 40 4: 40 40 40 40 10 40 5: 40 40 40 40 40 10 After: node distances: node 0 1 2 3 4 5 0: 10 40 80 80 80 80 1: 40 10 80 80 80 80 2: 80 80 10 80 80 80 3: 80 80 80 10 80 80 4: 80 80 80 80 10 80 5: 80 80 80 80 80 10 These are the same distances as on the host, mirroring the change made to host firmware in skiboot commit f845a648b8cb ("numa/associativity: Add a new level of NUMA for GPU's"). Signed-off-by: Reza Arbab <arbab@linux.ibm.com> Message-Id: <20200716225655.24289-1-arbab@linux.ibm.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-07-20spapr_pci: Robustify support of PCI bridgesGreg Kurz1-0/+54
Some recent error handling cleanups unveiled issues with our support of PCI bridges: 1) QEMU aborts when using non-standard PCI bridge types, unveiled by commit 7ef1553dac "spapr_pci: Drop some dead error handling" $ qemu-system-ppc64 -M pseries -device pcie-pci-bridge Unexpected error in object_property_find() at qom/object.c:1240: qemu-system-ppc64: -device pcie-pci-bridge: Property '.chassis_nr' not found Aborted (core dumped) This happens because we assume all PCI bridge types to have a "chassis_nr" property. This property only exists with the standard PCI bridge type "pci-bridge" actually. We could possibly revert 7ef1553dac but it seems much simpler to check the presence of "chassis_nr" earlier. 2) QEMU abort if same "chassis_nr" value is used several times, unveiled by commit d2623129a7de "qom: Drop parameter @errp of object_property_add() & friends" $ qemu-system-ppc64 -M pseries -device pci-bridge,chassis_nr=1 \ -device pci-bridge,chassis_nr=1 Unexpected error in object_property_try_add() at qom/object.c:1167: qemu-system-ppc64: -device pci-bridge,chassis_nr=1: attempt to add duplicate property '40000100' to object (type 'container') Aborted (core dumped) This happens because we assume that "chassis_nr" values are unique, but nobody enforces that and we end up generating duplicate DRC ids. The PCI code doesn't really care for duplicate "chassis_nr" properties since it is only used to initialize the "Chassis Number Register" of the bridge, with no functional impact on QEMU. So, even if passing the same value several times might look weird, it never broke anything before, so I guess we don't necessarily want to enforce strict checking in the PCI code now. Workaround both issues in the PAPR code: check that the bridge has a unique and non null "chassis_nr" when plugging it into its parent bus. Fixes: 05929a6c5dfe ("spapr: Don't use bus number for building DRC ids") Fixes: 7ef1553dac ("spapr_pci: Drop some dead error handling") Fixes: d2623129a7de ("qom: Drop parameter @errp of object_property_add() & friends") Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <159431476748.407044.16711294833569014964.stgit@bahia.lan> [dwg: Move check slightly to a better place] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-07-20ppc/pnv: Make PSI device types not user creatableGreg Kurz1-0/+1
QEMU aborts with -device pnv-psi-POWER8: $ qemu-system-ppc64 -device pnv-psi-POWER8 qemu-system-ppc64: hw/intc/xics.c:605: ics_realize: Assertion `ics->xics' failed. Aborted (core dumped) The Processor Service Interface Controller is an internal device. It should only be instantiated by the chip, which takes care of configuring the link required by the ICS object in the case of POWER8. It doesn't make sense for a user to specify it on the command line. Note that the PSI model for POWER8 was added 3 yrs ago but the devices weren't available on the command line because of a bug that was fixed by recent commit 2f35254aa0 ("pnv/psi: Correct the pnv-psi* devices not to be sysbus devices"). Fixes: 54f59d786c ("ppc/pnv: Add cut down PSI bridge model and hookup external interrupt") Reported-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <159413975752.169116.5808968580649255382.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2020-07-17tcg/cpu-exec: precise single-stepping after an interruptRichard Henderson1-1/+7
When single-stepping with a debugger attached to QEMU, and when an interrupt is raised, the debugger misses the first instruction after the interrupt. Tested-by: Luc Michel <luc.michel@greensocs.com> Reviewed-by: Luc Michel <luc.michel@greensocs.com> Buglink: https://bugs.launchpad.net/qemu/+bug/757702 Message-Id: <20200717163029.2737546-1-richard.henderson@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2020-07-17ipmi: add SET_SENSOR_READING commandCédric Le Goater1-0/+223
SET_SENSOR_READING is a complex IPMI command (see IPMI spec 35.17) which enables the host software to set the reading value and the event status of sensors supporting it. Below is a proposal for all the operations (reading, assert, deassert, event data) with the following limitations : - No event are generated for threshold-based sensors. - The case in which the BMC needs to generate its own events is not supported. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Corey Minyard <cminyard@mvista.com> Message-Id: <20191118092429.16149-1-clg@kaod.org> [Moved the break statement for case SENSOR_GEN_EVENT_DATA above the closing brace to keep the indention consistent.] Signed-off-by: Corey Minyard <cminyard@mvista.com>
2020-07-17ipmi: Fix a man page entryCorey Minyard1-1/+1
The line was too long, and some of the entries were wrong (fur instead of fru). Just use the prop=val thing tha other entries use. Signed-off-by: Corey Minyard <cminyard@mvista.com>
2020-07-17ipmi: Add man page pieces for the IPMI PCI devicesCorey Minyard1-0/+9
This was forgotten when the devices were added. Signed-off-by: Corey Minyard <cminyard@mvista.com>
2020-07-17migration/block-dirty-bitmap: fix add_bitmaps_to_listVladimir Sementsov-Ogievskiy1-1/+5
We shouldn't fail when finding an unnamed bitmap in a unnamed node or node with auto-generated node name, as bitmap migration ignores such bitmaps in the first place. Fixes: 82640edb88faa Fixes: 4ff5cc121b089 Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20200626130658.76498-1-vsementsov@virtuozzo.com> Reviewed-by: Eric Blake <eblake@redhat.com> [eblake: commit message grammar tweaks] Signed-off-by: Eric Blake <eblake@redhat.com>
2020-07-17file-posix: Fix leaked fd in raw_open_common() error pathKevin Wolf1-0/+3
Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20200717105426.51134-4-kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-17file-posix: Fix check_hdev_writable() with auto-read-onlyKevin Wolf1-12/+21
For Linux block devices, being able to open the device read-write doesn't necessarily mean that the device is actually writable (one example is a read-only LV, as you get with lvchange -pr <device>). We have check_hdev_writable() to check this condition and fail opening the image read-write if it's not actually writable. However, this check doesn't take auto-read-only into account, but results in a hard failure instead of downgrading to read-only where possible. Fix this and do the writable check not based on BDRV_O_RDWR, but only when this actually results in opening the file read-write. A second check is inserted in raw_reconfigure_getfd() to have the same check when dynamic auto-read-only upgrades an image file from read-only to read-write. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20200717105426.51134-3-kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-17file-posix: Move check_hdev_writable() upKevin Wolf1-33/+33
We'll need to call it in raw_open_common(), so move the function to avoid a forward declaration. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20200717105426.51134-2-kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-17file-posix: Allow byte-aligned O_DIRECT with NFSKevin Wolf1-1/+25
Since commit a6b257a08e3 ('file-posix: Handle undetectable alignment'), we assume that if we open a file with O_DIRECT and alignment probing returns 1, we just couldn't find out the real alignment requirement because some filesystems make the requirement only for allocated blocks. In this case, a safe default of 4k is used. This is too strict for NFS, which does actually allow byte-aligned requests even with O_DIRECT. Because we can't distinguish both cases with generic code, let's just look at the file system magic and disable s->needs_alignment for NFS. This way, O_DIRECT can still be used on NFS for images that are not aligned to 4k. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20200716142601.111237-3-kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-17block: Require aligned image size to avoid assertion failureKevin Wolf1-0/+16
Unaligned requests will automatically be aligned to bl.request_alignment and we can't extend write requests to access space beyond the end of the image without resizing the image, so if we have the WRITE permission, but not the RESIZE one, it's required that the image size is aligned. Failing to meet this requirement could cause assertion failures like this if RESIZE permissions weren't requested: qemu-img: block/io.c:1910: bdrv_co_write_req_prepare: Assertion `end_sector <= bs->total_sectors || child->perm & BLK_PERM_RESIZE' failed. This was e.g. triggered by qemu-img converting to a target image with 4k request alignment when the image was only aligned to 512 bytes, but not to 4k. Turn this into a graceful error in bdrv_check_perm() so that WRITE without RESIZE can only be taken if the image size is aligned. If a user holds both permissions and drops only RESIZE, the function will return an error, but bdrv_child_try_set_perm() will ignore the failure silently if permissions are only requested to be relaxed and just keep both permissions while returning success. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20200716142601.111237-2-kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-17iotests: test shutdown when bitmap is exported through NBDVladimir Sementsov-Ogievskiy3-0/+76
Test shutdown when bitmap is exported through NBD and active client exists. The previous patch fixes a crash, provoked by this scenario. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Tested-by: Eric Blake <eblake@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20200714162234.13113-3-vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-17nbd: make nbd_export_close_all() synchronousVladimir Sementsov-Ogievskiy1-0/+8
Consider nbd_export_close_all(). The call-stack looks like this: nbd_export_close_all() -> nbd_export_close -> call client_close() for each client. client_close() doesn't guarantee that client is closed: nbd_trip() keeps reference to it. So, nbd_export_close_all() just reduce reference counter on export and removes it from the list, but doesn't guarantee that nbd_trip() finished neither export actually removed. Let's wait for all exports actually removed. Without this fix, the following crash is possible: - export bitmap through internal Qemu NBD server - connect a client - shutdown Qemu On shutdown nbd_export_close_all is called, but it actually don't wait for nbd_trip() to finish and to release its references. So, export is not release, and exported bitmap remains busy, and on try to remove the bitmap (which is part of bdrv_close()) the assertion fails: bdrv_release_dirty_bitmap_locked: Assertion `!bdrv_dirty_bitmap_busy(bitmap)' failed Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20200714162234.13113-2-vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-17iotests/030: Reduce job speed to make race less likelyKevin Wolf1-1/+1
It can happen that the throttling of the stream job doesn't make it slow enough that we can be sure that it still exists when it is referenced again. Just use a much smaller speed to make this very unlikely to happen again. Reported-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20200716132829.20127-1-kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-17crypto: use a stronger private key for testsDaniel P. Berrangé2-37/+79
The unit tests using the x509 crypto functionality have started failing in Fedora 33 rawhide with a message like The certificate uses an insecure algorithm This is result of Fedora changes to support strong crypto [1]. RSA with 1024 bit key is viewed as legacy and thus insecure. Generate a new private key which is 3072 bits long and reasonable future proof. [1] https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2 Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20200715154701.1041325-1-berrange@redhat.com> Reviewed-by: Kashyap Chamarthy <kchamart@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-17qemu-img resize: Require --shrink for shrinking all image formatsKevin Wolf1-11/+3
QEMU 2.11 introduced the --shrink option for qemu-img resize to avoid accidentally shrinking images (commit 4ffca8904a3). However, for compatibility reasons, it was not enforced for raw images yet, but only a deprecation warning was printed. This warning has existed for long enough that we can now finally require --shrink for raw images, too, and error out if it's not given. Documentation already describes the state as it is after this patch. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20200710121717.28339-1-kwolf@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-17Remove VXHS block deviceMarc-André Lureau18-718/+10
The vxhs code doesn't compile since v2.12.0. There's no point in fixing and then adding CI for a config that our users have demonstrated that they do not use; better to just remove it. Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20200711065926.2204721-1-marcandre.lureau@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-17vvfat: set status to odd fixesPrasad J Pandit1-1/+1
Virtual VFAT driver is quite old and rarely used. Set its status to Odd Fixes. Signed-off-by: Prasad J Pandit <pjp@fedoraproject.org> Message-Id: <20200710190451.761286-1-ppandit@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-17docs/s390x: fix vfio-ccw typeCornelia Huck1-1/+1
Fix the type name in the mdevctl example. Signed-off-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Message-Id: <20200716145031.771476-1-cohuck@redhat.com>
2020-07-17gitlab-ci.yml: Add fuzzer testsThomas Huth1-1/+19
So far we neither compile-tested nor run any of the new fuzzers in our CI, which led to some build failures of the fuzzer code in the past weeks. To avoid this problem, add a job to compile the fuzzer code and run some loops (which likely don't find any new bugs via fuzzing, but at least we know that the code can still be run). A nice side-effect of this test is that the leak tests are enabled here, so we should now notice some of the memory leaks in our code base earlier. Message-Id: <20200716100950.27396-1-thuth@redhat.com> Reviewed-by: Alexander Bulekov <alxndr@bu.edu> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-07-17qom: Plug memory leak in "info qom-tree"Markus Armbruster1-2/+4
Commit e8c9e65816 "qom: Make "info qom-tree" show children sorted" created a memory leak, because I didn't realize object_get_canonical_path_component()'s value needs to be freed. Reproducer: $ qemu-system-x86_64 -nodefaults -display none -S -monitor stdio QEMU 5.0.50 monitor - type 'help' for more information (qemu) info qom-tree This leaks some 4500 path components, 12-13 characters on average, i.e. roughly 100kBytes depending on the allocator. A couple of hundred "info qom-tree" here, a couple of hundred there, and soon enough we're talking about real memory. Plug the leak. Fixes: e8c9e65816f5dbfe18ad3b2be938d0d8192d459a Signed-off-by: Markus Armbruster <armbru@redhat.com> Reported-by: Reviewed-by: Li Qiang <liq3ea@gmail.com> [sent same patch] Message-Id: <20200714160202.3121879-3-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-07-17configure: Fix for running with --enable-werror on macOSThomas Huth1-1/+1
The configure script currently refuses to succeed when run on macOS with --enable-werror: ERROR: configure test passed without -Werror but failed with -Werror. The information in config.log indicates: config-temp/qemu-conf.c:3:55: error: control reaches end of non-void function [-Werror,-Wreturn-type] static void *f(void *p) { pthread_setname_np("QEMU"); } ^ And indeed, the return statement is missing here. Fixes: 479a57475e ("util: Implement debug-threads for macOS") Message-Id: <20200716055655.24507-1-thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-07-17fuzz: Expect the cmdline in a freeable GStringAlexander Bulekov4-15/+14
In the initial FuzzTarget, get_init_cmdline returned a char *. With this API, we had no guarantee about where the string came from. For example, i440fx-qtest-reboot-fuzz simply returned a pointer to a string literal, while the QOS-based targets build the arguments out in a GString an return the gchar *str pointer. Since we did not try to free the cmdline, we have a leak for any targets that do not simply return string literals. Clean up this mess by forcing fuzz-targets to return a GString, that we can free. Signed-off-by: Alexander Bulekov <alxndr@bu.edu> Message-Id: <20200714174616.20709-1-alxndr@bu.edu> Reviewed-by: Darren Kenny <darren.kenny@oracle.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-07-17tests: qmp-cmd-test: fix memory leakLi Qiang1-0/+13
Properly free each test response to avoid memory leak and separate qtest_qmp() calls with spare lines, in a consistent manner. Fixes: 5b88849e7b9("tests/qmp-cmd-test: Add qmp/object-add-failure-modes") Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Li Qiang <liq3ea@163.com> Message-Id: <20200715154117.15456-1-liq3ea@163.com> Fixes: 9fc719b869 ("tests/qmp-cmd-test: Add qmp/object-add-duplicate-id") Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-07-17qtest: bios-tables-test: fix a memory leakLi Qiang1-0/+1
Fixes: 5da7c35e25a("bios-tables-test: Add Q35/TPM-TIS test") Signed-off-by: Li Qiang <liq3ea@163.com> Message-Id: <20200714153536.66060-1-liq3ea@163.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-07-16tcg/cpu-exec: precise single-stepping after an exceptionLuc Michel1-0/+11
When single-stepping with a debugger attached to QEMU, and when an exception is raised, the debugger misses the first instruction after the exception: $ qemu-system-aarch64 -M virt -display none -cpu cortex-a53 -s -S $ aarch64-linux-gnu-gdb GNU gdb (GDB) 9.2 [...] (gdb) tar rem :1234 Remote debugging using :1234 warning: No executable has been specified and target does not support determining executable automatically. Try using the "file" command. 0x0000000000000000 in ?? () (gdb) # writing nop insns to 0x200 and 0x204 (gdb) set *0x200 = 0xd503201f (gdb) set *0x204 = 0xd503201f (gdb) # 0x0 address contains 0 which is an invalid opcode. (gdb) # The CPU should raise an exception and jump to 0x200 (gdb) si 0x0000000000000204 in ?? () With this commit, the same run steps correctly on the first instruction of the exception vector: (gdb) si 0x0000000000000200 in ?? () Buglink: https://bugs.launchpad.net/qemu/+bug/757702 Signed-off-by: Luc Michel <luc.michel@greensocs.com> Message-Id: <20200716193947.3058389-1-luc.michel@greensocs.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2020-07-16tcg: Save/restore vecop_list around minmax fallbackRichard Henderson1-0/+2
Forgetting this asserts when tcg_gen_cmp_vec is called from within tcg_gen_cmpsel_vec. Fixes: 72b4c792c7a Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2020-07-16i386: hvf: Explicitly set CR4 guest/host maskRoman Bolshakov1-0/+1
Removal of register reset omitted initialization of CR4 guest/host mask. x86_64 guests aren't booting without it. Fixes: 5009ef22c6bb2 ("i386: hvf: Don't duplicate register reset") Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com> Message-Id: <20200714090726.41082-1-r.bolshakov@yadro.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-07-16hw/i2c: Document the I2C qdev helpersPhilippe Mathieu-Daudé1-0/+48
In commit d88c42ff2c we added new prototype but neglected to add their documentation. Fix that. Reported-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Corey Minyard <cminyard@mvista.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20200705224154.16917-6-f4bug@amsat.org> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2020-07-16hw/i2c: Rename i2c_create_slave() as i2c_slave_create_simple()Philippe Mathieu-Daudé16-53/+54
We use "create_simple" names for functions that allocate, initialize, configure and realize device objects: pci_create_simple(), isa_create_simple(), usb_create_simple(). For consistency, rename i2c_create_slave() as i2c_slave_create_simple(). Since we have to update all the callers, also let it return a I2CSlave object. Suggested-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Corey Minyard <cminyard@mvista.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20200705224154.16917-5-f4bug@amsat.org> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2020-07-16hw/i2c: Rename i2c_realize_and_unref() as i2c_slave_realize_and_unref()Philippe Mathieu-Daudé3-8/+10
The other i2c functions are called i2c_slave_FOO(). Rename as i2c_slave_realize_and_unref() to be consistent. Suggested-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Corey Minyard <cminyard@mvista.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20200705224154.16917-4-f4bug@amsat.org> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2020-07-16hw/i2c: Rename i2c_try_create_slave() as i2c_slave_new()Philippe Mathieu-Daudé3-9/+8
We use "new" names for functions that allocate and initialize device objects: pci_new(), isa_new(), usb_new(). Let's call this one i2c_slave_new(). Since we have to update all the callers, also let it return a I2CSlave object. Suggested-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20200705224154.16917-3-f4bug@amsat.org> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2020-07-16hw/i2c/aspeed_i2c: Simplify aspeed_i2c_get_bus()Philippe Mathieu-Daudé3-38/+37
All the callers of aspeed_i2c_get_bus() have a AspeedI2CState and cast it to a DeviceState with DEVICE(), then aspeed_i2c_get_bus() cast the DeviceState to an AspeedI2CState with ASPEED_I2C()... Simplify aspeed_i2c_get_bus() callers by using AspeedI2CState argument. Reviewed-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20200705224154.16917-2-f4bug@amsat.org> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2020-07-16hw/i2c/Kconfig: Add an entry for the SMBusPhilippe Mathieu-Daudé2-3/+8
The System Management Bus is more or less a derivative of the I2C bus, thus the Kconfig entry depends of I2C. Not all boards providing an I2C bus support SMBus. Use two different Kconfig entries to be able to select I2C without selecting SMBus. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20191231183216.6781-6-philmd@redhat.com> Signed-off-by: Corey Minyard <cminyard@mvista.com>
2020-07-16target/i386: add the missing vmx features for Skylake-Server and ↵Chenyi Qiang1-0/+14
Cascadelake-Server CPU models Add the missing vmx features in Skylake-Server and Cascadelake-Server CPU models based on the output of Paolo's script. Signed-off-by: Chenyi Qiang <chenyi.qiang@intel.com> Message-Id: <20200714084148.26690-4-chenyi.qiang@intel.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>