Avoids confusion with the global ppm_save() defined in hw/vga.c.
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
All devices that register a screen dump callback via
graphic_console_init() are updated.
The new argument is not used in this commit. Error handling will
be added to each device individually later.
This change is a preparation to convert the screendump command
to the QAPI.
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Report from smatch:
json-parser.c:474 parse_object(62) error: potential null derefence 'dict'.
json-parser.c:553 parse_array(75) error: potential null derefence 'list'.
Label 'out' in json-parser.c can be called with list == NULL
which is passed to QDECREF.
Modify QDECREF to handle a NULL argument (inline function qobject_decref
already handles them, too).
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Report from smatch:
qapi-visit.c:1640 visit_type_BlockdevAction(8) error:
we previously assumed 'obj' could be null (see line 1639)
qapi-visit.c:2432 visit_type_NetClientOptions(8) error:
we previously assumed 'obj' could be null (see line 2431)
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Convert 'sendkey' to use QAPI.
QAPI passes key's index of mapping table to qmp_send_key(),
not keycode. So we use help functions to convert key/code to
index of key_defs, and 'index' will be converted to 'keycode'
inside qmp_send_key().
For qmp, QAPI would check invalid key and raise error.
For hmp, invalid key is checked in hmp_send_key().
'send-key' of QMP doesn't support key in hexadecimal format.
Signed-off-by: Amos Kong <akong@redhat.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
This patch added two help functions to convert key/code to index of
mapping table, those functions will return Q_KEY_CODE_MAX if the
code/key is invalid.
Patch also moved key_defs[] to input.c, and removed useless KeyDef struct.
Key's index in QKeyCode enmu is same as keycode's index in new key_defs[].
Monitor functions were changed to access key_defs[] directly.
key_defs[] is used in do_send_key(), so export key_defs[]. It will be
changed to static in next patch.
Signed-off-by: Amos Kong <akong@redhat.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
key_defs[] in monitor.c is a mapping table of keys and keycodes,
this patch added a QKeyCode enum. Key's index in the enmu is same
as keycode's index in key_defs[].
Signed-off-by: Amos Kong <akong@redhat.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Currently, if we define an 'enum' and use it in one command's
data, list struct for enum could not be generated, but it's
used in qmp function.
For example: KeyCodesList could not be generated.
>>> qapi-schema.json:
{ 'enum': 'KeyCodes',
'data': [ 'shift', 'alt' ... ] }
{ 'command': 'sendkey',
'data': { 'keys': ['KeyCodes'], '*hold-time': 'int' } }
>>> qmp-command.h:
void qmp_sendkey(KeyCodesList * keys, bool has_hold_time, int64_t
hold_time, Error **errp);
This patch lets qapi generate list struct and visit_list for enum.
Signed-off-by: Amos Kong <akong@redhat.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
There are many maps of keycode 0x56 in pc-bios/keymaps/*
pc-bios/keymaps/common:less 0x56
pc-bios/keymaps/common:greater 0x56 shift
pc-bios/keymaps/common:bar 0x56 altgr
pc-bios/keymaps/common:brokenbar 0x56 shift altgr
This patch just renamed '<' to 'less', QAPI might add new
variable by adding a prefix to keyname, '$PREFIX_<' is not
available, '$PREFIX_less' is ok.
For compatibility, convert user inputted '<' to 'less'.
Signed-off-by: Amos Kong <akong@redhat.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
(qemu) sendkey a
(qemu) sendkey 0x1e
(qemu) sendkey #0x1e
unknown key: '#0x1e'
The last command doesn't work, '#' is not requested before
raw values, and the raw value in decimal format is not supported.
Signed-off-by: Amos Kong <akong@redhat.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Add a '-p' arg to the QMP/qmp-shell test program, which uses
the python pprint module to pretty-print the dictionary
returned from a command
$ qmp-shell -p /tmp/qemu
Welcome to the QMP low-level shell!
Connected to QEMU 1.1.50
(QEMU) query-cpus
{ u'return': [ { u'CPU': 0,
u'current': True,
u'halted': True,
u'pc': 1048556,
u'thread_id': 7108}]}
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
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>
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>
ccc-analyzer reports this warning:
console.c:1090:29: warning: Dereference of null pointer
if (active_console->cursor_timer) {
^
Function console_select allows active_console to be NULL,
but would crash when accessing cursor_timer. Fix this.
Reviewed-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
* kraxel/usb.61:
uas: move transfer kickoff
ehci: Fix interrupt endpoints no longer working
ehci: handle TD deactivation of inflight packets
ehci: add ehci_cancel_queue()
ehci: simplify ehci_state_executing
ehci: Remove unnecessary ehci_flush_qh call
ehci: Schedule async-bh when IAAD bit gets set
ehci: Fix NULL ptr deref when unplugging an USB dev with an iso stream active
usb: unique packet ids
usb: Halt ep queue en cancel pending packets on a packet error
fix info qtree indention
* kwolf/for-anthony:
qemu-iotests: add backing file smaller than image test case
stream: complete early if end of backing file is reached
qed: refuse unaligned zero writes with a backing file
Kick next scsi transfer from request release callback instead of command
completion callback, otherwise we might get stuck in case scsi_req_unref()
doesn't release the request instantly due to someone else holding a
reference too.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
One of the recent changes (likely the addition of queuing support) has broken
interrupt endpoints, this patch fixes this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
ehci_state_executing does not need to check for p->usb_status == USB_RET_ASYNC
or USB_RET_PROCERR, since ehci_execute_complete already does a similar check
and will trigger an assert if either value is encountered.
USB_RET_ASYNC should never be the packet status when execute_complete runs
for obvious reasons, and USB_RET_PROCERR is only used by ehci_state_execute /
ehci_execute not by ehci_state_executing / ehci_execute_complete.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
ehci_qh_do_overlay() already calls ehci_flush_qh() before it returns, calling
it twice is useless.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
After the "ehci: Print a warning when a queue unexpectedly contains packets
on cancel" commit. Under certain reproducable conditions I was getting the
following message: "EHCI: Warning queue not empty on queue reset".
After aprox. 8 hours of debugging I've finally found the cause. The Linux EHCI
driver has an IAAD watchdog, to work around certain EHCI hardware sometimes
not acknowledging the doorbell at all. This watchdog has a timeout of 10 ms,
which is less then the time between 2 runs through the async schedule when
async_stepdown is at its highest value.
Thus the watchdog can trigger, after which Linux clears the IAAD bit and
re-uses the QH. IOW we were not properly detecting the unlink of the qh, due
to us missing (ignoring for more then 10 ms) the IAAD command, which triggered
the warning.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
This patch adds IDs to usb packets. Those IDs are (a) supposed to be
unique for the lifecycle of a packet (from packet setup until the packet
is either completed or canceled) and (b) stable across migration.
uhci, ohci, ehci and xhci use the guest physical address of the transfer
descriptor for this.
musb needs a different approach because there is no transfer descriptor.
But musb also doesn't support pipelining, so we have never more than one
packet per endpoint in flight. So we go create an ID based on endpoint
and device address.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
For controllers which queue up more then 1 packet at a time, we must halt the
ep queue, and inside the controller code cancel all pending packets on an
error.
There are multiple reasons for this:
1) Guests expect the controllers to halt ep queues on error, so that they
get the opportunity to cancel transfers which the scheduled after the failing
one, before processing continues
2) Not cancelling queued up packets after a failed transfer also messes up
the controller state machine, in the case of EHCI causing the following
assert to trigger: "assert(p->qtdaddr == q->qtdaddr)" at hcd-ehci.c:2075
3) For bulk endpoints with pipelining enabled (redirection to a real USB
device), we must cancel all the transfers after this a failed one so that:
a) If they've completed already, they are not processed further causing more
stalls to be reported, originating from the same failed transfer
b) If still in flight, they are cancelled before the guest does
a clear stall, otherwise the guest and device can loose sync!
Note this patch only touches the ehci and uhci controller changes, since AFAIK
no other controllers actually queue up multiple transfer. If I'm wrong on this
other controllers need to be updated too!
Also note that this patch was heavily tested with the ehci code, where I had
a reproducer for a device causing a transfer to fail. The uhci code is not
tested with actually failing transfers and could do with a thorough review!
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Without the patch bus properties are are not in line with the other
properties:
[ ... ]
dev: fw_cfg, id ""
ctl_iobase = 0x510
data_iobase = 0x511
irq 0
mmio ffffffffffffffff/0000000000000002
mmio ffffffffffffffff/0000000000000001
[ ... ]
With the patch applied everything is lined up properly:
[ ... ]
dev: fw_cfg, id ""
ctl_iobase = 0x510
data_iobase = 0x511
irq 0
mmio ffffffffffffffff/0000000000000002
mmio ffffffffffffffff/0000000000000001
[ ... ]
Needed to make the autotest qtree parser happy.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Commit ef8621b1a3 added an include
file which is not available for MinGW compilations.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
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>
Support get/set of new PV EOI MSR, for migration.
Add an optional section for MSR value - send it
out in case MSR was changed from the default value (0).
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Update linux-headers to version present in Linux 3.6-rc3.
Header asm-x96_64/kvm_para.h update is needed for the new PV EOI
feature.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
We have a problem with how we handle migration with KVM paravirt features.
We unconditionally enable paravirt features regardless of whether we know how
to migrate them.
We also don't tie paravirt features to specific machine types so an old QEMU on
a new kernel would expose features that never existed.
The 1.2 cycle is over and as things stand, migration is broken. Michael has
another series that adds support for migrating PV EOI and attempts to make it
work correctly for different machine types.
After speaking with Michael on IRC, we agreed to take this patch plus 1 & 4
from his series. This makes sure QEMU can migrate PV EOI if it's enabled, but
does not enable it by default.
This also means that we won't unconditionally enable new features for guests
future proofing us from this happening again in the future.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
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>
Clang reports this warning:
Null pointer passed as an argument to a 'nonnull' parameter
Reviewed-by: Luiz Capitulino <lcapitulino@redhat.com>
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
The last argument of find_portio is "write", so this must be true here.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
setup_ioeventfds() is unnecessary and actually causes a segfault when used
ioeventfd=on is used on the command-line. Since ioeventfds are handled within
the memory API, it can be removed.
Signed-off-by: Cam Macdonell <cam@cs.ualberta.ca>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
