qemu_rearm_alarm_timer: do not call rearm if the next deadline is INT64_MAX

qemu_rearm_alarm_timer partially duplicates the code in
qemu_next_alarm_deadline to figure out if it needs to rearm the timer.
If it calls qemu_next_alarm_deadline, it always rearms the timer even if
the next deadline is INT64_MAX.

This patch simplifies the behavior of qemu_rearm_alarm_timer and removes
the duplicated code, always calling qemu_next_alarm_deadline and only
rearming the timer if the deadline is less than INT64_MAX.

Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Reviewed-by: Stefan Weil <sw@weilnetz.de>
Tested-by: Andreas Färber <andreas.faerber@web.de>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
(cherry picked from commit 8227421e0476d9caf2a9a089465bb40c23834e33)

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
reset PMBA and PMREGMISC PIIX4 registers.

The bug causes Windows + OVMF hang after reboot since OVMF
checks PMREGMISC to see if IO space is enabled and skip
configuration if it is.

Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Gleb Natapov <gleb@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
(cherry picked from commit 4d09d37c6aa9a02b44b1fdb6268820fab92499bd)

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
msix: make [un]use vectors on reset/load optional

The facility to use/unuse vectors dynamically is helpful
for virtio but little else: everyone just seems to use
vectors in their init function.

Avoid clearing msix vector use info on reset and load.
For virtio, clear it explicitly.
This should fix regressions reported with ivshmem - though
I didn't test this, I verified that virtio keeps
working like it did.

Tested-by: Cam Macdonell <cam@cs.ualberta.ca>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
(cherry picked from commit 3cac001e5ae3c0ceb33e0a1978a48cb5e2482ab2)

Conflicts:

	hw/msix.c
	hw/virtio-pci.c

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
ehci: Fix NULL ptr deref when unplugging an USB dev with an iso stream active

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
(cherry picked from commit 7ce86aa1aafaa65e7d3e572873bdf37bdb896f49)

Conflicts:

	hw/usb/hcd-ehci.c

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
target-xtensa: fix big-endian BBS/BBC implementation

Quote from ISA, 2.1:

For most Xtensa instructions, bit numbering is irrelevant; only the BBC
and BBS instructions assign bit numbers to values on which the processor
operates. The BBC/BBS instructions use big-endian bit ordering (0 is the
most-significant bit) on a big-endian processor configuration.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
(cherry picked from commit 7ff7563fc1c3c57914aafec1753219604346fe18)

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
target-xtensa: return ENOSYS for unimplemented simcalls

This prevents guest from proceeding with uninitialised garbage returned
from unimplemented simcalls.

Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
(cherry picked from commit e7eee62a90c671d22d50964b7de05e3f4fd96f5f)

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
qemu-timer: properly arm alarm timer for timers set by device initialization

QEMU will hang when fed the following command-line

  qemu-system-mips -kernel vmlinux-2.6.32-5-4kc-malta -append "console=ttyS0" -nographic -net none

The -net none is important otherwise it seems some events are generated
causing the things to work. When it doesn't work, the guest hangs when
measuring the CPU frequency, after the following line:

  [    0.000000] NR_IRQS:256

Pressing a key on the serial port unblocks it, hinting that the problem
is due to the recent elimination of the 1 second timeout in the main
loop.

The problem is that because init_timer_alarm sets the timer's pending
flag to true, the alarm timer is never armed until after the first time
through the main loop.  Thus the bug started when QEMU started testing
the pending flag in qemu_mod_timer (commit 1828be3, more alarm timer
cleanup, 2010-03-10).

But actually, it isn't true at all that a timer is pending when the
alarm timer is created, and the real bug has been latent forever: the
fix is to remove the bogus setting of pending flag.

Reported-by: Aurelien Jarno <aurelien@aurel32.net>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com>
Tested-by: Aurelien Jarno <aurelien@aurel32.net>
Tested-by: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
(cherry picked from commit de188751da8db3c77a681bf903035a0e5218c463)

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>
console: bounds check whenever changing the cursor due to an escape code

This is XSA-17 / CVE-2012-3515

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
update VERSION for 1.1.2

Signed-off-by: Michael Roth <mdroth@linux.vnet.ibm.com>