1. 15 Mar, 2013 4 commits
  2. 04 Mar, 2013 1 commit
  3. 22 Feb, 2013 4 commits
  4. 01 Feb, 2013 1 commit
  5. 25 Jan, 2013 4 commits
  6. 15 Jan, 2013 2 commits
    • Paolo Bonzini's avatar
      block: clear dirty bitmap when discarding · df702c9b
      Paolo Bonzini authored
      
      
      Note that resetting bits in the dirty bitmap is done _before_ actually
      processing the request.  Writes, instead, set bits after the request
      is completed.
      
      This way, when there are concurrent write and discard requests, the
      outcome will always be that the blocks are marked dirty.  This scenario
      should never happen, but it is safer to do it this way.
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      df702c9b
    • Peter Lieven's avatar
      block: fix initialization in bdrv_io_limits_enable() · 029d091e
      Peter Lieven authored
      
      
      bdrv_io_limits_enable() starts a new slice, but does not set io_base
      correctly for that slice.
      
      Here is how io_base is used:
      
          bytes_base  = bs->nr_bytes[is_write] - bs->io_base.bytes[is_write];
          bytes_res   = (unsigned) nb_sectors * BDRV_SECTOR_SIZE;
      
          if (bytes_base + bytes_res <= bytes_limit) {
              /* no wait */
          } else {
              /* operation needs to be throttled */
          }
      
      As a result, any I/O operations that are triggered between now and
      bs->slice_end are incorrectly limited.  If 10 MB of data has been
      written since the VM was started, QEMU thinks that 10 MB of data has
      been written in this slice. This leads to a I/O lockup in the guest.
      
      We fix this by delaying the start of a new slice to the next
      call of bdrv_exceed_io_limits().
      Signed-off-by: default avatarPeter Lieven <pl@kamp.de>
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      029d091e
  7. 14 Jan, 2013 2 commits
  8. 11 Jan, 2013 1 commit
  9. 19 Dec, 2012 5 commits
  10. 12 Dec, 2012 1 commit
    • Kevin Wolf's avatar
      qemu-io: Add AIO debugging commands · 41c695c7
      Kevin Wolf authored
      
      
      This makes the blkdebug suspend/resume functionality available in
      qemu-io. Use it like this:
      
        $ ./qemu-io blkdebug::/tmp/test.qcow2
        qemu-io> break write_aio req_a
        qemu-io> aio_write 0 4k
        qemu-io> blkdebug: Suspended request 'req_a'
        qemu-io> resume req_a
        blkdebug: Resuming request 'req_a'
        qemu-io> wrote 4096/4096 bytes at offset 0
        4 KiB, 1 ops; 0:00:30.71 (133.359788 bytes/sec and 0.0326 ops/sec)
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      41c695c7
  11. 11 Dec, 2012 5 commits
  12. 24 Nov, 2012 1 commit
  13. 14 Nov, 2012 2 commits
    • Stefan Hajnoczi's avatar
      aio: rename AIOPool to AIOCBInfo · d7331bed
      Stefan Hajnoczi authored
      
      
      Now that AIOPool no longer keeps a freelist, it isn't really a "pool"
      anymore.  Rename it to AIOCBInfo and make it const since it no longer
      needs to be modified.
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      d7331bed
    • Stefan Hajnoczi's avatar
      aio: use g_slice_alloc() for AIOCB pooling · d37c975f
      Stefan Hajnoczi authored
      
      
      AIO control blocks are frequently acquired and released because each aio
      request involves at least one AIOCB.  Therefore, we pool them to avoid
      heap allocation overhead.
      
      The problem with the freelist approach in AIOPool is thread-safety.  If
      we want BlockDriverStates to associate with AioContexts that execute in
      multiple threads, then a global freelist becomes a problem.
      
      This patch drops the freelist and instead uses g_slice_alloc() which is
      tuned for per-thread fixed-size object pools.  qemu_aio_get() and
      qemu_aio_release() are now thread-safe.
      
      Note that the change from g_malloc0() to g_slice_alloc() should be safe
      since the freelist reuse case doesn't zero the AIOCB either.
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      d37c975f
  14. 24 Oct, 2012 7 commits