When operating on the SCIF, process all the received characters, as long
as the FIFO can handle them.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
When a modifier key is pressed or released, the USB HID keyboard still
answers NAK, unless another key is also pressed or released.
The patch fixes that by calling usb_hid_changed() when a modifier key
is pressed or released.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
When reading cp0_count from a timer with a late trigger that should
already have expired, expire it and raise the timer irq.
This makes it possible for guest code (e.g, Linux) that first read
cp0_count, then compare it with cp0_compare and check for raised
timer interrupt lines to run reliably.
Acked-by: Aurelien Jarno <aurelien@aurel32.net>
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
Reorganize for future patches, no functional change.
Acked-by: Aurelien Jarno <aurelien@aurel32.net>
Signed-off-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
Linux kernel started to use the SM501 2D engine for the console, and
especially the copyrect operation.
Implement this operation so that recent kernels can be used with QEMU.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
The USB keyboard emulation's translation table in hw/usb-hid.c doesn't
match the codes actually sent for the Logo (a.k.a. "Windows") or Menu
keys. This results in the guest OS not being able to receive these keys
at all when the USB keyboard emulation is being used.
In particular, both the keymap in /usr/share/kvm/keymaps/modifiers and
the evdev table in x_keymap.c map these keys to 0xdb, 0xdc, and 0xdd,
while usb_hid_usage_keys[] seems to be expecting them to be mapped to
0x7d, 0x7e, and 0x7f.
The attached patch seems to fix the problem, at least in my (limited)
testing.
http://bugs.debian.org/578846http://bugs.debian.org/600593 (cloned from the above against different pkg)
https://bugs.launchpad.net/qemu/+bug/584139
Signed-Off-By: Brad Jorsch <anomie@users.sourceforge.net>
Signed-Off-By: Michael Tokarev <mjt@tls.msk.ru>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
lsi_ram_read*() and lsi_ram_write*() are not consistent, one uses
leXX_to_cpu() the other uses nothing. As the comment above the RAM
declaration says: "Script ram is stored as 32-bit words in host
byteorder.", remove the leXX_to_cpu() calls.
This fixes the boot of an ARM versatile machine on MIPS and PowerPC
hosts.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Board id can't be written with stl_phys() as it's read-only part of
memory. Use stl_p() on the memory buffer instead.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Fix a buffer overflow, reported by cppcheck:
[/src/qemu/hw/ppc405_uc.c:72]: (error) Buffer access out-of-bounds: bd.bi_s_version
The use of field bi_s_version seems to be a typo, it should be
bi_r_version.
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Fix a buffer overflow, reported by cppcheck:
[/src/qemu/hw/lan9118.c:849]: (error) Buffer access out-of-bounds: s.eeprom
All eeprom handling code assumes that the size of eeprom is 128,
except lan9118_eeprom_cmd. Fix this by restricting the address passed.
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
- Don't return status from start/stop functions where it's ignored
- report errors to make debugging easier
- assert on unexpected failures
- don't disable notifiers on error so that we'll
retry when guest driver restarts
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Virtqueue notify is currently handled synchronously in userspace virtio. This
prevents the vcpu from executing guest code while hardware emulation code
handles the notify.
On systems that support KVM, the ioeventfd mechanism can be used to make
virtqueue notify a lightweight exit by deferring hardware emulation to the
iothread and allowing the VM to continue execution. This model is similar to
how vhost receives virtqueue notifies.
The result of this change is improved performance for userspace virtio devices.
Virtio-blk throughput increases especially for multithreaded scenarios and
virtio-net transmit throughput increases substantially.
Some virtio devices are known to have guest drivers which expect a notify to be
processed synchronously and spin waiting for completion.
For virtio-net, this also seems to interact with the guest stack in strange
ways so that TCP throughput for small message sizes (~200bytes)
is harmed. Only enable ioeventfd for virtio-blk for now.
Care must be taken not to interfere with vhost-net, which uses host
notifiers. If the set_host_notifier() API is used by a device
virtio-pci will disable virtio-ioeventfd and let the device deal with
host notifiers as it wishes.
Finally, there used to be a limit of 6 KVM io bus devices inside the
kernel. On such a kernel, don't use ioeventfd for virtqueue host
notification since the limit is reached too easily. This ensures that
existing vhost-net setups (which always use ioeventfd) have ioeventfds
available so they can continue to work.
After migration and on VM change state (running/paused) virtio-ioeventfd
will enable/disable itself.
* VIRTIO_CONFIG_S_DRIVER_OK -> enable virtio-ioeventfd
* !VIRTIO_CONFIG_S_DRIVER_OK -> disable virtio-ioeventfd
* virtio_pci_set_host_notifier() -> disable virtio-ioeventfd
* vm_change_state(running=0) -> disable virtio-ioeventfd
* vm_change_state(running=1) -> enable virtio-ioeventfd
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Move tracking vmstate change from virtio-net to virtio.c
as it is going to be used by virito-blk and virtio-pci
for the ioeventfd support.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
The VirtIOPCIProxy bugs field is currently used to enable workarounds
for older guests. Rename it to flags so that other per-device behavior
can be tracked.
A later patch uses the flags field to remember whether ioeventfd should
be used for virtqueue host notification.
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
This patch tags all vga cards as not hotpluggable. The qemu
standard vga will never ever be hotpluggable. For cirrus + vmware
it might be possible to get that work some day. Todays we can't
handle that for a number of reasons though.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
This patch tags all pci devices which belong to the piix3/4 chipsets as
not hotpluggable (Host bridge, ISA bridge, IDE controller, ACPI bridge).
Acked-by: Aurelien Jarno <aurelien@aurel32.net>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
This patch adds a field to PCIDeviceInfo to tag devices as being
not hotpluggable. Any attempt to plug-in or -out such a device
will throw an error.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Some Linux kernels seems to implement ITLB/UTLB flushing through by
writing all TLB entries through the memory mapped interface instead
of writing one to MMUCR.TI.
Implement memory mapped ITLB write interface so that such kernels can
boot. This fixes https://bugs.launchpad.net/bugs/700774 .
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Commit 92d675d1c1 triggered uninitialized
variables warning with GCC 4.6. Fix them by adding zero initializers.
Acked-by: Blue Swirl <blauwirbel@gmail.com>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
This patch replaces explicit bswaps with endianness hints to the
mmio layer.
CC: Alexander Graf <agraf@suse.de>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
956a3e6bb7 introduced a bug concerning
reset bit for port 92.
Since the keyboard output port and port 92 are not compatible anyway,
let's separate them.
Reported-by: Peter Lieven <pl@dlh.net>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
--
v2: added reset handler and VMState
rtl8139 includes a cpu_register_io_memory acquired value in it's
migration data. This is not only unecessary, but we should treat
these values as unique to the VM instances since the value depends
on call order. In most cases, this miraculously still works.
However, if devices are added or removed from the system, it may
represent an ordering change, which could cause the target rtl8139
device to make use of another device's cpu_register_io_memory value.
If we detect that a hot-add/remove has occured, include a subsection
to restrict migrations only to driver versions known to include this
fix.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Create a trivial interface to track whether the machine has been
modified since boot. Adding or removing devices will trigger this
to return true. An example usage scenario for such an interface is
the rtl8139 driver which includes a cpu_register_io_memory() value
in it's migration stream. For the majority of migrations, where
no hotplug has occured in the machine, this works correctly. Once
the machine is modified, we can use this interface to detect that
and include a subsection for the device to prevent migrations to
rtl8139 versions with this bug.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
Acked-by: Juan Quintela <quintela@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Commit d85d0d3883 introduces a regression
with Windows ME that leads to a division by 0 and a crash.
It uses the color expansion rop with the source pitch set to 0. This is
something allowed, as the manual explicitely says "When the source of
color-expand data is display memory, the source pitch is ignored.".
This patch fixes this regression by computing sx, sy and others
variables only if they are going to be used later, that is for a plain
copy ROP. It basically consists in moving code.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
On big endian hosts, the curses interface is unusable: the emulated
graphic card only displays garbage, while the monitor interface displays
nothing (or rather only spaces).
The curses interface is waiting for data in native endianness, so
console_write_ch() should not do any conversion. The conversion should
be done when reading the video buffer in hw/vga.c. I supposed this
buffer is in little endian mode, though it's not impossible that the
data is actually in guest endianness. I currently have no big endian
guest to way (they all switch to graphic mode immediately).
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
The device path used for migration is currently broken for
for all devices behind a nested bridge.
Replace this by a hierarchical list of slot/function numbers, walking
the path from root down to device. Add :00 after the domain number
so that if there are no nested bridges, this is compatible
with what we have now.
Note: as pointed out by Gleb, using openfirmware paths
might be cleaner, doing this would break compatibility though,
and the IDs used are not guest or user visible at all,
so breaking the compatibility is probably not worth it.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
The s390 target doesn't compile out of the box anymore. This patch fixes all
the obvious glitches that got introduced in the last few weeks.
Signed-off-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
This patch introduce a helper function to get PCIDevice from qdev id.
This function will be used later.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
This patch exports qdev_find_recursive() for later use.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
by introducing pci-stub.c, eliminate QMP dependency on core PCI code
rquired by query-pci command.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Support flr: trigger device reset on flr config write.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
The change set of b1aeb92666 in pci branch
was mismerged. The compatibility should be kept for 0.13, not for 0.14.
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Every system should have some sort of main system bus,
so sysbus_get_default should always return a valid bus.
Without this patch, at least mipssim and malta no longer
start but raise a null pointer access exception (caused by
commit ec990eb622).
Cc: Anthony Liguori <anthony@codemonkey.ws>
Signed-off-by: Stefan Weil <weil@mail.berlios.de>
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Also trace the extra registers, and update the comments with new
info from Artyom Tarasenko.
Signed-off-by: Bob Breuer <breuerr@mc.net>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
softfloat.h's int64 type has least-width semantics.
Since we're assigning an int64_t, use plain int64_t.
v4:
* Summary change.
v3:
* Split off.
Signed-off-by: Andreas Färber <andreas.faerber@web.de>
Acked-by: Richard W.M. Jones <rjones@redhat.com>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Stefan Weil reported the regression caused by
ec990eb622 as follows
> The second regression also occurs with MIPS malta.
> Networking no longer works with the default pcnet nic.
>
> This is caused because the reset function for pcnet is no
> longer called during system boot. The result in an invalid
> mac address (all zero) and a non-working nic.
>
> For this second regression I still have no simple solution.
> Of course mips_malta.c should be converted to qdev which
> would fix both problems (but only for malta system emulation).
The issue is, it is assumed that all qbuses, qdeves are under
main_system_bus. But there are qbuses whose parent is NULL. So it
is necessary to trigger reset for those qbuses.
(On the other hand, if NULL is passed to qdev_create(), its parent bus
is main_system_bus.)
Ideally those buses should be moved under bus controller
device which is qdev. But it's not done yet.
So register qbus reset handler for qbus whose parent is NULL.
Reported-by: Stefan Weil <weil@mail.berlios.de>
Signed-off-by: "Michael S. Tsirkin" <mst@redhat.com>
Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Every system should have some sort of main system bus,
so sysbus_get_default should always return a valid bus.
Without this patch, at least mipssim and malta no longer
start but raise a null pointer access exception (caused by
commit ec990eb622).
Cc: Anthony Liguori <anthony@codemonkey.ws>
Signed-off-by: Stefan Weil <weil@mail.berlios.de>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
