Select Git revision
Search by author
- Any Author
- authors
-
Adrien Ricciardi
RICCIARDI-Adrien-BayLibre
-
Alexandre Bailon abailon
-
Andrew Stubbs
ams
-
Anne Françoise Gros afgros
-
BayLibreCI baylibreCI
-
Bernhard Rosenkränzer
bero
-
Carlo Caione carlo.caione
-
Christophe Baylibre
BLChristopheCBO
-
Drew Fustini dfustini
-
Guillaume LA ROQUE glaroque
-
Guillaume Pain gpain
-
Guillaume Ranquet granquet
-
Jeremy Robinson jrobinson
-
Jerome Brunet
jbrunet
-
Julien Masson
JulienMasson
-
Julien Morin
jmorin2
-
Julien Stephan jstephan
-
Jérémie Garcia jgarcia
-
Kevin Hilman khilman
-
Markus Schneider-Pargmann msp8
- Jan 22, 2015
-
-
Michael Roth authored
Signed-off-by:Michael Roth <mdroth@linux.vnet.ibm.com>
-
- Jan 15, 2015
-
-
Marcel Apfelbaum authored
After 'Machine as QOM' series the machine type input triggers the creation of the machine class. If the machine type is set in the configuration file, the machine class is not updated accordingly and remains the default. Fixed that by querying the machine options after the configuration file is loaded. Cc: qemu-stable@nongnu.org Reported-by:
William Dauchy <william@gandi.net> Signed-off-by:
Marcel Apfelbaum <marcel@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> (cherry picked from commit 364c3e6b) Signed-off-by:
-
David Gibson authored
spapr_tce_table_finalize() can SEGV if the object was not previously realized. In particular this can be triggered by running qemu-system-ppc -device spapr-tce-table,? The basic problem is that we have mismatched initialization versus finalization: spapr_tce_table_finalize() is attempting to undo things that are done in spapr_tce_table_realize(), not an instance_init function. Therefore, replace spapr_tce_table_finalize() with spapr_tce_table_unrealize(). Signed-off-by:David Gibson <david@gibson.dropbear.id.au> Cc: qemu-stable@nongnu.org Signed-off-by:
Alexander Graf <agraf@suse.de> (cherry picked from commit 5f9490de) Signed-off-by:
-
Paolo Bonzini authored
What needs to be volatile is not the pointer, but the pointed-to value! Cc: qemu-stable@nongnu.org Signed-off-by:
-
Vladimir Sementsov-Ogievskiy authored
Because of wrong return value of .save_live_pending() in migration/block.c, migration finishes before the whole disk is transferred. Such situation occurs when the migration process is fast enough, for example when source and dest are on the same host. If in the bulk phase we return something < max_size, we will skip transferring the tail of the device. Currently we have "set pending to BLOCK_SIZE if it is zero" for bulk phase, but there no guarantee, that it will be < max_size. True approach is to return, for example, max_size+1 when we are in the bulk phase. Signed-off-by:
Vladimir Sementsov-Ogievskiy <vsementsov@parallels.com> Message-id: 1419933856-4018-2-git-send-email-vsementsov@parallels.com Signed-off-by:
Stefan Hajnoczi <stefanha@redhat.com> (cherry picked from commit 04636dc4) Signed-off-by:
-
Igor Mammedov authored
If QEMU is started with -numa ... Windows only notices that CPU has been hot-added but it will not online such CPUs. It's caused by the fact that possible CPUs are flagged as not enabled in SRAT and Windows honoring that information doesn't use corresponding CPU. ACPI 5.0 Spec regarding to flag says: " Table 5-47 Local APIC Flags ... Enabled: if zero, this processor is unusable, and the operating system support will not attempt to use it. " Fix QEMU to adhere to spec and mark possible CPUs as enabled in SRAT. With that Windows onlines hot-added CPUs as expected. Signed-off-by:
Igor Mammedov <imammedo@redhat.com> Reviewed-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
-
Max Filippov authored
Alter cross-page TB test to also test cross-page opcode. Signed-off-by:
Max Filippov <jcmvbkbc@gmail.com> (cherry picked from commit 85d36377) Signed-off-by:
-
Max Filippov authored
If TB ends with an opcode that crosses page boundary and the following page is not executable then EPC1 for the code fetch exception wrongly points at the beginning of the TB. Always treat instruction that crosses page boundary as a separate TB. Cc: qemu-stable@nongnu.org Signed-off-by:
-
Peter Maydell authored
When stopping an audio voice, call the audio backend's fini method before calling audio_pcm_hw_free_resources_ rather than afterwards. This allows backends which use helper threads (like pulseaudio) to terminate those threads before the conv_buf or mix_buf are freed and avoids race conditions where the helper may access a NULL pointer or freed memory. Cc: qemu-stable@nongnu.org Reviewed-by:
Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
Peter Maydell <peter.maydell@linaro.org> Message-id: 1418406239-9838-1-git-send-email-peter.maydell@linaro.org (cherry picked from commit b28fb27b) Signed-off-by:
-
Paolo Bonzini authored
Old kernels that used high memory only allowed the initrd to be in the first 896MB of memory. If you load the initrd above, they complain that "initrd extends beyond end of memory". In order to fix this, while not breaking machines with small amounts of memory fixed by cdebec5e (linuxboot: compute initrd loading address, 2014-10-06), we need to distinguish two cases. If pc.c placed the initrd at end of memory, use the new algorithm based on the e801 memory map. If instead pc.c placed the initrd at the maximum address specified by the bzImage, leave it there. The only interesting part is that the low-memory info block is now loaded very early, in real mode, and thus the 32-bit address has to be converted into a real mode segment. The initrd address is also patched in the info block before entering real mode, it is simpler that way. This fixes booting the RHEL4.8 32-bit installation image with 1GB of RAM. Cc: qemu-stable@nongnu.org Cc: mst@redhat.com Cc: jsnow@redhat.com Signed-off-by:
-
Paolo Bonzini authored
Even though hw/i386/pc.c tries to compute a valid loading address for the initrd, close to the top of RAM, this does not take into account other data that is malloced into that memory by SeaBIOS. Luckily we can easily look at the memory map to find out how much memory is used up there. This patch places the initrd in the first four gigabytes, below the first hole (as returned by INT 15h, AX=e801h). Without this patch: [ 0.000000] init_memory_mapping: [mem 0x07000000-0x07fdffff] [ 0.000000] RAMDISK: [mem 0x0710a000-0x07fd7fff] With this patch: [ 0.000000] init_memory_mapping: [mem 0x07000000-0x07fdffff] [ 0.000000] RAMDISK: [mem 0x07112000-0x07fdffff] So linuxboot is able to use the 64k that were added as padding for QEMU <= 2.1. Acked-by:
-
Kevin Wolf authored
If a qcow2 image specifies a backing file format that doesn't correspond to any format driver that qemu knows, we shouldn't fall back to probing, but simply error out. Not looking up the backing file driver in bdrv_open_backing_file(), but just filling in the "driver" option if it isn't there moves us closer to the goal of having everything in QDict options and gets us the error handling of bdrv_open(), which correctly refuses unknown drivers. Cc: qemu-stable@nongnu.org Signed-off-by:
Kevin Wolf <kwolf@redhat.com> Reviewed-by:
Max Reitz <mreitz@redhat.com> Message-id: 1416935562-7760-4-git-send-email-kwolf@redhat.com Signed-off-by:
-
Kevin Wolf authored
The qcow2 specification requires that the header extension data be padded to round up the extension size to the next multiple of 8 bytes. Signed-off-by:
-
Kevin Wolf authored
After reading the extension header, offset is incremented, but not checked against end_offset any more. This way an integer overflow could happen when checking whether the extension end is within the allowed range, effectively disabling the check. This patch adds the missing check and a test case for it. Cc: qemu-stable@nongnu.org Reported-by:
-
Gary R Hook authored
Modify block_save_iterate() to return positive/zero/negative (success/not done/failure) return status. The computation of the blocks transferred (an int64_t) exceeds the size of an int return value. Signed-off-by:
Gary R Hook <gary.hook@nimboxx.com> Reviewed-by:
ChenLiang <chenliang88@huawei.com> Reviewed-by:
-
Hanna Reitz authored
The return value must be negative on error; there is one place in raw_open_common() where errp is set, but ret remains 0. Fix it. Cc: qemu-stable@nongnu.org Signed-off-by:
-
Hanna Reitz authored
bdrv_truncate() may fail and qcow2_write_compressed() should return the error code in that case. Cc: qemu-stable@nongnu.org Signed-off-by:
-
Hanna Reitz authored
qcow2_cache_flush() may fail; if one of the caches failed to be flushed successfully to disk in qcow2_close() the image should not be marked clean, and we should emit a warning. This breaks the (qcow2-specific) iotests 026, 071 and 089; change their output accordingly. Cc: qemu-stable@nongnu.org Signed-off-by:
-
Paolo Bonzini authored
Signed-off-by:
John Snow <jsnow@redhat.com> Signed-off-by:
-
- Jan 07, 2015
-
-
Hanna Reitz authored
In qcow2_alloc_cluster_offset(), *num is limited to INT_MAX >> BDRV_SECTOR_BITS by all callers. However, since remaining is of type uint64_t, we might as well cast *num to that type before performing the shift. Cc: qemu-stable@nongnu.org Signed-off-by:
-
Hanna Reitz authored
Add a test for creating and amending images (amendment uses the creation options) with formats not supporting creation over protocols not supporting creation. Cc: qemu-stable@nongnu.org Signed-off-by:
-
Hanna Reitz authored
There may be NBD tests which do not create a sample image and simply test whether wrong usage of the protocol is rejected as expected. In this case, there will be no NBD server and trying to kill it during clean-up will fail. Cc: qemu-stable@nongnu.org Signed-off-by:
-
Hanna Reitz authored
The image options which can be amended are described by the .create_opts field for every driver. This field must therefore be non-NULL so that anything can be amended in the first place. Check that this holds true before going into qemu_opts_create() (because if .create_opts is NULL, the create_opts pointer in img_amend() will be NULL after qemu_opts_append()). Cc: qemu-stable@nongnu.org Signed-off-by:
-
Hanna Reitz authored
If a driver supports image creation, it needs to set the .create_opts field. We can use that to make sure .create_opts for both drivers involved is not NULL for the target image in qemu-img convert, which is important so that the create_opts pointer in img_convert() is not NULL after the qemu_opts_append() calls and when going into qemu_opts_create(). Cc: qemu-stable@nongnu.org Signed-off-by:
-
Hanna Reitz authored
If a driver supports image creation, it needs to set the .create_opts field. We can use that to make sure .create_opts for both drivers involved is not NULL in bdrv_img_create(), which is important so that the create_opts pointer in that function is not NULL after the qemu_opts_append() calls and when going into qemu_opts_create(). Cc: qemu-stable@nongnu.org Signed-off-by:
-
Hanna Reitz authored
The nfs protocol driver is capable of creating images, but did not specify any creation options. Fix it. A way to test this issue is the following: $ qemu-img create -f nfs nfs://127.0.0.1/foo.qcow2 64M Without this patch, it segfaults. With this patch, it does not. However, this is not something that should really work; qemu-img should check whether the parameter for the -f option (and -O for convert) is indeed a format, and error out if it is not. Therefore, I am not making it an iotest. Cc: qemu-stable@nongnu.org Signed-off-by:
-
Hanna Reitz authored
Although virtually impossible right now, bdrv_find_format("qcow") may fail. The vvfat block driver should heed that case. Cc: qemu-stable@nongnu.org Signed-off-by: -
Hanna Reitz authored
We can always assume raw, file and qcow2 being available; so do not use bdrv_find_format() to locate their BlockDriver objects but statically reference the respective objects. Cc: qemu-stable@nongnu.org Signed-off-by:
-
Hanna Reitz authored
There are some block drivers which are essential to QEMU and may not be removed: These are raw, file and qcow2 (as the default non-raw format). Make their BlockDriver objects public so they can be directly referenced throughout the block layer without needing to call bdrv_find_format() and having to deal with an error at runtime, while the real problem occurred during linking (where raw, file or qcow2 were not linked into qemu). Cc: qemu-stable@nongnu.org Signed-off-by:
-
Jason Wang authored
virtio_net_handle_ctrl() and other functions that process control vq request call iov_discard_front() which will shorten the iov. This will lead unmapping in virtqueue_push() leaks mapping. Fixes this by keeping the original iov untouched and using a temp variable in those functions. Cc: Wen Congyang <wency@cn.fujitsu.com> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Cc: qemu-stable@nongnu.org Signed-off-by:
Jason Wang <jasowang@redhat.com> Reviewed-by:
Stefano Stabellini <stefano.stabellini@eu.citrix.com> Reviewed-by:
Fam Zheng <famz@redhat.com> Reviewed-by:
-
Don Slutz authored
The other callers to blk_set_enable_write_cache() in this file already check for s->blk == NULL. Signed-off-by:
Don Slutz <dslutz@verizon.com> Reviewed-by:
-
Peter Maydell authored
The code in invalidate_and_set_dirty() needs to handle addr/length combinations which cross guest physical page boundaries. This can happen, for example, when disk I/O reads large blocks into guest RAM which previously held code that we have cached translations for. Unfortunately we were only checking the clean/dirty status of the first page in the range, and then were calling a tb_invalidate function which only handles ranges that don't cross page boundaries. Fix the function to deal with multipage ranges. The symptoms of this bug were that guest code would misbehave (eg segfault), in particular after a guest reboot but potentially any time the guest reused a page of its physical RAM for new code. Cc: qemu-stable@nongnu.org Signed-off-by:
-
Hailiang Zhang authored
freeaddrinfo(result) does not assign result = NULL, after frees it. There will be a double free when it goes error case. It is reported by covertiy. Reviewed-by:
Gonglei <arei.gonglei@huawei.com> Cc: qemu-stable@nongnu.org Signed-off-by:
zhanghailiang <zhang.zhanghailiang@huawei.com> Signed-off-by:
-
Hailiang Zhang authored
In function connect_to_qemu(), getaddrinfo() will allocate memory that is stored into server, it should be freed by using freeaddrinfo() before connect_to_qemu() return. Cc: qemu-stable@nongnu.org Reviewed-by:
Markus Armbruster <armbru@redhat.com> Signed-off-by:
-
Paolo Bonzini authored
Old BIOSes left some padding by mistake after the req_size/resp_size. New QEMU does not like it, thinking it is a bidirectional command. As a workaround, we can check if the ANY_LAYOUT bit is set; if not, we always consider the first buffer as the virtio-scsi request/response, because, back when QEMU did not support ANY_LAYOUT, it expected the payload to start at the second element of the iovec. This can show up during migration. Cc: qemu-stable@nongnu.org Signed-off-by:
-
Alexander Graf authored
Memory slots have to be page aligned to get entered into KVM. There is existing logic that tries to ensure that we pad memory slots that are not page aligned to the biggest region that would still fit in the alignment requirements. Unfortunately, that logic is broken. It tries to calculate the start offset based on the region size. Fix up the logic to do the thing it was intended to do and document it properly in the comment above it. With this patch applied, I can successfully run an e500 guest with more than 3GB RAM (at which point RAM starts overlapping subpage memory regions). Cc: qemu-stable@nongnu.org Signed-off-by:
-
Max Filippov authored
Entry opcode needs to check if moving to new register frame would cause register window overflow. Entry used in function prologue never overflows because preceding windowed call* opcode writes return address to the target register window frame, causing overflow exceptions at the point of call. But when a sequence of entry opcodes is used for register window spilling there may not be a call or other opcode that would cause window check between entries and they would not raise overflow exception themselves resulting in data corruption. Cc: qemu-stable@nongnu.org Signed-off-by:
-
Hannes Reinecke authored
A linux guest will be issuing messages: [ 32.124042] DC390: Deadlock in DataIn_0: DMA aborted unfinished: 000000 bytes remain!! [ 32.126348] DC390: DataIn_0: DMA State: 0 and the HBA will fail to work properly. Reason is the emulation is not setting the 'DMA transfer done' status correctly. Signed-off-by:
Hannes Reinecke <hare@suse.de> Cc: qemu-stable@nongnu.org Signed-off-by:
-
Peter Maydell authored
The g_hash_table_iter_* functions for iterating through a hash table are not present in glib 2.12, which is our current minimum requirement. Rewrite the code to use g_hash_table_foreach() instead. Signed-off-by:
-
Zhang Haoyu authored
If there are still pending i/o while deleting snapshot, because deleting snapshot is done in non-coroutine context, and the pending i/o read/write (bdrv_co_do_rw) is done in coroutine context, so it's possible to cause concurrency problem between above two operations. Add bdrv_drain_all() to bdrv_snapshot_delete() to avoid this problem. Signed-off-by:
Zhang Haoyu <zhanghy@sangfor.com> Reviewed-by:
-
