The x86_64 ror instruction on a 32-bit host can generate up to 77 TCG
ops. Some more space should be left for opc that are added at the end
of the translation.
Thanks to Laurent Desnogues for the debugging help.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Backport from master:
Recent versions of the Linux kernel will not preempt CPU-intensive
tasks unless the clock used by sched_clock() works. On -M versatilepb
that's the 24MHz timer in the system controller. It's a very simple
timer, so implement it.
Signed-off-by: Daniel Jacobowitz <dan@codesourcery.com>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Don't call curses_resize() at the end of curses_display_init() as height
and width are not yet defined. It will be called later by code from
vl.c.
This save 250MB of memory when using -curses.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Split socket closing and releasing of VncState into two steps. First close
the socket and set the variable to -1 to indicate shutdown in progress. Do
the actual release in a few places where we can be sure it doesn't cause
trouble in form of use-after-free. Add some checks for a valid socket handle
to make sure we don't try to use the closed socket.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Backported to 0.10-stable, removing references to vs->force_update and
changing vnc_disconnect_finish() to match the code in the 0.10 version of
vnc_client_io_error() in place of the master branch version.
Signed-off-by: Chris Webb <chris@arachsys.com>
Signed-off-by: Glauber Costa <glommer@redhat.com>
When trying to do detached migration with exec, I found that
the monitor wouldn't always return in a timely manner. I
tracked this down to exec_start_outgoing_migration. It
appeared we were setting the fd to NONBLOCK'ing, but in
point of fact we weren't.
This bugfix should also go onto the stable 0.10 branch
Signed-off-by: Chris Lalancette <clalance@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Glauber Costa <glommer@redhat.com>
qemu-system-arm (0.10.5) segfaults when invoked with a PXA machine target,
e.g. -M tosa. The reason is fairly obvious:
[backport: current code uses struct scoop_info_s instead of a typedef ]
Signed-off-by: Torsten Duwe <duwe@lst.de>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Andrzej Zaborowski <balrogg@gmail.com>
Signed-off-by: Glauber Costa <glommer@redhat.com>
Windows seems to be very stupid about cdrom media change. It polls
cdrom status and if status goes ready->media not present->ready
it assumes that media was changed. If "media not present" step doesn't
happen even if "medium may have changed" was seen it assumes media
haven't changed. Fake "media not present" step.
Filip Navara did a great job debugging this issue in Windows and this is
what he found out:
BINGO! ... The media present notifications were broken ever since
Windows 2000 it seems. The media change is detected properly and it's
passed to ClassSetMediaChangeState function which in turn calls
ClasspInternalSetMediaChangeState. This function is responsible for
changing some internal state of the device object and sending the PnP
events which later result in application notifications. It has this
tiny bit of code (not copied byte for byte):
if (oldMediaState == NewState) {
// Media is in the same state it was before.
return;
}
so the end result is that for the case of UNIT NEEDS ATTENTION /
MEDIUM MAY HAVE CHANGED without NOT READY in-between is really broken.
It results in the internal media change counter incremented, so the
media contents are re-read when necessary, instead of relying on the
cache, but the notifications to applications are never sent.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Message-Id:
Signed-off-by: Glauber Costa <glommer@redhat.com>
Once again, the emulation of the EERD and ICS registers in e1000.c is
incorrect. Nobody has noticed this before because none of the Intel-written
e1000 drivers use these registers, and all of the independently written open
source drivers copy Intel's example, so they don't use them either.
Regardless, these registers are documented in the programmer's manuals, and
their emulated behavior doesn't match the verified behavior of real hardware,
so any software that does use them doesn't function correctly.
-Bill
Signed-off-by: Bill Paul <wpaul@windriver.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Glauber Costa <glommer@redhat.com>
When sending a copyrect command to the vnc client, we must also update
the local server surface. Otherwise the server's and the client's idea
of the screen content run out of sync and screen updates don't work
correctly.
[ backport: uses ds_get_data() instead of direct dereference ]
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Glauber Costa <glommer@redhat.com>
Since migration returns right away, starting the VM right
after calling qemu_start_incoming_migration is wrong even
if -S is not passed. We have to do this after migration
has completed.
Cc: Glauber Costa <glommer@redhat.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Glauber Costa <glommer@redhat.com>
While fixing migration with -S, commit
89befdd1a6 broke the rest of us. Poor
glommer, with a poor family, spare him his life from this monstruosity.
Since the unconditional vm_start, not autostart was the villain, I'm putting
back autostart. Let me know if you prefer other solutions, it doesn't really matter,
doesn't really matter to me.
Any way the wind blows...
Signed-off-by: Glauber Costa <glommer@redhat.com>
CC: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Glauber Costa <glommer@redhat.com>
Instead of storing the backing file in its own BlockDriverState, VMDK uses the
BlockDriverState of the raw image file it opened. This is wrong and breaks
functions that access the backing file or protocols. This fix replaces all
occurrences of s->hd->backing_* with bs->backing_*.
This fixes qemu-iotests failure in 020 (Commit changes to backing file).
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Glauber Costa <glommer@redhat.com>
This patch requires "Handle BH's queued by AIO completions in
qemu_aio_flush()" to work reliably. The combination of those two
patches survived 300+ migrations with heavy IO load running in the
guest.
Signed-off-by: Nolan Leake <nolan <at> sigbus.net>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Glauber Costa <glommer@redhat.com>
Without this, the call to qemu_aio_flush during migration doesn't
actually flush all in-flight SCSI IOs.
Signed-off-by: Nolan Leake <nolan <at> sigbus.net>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Glauber Costa <glommer@redhat.com>
The sequence of reading from eeprom is "offset by one" moved because of a false
detection of a clock cycle after an eeprom reset. Keeping the last clock value
after a reset keeps it in sync.
Signed-off-by: Naphtali Sprei <nsprei@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Glauber Costa <glommer@redhat.com>
Currently only common PS2 state is initialized, leaving keyboard and
mouse specific state to contain stale values.
Signed-off-by: Dinesh Subhraveti <dineshs@us.ibm.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Without this, after system reset, hpet does not detect transition from
non-legacy to legacy mode.
Signed-off-by: Beth Kon <eak@us.ibm.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
-S is not honored by qemu on incoming migration. If a domain is migrated
while paused, thus, it will start running on the remote machine; this
is wrong.
Given the trivial patch to fix this, it looks more like a thinko
than anything else, probably dating back to the qemu-kvm merge.
The interesting part is that the -S mechanism was in fact *used* when
migrating (setting autostart = 0) and the incoming migration code was
starting the VM at the end of the migration.
Since I was removing the vm_start from there, I also corrected a related
imprecision. The code was doing a vm_stop "just in case", but we can
be sure that the VM is not running---the vm_start call in vl.c has not
been reached yet. So the vm_stop is removed together with the vm_start.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This reverts commit accceed914.
This has proven to cause all sorts of odd build breakages. I don't think it's
quite ready for stable.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
When we finish migration, there may be pending async io requests
in flight. If we don't flush it before stage3 starting, it might be
the case that the guest loses it.
Signed-off-by: Glauber Costa <glommer@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Otherwise if you hot remove an eepro100 NIC and then migrate,
you get:
Unknown savevm section or instance 'eeprom' 0
on the destination side.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
destroy_nic() requires that NICInfo::private by a PCIDevice pointer,
but then goes on to require that the same pointer matches
VLANClientState::opaque.
That is no longer the case for virtio-net since qdev and wasn't
previously the case for rtl8139, ne2k_pci or eepro100.
Make the situation a lot more clear by maintaining a VLANClientState
pointer in NICInfo.
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Valgrind was so kind to remark that no one bothers to release keycodes
after use and that something is fishy about cleaning up the requested
keyboard descriptor. With this patch applied, we no longer leak about
12k during startup.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
fix memory leak in cpu_unregister_map_client() and cpu_notify_map_clients().
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
vga_screen_dump_blank() was not generating a valid PPM file: the width of the
image made no sense (why it was multiplied by sizeof(uint32_t)?), and there was
only one sample per pixel, instead of three.
(cherry picked from commit 77d4db015c)
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Section 10.8.25 ("START/STOP UNIT Command") of SFF-8020i states that
if the device is locked we should refuse to eject if the device is
locked.
ASC_MEDIA_REMOVAL_PREVENTED is the appropriate return in this case.
In order to stop itself from ejecting the media it is running from,
Fedora's installer (anaconda) requires the CDROMEJECT ioctl() to fail
if the drive has been previously locked.
See also https://bugzilla.redhat.com/501412
(cherry picked from commit aea2a33c73)
Signed-off-by: Mark McLoughlin <markmc@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
User space may only inject interrupts during kvm_arch_pre_run if
ready_for_interrupt_injection is set in kvm_run. But that field is
updated on exit from KVM_RUN, so we must ensure that we enter the
kernel after potentially queuing an interrupt, otherwise we risk to
loose one - like it happens with the current code against latest
kernel modules (since kvm-86) that started to queue only a single
interrupt.
Fix the problem by reordering kvm_cpu_exec.
Credits go to Gleb Natapov for analyzing the issue in details.
(cherry picked from commit 8c14c17395)
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
As per the IA32 processor manual, the accessed bit is set to 1 in the
processor state after reset. qemu pc cpu_reset code was missing this
accessed bit setting.
(cherry picked from commit 538f368612)
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
qemu_aio_wait by invoking the bh or one of the aio completion
callbacks, could end up submitting new pending aio, breaking the
invariant that qemu_aio_flush returns only when no pending aio is
outstanding (possibly a problem for migration as such).
(cherry picked from commit 986c28d655)
Signed-off-by: Andrea Arcangeli <aarcange@redhat.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Kevin Wolf <kwolf@redhat.com>
It may happen that the io-handler is still registered. That causes
select() to return with EBADF, not calling handlers for other fds.
The io-handler would be registered when (on the source) the whole state
was written but not yet flushed. For example when using QEMUFileBuffered,
(tcp-migration) there may be data left in a buffer waiting to be transferred.
In such a case buffered_close() calls buffered_flush() which calls
migrate_fd_put_buffer, which may, upon EAGAIN, register migrate_fd_put_notify
as a handler.
(cherry picked from commit e19252d32c)
Signed-off-by: Uri Lublin <uril@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Sometimes, upon interrupt, fread returns with no data, and
the (incoming exec) migration fails.
Fix by retrying on such a case.
(cherry picked from commit 8a67ec4d84)
Signed-off-by: Uri Lublin <uril@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
After creating an automated regression test to test the sysrq
responses while running a linux image in qemu, I found that the
simulated uart was eating the character right after the sysrq about
75% of the time.
The problem is that the qemu sets the LSR_DR (data ready) bit on a
serial break. The automated tests can send a break and the sysrq
character quickly enough that the qemu serial fifo has a real
character available. When there is valid character in the fifo, it
gets consumed by the serial driver in the guest OS.
The real hardware also appears to set the LSR_DR but always appears to
have a null byte in this condition. This patch changes the qemu
behavior to match the tested characteristics of a real 16550 chip.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Glauber Costa <glommer@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Use timer to separate them in time.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Glauber Costa <glommer@redhat.com>
In case no symbolic name is provided when requesting VLAN connection via
listening TCP socket ('-net socket,listen=...'), qemu crashes. This
fixes the cause.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Signed-off-by: Glauber Costa <glommer@redhat.com>
All,
I've recently been playing around with migration via exec. Unfortunately,
when starting the incoming qemu process with "-incoming exec:cmd", it suffers
the same problem that -incoming tcp used to suffer; namely, that you can't
interact with the monitor until after the migration has happened. This causes
problems for libvirt usage of -incoming exec, since libvirt expects to be able
to access the monitor ahead of time. This fairly simple patch allows you to
access the monitor both before and after the migration has completed using exec.
(note: developed/tested with qemu-kvm, but applies perfectly fine to qemu)
Signed-off-by: Chris Lalancette <clalance@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
raw_pread_aligned currently returns the raw return value from
lseek/read, which is always -1 in case of an error. But the
callers higher up the stack expect it to return the negated
errno just like raw_pwrite_aligned.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Pointer vs addresses a VncDisplay structure,
so it is sufficient to allocate sizeof(VncDisplay)
or sizeof(*vs) bytes instead of the much larger
sizeof(VncState).
Maybe the misleading name should be fixed, too:
the code contains many places where vs is used,
sometimes it is a VncState *, sometimes it is a
VncDisplay *. vd would be a better name.
Signed-off-by: Stefan Weil <weil@mail.berlios.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
When a reset is requested, the current e1000 emulation never clears the
reset bit which may cause a driver to hang. This patch masks the reset
bit out when setting the control registert, so the reset is immediately
completed.
Signed-off-by: Kevin Wolf <mail@kevin-wolf.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Aurelien Jarno