1. 17 11月, 2017 1 次提交
    • K
      block: Deprecate bdrv_set_read_only() and users · 398e6ad0
      Kevin Wolf 提交于
      bdrv_set_read_only() is used by some block drivers to override the
      read-only option given by the user. This is not how read-only images
      generally work in QEMU: Instead of second guessing what the user really
      meant (which currently includes making an image read-only even if the
      user didn't only use the default, but explicitly said read-only=off), we
      should error out if we can't provide what the user requested.
      
      This adds deprecation warnings to all callers of bdrv_set_read_only() so
      that the behaviour can be corrected after the usual deprecation period.
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      398e6ad0
  2. 25 4月, 2017 2 次提交
    • J
      block: do not set BDS read_only if copy_on_read enabled · e2b8247a
      Jeff Cody 提交于
      A few block drivers will set the BDS read_only flag from their
      .bdrv_open() function.  This means the bs->read_only flag could
      be set after we enable copy_on_read, as the BDRV_O_COPY_ON_READ
      flag check occurs prior to the call to bdrv->bdrv_open().
      
      This adds an error return to bdrv_set_read_only(), and an error will be
      return if we try to set the BDS to read_only while copy_on_read is
      enabled.
      
      This patch also changes the behavior of vvfat.  Before, vvfat could
      override the drive 'readonly' flag with its own, internal 'rw' flag.
      
      For instance, this -drive parameter would result in a writable image:
      
      "-drive format=vvfat,dir=/tmp/vvfat,rw,if=virtio,readonly=on"
      
      This is not correct.  Now, attempting to use the above -drive parameter
      will result in an error (i.e., 'rw' is incompatible with 'readonly=on').
      Signed-off-by: NJeff Cody <jcody@redhat.com>
      Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
      Reviewed-by: NJohn Snow <jsnow@redhat.com>
      Message-id: 0c5b4c1cc2c651471b131f21376dfd5ea24d2196.1491597120.git.jcody@redhat.com
      e2b8247a
    • J
      block: add bdrv_set_read_only() helper function · fe5241bf
      Jeff Cody 提交于
      We have a helper wrapper for checking for the BDS read_only flag,
      add a helper wrapper to set the read_only flag as well.
      Reviewed-by: NStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: NJeff Cody <jcody@redhat.com>
      Reviewed-by: NJohn Snow <jsnow@redhat.com>
      Message-id: 9b18972d05f5fa2ac16c014f0af98d680553048d.1491597120.git.jcody@redhat.com
      fe5241bf
  3. 01 3月, 2017 1 次提交
  4. 24 2月, 2017 1 次提交
    • K
      block: Attach bs->file only during .bdrv_open() · 4e4bf5c4
      Kevin Wolf 提交于
      The way that attaching bs->file worked was a bit unusual in that it was
      the only child that would be attached to a node which is not opened yet.
      Because of this, the block layer couldn't know yet which permissions the
      driver would eventually need.
      
      This patch moves the point where bs->file is attached to the beginning
      of the individual .bdrv_open() implementations, so drivers already know
      what they are going to do with the child. This is also more consistent
      with how driver-specific children work.
      
      For a moment, bdrv_open() gets its own BdrvChild to perform image
      probing, but instead of directly assigning this BdrvChild to the BDS, it
      becomes a temporary one and the node name is passed as an option to the
      drivers, so that they can simply use bdrv_open_child() to create another
      reference for their own use.
      
      This duplicated child for (the not opened yet) bs is not the final
      state, a follow-up patch will change the image probing code to use a
      BlockBackend, which is completely independent of bs.
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      Reviewed-by: NMax Reitz <mreitz@redhat.com>
      4e4bf5c4
  5. 05 7月, 2016 4 次提交
  6. 19 5月, 2016 1 次提交
  7. 12 5月, 2016 1 次提交
  8. 23 3月, 2016 1 次提交
    • M
      include/qemu/osdep.h: Don't include qapi/error.h · da34e65c
      Markus Armbruster 提交于
      Commit 57cb38b3 included qapi/error.h into qemu/osdep.h to get the
      Error typedef.  Since then, we've moved to include qemu/osdep.h
      everywhere.  Its file comment explains: "To avoid getting into
      possible circular include dependencies, this file should not include
      any other QEMU headers, with the exceptions of config-host.h,
      compiler.h, os-posix.h and os-win32.h, all of which are doing a
      similar job to this file and are under similar constraints."
      qapi/error.h doesn't do a similar job, and it doesn't adhere to
      similar constraints: it includes qapi-types.h.  That's in excess of
      100KiB of crap most .c files don't actually need.
      
      Add the typedef to qemu/typedefs.h, and include that instead of
      qapi/error.h.  Include qapi/error.h in .c files that need it and don't
      get it now.  Include qapi-types.h in qom/object.h for uint16List.
      
      Update scripts/clean-includes accordingly.  Update it further to match
      reality: replace config.h by config-target.h, add sysemu/os-posix.h,
      sysemu/os-win32.h.  Update the list of includes in the qemu/osdep.h
      comment quoted above similarly.
      
      This reduces the number of objects depending on qapi/error.h from "all
      of them" to less than a third.  Unfortunately, the number depending on
      qapi-types.h shrinks only a little.  More work is needed for that one.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      [Fix compilation without the spice devel packages. - Paolo]
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      da34e65c
  9. 20 1月, 2016 1 次提交
  10. 16 10月, 2015 1 次提交
  11. 15 8月, 2014 1 次提交
  12. 23 4月, 2014 1 次提交
  13. 01 4月, 2014 5 次提交
  14. 12 9月, 2013 1 次提交
  15. 15 3月, 2013 1 次提交
  16. 01 2月, 2013 1 次提交
  17. 19 12月, 2012 2 次提交
  18. 04 11月, 2011 2 次提交
  19. 21 10月, 2011 2 次提交
    • P
      block: take lock around bdrv_read implementations · 2914caa0
      Paolo Bonzini 提交于
      This does the first part of the conversion to coroutines, by
      wrapping bdrv_read implementations to take the mutex.
      
      Drivers that implement bdrv_read rather than bdrv_co_readv can
      then benefit from asynchronous operation (at least if the underlying
      protocol supports it, which is not the case for raw-win32), even
      though they still operate with a bounce buffer.
      
      raw-win32 does not need the lock, because it cannot yield.
      nbd also doesn't probably, but better be safe.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      2914caa0
    • P
      block: add a CoMutex to synchronous read drivers · 848c66e8
      Paolo Bonzini 提交于
      The big conversion of bdrv_read/write to coroutines caused the two
      homonymous callbacks in BlockDriver to become reentrant.  It goes
      like this:
      
      1) bdrv_read is now called in a coroutine, and calls bdrv_read or
      bdrv_pread.
      
      2) the nested bdrv_read goes through the fast path in bdrv_rw_co_entry;
      
      3) in the common case when the protocol is file, bdrv_co_do_readv calls
      bdrv_co_readv_em (and from here goes to bdrv_co_io_em), which yields
      until the AIO operation is complete;
      
      4) if bdrv_read had been called from a bottom half, the main loop
      is free to iterate again: a device model or another bottom half
      can then come and call bdrv_read again.
      
      This applies to all four of read/write/flush/discard.  It would also
      apply to is_allocated, but it is not used from within coroutines:
      besides qemu-img.c and qemu-io.c, which operate synchronously, the
      only user is the monitor.  Copy-on-read will introduce a use in the
      block layer, and will require converting it.
      
      The solution is "simply" to convert all drivers to coroutines!  We
      just need to add a CoMutex that is taken around affected operations.
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      848c66e8
  20. 21 8月, 2011 1 次提交
  21. 17 5月, 2010 2 次提交
  22. 03 5月, 2010 1 次提交
    • K
      block: Open the underlying image file in generic code · 66f82cee
      Kevin Wolf 提交于
      Format drivers shouldn't need to bother with things like file names, but rather
      just get an open BlockDriverState for the underlying protocol. This patch
      introduces this behaviour for bdrv_open implementation. For protocols which
      need to access the filename to open their file/device/connection/... a new
      callback bdrv_file_open is introduced which doesn't get an underlying file
      opened.
      
      For now, also some of the more obscure formats use bdrv_file_open because they
      open() the file themselves instead of using the block.c functions. They need to
      be fixed in later patches.
      Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      66f82cee
  23. 15 5月, 2009 2 次提交
  24. 08 3月, 2009 1 次提交
  25. 06 2月, 2009 1 次提交
  26. 13 12月, 2008 1 次提交
  27. 11 11月, 2007 1 次提交