Skip to content
Snippets Groups Projects
Select Git revision
0 results
Search by author
  • Any Author
0 authors
  1. Dec 03, 2009
    • Kevin Wolf's avatar
      qcow2: Bring synchronous read/write back to life · 08fd2f30
      Kevin Wolf authored 
      
When the synchronous read and write functions were dropped, they were replaced
by generic emulation functions. Unfortunately, these emulation functions don't
provide the same semantics as the original functions did.

The original bdrv_read would mean that we read some data synchronously and that
we won't be interrupted during this read. The latter assumption is no longer
true with the emulation function which needs to use qemu_aio_poll and therefore
allows the callback of any other concurrent AIO request to be run during the
read. Which in turn means that (meta)data read earlier could have changed and
be invalid now. qcow2 is not prepared to work in this way and it's just scary
how many places there are where other requests could run.

I'm not sure yet where exactly it breaks, but you'll see breakage with virtio
on qcow2 with a backing file. Providing synchronous functions again fixes the
problem for me.

Patchworks-ID: 35437
Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
(cherry picked from commit ef845c3b)

Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
Signed-off-by: default avatarAurelien Jarno <aurelien@aurel32.net>
      08fd2f30
  3. Dec 02, 2009
  5. Nov 27, 2009
  7. Nov 21, 2009
  9. Nov 19, 2009
  11. Nov 18, 2009
  13. Nov 17, 2009
  15. Nov 10, 2009
    • Mark McLoughlin's avatar
      net: disable draining tap queue in one go · 3e01c7b9
      Mark McLoughlin authored 
      
If qemu_send_packet_async() returns zero, it means the packet has been
queued and the sent callback will be invoked once it has been flushed.

This is only possible where the NIC's receive() handler returns zero
and promises to notify the networking core that room is available in its
queue again.

In the case where the receive handler does not have this capability
(and its queue fills up) it returns -1 and the networking core does not
queue up the packet. This condition is indicated by a -1 return from
qemu_send_packet_async().

Currently, tap handles this condition simply by dropping the packet. It
should do its best to avoid getting into this situation by checking such
NIC's have room for a packet before copying the packet from the tap
interface.

tap_send() used to achieve this by only reading a single packet before
returning to the mainloop. That way, tap_can_send() is called before
reading each packet.

tap_send() was changed to completely drain the tap interface queue
without taking into account the situation where the NIC returns an
error and the packet is not queued. Let's start fixing this by
reverting to the previous behaviour of reading one packet at a time.

Reported-by: default avatarScott Tsai <scottt.tw@gmail.com>
Tested-by: default avatarSven Rudolph <Sven_Rudolph@drewag.de>
Signed-off-by: default avatarMark McLoughlin <markmc@redhat.com>
Signed-off-by: default avatarAurelien Jarno <aurelien@aurel32.net>
      3e01c7b9
  17. Oct 11, 2009
  19. Oct 04, 2009
    • Jim Paris's avatar
      usb-linux.c: fix buffer overflow · babd03fd
      Jim Paris authored 
      In usb-linux.c:usb_host_handle_control, we pass a 1024-byte buffer and
length to the kernel.  However, the length was provided by the caller
of dev->handle_packet, and is not checked, so the kernel might provide
too much data and overflow our buffer.

For example, hw/usb-uhci.c could set the length to 2047.
hw/usb-ohci.c looks like it might go up to 4096 or 8192.

This causes a qemu crash, as reported here:
  http://www.mail-archive.com/kvm@vger.kernel.org/msg18447.html



This patch increases the usb-linux.c buffer size to 2048 to fix the
specific device reported, and adds a check to avoid the overflow in
any case.

Signed-off-by: default avatarJim Paris <jim@jtan.com>
Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      babd03fd
  21. Sep 25, 2009
  23. Sep 24, 2009
  25. Sep 23, 2009
  27. Sep 18, 2009
  29. Sep 16, 2009
  31. Sep 15, 2009
  33. Aug 28, 2009