Skip to content
Snippets Groups Projects
  1. Sep 20, 2023
    • Kevin Wolf's avatar
      block-coroutine-wrapper: Add no_co_wrapper_bdrv_wrlock functions · de903298
      Kevin Wolf authored
      
      Add a new wrapper type for GRAPH_WRLOCK functions that should be called
      from coroutine context.
      
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      Reviewed-by: default avatarEmanuele Giuseppe Esposito <eesposit@redhat.com>
      Reviewed-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Message-ID: <20230911094620.45040-7-kwolf@redhat.com>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      de903298
    • Kevin Wolf's avatar
      block: Introduce bdrv_schedule_unref() · ac2ae233
      Kevin Wolf authored
      
      bdrv_unref() is called by a lot of places that need to hold the graph
      lock (it naturally happens in the context of operations that change the
      graph). However, bdrv_unref() takes the graph writer lock internally, so
      it can't actually be called while already holding a graph lock without
      causing a deadlock.
      
      bdrv_unref() also can't just become GRAPH_WRLOCK because it drains the
      node before closing it, and draining requires that the graph is
      unlocked.
      
      The solution is to defer deleting the node until we don't hold the lock
      any more and draining is possible again.
      
      Note that keeping images open for longer than necessary can create
      problems, too: You can't open an image again before it is really closed
      (if image locking didn't prevent it, it would cause corruption).
      Reopening an image immediately happens at least during bdrv_open() and
      bdrv_co_create().
      
      In order to solve this problem, make sure to run the deferred unref in
      bdrv_graph_wrunlock(), i.e. the first possible place where we can drain
      again. This is also why bdrv_schedule_unref() is marked GRAPH_WRLOCK.
      
      The output of iotest 051 is updated because the additional polling
      changes the order of HMP output, resulting in a new "(qemu)" prompt in
      the test output that was previously on a separate line and filtered out.
      
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      Message-ID: <20230911094620.45040-6-kwolf@redhat.com>
      Reviewed-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: default avatarKevin Wolf <kwolf@redhat.com>
      ac2ae233
  2. Sep 19, 2023
    • hongmianquan's avatar
      memory: avoid updating ioeventfds for some address_space · 544cff46
      hongmianquan authored
      
      When updating ioeventfds, we need to iterate all address spaces,
      but some address spaces do not register eventfd_add|del call when
      memory_listener_register() and they do nothing when updating ioeventfds.
      So we can skip these AS in address_space_update_ioeventfds().
      
      The overhead of memory_region_transaction_commit() can be significantly
      reduced. For example, a VM with 8 vhost net devices and each one has
      64 vectors, can reduce the time spent on memory_region_transaction_commit by 20%.
      
      Message-ID: <20230830032906.12488-1-hongmianquan@bytedance.com>
      Reviewed-by: default avatarPeter Xu <peterx@redhat.com>
      Signed-off-by: default avatarhongmianquan <hongmianquan@bytedance.com>
      Signed-off-by: default avatarDavid Hildenbrand <david@redhat.com>
      544cff46
    • David Hildenbrand's avatar
      softmmu/physmem: Distinguish between file access mode and mmap protection · 5c52a219
      David Hildenbrand authored
      
      There is a difference between how we open a file and how we mmap it,
      and we want to support writable private mappings of readonly files. Let's
      define RAM_READONLY and RAM_READONLY_FD flags, to replace the single
      "readonly" parameter for file-related functions.
      
      In memory_region_init_ram_from_fd() and memory_region_init_ram_from_file(),
      initialize mr->readonly based on the new RAM_READONLY flag.
      
      While at it, add some RAM_* flags we missed to add to the list of accepted
      flags in the documentation of some functions.
      
      No change in functionality intended. We'll make use of both flags next
      and start setting them independently for memory-backend-file.
      
      Message-ID: <20230906120503.359863-3-david@redhat.com>
      Acked-by: default avatarPeter Xu <peterx@redhat.com>
      Signed-off-by: default avatarDavid Hildenbrand <david@redhat.com>
      5c52a219
    • David Hildenbrand's avatar
      nvdimm: Reject writing label data to ROM instead of crashing QEMU · 3a125839
      David Hildenbrand authored
      
      Currently, when using a true R/O NVDIMM (ROM memory backend) with a label
      area, the VM can easily crash QEMU by trying to write to the label area,
      because the ROM memory is mmap'ed without PROT_WRITE.
      
          [root@vm-0 ~]# ndctl disable-region region0
          disabled 1 region
          [root@vm-0 ~]# ndctl zero-labels nmem0
          -> QEMU segfaults
      
      Let's remember whether we have a ROM memory backend and properly
      reject the write request:
      
          [root@vm-0 ~]# ndctl disable-region region0
          disabled 1 region
          [root@vm-0 ~]# ndctl zero-labels nmem0
          zeroed 0 nmem
      
      In comparison, on a system with a R/W NVDIMM:
      
          [root@vm-0 ~]# ndctl disable-region region0
          disabled 1 region
          [root@vm-0 ~]# ndctl zero-labels nmem0
          zeroed 1 nmem
      
      For ACPI, just return "unsupported", like if no label exists. For spapr,
      return "H_P2", similar to when no label area exists.
      
      Could we rely on the "unarmed" property? Maybe, but it looks cleaner to
      only disallow what certainly cannot work.
      
      After all "unarmed=on" primarily means: cannot accept persistent writes. In
      theory, there might be setups where devices with "unarmed=on" set could
      be used to host non-persistent data (temporary files, system RAM, ...); for
      example, in Linux, admins can overwrite the "readonly" setting and still
      write to the device -- which will work as long as we're not using ROM.
      Allowing writing label data in such configurations can make sense.
      
      Message-ID: <20230906120503.359863-2-david@redhat.com>
      Fixes: dbd730e8 ("nvdimm: check -object memory-backend-file, readonly=on option")
      Reviewed-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      Signed-off-by: default avatarDavid Hildenbrand <david@redhat.com>
      3a125839
  3. Sep 18, 2023
  4. Sep 16, 2023
  5. Sep 15, 2023
  6. Sep 12, 2023
  7. Sep 11, 2023
  8. Sep 08, 2023
Loading