Using this function would always be wrong because a dirty bitmap must
have a specific owner that consumes the dirty bits and calls
bdrv_reset_dirty_bitmap().
Remove the unused function to avoid future misuse.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Fam Zheng <famz@redhat.com>
Reviewed-by: John Snow <jsnow@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Unsetting dirty globally with discard is not very correct. The discard may zero
out sectors (depending on can_write_zeroes_with_unmap), we should replicate
this change to destination side to make sure that the guest sees the same data.
Calling bdrv_reset_dirty also troubles mirror job because the hbitmap iterator
doesn't expect unsetting of bits after current position.
So let's do it the opposite way which fixes both problems: set the dirty bits
if we are to discard it.
Reported-by: wangxiaolong@ucloud.cn
Signed-off-by: Fam Zheng <famz@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
If guest discards a source cluster, mirroring with bdrv_aio_readv is overkill.
Some protocols do zero upon discard, where it's best to use
bdrv_aio_write_zeroes, otherwise, bdrv_aio_discard will be enough.
Signed-off-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
If specified as "true", it allows discarding on target sectors where source is
not allocated.
Signed-off-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Like bdrv_is_allocated_above, this function follows the backing chain until seeing
BDRV_BLOCK_ALLOCATED. Base is not included.
Reimplement bdrv_is_allocated on top.
[Initialized bdrv_co_get_block_status_above() ret to 0 to silence
mingw64 compiler warning about the unitialized variable. assert(bs !=
base) prevents that case but I suppose the program could be compiled
with -DNDEBUG.
--Stefan]
Signed-off-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
If we wish to make differential backups a feature that's easy to access,
it might be pertinent to rename the "dirty-bitmap" mode to "incremental"
to make it clear what /type/ of backup the dirty-bitmap is helping us
perform.
This is an API breaking change, but 2.4 has not yet gone live,
so we have this flexibility.
Signed-off-by: John Snow <jsnow@redhat.com>
Message-id: 1433463642-21840-2-git-send-email-jsnow@redhat.com
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
libiscsi starting with 1.15 will properly support timeout of iscsi
commands. The default will remain no timeout, but this can
be changed via cmdline parameters, e.g.:
qemu -iscsi timeout=30 -drive file=iscsi://...
If a timeout occurs a reconnect is scheduled and the timed out command
will be requeued for processing after a successful reconnect.
The required API call iscsi_set_timeout is present since libiscsi
1.10 which was released in October 2013. However, due to some bugs
in the libiscsi code the use is not recommended before version 1.15.
Please note that this patch bumps the libiscsi requirement to 1.10
to have all function and macros defined. The patch fixes also a
off-by-one error in the NOP timeout calculation which was fixed
while touching these code parts.
Signed-off-by: Peter Lieven <pl@kamp.de>
Message-id: 1434455107-19328-1-git-send-email-pl@kamp.de
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Do not take the BQL before dispatching MMIO requests of KVM VCPUs.
Instead, address_space_rw will do it if necessary. This enables completely
BQL-free MMIO handling in KVM mode for upcoming devices with fine-grained
locking.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <1434646046-27150-10-git-send-email-pbonzini@redhat.com>
Do not take the BQL before dispatching PIO requests of KVM VCPUs.
Instead, address_space_rw will do it if necessary. This enables
completely BQL-free PIO handling in KVM mode for upcoming devices with
fine-grained locking.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <1434646046-27150-8-git-send-email-pbonzini@redhat.com>
This opens the path to get rid of the iothread lock on vmexits in KVM
mode. On x86, the in-kernel irqchips has to be used because we otherwise
need to synchronize APIC and other per-cpu state accesses that could be
changed concurrently.
Regarding pre/post-run callbacks, s390x and ARM should be fine without
specific locking as the callbacks are empty. MIPS and POWER require
locking for the pre-run callback.
For the handle_exit callback, it is non-empty in x86, POWER and s390.
Some POWER cases could do without the locking, but it is left in
place for now.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <1434646046-27150-7-git-send-email-pbonzini@redhat.com>
The MMIO case is further broken up in two cases: if the caller does not
hold the BQL on invocation, the unlocked one takes or avoids BQL depending
on the locking strategy of the target memory region and its coalesced
MMIO handling. In this case, the caller should not hold _any_ lock
(a friendly suggestion which is disregarded by virtio-scsi-dataplane).
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Frederic Konrad <fred.konrad@greensocs.com>
Message-Id: <1434646046-27150-6-git-send-email-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
This function will be used to avoid recursive locking of the iothread lock
whenever address_space_rw/ld*/st* are called with the BQL held, which is
almost always the case.
Tracking whether the iothread is owned is very cheap (just use a TLS
variable) but requires some care because now the lock must always be
taken with qemu_mutex_lock_iothread(). Previously this wasn't the case.
Outside TCG mode this is not a problem. In TCG mode, we need to be
careful and avoid the "prod out of compiled code" step if already
in a VCPU thread. This is easily done with a check on current_cpu,
i.e. qemu_in_vcpu_thread().
Hopefully, multithreaded TCG will get rid of the whole logic to kick
VCPUs whenever an I/O event occurs!
Cc: Frederic Konrad <fred.konrad@greensocs.com>
Message-Id: <1434646046-27150-3-git-send-email-pbonzini@redhat.com>
Reviewed-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
The next patch will require the BQL to be always taken with
qemu_mutex_lock_iothread(), while right now this isn't the case.
Outside TCG mode this is not a problem. In TCG mode, we need to be
careful and avoid the "prod out of compiled code" step if already
in a VCPU thread. This is easily done with a check on current_cpu,
i.e. qemu_in_vcpu_thread().
Hopefully, multithreaded TCG will get rid of the whole logic to kick
VCPUs whenever an I/O event occurs!
Cc: Frederic Konrad <fred.konrad@greensocs.com>
Message-Id: <1434646046-27150-2-git-send-email-pbonzini@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Last month, we experienced several guests crash(6cores-8cores), qemu logs
display the following messages:
qemu-system-x86_64: /build/qemu-2.1.2/kvm-all.c:976:
kvm_irqchip_commit_routes: Assertion `ret == 0' failed.
After analysis and verification, we can confirm it's irq-balance
daemon(in guest) leads to the assertion failure. Start a 8 core guest with
two disks, execute the following scripts will reproduce the BUG quickly:
irq_affinity.sh
========================================================================
vda_irq_num=25
vdb_irq_num=27
while [ 1 ]
do
for irq in {1,2,4,8,10,20,40,80}
do
echo $irq > /proc/irq/$vda_irq_num/smp_affinity
echo $irq > /proc/irq/$vdb_irq_num/smp_affinity
dd if=/dev/vda of=/dev/zero bs=4K count=100 iflag=direct
dd if=/dev/vdb of=/dev/zero bs=4K count=100 iflag=direct
done
done
========================================================================
QEMU setup static irq route entries in kvm_pc_setup_irq_routing(), PIC and
IOAPIC share the first 15 GSI numbers, take up 23 GSI numbers, but take up
38 irq route entries. When change irq smp_affinity in guest, a dynamic route
entry may be setup, the current logic is: if allocate GSI number succeeds,
a new route entry can be added. The available dynamic GSI numbers is
1021(KVM_MAX_IRQ_ROUTES-23), but available irq route entries is only
986(KVM_MAX_IRQ_ROUTES-38), GSI numbers greater than route entries.
irq-balance's behavior will eventually leads to total irq route entries
exceed KVM_MAX_IRQ_ROUTES, ioctl(KVM_SET_GSI_ROUTING) fail and
kvm_irqchip_commit_routes() trigger assertion failure.
This patch fix the BUG.
Signed-off-by: Wenshuang Ma <kevinnma@tencent.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
We need a possibility to run code when a subchannel gets disabled.
This patch adds the necessary infrastructure.
Signed-off-by: Thomas Huth <thuth@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
We have to consume the outstanding service interrupt after each
service call, otherwise a correct implementation will return
CC=2 on subsequent service calls.
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: David Hildenbrand <dahi@linux.vnet.ibm.com>
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Our main channel_subsys structure is not a device (yet), but we need
to setup mss/mcss-e again if the guest had enabled it before. Use
a hack that should catch most configurations (assuming that the guest
will have enabled at least one device in higher subchannel sets or
channel subsystems if it enabled the functionality.)
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
For a guest-initiated reset, we need to not only reset the virtio device,
but also reset the VirtioCcwDevice into a clean state. This includes
resetting the indicators, or else a guest will not be able to e.g.
switch from classic interrupts to adapter interrupts.
Split off this routine into a new function virtio_ccw_reset_virtio()
to make the distinction between resetting the virtio-related devices
and the base subchannel device clear.
CC: qemu-stable@nongnu.org
Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
TriCore bugfixes
# gpg: Signature made Mon Jun 29 13:08:17 2015 BST using RSA key ID 6B69CA14
# gpg: Good signature from "Bastian Koppelmann <kbastian@mail.uni-paderborn.de>"
* remotes/bkoppelmann/tags/pull-tricore-20150629:
target-tricore: fix depositing bits from PCXI into ICR
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
virtio, pci fixes, enhancements
Almost exclusively bugfixes, though in this case,
we are adding functionality to the pxb in order
to make OVMF work on it.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
# gpg: Signature made Fri Jun 26 14:43:27 2015 BST using RSA key ID D28D5469
# gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>"
# gpg: aka "Michael S. Tsirkin <mst@redhat.com>"
* remotes/mst/tags/for_upstream:
Fix glib_subprocess test
hw/pci-bridge: format special OFW unit address for PXB host
hw/core: explicit OFW unit address callback for SysBusDeviceClass
hw/pci-bridge: disable SHPC in PXB
hw/pci-bridge: introduce "shpc" property
hw/pci: introduce shpc_present() helper function
hw/pci-bridge: add macro for "msi" property
hw/pci-bridge: add macro for "chassis_nr" property
hw/pci-bridge: expose _test parameter in SHPC_VMSTATE()
migration: introduce VMSTATE_BUFFER_UNSAFE_INFO_TEST()
add pci-bridge-seat
pc: cleanup and convert TMP ACPI device description to AML API
MAINTAINERS: add ACPI entry
vhost: correctly pass error to caller in vhost_dev_enable_notifiers()
balloon: add a feature bit to let Guest OS deflate balloon on oom
qdev: fix OVERFLOW_BEFORE_WIDEN
virito-pci: fix OVERRUN problem
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
This is one of very few things in exec-all with a genuine CPU
architecture dependency. Move these hashing helpers to a new
header to trim exec-all.h down to a near architecture-agnostic
header.
The defs are only used by cpu-exec and translate-all which are both
arch-obj's so the new tb-hash.h has no core code usage.
Reviewed-by: Richard Henderson <rth@redhat.com>
Signed-off-by: Peter Crosthwaite <crosthwaite.peter@gmail.com>
Message-Id: <9d048b96f7cfa64a4d9c0b88e0dd2877fac51d41.1433052532.git.crosthwaite.peter@gmail.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
target-arm queue:
* Change the virt board's default interface type for block devices to virtio
* Improve some error messages that will now be triggered by some incorrect
but previously worked-by-accident command lines
* Print ELR if we're doing debug logging of AArch64 exception entry
* Handle the "completely empty semihosting commandline" correctly for
softmmu (we already did for linux-user)
* Add GICv2m description to ACPI tables for virt board
* Fix some incorrect table revision entries in virt board ACPI tables
# gpg: Signature made Fri Jun 26 14:29:39 2015 BST using RSA key ID 14360CDE
# gpg: Good signature from "Peter Maydell <peter.maydell@linaro.org>"
* remotes/pmaydell/tags/pull-target-arm-20150626:
hw/arm/virt: Make block devices default to virtio
qdev-properties-system: Improve error message for drive assignment conflict
qdev-properties-system: Change set_pointer's parse callback to use Error
target-arm: A64: Print ELR when taking exceptions
target-arm: default empty semihosting cmdline
hw/arm/virt-acpi-build: Add GICv2m description in ACPI MADT table
hw/arm/virt-acpi-build: Fix table revision and some comments
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Now we have virtio-pci, we can make the virt board's default block
device type be IF_VIRTIO. This allows users to use simplified
command lines that don't have to explicitly create virtio-pci-blk
devices; the -hda &c very short options now also work.
This means we also need to set no_cdrom to avoid getting a
default cdrom device -- this is needed because the virtio-blk
device will fail if it is connected to a block backend with
no media, which is what the default cdrom device typically is.
Providing a cdrom with media via -cdrom will succeed, but silently
create a device with non-removable medium. this is probably
not really what the user wants, but is the best we can do now.
Note that this change means that some command lines which used
to work (by accident) will stop working. Where a drive was connected
manually to a device but without 'if=none' being specified, we
used to treat this as an IDE drive, which we would then not autoplug
because the board doesn't support IDE. Now we will treat it as a
virtio disk and autoplug it, which means the attempt to use the
drive manually will fail:
qemu-system-arm: -drive file=img.qcow2,id=foo: Drive 'foo' is already
in use because it has been automatically connected to another device
(did you need 'if=none' in the drive options?)
The command line will have to be changed to include 'if=none', as the
error message suggests.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 1435068107-12594-4-git-send-email-peter.maydell@linaro.org
If the user forgot if=none on their drive specification they're likely
to get an error message because the drive is assigned once automatically
by QEMU and once by the manual id=/drive= user command line specification.
Improve the error message produced in this case to explicitly guide the
user towards if=none.
We rephrase the "drive conflict but not for an if=something" error as
well to keep the wording in line.
The two cases that change are:
(1) Drive specified as to be auto-connected and also manually connected
(and the board does handle this if= type):
qemu-system-x86_64 -nodefaults -display none \
-drive if=scsi,file=tmp.qcow2,id=foo -device ide-hd,drive=foo
Previously:
qemu-system-x86_64: -device ide-hd,drive=foo: Property 'ide-hd.drive'
can't take value 'foo', it's in use
Now:
qemu-system-x86_64: -device ide-hd,drive=foo: Drive 'foo' is already in
use because it has been automatically connected to another device (did
you need 'if=none' in the drive options?)
(2) Drive specified to be manually connected in two different ways:
qemu-system-x86_64 -nodefaults -display none \
-drive if=none,file=tmp.qcow2,id=foo -device ide-hd,drive=foo \
-device ide-hd,drive=foo
Previously:
qemu-system-x86_64: -device ide-hd,drive=foo: Property 'ide-hd.drive'
can't take value 'foo', it's in use
Now:
qemu-system-x86_64: -device ide-hd,drive=foo: Drive 'foo' is already in
use by another device
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 1435068107-12594-3-git-send-email-peter.maydell@linaro.org
Instead of having set_pointer() call a parse callback which returns
an error number that we then convert to an Error string with
error_set_from_qdev_prop_error(), make the parse callback take an
Error** and set the error itself. This will allow parse routines
to provide more helpful error messages than the generic ones.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-id: 1435068107-12594-2-git-send-email-peter.maydell@linaro.org
MIPS patches 2015-06-26
Changes:
* MIPS UHI semihosting support
* microMIPS32 R6 support
# gpg: Signature made Fri Jun 26 10:42:33 2015 BST using RSA key ID 0B29DA6B
# gpg: Good signature from "Leon Alrae <leon.alrae@imgtec.com>"
# 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: 8DD3 2F98 5495 9D66 35D4 4FC0 5211 8E3C 0B29 DA6B
* remotes/lalrae/tags/mips-20150626:
target-mips: add mips32r6-generic CPU definition
target-mips: microMIPS32 R6 POOL16{A, C} instructions
target-mips: microMIPS32 R6 Major instructions
target-mips: microMIPS32 R6 POOL32{I, C} instructions
target-mips: microMIPS32 R6 POOL32F instructions
target-mips: microMIPS32 R6 POOL32A{XF} instructions
target-mips: microMIPS32 R6 branches and jumps
target-mips: add microMIPS32 R6 opcode enum
target-mips: signal RI for removed instructions in microMIPS R6
target-mips: raise RI exceptions when FIR.PS = 0
target-mips: rearrange gen_compute_compact_branch
target-mips: refactor {D}LSA, {D}ALIGN, {D}BITSWAP
target-mips: remove an unused argument
target-mips: add microMIPS TLBINV, TLBINVF
target-mips: fix {RD, WR}PGPR in microMIPS
target-mips: convert host to MIPS errno values when required
target-mips: add Unified Hosting Interface (UHI) support
target-mips: remove identical code in different branch
hw/mips: Do not clear BEV for MIPS malta kernel load
include/softmmu-semi.h: Make semihosting support 64-bit clean
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Fam Zheng