Looks like the two bdrv_raw instances were missed last time.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7018 c046a42c-6fe2-441c-8c8c-71466251a162
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7014 c046a42c-6fe2-441c-8c8c-71466251a162
they are reported as DRIVE_REMOVABLE by win32.
Signed-off-by: Luca Tettamanti <kronos.it@gmail.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7010 c046a42c-6fe2-441c-8c8c-71466251a162
A const function only reads its arguments and does not use TCG
globals variables. Hence a call to such a function does not
save TCG globals variabes back to their canonical location.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7008 c046a42c-6fe2-441c-8c8c-71466251a162
This replaces a compile time option for some targets and adds
this feature to targets which did not have a compile time option.
Add monitor command to enable or disable single step mode.
Modify monitor command "info status" to display single step mode.
Signed-off-by: Stefan Weil <weil@mail.berlios.de>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7004 c046a42c-6fe2-441c-8c8c-71466251a162
The beginning of the register allocation order list on the TCG x86_64
target matches the list of clobbered registers. This means that when an
helper is called, there is almost always clobbered registers that have
to be spilled.
The same way register %rsi and %rdi are at the top of the register
allocation order list, while they can't be used for load/store
operations. This means the data and/or address registers are very often
%rsi and %rdi, and their values have to be spilled, and then moved back
to another register.
This patches changes to the allocation order to avoid those effects.
It results in a 8% gain speed in qemu-x86_64 to compress a bzip2 file,
and a 6% gain in qemu-system-mips64 to compile a small application.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@7003 c046a42c-6fe2-441c-8c8c-71466251a162
If there is still work to do, it is not safe to assume we
can end the dirty tracking. Specifically, kvm can update the dirty
tracking log inside ram_save_block(), leaving pages still out of sync
if we go with the current code.
Based on a patch by Yaniv Kamay
Signed-off-by: Glauber Costa <glommer@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6999 c046a42c-6fe2-441c-8c8c-71466251a162
This is mainly for consistency, since we don't want
anything outside of savevm setting it explicitly. There
are current no users of that in qemu tree, but there
are potential candidates on kvm-userspace. And avi
is a nice guy, let's be nice with him.
Based on a patch by Yaniv Kamay
Signed-off-by: Glauber Costa <glommer@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6998 c046a42c-6fe2-441c-8c8c-71466251a162
migrate_fd_put_ready() calls qemu_savevm_state_complete(),
but the later can fail.
If it happens, re-start the vm and propagate the error up
Based on a patch by Yaniv Kamay
Signed-off-by: Glauber Costa <glommer@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6997 c046a42c-6fe2-441c-8c8c-71466251a162
It breaks the build.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6996 c046a42c-6fe2-441c-8c8c-71466251a162
We now enforce that you cannot write beyond the end of a non-growable file.
qcow2 files are not growable but we rely on them being growable to do
savevm/loadvm. Temporarily allow them to be growable by introducing a new
API specifically for savevm read/write operations.
Reported-by: malc
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6994 c046a42c-6fe2-441c-8c8c-71466251a162
This was reported by malc.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6993 c046a42c-6fe2-441c-8c8c-71466251a162
Introduce a more canonical gdbstub configuration (system emulation only)
via the new switch '-gdb dev'. Keep '-s' as shorthand for
'-gdb tcp::1234'. Use the same syntax also for the corresponding monitor
command 'gdbserver'. Its default remains to listen on TCP port 1234.
Changes in v4:
- Rebased over new command line switches meta file
Changes in v3:
- Fix documentation
Changes in v2:
- Support for pipe-based like to gdb (target remote | qemu -gdb stdio)
- Properly update the qemu-doc
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6992 c046a42c-6fe2-441c-8c8c-71466251a162
On Windows default screen width for the command prompt (A.K.A. "DOS
window") is 80 chars. `-icount' help is 87 chars wide. So make it fit.
Signed-off-by: Robert Riebisch <rr@bttr-software.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6991 c046a42c-6fe2-441c-8c8c-71466251a162
This patch adds a new qemu-io tool that links against the block layer and
image formats and allow to exercise them without needing a guest image.
It is inspired by the xfs_io tool which does the same for plain file I/O.
In fact the libxcmd library which is the backend of xfs_io is reused by this
tool in a limited fashing (cmd.[ch] files).
This version tests out most of the plain block I/O commands with the
most notable absent commands beeing snapshot handling and real aio.
This tool is the basis of the I/O path test suite I'm working on right now.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6990 c046a42c-6fe2-441c-8c8c-71466251a162
When the vga resolution changes, a new display surface is not allocated
immediately; instead that is deferred until the next update. However,
if we're running without a display client attached, that won't happen
and the next bitblt is likely to cause a segfault by overflowing the
display surface.
Fix by reallocating the display immediately when the resolution changes.
Tested with (Windows|Linux) x (cirrus|std) x (curses|sdl).
Changes from v1:
- fix segfault when switching virtual consoles with curses
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6989 c046a42c-6fe2-441c-8c8c-71466251a162
Currently qemu unconditionally strips binaries on install. This
is a problem for packagers who may want to store/ship debug symbols
of compiled packages for debugging purposes.
Keep stripping as default for the oldtimers and add a
--disable-strip flag to override.
Signed-off-by: Riku Voipio <riku.voipio@iki.fi>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6983 c046a42c-6fe2-441c-8c8c-71466251a162
When creating large disk images w/ qcow2 format, qcow2_create is hard
coded to creating a single refcount block. This is insufficient for
large images, and will cause qemu-img to segfault as it walks off the
end of the refcount block. Keep track of the space needed during image
create and create proper number of refcount blocks accordingly.
https://bugzilla.redhat.com/show_bug.cgi?id=491943
Signed-off-by: Chris Wright <chrisw@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6982 c046a42c-6fe2-441c-8c8c-71466251a162
This fixes:
- The error message to show the actual if= argument value. It was showing
the filename instead, because 'buf' is reaused on the filename parsing.
- A bug that makes a block device to be created even when an unsupported if= arg
is passed to pci_add.
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6981 c046a42c-6fe2-441c-8c8c-71466251a162
This patch allows the use a host_device as the destination for "qemu-img
convert".
I added a ->bdrv_create function host_device. It merely verifies that
the device exists and is large enough.
A check is needed in the qemu-img convert loop to ensure that we write
out all 0 sectors to the host_device. Otherwise they end up with stale
garbage where all zero sectors were expected.
I also made the check against bdrv_is_allocated enabled for everything
_except_ host devices, since there is no point in making the block
backend write a bunch of zeros just so that we can memcmp them
immediately afterwards. Host devices can't benefit from this because
there is no way to differentiate between a sector being unallocated
because it was never written, or because it was written with all zeros
and then made a trip through qemu-img convert.
Finally, there is an unrelated fix for a typo in the error message
printed if the destination device does not support ->bdrv_create.
Signed-off-by: Nolan Leake <nolan <at> sigbus.net>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6978 c046a42c-6fe2-441c-8c8c-71466251a162
qcow2's get_cluster_offset() scans forward in the l2 table to find other
clusters that have the same allocation status as the first cluster.
This is used by (among others) qcow_is_allocated().
Unfortunately, it was not checking to be sure that it didn't fall off
the end of the l2 table. This patch adds that check.
The symptom that motivated me to look into this was that
bdrv_is_allocated() was returning false when there was in fact data
there. This is one of many ways this bug could lead to data corruption.
I checked the other place that scans for consecutive unallocated blocks
(alloc_cluster_offset()) and it appears to be OK:
nb_clusters = MIN(nb_clusters, s->l2_size - l2_index);
appears to prevent the same problem from occurring.
Signed-off-by: Nolan Leake <nolan <at> sigbus.net>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6977 c046a42c-6fe2-441c-8c8c-71466251a162
With the help of some Limoncino I noted several aspects of the QEMU coding
style, particularly where it differs from the Linux coding style as many
contributors work on both projects.
Signed-off-by: Avi Kivity <avi@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6976 c046a42c-6fe2-441c-8c8c-71466251a162
I believe this is behind the following:
https://bugs.edge.launchpad.net/ubuntu/jaunty/+source/linux/+bug/331128
virtio_pci in 2.6.25 didn't do feature negotiation correctly: it acked every
bit. Fortunately, we can detect this.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6975 c046a42c-6fe2-441c-8c8c-71466251a162
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6970 c046a42c-6fe2-441c-8c8c-71466251a162
The entire U0 area is assumed to be cacheable.
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6969 c046a42c-6fe2-441c-8c8c-71466251a162
target-ppc/translate.c puts values of type opcode_t into .opcodes
section, using GCC extension to do so, and hoping that this will make
them appear contiguously and in the source order in the resulting
executable. This assumption is not safe and is known to be violated
with certain versions of GCC, certain flags passed to it and on
certain platforms (gcc 4.3.0, -O and PPC/PPC64 for instance)
The workaround consists of adding -fno-unit-at-a-time to the list of
GCC command line options while building PPC translate.o on a PPC.
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6967 c046a42c-6fe2-441c-8c8c-71466251a162
Author: Vladimir Prus <vladimir@codesourcery.com>
Fix movcal.l/ocbi emulation.
* target-sh4/cpu.h (memory_content): New.
(CPUSH4State): New fields movcal_backup and movcal_backup_tail.
* target-sh4/helper.h (helper_movcal)
(helper_discard_movcal_backup, helper_ocbi): New.
* target-sh4/op_helper.c (helper_movcal)
(helper_discard_movcal_backup, helper_ocbi): New.
* target-sh4/translate.c (DisasContext): New field has_movcal.
(sh4_defs): Update CVS for SH7785.
(cpu_sh4_init): Initialize env->movcal_backup_tail.
(_decode_opc): Discard movca.l-backup.
Make use of helper_movcal and helper_ocbi.
(gen_intermediate_code_internal): Initialize has_movcal to 1.
Thanks to Shin-ichiro KAWASAKI and Paul Mundt for valuable feedback.
Acked-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6966 c046a42c-6fe2-441c-8c8c-71466251a162
AFAIK, it's never been enabled and hasn't even compiled in ages. Remove the
code to avoid confusion. If someone ever decides to fix it, they can get at
the old version in RCS history.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6958 c046a42c-6fe2-441c-8c8c-71466251a162
