1. 23 4月, 2013 1 次提交
  2. 22 4月, 2013 5 次提交
  3. 15 4月, 2013 2 次提交
  4. 06 4月, 2013 4 次提交
  5. 28 3月, 2013 1 次提交
  6. 23 3月, 2013 6 次提交
  7. 19 3月, 2013 1 次提交
  8. 15 3月, 2013 4 次提交
  9. 04 3月, 2013 1 次提交
  10. 23 2月, 2013 4 次提交
  11. 01 2月, 2013 1 次提交
  12. 26 1月, 2013 4 次提交
  13. 15 1月, 2013 2 次提交
    • P
      block: clear dirty bitmap when discarding · df702c9b
      Paolo Bonzini 提交于
      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: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      df702c9b
    • P
      block: fix initialization in bdrv_io_limits_enable() · 029d091e
      Peter Lieven 提交于
      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: NPeter Lieven <pl@kamp.de>
      Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      029d091e
  14. 14 1月, 2013 2 次提交
  15. 11 1月, 2013 1 次提交
  16. 19 12月, 2012 1 次提交