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.
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 <email address hidden>
Signed-off-by: Blue Swirl <email address hidden>
(cherry picked from commit 7ff7563fc1c3c57914aafec1753219604346fe18)
Signed-off-by: Michael Roth <email address hidden>
a8cd6f7...
by
Hans de Goede <email address hidden>
ehci: Fix NULL ptr deref when unplugging an USB dev with an iso stream active
Signed-off-by: Hans de Goede <email address hidden>
(cherry picked from commit 7ce86aa1aafaa65e7d3e572873bdf37bdb896f49)
Conflicts:
hw/usb/hcd-ehci.c
Signed-off-by: Michael Roth <email address hidden>
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 <email address hidden>
Signed-off-by: Michael S. Tsirkin <email address hidden>
Signed-off-by: Anthony Liguori <email address hidden>
(cherry picked from commit 3cac001e5ae3c0ceb33e0a1978a48cb5e2482ab2)
Conflicts:
hw/msix.c
hw/virtio-pci.c
Signed-off-by: Michael Roth <email address hidden>
Signed-off-by: Michael Roth <email address hidden>
28846ad...
by
Stefano Stabellini <email address hidden>
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 <email address hidden>
Reviewed-by: Stefan Weil <email address hidden>
Tested-by: Andreas Färber <email address hidden>
Signed-off-by: Blue Swirl <email address hidden>
(cherry picked from commit 8227421e0476d9caf2a9a089465bb40c23834e33)
Signed-off-by: Michael Roth <email address hidden>
