- 10 4月, 2019 9 次提交
-
-
由 Peter Maydell 提交于
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: NPeter Maydell <peter.maydell@linaro.org>
-
由 Markus Armbruster 提交于
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: NKurtis Miller <kurtis.miller@nccgroup.com> Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: NAlistair Francis <alistair.francis@wdc.com> Message-Id: <20190409174018.25798-1-armbru@redhat.com>
-
由 Peter Maydell 提交于
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: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NJuan Quintela <quintela@redhat.com> Message-id: 20190409151830.6024-1-peter.maydell@linaro.org Reviewed-by: NPhilippe Mathieu-Daudé <philmd@redhat.com>
-
由 Peter Maydell 提交于
* 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: NPeter Maydell <peter.maydell@linaro.org>
-
由 Markus Armbruster 提交于
Fixes: b93b63f5 "test makefile overhaul" Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Message-Id: <20190319072104.32591-1-armbru@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Thomas Huth 提交于
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: 9040e6dfSigned-off-by: NThomas Huth <thuth@redhat.com> Message-Id: <20190407092314.11066-1-thuth@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Peter Maydell 提交于
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: NFernando Casas Schössow <casasfernando@outlook.com> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Message-Id: <20190318112938.8298-1-peter.maydell@linaro.org> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Philippe Mathieu-Daudé 提交于
Since commit f590a812 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.htmlReported-by: NOlaf Hering <olaf@aepfle.de> Suggested-by: NLaszlo Ersek <lersek@redhat.com> Signed-off-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190409134536.15548-3-philmd@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Reviewed-by: NLaszlo Ersek <lersek@redhat.com> Reviewed-by: NIgor Mammedov <imammedo@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
由 Philippe Mathieu-Daudé 提交于
The iPXE's 'veryclean' recipe removes $(EFIROM) even if the EFIROM macro originates from elsewhere: $ git checkout f590a812~ $ 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 f590a812 this variable could be overridden or unset, and the 'veryclean' Makefile rule would not complain. Commit f590a812 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: f590a812Reported-by: NOlaf Hering <olaf@aepfle.de> Reviewed-by: NLaszlo Ersek <lersek@redhat.com> Signed-off-by: NPhilippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190409134536.15548-2-philmd@redhat.com> Reviewed-by: NMichael S. Tsirkin <mst@redhat.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
-
- 09 4月, 2019 11 次提交
-
-
由 Peter Maydell 提交于
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 e84fcd7f, and we fix it in the same way. Fixes: https://bugs.launchpad.net/qemu/+bug/1807675Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Acked-by: NPaolo Bonzini <pbonzini@redhat.com> Message-id: 20190328104750.25046-1-peter.maydell@linaro.org
-
由 Peter Maydell 提交于
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: NPeter Maydell <peter.maydell@linaro.org>
-
由 Peter Maydell 提交于
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: NPeter Maydell <peter.maydell@linaro.org>
-
由 Greg Kurz 提交于
The PAPR PHB acts as a legacy PCI bus but it allows PCIe extended config space accesses anyway (for pseries-2.9 and newer machine types). Introduce a specific PCI bus subtype to inform the common PCI code about that. Fixes: c2077e2cSigned-off-by: NGreg 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: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Greg Kurz 提交于
Some PHB implementations, eg. PAPR used on pseries machine, act like a regular PCI bus rather than a PCIe bus, but allow access to the PCIe extended config space anyway. Introduce a new PCI bus class method to modelize this behaviour and use it when adjusting the config space size limit during accesses. No behaviour change for existing PCI bus types. Signed-off-by: NGreg Kurz <groug@kaod.org> Message-Id: <155414130271.574858.4253514266378127489.stgit@bahia.lan> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Peter Maydell 提交于
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: NPeter Maydell <peter.maydell@linaro.org>
-
由 Eric Blake 提交于
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: 3add3ab7Signed-off-by: NEric Blake <eblake@redhat.com> Message-Id: <20190404145226.32649-1-eblake@redhat.com> Reviewed-by: NKevin Wolf <kwolf@redhat.com>
-
由 Eric Blake 提交于
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: b0245d64Signed-off-by: NEric Blake <eblake@redhat.com> Message-Id: <20190403030526.12258-4-eblake@redhat.com> Reviewed-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
-
由 Eric Blake 提交于
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: NEric Blake <eblake@redhat.com> Message-Id: <20190403030526.12258-3-eblake@redhat.com> [eblake: address minor review nits] Reviewed-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
-
由 Eric Blake 提交于
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: fb7afc79Signed-off-by: NEric Blake <eblake@redhat.com> Message-Id: <20190403030526.12258-2-eblake@redhat.com> Reviewed-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
-
由 Peter Maydell 提交于
Block layer patches: - hmp: Fix drive_add ... format=help crash - block: Forward 'discard' to temporary overlay # gpg: Signature made Mon 08 Apr 2019 16:43:20 BST # gpg: using RSA key 7F09B272C88F2FD6 # gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>" [full] # Primary key fingerprint: DC3D EB15 9A9A F95D 3D74 56FE 7F09 B272 C88F 2FD6 * remotes/kevin/tags/for-upstream: hmp: Fix drive_add ... format=help crash block: Forward 'discard' to temporary overlay Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
- 08 4月, 2019 8 次提交
-
-
由 Markus Armbruster 提交于
drive_new() returns null without setting an error when it provided help. add_init_drive() assumes null means failure, and crashes trying to report a null error. Fixes: c4f26c9f Cc: qemu-stable@nongnu.org Signed-off-by: NMarkus Armbruster <armbru@redhat.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Daniel P. Berrangé 提交于
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: NDaniel P. Berrangé <berrange@redhat.com> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Reviewed-by: NLaurent Vivier <laurent@vivier.eu> Message-Id: <20190320161842.13908-3-berrange@redhat.com> Signed-off-by: NLaurent Vivier <laurent@vivier.eu>
-
由 Daniel P. Berrangé 提交于
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: NDaniel P. Berrangé <berrange@redhat.com> Reviewed-by: NRichard Henderson <richard.henderson@linaro.org> Reviewed-by: NLaurent Vivier <laurent@vivier.eu> Message-Id: <20190320161842.13908-2-berrange@redhat.com> Signed-off-by: NLaurent Vivier <laurent@vivier.eu>
-
由 Kevin Wolf 提交于
When bdrv_temp_snapshot_options() is called for snapshot=on, the 'discard' option in the options QDict hasn't been parsed and merged into the flags yet. So copy the dict entry to make sure that the temporary overlay enables discard when it was requested for the drive. Signed-off-by: NKevin Wolf <kwolf@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NStefano Garzarella <sgarzare@redhat.com> Reviewed-by: NAlberto Garcia <berto@igalia.com>
-
由 Peter Maydell 提交于
- 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: NPeter Maydell <peter.maydell@linaro.org>
-
由 Dr. David Alan Gilbert 提交于
The test uses the trick: if (!opts) { opts = &(QOSGraph...Options) { }; } in a couple of places, however the temporary created by the &() {} goes out of scope at the bottom of the if, and results in a seg or assert when opts-> fields are used (on fedora 30's gcc 9). Fixes: fc281c80Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Message-Id: <20190405184037.16799-1-dgilbert@redhat.com> Signed-off-by: NThomas Huth <thuth@redhat.com>
-
由 Jafar Abdi 提交于
Clean up wrong usage of FALSE and TRUE in places that use "bool" from stdbool.h. FALSE and TRUE (with capital letters) are the constants defined by glib for being used with the "gboolean" type of glib. But some parts of the code also use TRUE and FALSE for variables that are declared as "bool" (the type from <stdbool.h>). Signed-off-by: NJafar Abdi <cafer.abdi@gmail.com> Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Acked-by: NDavid Gibson <david@gibson.dropbear.id.au> Message-Id: <1553351197-14581-4-git-send-email-cafer.abdi@gmail.com> Signed-off-by: NThomas Huth <thuth@redhat.com>
-
由 Jafar Abdi 提交于
Clean up wrong usage of FALSE and TRUE in places that use "bool" from stdbool.h. FALSE and TRUE (with capital letters) are the constants defined by glib for being used with the "gboolean" type of glib. But some parts of the code also use TRUE and FALSE for variables that are declared as "bool" (the type from <stdbool.h>). Signed-off-by: NJafar Abdi <cafer.abdi@gmail.com> Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Message-Id: <1553351197-14581-3-git-send-email-cafer.abdi@gmail.com> Signed-off-by: NThomas Huth <thuth@redhat.com>
-
- 07 4月, 2019 1 次提交
-
-
由 Peter Maydell 提交于
pci, pc, virtio: fixes intel-iommu fixes virtio typo fixes linker: a couple of asserts for consistency/security Signed-off-by: NMichael 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: NPeter Maydell <peter.maydell@linaro.org>
-
- 06 4月, 2019 1 次提交
-
-
由 Peter Maydell 提交于
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: NPeter Maydell <peter.maydell@linaro.org>
-
- 05 4月, 2019 7 次提交
-
-
由 Juan Quintela 提交于
Otherwise we are setting err twice, what is wrong and causes an abort. Signed-off-by: NJuan Quintela <quintela@redhat.com> Message-Id: <20190403114958.3705-2-quintela@redhat.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
由 Zhang Chen 提交于
I found upstream codes conflict with COLO and lead to crash, and I located to this patch: commit 386a907b 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: NZhang Chen <chen.zhang@intel.com> Message-Id: <20190329222951.28945-1-chen.zhang@intel.com> Reviewed-by: NWei Wang <wei.w.wang@intel.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
-
由 Peter Maydell 提交于
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: NPeter Maydell <peter.maydell@linaro.org>
-
由 Peter Maydell 提交于
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: NPeter Maydell <peter.maydell@linaro.org>
-
由 Alistair Francis 提交于
Instead of using error_report() to print guest errors let's use qemu_log_mask(LOG_GUEST_ERROR,...) to log the error. Signed-off-by: NAlistair Francis <alistair.francis@wdc.com> Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>
-
由 Alistair Francis 提交于
This patch fixes four different things, to maintain bisectability they have been merged into a single patch. The following fixes are below: sifive_plic: Fix incorrect irq calculation The irq is incorrectly calculated to be off by one. It has worked in the past as the priority_base offset has also been set incorrectly. We are about to fix the priority_base offset so first first the irq calculation. sifive_u: Fix PLIC priority base offset and numbering According to the FU540 manual the PLIC source priority address starts at an offset of 0x04 and not 0x00. The same manual also specifies that the PLIC only has 53 source priorities. Fix these two incorrect header files. We also need to over extend the plic_gpios[] array as the PLIC sources count from 1 and not 0. riscv: sifive_e: Fix PLIC priority base offset According to the FE31 manual the PLIC source priority address starts at an offset of 0x04 and not 0x00. riscv: virt: Fix PLIC priority base offset Update the virt offsets based on the newly updated SiFive U and SiFive E offsets. Signed-off-by: NAlistair Francis <alistair.francis@wdc.com> Signed-off-by: NPalmer Dabbelt <palmer@sifive.com>
-
由 Paul Durrant 提交于
The Xen blkif protocol requires that sector based quantities should be interpreted strictly as multiples of 512 bytes. Specifically: "first_sect and last_sect in blkif_request_segment, as well as sector_number in blkif_request, are always expressed in 512-byte units." Commit fcab2b46 "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: NPaul Durrant <paul.durrant@citrix.com> Reviewed-by: NAnthony PERARD <anthony.perard@citrix.com> Message-Id: <20190401121719.27208-1-paul.durrant@citrix.com> Signed-off-by: NAnthony PERARD <anthony.perard@citrix.com>
-
- 04 4月, 2019 1 次提交
-
-
由 Paul Durrant 提交于
...and properly enable it when synthesizing a drive. The Xen toolstack sets 'discard-enable' to '1' in xenstore when it wants to enable discard on a specified image. The code in xen_block_drive_create() correctly parses this and uses it to set 'discard' to 'unmap' for the file_layer, but fails to do the same for the driver_layer (which effectively disables it). Meanwhile the code in xen_block_realize() advertizes discard support to the frontend in the default case (because conf->discard_granularity defaults to -1), even when the underlying image may not handle it. This patch adds the missing option to the driver_layer in xen_block_driver_create() and checks whether BDRV_O_UNMAP is actually set on the block device before advertizing discard to the frontend. In the case that discard is supported it also makes sure that the granularity is set to the physical block size. Signed-off-by: NPaul Durrant <paul.durrant@citrix.com> Reviewed-by: NAnthony PERARD <anthony.perard@citrix.com> Message-Id: <20190320142825.24565-1-paul.durrant@citrix.com> Signed-off-by: NAnthony PERARD <anthony.perard@citrix.com>
-
- 03 4月, 2019 2 次提交
-
-
由 Peter Maydell 提交于
Fix taking address of fields in packed structs warnings by gcc 9 # gpg: Signature made Wed 03 Apr 2019 10:58:42 BST # gpg: using RSA key C3D0D66DC3624FF6A8C018CEDECF6B93C6F02FAF # gpg: issuer "cohuck@redhat.com" # gpg: Good signature from "Cornelia Huck <conny@cornelia-huck.de>" [unknown] # gpg: aka "Cornelia Huck <huckc@linux.vnet.ibm.com>" [full] # gpg: aka "Cornelia Huck <cornelia.huck@de.ibm.com>" [full] # gpg: aka "Cornelia Huck <cohuck@kernel.org>" [unknown] # gpg: aka "Cornelia Huck <cohuck@redhat.com>" [unknown] # Primary key fingerprint: C3D0 D66D C362 4FF6 A8C0 18CE DECF 6B93 C6F0 2FAF * remotes/cohuck/tags/s390x-20190403: hw/s390x/3270-ccw: avoid taking address of fields in packed struct hw/s390x/ipl: avoid taking address of fields in packed struct hw/s390/css: avoid taking address members in packed structs hw/vfio/ccw: avoid taking address members in packed structs Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Daniel P. Berrangé 提交于
Compiling with GCC 9 complains hw/s390x/3270-ccw.c: In function ‘emulated_ccw_3270_cb’: hw/s390x/3270-ccw.c:81:19: error: taking address of packed member of ‘struct SCHIB’ may result in an unaligned pointer value [-Werror=address-of-packed-member] 81 | SCSW *s = &sch->curr_status.scsw; | ^~~~~~~~~~~~~~~~~~~~~~ This local variable is only present to save a little bit of typing when setting the field later. Get rid of this to avoid the warning about unaligned accesses. Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com> Message-Id: <20190329111104.17223-15-berrange@redhat.com> Reviewed-by: NDavid Hildenbrand <david@redhat.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-