Alexander Graf [Thu, 25 Mar 2010 13:59:02 +0000 (14:59 +0100)]
target-s390: Don't compile in virtio-pci
As soon as virtio-pci.c gets compiled and used on S390 the internal qdev magic
gets confused and tries to give us PCI devices instead of S390 virtio devices.
Since we don't have PCI on S390, we can safely not compile virtio-pci at all.
In order to do this I added a new config option "CONFIG_VIRTIO_PCI" that I
enabled for every platform except S390. Thanks to this the change should be a
complete nop for every other platform.
Signed-off-by: Alexander Graf <agraf@suse.de> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Dmitry Ilyevsky [Fri, 26 Mar 2010 00:25:36 +0000 (03:25 +0300)]
target-ppc: generic PowerPC TBL
Time base SPRs TBL/TBU should be accessible in user/priv modes for reading
as specified in POWER ISA documentation. Therefore SPRs permissions were
changed in gen_tbl function.
tcg: Disambiguate qemu_ld32u with 32-bit and 64-bit outputs.
Some targets (e.g. Alpha and MIPS64) need to keep 32-bit operands
sign-extended in 64-bit registers (regardless of the "real" sign
of the operand). For that, we need to be able to distinguish
between a 32-bit load with a 32-bit result and a 32-bit load with
a given extension to a 64-bit result. This distinction already
exists for the ld* loads, but not the qemu_ld* loads.
Reserve qemu_ld32u for 64-bit outputs and introduce qemu_ld32 for
32-bit outputs. Adjust all code generators to match.
Signed-off-by: Richard Henderson <rth@twiddle.net> Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
CC qemu-error.o
cc1: warnings being treated as errors
/home/edgar/src/c/qemu/git/qemu/qemu-error.c: In function 'error_print_loc':
/home/edgar/src/c/qemu/git/qemu/qemu-error.c:191: error: format not a string literal and no format arguments
make: *** [qemu-error.o] Error 1
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
Blue Swirl [Sat, 20 Mar 2010 08:26:27 +0000 (08:26 +0000)]
Fix mingw32 build
mkdir() only takes path argument on mingw32:
CC i386-softmmu/vl.o
/src/qemu/vl.c: In function 'qmp_add_default':
/src/qemu/vl.c:3763: error: too many arguments to function 'mkdir'
/src/qemu/vl.c:3769: error: too many arguments to function 'mkdir'
Blue Swirl [Sat, 20 Mar 2010 08:11:01 +0000 (08:11 +0000)]
Fix build
CC curses.o
cc1: warnings being treated as errors
/src/qemu/curses.c: In function 'curses_display_init':
/src/qemu/curses.c:341: error: initialization from incompatible pointer type
Anthony Liguori [Wed, 17 Mar 2010 23:00:45 +0000 (18:00 -0500)]
tap: invoke downscript when we exit abnormally
Right now, downscript is not invoked reliably. If you execute 'quit' from the
monitor, it won't be invoked.
This fixes that by converting tap to use an exit_notifier to execute the
downscript. In this case, allowing an exit notifier to include state is
critically important for the conversion.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Anthony Liguori [Wed, 17 Mar 2010 22:59:26 +0000 (17:59 -0500)]
Convert atexit users to exit_notifier
All of these users have global state so we really don't see a benefit from
exit_notifier. However, using exit_notifier means that there's one less
justification for having global state in the first place.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Anthony Liguori [Wed, 10 Mar 2010 15:42:58 +0000 (09:42 -0600)]
sdl: use mouse mode notifier
Today we poll the mouse mode whenever there is a mouse movement. There is a
subtle usability problem with this though.
If we're in relative mode and grab is enabled, when we change to absolute mode,
we break grab. This gives a user a seamless transition when the new pointer
is enabled.
But because we poll for mouse change, this grab break won't occur until the user
attempts to move the mouse. By using notifiers, the grab break happens as soon
as possible.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Anthony Liguori [Wed, 10 Mar 2010 15:38:29 +0000 (09:38 -0600)]
input: make vnc use mouse mode notifiers
When we switch to absolute mode, we send out a notification (if the client
supports it). Today, we only send this notification when the client sends us
a mouse event and we're in the wrong mode.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Anthony Liguori [Tue, 9 Mar 2010 19:25:00 +0000 (13:25 -0600)]
Add notifier for mouse mode changes
Right now, DisplayState clients rely on polling the mouse mode to determine
when the device is changed to an absolute device. Use a notification list to
add an explicit notification.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Anthony Liguori [Tue, 9 Mar 2010 20:26:40 +0000 (14:26 -0600)]
Add kbd_mouse_has_absolute()
kbd_mouse_is_absolute tells us whether the current mouse handler is an absolute
device. kbd_mouse_has_absolute tells us whether we have any device that is
capable of absolute input.
This lets us tell a user that they have configured an absolute device but that
the guest is not currently using it.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Anthony Liguori [Wed, 10 Mar 2010 02:52:22 +0000 (20:52 -0600)]
Rewrite mouse handlers to use QTAILQ and to have an activation function
And convert usb-hid to use it (to avoid regression with bisection)
Right now, when we do info mice and we've added a usb tablet, we don't see it
until the guest starts using the tablet. We implement this behavior in order
to provide a means to delay registration of a mouse handler since we treat
the last registered handler as the current handler.
This is a usability problem though as we would like to give the user feedback
that they've either 1) not added an absolute device 2) there is an absolute
device but the guest isn't using it 3) we have an absolute device and it's
active.
By using QTAILQ and having an explicit activation function that moves the
handler to the front of the queue, we can implement the same semantics as
before with respect to automatically switching to usb tablet while providing
the user with a whole lot more information.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This breaks build (gcc 4.3.2):
CC usb-linux.o
cc1: warnings being treated as errors
/src/qemu/usb-linux.c: In function 'usb_linux_update_endp_table':
/src/qemu/usb-linux.c:759: error: 'type' may be used uninitialized in
this function
Reported-by: Blue Swirl <blauwirbel@gmail.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Blue Swirl [Thu, 18 Mar 2010 20:48:19 +0000 (20:48 +0000)]
Fix OpenBSD linker warning
qemu-option.o(.text+0x20f8): In function `qemu_opts_from_qdict_1':
/src/qemu/qemu-option.c:813: warning: strcpy() is almost always misused, please use strlcpy()
The usb-msd device emulation needs some small tweaks in the requests
emulations. For instance, the reset/maxlun requests are class/interface
specific so requests for them with the type class and recipient interface
bits sets have to be handled.
Signed-off-by: Arnaud Patard <arnaud.patard@rtp-net.org> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Gerd Hoffmann [Wed, 10 Mar 2010 16:47:17 +0000 (17:47 +0100)]
scsi-disk: fix buffer overflow
In case s->version is shorter than 4 bytes we overflow the memcpy src
buffer. Fix it by clearing the target buffer, then copy only the
amount of bytes we actually have.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Paolo Bonzini [Wed, 10 Mar 2010 10:38:54 +0000 (11:38 +0100)]
disentangle tcg and deadline calculation
Just tell main_loop_wait whether to be blocking or nonblocking, so that
there is no need to call qemu_cpus_have_work from the timer subsystem.
Instead, tcg_cpu_exec can say "we want the main loop not to block because
we have stuff to do".
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Paolo Bonzini [Wed, 10 Mar 2010 10:38:43 +0000 (11:38 +0100)]
tweak qemu_notify_event
Instead of testing specially next_cpu in host_alarm_handler, just do
that in qemu_notify_event. The idea is, if we are not running (or
not yet running) target CPU code, prepare things so that the execution
loop is exited asap; just make that clear.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Paolo Bonzini [Wed, 10 Mar 2010 10:38:42 +0000 (11:38 +0100)]
do not use qemu_event_increment outside qemu_notify_event
qemu_notify_event in the non-iothread case is only stopping the current
CPU. However, if the CPU is idle and the main loop is in the select
call then a call to qemu_event_increment is needed too (as done in
host_alarm_handler). Since in general one doesn't know whether the CPU
is executing or not, it is a safe bet to always do qemu_event_increment.
Another way to see it: after this patch qemu_event_increment is the
"common part" of qemu_notify_event for both the CONFIG_IOTHREAD and
!CONFIG_IOTHREAD cases, which makes sense.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Paolo Bonzini [Wed, 10 Mar 2010 10:38:41 +0000 (11:38 +0100)]
more alarm timer cleanup
The timer_alarm_pending variable is related to the alarm timer but not
placed in the struct. Also, in qemu_mod_timer the wrong flag was being
tested: the timer is rearmed in the alarm timer "bottom half", so the
right flag to test there is the "pending" flag.
Finally, I hoisted the NULL checks from alarm_has_dynticks to
host_alarm_handler.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>