with the "usb-ehci: cleanup port reset handling" patch in place no callers
are calling usb_attach(port, NULL) for a port where port->dev is NULL.
Doing that makes no sense as that causes the port detach op to get called
for a port with nothing attached. Add an assert that port->dev != NULL when
dev == NULL, and remove the check for not having a port->dev in the dev == NULL
case.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Doing a usb_attach when dev is NULL will just result in the
port detach op getting called even though nothing was connected in
the first place.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Note this fixes 2 things in one go, first of all the device_destroy bus
op should be a device_detach bus op, as pending async packets from the
device should be cancelled on detach not on destroy.
Secondly having this as a bus op won't work with companion controllers, since
then there will be 1 bus driven by the ehci controller and thus 1 set of bus
ops, but the device being detached may be downstream of a handed over port.
Making the detach of a downstream device a port op allows the ehci controller
to forward this to the companion controller port for handed over ports.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This makes them consistent with the attach and detach ops, and in general
it makes sense to make portops take a port as argument. This also makes
adding support for a companion controller easier / cleaner.
[ kraxel: fix usb-musb.c build ]
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This is a preparation patch for adding support for USB companion controllers.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Cleanup / preparation patch for companion controller support. Note that
as a "side-effect" this patch also fixes the milkymist-softusb controller
not having a port_location set for its ports.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
In musb_packet() handle final processing of non-asynchronous
USB packets by directly calling musb_schedule_cb() rather than
going through usb_packet_complete(). The latter will trigger
an assertion because the packet doesn't belong to a device.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Just in case there's still a way how a guest can read out buffers when it's not
supposed to, let's zero the buffers during initialisation so that we don't leak
information to the guest.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
This fixes https://bugs.launchpad.net/qemu/+bug/786209:
When the DRQ_STAT bit is set, the IDE core permits both data reads
and data writes, regardless of whether the current transfer was
initiated as a read or write.
This potentially leaks uninitialized host memory into the guest,
if, before doing anything else to an IDE device, the guest begins a
write transaction (e.g. WIN_WRITE), but then *reads* from the IO
port instead of writing to it.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
The current message doesn't clearly communicate the error cause.
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
It needs to be a qdev property, because it belongs to the drive's
guest part. Precedence: commit a0fef654 and 6ced55a5.
Bonus: info qtree now shows the serial number.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
On Linux x86_64 host with 32bit userspace, running
qemu or even just "qemu-img create -f qcow2 some.img 1G"
causes a kernel warning:
ioctl32(qemu-img:5296): Unknown cmd fd(3) cmd(00005326){t:'S';sz:0} arg(7fffffff) on some.img
ioctl32(qemu-img:5296): Unknown cmd fd(3) cmd(801c0204){t:02;sz:28} arg(fff77350) on some.img
ioctl 00005326 is CDROM_DRIVE_STATUS,
ioctl 801c0204 is FDGETPRM.
The warning appears because the Linux compat-ioctl handler for these
ioctls only applies to block devices, while qemu also uses the ioctls on
plain files. Work around by calling fstat() the ensure the ioctls are
only used on block devices.
Signed-off-by: Johannes Stezenbach <js@sig21.net>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
qemu-img currently writes disk images using writeback and filling
up the cache buffers which are then flushed by the kernel preventing
other processes from accessing the storage.
This is particularly bad in cluster environments where time-based
algorithms might be in place and accessing the storage within
certain timeouts is critical.
This patch adds the option to choose a cache method when writing
disk images.
Signed-off-by: Federico Simoncelli <fsimonce@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Until now, pxa2xx_lcd only supported 90deg rotation, but
some machines (for example Zipit Z2) needs 270deg rotation.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
Signed-off-by: Andrzej Zaborowski <andrew.zaborowski@intel.com>
Parameter 'info' is const, so add the missing attribute.
v2:
Add 'const' to the local variable info in do_cpu_reset() and to
the boot_info field in CPUARMState (suggested by Peter Maydell).
Cc: Andrzej Zaborowski <balrogg@gmail.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Stefan Weil <weil@mail.berlios.de>
Signed-off-by: Andrzej Zaborowski <andrew.zaborowski@intel.com>
report correct mode when in undefined mode.
introduces qxl_mode_to_string(), and uses it in other places too.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This fixes a problem where on windows 7 startup phase, before the qxl driver
is loaded, the drawables are sufficiently large and video like to trigger a
stream, but the lack of a filled mm time field triggers a warning in spice-gtk.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
This bug showed up after 1455084ea2, and
may be seen only on operating systems *not* using DMA to give commands
to SCSI adapter.
Signed-off-by: Hervé Poussineau <hpoussin@reactos.org>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
udivx and sdvix don't modify condition flags, so they shall not
overwrite cpu_cc_*
Signed-off-by: Artyom Tarasenko <atar4qemu@gmail.com>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
* 'ppc-next' of git://repo.or.cz/qemu/agraf:
PPC: move TLBs to their own arrays
PPC: 440: Use 440 style MMU as default, so Qemu knows the MMU type
PPC: E500: Use MAS registers instead of internal TLB representation
PPC: Only set lower 32bits with mtmsr
PPC: update openbios firmware
PPC: mpc8544ds: Add hypervisor node
PPC: calculate kernel,initrd,cmdline locations dynamically
target-ppc: Handle memory-forced I/O controller access
PPC: E500: Implement reboot controller
Use stack instead of temp_buf array in CPUState for TCG temps.
Signed-off-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Use TCG_REG_CALL_STACK instead of TCG_REG_SP for consistency.
Acked-by: Richard Henderson <rth@twiddle.net>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Commit f26e428da5 fixed compilation
with --enable-vnc-png, but broke it with --enable-vnc-png.
The breakage is caused by pngconfig.h which checks whether
setjmp.h was already included and fails because qemu-common.h
includes setjmp.h.
The check is disabled by defining PNG_SKIP_SETJMP_CHECK.
Cc: Blue Swirl <blauwirbel@gmail.com>
Signed-off-by: Stefan Weil <weil@mail.berlios.de>
Reviewed-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
If I start qemu with:
# qemu -hda disks/test.img -enable-kvm -m 1G -snapshot \
-device virtio-serial \
-chardev socket,host=localhost,port=1234,server,nowait,id=foo \
-device virtserialport,chardev=foo,name=org.qemu.guest_agent
I get a segfault when booting a Fedora 14 guest. The backtrace says:
Program terminated with signal 11, Segmentation fault.
#0 0x0000000000420850 in handle_control_message (vser=0x3732bd0, buf=0x2c173e0, len=8) at /home/lcapitulino/src/qmp-unstable/hw/virtio-serial-bus.c:335
335 info = DO_UPCAST(VirtIOSerialPortInfo, qdev, port->dev.info);
What's happening is VIRTIO_CONSOLE_DEVICE_READY is a message for the
whole device, not for an individual port. So port is NULL. This bug was
introduced by commit a15bb0d6a9.
This commit fixes that by making the port returned by find_port_by_id()
be used only by the VIRTIO_CONSOLE_PORT_READY and
VIRTIO_CONSOLE_PORT_OPEN messages.
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Amit Shah <amit.shah@redhat.com>
Fix conflicting types for 'INT32' in basetsd.h and jmorecfg.h by
including qemu-common.h first.
Signed-off-by: Roy Tam <roytam@gmail.com>
Acked-by: Stefan Weil <weil@mail.berlios.de>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Use stack instead of temp_buf array in CPUState for TCG temps.
On Sparc64, stack pointer is not aligned but there is a fixed bias of 2047,
so don't try to enforce alignment.
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
Hans de Goede