Skip to content
Snippets Groups Projects
  1. Oct 17, 2023
  2. Oct 16, 2023
  3. Oct 12, 2023
  4. Oct 11, 2023
  5. Oct 08, 2023
  6. Oct 07, 2023
  7. Oct 05, 2023
    • Eric Blake's avatar
      nbd/server: Add FLAG_PAYLOAD support to CMD_BLOCK_STATUS · 2dcbb11b
      Eric Blake authored
      
      Allow a client to request a subset of negotiated meta contexts.  For
      example, a client may ask to use a single connection to learn about
      both block status and dirty bitmaps, but where the dirty bitmap
      queries only need to be performed on a subset of the disk; forcing the
      server to compute that information on block status queries in the rest
      of the disk is wasted effort (both at the server, and on the amount of
      traffic sent over the wire to be parsed and ignored by the client).
      
      Qemu as an NBD client never requests to use more than one meta
      context, so it has no need to use block status payloads.  Testing this
      instead requires support from libnbd, which CAN access multiple meta
      contexts in parallel from a single NBD connection; an interop test
      submitted to the libnbd project at the same time as this patch
      demonstrates the feature working, as well as testing some corner cases
      (for example, when the payload length is longer than the export
      length), although other corner cases (like passing the same id
      duplicated) requires a protocol fuzzer because libnbd is not wired up
      to break the protocol that badly.
      
      This also includes tweaks to 'qemu-nbd --list' to show when a server
      is advertising the capability, and to the testsuite to reflect the
      addition to that output.
      
      Of note: qemu will always advertise the new feature bit during
      NBD_OPT_INFO if extended headers have alreay been negotiated
      (regardless of whether any NBD_OPT_SET_META_CONTEXT negotiation has
      occurred); but for NBD_OPT_GO, qemu only advertises the feature if
      block status is also enabled (that is, if the client does not
      negotiate any contexts, then NBD_CMD_BLOCK_STATUS cannot be used, so
      the feature is not advertised).
      
      Signed-off-by: default avatarEric Blake <eblake@redhat.com>
      Message-ID: <20230925192229.3186470-26-eblake@redhat.com>
      [eblake: fix logic to reject unnegotiated contexts]
      Signed-off-by: default avatarEric Blake <eblake@redhat.com>
      2dcbb11b
    • Eric Blake's avatar
      nbd/server: Enable initial support for extended headers · 9c1d2614
      Eric Blake authored
      
      Time to start supporting clients that request extended headers.  Now
      we can finally reach the code added across several previous patches.
      
      Even though the NBD spec has been altered to allow us to accept
      NBD_CMD_READ larger than the max payload size (provided our response
      is a hole or broken up over more than one data chunk), we are not
      planning to take advantage of that, and continue to cap NBD_CMD_READ
      to 32M regardless of header size.
      
      For NBD_CMD_WRITE_ZEROES and NBD_CMD_TRIM, the block layer already
      supports 64-bit operations without any effort on our part.  For
      NBD_CMD_BLOCK_STATUS, the client's length is a hint, and the previous
      patch took care of implementing the required
      NBD_REPLY_TYPE_BLOCK_STATUS_EXT.
      
      We do not yet support clients that want to do request payload
      filtering of NBD_CMD_BLOCK_STATUS; that will be added in later
      patches, but is not essential for qemu as a client since qemu only
      requests the single context base:allocation.
      
      Signed-off-by: default avatarEric Blake <eblake@redhat.com>
      Reviewed-by: default avatarVladimir Sementsov-Ogievskiy <vsementsov@yandex-team.ru>
      Message-ID: <20230925192229.3186470-19-eblake@redhat.com>
      9c1d2614
  8. Oct 04, 2023
  9. Oct 03, 2023
    • Paolo Bonzini's avatar
      audio: remove QEMU_AUDIO_* and -audio-help support · 69a80279
      Paolo Bonzini authored
      
      These have been deprecated for a long time, and the introduction of
      -audio in 7.1.0 has cemented the new way of specifying an audio backend's
      parameters.  However, there is still a need for simple configuration
      of the audio backend in the desktop case; therefore, if no audiodev is
      passed to audio_init(), go through a bunch of simple Audiodev* structures
      and pick the first that can be initialized successfully.
      
      The only QEMU_AUDIO_* option that is left in, waiting for a better idea,
      is QEMU_AUDIO_DRV=none which is used by qtest.
      
      Remove all the parsing code, including the concept of "can_be_default"
      audio drivers: now that audio_prio_list[] is only used in a single place,
      wav can be excluded directly in that function.
      
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      69a80279
    • Paolo Bonzini's avatar
      ui/vnc: Require audiodev= to enable audio · 9e58d7a7
      Paolo Bonzini authored
      
      If there is no audiodev do not send the audio ack in response to
      VNC_ENCODING_AUDIO, so that clients aren't told audio exists, and
      immediately drop the client if they try to send any audio control messages
      when audio is not advertised.
      
      Reviewed-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      9e58d7a7
  10. Sep 25, 2023
  11. Sep 22, 2023
  12. Sep 21, 2023
  13. Sep 19, 2023
  14. Sep 12, 2023
  15. Sep 11, 2023
    • Avihai Horon's avatar
      vfio/migration: Add P2P support for VFIO migration · 94f775e4
      Avihai Horon authored
      
      VFIO migration uAPI defines an optional intermediate P2P quiescent
      state. While in the P2P quiescent state, P2P DMA transactions cannot be
      initiated by the device, but the device can respond to incoming ones.
      Additionally, all outstanding P2P transactions are guaranteed to have
      been completed by the time the device enters this state.
      
      The purpose of this state is to support migration of multiple devices
      that might do P2P transactions between themselves.
      
      Add support for P2P migration by transitioning all the devices to the
      P2P quiescent state before stopping or starting the devices. Use the new
      VMChangeStateHandler prepare_cb to achieve that behavior.
      
      This will allow migration of multiple VFIO devices if all of them
      support P2P migration.
      
      Signed-off-by: default avatarAvihai Horon <avihaih@nvidia.com>
      Tested-by: default avatarYangHang Liu <yanghliu@redhat.com>
      Reviewed-by: default avatarCédric Le Goater <clg@redhat.com>
      Signed-off-by: default avatarCédric Le Goater <clg@redhat.com>
      94f775e4
  16. Sep 08, 2023
Loading