aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-04-09spapr_pci: Fix extended config space accessesGreg Kurz
The PAPR PHB acts as a legacy PCI bus but it allows PCIe extended config space accesses anyway (for pseries-2.9 and newer machine types). Introduce a specific PCI bus subtype to inform the common PCI code about that. Fixes: c2077e2ca0da7 Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <155414130834.574858.16502276132110219890.stgit@bahia.lan> [dwg: Apply fix so we don't rename the default pci bus, breaking everything] Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-04-09pci: Allow PCI bus subtypes to support extended config space accessesGreg Kurz
Some PHB implementations, eg. PAPR used on pseries machine, act like a regular PCI bus rather than a PCIe bus, but allow access to the PCIe extended config space anyway. Introduce a new PCI bus class method to modelize this behaviour and use it when adjusting the config space size limit during accesses. No behaviour change for existing PCI bus types. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <155414130271.574858.4253514266378127489.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-04-08Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into stagingPeter Maydell
Block layer patches: - hmp: Fix drive_add ... format=help crash - block: Forward 'discard' to temporary overlay # gpg: Signature made Mon 08 Apr 2019 16:43:20 BST # gpg: using RSA key 7F09B272C88F2FD6 # 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: hmp: Fix drive_add ... format=help crash block: Forward 'discard' to temporary overlay Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-04-08hmp: Fix drive_add ... format=help crashMarkus Armbruster
drive_new() returns null without setting an error when it provided help. add_init_drive() assumes null means failure, and crashes trying to report a null error. Fixes: c4f26c9f37ce511e5fe629c21c180dc6eb7c5a25 Cc: qemu-stable@nongnu.org Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-04-08block: Forward 'discard' to temporary overlayKevin Wolf
When bdrv_temp_snapshot_options() is called for snapshot=on, the 'discard' option in the options QDict hasn't been parsed and merged into the flags yet. So copy the dict entry to make sure that the temporary overlay enables discard when it was requested for the drive. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Alberto Garcia <berto@igalia.com>
2019-04-08Merge remote-tracking branch ↵Peter Maydell
'remotes/huth-gitlab/tags/pull-request-2019-04-08' into staging - Fix a crash in libqos with GCC 9 - Fix usage of wrong boolean types in libqos # gpg: Signature made Mon 08 Apr 2019 11:48:56 BST # gpg: using RSA key 2ED9D774FE702DB5 # gpg: Good signature from "Thomas Huth <th.huth@gmx.de>" [full] # gpg: aka "Thomas Huth <thuth@redhat.com>" [full] # gpg: aka "Thomas Huth <huth@tuxfamily.org>" [full] # gpg: aka "Thomas Huth <th.huth@posteo.de>" [unknown] # Primary key fingerprint: 27B8 8847 EEE0 2501 18F3 EAB9 2ED9 D774 FE70 2DB5 * remotes/huth-gitlab/tags/pull-request-2019-04-08: test qgraph.c: Fix segs due to out of scope default tests/libqos: fix usage of bool in pci-spapr.c tests/libqos: fix usage of bool in pci-pc.c Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-04-08test qgraph.c: Fix segs due to out of scope defaultDr. David Alan Gilbert
The test uses the trick: if (!opts) { opts = &(QOSGraph...Options) { }; } in a couple of places, however the temporary created by the &() {} goes out of scope at the bottom of the if, and results in a seg or assert when opts-> fields are used (on fedora 30's gcc 9). Fixes: fc281c802022cb3a73a5 Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20190405184037.16799-1-dgilbert@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2019-04-08tests/libqos: fix usage of bool in pci-spapr.cJafar Abdi
Clean up wrong usage of FALSE and TRUE in places that use "bool" from stdbool.h. FALSE and TRUE (with capital letters) are the constants defined by glib for being used with the "gboolean" type of glib. But some parts of the code also use TRUE and FALSE for variables that are declared as "bool" (the type from <stdbool.h>). Signed-off-by: Jafar Abdi <cafer.abdi@gmail.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <1553351197-14581-4-git-send-email-cafer.abdi@gmail.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2019-04-08tests/libqos: fix usage of bool in pci-pc.cJafar Abdi
Clean up wrong usage of FALSE and TRUE in places that use "bool" from stdbool.h. FALSE and TRUE (with capital letters) are the constants defined by glib for being used with the "gboolean" type of glib. But some parts of the code also use TRUE and FALSE for variables that are declared as "bool" (the type from <stdbool.h>). Signed-off-by: Jafar Abdi <cafer.abdi@gmail.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-Id: <1553351197-14581-3-git-send-email-cafer.abdi@gmail.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
2019-04-07Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into stagingPeter Maydell
pci, pc, virtio: fixes intel-iommu fixes virtio typo fixes linker: a couple of asserts for consistency/security Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # gpg: Signature made Tue 02 Apr 2019 16:51:19 BST # gpg: using RSA key 281F0DB8D28D5469 # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" [full] # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" [full] # Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67 # Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469 * remotes/mst/tags/for_upstream: intel_iommu: Drop extended root field intel_iommu: Fix root_scalable migration breakage virtio-net: Fix typo in comment intel_iommu: Correct caching-mode error message acpi: verify file entries in bios_linker_loader_add_pointer() Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-04-06Merge remote-tracking branch ↵Peter Maydell
'remotes/dgilbert/tags/pull-migration-20190405a' into staging Migration fixes pull for 4.0 A couple of fixes for crashes in colo and migration parameters. # gpg: Signature made Fri 05 Apr 2019 16:47:38 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-20190405a: migration: Fix migrate_set_parameter migration/ram.c: Fix codes conflict about bitmap_mutex Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-04-05migration: Fix migrate_set_parameterJuan Quintela
Otherwise we are setting err twice, what is wrong and causes an abort. Signed-off-by: Juan Quintela <quintela@redhat.com> Message-Id: <20190403114958.3705-2-quintela@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2019-04-05migration/ram.c: Fix codes conflict about bitmap_mutexZhang Chen
I found upstream codes conflict with COLO and lead to crash, and I located to this patch: commit 386a907b37a9321bc5d699bc37104d6ffba1b34d Author: Wei Wang <wei.w.wang@intel.com> Date: Tue Dec 11 16:24:49 2018 +0800 migration: use bitmap_mutex in migration_bitmap_clear_dirty My colleague Wei's patch add bitmap_mutex in migration_bitmap_clear_dirty, but COLO didn't initialize the bitmap_mutex. So we always get an error when COLO start up. like that: qemu-system-x86_64: util/qemu-thread-posix.c:64: qemu_mutex_lock_impl: Assertion `mutex->initialized' failed. This patch add the bitmap_mutex initialize and destroy in COLO lifecycle. Signed-off-by: Zhang Chen <chen.zhang@intel.com> Message-Id: <20190329222951.28945-1-chen.zhang@intel.com> Reviewed-by: Wei Wang <wei.w.wang@intel.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2019-04-05Merge remote-tracking branch ↵Peter Maydell
'remotes/palmer/tags/riscv-for-master-4.0-rc3-v2' into staging RISC-V Patches for 4.0-rc3, v2 This patch set contains a pair of tightly coupled PLIC bug fixes: * We were calculating the PLIC addresses incorrectly. * We were installing the wrong number of PLIC interrupts. The two bugs togther resulted in a mostly-working system, but they're impossible to seperate because fixing one bug would result in significant breakage. As a result they're in the same patch. There is also a cleanup to use qemu_log_mask(LOG_GUEST_ERROR,...) for error reporting. As far as I know these are the last outstanding RISC-V patches for 4.0. v2 no longer fails "make check" for me... sorry! # gpg: Signature made Fri 05 Apr 2019 01:33:57 BST # gpg: using RSA key 00CE76D1834960DFCE886DF8EF4CA1502CCBAB41 # gpg: issuer "palmer@dabbelt.com" # gpg: Good signature from "Palmer Dabbelt <palmer@dabbelt.com>" [unknown] # gpg: aka "Palmer Dabbelt <palmer@sifive.com>" [unknown] # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 00CE 76D1 8349 60DF CE88 6DF8 EF4C A150 2CCB AB41 * remotes/palmer/tags/riscv-for-master-4.0-rc3-v2: riscv: plic: Log guest errors riscv: plic: Fix incorrect irq calculation Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-04-05Merge remote-tracking branch 'remotes/aperard/tags/pull-xen-20190404' into ↵Peter Maydell
staging Xen queue xen-block fixes # gpg: Signature made Thu 04 Apr 2019 18:04:38 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-20190404: xen-block: scale sector based quantities correctly xen-block: only advertize discard to the frontend when it is enabled... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-04-04riscv: plic: Log guest errorsAlistair Francis
Instead of using error_report() to print guest errors let's use qemu_log_mask(LOG_GUEST_ERROR,...) to log the error. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-04-04riscv: plic: Fix incorrect irq calculationAlistair Francis
This patch fixes four different things, to maintain bisectability they have been merged into a single patch. The following fixes are below: sifive_plic: Fix incorrect irq calculation The irq is incorrectly calculated to be off by one. It has worked in the past as the priority_base offset has also been set incorrectly. We are about to fix the priority_base offset so first first the irq calculation. sifive_u: Fix PLIC priority base offset and numbering According to the FU540 manual the PLIC source priority address starts at an offset of 0x04 and not 0x00. The same manual also specifies that the PLIC only has 53 source priorities. Fix these two incorrect header files. We also need to over extend the plic_gpios[] array as the PLIC sources count from 1 and not 0. riscv: sifive_e: Fix PLIC priority base offset According to the FE31 manual the PLIC source priority address starts at an offset of 0x04 and not 0x00. riscv: virt: Fix PLIC priority base offset Update the virt offsets based on the newly updated SiFive U and SiFive E offsets. Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2019-04-04xen-block: scale sector based quantities correctlyPaul Durrant
The Xen blkif protocol requires that sector based quantities should be interpreted strictly as multiples of 512 bytes. Specifically: "first_sect and last_sect in blkif_request_segment, as well as sector_number in blkif_request, are always expressed in 512-byte units." Commit fcab2b464e06 "xen: add header and build dataplane/xen-block.c" incorrectly modified behaviour to use the block device logical_block_size property as the scale, instead of correctly shifting values by the hardcoded BDRV_SECTOR_BITS (and hence scaling them to 512 byte units). This patch undoes that change and restores compliance with the spec. Furthermore, this patch also restores the original xen_disk behaviour of advertizing a hardcoded 'sector-size' value of 512 in xenstore and scaling 'sectors' accordingly. The realize() method is also modified to fail if logical_block_size is set to anything other than 512. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20190401121719.27208-1-paul.durrant@citrix.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2019-04-04xen-block: only advertize discard to the frontend when it is enabled...Paul Durrant
...and properly enable it when synthesizing a drive. The Xen toolstack sets 'discard-enable' to '1' in xenstore when it wants to enable discard on a specified image. The code in xen_block_drive_create() correctly parses this and uses it to set 'discard' to 'unmap' for the file_layer, but fails to do the same for the driver_layer (which effectively disables it). Meanwhile the code in xen_block_realize() advertizes discard support to the frontend in the default case (because conf->discard_granularity defaults to -1), even when the underlying image may not handle it. This patch adds the missing option to the driver_layer in xen_block_driver_create() and checks whether BDRV_O_UNMAP is actually set on the block device before advertizing discard to the frontend. In the case that discard is supported it also makes sure that the granularity is set to the physical block size. Signed-off-by: Paul Durrant <paul.durrant@citrix.com> Reviewed-by: Anthony PERARD <anthony.perard@citrix.com> Message-Id: <20190320142825.24565-1-paul.durrant@citrix.com> Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
2019-04-03Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20190403' into stagingPeter Maydell
Fix taking address of fields in packed structs warnings by gcc 9 # gpg: Signature made Wed 03 Apr 2019 10:58:42 BST # gpg: using RSA key C3D0D66DC3624FF6A8C018CEDECF6B93C6F02FAF # gpg: issuer "cohuck@redhat.com" # gpg: Good signature from "Cornelia Huck <conny@cornelia-huck.de>" [unknown] # 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>" [unknown] # gpg: aka "Cornelia Huck <cohuck@redhat.com>" [unknown] # Primary key fingerprint: C3D0 D66D C362 4FF6 A8C0 18CE DECF 6B93 C6F0 2FAF * remotes/cohuck/tags/s390x-20190403: hw/s390x/3270-ccw: avoid taking address of fields in packed struct hw/s390x/ipl: avoid taking address of fields in packed struct hw/s390/css: avoid taking address members in packed structs hw/vfio/ccw: avoid taking address members in packed structs Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-04-03hw/s390x/3270-ccw: avoid taking address of fields in packed structDaniel P. Berrangé
Compiling with GCC 9 complains hw/s390x/3270-ccw.c: In function ‘emulated_ccw_3270_cb’: hw/s390x/3270-ccw.c:81:19: error: taking address of packed member of ‘struct SCHIB’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 81 | SCSW *s = &sch->curr_status.scsw; | ^~~~~~~~~~~~~~~~~~~~~~ This local variable is only present to save a little bit of typing when setting the field later. Get rid of this to avoid the warning about unaligned accesses. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20190329111104.17223-15-berrange@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-04-03hw/s390x/ipl: avoid taking address of fields in packed structDaniel P. Berrangé
Compiling with GCC 9 complains hw/s390x/ipl.c: In function ‘s390_ipl_set_boot_menu’: hw/s390x/ipl.c:256:25: warning: taking address of packed member of ‘struct QemuIplParameters’ may result in an unaligned pointer value [-Waddress-of-packed-member] 256 | uint32_t *timeout = &ipl->qipl.boot_menu_timeout; | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ This local variable is only present to save a little bit of typing when setting the field later. Get rid of this to avoid the warning about unaligned accesses. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20190329111104.17223-14-berrange@redhat.com> Reviewed-by: David Hildenbrand <david@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Farhan Ali <alifm@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-04-03hw/s390/css: avoid taking address members in packed structsDaniel P. Berrangé
The GCC 9 compiler complains about many places in s390 code that take the address of members of the 'struct SCHIB' which is marked packed: hw/s390x/css.c: In function ‘sch_handle_clear_func’: hw/s390x/css.c:698:15: warning: taking address of packed member of ‘struct SCHIB’ may result in an unaligned pointer val\ ue [-Waddress-of-packed-member] 698 | PMCW *p = &sch->curr_status.pmcw; | ^~~~~~~~~~~~~~~~~~~~~~ hw/s390x/css.c:699:15: warning: taking address of packed member of ‘struct SCHIB’ may result in an unaligned pointer val\ ue [-Waddress-of-packed-member] 699 | SCSW *s = &sch->curr_status.scsw; | ^~~~~~~~~~~~~~~~~~~~~~ ...snip many more... Almost all of these are just done for convenience to avoid typing out long variable/field names when referencing struct members. We can get most of this convenience by taking the address of the 'struct SCHIB' instead, avoiding triggering the compiler warnings. In a couple of places we copy via a local variable which is a technique already applied elsewhere in s390 code for this problem. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20190329111104.17223-13-berrange@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-04-03hw/vfio/ccw: avoid taking address members in packed structsDaniel P. Berrangé
The GCC 9 compiler complains about many places in s390 code that take the address of members of the 'struct SCHIB' which is marked packed: hw/vfio/ccw.c: In function ‘vfio_ccw_io_notifier_handler’: hw/vfio/ccw.c:133:15: warning: taking address of packed member of ‘struct SCHIB’ may result in an unaligned pointer value \ [-Waddress-of-packed-member] 133 | SCSW *s = &sch->curr_status.scsw; | ^~~~~~~~~~~~~~~~~~~~~~ hw/vfio/ccw.c:134:15: warning: taking address of packed member of ‘struct SCHIB’ may result in an unaligned pointer value \ [-Waddress-of-packed-member] 134 | PMCW *p = &sch->curr_status.pmcw; | ^~~~~~~~~~~~~~~~~~~~~~ ...snip many more... Almost all of these are just done for convenience to avoid typing out long variable/field names when referencing struct members. We can get most of this convenience by taking the address of the 'struct SCHIB' instead, avoiding triggering the compiler warnings. In a couple of places we copy via a local variable which is a technique already applied elsewhere in s390 code for this problem. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20190329111104.17223-12-berrange@redhat.com> Reviewed-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Halil Pasic <pasic@linux.ibm.com> Reviewed-by: Farhan Ali <alifm@linux.ibm.com> Signed-off-by: Cornelia Huck <cohuck@redhat.com>
2019-04-02Update version for v4.0.0-rc2 releasev4.0.0-rc2Peter Maydell
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-04-02intel_iommu: Drop extended root fieldPeter Xu
VTD_RTADDR_RTT is dropped even by the VT-d spec, so QEMU should probably do the same thing (after all we never really implemented it). Since we've had a field for that in the migration stream, to keep compatibility we need to fill the hole up. Please refer to VT-d spec 10.4.6. Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20190329061422.7926-3-peterx@redhat.com> Reviewed-by: Liu, Yi L <yi.l.liu@intel.com> Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-04-02intel_iommu: Fix root_scalable migration breakagePeter Xu
When introducing the initial support for scalable mode we added a new field into vmstate however we blindly migrate that field without notice. That'll break migration no matter forward or backward. The normal way should be that we use something like VMSTATE_UINT32_TEST() or subsections for the new vmstate field however for this case of vt-d we can even make it simpler because we've already migrated all the registers and it'll be fairly simple that we re-generate root_scalable field from the register values during post load of the device. Fixes: fb43cf739e ("intel_iommu: scalable mode emulation") Reviewed-by: Yi Sun <yi.y.sun@linux.intel.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <20190329061422.7926-2-peterx@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-04-02virtio-net: Fix typo in commentYuval Shaia
Signed-off-by: Yuval Shaia <yuval.shaia@oracle.com> Message-Id: <20190321161832.10533-1-yuval.shaia@oracle.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-04-02intel_iommu: Correct caching-mode error messageAlex Williamson
If we try to use the intel-iommu device with vfio-pci devices without caching mode enabled, we're told: qemu-system-x86_64: We need to set caching-mode=1 for intel-iommu to enable device assignment with IOMMU protection. But to enable caching mode, the option is actually "caching-mode=on". Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Message-Id: <155364147432.16467.15898335025013220939.stgit@gimli.home> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Alex Williamson &lt;<a href="mailto:alex.williamson@redhat.com" target="_blank" rel="noreferrer">alex.williamson@redhat.com</a>&gt;<br> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-04-02acpi: verify file entries in bios_linker_loader_add_pointer()Liam Merwick
The callers to bios_linker_find_file() assert that the file entry returned is not NULL, except for those in bios_linker_loader_add_pointer(). Add two asserts in that case for completeness and to facilitate static code analysis. Signed-off-by: Liam Merwick <liam.merwick@oracle.com> Message-Id: <1553199229-25318-1-git-send-email-liam.merwick@oracle.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-04-02Merge remote-tracking branch 'remotes/armbru/tags/pull-misc-2019-04-02' into ↵Peter Maydell
staging Miscellaneous patches for 2019-04-02 # gpg: Signature made Tue 02 Apr 2019 12:54:27 BST # gpg: using RSA key 3870B400EB918653 # gpg: Good signature from "Markus Armbruster <armbru@redhat.com>" [full] # gpg: aka "Markus Armbruster <armbru@pond.sub.org>" [full] # Primary key fingerprint: 354B C8B3 D7EB 2A6B 6867 4E5F 3870 B400 EB91 8653 * remotes/armbru/tags/pull-misc-2019-04-02: accel: Unbreak accelerator fallback vl: Document dependencies hiding in global and compat props migration: Support adding migration blockers earlier Revert "migration: move only_migratable to MigrationState" Revert "vl: Fix to create migration object before block backends again" qapi/migration.json: Rename COLOStatus last_mode to last-mode qapi/migration.json: Fix ColoStatus member last_mode's version vl: Fix error location of positional arguments Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-04-02Merge remote-tracking branch ↵Peter Maydell
'remotes/berrange/tags/filemon-next-pull-request' into staging filemon: various fixes / improvements to file monitor for USB MTP Ensure watch IDs unique within a monitor and avoid integer wraparound issues when many watches are set & unset over time. # gpg: Signature made Tue 02 Apr 2019 13:53:40 BST # gpg: using RSA key BE86EBB415104FDF # gpg: Good signature from "Daniel P. Berrange <dan@berrange.com>" [full] # gpg: aka "Daniel P. Berrange <berrange@redhat.com>" [full] # Primary key fingerprint: DAF3 A6FD B26B 6291 2D0E 8E3F BE86 EBB4 1510 4FDF * remotes/berrange/tags/filemon-next-pull-request: filemon: fix watch IDs to avoid potential wraparound issues filemon: ensure watch IDs are unique to QFileMonitor scope tests: refactor file monitor test to make it more understandable Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-04-02Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into stagingPeter Maydell
Block layer patches: - file-posix: Ignore unlock failure instead of crashing - gluster: Limit the transfer size to 512 MiB - stream: Fix backing chain freezing - qemu-img: Enable BDRV_REQ_MAY_UNMAP for zero writes in convert - iotests fixes # gpg: Signature made Tue 02 Apr 2019 13:47:43 BST # gpg: using RSA key 7F09B272C88F2FD6 # 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: tests/qemu-iotests/235: Allow fallback to tcg block: test block-stream with a base node that is used by block-commit block: freeze the backing chain earlier in stream_start() block: continue until base is found in bdrv_freeze_backing_chain() et al block/file-posix: do not fail on unlock bytes tests/qemu-iotests: Remove redundant COPYING file block/gluster: limit the transfer size to 512 MiB qemu-img: Enable BDRV_REQ_MAY_UNMAP in convert iotests: Fix test 200 on s390x without virtio-pci Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-04-02filemon: fix watch IDs to avoid potential wraparound issuesDaniel P. Berrangé
Watch IDs are allocated from incrementing a int counter against the QFileMonitor object. In very long life QEMU processes with a huge amount of USB MTP activity creating & deleting directories it is just about conceivable that the int counter can wrap around. This would result in incorrect behaviour of the file monitor watch APIs due to clashing watch IDs. Instead of trying to detect this situation, this patch changes the way watch IDs are allocated. It is turned into an int64_t variable where the high 32 bits are set from the underlying inotify "int" ID. This gives an ID that is guaranteed unique for the directory as a whole, and we can rely on the kernel to enforce this. QFileMonitor then sets the low 32 bits from a per-directory counter. The USB MTP device only sets watches on the directory as a whole, not files within, so there is no risk of guest triggered wrap around on the low 32 bits. Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-02filemon: ensure watch IDs are unique to QFileMonitor scopeDaniel P. Berrangé
The watch IDs are mistakenly only unique within the scope of the directory being monitored. This is not useful for clients which are monitoring multiple directories. They require watch IDs to be unique globally within the QFileMonitor scope. Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Tested-by: Bandan Das <bsd@redhat.com> Reviewed-by: Bandan Das <bsd@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-02tests: refactor file monitor test to make it more understandableDaniel P. Berrangé
The current file monitor unit tests are too clever for their own good making it hard to understand the desired output. Instead of trying to infer the expected events, explicitly list the events we expect in the operation sequence. Instead of dynamically building a matrix of tests, just have one giant operation sequence that validates all scenarios in a single test. Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-04-02accel: Unbreak accelerator fallbackMarkus Armbruster
When the user specifies a list of accelerators, we pick the first one that initializes successfully. Recent commit 1a3ec8c1564 broke that. Reproducer: $ qemu-system-x86_64 --machine accel=xen:tcg xencall: error: Could not obtain handle on privileged command interface: No such file or directory xen be core: xen be core: can't open xen interface can't open xen interface qemu-system-x86_64: failed to initialize Xen: Operation not permitted qemu-system-x86_64: /home/armbru/work/qemu/qom/object.c:436: object_set_accelerator_compat_props: Assertion `!object_compat_props[0]' failed. Root cause: we register accelerator compat properties even when the accelerator fails. The failed assertion is object_set_accelerator_compat_props() telling us off. Fix by calling it only for the accelerator that succeeded. Fixes: 1a3ec8c1564f51628cce10d435a2e22559ea29fd Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20190401090827.20793-6-armbru@redhat.com>
2019-04-02vl: Document dependencies hiding in global and compat propsMarkus Armbruster
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190401090827.20793-5-armbru@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
2019-04-02migration: Support adding migration blockers earlierMarkus Armbruster
migrate_add_blocker() asserts we have a current_migration object, in migrate_get_current(). We do only after migration_object_init(). This contributes to the following dependency cycle: * configure_blockdev() must run before machine_set_property() so machine properties can refer to block backends * machine_set_property() before configure_accelerator() so machine properties like kvm-irqchip get applied * configure_accelerator() before migration_object_init() so that Xen's accelerator compat properties get applied. * migration_object_init() before configure_blockdev() so configure_blockdev() can add migration blockers The cycle was closed when recent commit cda4aa9a5a0 "Create block backends before setting machine properties" added the first dependency, and satisfied it by violating the last one. Broke block backends that add migration blockers, as demonstrated by qemu-iotests 055. To fix it, break the last dependency: make migrate_add_blocker() usable before migration_object_init(). The previous commit already removed the use of migrate_get_current() from migrate_add_blocker() itself. Didn't quite do the trick, as there's another one hiding in migration_is_idle(). The use there isn't actually necessary: when no migration object has been created yet, migration is surely idle. Make migration_is_idle() return true then. Fixes: cda4aa9a5a08777cf13e164c0543bd4888b8adce Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190401090827.20793-4-armbru@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
2019-04-02Revert "migration: move only_migratable to MigrationState"Markus Armbruster
This reverts commit 3df663e575f1876d7f3bc684f80e72fca0703d39. This reverts commit b605c47b57b58e61a901a50a0762dccf43d94783. Command line option --only-migratable is for disallowing any configuration that can block migration. Initially, --only-migratable set global variable @only_migratable. Commit 3df663e575 "migration: move only_migratable to MigrationState" replaced it by MigrationState member @only_migratable. That was a mistake. First, it doesn't make sense on the design level. MigrationState captures the state of an individual migration, but --only-migratable isn't a property of an individual migration, it's a restriction on QEMU configuration. With fault tolerance, we could have several migrations at once. --only-migratable would certainly protect all of them. Storing it in MigrationState feels inappropriate. Second, it contributes to a dependency cycle that manifests itself as a bug now. Putting @only_migratable into MigrationState means its available only after migration_object_init(). We can't set it before migration_object_init(), so we delay setting it with a global property (this is fixup commit b605c47b57 "migration: fix handling for --only-migratable"). We can't get it before migration_object_init(), so anything that uses it can only run afterwards. Since migrate_add_blocker() needs to obey --only-migratable, any code adding migration blockers can run only afterwards. This contributes to the following dependency cycle: * configure_blockdev() must run before machine_set_property() so machine properties can refer to block backends * machine_set_property() before configure_accelerator() so machine properties like kvm-irqchip get applied * configure_accelerator() before migration_object_init() so that Xen's accelerator compat properties get applied. * migration_object_init() before configure_blockdev() so configure_blockdev() can add migration blockers The cycle was closed when recent commit cda4aa9a5a0 "Create block backends before setting machine properties" added the first dependency, and satisfied it by violating the last one. Broke block backends that add migration blockers. Moving @only_migratable into MigrationState was a mistake. Revert it. This doesn't quite break the "migration_object_init() before configure_blockdev() dependency, since migrate_add_blocker() still has another dependency on migration_object_init(). To be addressed the next commit. Note that the reverted commit made -only-migratable sugar for -global migration.only-migratable=on below the hood. Documentation has only ever mentioned -only-migratable. This commit removes the arcane & undocumented alternative to -only-migratable again. Nobody should be using it. Conflicts: include/migration/misc.h migration/migration.c migration/migration.h vl.c Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190401090827.20793-3-armbru@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
2019-04-02Revert "vl: Fix to create migration object before block backends again"Markus Armbruster
This reverts commit e60483f2f8498ae08ae79ca4c6fb03a3317f5e1e. Recent commit cda4aa9a5a0 moved block backend creation before machine property evaluation. This broke block backends registering migration blockers. Commit e60483f2f84 fixed it by moving migration object creation before block backend creation. This broke migration with Xen. Turns out we need to configure the accelerator before we create the migration object so that Xen's accelerator compat properties get applied. Revert the flawed commit. This fixes the Xen regression, but brings back the block backend regression. The next commits will fix it again. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190401090827.20793-2-armbru@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com>
2019-04-02qapi/migration.json: Rename COLOStatus last_mode to last-modeZhang Chen
Signed-off-by: Zhang Chen <chen.zhang@intel.com> Message-Id: <20190402085521.17973-1-chen.zhang@intel.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [Commit message rephrased] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2019-04-02qapi/migration.json: Fix ColoStatus member last_mode's versionZhang Chen
Signed-off-by: Zhang Chen <chen.zhang@intel.com> Message-Id: <20190326174510.13303-1-chen.zhang@intel.com> Reviewed-by: Eric Blake <eblake@redhat.com> [Commit message tweaked as per Eric's review] Signed-off-by: Markus Armbruster <armbru@redhat.com>
2019-04-02vl: Fix error location of positional argumentsMarkus Armbruster
We blame badness in positional arguments on the last option argument: $ qemu-system-x86_64 -vnc :1 bad.img qemu-system-x86_64: -vnc :1: Could not open 'foo': No such file or directory I believe we've done this ever since we reported locations. Fix it to qemu-system-x86_64: bad.img: Could not open 'bad.img': No such file or directory Reported-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190318183312.4684-1-armbru@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
2019-04-02tests/qemu-iotests/235: Allow fallback to tcgThomas Huth
iotest 235 currently only works with KVM - this is bad for systems where it is not available, e.g. CI pipelines. The test also works when using "tcg" as accelerator, so we can simply add that to the list of accelerators, too. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-04-02block: test block-stream with a base node that is used by block-commitAlberto Garcia
The base node of a block-stream operation indicates the first image from the backing chain starting from which no data is copied to the top node. The block-stream job allows others to use that base image, so a second block-stream job could be writing to it at the same time. An important restriction is that the base image must not disappear while the stream job is ongoing. stream_start() freezes the backing chain from top to base with that purpose but it does it too late in the code so there is a race condition there. This bug was fixed in the previous commit, and this patch contains an iotest for this scenario. Signed-off-by: Alberto Garcia <berto@igalia.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-04-02block: freeze the backing chain earlier in stream_start()Alberto Garcia
Commit 6585493369819a48d34a86d57ec6b97cb5cd9bc0 added code to freeze the backing chain from 'top' to 'base' for the duration of the block-stream job. The problem is that the freezing happens too late in stream_start(): during the bdrv_reopen_set_read_only() call earlier in that function another job can jump in and remove the base image. If that happens we have an invalid chain and QEMU crashes. This patch puts the bdrv_freeze_backing_chain() call at the beginning of the function. Signed-off-by: Alberto Garcia <berto@igalia.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-04-02block: continue until base is found in bdrv_freeze_backing_chain() et alAlberto Garcia
All three functions that handle the BdrvChild.frozen attribute walk the backing chain from 'bs' to 'base' and stop either when 'base' is found or at the end of the chain if 'base' is NULL. However if 'base' is not found then the functions return without errors as if it was NULL. This is wrong: if the caller passed an incorrect parameter that means that there is a bug in the code. Signed-off-by: Alberto Garcia <berto@igalia.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-04-02block/file-posix: do not fail on unlock bytesVladimir Sementsov-Ogievskiy
bdrv_replace_child() calls bdrv_check_perm() with error_abort on loosening permissions. However file-locking operations may fail even in this case, for example on NFS. And this leads to Qemu crash. Let's avoid such errors. Note, that we ignore such things anyway on permission update commit and abort. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2019-04-02tests/qemu-iotests: Remove redundant COPYING fileThomas Huth
The file tests/qemu-iotests/COPYING is the same text as in the COPYING file in the main directory. So as far as I can see, we don't need the duplicate here. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
generated by cgit v1.2.3 (git 2.26.2) at 2025-01-06 17:19:32 +0000