Skip to main content

Browse the archive

https://github.com/qemu/qemu
04 August 2024, 22:51:34 UTC
sort by:
Revision Author Date Message Commit Date
532cc6d Peter Maydell 10 April 2019, 14:38:59 UTC Update version for v4.0.0-rc3 release Signed-off-by: Peter Maydell <peter.maydell@linaro.org> 10 April 2019, 14:38:59 UTC
6523516 Peter Maydell 10 April 2019, 07:57:19 UTC Merge remote-tracking branch 'remotes/alistair/tags/pull-device-tree-20190409-1' into staging Single device tree fix for 4.0 A single patch to avoid an overflow when loading device trees. # gpg: Signature made Wed 10 Apr 2019 00:52:16 BST # gpg: using RSA key F6C4AC46D4934868D3B8CE8F21E10D29DF977054 # gpg: Good signature from "Alistair Francis <alistair@alistair23.me>" [full] # Primary key fingerprint: F6C4 AC46 D493 4868 D3B8 CE8F 21E1 0D29 DF97 7054 * remotes/alistair/tags/pull-device-tree-20190409-1: device_tree: Fix integer overflowing in load_device_tree() Signed-off-by: Peter Maydell <peter.maydell@linaro.org> 10 April 2019, 07:57:19 UTC
065e629 Markus Armbruster 09 April 2019, 17:40:18 UTC device_tree: Fix integer overflowing in load_device_tree() If the value of get_image_size() exceeds INT_MAX / 2 - 10000, the computation of @dt_size overflows to a negative number, which then gets converted to a very large size_t for g_malloc0() and load_image_size(). In the (fortunately improbable) case g_malloc0() succeeds and load_image_size() survives, we'd assign the negative number to *sizep. What that would do to the callers I can't say, but it's unlikely to be good. Fix by rejecting images whose size would overflow. Reported-by: Kurtis Miller <kurtis.miller@nccgroup.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20190409174018.25798-1-armbru@redhat.com> 09 April 2019, 23:35:40 UTC
f151f8a Peter Maydell 09 April 2019, 15:18:30 UTC migration/ram.c: Fix use-after-free in multifd_recv_unfill_packet() Coverity points out (CID 1400442) that in this code: if (packet->pages_alloc > p->pages->allocated) { multifd_pages_clear(p->pages); multifd_pages_init(packet->pages_alloc); } we free p->pages in multifd_pages_clear() but continue to use it in the following code. We also leak memory, because multifd_pages_init() returns the pointer to a new MultiFDPages_t struct but we are ignoring its return value. Fix both of these bugs by adding the missing assignment of the newly created struct to p->pages. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Juan Quintela <quintela@redhat.com> Message-id: 20190409151830.6024-1-peter.maydell@linaro.org Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> 09 April 2019, 19:46:34 UTC
4b9a21c Peter Maydell 09 April 2019, 16:36:00 UTC Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging * fixes for Alpine and SuSE * fix crash when hot-plugging nvdimm on older machine types # gpg: Signature made Tue 09 Apr 2019 17:34:27 BST # gpg: using RSA key BFFBD25F78C7AE83 # 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: tests: Make check-block a phony target hw/i386/pc: Fix crash when hot-plugging nvdimm on older machine types include/qemu/bswap.h: Use __builtin_memcpy() in accessor functions roms: Allow passing configure options to the EDK2 build tools roms: Rename the EFIROM variable to avoid clashing with iPXE Signed-off-by: Peter Maydell <peter.maydell@linaro.org> 09 April 2019, 16:36:01 UTC
3e20c81 Markus Armbruster 19 March 2019, 07:21:04 UTC tests: Make check-block a phony target Fixes: b93b63f574c "test makefile overhaul" Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-Id: <20190319072104.32591-1-armbru@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> 09 April 2019, 16:34:21 UTC
ae90949 Thomas Huth 07 April 2019, 09:23:14 UTC hw/i386/pc: Fix crash when hot-plugging nvdimm on older machine types QEMU currently crashes when you try to hot-plug an "nvdimm" device on older machine types: $ qemu-system-x86_64 -monitor stdio -M pc-1.1 QEMU 3.1.92 monitor - type 'help' for more information (qemu) device_add nvdimm,id=nvdimmn1 qemu-system-x86_64: /home/thuth/devel/qemu/util/error.c:57: error_setv: Assertion `*errp == ((void *)0)' failed. Aborted (core dumped) The call to hotplug_handler_pre_plug() in pc_memory_pre_plug() has been added recently before the check whether nvdimm is enabled. It should be done after the check. And while we're at it, also check the errp after the hotplug_handler_pre_plug(), otherwise errors are silently ignored here. Fixes: 9040e6dfa8c3fed87695a3de555d2c775727bb51 Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <20190407092314.11066-1-thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> 09 April 2019, 16:34:21 UTC
77b1757 Peter Maydell 18 March 2019, 11:29:38 UTC include/qemu/bswap.h: Use __builtin_memcpy() in accessor functions In the accessor functions ld*_he_p() and st*_he_p() we use memcpy() to perform a load or store to a pointer which might not be aligned for the size of the type. We rely on the compiler to optimize this memcpy() into an efficient load or store instruction where possible. This is required for good performance, but at the moment it is also required for correct operation, because some users of these functions require that the access is atomic if the pointer is aligned, which will only be the case if the compiler has optimized out the memcpy(). (The particular example where we discovered this is the virtio vring_avail_idx() which calls virtio_lduw_phys_cached() which eventually ends up calling lduw_he_p().) Unfortunately some compile environments, such as the fortify-source setup used in Alpine Linux, define memcpy() to a wrapper function in a way that inhibits this compiler optimization. The correct long-term fix here is to add a set of functions for doing atomic accesses into AddressSpaces (and to other relevant families of accessor functions like the virtio_*_phys_cached() ones), and make sure that callsites which want atomic behaviour use the correct functions. In the meantime, switch to using __builtin_memcpy() in the bswap.h accessor functions. This will make us robust against things like this fortify library in the short term. In the longer term it will mean that we don't end up with these functions being really badly-performing even if the semantics of the out-of-line memcpy() are correct. Reported-by: Fernando Casas Schössow <casasfernando@outlook.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-Id: <20190318112938.8298-1-peter.maydell@linaro.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> 09 April 2019, 16:34:21 UTC
1cab464 Philippe Mathieu-Daudé 09 April 2019, 13:45:36 UTC roms: Allow passing configure options to the EDK2 build tools Since commit f590a812c210 we build the EDK2 EfiRom utility unconditionally. Some distributions require to use extra compiler/linker flags, i.e. SUSE which enforces the PIE protection (see [*]). EDK2 build tools already provide a set of variables for that, use them to allow the caller to easily inject compiler/linker options.. Now build scripts can pass extra options, example: $ make -C roms \ EDK2_BASETOOLS_OPTFLAGS='-fPIE' \ efirom [*] https://lists.opensuse.org/opensuse-factory/2017-06/msg00403.html Reported-by: Olaf Hering <olaf@aepfle.de> Suggested-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190409134536.15548-3-philmd@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> 09 April 2019, 16:33:55 UTC
d912e79 Philippe Mathieu-Daudé 09 April 2019, 13:45:35 UTC roms: Rename the EFIROM variable to avoid clashing with iPXE The iPXE's 'veryclean' recipe removes $(EFIROM) even if the EFIROM macro originates from elsewhere: $ git checkout f590a812c21~ $ make -C roms clean EFIROM=$(type -P EfiRom) make: Entering directory '/source/qemu/roms' [...] make -C ipxe/src veryclean make[1]: Entering directory '/source/qemu/roms/ipxe/src' rm -f bin{,-*}/*.* bin{,-*}/.certificate.* bin{,-*}/.certificates.* bin{,-*}/.private_key.* bin{,-*}/errors bin{,-*}/NIC ./util/zbin ./util/elf2efi32 ./util/elf2efi64 /usr/bin/EfiRom ./util/efifatbin ./util/iccfix ./util/einfo TAGS bin{,-*}/symtab rm: cannot remove '/usr/bin/EfiRom': Permission denied make[1]: *** [Makefile.housekeeping:1564: clean] Error 1 make[1]: Leaving directory '/source/qemu/roms/ipxe/src' make: *** [Makefile:152: clean] Error 2 make: Leaving directory '/source/qemu/roms' Before f590a812c21 this variable could be overridden or unset, and the 'veryclean' Makefile rule would not complain. Commit f590a812c21 enforces this variable to the Intel EfiRom tool provided by the EDK2 project. To avoid the name clash and make the difference between the projects obvious, rename the variable used by the EDK2 project as EDK2_EFIROM. Fixes: f590a812c21074e82228de3e1dfb57b75fc02b62 Reported-by: Olaf Hering <olaf@aepfle.de> Reviewed-by: Laszlo Ersek <lersek@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190409134536.15548-2-philmd@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> 09 April 2019, 16:33:45 UTC
8cb2ca3 Peter Maydell 28 March 2019, 10:47:50 UTC target/i386: Generate #UD for LOCK on a register increment Fix a TCG crash due to attempting an atomic increment operation without having set up the address first. This is a similar case to that dealt with in commit e84fcd7f662a0d8198703, and we fix it in the same way. Fixes: https://bugs.launchpad.net/qemu/+bug/1807675 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Message-id: 20190328104750.25046-1-peter.maydell@linaro.org 09 April 2019, 12:29:32 UTC
120cba7 Peter Maydell 09 April 2019, 11:58:50 UTC Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-4.0-20190409' into staging ppc patch queue 2019-04-09 This is a small, hard freeze, pull request which fixes a regression on the pseries machine handling of PCI-E extended config space accesses. # gpg: Signature made Tue 09 Apr 2019 08:00:36 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.0-20190409: spapr_pci: Fix extended config space accesses pci: Allow PCI bus subtypes to support extended config space accesses Signed-off-by: Peter Maydell <peter.maydell@linaro.org> 09 April 2019, 11:58:50 UTC
248987f Peter Maydell 09 April 2019, 09:02:30 UTC Merge remote-tracking branch 'remotes/vivier2/tags/linux-user-for-4.0-pull-request' into staging fix gettid() clash with new glibc # gpg: Signature made Mon 08 Apr 2019 20:36:06 BST # gpg: using RSA key F30C38BD3F2FBE3C # gpg: Good signature from "Laurent Vivier <lvivier@redhat.com>" [full] # gpg: aka "Laurent Vivier <laurent@vivier.eu>" [full] # gpg: aka "Laurent Vivier (Red Hat) <lvivier@redhat.com>" [full] # Primary key fingerprint: CD2F 75DD C8E3 A4DC 2E4F 5173 F30C 38BD 3F2F BE3C * remotes/vivier2/tags/linux-user-for-4.0-pull-request: linux-user: rename gettid() to sys_gettid() to avoid clash with glibc linux-user: assume __NR_gettid always exists Signed-off-by: Peter Maydell <peter.maydell@linaro.org> 09 April 2019, 09:02:30 UTC
5cf0d32 Greg Kurz 01 April 2019, 17:55:08 UTC spapr_pci: Fix extended config space accesses 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> 09 April 2019, 05:03:10 UTC
1c685a9 Greg Kurz 01 April 2019, 17:55:02 UTC pci: Allow PCI bus subtypes to support extended config space accesses 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> 08 April 2019, 23:14:47 UTC
7fe1427 Peter Maydell 08 April 2019, 19:10:21 UTC Merge remote-tracking branch 'remotes/ericb/tags/pull-nbd-2019-04-08' into staging nbd patches for 2019-04-08 - Fix minor issues in recent alignment patches # gpg: Signature made Mon 08 Apr 2019 19:53:48 BST # gpg: using RSA key A7A16B4A2527436A # gpg: Good signature from "Eric Blake <eblake@redhat.com>" [full] # gpg: aka "Eric Blake (Free Software Programmer) <ebb9@byu.net>" [full] # gpg: aka "[jpeg image of size 6874]" [full] # Primary key fingerprint: 71C2 CC22 B1C4 6029 27D2 F3AA A7A1 6B4A 2527 436A * remotes/ericb/tags/pull-nbd-2019-04-08: nbd/client: Fix error message for server with unusable sizing nbd/server: Don't fail NBD_OPT_INFO for byte-aligned sources nbd/server: Trace client noncompliance on unaligned requests nbd/server: Fix blockstatus trace Signed-off-by: Peter Maydell <peter.maydell@linaro.org> 08 April 2019, 19:10:21 UTC
e53f88d Eric Blake 04 April 2019, 14:52:26 UTC nbd/client: Fix error message for server with unusable sizing Add a missing space to the error message used when giving up on a server that insists on an alignment which renders the last few bytes of the export unreadable. Fixes: 3add3ab78 Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20190404145226.32649-1-eblake@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> 08 April 2019, 18:51:25 UTC
099fbcd Eric Blake 03 April 2019, 03:05:22 UTC nbd/server: Don't fail NBD_OPT_INFO for byte-aligned sources In commit 0c1d50bd, I added a couple of TODO comments about whether we consult bl.request_alignment when responding to NBD_OPT_INFO. At the time, qemu as server was hard-coding an advertised alignment of 512 to clients that promised to obey constraints, and there was no function for getting at a device's preferred alignment. But in hindsight, advertising 512 when the block device prefers 1 caused other compliance problems, and commit b0245d64 changed one of the two TODO comments to advertise a more accurate alignment. Time to fix the other TODO. Doesn't really impact qemu as client (our normal client doesn't use NBD_OPT_INFO, and qemu-nbd --list promises to obey block sizes), but it might prove useful to other clients. Fixes: b0245d64 Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20190403030526.12258-4-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> 08 April 2019, 18:49:25 UTC
6e28064 Eric Blake 03 April 2019, 03:05:21 UTC nbd/server: Trace client noncompliance on unaligned requests We've recently added traces for clients to flag server non-compliance; let's do the same for servers to flag client non-compliance. According to the spec, if the client requests NBD_INFO_BLOCK_SIZE, it is promising to send all requests aligned to those boundaries. Of course, if the client does not request NBD_INFO_BLOCK_SIZE, then it made no promises so we shouldn't flag anything; and because we are willing to handle clients that made no promises (the spec allows us to use NBD_REP_ERR_BLOCK_SIZE_REQD if we had been unwilling), we already have to handle unaligned requests (which the block layer already does on our behalf). So even though the spec allows us to return EINVAL for clients that promised to behave, it's easier to always answer unaligned requests. Still, flagging non-compliance can be useful in debugging a client that is trying to be maximally portable. Qemu as client used to have one spot where it sent non-compliant requests: if the server sends an unaligned reply to NBD_CMD_BLOCK_STATUS, and the client was iterating over the entire disk, the next request would start at that unaligned point; this was fixed in commit a39286dd when the client was taught to work around server non-compliance; but is equally fixed if the server is patched to not send unaligned replies in the first place (yes, qemu 4.0 as server still has few such bugs, although they will be patched in 4.1). Fortunately, I did not find any more spots where qemu as client was non-compliant. I was able to test the patch by using the following hack to convince qemu-io to run various unaligned commands, coupled with serving 512-byte alignment by intentionally omitting '-f raw' on the server while viewing server traces. | diff --git i/nbd/client.c w/nbd/client.c | index 427980bdd22..1858b2aac35 100644 | --- i/nbd/client.c | +++ w/nbd/client.c | @@ -449,6 +449,7 @@ static int nbd_opt_info_or_go(QIOChannel *ioc, uint32_t opt, | nbd_send_opt_abort(ioc); | return -1; | } | + info->min_block = 1;//hack | if (!is_power_of_2(info->min_block)) { | error_setg(errp, "server minimum block size %" PRIu32 | " is not a power of two", info->min_block); Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20190403030526.12258-3-eblake@redhat.com> [eblake: address minor review nits] Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> 08 April 2019, 18:42:24 UTC
2178a56 Eric Blake 03 April 2019, 03:05:20 UTC nbd/server: Fix blockstatus trace Don't increment remaining_bytes until we know that we will actually be including the current block status extent in the reply; otherwise, the value traced will include a bytes value that is oversized by the length of the next block status extent which did not get sent because it instead ended the loop. Fixes: fb7afc79 Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20190403030526.12258-2-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> 08 April 2019, 18:36:04 UTC
5263724 Peter Maydell 08 April 2019, 16:53:18 UTC Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging 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> 08 April 2019, 16:53:18 UTC
ab63817 Markus Armbruster 08 April 2019, 15:30:03 UTC hmp: Fix drive_add ... format=help crash 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> 08 April 2019, 15:42:06 UTC
71ba74f Daniel P. Berrangé 20 March 2019, 16:18:42 UTC linux-user: rename gettid() to sys_gettid() to avoid clash with glibc The glibc-2.29.9000-6.fc31.x86_64 package finally includes the gettid() function as part of unistd.h when __USE_GNU is defined. This clashes with linux-user code which unconditionally defines this function name itself. /home/berrange/src/virt/qemu/linux-user/syscall.c:253:16: error: static declaration of ‘gettid’ follows non-static declaration 253 | _syscall0(int, gettid) | ^~~~~~ /home/berrange/src/virt/qemu/linux-user/syscall.c:184:13: note: in definition of macro ‘_syscall0’ 184 | static type name (void) \ | ^~~~ In file included from /usr/include/unistd.h:1170, from /home/berrange/src/virt/qemu/include/qemu/osdep.h:107, from /home/berrange/src/virt/qemu/linux-user/syscall.c:20: /usr/include/bits/unistd_ext.h:34:16: note: previous declaration of ‘gettid’ was here 34 | extern __pid_t gettid (void) __THROW; | ^~~~~~ CC aarch64-linux-user/linux-user/signal.o make[1]: *** [/home/berrange/src/virt/qemu/rules.mak:69: linux-user/syscall.o] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [Makefile:449: subdir-aarch64-linux-user] Error 2 While we could make our definition conditional and rely on glibc's impl, this patch simply renames our definition to sys_gettid() which is a common pattern in this file. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20190320161842.13908-3-berrange@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu> 08 April 2019, 15:27:13 UTC
184943d Daniel P. Berrangé 20 March 2019, 16:18:41 UTC linux-user: assume __NR_gettid always exists The gettid syscall was introduced in Linux 2.4.11. This is old enough that we can assume it always exists and thus not bother with the conditional backcompat logic. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20190320161842.13908-2-berrange@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu> 08 April 2019, 15:26:44 UTC
3f48686 Kevin Wolf 04 April 2019, 15:04:43 UTC block: Forward 'discard' to temporary overlay 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> 08 April 2019, 14:48:46 UTC
2c57310 Peter Maydell 08 April 2019, 14:21:11 UTC Merge remote-tracking branch '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> 08 April 2019, 14:21:11 UTC
c19f2b7 Dr. David Alan Gilbert 05 April 2019, 18:40:37 UTC test qgraph.c: Fix segs due to out of scope default 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> 08 April 2019, 10:38:07 UTC
c098aac Jafar Abdi 23 March 2019, 14:26:36 UTC tests/libqos: fix usage of bool in pci-spapr.c 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> 08 April 2019, 10:38:07 UTC
08f7ad1 Jafar Abdi 23 March 2019, 14:26:35 UTC tests/libqos: fix usage of bool in pci-pc.c 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> 08 April 2019, 10:38:07 UTC
f55a585 Peter Maydell 07 April 2019, 13:54:55 UTC Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into staging 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> 07 April 2019, 13:54:55 UTC
90fb864 Peter Maydell 05 April 2019, 23:22:34 UTC Merge remote-tracking branch '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> 05 April 2019, 23:22:34 UTC
d013283 Juan Quintela 03 April 2019, 11:49:51 UTC migration: Fix migrate_set_parameter 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> 05 April 2019, 14:32:13 UTC
c6e5baf Zhang Chen 29 March 2019, 22:29:51 UTC migration/ram.c: Fix codes conflict about bitmap_mutex 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> 05 April 2019, 14:29:48 UTC
10546e0 Peter Maydell 05 April 2019, 03:50:30 UTC Merge remote-tracking branch '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> 05 April 2019, 03:50:30 UTC
bc939ab Peter Maydell 05 April 2019, 02:52:05 UTC Merge remote-tracking branch 'remotes/aperard/tags/pull-xen-20190404' into 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> 05 April 2019, 02:52:05 UTC
79bcac2 Alistair Francis 04 April 2019, 18:15:34 UTC riscv: plic: Log guest errors 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> 04 April 2019, 23:36:21 UTC
0feb4a7 Alistair Francis 04 April 2019, 18:15:23 UTC riscv: plic: Fix incorrect irq calculation 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> 04 April 2019, 23:36:19 UTC
2bcd05c Paul Durrant 01 April 2019, 12:17:19 UTC xen-block: scale sector based quantities correctly 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> 04 April 2019, 17:00:07 UTC
15f0845 Paul Durrant 20 March 2019, 14:28:25 UTC xen-block: only advertize discard to the frontend when it is enabled... ...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> 04 April 2019, 11:41:23 UTC
f4b3717 Peter Maydell 03 April 2019, 12:13:30 UTC Merge remote-tracking branch 'remotes/cohuck/tags/s390x-20190403' into staging 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> 03 April 2019, 12:13:30 UTC
7357b22 Daniel P. Berrangé 29 March 2019, 11:11:04 UTC hw/s390x/3270-ccw: avoid taking address of fields in packed struct 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> 03 April 2019, 09:19:57 UTC
5d45a33 Daniel P. Berrangé 29 March 2019, 11:11:03 UTC hw/s390x/ipl: avoid taking address of fields in packed struct 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> 03 April 2019, 09:19:57 UTC
bea0279 Daniel P. Berrangé 29 March 2019, 11:11:02 UTC hw/s390/css: avoid taking address members in packed structs 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> 03 April 2019, 09:19:57 UTC
e1d0b37 Daniel P. Berrangé 29 March 2019, 11:11:01 UTC hw/vfio/ccw: avoid taking address members in packed structs 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> 03 April 2019, 09:19:57 UTC
061b51e Peter Maydell 02 April 2019, 16:01:20 UTC Update version for v4.0.0-rc2 release Signed-off-by: Peter Maydell <peter.maydell@linaro.org> 02 April 2019, 16:01:20 UTC
81fb1e6 Peter Xu 29 March 2019, 06:14:22 UTC intel_iommu: Drop extended root field 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> 02 April 2019, 15:49:14 UTC
2811af3 Peter Xu 29 March 2019, 06:14:21 UTC intel_iommu: Fix root_scalable migration breakage 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> 02 April 2019, 15:49:14 UTC
20f86a7 Yuval Shaia 21 March 2019, 16:18:32 UTC virtio-net: Fix typo in comment 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> 02 April 2019, 15:49:14 UTC
75c5626 Alex Williamson 26 March 2019, 23:05:38 UTC intel_iommu: Correct caching-mode error message 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> 02 April 2019, 15:49:14 UTC
2213282 Liam Merwick 21 March 2019, 20:13:49 UTC acpi: verify file entries in bios_linker_loader_add_pointer() 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> 02 April 2019, 15:49:14 UTC
37301a8 Peter Maydell 02 April 2019, 15:13:59 UTC Merge remote-tracking branch 'remotes/armbru/tags/pull-misc-2019-04-02' into 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> 02 April 2019, 15:13:59 UTC
436960c Peter Maydell 02 April 2019, 13:52:17 UTC Merge remote-tracking branch '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> 02 April 2019, 13:52:17 UTC
9a363f0 Peter Maydell 02 April 2019, 13:03:11 UTC Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging 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> 02 April 2019, 13:03:11 UTC
b4682a6 Daniel P. Berrangé 19 March 2019, 15:47:47 UTC filemon: fix watch IDs to avoid potential wraparound issues 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> 02 April 2019, 12:52:02 UTC
ff3dc8f Daniel P. Berrangé 13 March 2019, 17:36:18 UTC filemon: ensure watch IDs are unique to QFileMonitor scope 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> 02 April 2019, 12:46:33 UTC
b26c3f9 Daniel P. Berrangé 14 March 2019, 14:45:08 UTC tests: refactor file monitor test to make it more understandable 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> 02 April 2019, 12:46:33 UTC
79b9d4b Markus Armbruster 01 April 2019, 09:08:27 UTC accel: Unbreak accelerator fallback 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> 02 April 2019, 11:50:09 UTC
0427b62 Markus Armbruster 01 April 2019, 09:08:26 UTC vl: Document dependencies hiding in global and compat props Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190401090827.20793-5-armbru@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> 02 April 2019, 11:50:01 UTC
daff7f0 Markus Armbruster 01 April 2019, 09:08:25 UTC migration: Support adding migration blockers earlier 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> 02 April 2019, 11:49:36 UTC
811f865 Markus Armbruster 01 April 2019, 09:08:24 UTC Revert "migration: move only_migratable to MigrationState" 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> 02 April 2019, 11:38:05 UTC
2fa2327 Markus Armbruster 01 April 2019, 09:08:23 UTC Revert "vl: Fix to create migration object before block backends again" 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> 02 April 2019, 11:35:00 UTC
5cc8f9e Zhang Chen 02 April 2019, 08:55:21 UTC qapi/migration.json: Rename COLOStatus last_mode to last-mode 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> 02 April 2019, 11:32:15 UTC
966c0d4 Zhang Chen 26 March 2019, 17:45:10 UTC qapi/migration.json: Fix ColoStatus member last_mode's version 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> 02 April 2019, 11:30:25 UTC
17f30ea Markus Armbruster 18 March 2019, 18:33:12 UTC vl: Fix error location of positional arguments 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> 02 April 2019, 11:30:25 UTC
f18957b Thomas Huth 27 March 2019, 09:23:42 UTC tests/qemu-iotests/235: Allow fallback to tcg 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> 02 April 2019, 10:04:56 UTC
d20ba60 Alberto Garcia 28 March 2019, 16:25:11 UTC block: test block-stream with a base node that is used by block-commit 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> 02 April 2019, 10:04:44 UTC
20509c4 Alberto Garcia 28 March 2019, 16:25:10 UTC block: freeze the backing chain earlier in stream_start() 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> 02 April 2019, 10:04:44 UTC
0f0998f Alberto Garcia 28 March 2019, 16:25:09 UTC block: continue until base is found in bdrv_freeze_backing_chain() et al 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> 02 April 2019, 10:04:44 UTC
696aaae Vladimir Sementsov-Ogievskiy 29 March 2019, 11:04:54 UTC block/file-posix: do not fail on unlock bytes 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> 02 April 2019, 10:04:44 UTC
38e694f Thomas Huth 05 February 2019, 14:49:45 UTC tests/qemu-iotests: Remove redundant COPYING file 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> 02 April 2019, 10:04:44 UTC
de23e72 Stefano Garzarella 28 March 2019, 10:52:27 UTC block/gluster: limit the transfer size to 512 MiB Several versions of GlusterFS (3.12? -> 6.0.1) fail when the transfer size is greater or equal to 1024 MiB, so we are limiting the transfer size to 512 MiB to avoid this rare issue. Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1691320 Signed-off-by: Stefano Garzarella <sgarzare@redhat.com> Reviewed-by: Niels de Vos <ndevos@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> 02 April 2019, 10:04:44 UTC
a3d6ae2 Nir Soffer 24 March 2019, 00:20:12 UTC qemu-img: Enable BDRV_REQ_MAY_UNMAP in convert With Kevin's "block: Fix slow pre-zeroing in qemu-img convert"[1] (commit c9fdcf202f, 'qemu-img: Use BDRV_REQ_NO_FALLBACK for pre-zeroing') we skip the pre zero step called like this: blk_make_zero(s->target, BDRV_REQ_MAY_UNMAP | BDRV_REQ_NO_FALLBACK) And we write zeroes later using: blk_co_pwrite_zeroes(s->target, sector_num << BDRV_SECTOR_BITS, n << BDRV_SECTOR_BITS, 0); Since we use flags=0, this is translated to NBD_CMD_WRITE_ZEROES with NBD_CMD_FLAG_NO_HOLE flag, which cause the NBD server to allocated space instead of punching a hole. Here is an example failure: $ dd if=/dev/urandom of=src.img bs=1M count=5 $ truncate -s 50m src.img $ truncate -s 50m dst.img $ nbdkit -f -v -e '' -U nbd.sock file file=dst.img $ ./qemu-img convert -n src.img nbd:unix:nbd.sock We can see in nbdkit log that it received the NBD_CMD_FLAG_NO_HOLE (may_trim=0): nbdkit: file[1]: debug: newstyle negotiation: flags: export 0x4d nbdkit: file[1]: debug: pwrite count=2097152 offset=0 nbdkit: file[1]: debug: pwrite count=2097152 offset=2097152 nbdkit: file[1]: debug: pwrite count=1048576 offset=4194304 nbdkit: file[1]: debug: zero count=33554432 offset=5242880 may_trim=0 nbdkit: file[1]: debug: zero count=13631488 offset=38797312 may_trim=0 nbdkit: file[1]: debug: flush And the image became fully allocated: $ qemu-img info dst.img virtual size: 50M (52428800 bytes) disk size: 50M With this change we see that nbdkit did not receive the NBD_CMD_FLAG_NO_HOLE (may_trim=1): nbdkit: file[1]: debug: newstyle negotiation: flags: export 0x4d nbdkit: file[1]: debug: pwrite count=2097152 offset=0 nbdkit: file[1]: debug: pwrite count=2097152 offset=2097152 nbdkit: file[1]: debug: pwrite count=1048576 offset=4194304 nbdkit: file[1]: debug: zero count=33554432 offset=5242880 may_trim=1 nbdkit: file[1]: debug: zero count=13631488 offset=38797312 may_trim=1 nbdkit: file[1]: debug: flush And the file is sparse as expected: $ qemu-img info dst.img virtual size: 50M (52428800 bytes) disk size: 5.0M [1] http://lists.nongnu.org/archive/html/qemu-block/2019-03/msg00761.html Signed-off-by: Nir Soffer <nsoffer@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> 02 April 2019, 10:04:44 UTC
e0a5974 Thomas Huth 27 March 2019, 06:43:49 UTC iotests: Fix test 200 on s390x without virtio-pci virtio-pci is optional on s390x, e.g. in downstream RHEL builds, it is disabled. On s390x, virtio-ccw should be used instead. Other tests like 051 or 240 already use virtio-scsi-ccw instead of virtio-scsi-pci on s390x, so let's do the same here and always use virtio-scsi-ccw on s390x. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com> 02 April 2019, 10:04:44 UTC
d61d1a1 Peter Maydell 02 April 2019, 07:18:24 UTC Merge remote-tracking branch 'remotes/kraxel/tags/fixes-20190402-pull-request' into staging fixes for 4.0 (audio, usb), # gpg: Signature made Tue 02 Apr 2019 07:46:22 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-20190402-pull-request: audio: fix audio timer rate conversion bug usb-mtp: remove usb_mtp_object_free_one usb-mtp: fix return status of delete hw/usb/bus.c: Handle "no speed matched" case in usb_mask_to_str() Revert "audio: fix pc speaker init" Signed-off-by: Peter Maydell <peter.maydell@linaro.org> 02 April 2019, 07:18:24 UTC
be1092a Volker Rümelin 01 April 2019, 18:59:20 UTC audio: fix audio timer rate conversion bug Currently the default audio timer frequency is 10000Hz instead of a period of 10000us. Also the audiodev timer-period property gets converted like a frequency. Only handling of the legacy QEMU_AUDIO_TIMER_PERIOD environment variable is correct because it's actually a frequency. With this patch the property timer-period is really a timer period and QEMU_AUDIO_TIMER_PERIOD remains a frequency. Fixes: 71830221fb "-audiodev command line option basic implementation." Signed-off-by: Volker Rümelin <vr_qemu@t-online.de> Reviewed-by: Zoltán Kővágó <DirtY.iCE.hu@gmail.com> Message-id: 90b95e4f-39ef-2b01-da6a-857ebaee1ec5@t-online.de Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> 02 April 2019, 05:50:49 UTC
b396733 Bandan Das 01 April 2019, 21:17:11 UTC usb-mtp: remove usb_mtp_object_free_one This function is used in the delete path only and can be replaced by a call to usb_mtp_object_free. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Bandan Das <bsd@redhat.com> Message-Id: <20190401211712.19012-3-bsd@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> 02 April 2019, 05:22:49 UTC
4bc1591 Bandan Das 01 April 2019, 21:17:10 UTC usb-mtp: fix return status of delete Spotted by Coverity: CID 1399414 mtp delete allows the return status of delete succeeded, partial_delete or readonly - when none of the objects could be deleted. Give more meaningful names to return values of the delete function. Some initiators recurse over the objects themselves. In that case, only READ_ONLY can be returned. Signed-off-by: Bandan Das <bsd@redhat.com> Message-Id: <20190401211712.19012-2-bsd@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> 02 April 2019, 05:22:40 UTC
4717595 Peter Maydell 02 April 2019, 02:46:30 UTC Merge remote-tracking branch 'remotes/ericb/tags/pull-nbd-2019-04-01' into staging nbd patches for 2019-04-01 - Better behavior of qemu-img map on NBD images - Fixes for NBD protocol alignment corner cases: - the server has fewer places where it sends reads or block status not aligned to its advertised block size - the client has more cases where it can work around server non-compliance present in qemu 3.1 - the client now avoids non-compliant requests when interoperating with nbdkit or other servers not advertising block size # gpg: Signature made Mon 01 Apr 2019 15:06:54 BST # gpg: using RSA key A7A16B4A2527436A # gpg: Good signature from "Eric Blake <eblake@redhat.com>" [full] # gpg: aka "Eric Blake (Free Software Programmer) <ebb9@byu.net>" [full] # gpg: aka "[jpeg image of size 6874]" [full] # Primary key fingerprint: 71C2 CC22 B1C4 6029 27D2 F3AA A7A1 6B4A 2527 436A * remotes/ericb/tags/pull-nbd-2019-04-01: nbd/client: Trace server noncompliance on structured reads nbd/server: Advertise actual minimum block size block: Add bdrv_get_request_alignment() nbd/client: Support qemu-img convert from unaligned size nbd/client: Reject inaccessible tail of inconsistent server nbd/client: Report offsets in bdrv_block_status nbd/client: Lower min_block for block-status, unaligned size iotests: Add 241 to test NBD on unaligned images nbd-client: Work around server BLOCK_STATUS misalignment at EOF qemu-img: Gracefully shutdown when map can't finish nbd: Permit simple error to NBD_CMD_BLOCK_STATUS nbd: Don't lose server's error to NBD_CMD_BLOCK_STATUS nbd: Tolerate some server non-compliance in NBD_CMD_BLOCK_STATUS qemu-img: Report bdrv_block_status failures Signed-off-by: Peter Maydell <peter.maydell@linaro.org> 02 April 2019, 02:46:30 UTC
75d34eb Eric Blake 30 March 2019, 16:53:49 UTC nbd/client: Trace server noncompliance on structured reads Just as we recently added a trace for a server sending block status that doesn't match the server's advertised minimum block alignment, let's do the same for read chunks. But since qemu 3.1 is such a server (because it advertised 512-byte alignment, but when serving a file that ends in data but is not sector-aligned, NBD_CMD_READ would detect a mid-sector change between data and hole at EOF and the resulting read chunks are unaligned), we don't want to change our behavior of otherwise tolerating unaligned reads. Note that even though we fixed the server for 4.0 to advertise an actual block alignment (which gets rid of the unaligned reads at EOF for posix files), we can still trigger it via other means: $ qemu-nbd --image-opts driver=blkdebug,align=512,image.driver=file,image.filename=/path/to/non-aligned-file Arguably, that is a bug in the blkdebug block status function, for leaking a block status that is not aligned. It may also be possible to observe issues with a backing layer with smaller alignment than the active layer, although so far I have been unable to write a reliable iotest for that scenario. Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20190330165349.32256-1-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> 01 April 2019, 13:58:04 UTC
b0245d6 Eric Blake 31 March 2019, 01:36:36 UTC nbd/server: Advertise actual minimum block size Both NBD_CMD_BLOCK_STATUS and structured NBD_CMD_READ will split their reply according to bdrv_block_status() boundaries. If the block device has a request_alignment smaller than 512, but we advertise a block alignment of 512 to the client, then this can result in the server reply violating client expectations by reporting a smaller region of the export than what the client is permitted to address (although this is less of an issue for qemu 4.0 clients, given recent client patches to overlook our non-compliance at EOF). Since it's always better to be strict in what we send, it is worth advertising the actual minimum block limit rather than blindly rounding it up to 512. Note that this patch is not foolproof - it is still possible to provoke non-compliant server behavior using: $ qemu-nbd --image-opts driver=blkdebug,align=512,image.driver=file,image.filename=/path/to/non-aligned-file That is arguably a bug in the blkdebug driver (it should never pass back block status smaller than its alignment, even if it has to make multiple bdrv_get_status calls and determine the least-common-denominator status among the group to return). It may also be possible to observe issues with a backing layer with smaller alignment than the active layer, although so far I have been unable to write a reliable iotest for that scenario (but again, an issue like that could be argued to be a bug in the block layer, or something where we need a flag to bdrv_block_status() to state whether the result must be aligned to the current layer's limits or can be subdivided for accuracy when chasing backing files). Anyways, as blkdebug is not normally used, and as this patch makes our server more interoperable with qemu 3.1 clients, it is worth applying now, even while we still work on a larger patch series for the 4.1 timeframe to have byte-accurate file lengths. Note that the iotests output changes - for 223 and 233, we can see the server's better granularity advertisement; and for 241, the three test cases have the following effects: - natural alignment: the server's smaller alignment is now advertised, and the hole reported at EOF is now the right result; we've gotten rid of the server's non-compliance - forced server alignment: the server still advertises 512 bytes, but still sends a mid-sector hole. This is still a server compliance bug, which needs to be fixed in the block layer in a later patch; output does not change because the client is already being tolerant of the non-compliance - forced client alignment: the server's smaller alignment means that the client now sees the server's status change mid-sector without any protocol violations, but the fact that the map shows an unaligned mid-sector hole is evidence of the block layer problems with aligned block status, to be fixed in a later patch Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20190329042750.14704-7-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> [eblake: rebase to enhanced iotest 241 coverage] 01 April 2019, 13:52:28 UTC
4841211 Eric Blake 29 March 2019, 04:27:49 UTC block: Add bdrv_get_request_alignment() The next patch needs access to a device's minimum permitted alignment, since NBD wants to advertise this to clients. Add an accessor function, borrowing from blk_get_max_transfer() for accessing a backend's block limits. Signed-off-by: Eric Blake <eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20190329042750.14704-6-eblake@redhat.com> 01 April 2019, 13:46:52 UTC
9cf6385 Eric Blake 29 March 2019, 04:27:48 UTC nbd/client: Support qemu-img convert from unaligned size If an NBD server advertises a size that is not a multiple of a sector, the block layer rounds up that size, even though we set info.size to the exact byte value sent by the server. The block layer then proceeds to let us read or query block status on the hole that it added past EOF, which the NBD server is unlikely to be happy with. Fortunately, qemu as a server never advertizes an unaligned size, so we generally don't run into this problem; but the nbdkit server makes it easy to test: $ printf %1000d 1 > f1 $ ~/nbdkit/nbdkit -fv file f1 & pid=$! $ qemu-img convert -f raw nbd://localhost:10809 f2 $ kill $pid $ qemu-img compare f1 f2 Pre-patch, the server attempts a 1024-byte read, which nbdkit rightfully rejects as going beyond its advertised 1000 byte size; the conversion fails and the output files differ (not even the first sector is copied, because qemu-img does not follow ddrescue's habit of trying smaller reads to get as much information as possible in spite of errors). Post-patch, the client's attempts to read (and query block status, for new enough nbdkit) are properly truncated to the server's length, with sane handling of the hole the block layer forced on us. Although f2 ends up as a larger file (1024 bytes instead of 1000), qemu-img compare shows the two images to have identical contents for display to the guest. I didn't add iotests coverage since I didn't want to add a dependency on nbdkit in iotests. I also did NOT patch write, trim, or write zeroes - these commands continue to fail (usually with ENOSPC, but whatever the server chose), because we really can't write to the end of the file, and because 'qemu-img convert' is the most common case where we care about being tolerant (which is read-only). Perhaps we could truncate the request if the client is writing zeros to the tail, but that seems like more work, especially if the block layer is fixed in 4.1 to track byte-accurate sizing (in which case this patch would be reverted as unnecessary). Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20190329042750.14704-5-eblake@redhat.com> Tested-by: Richard W.M. Jones <rjones@redhat.com> 01 April 2019, 13:32:44 UTC
3add3ab Eric Blake 30 March 2019, 15:57:04 UTC nbd/client: Reject inaccessible tail of inconsistent server The NBD spec suggests that a server should never advertise a size inconsistent with its minimum block alignment, as that tail is effectively inaccessible to a compliant client obeying those block constraints. Since we have a habit of rounding up rather than truncating, to avoid losing the last few bytes of user input, and we cannot access the tail when the server advertises bogus block sizing, abort the connection to alert the server to fix their bug. And rejecting such servers matches what we already did for a min_block that was not a power of 2 or which was larger than max_block. Does not impact either qemu (which always sends properly aligned sizes) or nbdkit (which does not send minimum block requirements yet); so this is mostly aimed at new NBD server implementations, and ensures that the rest of our code can assume the size is aligned. Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20190330155704.24191-1-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> 01 April 2019, 13:31:16 UTC
5189e30 Peter Maydell 28 March 2019, 13:35:03 UTC hw/usb/bus.c: Handle "no speed matched" case in usb_mask_to_str() In usb_mask_to_str() we convert a mask of USB speeds into a human-readable string (like "full+high") for use in tracing and error messages. However the conversion code doesn't do anything to the string buffer if the passed in speedmask doesn't match any of the recognized speeds, which means that the tracing and error messages will end up with random garbage in them. This can happen if we're doing USB device passthrough. Handle the "unrecognized speed" case by using the string "unknown". Fixes: https://bugs.launchpad.net/qemu/+bug/1603785 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20190328133503.6490-1-peter.maydell@linaro.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> 01 April 2019, 06:53:44 UTC
28605a2 Gerd Hoffmann 28 March 2019, 07:11:21 UTC Revert "audio: fix pc speaker init" This reverts commit bd56d378842c238c8901536c06c20a4a51ee9761. Turned out it isn't that simple as the device needs the pit object link. So "-device isa-pcspk" isn't going wo work anyway. We are in freeze, so just reverting the thing is the best way to handle this for now, trying to come up with something better can be done in the 4.1 devel cycle. Also add a comment noting the object link. Reported-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Message-id: 20190328071121.21147-1-kraxel@redhat.com 01 April 2019, 06:53:40 UTC
a62a85e Eric Blake 31 March 2019, 01:28:37 UTC nbd/client: Report offsets in bdrv_block_status It is desirable for 'qemu-img map' to have the same output for a file whether it is served over file or nbd protocols. However, ever since we implemented block status for NBD (2.12), the NBD protocol forgot to inform the block layer that as the final layer in the chain, the offset is valid; without an offset, the human-readable form of qemu-img map gives up with the unhelpful: $ nbdkit -U - data data="1" size=512 --run 'qemu-img map $nbd' Offset Length Mapped to File qemu-img: File contains external, encrypted or compressed clusters. The --output=json form always works, because it is reporting the lower-level bdrv_block_status results directly rather than trying to filter out sparse ranges for human consumption - but now it also shows the offset member. With this patch, the human output changes to: Offset Length Mapped to File 0 0x200 0 nbd+unix://?socket=/tmp/nbdkitOxeoLa/socket This change is observable to several iotests. Fixes: 78a33ab5 Reported-by: Richard W.M. Jones <rjones@redhat.com> Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20190329042750.14704-4-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> 31 March 2019, 01:52:29 UTC
7da537f Eric Blake 29 March 2019, 04:27:46 UTC nbd/client: Lower min_block for block-status, unaligned size We have a latent bug in our NBD client code, tickled by the brand new nbdkit 1.11.10 block status support: $ nbdkit --filter=log --filter=truncate -U - \ data data="1" size=511 truncate=64K logfile=/dev/stdout \ --run 'qemu-img convert $nbd /var/tmp/out' ... qemu-img: block/io.c:2122: bdrv_co_block_status: Assertion `*pnum && QEMU_IS_ALIGNED(*pnum, align) && align > offset - aligned_offset' failed. The culprit? Our implementation of .bdrv_co_block_status can return unaligned block status for any server that operates with a lower actual alignment than what we tell the block layer in request_alignment, in violation of the block layer's constraints. To date, we've been unable to trip the bug, because qemu as NBD server always advertises block sizing (at which point it is a server bug if the server sends unaligned status - although qemu 3.1 is such a server and I've sent separate patches for 4.0 both to get the server to obey the spec, and to let the client to tolerate server oddities at EOF). But nbdkit does not (yet) advertise block sizing, and therefore is not in violation of the spec for returning block status at whatever boundaries it wants, and those unaligned results can occur anywhere rather than just at EOF. While we are still wise to avoid sending sub-sector read/write requests to a server of unknown origin, we MUST consider that a server telling us block status without an advertised block size is correct. So, we either have to munge unaligned answers from the server into aligned ones that we hand back to the block layer, or we have to tell the block layer about a smaller alignment. Similarly, if the server advertises an image size that is not sector-aligned, we might as well assume that the server intends to let us access those tail bytes, and therefore supports a minimum block size of 1, regardless of whether the server supports block status (although we still need more patches to fix the problem that with an unaligned image, we can send read or block status requests that exceed EOF to the server). Again, qemu as server cannot trip this problem (because it rounds images to sector alignment), but nbdkit advertised unaligned size even before it gained block status support. Solve both alignment problems at once by using better heuristics on what alignment to report to the block layer when the server did not give us something to work with. Note that very few NBD servers implement block status (to date, only qemu and nbdkit are known to do so); and as the NBD spec mentioned block sizing constraints prior to documenting block status, it can be assumed that any future implementations of block status are aware that they must advertise block size if they want a minimum size other than 1. We've had a long history of struggles with picking the right alignment to use in the block layer, as evidenced by the commit message of fd8d372d (v2.12) that introduced the current choice of forced 512-byte alignment. There is no iotest coverage for this fix, because qemu can't provoke it, and I didn't want to make test 241 dependent on nbdkit. Fixes: fd8d372d Reported-by: Richard W.M. Jones <rjones@redhat.com> Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20190329042750.14704-3-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Tested-by: Richard W.M. Jones <rjones@redhat.com> 31 March 2019, 01:52:19 UTC
e9dce9c Eric Blake 29 March 2019, 04:27:45 UTC iotests: Add 241 to test NBD on unaligned images Add a test for the NBD client workaround in the previous patch. It's not really feasible for an iotest to assume a specific tracing engine, so we can't really probe trace_nbd_parse_blockstatus_compliance to see if the server was fixed vs. whether the client just worked around the server (other than by rearranging order between code patches and this test). But having a successful exchange sure beats the previous state of an error message. Since format probing can change alignment, we can use that as an easy way to test several configurations. Not tested yet, but worth adding to this test in future patches: an NBD server that can advertise a non-sector-aligned size (such as nbdkit) causes qemu as the NBD client to misbehave when it rounds the size up and accesses beyond the advertised size. Qemu as NBD server never advertises a non-sector-aligned size (since bdrv_getlength() currently rounds up to sector boundaries); until qemu can act as such a server, testing that flaw will have to rely on external binaries. Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20190329042750.14704-2-eblake@redhat.com> Tested-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> [eblake: add forced-512 alignment, and nbdkit reproducer comment] 31 March 2019, 01:50:58 UTC
737d3f5 Eric Blake 26 March 2019, 17:13:17 UTC nbd-client: Work around server BLOCK_STATUS misalignment at EOF The NBD spec is clear that a server that advertises a minimum block size should reply to NBD_CMD_BLOCK_STATUS with extents aligned accordingly. However, we know that the qemu NBD server implementation has had a corner-case bug where it is not compliant with the spec, present since the introduction of NBD_CMD_BLOCK_STATUS in qemu 2.12 (and unlikely to be patched in time for 4.0). Namely, when qemu is serving a file that is not a multiple of 512 bytes, it rounds the size advertised over NBD up to the next sector boundary (someday, I'd like to fix that to be byte-accurate, but it's a much bigger audit not appropriate for this release); yet if the final sector contains data prior to EOF, lseek(SEEK_HOLE) will point to the implicit hole mid-sector which qemu then reported over NBD. We are well within our rights to hang up on a server that can't follow the spec, but it is more useful to try and keep the connection alive in spite of the problem. Do so by tracing a message about the problem, and then either truncating the request back to an aligned boundary (if it covered more than the final sector) or widening it out to the full boundary with a forced status of data (since truncating would result in 0 bytes, but we have to make progress, and valid since data is a default-safe answer). And in practice, since the problem only happens on a sector that starts with data and ends with a hole, we are going to want to read that full sector anyway (where qemu as the server fills in the tail beyond EOF with appropriate NUL bytes). Easy reproduction: $ printf %1000d 1 > file $ qemu-nbd -f raw -t file & pid=$! $ qemu-img map --output=json -f raw nbd://localhost:10809 qemu-img: Could not read file metadata: Invalid argument $ kill $pid where the patched version instead succeeds with: [{ "start": 0, "length": 1024, "depth": 0, "zero": false, "data": true}] Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20190326171317.4036-1-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> 30 March 2019, 15:06:08 UTC
30065d1 Eric Blake 26 March 2019, 18:40:43 UTC qemu-img: Gracefully shutdown when map can't finish Trying 'qemu-img map -f raw nbd://localhost:10809' causes the NBD server to output a scary message: qemu-nbd: Disconnect client, due to: Failed to read request: Unexpected end-of-file before all bytes were read This is because the NBD client, being remote, has no way to expose a human-readable map (the --output=json data is fine, however). But because we exit(1) right after the message, causing the client to bypass all block cleanup, the server sees the abrupt exit and warns, whereas it would be silent had the client had a chance to send NBD_CMD_DISC. Other protocols may have similar cleanup issues, where failure to blk_unref() could cause unintended effects. Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20190326184043.7544-1-eblake@redhat.com> Reviewed-by: John Snow <jsnow@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> 30 March 2019, 15:06:08 UTC
ebd82cd Eric Blake 25 March 2019, 19:01:04 UTC nbd: Permit simple error to NBD_CMD_BLOCK_STATUS The NBD spec is clear that when structured replies are active, a simple error reply is acceptable to any command except for NBD_CMD_READ. However, we were mistakenly requiring structured errors for NBD_CMD_BLOCK_STATUS, and hanging up on a server that gave a simple error (since qemu does not behave as such a server, we didn't notice the problem until now). Broken since its introduction in commit 78a33ab5 (v2.12). Noticed while debugging a separate failure reported by nbdkit while working out its initial implementation of BLOCK_STATUS, although it turns out that nbdkit also chose to send structured error replies for BLOCK_STATUS, so I had to manually provoke the situation by hacking qemu's server to send a simple error reply: | diff --git i/nbd/server.c w/nbd/server.c | index fd013a2817a..833288d7c45 100644 | 00--- i/nbd/server.c | +++ w/nbd/server.c | @@ -2269,6 +2269,8 @@ static coroutine_fn int nbd_handle_request(NBDClient *client, | "discard failed", errp); | | case NBD_CMD_BLOCK_STATUS: | + return nbd_co_send_simple_reply(client, request->handle, ENOMEM, | + NULL, 0, errp); | if (!request->len) { | return nbd_send_generic_reply(client, request->handle, -EINVAL, | "need non-zero length", errp); | Signed-off-by: Eric Blake <eblake@redhat.com> Acked-by: Richard W.M. Jones <rjones@redhat.com> Message-Id: <20190325190104.30213-3-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> 30 March 2019, 15:06:08 UTC
b29f3a3 Eric Blake 25 March 2019, 19:01:03 UTC nbd: Don't lose server's error to NBD_CMD_BLOCK_STATUS When the server replies with a (structured [*]) error to NBD_CMD_BLOCK_STATUS, without any extent information sent first, the client code was blindly throwing away the server's error code and instead telling the caller that EIO occurred. This has been broken since its introduction in 78a33ab5 (v2.12, where we should have called: error_setg(&local_err, "Server did not reply with any status extents"); nbd_iter_error(&iter, false, -EIO, &local_err); to declare the situation as a non-fatal error if no earlier error had already been flagged, rather than just blindly slamming iter.err and iter.ret), although it is more noticeable since commit 7f86068d, which actually tries hard to preserve the server's code thanks to a separate iter.request_ret. [*] The spec is clear that the server is also permitted to reply with a simple error, but that's a separate fix. I was able to provoke this scenario with a hack to the server, then seeing whether ENOMEM makes it back to the caller: | diff --git a/nbd/server.c b/nbd/server.c | index fd013a2817a..29c7995de02 100644 | --- a/nbd/server.c | +++ b/nbd/server.c | @@ -2269,6 +2269,8 @@ static coroutine_fn int nbd_handle_request(NBDClient *client, | "discard failed", errp); | | case NBD_CMD_BLOCK_STATUS: | + return nbd_send_generic_reply(client, request->handle, -ENOMEM, | + "no status for you today", errp); | if (!request->len) { | return nbd_send_generic_reply(client, request->handle, -EINVAL, | "need non-zero length", errp); | -- Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20190325190104.30213-2-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> 30 March 2019, 15:06:08 UTC
a39286d Eric Blake 23 March 2019, 21:26:39 UTC nbd: Tolerate some server non-compliance in NBD_CMD_BLOCK_STATUS The NBD spec states that NBD_CMD_FLAG_REQ_ONE (which we currently always use) should not reply with an extent larger than our request, and that the server's response should be exactly one extent. Right now, that means that if a server sends more than one extent, we treat the server as broken, fail the block status request, and disconnect, which prevents all further use of the block device. But while good software should be strict in what it sends, it should be tolerant in what it receives. While trying to implement NBD_CMD_BLOCK_STATUS in nbdkit, we temporarily had a non-compliant server sending too many extents in spite of REQ_ONE. Oddly enough, 'qemu-img convert' with qemu 3.1 failed with a somewhat useful message: qemu-img: Protocol error: invalid payload for NBD_REPLY_TYPE_BLOCK_STATUS which then disappeared with commit d8b4bad8, on the grounds that an error message flagged only at the time of coroutine teardown is pointless, and instead we should rely on the actual failed API to report an error - in other words, the 3.1 behavior was masking the fact that qemu-img was not reporting an error. That has since been fixed in the previous patch, where qemu-img convert now fails with: qemu-img: error while reading block status of sector 0: Invalid argument But even that is harsh. Since we already partially relaxed things in commit acfd8f7a to tolerate a server that exceeds the cap (although that change was made prior to the NBD spec actually putting a cap on the extent length during REQ_ONE - in fact, the NBD spec change was BECAUSE of the qemu behavior prior to that commit), it's not that much harder to argue that we should also tolerate a server that sends too many extents. But at the same time, it's nice to trace when we are being tolerant of server non-compliance, in order to help server writers fix their implementations to be more portable (if they refer to our traces, rather than just stderr). Reported-by: Richard W.M. Jones <rjones@redhat.com> Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20190323212639.579-3-eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> 30 March 2019, 15:06:08 UTC
2058c2a Eric Blake 23 March 2019, 21:26:38 UTC qemu-img: Report bdrv_block_status failures If bdrv_block_status_above() fails, we are aborting the convert process but failing to print an error message. Broken in commit 690c7301 (v2.4) when rewriting convert's logic. Discovered when teaching nbdkit to support NBD_CMD_BLOCK_STATUS, and accidentally violating the protocol by returning more than one extent in spite of qemu asking for NBD_CMD_FLAG_REQ_ONE. The qemu NBD code should probably handle the server's non-compliance more gracefully than failing with EINVAL, but qemu-img shouldn't be silently squelching any block status failures. It doesn't help that qemu 3.1 masks the qemu-img bug with extra noise that the nbd code is dumping to stderr (that noise was cleaned up in d8b4bad8). Reported-by: Richard W.M. Jones <rjones@redhat.com> Signed-off-by: Eric Blake <eblake@redhat.com> Message-Id: <20190323212639.579-2-eblake@redhat.com> Reviewed-by: Kevin Wolf <kwolf@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> 30 March 2019, 15:06:07 UTC
230ce19 Peter Maydell 29 March 2019, 19:28:59 UTC Merge remote-tracking branch 'remotes/rth/tags/pull-axp-20190325' into staging Update palcode for machine checks. # gpg: Signature made Mon 25 Mar 2019 23:09:24 GMT # gpg: using RSA key 7A481E78868B4DB6A85A05C064DF38E8AF7E215F # gpg: issuer "richard.henderson@linaro.org" # gpg: Good signature from "Richard Henderson <richard.henderson@linaro.org>" [full] # Primary key fingerprint: 7A48 1E78 868B 4DB6 A85A 05C0 64DF 38E8 AF7E 215F * remotes/rth/tags/pull-axp-20190325: pc-bios: Update palcode-clipper Signed-off-by: Peter Maydell <peter.maydell@linaro.org> 29 March 2019, 19:29:00 UTC
c503849 Peter Maydell 29 March 2019, 11:51:54 UTC Merge remote-tracking branch 'remotes/jasowang/tags/net-pull-request' into staging # gpg: Signature made Fri 29 Mar 2019 07:30:26 GMT # gpg: using RSA key EF04965B398D6211 # gpg: Good signature from "Jason Wang (Jason Wang on RedHat) <jasowang@redhat.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: 215D 46F4 8246 689E C77F 3562 EF04 965B 398D 6211 * remotes/jasowang/tags/net-pull-request: net: tap: use qemu_set_nonblock MAINTAINERS: Update the latest email address e1000: Delay flush queue when receive RCTL net/socket: learn to talk with a unix dgram socket Signed-off-by: Peter Maydell <peter.maydell@linaro.org> 29 March 2019, 11:51:54 UTC
94c0176 Peter Maydell 29 March 2019, 09:36:29 UTC Merge remote-tracking branch 'remotes/dgibson/tags/ppc-for-4.0-20190329' into staging ppc patch queue 2019-03-29 Here's a set of bugfixes for ppc, aimed at qemu-4.0 during hard freeze. We have one cleanup that's not strictly a bugfix, but will avoid an ugly external interface making it to a released version. We have one change to generic code to tweak the semantics of qemu_getrampagesize() which fixes a bug for ppc. This does have a possible impact on s390x which uses this function for a different purpose. I've discussed with David Hildenbrand and Igor Mammedov, however and we think it won't immediately break anything due to some existing bugs in the s390 usage. David H will be following up with some s390 fixes in that area. # gpg: Signature made Fri 29 Mar 2019 03:27:49 GMT # 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.0-20190329: exec: Only count mapped memory backends for qemu_getrampagesize() spapr/irq: Add XIVE sanity checks on non-P9 machines spapr: Simplify handling of host-serial and host-model values target/ppc: Fix QEMU crash with stxsdx target/ppc: Improve comment of bcctr used for spectre v2 mitigation target/ppc: Consolidate 64-bit server processor detection in a helper target/ppc: Enable "decrement and test CTR" version of bcctr target/ppc: Fix TCG temporary leaks in gen_bcond() Signed-off-by: Peter Maydell <peter.maydell@linaro.org> 29 March 2019, 09:36:29 UTC
ab79237 Li Qiang 21 November 2018, 11:21:59 UTC net: tap: use qemu_set_nonblock The fcntl will change the flags directly, use qemu_set_nonblock() instead. Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Li Qiang <liq3ea@gmail.com> Signed-off-by: Jason Wang <jasowang@redhat.com> 29 March 2019, 07:22:18 UTC
c6bf50f Zhang Chen 15 March 2019, 06:12:58 UTC MAINTAINERS: Update the latest email address Signed-off-by: Zhang Chen <chen.zhang@intel.com> Signed-off-by: Jason Wang <jasowang@redhat.com> 29 March 2019, 07:22:18 UTC
157628d yuchenlin 13 March 2019, 06:56:49 UTC e1000: Delay flush queue when receive RCTL Due to too early RCT0 interrput, win10x32 may hang on booting. This problem can be reproduced by doing power cycle on win10x32 guest. In our environment, we have 10 win10x32 and stress power cycle. The problem will happen about 20 rounds. Below shows some log with comment: The normal case: 22831@1551928392.984687:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 22831@1551928392.985655:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 22831@1551928392.985801:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: RCTL: 0, mac_reg[RCTL] = 0x0 22831@1551928393.056710:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: ICR read: 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: RCTL: 0, mac_reg[RCTL] = 0x0 22831@1551928393.077548:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: ICR read: 0 e1000: set_ics 2, ICR 0, IMR 0 e1000: set_ics 2, ICR 2, IMR 0 e1000: RCTL: 0, mac_reg[RCTL] = 0x0 22831@1551928393.102974:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 22831@1551928393.103267:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 e1000: RCTL: 255, mac_reg[RCTL] = 0x40002 <- win10x32 says it can handle RX now e1000: set_ics 0, ICR 2, IMR 9d <- unmask interrupt e1000: RCTL: 255, mac_reg[RCTL] = 0x48002 e1000: set_ics 80, ICR 2, IMR 9d <- interrupt and work! ... The bad case: 27744@1551930483.117766:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 27744@1551930483.118398:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: RCTL: 0, mac_reg[RCTL] = 0x0 27744@1551930483.198063:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: ICR read: 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: RCTL: 0, mac_reg[RCTL] = 0x0 27744@1551930483.218675:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 e1000: set_ics 0, ICR 0, IMR 0 e1000: ICR read: 0 e1000: set_ics 2, ICR 0, IMR 0 e1000: set_ics 2, ICR 2, IMR 0 e1000: RCTL: 0, mac_reg[RCTL] = 0x0 27744@1551930483.241768:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 27744@1551930483.241979:e1000x_rx_disabled Received packet dropped because receive is disabled RCTL = 0 e1000: RCTL: 255, mac_reg[RCTL] = 0x40002 <- win10x32 says it can handle RX now e1000: set_ics 80, ICR 2, IMR 0 <- flush queue (caused by setting RCTL) e1000: set_ics 0, ICR 82, IMR 9d <- unmask interrupt and because 0x82&0x9d != 0 generate interrupt, hang on here... To workaround this problem, simply delay flush queue. Also stop receiving when timer is going to run. Tested on CentOS, Win7SP1x64 and Win10x32. Signed-off-by: yuchenlin <yuchenlin@synology.com> Reviewed-by: Dmitry Fleytman <dmitry.fleytman@gmail.com> Signed-off-by: Jason Wang <jasowang@redhat.com> 29 March 2019, 07:22:18 UTC
back to top