Signed-off-by: Kevin Wolf <mail@kevin-wolf.de>
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Message-id: 1372018066-21822-4-git-send-email-mail@kevin-wolf.de
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
The upper_mem field of the Multiboot information struct doesn't really
contain the RAM size - 1 MB like we used to calculate it, but only the
memory from 1 MB up to the first (upper) memory hole.
In order to correctly retrieve this information, the multiboot ROM now
looks at the mmap it creates anyway and tries to find the size of
contiguous usable memory from 1 MB.
Drop the multiboot.c definition of lower_mem and upper_mem because both
are queried at runtime now.
Signed-off-by: Kevin Wolf <mail@kevin-wolf.de>
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Message-id: 1372018066-21822-3-git-send-email-mail@kevin-wolf.de
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
When the BIOS returns ebx = 0, the current entry is still valid and
needs to be included in the Multiboot memory map.
Fixing this meant that using bx as the entry index doesn't work any
more because it's 0 on the last entry (and it was SeaBIOS-specific
anyway), so the whole loop had to change a bit and should be more
generic as a result (ebx can be an arbitrary continuation number now,
and the entry size returned by the BIOS is used instead of hard-coding
20 bytes).
Signed-off-by: Kevin Wolf <mail@kevin-wolf.de>
Reviewed-by: Anthony Liguori <aliguori@us.ibm.com>
Message-id: 1372018066-21822-2-git-send-email-mail@kevin-wolf.de
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
length is a ram_addr_t, so RAM_ADDR_FMT must be used instead of %ld.
This fixes a recently introduced regression for w64 builds.
Using RAM_ADDR_FMT also changes decimal output to sedecimal.
This is good here because length and block->length should both
use the same base in the error message.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Message-id: 1372359606-2759-1-git-send-email-sw@weilnetz.de
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Allow to explicitly create mux chardevs on the command line,
like you can using QMP.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
mux failure path has a memory leak. creating a mux chardev can't
fail though, so just assert() that instead of fixing an error path
which never ever runs anyway ...
Also fix bid being leaked while being at it.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
# By Stefan Hajnoczi (11) and others
# Via Kevin Wolf
* kwolf/for-anthony:
cmd646: fix build when DEBUG_IDE is enabled.
block: change default of .has_zero_init to 0
vpc: Implement .bdrv_has_zero_init
vmdk: remove wrong calculation of relative path
gluster: Return bdrv_has_zero_init = 0
block/ssh: Set bdrv_has_zero_init according to the file type.
block: Make BlockJobTypes const
qemu-iotests: add 055 drive-backup test case
qemu-iotests: extract wait_until_completed() into iotests.py
blockdev: add Abort transaction
blockdev: add DriveBackup transaction
blockdev: allow BdrvActionOps->commit() to be NULL
blockdev: rename BlkTransactionStates to singular
block: add drive-backup QMP command
blockdev: use bdrv_getlength() in qmp_drive_mirror()
blockdev: drop redundant proto_drv check
block: add basic backup support to block driver
block: add bdrv_add_before_write_notifier()
notify: add NotiferWithReturn so notifier list can abort
raw-posix: Fix /dev/cdrom magic on OS X
Message-id: 1372429509-29642-1-git-send-email-kwolf@redhat.com
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Make sure we use the correct TARGET/PRI macros in the debug statements.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
CC: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
.has_zero_init defaults to 1 for all formats and protocols.
this is a dangerous default since this means that all
new added drivers need to manually overwrite it to 0 if
they do not ensure that a device is zero initialized
after bdrv_create().
if a driver needs to explicitly set this value to
1 its easier to verify the correctness in the review process.
during review of the existing drivers it turned out
that ssh and gluster had a wrong default of 1.
both protocols support host_devices as backend
which are not by default zero initialized. this
wrong assumption will lead to possible corruption
if qemu-img convert is used to write to such a backend.
vpc and vmdk also defaulted to 1 altough they support
fixed respectively flat extends. this has to be addresses
in separate patches. both formats as well as the mentioned
ssh and gluster are turned to the default of 0 with this
patch for safety.
a similar problem with the wrong default existed for
iscsi most likely because the driver developer did
oversee the default value of 1.
Signed-off-by: Peter Lieven <pl@kamp.de>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Use it for all targets, but be careful not to pass invalid CPUState.
cpu_single_env can be NULL, e.g. on Xen.
Signed-off-by: Andreas Färber <afaerber@suse.de>
While not normally needed for *-user, it can safely be used there since
always based on uint64_t, to avoid ifdeffery.
To avoid accidental uses, move the guards from exec/hwaddr.h to its
inclusion sites. No need for them in include/hw/.
Prepares for hwaddr use in qom/cpu.h.
Signed-off-by: Andreas Färber <afaerber@suse.de>
This allows to move the call into CPUState's realizefn.
Therefore move the stub into libqemustub.a.
Reviewed-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Pass it to qemu_dummy_cpu_thread_fn().
Use CPUState::env_ptr for cpu_single_env.
Prepares for changing qemu_init_vcpu() argument to CPUState.
Reviewed-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Pass it on to qemu_kvm_cpu_thread_fn().
Prepares for changing qemu_init_vcpu() argument to CPUState.
Reviewed-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Andreas Färber <afaerber@suse.de>
CPUArchState is no longer needed.
Prepares for changing qemu_kvm_cpu_thread_fn() opaque to CPUState.
Reviewed-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Use CPUState::env_ptr for now.
Prepares for changing cpu_handle_guest_debug() argument to CPUState.
Reviewed-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Andreas Färber <afaerber@suse.de>
It no longer uses CPUArchState.
Prepares for changing qemu_kvm_cpu_thread_fn() opaque to CPUState.
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Andreas Färber <afaerber@suse.de>
It no longer uses CPUArchState.
Prepares for changing kvm_cpu_exec() argument to CPUState.
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Make cpustats monitor command available unconditionally.
Prepares for changing kvm_handle_internal_error() and kvm_cpu_exec()
arguments to CPUState.
Signed-off-by: Andreas Färber <afaerber@suse.de>
CPUArchState is no longer needed.
Prepares for changing qemu_kvm_cpu_thread_fn() opaque to CPUState.
Reviewed-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Andreas Färber <afaerber@suse.de>
CPUArchState is no longer needed.
Prepares for changing qemu_kvm_init_cpu_signals() argument to CPUState.
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Andreas Färber <afaerber@suse.de>
It no longer uses CPUArchState.
Prepares for changing qemu_kvm_cpu_thread_fn() opaque to CPUState.
Reviewed-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Andreas Färber <afaerber@suse.de>
It no longer needs CPUArchState.
Prepares for changing all_cpu_threads_idle() CPU loop to CPUState and
needed for changing qemu_kvm_wait_io_event() argument to CPUState.
Reviewed-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Andreas Färber <afaerber@suse.de>
It no longer depends on CPUArchState, so move it to qom/cpu.c.
Prepares for changing GDBState::c_cpu to CPUState.
Signed-off-by: Andreas Färber <afaerber@suse.de>
Change Monitor::mon_cpu to CPUState as well.
Reviewed-by: liguang <lig.fnst@cn.fujitsu.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
It no longer relies on CPUArchState since 20d695a.
Reviewed-by: liguang <lig.fnst@cn.fujitsu.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Andreas Färber <afaerber@suse.de>
A few targets already managed to implement cpu_save() and cpu_load()
without defining CPU_SAVE_VERSION that causes them to be registered.
Guard the prototypes with CPU_SAVE_VERSION to avoid this happening again
until all targets are converted to VMState (or QIDL).
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Since commit e67db06e9f (target-or32: Add
target stubs and QOM cpu) a VMStateDescription existed, but
CPU_SAVE_VERSION was not set, so it was never registered.
Drop cpu_{save,load}() and register VMStateDescription via DeviceState.
Use a version_id of 1 and specify minimum versions as well.
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Commit b758aca1f6 (target-alpha: Enable
the alpha-softmmu target.) introduced cpu_{save,load}() functions but
didn't define CPU_SAVE_VERSION, so they were never registered.
Drop cpu_{save,load}() and register the VMStateDescription via DeviceClass.
This operates on the AlphaCPU object instead of CPUAlphaState.
Reviewed-by: Juan Quintela <quintela@redhat.com>
Acked-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Andreas Färber <afaerber@suse.de>
To be used to embed common CPU state into CPU subclasses.
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
It's the equivalent to cpu_class_set_vmsd(), to assign
DeviceClass::vmsd. It wasn't needed before since only static,
unmigratable VMStateDescriptions were assigned so far.
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
It's CPUClass::vmsd, not CPUState::vmsd.
Reviewed-by: liguang <lig.fnst@cn.fujitsu.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Andreas Färber <afaerber@suse.de>
Depending on the subformat, has_zero_init on VHD must behave like raw
and query the underlying storage (fixed) or like other sparse formats
that can always return 1 (dynamic, differencing).
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
When creating image with backing file, the driver tries to calculate the
relative path from created image file to backing file, but the path
computation is incorrect. e.g.:
$ qemu-img create -f vmdk -b vmdk-data-disk.vmdk vmdk-data-snapshot1
Formatting 'vmdk-data-snapshot1', fmt=vmdk size=10737418240
backing_file='vmdk-data-disk.vmdk' compat6=off zeroed_grain=off
$ qemu-img info vmdk-data-snapshot1
image: vmdk-data-snapshot1
file format: vmdk
virtual size: 10G (10737418240 bytes)
disk size: 12K
-> backing file: disk.vmdk
The common part in file names, "vmdk-data-", is incorrectly forgotten by
relative_path(). As the VMDK specification has no restriction on
parentNameHint to be relative path, we simply remove this by using the
backing_file option.
Cc: qemu-stable@nongnu.org
Signed-off-by: Fam Zheng <famz@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
GlusterFS volumes can be backed by block devices, in which case
bdrv_create() doesn't make sure that the image is zeroed out. It is
currently not possibly to detect whether a given image is backed by a
file or a block device, and incorrectly assuming that it is zeroed
corrupts images during qemu-img convert, so let's err on the side of
caution and always return 0.
Cc: qemu-stable@nongnu.org
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
If the remote is a regular file, set it to true (ie. reads of
uninitialized areas in a newly created file will return zeroes).
If we can't prove that, return false (a safe default).
Tested by adding a debugging print statement [not part of this commit]
and creating a remote file and a remote block device:
$ ./qemu-img create ssh://localhost/tmp/new 100M
Formatting 'ssh://localhost/tmp/new', fmt=raw size=104857600
filename ssh://localhost/tmp/new: has_zero_init = 1
$ sudo lvcreate -L 1G -n tmp /dev/fedora
Logical volume "tmp" created
$ ./qemu-img create ssh://localhost/dev/fedora/tmp 1G
Formatting 'ssh://localhost/dev/fedora/tmp', fmt=raw size=1073741824
filename ssh://localhost/dev/fedora/tmp: has_zero_init = 0
Cc: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-stable@nongnu.org
Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
