Skip to content
Snippets Groups Projects
  1. Jul 29, 2022
  2. Jul 18, 2022
  3. Jul 14, 2022
  4. Jul 13, 2022
  5. Jul 05, 2022
  6. Jun 28, 2022
  7. Jun 27, 2022
    • David Hildenbrand's avatar
      MAINTAINERS: Collect memory device files in "Memory devices" · 2fcd005f
      David Hildenbrand authored
      
      Xiao Guangrong doesn't have enough time to actively review or contribute
      to our NVDIMM implementation. Let's dissolve the "NVDIMM" section, moving
      relevant ACPI parts to "ACPI/SMBIOS" and moving memory device stuff into a
      new "Memory devices" section. Make that new section cover other memory
      device stuff as well.
      
      We can now drop the "hw/mem/*" rule from "ACPI/SMBIOS". Note that
      hw/acpi/nvdimm.c is already covered by "ACPI/SMBIOS".
      
      The following files in hw/mem don't fall into the TYPE_MEMPORY_DEVICE
      category:
      * hw/mem/cxl_type3.c is CXL specific and belongs to "Compute Express Link"
      * hw/mem/sparse-mem.c is already covered by "Device Fuzzing"
      * hw/mem/npcm7xx_mc.c is already covered by "Nuvoton NPCM7xx"
      
      Thanks Xiao for your work on NVDIMM!
      
      Cc: Ben Widawsky <ben.widawsky@intel.com>
      Cc: Jonathan Cameron <jonathan.cameron@huawei.com>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Cc: Igor Mammedov <imammedo@redhat.com>
      Cc: Ani Sinha <ani@anisinha.ca>
      Cc: Xiao Guangrong <xiaoguangrong.eric@gmail.com>
      Cc: "Philippe Mathieu-Daudé" <f4bug@amsat.org>
      Cc: Richard Henderson <richard.henderson@linaro.org>
      Cc: Peter Maydell <peter.maydell@linaro.org>
      Cc: Julia Suvorova <jusual@redhat.com>
      Signed-off-by: default avatarDavid Hildenbrand <david@redhat.com>
      Message-Id: <20220617123151.103033-1-david@redhat.com>
      Reviewed-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      2fcd005f
  8. Jun 24, 2022
  9. Jun 15, 2022
  10. Jun 14, 2022
  11. Jun 11, 2022
  12. Jun 09, 2022
  13. Jun 06, 2022
  14. Jun 03, 2022
  15. May 30, 2022
  16. May 13, 2022
  17. May 12, 2022
    • Eric Blake's avatar
      nbd/server: Allow MULTI_CONN for shared writable exports · 58a6fdcc
      Eric Blake authored
      
      According to the NBD spec, a server that advertises
      NBD_FLAG_CAN_MULTI_CONN promises that multiple client connections will
      not see any cache inconsistencies: when properly separated by a single
      flush, actions performed by one client will be visible to another
      client, regardless of which client did the flush.
      
      We always satisfy these conditions in qemu - even when we support
      multiple clients, ALL clients go through a single point of reference
      into the block layer, with no local caching.  The effect of one client
      is instantly visible to the next client.  Even if our backend were a
      network device, we argue that any multi-path caching effects that
      would cause inconsistencies in back-to-back actions not seeing the
      effect of previous actions would be a bug in that backend, and not the
      fault of caching in qemu.  As such, it is safe to unconditionally
      advertise CAN_MULTI_CONN for any qemu NBD server situation that
      supports parallel clients.
      
      Note, however, that we don't want to advertise CAN_MULTI_CONN when we
      know that a second client cannot connect (for historical reasons,
      qemu-nbd defaults to a single connection while nbd-server-add and QMP
      commands default to unlimited connections; but we already have
      existing means to let either style of NBD server creation alter those
      defaults).  This is visible by no longer advertising MULTI_CONN for
      'qemu-nbd -r' without -e, as in the iotest nbd-qemu-allocation.
      
      The harder part of this patch is setting up an iotest to demonstrate
      behavior of multiple NBD clients to a single server.  It might be
      possible with parallel qemu-io processes, but I found it easier to do
      in python with the help of libnbd, and help from Nir and Vladimir in
      writing the test.
      
      Signed-off-by: default avatarEric Blake <eblake@redhat.com>
      Suggested-by: default avatarNir Soffer <nsoffer@redhat.com>
      Suggested-by: default avatarVladimir Sementsov-Ogievskiy <v.sementsov-og@mail.ru>
      Message-Id: <20220512004924.417153-3-eblake@redhat.com>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      58a6fdcc
  18. May 09, 2022
  19. May 08, 2022
  20. May 04, 2022
  21. Apr 21, 2022
Loading