aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-08-16Clean up inclusion of exec/cpu-common.hMarkus Armbruster
migration/qemu-file.h neglects to include it even though it needs ram_addr_t. Fix that. Drop a few superfluous inclusions elsewhere. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190812052359.30071-14-armbru@redhat.com>
2019-08-16Include hw/irq.h a lot lessMarkus Armbruster
In my "build everything" tree, changing hw/irq.h triggers a recompile of some 5400 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). hw/hw.h supposedly includes it for convenience. Several other headers include it just to get qemu_irq and.or qemu_irq_handler. Move the qemu_irq and qemu_irq_handler typedefs from hw/irq.h to qemu/typedefs.h, and then include hw/irq.h only where it's still needed. Touching it now recompiles only some 500 objects. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190812052359.30071-13-armbru@redhat.com>
2019-08-16typedefs: Separate incomplete types and function typesMarkus Armbruster
While there, rewrite the obsolete file comment. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190812052359.30071-12-armbru@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> [File comment rewritten, commit message adjusted]
2019-08-16ide: Include hw/ide/internal a bit less outside hw/ide/Markus Armbruster
According to hw/ide/internal's file comment, only files in hw/ide/ are supposed to include it. Drag reality slightly closer to supposition. Three includes outside hw/ide remain: hw/arm/sbsa-ref.c, include/hw/ide/pci.h, and include/hw/misc/macio/macio.h. Turns out board code needs ide-internal.h to wire up IDE stuff. More cleanup is needed. Left for another day. Cc: John Snow <jsnow@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190812052359.30071-11-armbru@redhat.com>
2019-08-16Include migration/qemu-file-types.h a lot lessMarkus Armbruster
In my "build everything" tree, changing migration/qemu-file-types.h triggers a recompile of some 2600 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). The culprit is again hw/hw.h, which supposedly includes it for convenience. Include migration/qemu-file-types.h only where it's needed. Touching it now recompiles less than 200 objects. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190812052359.30071-10-armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-08-16Include sysemu/reset.h a lot lessMarkus Armbruster
In my "build everything" tree, changing sysemu/reset.h triggers a recompile of some 2600 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). The main culprit is hw/hw.h, which supposedly includes it for convenience. Include sysemu/reset.h only where it's needed. Touching it now recompiles less than 200 objects. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190812052359.30071-9-armbru@redhat.com>
2019-08-16trace: Do not include qom/cpu.h into generated trace.hMarkus Armbruster
docs/devel/tracing.txt explains "since many source files include trace.h, [the generated trace.h use] a minimum of types and other header files included to keep the namespace clean and compile times and dependencies down." Commit 4815185902 "trace: Add per-vCPU tracing states for events with the 'vcpu' property" made them all include qom/cpu.h via control-internal.h. qom/cpu.h in turn includes about thirty headers. Ouch. Per-vCPU tracing is currently not supported in sub-directories' trace-events. In other words, qom/cpu.h can only be used in trace-root.h, not in any trace.h. Split trace/control-vcpu.h off trace/control.h and trace/control-internal.h. Have the generated trace.h include trace/control.h (which no longer includes qom/cpu.h), and trace-root.h include trace/control-vcpu.h (which includes it). The resulting improvement is a bit disappointing: in my "build everything" tree, some 1100 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h) depend on a trace.h, and about 600 of them no longer depend on qom/cpu.h. But more than 1300 others depend on trace-root.h. More work is clearly needed. Left for another day. Cc: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190812052359.30071-8-armbru@redhat.com>
2019-08-16trace: Eliminate use of TARGET_FMT_plxMarkus Armbruster
hw/tpm/trace-events uses TARGET_FMT_plx formats with uint64_t arguments. That's wrong, TARGET_FMT_plx takes hwaddr. Since hwaddr happens to be uint64_t, it works anyway. Messed up in commit ec427498da5, v2.12.0. Clean up by replacing TARGET_FMT_plx with its macro expansion. scripts/tracetool/format/log_stap.py (commit 62dd1048c0b, v4.0.0) has a special case for TARGET_FMT_plx. Delete it. Cc: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Message-Id: <20190812052359.30071-7-armbru@redhat.com>
2019-08-16queue: Drop superfluous #include qemu/atomic.hMarkus Armbruster
When commit 5f7d05ecfda added QLIST_INSERT_HEAD_RCU() to qemu/queue.h, it had to include qemu/atomic.h. Commit 341774fe6cc removed QLIST_INSERT_HEAD_RCU() again, but neglected to remove the #include. Do that now. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-Id: <20190812052359.30071-6-armbru@redhat.com>
2019-08-16memory: Fix type of IOMMUMemoryRegionClass member @parent_classMarkus Armbruster
TYPE_IOMMU_MEMORY_REGION is a direct subtype of TYPE_MEMORY_REGION. Its instance struct is IOMMUMemoryRegion, and its first member is a MemoryRegion. Correct. Its class struct is IOMMUMemoryRegionClass, and its first member is a DeviceClass. Wrong. Messed up when commit 1221a474676 introduced the QOM type. It even included hw/qdev-core.h just for that. TYPE_MEMORY_REGION doesn't bother to define a class struct. This is fine, it simply defaults to its super-type TYPE_OBJECT's class struct ObjectClass. Changing IOMMUMemoryRegionClass's first member's type to ObjectClass would be a minimal fix, if a bit brittle: if TYPE_MEMORY_REGION ever acquired own class struct, we'd have to update IOMMUMemoryRegionClass to use it. Fix it the clean and robust way instead: give TYPE_MEMORY_REGION its own class struct MemoryRegionClass now, and use it for IOMMUMemoryRegionClass's first member. Revert the include of hw/qdev-core.h, and fix the few files that have come to rely on it. Cc: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20190812052359.30071-5-armbru@redhat.com>
2019-08-16qapi: Split error.json off common.jsonMarkus Armbruster
In my "build everything" tree, changing a type in qapi/common.json triggers a recompile of some 3600 out of 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h). One common dependency is QapiErrorClass: it's used only in in qapi/error.h, which uses nothing else, and is widely included. Move QapiErrorClass from common.json to new error.json. Touching common.json now recompiles only some 2900 objects. Cc: Eric Blake <eblake@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190812052359.30071-4-armbru@redhat.com>
2019-08-16Include generated QAPI headers lessMarkus Armbruster
Some of the generated qapi-types-MODULE.h are included all over the place. Changing a QAPI type can trigger massive recompiling. Top scorers recompile more than 1000 out of some 6600 objects (not counting tests and objects that don't depend on qemu/osdep.h): 6300 qapi/qapi-builtin-types.h 5700 qapi/qapi-types-run-state.h 3900 qapi/qapi-types-common.h 3300 qapi/qapi-types-sockets.h 3000 qapi/qapi-types-misc.h 3000 qapi/qapi-types-crypto.h 3000 qapi/qapi-types-job.h 3000 qapi/qapi-types-block-core.h 2800 qapi/qapi-types-block.h 1300 qapi/qapi-types-net.h Clean up headers to include generated QAPI headers only where needed. Impact is negligible except for hw/qdev-properties.h. This header includes qapi/qapi-types-block.h and qapi/qapi-types-misc.h. They are used only in expansions of property definition macros such as DEFINE_PROP_BLOCKDEV_ON_ERROR() and DEFINE_PROP_OFF_AUTO(). Moving their inclusion from hw/qdev-properties.h to the users of these macros avoids pointless recompiles. This is how other property definition macros, such as DEFINE_PROP_NETDEV(), already work. Improves things for some of the top scorers: 3600 qapi/qapi-types-common.h 2800 qapi/qapi-types-sockets.h 900 qapi/qapi-types-misc.h 2200 qapi/qapi-types-crypto.h 2100 qapi/qapi-types-job.h 2100 qapi/qapi-types-block-core.h 270 qapi/qapi-types-block.h Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190812052359.30071-3-armbru@redhat.com>
2019-08-16include: Make headers more self-containedMarkus Armbruster
Back in 2016, we discussed[1] rules for headers, and these were generally liked: 1. Have a carefully curated header that's included everywhere first. We got that already thanks to Peter: osdep.h. 2. Headers should normally include everything they need beyond osdep.h. If exceptions are needed for some reason, they must be documented in the header. If all that's needed from a header is typedefs, put those into qemu/typedefs.h instead of including the header. 3. Cyclic inclusion is forbidden. This patch gets include/ closer to obeying 2. It's actually extracted from my "[RFC] Baby steps towards saner headers" series[2], which demonstrates a possible path towards checking 2 automatically. It passes the RFC test there. [1] Message-ID: <87h9g8j57d.fsf@blackfin.pond.sub.org> https://lists.nongnu.org/archive/html/qemu-devel/2016-03/msg03345.html [2] Message-Id: <20190711122827.18970-1-armbru@redhat.com> https://lists.nongnu.org/archive/html/qemu-devel/2019-07/msg02715.html Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20190812052359.30071-2-armbru@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-08-15Open 4.2 development treePeter Maydell
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-08-15Update version for v4.1.0 releasev4.1.0Peter Maydell
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-08-13Update version for v4.1.0-rc5 releasev4.1.0-rc5Peter Maydell
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-08-13riscv: roms: Fix make rules for building sifive_u biosBin Meng
Currently the make rules are wrongly using qemu/virt opensbi image for sifive_u machine. Correct it. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Chih-Min Chao <chihmin.chao@sifive.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 1564812484-20385-1-git-send-email-bmeng.cn@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-08-13Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-4.1-20190813' ↵Peter Maydell
into staging ppc patch queue 2019-08-13 (last minute qemu-4.1 fixes) Here's a very, very last minute pull request for qemu-4.1. This fixes two nasty bugs with the XIVE interrupt controller in "dual" mode (where the guest decides which interrupt controller it wants to use). One occurs when resetting the guest while I/O is active, and the other with migration of hotplugged CPUs. The timing here is very unfortunate. Alas, we only spotted these bugs very late, and I was sick last week, delaying analysis and fix even further. This series hasn't had nearly as much testing as I'd really like, but I'd still like to squeeze it into qemu-4.1 if possible, since definitely fixing two bad bugs seems like an acceptable tradeoff for the risk of introducing different bugs. # gpg: Signature made Tue 13 Aug 2019 07:56:42 BST # gpg: using RSA key 75F46586AE61A66CC44E87DC6C38CACA20D9B392 # gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" [full] # gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" [full] # gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" [full] # gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>" [unknown] # Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392 * remotes/dgibson/tags/ppc-for-4.1-20190813: spapr/xive: Fix migration of hot-plugged CPUs spapr: Reset CAS & IRQ subsystem after devices Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-08-13spapr/xive: Fix migration of hot-plugged CPUsCédric Le Goater
The migration sequence of a guest using the XIVE exploitation mode relies on the fact that the states of all devices are restored before the machine is. This is not true for hot-plug devices such as CPUs which state come after the machine. This breaks migration because the thread interrupt context registers are not correctly set. Fix migration of hotplugged CPUs by restoring their context in the 'post_load' handler of the XiveTCTX model. Fixes: 277dd3d7712a ("spapr/xive: add migration support for KVM") Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20190813064853.29310-1-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-13spapr: Reset CAS & IRQ subsystem after devicesDavid Gibson
This fixes a nasty regression in qemu-4.1 for the 'pseries' machine, caused by the new "dual" interrupt controller model. Specifically, qemu can crash when used with KVM if a 'system_reset' is requested while there's active I/O in the guest. The problem is that in spapr_machine_reset() we: 1. Reset the CAS vector state spapr_ovec_cleanup(spapr->ov5_cas); 2. Reset all devices qemu_devices_reset() 3. Reset the irq subsystem spapr_irq_reset(); However (1) implicitly changes the interrupt delivery mode, because whether we're using XICS or XIVE depends on the CAS state. We don't properly initialize the new irq mode until (3) though - in particular setting up the KVM devices. During (2), we can temporarily drop the BQL allowing some irqs to be delivered which will go to an irq system that's not properly set up. Specifically, if the previous guest was in (KVM) XIVE mode, the CAS reset will put us back in XICS mode. kvm_kernel_irqchip() still returns true, because XIVE was using KVM, however XICs doesn't have its KVM components intialized and kernel_xics_fd == -1. When the irq is delivered it goes via ics_kvm_set_irq() which assert()s that kernel_xics_fd != -1. This change addresses the problem by delaying the CAS reset until after the devices reset. The device reset should quiesce all the devices so we won't get irqs delivered while we mess around with the IRQ. The CAS reset and irq re-initialize should also now be under the same BQL critical section so nothing else should be able to interrupt it either. We also move the spapr_irq_msi_reset() used in one of the legacy irq modes, since it logically makes sense at the same point as the spapr_irq_reset() (it's essentially an equivalent operation for older machine types). Since we don't need to switch between different interrupt controllers for those old machine types it shouldn't actually be broken in those cases though. Cc: Cédric Le Goater <clg@kaod.org> Fixes: b2e22477 "spapr: add a 'reset' method to the sPAPR IRQ backend" Fixes: 13db0cd9 "spapr: introduce a new sPAPR IRQ backend supporting XIVE and XICS" Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2019-08-12display/bochs: fix pcie supportGerd Hoffmann
Set QEMU_PCI_CAP_EXPRESS unconditionally in init(), then clear it in realize() in case the device is not connected to a PCIe bus. This makes sure the pci config space allocation is big enough, so accessing the PCIe extended config space doesn't overflow the pci config space buffer. PCI(e) config space is guest writable. Writes are limited by write mask (which probably is also filled with random stuff), so the guest can only flip enabled bits. But I suspect it still might be exploitable, so rather serious because it might be a host escape for the guest. On the other hand the device is probably not yet in widespread use. (For a QEMU version without this commit, a mitigation for the bug is available: use "-device bochs-display" as a conventional pci device only.) Cc: qemu-stable@nongnu.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20190812065221.20907-2-kraxel@redhat.com Reviewed-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-08-06Update version for v4.1.0-rc4 releasev4.1.0-rc4Peter Maydell
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-08-06compat: disable edid on virtio-gpu base deviceCornelia Huck
'edid' is a property of the virtio-gpu base device, so turning it off on virtio-gpu-pci is not enough (it misses -ccw). Turn it off on the base device instead. Fixes: 0a71966253c8 ("edid: flip the default to enabled") Signed-off-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20190806115819.16026-1-cohuck@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-08-06Merge remote-tracking branch 'remotes/maxreitz/tags/pull-block-2019-08-06' ↵Peter Maydell
into staging Block patches for 4.1.0-rc4: - Fix the backup block job when using copy offloading - Fix the mirror block job when using the write-blocking copy mode - Fix incremental backups after the image has been grown with the respective bitmap attached to it # gpg: Signature made Tue 06 Aug 2019 12:57:07 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-2019-08-06: block/backup: disable copy_range for compressed backup iotests: Test unaligned blocking mirror write mirror: Only mirror granularity-aligned chunks iotests: Test incremental backup after truncation util/hbitmap: update orig_size on truncate iotests: Test backup job with two guest writes backup: Copy only dirty areas Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-08-06block/backup: disable copy_range for compressed backupVladimir Sementsov-Ogievskiy
Enabled by default copy_range ignores compress option. It's definitely unexpected for user. It's broken since introduction of copy_range usage in backup in 9ded4a011496. Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-id: 20190730163251.755248-3-vsementsov@virtuozzo.com Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Max Reitz <mreitz@redhat.com>
2019-08-06iotests: Test unaligned blocking mirror writeMax Reitz
Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20190805113526.20319-1-mreitz@redhat.com Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2019-08-06mirror: Only mirror granularity-aligned chunksMax Reitz
In write-blocking mode, all writes to the top node directly go to the target. We must only mirror chunks of data that are aligned to the job's granularity, because that is how the dirty bitmap works. Therefore, the request alignment for writes must be the job's granularity (in write-blocking mode). Unfortunately, this forces all reads and writes to have the same granularity (we only need this alignment for writes to the target, not the source), but that is something to be fixed another time. Cc: qemu-stable@nongnu.org Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20190805153308.2657-1-mreitz@redhat.com Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Fixes: d06107ade0ce74dc39739bac80de84b51ec18546 Signed-off-by: Max Reitz <mreitz@redhat.com>
2019-08-06iotests: Test incremental backup after truncationMax Reitz
Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20190805152840.32190-1-mreitz@redhat.com Signed-off-by: Max Reitz <mreitz@redhat.com>
2019-08-06util/hbitmap: update orig_size on truncateVladimir Sementsov-Ogievskiy
Without this, hbitmap_next_zero and hbitmap_next_dirty_area are broken after truncate. So, orig_size is broken since it's introduction in 76d570dc495c56bb. Fixes: 76d570dc495c56bb Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-id: 20190805120120.23585-1-vsementsov@virtuozzo.com Reviewed-by: Max Reitz <mreitz@redhat.com> Cc: qemu-stable@nongnu.org Signed-off-by: Max Reitz <mreitz@redhat.com>
2019-08-06iotests: Test backup job with two guest writesMax Reitz
Perform two guest writes to not yet backed up areas of an image, where the former touches an inner area of the latter. Before HEAD^, copy offloading broke this in two ways: (1) The target image differs from the reference image (what the source was when the backup started). (2) But you will not see that in the failing output, because the job offset is reported as being greater than the job length. This is because one cluster is copied twice, and thus accounted for twice, but of course the job length does not increase. Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20190801173900.23851-3-mreitz@redhat.com Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Tested-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2019-08-06backup: Copy only dirty areasMax Reitz
The backup job must only copy areas that the copy_bitmap reports as dirty. This is always the case when using traditional non-offloading backup, because it copies each cluster separately. When offloading the copy operation, we sometimes copy more than one cluster at a time, but we only check whether the first one is dirty. Therefore, whenever copy offloading is possible, the backup job currently produces wrong output when the guest writes to an area of which an inner part has already been backed up, because that inner part will be re-copied. Fixes: 9ded4a0114968e98b41494fc035ba14f84cdf700 Signed-off-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-id: 20190801173900.23851-2-mreitz@redhat.com Cc: qemu-stable@nongnu.org Signed-off-by: Max Reitz <mreitz@redhat.com>
2019-08-05Merge remote-tracking branch 'remotes/philmd-gitlab/tags/edk2-next-20190803' ↵Peter Maydell
into staging A harmless build-sys patch that fixes a regression affecting Linux distributions packaging QEMU. # gpg: Signature made Sat 03 Aug 2019 09:24:15 BST # gpg: using RSA key E3E32C2CDEADC0DE # gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <f4bug@amsat.org>" [full] # Primary key fingerprint: FAAB E75E 1291 7221 DCFD 6BB2 E3E3 2C2C DEAD C0DE * remotes/philmd-gitlab/tags/edk2-next-20190803: Makefile: remove DESTDIR from firmware file content Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-08-03Makefile: remove DESTDIR from firmware file contentOlaf Hering
The resulting firmware files should only contain the runtime path. Fixes commit 26ce90fde5c ("Makefile: install the edk2 firmware images and their descriptors") Signed-off-by: Olaf Hering <olaf@aepfle.de> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20190530192812.17637-1-olaf@aepfle.de> Fixes: https://bugs.launchpad.net/qemu/+bug/1838703 Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
2019-08-02target/arm: Avoid bogus NSACR traps on M-profile without Security ExtensionPeter Maydell
In Arm v8.0 M-profile CPUs without the Security Extension and also in v7M CPUs, there is no NSACR register. However, the code we have to handle the FPU does not always check whether the ARM_FEATURE_M_SECURITY bit is set before testing whether env->v7m.nsacr permits access to the FPU. This means that for a CPU with an FPU but without the Security Extension we would always take a bogus fault when trying to stack the FPU registers on an exception entry. We could fix this by adding extra feature bit checks for all uses, but it is simpler to just make the internal value of nsacr 0xcff ("all non-secure accesses allowed"), since this is not guest visible when the Security Extension is not present. This allows us to continue to follow the Arm ARM pseudocode which takes a similar approach. (In particular, in the v8.1 Arm ARM the register is documented as reading as 0xcff in this configuration.) Fixes: https://bugs.launchpad.net/qemu/+bug/1838475 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Damien Hedde <damien.hedde@greensocs.com> Message-id: 20190801105742.20036-1-peter.maydell@linaro.org
2019-08-02Merge remote-tracking branch ↵Peter Maydell
'remotes/elmarco/tags/slirp-CVE-2019-14378-pull-request' into staging Slirp CVE-2019-14378 pull request # gpg: Signature made Fri 02 Aug 2019 12:17:24 BST # gpg: using RSA key 87A9BD933F87C606D276F62DDAE8E10975969CE5 # gpg: issuer "marcandre.lureau@redhat.com" # gpg: Good signature from "Marc-André Lureau <marcandre.lureau@redhat.com>" [full] # gpg: aka "Marc-André Lureau <marcandre.lureau@gmail.com>" [full] # Primary key fingerprint: 87A9 BD93 3F87 C606 D276 F62D DAE8 E109 7596 9CE5 * remotes/elmarco/tags/slirp-CVE-2019-14378-pull-request: slirp: update with CVE-2019-14378 fix Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-08-02slirp: update with CVE-2019-14378 fixMarc-André Lureau
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2019-07-30Update version for v4.1.0-rc3 releasev4.1.0-rc3Peter Maydell
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-30Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into stagingPeter Maydell
pci: bugfix A last minute fix to cross-version migration. Better late than never. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # gpg: Signature made Tue 30 Jul 2019 17:07:42 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: pcie_root_port: Disable ACS on older machines pcie_root_port: Allow ACS to be disabled Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-30pcie_root_port: Disable ACS on older machinesDr. David Alan Gilbert
ACS got added in 4.0 unconditionally, that broke older<->4.0 migration where there was a PCIe root port. Fix this by turning it off for 3.1 and older machines; note this fixes compatibility for older QEMUs but breaks compatibility with 4.0 for older machine types. machine type source qemu dest qemu 3.1 3.1 4.0 broken 3.1 3.1 4.1rc2 broken 3.1 3.1 4.1+this OK ++ 3.1 4.0 4.1rc2 OK 3.1 4.0 4.1+this broken -- 4.0 4.0 4.1rc2 OK 4.0 4.0 4.1+this OK So we gain and lose; the consensus seems to be treat this as a fix for older machine types. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20190730093719.12958-3-dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.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-07-30pcie_root_port: Allow ACS to be disabledDr. David Alan Gilbert
ACS was added in 4.0 unconditionally, this breaks migration compatibility. Allow ACS to be disabled by adding a property that's checked by pcie_root_port. Unfortunately pcie-root-port doesn't have any instance data, so there's no where for that flag to live, so stuff it into PCIESlot. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Message-Id: <20190730093719.12958-2-dgilbert@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2019-07-30target/arm: Deliver BKPT/BRK exceptions to correct exception levelPeter Maydell
Most Arm architectural debug exceptions (eg watchpoints) are ignored if the configured "debug exception level" is below the current exception level (so for example EL1 can't arrange to get debug exceptions for EL2 execution). Exceptions generated by the BRK or BPKT instructions are a special case -- they must always cause an exception, so if we're executing above the debug exception level then we must take them to the current exception level. This fixes a bug where executing BRK at EL2 could result in an exception being taken at EL1 (which is strictly forbidden by the architecture). Fixes: https://bugs.launchpad.net/qemu/+bug/1838277 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: 20190730132522.27086-1-peter.maydell@linaro.org
2019-07-30Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into stagingPeter Maydell
Block layer patches: - fdc: Fix inserting read-only media in empty drive # gpg: Signature made Tue 30 Jul 2019 16:32:14 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: iotests/118: Test inserting a read-only medium fdc: Fix inserting read-only media in empty drive Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-30iotests/118: Test inserting a read-only mediumKevin Wolf
Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com>
2019-07-30fdc: Fix inserting read-only media in empty driveKevin Wolf
In order to insert a read-only medium (i.e. a read-only block node) to the BlockBackend of a floppy drive, we must not have taken write permissions on that BlockBackend, or the operation will fail with the error message "Block node is read-only". The device already takes care to remove all permissions when the medium is ejected, but the state isn't correct if the drive is initially empty: It uses blk_is_read_only() to check whether write permissions should be taken, but this function returns false for empty BlockBackends in the common case. Fix floppy_drive_realize() to avoid taking write permissions if the drive is empty. Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com>
2019-07-30Merge remote-tracking branch 'remotes/maxreitz/tags/pull-block-2019-07-30' ↵Peter Maydell
into staging Block patch for 4.1.0-rc3: - Fix CID 1403771 in block/nvme.c # gpg: Signature made Tue 30 Jul 2019 13:51:52 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-2019-07-30: nvme: Limit blkshift to 12 (for 4 kB blocks) Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-30nvme: Limit blkshift to 12 (for 4 kB blocks)Max Reitz
Linux does not support blocks greater than 4 kB anyway, so we might as well limit blkshift to 12 and thus save us from some potential trouble. Reported-by: Peter Maydell <peter.maydell@linaro.org> Suggested-by: Maxim Levitsky <mlevitsk@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com> Message-id: 20190730114812.10493-1-mreitz@redhat.com Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com> Coverity: CID 1403771 Signed-off-by: Max Reitz <mreitz@redhat.com>
2019-07-30Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into stagingPeter Maydell
Block layer patches: - scsi-cd: Fix inserting read-only media in empty drive - block/copy-on-read: Fix permissions for inactive node - Test case fixes # gpg: Signature made Tue 30 Jul 2019 12:21:48 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: scsi-cd: Fix inserting read-only media in empty drive block/copy-on-read: Fix permissions for inactive node Fixes: add read-zeroes to 051.out tests/multiboot: Fix load address of test kernels Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-30scsi-cd: Fix inserting read-only media in empty driveKevin Wolf
scsi-disks decides whether it has a read-only device by looking at whether the BlockBackend specified as drive=... is read-only. In the case of an anonymous BlockBackend (with a node name specified in drive=...), this is the read-only flag of the attached node. In the case of an empty anonymous BlockBackend, it's always read-write because nothing prevented it from being read-write. This is a problem because scsi-cd would take write permissions on the anonymous BlockBackend of an empty drive created without a drive=... option. Using blockdev-insert-medium with a read-only node fails then with the error message "Block node is read-only". Fix scsi_realize() so that scsi-cd devices always take read-only permissions on their BlockBackend instead. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1733920 Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com>
2019-07-30block/copy-on-read: Fix permissions for inactive nodeKevin Wolf
The copy-on-read drive must not request the WRITE_UNCHANGED permission for its child if the node is inactive, otherwise starting a migration destination with -incoming will fail because the child cannot provide write access yet: qemu-system-x86_64: -blockdev copy-on-read,file=img,node-name=cor: Block node is read-only Earlier QEMU versions additionally ran into an abort() on the migration source side: bdrv_inactivate_recurse() failed to update permissions. This is silently ignored today because it was only supposed to loosen restrictions. This is the symptom that was originally reported here: https://bugzilla.redhat.com/show_bug.cgi?id=1733022 Signed-off-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com>
2019-07-30Fixes: add read-zeroes to 051.outAndrey Shinkevich
The patch "iotests: Set read-zeroes on in null block driver for Valgrind" with the commit ID a6862418fec4072 needs the change in 051.out when compared against on the s390 system. Fixes: a6862418fec40727b392c86dc13d9ec980efcb15 Reported-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Andrey Shinkevich <andrey.shinkevich@virtuozzo.com> Tested-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: John Snow <jsnow@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
generated by cgit v1.2.3 (git 2.26.2) at 2024-12-17 20:25:56 +0000