1. 13 3月, 2017 7 次提交
    • K
      commit: Implement bdrv_commit_top.bdrv_co_get_block_status · 91965658
      Kevin Wolf 提交于
      In some cases, bdrv_co_get_block_status() is called recursively for the
      whole backing chain. The automatically inserted bdrv_commit_top filter
      driver must not stop the recursion, so implement a callback that simply
      forwards the request to bs->backing.
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      91965658
    • K
      block: Request block status from *file for BDRV_BLOCK_RAW · b64aa441
      Kevin Wolf 提交于
      This fixes bdrv_co_get_block_status() for the bdrv_mirror_top block
      driver, which must fall through to bs->backing instead of bs->file.
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      b64aa441
    • E
      vvfat: React to bdrv_is_allocated() errors · 6f712ee0
      Eric Blake 提交于
      If bdrv_is_allocated() fails, we should react to that failure.
      For 2 of the 3 callers, reporting the error was easy.  But in
      cluster_was_modified() and its lone caller
      get_cluster_count_for_direntry(), it's rather invasive to update
      the logic to pass the error back; so there, I went with merely
      documenting the issue by changing the return type to bool (in
      all likelihood, treating the cluster as modified will then
      trigger a read which will also fail, and eventually get to an
      error - but given the appalling number of abort() calls in this
      code, I'm not making it any worse).
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      6f712ee0
    • E
      backup: React to bdrv_is_allocated() errors · 666a9543
      Eric Blake 提交于
      If bdrv_is_allocated() fails, we should immediately do the backup
      error action, rather than attempting backup_do_cow() (although
      that will likely fail too).
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      666a9543
    • E
      block: Drop unmaintained 'archipelago' driver · e32ccbc6
      Eric Blake 提交于
      The driver has failed to build since commit da34e65c, in qemu 2.6,
      due to a missing include of qapi/error.h for error_setg().
      Since no one has complained in three releases, it is easier to
      remove the dead code than to keep it around, especially since it
      is not being built by default and therefore prone to bitrot.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NMax Reitz <mreitz@redhat.com>
      Reviewed-by: NFam Zheng <famz@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      e32ccbc6
    • F
      file-posix: Consider max_segments for BlockLimits.max_transfer · 9103f1ce
      Fam Zheng 提交于
      BlockLimits.max_transfer can be too high without this fix, guest will
      encounter I/O error or even get paused with werror=stop or rerror=stop. The
      cause is explained below.
      
      Linux has a separate limit, /sys/block/.../queue/max_segments, which in
      the worst case can be more restrictive than the BLKSECTGET which we
      already consider (note that they are two different things). So, the
      failure scenario before this patch is:
      
      1) host device has max_sectors_kb = 4096 and max_segments = 64;
      2) guest learns max_sectors_kb limit from QEMU, but doesn't know
         max_segments;
      3) guest issues e.g. a 512KB request thinking it's okay, but actually
         it's not, because it will be passed through to host device as an
         SG_IO req that has niov > 64;
      4) host kernel doesn't like the segmenting of the request, and returns
         -EINVAL;
      
      This patch checks the max_segments sysfs entry for the host device and
      calculates a "conservative" bytes limit using the page size, which is
      then merged into the existing max_transfer limit. Guest will discover
      this from the usual virtual block device interfaces. (In the case of
      scsi-generic, it will be done in the INQUIRY reply interception in
      device model.)
      
      The other possibility is to actually propagate it as a separate limit,
      but it's not better. On the one hand, there is a big complication: the
      limit is per-LUN in QEMU PoV (because we can attach LUNs from different
      host HBAs to the same virtio-scsi bus), but the channel to communicate
      it in a per-LUN manner is missing down the stack; on the other hand,
      two limits versus one doesn't change much about the valid size of I/O
      (because guest has no control over host segmenting).
      
      Also, the idea to fall back to bounce buffering in QEMU, upon -EINVAL,
      was explored. Unfortunately there is no neat way to ensure the bounce
      buffer is less segmented (in terms of DMA addr) than the guest buffer.
      
      Practically, this bug is not very common. It is only reported on a
      Emulex (lpfc), so it's okay to get it fixed in the easier way.
      Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NFam Zheng <famz@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      9103f1ce
    • V
      backup: allow target without .bdrv_get_info · a410a7f1
      Vladimir Sementsov-Ogievskiy 提交于
      Currently backup to nbd target is broken, as nbd doesn't have
      .bdrv_get_info realization.
      Signed-off-by: NVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      a410a7f1
  2. 07 3月, 2017 21 次提交
  3. 05 3月, 2017 1 次提交
  4. 03 3月, 2017 1 次提交
  5. 02 3月, 2017 1 次提交
  6. 01 3月, 2017 9 次提交