- 28 11月, 2017 4 次提交
-
-
由 Eric Blake 提交于
Introduced in commit f37708f6 (2.10). The NBD spec says a client can request export names up to 4096 bytes in length, even though they should not expect success on names longer than 256. However, qemu hard-codes the limit of 256, and fails to filter out a client that probes for a longer name; the result is a stack smash that can potentially give an attacker arbitrary control over the qemu process. The smash can be easily demonstrated with this client: $ qemu-io f raw nbd://localhost:10809/$(printf %3000d 1 | tr ' ' a) If the qemu NBD server binary (whether the standalone qemu-nbd, or the builtin server of QMP nbd-server-start) was compiled with -fstack-protector-strong, the ability to exploit the stack smash into arbitrary execution is a lot more difficult (but still theoretically possible to a determined attacker, perhaps in combination with other CVEs). Still, crashing a running qemu (and losing the VM) is bad enough, even if the attacker did not obtain full execution control. CC: qemu-stable@nongnu.org Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Eric Blake 提交于
The NBD spec gives us permission to abruptly disconnect on clients that send outrageously large option requests, rather than having to spend the time reading to the end of the option. No real option request requires that much data anyways; and meanwhile, we already have the practice of abruptly dropping the connection on any client that sends NBD_CMD_WRITE with a payload larger than 32M. For comparison, nbdkit drops the connection on any request with more than 4096 bytes; however, that limit is probably too low (as the NBD spec states an export name can theoretically be up to 4096 bytes, which means a valid NBD_OPT_INFO could be even longer) - even if qemu doesn't permit exports longer than 256 bytes. It could be argued that a malicious client trying to get us to read nearly 4G of data on a bad request is a form of denial of service. In particular, if the server requires TLS, but a client that does not know the TLS credentials sends any option (other than NBD_OPT_STARTTLS or NBD_OPT_EXPORT_NAME) with a stated payload of nearly 4G, then the server was keeping the connection alive trying to read all the payload, tying up resources that it would rather be spending on a client that can get past the TLS handshake. Hence, this warranted a CVE. Present since at least 2.5 when handling known options, and made worse in 2.6 when fixing support for NBD_FLAG_C_FIXED_NEWSTYLE to handle unknown options. CC: qemu-stable@nongnu.org Signed-off-by: NEric Blake <eblake@redhat.com>
-
由 Peter Maydell 提交于
# gpg: Signature made Tue 28 Nov 2017 03:58:11 GMT # gpg: using RSA key 0xEF04965B398D6211 # gpg: Good signature from "Jason Wang (Jason Wang on RedHat) <jasowang@redhat.com>" # 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: virtio-net: don't touch virtqueue if vm is stopped Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Jason Wang 提交于
Guest state should not be touched if VM is stopped, unfortunately we didn't check running state and tried to drain tx queue unconditionally in virtio_net_set_status(). A crash was then noticed as a migration destination when user type quit after virtqueue state is loaded but before region cache is initialized. In this case, virtio_net_drop_tx_queue_data() tries to access the uninitialized region cache. Fix this by only dropping tx queue data when vm is running. Fixes: 283e2c2a ("net: virtio-net discards TX data after link down") Cc: Yuri Benditovich <yuri.benditovich@daynix.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Stefan Hajnoczi <stefanha@redhat.com> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: qemu-stable@nongnu.org Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com> Signed-off-by: NJason Wang <jasowang@redhat.com>
-
- 27 11月, 2017 3 次提交
-
-
由 Peter Maydell 提交于
ppc patch queue 2017-11-27 This series contains a couple of migration fixes for hash guests on POWER9 radix MMU hosts. # gpg: Signature made Mon 27 Nov 2017 04:27:15 GMT # gpg: using RSA key 0x6C38CACA20D9B392 # gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" # gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" # gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" # gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>" # Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392 * remotes/dgibson/tags/ppc-for-2.11-20171127: target/ppc: Fix setting of cpu->compat_pvr on incoming migration target/ppc: Move setting of patb_entry on hash table init Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Suraj Jitindar Singh 提交于
cpu->compat_pvr is used to store the current compat mode of the cpu. On the receiving side during incoming migration we check compatibility with the compat mode by calling ppc_set_compat(). However we fail to set the compat mode with the hypervisor since the "new" compat mode doesn't differ from the current (due to a "cpu->compat_pvr != compat_pvr" check). This means that kvm runs the vcpus without a compat mode, which is the incorrect behaviour. The implication being that a compatibility mode will never be in effect after migration. To fix this so that the compat mode is correctly set with the hypervisor, store the desired compat mode and reset cpu->compat_pvr to zero before calling ppc_set_compat(). Fixes: 5dfaa532 ("ppc: fix ppc_set_compat() with KVM PR") Signed-off-by: NSuraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Suraj Jitindar Singh 提交于
The patb_entry is used to store the location of the process table in guest memory. The msb is also used to indicate the mmu mode of the guest, that is patb_entry & 1 << 63 ? radix_mode : hash_mode. Currently we set this to zero in spapr_setup_hpt_and_vrma() since if this function gets called then we know we're hash. However some code paths, such as setting up the hpt on incoming migration of a hash guest, call spapr_reallocate_hpt() directly bypassing this higher level function. Since we assume radix if the host is capable this results in the msb in patb_entry being left set so in spapr_post_load() we call kvmppc_configure_v3_mmu() and tell the host we're radix which as expected means addresses cannot be translated once we actually run the cpu. To fix this move the zeroing of patb_entry into spapr_reallocate_hpt(). Signed-off-by: NSuraj Jitindar Singh <sjitindarsingh@gmail.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
- 24 11月, 2017 5 次提交
-
-
由 Peter Maydell 提交于
In our various supported host OSes, the time_t type may be either 32 or 64 bit, and could in theory also be either signed or unsigned. Notably, in OpenBSD time_t is a 64 bit type even if 'long' is 32 bits, so using LONG_MAX for TIME_MAX is incorrect. Use an approach suggested by Paolo Bonzini which calculates the maximum value of the type rather than hardcoding it; to do this we use the TYPE_MAXIMUM macro from Gnulib. Suggested-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org> Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com> Message-id: 1511452598-6077-1-git-send-email-peter.maydell@linaro.org
-
由 Eric Auger 提交于
Add virt-2.11 machine type. Signed-off-by: NEric Auger <eric.auger@redhat.com> Message-id: 1511516626-21178-1-git-send-email-eric.auger@redhat.com Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Peter Maydell 提交于
Deal with the fallout from the deletion of the old s390 virtio header in Linux master. # gpg: Signature made Fri 24 Nov 2017 09:56:49 GMT # gpg: using RSA key 0xDECF6B93C6F02FAF # gpg: Good signature from "Cornelia Huck <conny@cornelia-huck.de>" # gpg: aka "Cornelia Huck <huckc@linux.vnet.ibm.com>" # gpg: aka "Cornelia Huck <cornelia.huck@de.ibm.com>" # gpg: aka "Cornelia Huck <cohuck@kernel.org>" # gpg: aka "Cornelia Huck <cohuck@redhat.com>" # Primary key fingerprint: C3D0 D66D C362 4FF6 A8C0 18CE DECF 6B93 C6F0 2FAF * remotes/cohuck/tags/s390x-20171124: s390/kvm_virtio/linux-headers: remove traces of old virtio transport Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Christian Borntraeger 提交于
We no longer support the old s390 transport, neither does the newest Linux kernel. Remove it from the linux header script as well as the s390x virtio code. We still should handle the VIRTIO_NOTIFY hypercall, to tolerate early printk on older guest kernels without an sclp console. We continue to ignore these events. Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com> Message-Id: <20171115154223.109991-1-borntraeger@de.ibm.com> Signed-off-by: NCornelia Huck <cohuck@redhat.com>
-
由 Brad Smith 提交于
OpenBSD/i386 uses elf_i386_obsd for the emulation linker. Signed-off-by: NBrad Smith <brad@comstyle.com> Message-id: 20171107234608.GA395@humpty.home.comstyle.com Reviewed-by: NPeter Maydell <peter.maydell@linaro.org> Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
- 23 11月, 2017 4 次提交
-
-
由 Peter Maydell 提交于
migration/next for 20171122 # gpg: Signature made Wed 22 Nov 2017 08:43:13 GMT # gpg: using RSA key 0xF487EF185872D723 # gpg: Good signature from "Juan Quintela <quintela@redhat.com>" # gpg: aka "Juan Quintela <quintela@trasno.org>" # Primary key fingerprint: 1899 FF8E DEBF 58CC EE03 4B82 F487 EF18 5872 D723 * remotes/juanquintela/tags/migration/20171122: migration/ram.c: do not set 'postcopy_running' in POSTCOPY_INCOMING_END migration, xen: Fix block image lock issue on live migration Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Peter Maydell 提交于
ppc patch queue 2017-11-22 Several more fixes to merge for qemu-2.11. # gpg: Signature made Wed 22 Nov 2017 04:29:57 GMT # gpg: using RSA key 0x6C38CACA20D9B392 # gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" # gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" # gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" # gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>" # Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392 * remotes/dgibson/tags/ppc-for-2.11-20171122: ppc: fix VTB migration spapr: Implement bug in spapr-vty device to be compatible with PowerVM hw/ppc/spapr: Fix virtio-scsi bootindex handling for LUNs >= 256 Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Stefan Weil 提交于
It was broken by commit 8ecc89f6 which moved the SDL linker flags from macro libs_softmmu to macro SDL_LIBS. Signed-off-by: NStefan Weil <sw@weilnetz.de> Message-id: 20171116163732.31584-1-sw@weilnetz.de Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Juan Quintela 提交于
Commit 27266271 started to use tb_unlock() and tlb_set_dirty() on non TCG code. Add the functions as stubs, so that builds with TCG disabled continue to compile. Signed-off-by: NJuan Quintela <quintela@redhat.com> Acked-by: NRichard Henderson <richard.henderson@linaro.org> Reviewed-by: NPhilippe Mathieu-Daudé <f4bug@amsat.org> [PMM: tweaked commit message] Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
- 22 11月, 2017 11 次提交
-
-
由 Daniel Henrique Barboza 提交于
When migrating a VM with 'migrate_set_capability postcopy-ram on' a postcopy_state is set during the process, ending up with the state POSTCOPY_INCOMING_END when the migration is over. This postcopy_state is taken into account inside ram_load to check how it will load the memory pages. This same ram_load is called when in a loadvm command. Inside ram_load, the logic to see if we're at postcopy_running state is: postcopy_running = postcopy_state_get() >= POSTCOPY_INCOMING_LISTENING postcopy_state_get() returns this enum type: typedef enum { POSTCOPY_INCOMING_NONE = 0, POSTCOPY_INCOMING_ADVISE, POSTCOPY_INCOMING_DISCARD, POSTCOPY_INCOMING_LISTENING, POSTCOPY_INCOMING_RUNNING, POSTCOPY_INCOMING_END } PostcopyState; In the case where ram_load is executed and postcopy_state is POSTCOPY_INCOMING_END, postcopy_running will be set to 'true' and ram_load will behave like a postcopy is in progress. This scenario isn't achievable in a migration but it is reproducible when executing savevm/loadvm after migrating with 'postcopy-ram on', causing loadvm to fail with Error -22: Source: (qemu) migrate_set_capability postcopy-ram on (qemu) migrate tcp:127.0.0.1:4444 Dest: (qemu) migrate_set_capability postcopy-ram on (qemu) ubuntu1704-intel login: Ubuntu 17.04 ubuntu1704-intel ttyS0 ubuntu1704-intel login: (qemu) (qemu) savevm test1 (qemu) loadvm test1 Unknown combination of migration flags: 0x4 (postcopy mode) error while loading state for instance 0x0 of device 'ram' Error -22 while loading VM state (qemu) This patch fixes this problem by changing the existing logic for postcopy_advised and postcopy_running in ram_load, making them 'false' if we're at POSTCOPY_INCOMING_END state. Signed-off-by: NDaniel Henrique Barboza <danielhb@linux.vnet.ibm.com> CC: Juan Quintela <quintela@redhat.com> CC: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: NPeter Xu <peterx@redhat.com> Reviewed-by: NJuan Quintela <quintela@redhat.com> Reported-by: NBalamuruhan S <bala24@linux.vnet.ibm.com> Signed-off-by: NJuan Quintela <quintela@redhat.com>
-
由 Laurent Vivier 提交于
Migration of a system under stress (for example, with "stress-ng --numa 2") triggers on the destination some kernel watchdog messages like: NMI watchdog: BUG: soft lockup - CPU#0 stuck for 3489660870s! NMI watchdog: BUG: soft lockup - CPU#1 stuck for 3489660884s! This problem appears with the changes introduced by 42043e4f spapr: clock should count only if vm is running I think this commit only triggers the problem. Kernel computes the soft lockup duration using the Virtual Timebase register (VTB), not using the Timebase Register (TBR, the one 42043e4f stops). It appears VTB is not migrated, so this patch adds it in the list of the SPRs to migrate, and fixes the problem. For the migration, I've tested a migration from qemu-2.8.0 and pseries-2.8.0 to a patched master (qemu-2.11.0-rc1). The received VTB is 0 (as is it not initialized by qemu-2.8.0), but the value seems to be ignored by KVM and a non zero VTB is used by the kernel. I have no explanation for that, but as the original problem appears only with SMP system under stress I suspect some problems in KVM (I think because VTB is shared by all threads of a core). Signed-off-by: NLaurent Vivier <lvivier@redhat.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 David Gibson 提交于
The spapr-vty device implements the PAPR defined virtual console, which is also implemented by IBM's proprietary PowerVM hypervisor. PowerVM's implementation has a bug where it inserts an extra \0 after every \r going to the guest. Because of that Linux's guest side driver has a workaround which strips \0 characters that appear immediately after a \r. That means that when running under qemu, sending a binary stream from host to guest via spapr-vty which happens to include a \r\0 sequence will get corrupted by that workaround. To deal with that, this patch duplicates PowerVM's bug, inserting an extra \0 after each \r. Ugly, but the best option available. Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au> Reviewed-by: NThomas Huth <thuth@redhat.com> Reviewed-by: NGreg Kurz <groug@kaod.org>
-
由 Thomas Huth 提交于
LUNs >= 256 have to be encoded with the so-called "flat space addressing method" for virtio-scsi, where an additional bit has to be set. SLOF already took care of this with the following commit: https://git.qemu.org/?p=SLOF.git;a=commitdiff;h=f72a37713fea47da (see https://bugzilla.redhat.com/show_bug.cgi?id=1431584 for details) But QEMU does not use this encoding yet for device tree paths that have to be handed over to SLOF to deal with the "bootindex" property, so SLOF currently fails to boot from virtio-scsi devices with LUNs >= 256 in the right boot order. Fix it by using the bit to indicate the "flat space addressing method" for LUNs >= 256. Signed-off-by: NThomas Huth <thuth@redhat.com> Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
-
由 Anthony PERARD 提交于
When doing a live migration of a Xen guest with libxl, the images for block devices are locked by the original QEMU process, and this prevent the QEMU at the destination to take the lock and the migration fail. >From QEMU point of view, once the RAM of a domain is migrated, there is two QMP commands, "stop" then "xen-save-devices-state", at which point a new QEMU is spawned at the destination. Release locks in "xen-save-devices-state" so the destination can takes them, if it's a live migration. This patch add the "live" parameter to "xen-save-devices-state" which default to true so older version of libxenlight can work with newer version of QEMU. Signed-off-by: NAnthony PERARD <anthony.perard@citrix.com> Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: NJuan Quintela <quintela@redhat.com> Signed-off-by: NJuan Quintela <quintela@redhat.com>
-
由 Peter Maydell 提交于
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Peter Maydell 提交于
# gpg: Signature made Tue 21 Nov 2017 17:01:33 GMT # gpg: using RSA key 0xBDBE7B27C0DE3057 # gpg: Good signature from "Jeffrey Cody <jcody@redhat.com>" # gpg: aka "Jeffrey Cody <jeff@codyprime.org>" # gpg: aka "Jeffrey Cody <codyprime@gmail.com>" # Primary key fingerprint: 9957 4B4D 3474 90E7 9D98 D624 BDBE 7B27 C0DE 3057 * remotes/cody/tags/block-pull-request: qemu-iotest: add test for blockjob coroutine race condition qemu-iotests: add option in common.qemu for mismatch only coroutine: abort if we try to schedule or enter a pending coroutine blockjob: do not allow coroutine double entry or entry-after-completion Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Jeff Cody 提交于
Signed-off-by: NJeff Cody <jcody@redhat.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
-
由 Jeff Cody 提交于
Add option to echo response to QMP / HMP command only on mismatch. Useful for ignore all normal responses, but catching things like segfaults. Signed-off-by: NJeff Cody <jcody@redhat.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
-
由 Jeff Cody 提交于
The previous patch fixed a race condition, in which there were coroutines being executing doubly, or after coroutine deletion. We can detect common scenarios when this happens, and print an error message and abort before we corrupt memory / data, or segfault. This patch will abort if an attempt to enter a coroutine is made while it is currently pending execution, either in a specific AioContext bh, or pending execution via a timer. It will also abort if a coroutine is scheduled, before a prior scheduled run has occurred. We cannot rely on the existing co->caller check for recursive re-entry to catch this, as the coroutine may run and exit with COROUTINE_TERMINATE before the scheduled coroutine executes. (This is the scenario that was occurring and fixed in the previous patch). This patch also re-orders the Coroutine struct elements in an attempt to optimize caching. Signed-off-by: NJeff Cody <jcody@redhat.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
-
由 Jeff Cody 提交于
When block_job_sleep_ns() is called, the co-routine is scheduled for future execution. If we allow the job to be re-entered prior to the scheduled time, we present a race condition in which a coroutine can be entered recursively, or even entered after the coroutine is deleted. The job->busy flag is used by blockjobs when a coroutine is busy executing. The function 'block_job_enter()' obeys the busy flag, and will not enter a coroutine if set. If we sleep a job, we need to leave the busy flag set, so that subsequent calls to block_job_enter() are prevented. This changes the prior behavior of block_job_cancel() being able to immediately wake up and cancel a job; in practice, this should not be an issue, as the coroutine sleep times are generally very small, and the cancel will occur the next time the coroutine wakes up. This fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1508708Signed-off-by: NJeff Cody <jcody@redhat.com> Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
-
- 21 11月, 2017 13 次提交
-
-
由 Peter Maydell 提交于
Block layer patches for 2.11.0-rc2 # gpg: Signature made Tue 21 Nov 2017 15:09:12 GMT # gpg: using RSA key 0x7F09B272C88F2FD6 # gpg: Good signature from "Kevin Wolf <kwolf@redhat.com>" # Primary key fingerprint: DC3D EB15 9A9A F95D 3D74 56FE 7F09 B272 C88F 2FD6 * remotes/kevin/tags/for-upstream: iotests: Fix 176 on 32-bit host block: Close a BlockDriverState completely even when bs->drv is NULL block: Error out on load_vm with active dirty bitmaps block: Add errp to bdrv_all_goto_snapshot() block: Add errp to bdrv_snapshot_goto() block: Don't request I/O permission with BDRV_O_NO_IO block: Don't use BLK_PERM_CONSISTENT_READ for format probing Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Daniel P. Berrange 提交于
Developers sometimes mistakenly run 'make test' instead of 'make check'. 'make test' triggers the ancient, unmaintained tcg unit tests in tests/tcg/Makefile which have long since ceased compiling. Even if someone fixes the TCG tests, it makes little sense to put them in a 'make test' target, rather they should be 'make check-tcg', possibly wired up as a dependency of 'make check'. In the meantime, this patch disarms the 'make test' trap by simply deleting it so users get an immediate error. This should be enough for them to remember to type 'make check' instead (or 'make help' to learn). It also deletes 'make speed' which is another route into the tcg tests. Signed-off-by: NDaniel P. Berrange <berrange@redhat.com> Reviewed-by: NKashyap Chamarthy <kchamart@redhat.com> Reviewed-by: NDaniel Henrique Barboza <danielhb@linux.vnet.ibm.com> Message-id: 20171121142538.22072-1-berrange@redhat.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Kevin Wolf 提交于
Block patches for 2.11.0-rc2 # gpg: Signature made Tue Nov 21 14:54:28 2017 CET # gpg: using RSA key F407DB0061D5CF40 # gpg: Good signature from "Max Reitz <mreitz@redhat.com>" # Primary key fingerprint: 91BE B60A 30DB 3E88 57D1 1829 F407 DB00 61D5 CF40 * mreitz/tags/pull-block-2017-11-21: iotests: Fix 176 on 32-bit host block: Close a BlockDriverState completely even when bs->drv is NULL Signed-off-by: NKevin Wolf <kwolf@redhat.com>
-
由 Eric Blake 提交于
The contents of a qcow2 bitmap are rounded up to a size that matches the number of bits available for the granularity, but that granularity differs for 32-bit hosts (our default 64k cluster allows for 2M bitmap coverage per 'long') and 64-bit hosts (4M bitmap per 'long'). If the image is a multiple of 2M but not 4M, then the number of bytes occupied by the array of longs in memory differs between architecture, thus resulting in different SHA256 hashes. Furthermore (but untested by me), if our computation of the SHA256 hash is at all endian-dependent because of how we store data in memory, that's another variable we'd have to account for (ideally, we specified the bitmap stored in qcow2 as fixed-endian on disk, because the same qcow2 file must be usable across any architecture; but that says nothing about how we represent things in memory). But we already have test 165 to validate that bitmaps are stored correctly on disk, while this test is merely testing that the bitmap exists. So for this test, the easiest solution is to filter out the actual hash value. Broken in commit 4096974e. Reported-by: NMax Reitz <mreitz@redhat.com> Signed-off-by: NEric Blake <eblake@redhat.com> Message-id: 20171117190422.23626-1-eblake@redhat.com Reviewed-by: NJohn Snow <jsnow@redhat.com> Reviewed-by: NMax Reitz <mreitz@redhat.com> Signed-off-by: NMax Reitz <mreitz@redhat.com>
-
由 Alberto Garcia 提交于
bdrv_close() skips much of its logic when bs->drv is NULL. This is fine when we're closing a BlockDriverState that has just been created (because e.g the initialization process failed), but it's not enough in other cases. For example, when a valid qcow2 image is found to be corrupted then QEMU marks it as such in the file header and then sets bs->drv to NULL in order to make the BlockDriverState unusable. When that BDS is later closed then many of its data structures are not freed (leaking their memory) and none of its children are detached. This results in bdrv_close_all() failing to close all BDSs and making this assertion fail when QEMU is being shut down: bdrv_close_all: Assertion `QTAILQ_EMPTY(&all_bdrv_states)' failed. This patch makes bdrv_close() do the full uninitialization process in all cases. This fixes the problem with corrupted images and still works fine with freshly created BDSs. Signed-off-by: NAlberto Garcia <berto@igalia.com> Message-id: 20171106145345.12038-1-berto@igalia.com Reviewed-by: NEric Blake <eblake@redhat.com> Signed-off-by: NMax Reitz <mreitz@redhat.com>
-
由 Kevin Wolf 提交于
Loading a snapshot invalidates the bitmap. Just marking all blocks dirty is not a useful response in practice, instead the user needs to be aware that we switch to a completely different state. If they are okay with losing the dirty bitmap, they can just explicitly delete it. This effectively reverts commit 04dec3c3. Signed-off-by: NKevin Wolf <kwolf@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NDenis V. Lunev <den@openvz.org> Reviewed-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: NJohn Snow <jsnow@redhat.com>
-
由 Kevin Wolf 提交于
Signed-off-by: NKevin Wolf <kwolf@redhat.com> Reviewed-by: NEric Blake <eblake@redhat.com> Reviewed-by: NDenis V. Lunev <den@openvz.org> Reviewed-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: NJohn Snow <jsnow@redhat.com>
-
由 Kevin Wolf 提交于
Signed-off-by: NKevin Wolf <kwolf@redhat.com> Reviewed-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Reviewed-by: NJohn Snow <jsnow@redhat.com>
-
由 Kevin Wolf 提交于
'qemu-img info' makes sense even when BLK_PERM_CONSISTENT_READ cannot be granted because of a block job in a running qemu process. It already sets BDRV_O_NO_IO to indicate that it doesn't access the guest visible data at all. Check the BDRV_O_NO_IO flags in blk_new_open(), so that I/O related permissions are not unnecessarily requested and 'qemu-img info' can work even if BLK_PERM_CONSISTENT_READ cannot be granted. Signed-off-by: NKevin Wolf <kwolf@redhat.com> Reviewed-by: NFam Zheng <famz@redhat.com> Reviewed-by: NAlberto Garcia <berto@igalia.com>
-
由 Kevin Wolf 提交于
For format probing, we don't really care whether all of the image content is consistent. The only thing we're looking at is the image header, and specifically the magic numbers that are expected to never change, no matter how inconsistent the guest visible disk content is. Therefore, don't request BLK_PERM_CONSISTENT_READ. This allows to use format probing, e.g. in the context of 'qemu-img info', even while the guest visible data in the image is inconsistent during a running block job. Signed-off-by: NKevin Wolf <kwolf@redhat.com> Reviewed-by: NFam Zheng <famz@redhat.com>
-
由 Stefan Hajnoczi 提交于
qemu.org enabled HTTPS in 2017 and it should be used instead of HTTP. There are also URLs to json.org, openvpn.net, and other domains that support HTTPS. This patch updates the qemu.org domains everywhere and also third-party domains that I have checked. Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com> Message-id: 20171121120435.28728-3-stefanha@redhat.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Stefan Hajnoczi 提交于
The owner of qemu.org has delegated authority to modify DNS records to the QEMU Project. This has allowed us to use the domain name without worries about IP address changes or technical issues disrupting service. The issues described in commit 85938981 ("Use qemu-project.org domain name") have therefore been mitigated. This patch switches back to consistently using qemu.org instead of qemu-project.org in documentation, version.rc, and the Windows installer script. The git submodules and SeaBIOS still use qemu-project.org for the time being. This will be fixed in the QEMU 2.12 release cycle. Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com> Message-id: 20171121120435.28728-2-stefanha@redhat.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-
由 Michael Roth 提交于
The u-boot sources we ship currently cause problems with unpacking on a case-insensitive filesystem due to path conflicts. This has been fixed in upstream u-boot via commit 610eec7f, but since it is not yet included in an official release we implement this approach as a temporary workaround. Once we move to a u-boot containing commit 610eec7f we should revert this patch. Cc: qemu-stable@nongnu.org Cc: Alexander Graf <agraf@suse.de> Cc: Richard Henderson <richard.henderson@linaro.org> Cc: Thomas Huth <thuth@redhat.com> Cc: Peter Maydell <peter.maydell@linaro.org> Suggested-by: NRichard Henderson <richard.henderson@linaro.org> Signed-off-by: NMichael Roth <mdroth@linux.vnet.ibm.com> Reviewed-by: NThomas Huth <thuth@redhat.com> Message-id: 20171107205201.10207-1-mdroth@linux.vnet.ibm.com Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
-