Age | Commit message (Collapse) | Author |
|
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 364c3e6b8dd7912e01d19122d791b8c8f6df4f6c)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
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 5f9490de566c5b092a6cfedc3c7a37a9c9dee917)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
What needs to be volatile is not the pointer, but the pointed-to
value!
Cc: qemu-stable@nongnu.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 2cbcfb281afa041a41f6e4c4da0f5c9314084604)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
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 04636dc410b163c2243e66c3813dd4900a50a4ed)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
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: Michael S. Tsirkin <mst@redhat.com>
(cherry picked from commit dd0247e09a542d2a7ba6e390c70b5616edb9ec56)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
Alter cross-page TB test to also test cross-page opcode.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
(cherry picked from commit 85d36377e4ff8b98119420099d445369bfd6b7bb)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
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: Max Filippov <jcmvbkbc@gmail.com>
(cherry picked from commit 01673a3401614b4199c9946ad47b97bedfc7a7c2)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
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 b28fb27b5edf77f6fd0ac550a156fb20f2218db3)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
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 cdebec5 (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 <pbonzini@redhat.com>
(cherry picked from commit 269e2358492b674c50160553d037702e916b9f1b)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
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: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit cdebec5e40bd0af82da0659f37af85ee2aa2c9d1)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
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: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit c5f6e493bb5339d244eae5d3f21c5b6d73996739)
Conflicts:
tests/qemu-iotests/group
*removed context from upstream iotest groups
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
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 <kwolf@redhat.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Message-id: 1416935562-7760-3-git-send-email-kwolf@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 8884dd1bbc5ce42cd657ffcbef3a477443468974)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
(cherry picked from commit a163ac3f57b5baa117158f7c0488d276ba3377e2)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
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: Max Reitz <mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Message-id: 1416935562-7760-2-git-send-email-kwolf@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 2ebafc854d109ff09b66fb4dd62c2c53fc29754a)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
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: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 1416958202-15913-1-git-send-email-gary.hook@nimboxx.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit ebd9fbd7e102c533143c2c8372312b75c2b2678a)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
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: Max Reitz <mreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 01212d4ed68fc8daa29062a9a38650cf8febe392)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
bdrv_truncate() may fail and qcow2_write_compressed() should return the
error code in that case.
Cc: qemu-stable@nongnu.org
Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 6a69b9620ac1562a067990d87284a85552bfd61b)
Conflicts:
block/qcow2.c
*removed context dependency on 75d3d21
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
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: Max Reitz <mreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 3b5e14c76a6bb142bf250ddf99e24a0ac8c7bc12)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: John Snow <jsnow@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 9e52c53b8c7821ce06e8b995b960e81b469e6847)
*included to maintain parity with unit tests which inject errors
via blkdebug. needed for:
"qcow2: Flushing the caches in qcow2_close may fail"
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
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: Max Reitz <mreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 11c89769dc3e638ef72915d97058411ddf79b64b)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
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: Max Reitz <mreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 2247798d13e5295a097da0a42f9d0d70d88690a4)
Conflicts:
tests/qemu-iotests/group
*removed context dependencies from upstream iotest groups
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
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: Max Reitz <mreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit f798068c565918ead63218d083ff814b7635be72)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
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: Max Reitz <mreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit b2439d26f078c826e5e06b34d978a6f6d5c7c56f)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
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: Max Reitz <mreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit f75613cf2488a37fb8019bc32a06ddbcd477d0ce)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
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: Max Reitz <mreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit c6149724080af7b3d5d61eac8942655e6d212783)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
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: Max Reitz <mreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit fd752801ae1cc729359a37f29e32265de6948d37)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
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: Max Reitz <mreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 1bcb15cf776a57e8963072c1919a59a90aea8e94)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
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: Max Reitz <mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit ef8104378c4a0497be079e48ee5ac5a89c68f978)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
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: Max Reitz <mreitz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 5f535a941e52229d81e55603eb69b2bd449b937a)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
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: Michael S. Tsirkin <mst@redhat.com>
Message-id: 1417082643-23907-1-git-send-email-jasowang@redhat.com
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 771b6ed37e3aa188a7485560b949a41c6cf174dc)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
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: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 1416259239-13281-1-git-send-email-dslutz@verizon.com
Cc: qemu-stable@nongnu.org
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 6b896ab261942f441a16836e3fa3c83f3f4488b9)
Conflicts:
hw/ide/core.c
*removed dependency on 4be746345
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
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: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 1416167061-13203-1-git-send-email-peter.maydell@linaro.org
(cherry picked from commit f874bf905ff2f8dcc17acbfc61e49a92a6f4d04b)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
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: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 77374582ab961af2c5e702f767f52179d5f7676c)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
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: zhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 5bbebf622897a59db5da4c468e737bfec4d71280)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
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: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit 55783a5521a3b1f93ee6a072e414a27c6cfa15f0)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
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: Alexander Graf <agraf@suse.de>
(cherry picked from commit f2a64032a14c642d0ddc9a7a846fc3d737deede5)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
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: Max Filippov <jcmvbkbc@gmail.com>
(cherry picked from commit 1b3e71f8ee17ced609213d9b41758110f3c026e9)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
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: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit c3543fb5fe4520f03dd4fef04fab7745eeca1c96)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
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: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Alexander Graf <agraf@suse.de>
(cherry picked from commit f8833a37c0c6b22ddd57b45e48cfb0f97dbd5af4)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
concurrency problem
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: Paolo Bonzini <pbonzini@redhat.com>
Message-id: 201410211637596311287@sangfor.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
(cherry picked from commit 3432a1929ee18e08787ce35476abd74f2c93a17c)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
U-boot for xtensa always treats uImage load address as virtual address.
This is important when booting uImage on xtensa core with MMUv2, because
MMUv2 has fixed non-identity virtual-to-physical mapping after reset.
Always do virtual-to-physical translation of uImage load address and
load uImage at the translated address. This fixes booting uImage kernels
on dc232b and other MMUv2 cores.
Cc: qemu-stable@nongnu.org
Reported-by: Waldemar Brodkorb <mail@waldemar-brodkorb.de>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
(cherry picked from commit 6d2e4530532ca1dbb5e68bdcca12e10931bc6503)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
Such address translation is needed when load address recorded in uImage
is a virtual address. When the actual load address is requested, return
untranslated address: user that needs the translated address can always
apply translation function to it and those that need it untranslated
don't need to do the inverse translation.
Add translation function pointer and its parameter to uimage_load
prototype. Update all existing users.
No user-visible functional changes.
Cc: qemu-stable@nongnu.org
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Reviewed-by: Alexander Graf <agraf@suse.de>
(cherry picked from commit 25bda50a0c7241dcb247483af2b7f961632020cc)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
Commit 9d8bf2d1 moved the softmmu slow path out of line and introduce a
regression at the same time by always calling tcg_out_tlb_load with
is_load=1. This makes impossible to run any significant code under
qemu-system-mips*.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-stable@nongnu.org
Reviewed-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
(cherry picked from commit 0a2923f8488498000eec54871456aa64a4391da4)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
If req->resp.cmd.status is not GOOD, the address of sense for
qemu_iovec_from_buf should be modified from &req->resp to sense.
Cc: qemu-stable@nongnu.org
Signed-off-by: Ting Wang <kathy.wangting@huawei.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
(cherry picked from commit b7890c40e557f4733b6fcd1eb79af79b70dc8c05)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
bits_per_pixel that are less than 8 could result in accessing
non-initialized buffers later in the code due to the expectation
that bytes_per_pixel value that is used to initialize these buffers is
never zero.
To fix this check that bits_per_pixel from the client is one of the
values that the rfb protocol specification allows.
This is CVE-2014-7815.
Signed-off-by: Petr Matousek <pmatouse@redhat.com>
[ kraxel: apply codestyle fix ]
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit e6908bfe8e07f2b452e78e677da1b45b1c0f6829)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
qemu_shutdown_requested may be interrupted by qemu_system_killed. If the
latter sets shutdown_requested after qemu_shutdown_requested has read it
but before it was cleared, the shutdown event is lost. Fix this by using
atomic_xchg.
This provides a different fix for the problem which commit 15124e142
attempts to deal with. That commit breaks use of ^C to drop into gdb,
and so this approach is better (and 15124e142 can be reverted).
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Reviewed-by: Gonglei <arei.gonglei@huawei.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
[PMM: commit message tweak]
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
(cherry picked from commit 817ef04db2cfa2df04daffd6917f4ea7605f6403)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
commit 57f97834efe0c208ffadc9d2959f3d3d55580e52 cleaned up
the cac_applet_pki_process_apdu function to have a single
exit point. Unfortunately, that commit introduced a bug
where the sign buffer can get free'd and nullified while
it's still being used.
This commit corrects the bug by introducing a boolean to
track whether or not the sign buffer should be freed in
the function exit path.
Signed-off-by: Ray Strode <rstrode@redhat.com>
Reviewed-by: Alon Levy <alon@pobox.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
(cherry picked from commit 81b49e8f892a977f3821f3416ea51aa641d63ac4)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
While writing an L1 table sector, qcow2_write_l1_entry() copies the
respective range from s->l1_table to the local "buf" array. The size of
s->l1_table does not have to be a multiple of L1_ENTRIES_PER_SECTOR;
thus, limit the index which is used for copying all entries to the L1
size.
Cc: qemu-stable@nongnu.org
Signed-off-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Peter Lieven <pl@kamp.de>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit a1391444fe1cfef14976458f3293a2c6945e725c)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
Add verification to vmsvga_fill_rect, re-enable HW_FILL_ACCEL.
Cc: qemu-stable@nongnu.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Don Koch <dkoch@verizon.com>
(cherry picked from commit bd9ccd8517e83b7c33a9167815dbfffb30d70b13)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
Add verification to vmsvga_copy_rect, re-enable HW_RECT_ACCEL.
Cc: qemu-stable@nongnu.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Don Koch <dkoch@verizon.com>
(cherry picked from commit 61b41b4c20eba08d2185297767e69153d7f3e09d)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|
|
Switch vmsvga_update_rect over to use vmsvga_verify_rect. Slight change
in behavior: We don't try to automatically fixup rectangles any more.
In case we find invalid update requests we'll do a full-screen update
instead.
Cc: qemu-stable@nongnu.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Don Koch <dkoch@verizon.com>
(cherry picked from commit 1735fe1edba9cc86bc0f26937ed5a62d3cb47c9c)
Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
|