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>
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>
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>
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>
For QMP, we just add an attribute which is backwards compatible. For the human
monitor, we add (absolute) to the end of the line.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
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>
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>
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>
Notifiers are data-less callbacks and a notifier list is a list of registered
notifiers that all are interested in a particular event.
We'll use this in a few patches to implement mouse change notification.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
---
v1 -> v2
- Do not do memory allocations by placing list nodes in notifier
This reverts commit 3c9c706c3b.
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>
It allways returned true, that is the equivalent of not having the
callback.
Signed-off-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
values are already pointers, no need to cast them to void *
Signed-off-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
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()
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
When building with -DNDEBUG, assert(0) will not stop execution
so it must not be used for abnormal termination.
Use cpu_abort() when in CPU context, abort() otherwise.
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
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>
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>
Add an option to disable the heuristics which try to keep
capslock and numlock state for guest and host in sync.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This was the only incoming migration without autostart check
Signed-off-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Not clearing the fd and closing the file makes qemu spin using 100%CPU
after incoming migration error.
See for instance bug:
https://bugzilla.redhat.com/show_bug.cgi?id=518032
Signed-off-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Don't rely on CDROM hint for read_only attribute
Signed-off-by: Naphtali Sprei <nsprei@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Really use read-only flags for opening the file when asked for read-only
Signed-off-by: Naphtali Sprei <nsprei@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
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>
Tweaking the rounding in qemu_next_deadline ensures that there's
no change whatsoever.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
A simple patch to place together all handling of -icount.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
By adding the possibility to turn on/off a clock, yet another
incestuous relationship between timers and CPUs can be disentangled.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Make the timer subsystem register its own callback instead.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
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>
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>
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>
The ALARM_FLAG_DYNTICKS can be testing simply by checking if there is
a rearm function.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
The TIME_ONESHOT and TIME_PERIODIC flags are mutually exclusive.
The code after the patch matches the flags used in win32_start_timer.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
The code is initializing an unsigned int to UINT_MAX using "-1", so that
the following always-true comparison seems to be always-false at a
first look. Since alarm timer initializations are never nested, it is
simpler to unconditionally store the result of timeGetDevCaps into
data->period.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
When working with the VM state (for loadvm/savevm and migration), it is not
valid to load and store pointers since the validity of those pointers cannot be
assured in the new qemu address space. Therefore, virtio_balloon_save() and
virtio_balloon_load() must not handle the stats-related fields in struct
VirtIOBalloon.
If a memory stats request is in-flight at the time of a migration or savevm,
the request will not complete and should be resubmitted once migration or
loadvm completes. Note that this extremely small race window can only be
triggered using QMP so it is not possible to hang the user monitor.
Signed-off-by: Adam Litke <agl@us.ibm.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Add a logical block size attribute as various guest side tools only
increase the filesystem sector size based on it, not the advisory
physical block size.
For scsi we already have support for a different logical block size
in place for CDROMs that we can built upon. Only my recent block
device characteristics VPD page needs some fixups. Note that we
leave the logial block size for CDROMs hardcoded as the 2k value
is expected for it in general.
For virtio-blk we already have a feature flag claiming to support
a variable logical block size that was added for the s390 kuli
hypervisor. Interestingly it does not actually change the units
in which the protocol works, which is still fixed at 512 bytes,
but only communicates a different minimum I/O granularity. So
all we need to do in virtio is to add a trap for unaligned I/O
and round down the device size to the next multiple of the logical
block size.
IDE does not support any other logical block size than 512 bytes.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Many usbdevice_init implementors assume params is non-NULL.
Signed-off-by: Jan Kiszka <jan.kiszka@web.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
During boot, the screen gets resized to height 1 and a mouse click at this
point will cause a division by zero when calculating the absolute pointer
position from the pixel (x, y). Return a click in the middle of the screen
instead in this case.
Signed-off-by: Chris Webb <chris@arachsys.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
