summaryrefslogtreecommitdiffstats
path: root/hw
Commit message (Collapse)AuthorAgeFilesLines
* various: Remove suspicious '\' character outside of #define in C codePhilippe Mathieu-Daudé2020-04-294-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes the following coccinelle warnings: $ spatch --sp-file --verbose-parsing ... \ scripts/coccinelle/remove_local_err.cocci ... SUSPICIOUS: a \ character appears outside of a #define at ./target/ppc/translate_init.inc.c:5213 SUSPICIOUS: a \ character appears outside of a #define at ./target/ppc/translate_init.inc.c:5261 SUSPICIOUS: a \ character appears outside of a #define at ./target/microblaze/cpu.c:166 SUSPICIOUS: a \ character appears outside of a #define at ./target/microblaze/cpu.c:167 SUSPICIOUS: a \ character appears outside of a #define at ./target/microblaze/cpu.c:169 SUSPICIOUS: a \ character appears outside of a #define at ./target/microblaze/cpu.c:170 SUSPICIOUS: a \ character appears outside of a #define at ./target/microblaze/cpu.c:171 SUSPICIOUS: a \ character appears outside of a #define at ./target/microblaze/cpu.c:172 SUSPICIOUS: a \ character appears outside of a #define at ./target/microblaze/cpu.c:173 SUSPICIOUS: a \ character appears outside of a #define at ./target/i386/cpu.c:5787 SUSPICIOUS: a \ character appears outside of a #define at ./target/i386/cpu.c:5789 SUSPICIOUS: a \ character appears outside of a #define at ./target/i386/cpu.c:5800 SUSPICIOUS: a \ character appears outside of a #define at ./target/i386/cpu.c:5801 SUSPICIOUS: a \ character appears outside of a #define at ./target/i386/cpu.c:5802 SUSPICIOUS: a \ character appears outside of a #define at ./target/i386/cpu.c:5804 SUSPICIOUS: a \ character appears outside of a #define at ./target/i386/cpu.c:5805 SUSPICIOUS: a \ character appears outside of a #define at ./target/i386/cpu.c:5806 SUSPICIOUS: a \ character appears outside of a #define at ./target/i386/cpu.c:6329 SUSPICIOUS: a \ character appears outside of a #define at ./hw/sd/sdhci.c:1133 SUSPICIOUS: a \ character appears outside of a #define at ./hw/scsi/scsi-disk.c:3081 SUSPICIOUS: a \ character appears outside of a #define at ./hw/net/virtio-net.c:1529 SUSPICIOUS: a \ character appears outside of a #define at ./hw/riscv/sifive_u.c:468 SUSPICIOUS: a \ character appears outside of a #define at ./dump/dump.c:1895 SUSPICIOUS: a \ character appears outside of a #define at ./block/vhdx.c:2209 SUSPICIOUS: a \ character appears outside of a #define at ./block/vhdx.c:2215 SUSPICIOUS: a \ character appears outside of a #define at ./block/vhdx.c:2221 SUSPICIOUS: a \ character appears outside of a #define at ./block/vhdx.c:2222 SUSPICIOUS: a \ character appears outside of a #define at ./block/replication.c:172 SUSPICIOUS: a \ character appears outside of a #define at ./block/replication.c:173 Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20200412223619.11284-2-f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Markus Armbruster <armbru@redhat.com>
* Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into stagingPeter Maydell2020-04-134-3/+93
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | pc: bugfixes, maintainers A couple of bugfixes. Add a new vhost-user-blk maintainer. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # gpg: Signature made Mon 13 Apr 2020 11:57:17 BST # gpg: using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469 # gpg: issuer "mst@redhat.com" # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [full] # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [full] # Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67 # Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469 * remotes/mst/tags/for_upstream: exec: Fix for qemu_ram_resize() callback fw_cfg: Migrate ACPI table mr sizes separately acpi: Use macro for table-loader file name MAINTAINERS: Add myself as vhost-user-blk maintainer Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * fw_cfg: Migrate ACPI table mr sizes separatelyShameer Kolothum2020-04-132-1/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Any sub-page size update to ACPI MRs will be lost during migration, as we use aligned size in ram_load_precopy() -> qemu_ram_resize() path. This will result in inconsistency in FWCfgEntry sizes between source and destination. In order to avoid this, save and restore them separately during migration. Up until now, this problem may not be that relevant for x86 as both ACPI table and Linker MRs gets padded and aligned. Also at present, qemu_ram_resize() doesn't invoke callback to update FWCfgEntry for unaligned size changes. But since we are going to fix the qemu_ram_resize() in the subsequent patch, the issue may become more serious especially for RSDP MR case. Moreover, the issue will soon become prominent in arm/virt as well where the MRs are not padded or aligned at all and eventually have acpi table changes as part of future additions like NVDIMM hot-add feature. Suggested-by: David Hildenbrand <david@redhat.com> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> Acked-by: David Hildenbrand <david@redhat.com> Message-Id: <20200403101827.30664-3-shameerali.kolothum.thodi@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
| * acpi: Use macro for table-loader file nameShameer Kolothum2020-04-132-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | Use macro for "etc/table-loader" and move it to the header file similar to ACPI_BUILD_TABLE_FILE/ACPI_BUILD_RSDP_FILE etc. Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20200403101827.30664-2-shameerali.kolothum.thodi@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
* | Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into stagingPeter Maydell2020-04-131-3/+16
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bugfixes, and reworking of the atomics documentation. # gpg: Signature made Mon 13 Apr 2020 07:56:22 BST # gpg: using RSA key F13338574B662389866C7682BFFBD25F78C7AE83 # gpg: issuer "pbonzini@redhat.com" # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full] # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" [full] # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * remotes/bonzini/tags/for-upstream: module: increase dirs array size by one memory: Do not allow direct write access to rom_device regions vl.c: error out if -mem-path is used together with -M memory-backend rcu: do not mention atomic_mb_read/set in documentation atomics: update documentation atomics: convert to reStructuredText oslib-posix: take lock before qemu_cond_broadcast piix: fix xenfv regression, add compat machine xenfv-4.2 Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * piix: fix xenfv regression, add compat machine xenfv-4.2Olaf Hering2020-04-111-3/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With QEMU 4.0 an incompatible change was added to pc_piix, which makes it practical impossible to migrate domUs started with qemu2 or qemu3 to newer qemu versions. Commit 7fccf2a06890e3bc3b30e29827ad3fb93fe88fea added and enabled a new member "smbus_no_migration_support". In commit 4ab2f2a8aabfea95cc53c64e13b3f67960b27fdf the vmstate_acpi got new elements, which are conditionally filled. As a result, an incoming migration expected smbus related data unless smbus migration was disabled for a given MachineClass. Since first commit forgot to handle 'xenfv', domUs started with QEMU 4.x are incompatible with their QEMU siblings. Using other existing machine types, such as 'pc-i440fx-3.1', is not possible because 'xenfv' creates the 'xen-platform' PCI device at 00:02.0, while all other variants to run a domU would create it at 00:04.0. To cover both the existing and the broken case of 'xenfv' in a single qemu binary, a new compatibility variant of 'xenfv-4.2' must be added which targets domUs started with qemu 4.2. The existing 'xenfv' restores compatibility of QEMU 5.x with qemu 3.1. Host admins who started domUs with QEMU 4.x (preferrable QEMU 4.2) have to use a wrapper script which appends '-machine xenfv-4.2' to the device-model command line. This is only required if there is no maintenance window which allows to temporary shutdown the domU and restart it with a fixed device-model. The wrapper script is as simple as this: #!/bin/sh exec /usr/bin/qemu-system-i386 "$@" -machine xenfv-4.2 With xl this script will be enabled with device_model_override=, see xl.cfg(5). To live migrate a domU, adjust the existing domU.cfg and pass it to xl migrate or xl save/restore: xl migrate -C new-domU.cfg domU remote-host xl save domU CheckpointFile new-domU.cfg xl restore new-domU.cfg CheckpointFile With libvirt this script will be enabled with the <emulator> element in domU.xml. Use 'virsh edit' prior 'virsh migrate' to replace the existing <emulator> element to point it to the wrapper script. Signed-off-by: Olaf Hering <olaf@aepfle.de> Message-Id: <20200327151841.13877-1-olaf@aepfle.de> [Adjust tests for blacklisted machine types, simplifying the one in qom-test. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* | Merge remote-tracking branch 'remotes/stsquad/tags/pull-misc-fixes-070420-1' ↵Peter Maydell2020-04-071-1/+4
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into staging Various fixes: - add .github repo lockdown config - better handle missing symbols in elf-ops - protect fcntl64 with #ifdef - remove unused macros from test - fix handling of /proc/self/maps - avoid BAD_SHIFT in x80 softfloat - properly terminate on .hex EOF - fix configure probe on windows cross build - fix %r12 guest_base initialization # gpg: Signature made Tue 07 Apr 2020 16:31:14 BST # gpg: using RSA key 6685AE99E75167BCAFC8DF35FBD0DB095A9E2A44 # gpg: Good signature from "Alex Bennée (Master Work Key) <alex.bennee@linaro.org>" [full] # Primary key fingerprint: 6685 AE99 E751 67BC AFC8 DF35 FBD0 DB09 5A9E 2A44 * remotes/stsquad/tags/pull-misc-fixes-070420-1: tcg/i386: Fix %r12 guest_base initialization configure: Add -Werror to PIE probe hw/core: properly terminate loading .hex on EOF record linux-user: clean-up padding on /proc/self/maps linux-user: factor out reading of /proc/self/maps softfloat: Fix BAD_SHIFT from normalizeFloatx80Subnormal gdbstub: fix compiler complaining target/xtensa: add FIXME for translation memory leak linux-user: more debug for init_guest_space tests/tcg: remove extraneous pasting macros linux-user: protect fcntl64 with an #ifdef elf-ops: bail out if we have no function symbols .github: Enable repo-lockdown bot to refuse GitHub pull requests Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * | hw/core: properly terminate loading .hex on EOF recordAlex Bennée2020-04-071-1/+4
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The https://makecode.microbit.org/#editor generates slightly weird .hex files which work fine on a real microbit but causes QEMU to choke. The reason is extraneous data after the EOF record which causes the loader to attempt to write a bigger file than it should to the "rom". According to the HEX file spec an EOF really should be the last thing we process so lets do that. Reported-by: Ursula Bennée <alex.bennee@linaro.org> Signed-off-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200403191150.863-12-alex.bennee@linaro.org>
* | Merge remote-tracking branch 'remotes/aperard/tags/pull-xen-20200407' into ↵Peter Maydell2020-04-072-7/+5Star
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | staging Xen queue for QEMU 5.0 - Fix for xen-block. - A fix for a Coverity false positive in xen-usb. - Update MAINTAINERS to add xen-usb.c to Xen section. # gpg: Signature made Tue 07 Apr 2020 16:21:16 BST # gpg: using RSA key F80C006308E22CFD8A92E7980CF5572FD7FB55AF # gpg: issuer "anthony.perard@citrix.com" # gpg: Good signature from "Anthony PERARD <anthony.perard@gmail.com>" [marginal] # gpg: aka "Anthony PERARD <anthony.perard@citrix.com>" [marginal] # gpg: WARNING: This key is not certified with sufficiently trusted signatures! # gpg: It is not certain that the signature belongs to the owner. # Primary key fingerprint: 5379 2F71 024C 600F 778A 7161 D8D5 7199 DF83 42C8 # Subkey fingerprint: F80C 0063 08E2 2CFD 8A92 E798 0CF5 572F D7FB 55AF * remotes/aperard/tags/pull-xen-20200407: MAINTAINERS: Add xen-usb.c to Xen section xen-block: Fix uninitialized variable hw/usb/xen-usb.c: Pass struct usbback_req* to usbback_packet_complete() Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * | xen-block: Fix uninitialized variableAnthony PERARD2020-04-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since 7f5d9b206d1e ("object-add: don't create return value if failed"), qmp_object_add() don't write any value in 'ret_data', thus has random data. Then qobject_unref() fails and abort(). Fix by initialising 'ret_data' properly. Fixes: 5f07c4d60d09 ("qapi: Flatten object-add") Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20200406164207.1446817-1-anthony.perard@citrix.com>
| * | hw/usb/xen-usb.c: Pass struct usbback_req* to usbback_packet_complete()Peter Maydell2020-04-071-6/+4Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The function usbback_packet_complete() currently takes a USBPacket*, which must be a pointer to the packet field within a struct usbback_req; the function uses container_of() to get the struct usbback_req* given the USBPacket*. This is unnecessarily confusing (and in particular it confuses the Coverity Scan analysis, resulting in the false positive CID 1421919 where it thinks that we write off the end of the structure). Since both callsites already have the pointer to the struct usbback_req, just pass that in directly. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20200323164318.26567-1-peter.maydell@linaro.org> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
* | | Merge remote-tracking branch 'remotes/maxreitz/tags/pull-block-2020-04-07' ↵Peter Maydell2020-04-071-32/+16Star
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into staging Block patches for 5.0-rc2: - Fix double QLIST_REMOVE() and potential request object leak in xen-block - Prevent a potential assertion failure in qcow2's code for compressed clusters by rejecting invalid (unaligned) requests with -EIO - Prevent discards on qcow2 v2 images from making backing data reappear - Make qemu-img convert report I/O error locations by byte offsets consistently - Fix for potential I/O test errors (accidental globbing due to missing quotes) # gpg: Signature made Tue 07 Apr 2020 13:30:01 BST # gpg: using RSA key 91BEB60A30DB3E8857D11829F407DB0061D5CF40 # gpg: issuer "mreitz@redhat.com" # gpg: Good signature from "Max Reitz <mreitz@redhat.com>" [full] # Primary key fingerprint: 91BE B60A 30DB 3E88 57D1 1829 F407 DB00 61D5 CF40 * remotes/maxreitz/tags/pull-block-2020-04-07: xen-block: Fix double qlist remove and request leak iotests/common.pattern: Quote echos qcow2: Check request size in qcow2_co_pwritev_compressed_part() qemu-img: Report convert errors by bytes, not sectors qcow2: Forbid discard in qcow2 v2 images with backing files Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * | xen-block: Fix double qlist remove and request leakAnthony PERARD2020-04-071-32/+16Star
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit a31ca6801c02 ("qemu/queue.h: clear linked list pointers on remove") revealed that a request was removed twice from a list, once in xen_block_finish_request() and a second time in xen_block_release_request() when both function are called from xen_block_complete_aio(). But also, the `requests_inflight' counter is decreased twice, and thus became negative. This is a bug that was introduced in bfd0d6366043 ("xen-block: improve response latency"), where a `finished' list was removed. That commit also introduced a leak of request in xen_block_do_aio(). That function calls xen_block_finish_request() but the request is never released after that. To fix both issue, we do two changes: - we squash finish_request() and release_request() together as we want to remove a request from 'inflight' list to add it to 'freelist'. - before releasing a request, we need to let the other end know the result, thus we should call xen_block_send_response() before releasing a request. The first change fixes the double QLIST_REMOVE() as we remove the extra call. The second change makes the leak go away because if we want to call finish_request(), we need to call a function that does all of finish, send response, and release. Fixes: bfd0d6366043 ("xen-block: improve response latency") Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20200406140217.1441858-1-anthony.perard@citrix.com> Reviewed-by: Paul Durrant <paul@xen.org> [mreitz: Amended commit message as per Paul's suggestions] Signed-off-by: Max Reitz <mreitz@redhat.com>
* | Merge remote-tracking branch ↵Peter Maydell2020-04-071-11/+26
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 'remotes/kraxel/tags/fixes-20200407-pull-request' into staging fixes for 5.0: - audio: windows (dsound) fixes. - vga: ati blitter sanity check fixes. # gpg: Signature made Tue 07 Apr 2020 10:21:44 BST # gpg: using RSA key 4CB6D8EED3E87138 # gpg: Good signature from "Gerd Hoffmann (work) <kraxel@redhat.com>" [full] # gpg: aka "Gerd Hoffmann <gerd@kraxel.org>" [full] # gpg: aka "Gerd Hoffmann (private) <kraxel@gmail.com>" [full] # Primary key fingerprint: A032 8CFF B93A 17A7 9901 FE7D 4CB6 D8EE D3E8 7138 * remotes/kraxel/tags/fixes-20200407-pull-request: ati-vga: Fix checks in ati_2d_blt() to avoid crash dsoundaudio: dsound_get_buffer_in should honor *size dsoundaudio: fix "Could not lock capture buffer" warning dsoundaudio: fix never-ending playback loop Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * | ati-vga: Fix checks in ati_2d_blt() to avoid crashBALATON Zoltan2020-04-071-11/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In some corner cases (that never happen during normal operation but a malicious guest could program wrong values) pixman functions were called with parameters that result in a crash. Fix this and add more checks to disallow such cases. Reported-by: Ziming Zhang <ezrakiez@gmail.com> Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-id: 20200406204029.19559747D5D@zero.eik.bme.hu Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
* | | ppc/pnv: Create BMC devices only when defaults are enabledCédric Le Goater2020-04-072-5/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit e2392d4395dd ("ppc/pnv: Create BMC devices at machine init") introduced default BMC devices which can be a problem when the same devices are defined on the command line with : -device ipmi-bmc-sim,id=bmc0 -device isa-ipmi-bt,bmc=bmc0,irq=10 QEMU fails with : qemu-system-ppc64: error creating device tree: node: FDT_ERR_EXISTS Use defaults_enabled() when creating the default BMC devices to let the user provide its own BMC devices using '-nodefaults'. If no BMC device are provided, output a warning but let QEMU run as this is a supported configuration. However, when multiple BMC devices are defined, stop QEMU with a clear error as the results are unexpected. Fixes: e2392d4395dd ("ppc/pnv: Create BMC devices at machine init") Reported-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20200404153655.166834-1-clg@kaod.org> Tested-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* | | hw/ppc/ppc440_uc.c: Remove incorrect iothread locking from dcr_write_pcie()Peter Maydell2020-04-071-3/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In dcr_write_pcie() we take the iothread lock around a call to pcie_host_mmcfg_udpate(). This is an incorrect attempt to deal with the bug fixed in commit 235352ee6e73d7716, where we were not taking the iothread lock before calling device dcr read/write functions. (It's not sufficient locking, because although the other cases in the switch statement won't assert, there is no locking which prevents multiple guest CPUs from trying to access the PPC460EXPCIEState struct at the same time and corrupting data.) Unfortunately with commit 235352ee6e73d7716 we are now trying to recursively take the iothread lock, which will assert: $ qemu-system-ppc -M sam460ex --display none ** ERROR:/home/petmay01/linaro/qemu-from-laptop/qemu/cpus.c:1830:qemu_mutex_lock_iothread_impl: assertion failed: (!qemu_mutex_iothread_locked()) Aborted (core dumped) Remove the locking within dcr_write_pcie(). Fixes: 235352ee6e73d7716 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20200330125228.24994-1-peter.maydell@linaro.org> Tested-by: BALATON Zoltan <balaton@eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* | | spapr: Fix failure path for attempting to hot unplug PCI bridgesDavid Gibson2020-04-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For various technical reasons we can't currently allow unplug a PCI to PCI bridge on the pseries machine. spapr_pci_unplug_request() correctly generates an error message if that's attempted. But.. if the given errp is not error_abort or error_fatal, it doesn't actually stop trying to unplug the bridge anyway. Fixes: 14e714900f6b "spapr: Allow hot plug/unplug of PCI bridges and devices under PCI bridges" Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Greg Kurz <groug@kaod.org>
* | | ppc/spapr: Don't kill the guest if a recovered FWNMI machine check delivery ↵Nicholas Piggin2020-04-071-5/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fails Try to be tolerant of FWNMI delivery errors if the machine check had been recovered by the host. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20200325142906.221248-5-npiggin@gmail.com> Reviewed-by: Greg Kurz <groug@kaod.org> [dwg: Updated comment at Greg's suggestion] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* | | ppc/spapr: Add FWNMI machine check delivery warningsNicholas Piggin2020-04-072-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add some messages which explain problems and guest misbehaviour that may be difficult to diagnose in rare cases of machine checks. Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20200325142906.221248-4-npiggin@gmail.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* | | ppc/spapr: Improve FWNMI machine check delivery corner case commentsNicholas Piggin2020-04-071-8/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some of the conditions are not as clearly documented as they could be. Also the non-FWNMI case does not need a large comment. Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20200325142906.221248-3-npiggin@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* | | ppc/spapr: KVM FWNMI should not be enabled until guest requests itNicholas Piggin2020-04-072-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The KVM FWNMI capability should be enabled with the "ibm,nmi-register" rtas call. Although MCEs from KVM will be delivered as architected interrupts to the guest before "ibm,nmi-register" is called, KVM has different behaviour depending on whether the guest has enabled FWNMI (it attempts to do more recovery on behalf of a non-FWNMI guest). Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Message-Id: <20200325142906.221248-2-npiggin@gmail.com> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* | | vfio/spapr: Fix page size calculationAlexey Kardashevskiy2020-04-071-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Coverity detected an issue (CID 1421903) with potential call of clz64(0) which returns 64 which make it do "<<" with a negative number. This checks the mask and avoids undefined behaviour. In practice pgsizes and memory_region_iommu_get_min_page_size() always have some common page sizes and even if they did not, the resulting page size would be 0x8000.0000.0000.0000 (gcc 9.2) and ioctl(VFIO_IOMMU_SPAPR_TCE_CREATE) would fail anyway. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Message-Id: <20200324063912.25063-1-aik@ozlabs.ru> Reviewed-by: Greg Kurz <groug@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* | | hw/ppc/e500.c: Handle qemu_find_file() failurePeter Maydell2020-04-071-0/+4
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If qemu_find_file() doesn't find the BIOS it returns NULL; we were passing that unchecked through to load_elf(), which assumes a non-NULL pointer and may misbehave. In practice it fails with a weird message: $ qemu-system-ppc -M ppce500 -display none -kernel nonesuch Bad address qemu-system-ppc: could not load firmware '(null)' Handle the failure case better: $ qemu-system-ppc -M ppce500 -display none -kernel nonesuch qemu-system-ppc: could not find firmware/kernel file 'nonesuch' Spotted by Coverity (CID 1238954). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20200324121216.23899-1-peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
* | dma/xlnx-zdma: Reorg to fix CUR_DSCREdgar E. Iglesias2020-04-061-25/+22Star
| | | | | | | | | | | | | | | | | | | | | | Reorganize the descriptor handling so that CUR_DSCR always points to the next descriptor to be processed. Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Francisco Iglesias <frasse.iglesias@gmail.com> Message-id: 20200402134721.27863-6-edgar.iglesias@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* | dma/xlnx-zdma: Advance the descriptor address when stoppingEdgar E. Iglesias2020-04-061-1/+0Star
| | | | | | | | | | | | | | | | | | | | Advance the descriptor address when stopping the channel. Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Francisco Iglesias <frasse.iglesias@gmail.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200402134721.27863-5-edgar.iglesias@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* | dma/xlnx-zdma: Clear DMA_DONE when haltingEdgar E. Iglesias2020-04-061-0/+1
| | | | | | | | | | | | | | | | | | | | Clear DMA_DONE when halting the DMA channel. Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Francisco Iglesias <frasse.iglesias@gmail.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20200402134721.27863-4-edgar.iglesias@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* | dma/xlnx-zdma: Populate DBG0.CMN_BUF_FREEEdgar E. Iglesias2020-04-061-0/+6
| | | | | | | | | | | | | | | | | | | | Populate DBG0.CMN_BUF_FREE so that SW can see some free space. Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Francisco Iglesias <frasse.iglesias@gmail.com> Message-id: 20200402134721.27863-3-edgar.iglesias@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* | dma/xlnx-zdma: Remove commentEdgar E. Iglesias2020-04-061-1/+0Star
| | | | | | | | | | | | | | | | | | | | Remove comment. Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Francisco Iglesias <frasse.iglesias@gmail.com> Message-id: 20200402134721.27863-2-edgar.iglesias@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
* | hw/gpio/aspeed_gpio.c: Don't directly include assert.hPeter Maydell2020-04-031-2/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove a direct include of assert.h -- this is already provided by qemu/osdep.h, and it breaks our rule that the first include must always be osdep.h. In particular we must get the assert() macro via osdep.h to avoid compile failures on mingw (see the comment in osdep.h where we redefine assert() for that platform). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-id: 20200403124712.24826-1-peter.maydell@linaro.org
* | hw/arm/collie: Put StrongARMState* into a CollieMachineState structPeter Maydell2020-04-031-5/+28
|/ | | | | | | | | | | | | | | | | | | Coverity complains that the collie_init() function leaks the memory allocated in sa1110_init(). This is true but not significant since the function is called only once on machine init and the memory must remain in existence until QEMU exits anyway. Still, we can avoid the technical memory leak by keeping the pointer to the StrongARMState inside the machine state struct. Switch from the simple DEFINE_MACHINE() style to defining a subclass of TYPE_MACHINE which extends the MachineState struct, and keep the pointer there. Fixes: CID 1421921 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20200326204919.22006-1-peter.maydell@linaro.org
* Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20200403' into stagingPeter Maydell2020-04-034-15/+30
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - fix cpu number reporting in the stsi 3.2.2 block for kvm - fix migration for old machines with odd ram sizes # gpg: Signature made Fri 03 Apr 2020 10:11:06 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-20200403: vl/s390x: fixup ram sizes for compat machines s390x: kvm: Fix number of cpu reports for stsi 3.2.2 Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * vl/s390x: fixup ram sizes for compat machinesChristian Borntraeger2020-04-024-15/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Older QEMU versions did fixup the ram size to match what can be reported via sclp. We need to mimic this behaviour for machine types 4.2 and older to not fail on inbound migration for memory sizes that do not fit. Old machines with proper aligned memory sizes are not affected. Alignment table: VM size (<=) | Alignment -------------------------- 1020M | 1M 2040M | 2M 4080M | 4M 8160M | 8M 16320M | 16M 32640M | 32M 65280M | 64M 130560M | 128M 261120M | 256M 522240M | 512M 1044480M | 1G 2088960M | 2G 4177920M | 4G 8355840M | 8G Suggested action is to replace unaligned -m value with a suitable aligned one or if a change to a newer machine type is possible, use a machine version >= 5.0. A future version might remove the compatibility handling. For machine types >= 5.0 we can simply use an increment size of 1M and use the full range of increment number which allows for all possible memory sizes. The old limitation of having a maximum of 1020 increments was added for standby memory, which we no longer support. With that we can now support even weird memory sizes like 10001234 MB. As we no longer fixup maxram_size as well, make other users use ram_size instead. Keep using maxram_size when setting the maximum ram size in KVM, as that will come in handy in the future when supporting memory hotplug (in contrast, storage keys and storage attributes for hotplugged memory will have to be migrated per RAM block in the future). Fixes: 3a12fc61af5c ("390x/s390-virtio-ccw: use memdev for RAM") Reported-by: Lukáš Doktor <ldoktor@redhat.com> Signed-off-by: David Hildenbrand <david@redhat.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: David Hildenbrand <david@redhat.com> Acked-by: Igor Mammedov <imammedo@redhat.com> Cc: Igor Mammedov <imammedo@redhat.com> Cc: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20200401123754.109602-1-borntraeger@de.ibm.com> [CH: fixed up message on memory size fixup] Signed-off-by: Cornelia Huck <cohuck@redhat.com>
* | Merge remote-tracking branch 'remotes/ehabkost/tags/x86-next-pull-request' ↵Peter Maydell2020-04-032-10/+39
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into staging x86 queue for -rc2 Fixes: * EPYC CPU model APIC ID topology fixes (Babu Moger) * Fix crash when enabling intel-pt on older machine types (Luwei Kang) * Add missing ARCH_CAPABILITIES bits to Icelake-Server CPU model (Xiaoyao Li) # gpg: Signature made Thu 02 Apr 2020 23:18:30 BST # gpg: using RSA key 5A322FD5ABC4D3DBACCFD1AA2807936F984DC5A6 # gpg: issuer "ehabkost@redhat.com" # gpg: Good signature from "Eduardo Habkost <ehabkost@redhat.com>" [full] # Primary key fingerprint: 5A32 2FD5 ABC4 D3DB ACCF D1AA 2807 936F 984D C5A6 * remotes/ehabkost/tags/x86-next-pull-request: target/i386: Add ARCH_CAPABILITIES related bits into Icelake-Server CPU model target/i386: set the CPUID level to 0x14 on old machine-type i386: Fix pkg_id offset for EPYC cpu models target/i386: Enable new apic id encoding for EPYC based cpus models hw/i386: Move arch_id decode inside x86_cpus_init i386: Introduce use_epyc_apic_id_encoding in X86CPUDefinition hw/i386: Introduce apicid functions inside X86MachineState target/i386: Cleanup and use the EPYC mode topology functions hw/386: Add EPYC mode topology decoding functions Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * | i386: Fix pkg_id offset for EPYC cpu modelsBabu Moger2020-04-011-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the system is numa configured the pkg_offset needs to be adjusted for EPYC cpu models. Fix it calling the model specific handler. Signed-off-by: Babu Moger <babu.moger@amd.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <158396725589.58170.16424607815207074485.stgit@naples-babu.amd.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
| * | hw/i386: Move arch_id decode inside x86_cpus_initBabu Moger2020-04-012-10/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Apicid calculation depends on knowing the total number of numa nodes for EPYC cpu models. Right now, we are calculating the arch_id while parsing the numa(parse_numa). At this time, it is not known how many total numa nodes are configured in the system. Move the arch_id calculation inside x86_cpus_init. At this time, smp parse is already completed and numa node information is available. Override the handlers if use_epyc_apic_id_encoding is enabled in cpu model definition. Also replace the calling convention to use handlers from X86MachineState. Signed-off-by: Babu Moger <babu.moger@amd.com> Message-Id: <158396724217.58170.12256158354204870716.stgit@naples-babu.amd.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
| * | hw/i386: Introduce apicid functions inside X86MachineStateBabu Moger2020-04-011-0/+5
| |/ | | | | | | | | | | | | | | | | | | | | Introduce model specific apicid functions inside X86MachineState. These functions will be loaded from X86CPUDefinition. Signed-off-by: Babu Moger <babu.moger@amd.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Message-Id: <158396722838.58170.5675998866484476427.stgit@naples-babu.amd.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
* | xen: fixup RAM memory region initializationIgor Mammedov2020-04-021-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since bd457782b3b0 ("x86/pc: use memdev for RAM") Xen machine fails to start with: qemu-system-i386: xen: failed to populate ram at 0 The reason is that xen_ram_alloc() which is called by memory_region_init_ram(), compares memory region with statically allocated 'global' ram_memory memory region that it uses for RAM, and does nothing in case it matches. While it's possible feed machine->ram to xen_ram_alloc() in the same manner to keep that hack working, I'd prefer not to keep that circular dependency and try to untangle that. However it doesn't look trivial to fix, so as temporary fixup opt out Xen machine from memdev based RAM allocation, and let xen_ram_alloc() do its trick for now. Reported-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20200402145418.5139-1-imammedo@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* | serial: Fix double migration dataDr. David Alan Gilbert2020-04-021-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After c9808d60281 we have both an object representing the serial-isa device and a separate object representing the underlying common serial uart. Both of these have vmsd's associated with them and thus the migration stream ends up with two copies of the migration data - the serial-isa includes the vmstate of the core serial. Besides being wrong, it breaks backwards migration compatibility. Fix this by removing the dc->vmsd from the core device, so it only gets migrated by any parent devices including it. Add a vmstate_serial_mm so that any device that uses serial_mm_init rather than creating a device still gets migrated. (That doesn't fix backwards migration for serial_mm_init users, but does seem to work forwards for ppce500). Fixes: c9808d60281 ('serial: realize the serial device') Buglink: https://bugs.launchpad.net/qemu/+bug/1869426 Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20200330164712.198282-1-dgilbert@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* | virtio-iommu: depend on PCIPaolo Bonzini2020-04-011-1/+1
| | | | | | | | | | | | | | | | | | The virtio-iommu device attaches itself to a PCI bus, so it makes no sense to include it unless PCI is supported---and in fact compilation fails without this change. Reported-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* | hw/isa/superio: Correct the license textPhilippe Mathieu-Daudé2020-04-012-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The license is the 'GNU General Public License v2.0 or later', not 'and': This program is free software; you can redistribute it and/ori modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. Fix the license comment. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20200312213712.16671-1-philmd@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* | hw/scsi/vmw_pvscsi: Remove assertion for kick after resetElazar Leibovich2020-04-011-1/+4
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When running Ubuntu 3.13.0-65-generic guest, QEMU sometimes crashes during guest ACPI reset. It crashes on assert(s->rings_info_valid) in pvscsi_process_io(). Analyzing the crash revealed that it happens when userspace issues a sync during a reboot syscall. Below are backtraces we gathered from the guests. Guest backtrace when issuing PVSCSI_CMD_ADAPTER_RESET: pci_device_shutdown device_shutdown init_pid_ns init_pid_ns kernel_power_off SYSC_reboot Guest backtrace when issuing PVSCSI_REG_OFFSET_KICK_RW_IO: scsi_done scsi_dispatch_cmd blk_add_timer scsi_request_fn elv_rb_add __blk_run_queue queue_unplugged blk_flush_plug_list blk_finish_plug ext4_writepages set_next_entity do_writepages __filemap_fdatawrite_range filemap_write_and_wait_range ext4_sync_file ext4_sync_file do_fsync sys_fsync Since QEMU pvscsi should imitate VMware pvscsi device emulation, we decided to imitate VMware's behavior in this case. To check VMware behavior, we wrote a kernel module that issues a reset to the pvscsi device and then issues a kick. We ran it on VMware ESXi 6.5 and it seems that it simply ignores the kick. Hence, we decided to ignore the kick as well. Signed-off-by: Elazar Leibovich <elazar.leibovich@oracle.com> Signed-off-by: Liran Alon <liran.alon@oracle.com> Message-Id: <20200315132634.113632-1-liran.alon@oracle.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
* Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into stagingPeter Maydell2020-03-3113-30/+85
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | virtio, pci, pc: bugfixes, checkpatch, maintainers Bugfixes all over the place. Add a new balloon maintainer. A checkpatch enhancement to enforce ACPI change rules. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # gpg: Signature made Tue 31 Mar 2020 15:54:36 BST # gpg: using RSA key 5D09FD0871C8F85B94CA8A0D281F0DB8D28D5469 # gpg: issuer "mst@redhat.com" # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [full] # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [full] # Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67 # Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469 * remotes/mst/tags/for_upstream: vhost-vsock: fix double close() in the realize() error path acpi: add acpi=OnOffAuto machine property to x86 and arm virt fix vhost_user_blk_watch crash hw/i386/amd_iommu.c: Fix corruption of log events passed to guest virtio-iommu: avoid memleak in the unrealize virtio-blk: delete vqs on the error path in realize() acpi: pcihp: fix left shift undefined behavior in acpi_pcihp_eject_slot() virtio-serial-bus: Plug memory leak on realize() error paths MAINTAINERS: Add myself as virtio-balloon co-maintainer checkpatch: enforce process for expected files Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
| * vhost-vsock: fix double close() in the realize() error pathStefano Garzarella2020-03-311-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | vhost_dev_cleanup() closes the vhostfd parameter passed to vhost_dev_init(), so this patch avoids closing it twice in the vhost_vsock_device_realize() error path. Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Message-Id: <20200331075910.42529-1-sgarzare@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
| * acpi: add acpi=OnOffAuto machine property to x86 and arm virtGerd Hoffmann2020-03-296-7/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove the global acpi_enabled bool and replace it with an acpi OnOffAuto machine property. qemu throws an error now if you use -no-acpi while the machine type you are using doesn't support acpi in the first place. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-Id: <20200320100136.11717-1-kraxel@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
| * fix vhost_user_blk_watch crashLi Feng2020-03-291-19/+0Star
| | | | | | | | | | | | | | | | | | | | | | the G_IO_HUP is watched in tcp_chr_connect, and the callback vhost_user_blk_watch is not needed, because tcp_chr_hup is registered as callback. And it will close the tcp link. Signed-off-by: Li Feng <fengli@smartx.com> Message-Id: <20200323052924.29286-1-fengli@smartx.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
| * hw/i386/amd_iommu.c: Fix corruption of log events passed to guestPeter Maydell2020-03-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the function amdvi_log_event(), we write an event log buffer entry into guest ram, whose contents are passed to the function via the "uint64_t *evt" argument. Unfortunately, a spurious '&' in the call to dma_memory_write() meant that instead of writing the event to the guest we would write the literal value of the pointer, plus whatever was in the following 8 bytes on the stack. This error was spotted by Coverity. Fix the bug by removing the '&'. Fixes: CID 1421945 Cc: qemu-stable@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20200326105349.24588-1-peter.maydell@linaro.org> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
| * virtio-iommu: avoid memleak in the unrealizePan Nengyuan2020-03-291-0/+3
| | | | | | | | | | | | | | | | | | | | | | req_vq/event_vq forgot to free in unrealize. Fix that. And also do clean 's->as_by_busptr' hash table in unrealize to fix another leak. Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Acked-by: Eric Auger <eric.auger@redhat.com> Message-Id: <20200328005705.29898-3-pannengyuan@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
| * virtio-blk: delete vqs on the error path in realize()Pan Nengyuan2020-03-291-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | virtio_vqs forgot to free on the error path in realize(). Fix that. The asan stack: Direct leak of 14336 byte(s) in 1 object(s) allocated from: #0 0x7f58b93fd970 in __interceptor_calloc (/lib64/libasan.so.5+0xef970) #1 0x7f58b858249d in g_malloc0 (/lib64/libglib-2.0.so.0+0x5249d) #2 0x5562cc627f49 in virtio_add_queue /mnt/sdb/qemu/hw/virtio/virtio.c:2413 #3 0x5562cc4b524a in virtio_blk_device_realize /mnt/sdb/qemu/hw/block/virtio-blk.c:1202 #4 0x5562cc613050 in virtio_device_realize /mnt/sdb/qemu/hw/virtio/virtio.c:3615 #5 0x5562ccb7a568 in device_set_realized /mnt/sdb/qemu/hw/core/qdev.c:891 #6 0x5562cd39cd45 in property_set_bool /mnt/sdb/qemu/qom/object.c:2238 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Pan Nengyuan <pannengyuan@huawei.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Message-Id: <20200328005705.29898-2-pannengyuan@huawei.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
| * acpi: pcihp: fix left shift undefined behavior in acpi_pcihp_eject_slot()Igor Mammedov2020-03-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Coverity spots subj in following guest triggered code path pci_write(, data = 0) -> acpi_pcihp_eject_slot(,slots = 0) uinst32_t slot = ctz32(slots) ... ... = ~(1U << slot) where 'slot' value is 32 in case 'slots' bitmap is empty. 'slots' is a bitmap and empty one shouldn't do anything so return early doing nothing if resulted slot value is not valid (i.e. not in 0-31 range) Reported-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20200326135624.32464-1-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2025-01-09 17:50:47 +0100