1. 09 Apr, 2018 1 commit
    • Eric Blake's avatar
      dump: Fix build with newer gcc · 84c868f6
      Eric Blake authored
      gcc 8 on rawhide is picky enough to complain:
      
      /home/dummy/qemu/dump.c: In function 'create_header32':
      /home/dummy/qemu/dump.c:817:5: error: 'strncpy' output truncated before terminating nul copying 8 bytes from a string of the same length [-Werror=stringop-truncation]
           strncpy(dh->signature, KDUMP_SIGNATURE, strlen(KDUMP_SIGNATURE));
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      But we already have SIG_LEN defined as the right length without needing
      to do a strlen(), and memcpy() is better than strncpy() when we know
      we do not want a trailing NUL byte.
      Signed-off-by: 's avatarEric Blake <eblake@redhat.com>
      Signed-off-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
      84c868f6
  2. 21 Mar, 2018 1 commit
    • Yasmin Beatriz's avatar
      dump.c: allow fd_write_vmcore to return errno on failure · 0c33659d
      Yasmin Beatriz authored
      fd_write_vmcore can fail to execute for a lot of reasons that can be
      retrieved by errno, but it only returns -1. This makes difficult for
      the caller to know what happened and only a generic error message is
      propagated back to the user. This is an example using dump-guest-memory:
      
      (qemu) dump-guest-memory /home/yasmin/mnt/test.dump
      dump: failed to save memory
      
      All callers of fd_write_vmcore of dump.c does error handling via
      error_setg(), so at first it seems feasible to add the Error pointer as
      an argument of fd_write_vmcore. This proved to be more complex than it
      first looked. fd_write_vmcore is used by write_elf64_notes and
      write_elf32_notes as a WriteCoreDumpFunction prototype. WriteCoreDumpFunction
      is declared in include/qom/cpu.h and is used all around the code. This
      leaves us with few alternatives:
      
      - change the WriteCoreDumpFunction prototype to include an error pointer.
      This would require to change all functions that implements this prototype
      to also receive an Error pointer;
      
      - change both write_elf64_notes and write_elf32_notes to no use the
      WriteCoreDumpFunction. These functions use not only fd_write_vmcore
      but also buf_write_note, so this would require to change buf_write_note
      to handle an Error pointer. Considerable easier than the alternative
      above, but it's still a lot of code just for the benefit of the callers
      of fd_write_vmcore.
      
      This patch presents an easier solution that benefits all fd_write_vmcore
      callers:
      
      - instead of returning -1 on error, return -errno. All existing callers
      already checks for ret < 0 so there is no need to change the caller's
      logic too much. This also allows the retrieval of the errno.
      
      - all callers were updated to use error_setg_errno instead of just
      errno_setg. Now that fd_write_vmcore can return an errno, let's update
      all callers so they can benefit from a more detailed error message.
      
      This is the same dump-guest-memory example with this patch applied:
      
      (qemu) dump-guest-memory /home/yasmin/mnt/test.dump
      dump: failed to save memory: No space left on device
      (qemu)
      
      This example illustrates an error of fd_write_vmcore when called
      from write_data. All other callers will benefit from better
      error messages as well.
      
      Reported-by: yilzhang@redhat.com
      Cc: Jose Ricardo Ziviani <joserz@linux.vnet.ibm.com>
      Signed-off-by: 's avatarYasmin Beatriz <yasmins@linux.vnet.ibm.com>
      Signed-off-by: 's avatarDaniel Henrique Barboza <danielhb@linux.vnet.ibm.com>
      Message-Id: <20180212142506.28445-2-danielhb@linux.vnet.ibm.com>
      Reviewed-by: 's avatarEric Blake <eblake@redhat.com>
      Reviewed-by: 's avatarMarc-André Lureau <marcandre.lureau@redhat.com>
      Signed-off-by: 's avatarMarc-André Lureau <marcandre.lureau@redhat.com>
      0c33659d
  3. 19 Mar, 2018 1 commit
  4. 02 Mar, 2018 1 commit
    • Markus Armbruster's avatar
      qapi: Empty out qapi-schema.json · 112ed241
      Markus Armbruster authored
      The previous commit improved compile time by including less of the
      generated QAPI headers.  This is impossible for stuff defined directly
      in qapi-schema.json, because that ends up in headers that that pull in
      everything.
      
      Move everything but include directives from qapi-schema.json to new
      sub-module qapi/misc.json, then include just the "misc" shard where
      possible.
      
      It's possible everywhere, except:
      
      * monitor.c needs qmp-command.h to get qmp_init_marshal()
      
      * monitor.c, ui/vnc.c and the generated qapi-event-FOO.c need
        qapi-event.h to get enum QAPIEvent
      
      Perhaps we'll get rid of those some other day.
      
      Adding a type to qapi/migration.json now recompiles some 120 instead
      of 2300 out of 5100 objects.
      Signed-off-by: 's avatarMarkus Armbruster <armbru@redhat.com>
      Message-Id: <20180211093607.27351-25-armbru@redhat.com>
      [eblake: rebase to master]
      Signed-off-by: 's avatarEric Blake <eblake@redhat.com>
      112ed241
  5. 09 Feb, 2018 1 commit
  6. 02 Jan, 2018 1 commit
  7. 15 Oct, 2017 3 commits
  8. 19 Sep, 2017 1 commit
  9. 14 Sep, 2017 1 commit
  10. 30 Aug, 2017 1 commit
  11. 05 May, 2017 1 commit
    • Fam Zheng's avatar
      dump: Acquire BQL around vm_start() in dump thread · 6796b400
      Fam Zheng authored
      This fixes an assertion failure in the following backtrace:
      
          __GI___assert_fail
          memory_region_transaction_commit
          memory_region_add_eventfd
          virtio_pci_ioeventfd_assign
          virtio_bus_set_host_notifier
          virtio_blk_data_plane_start
          virtio_bus_start_ioeventfd
          virtio_vmstate_change
          vm_state_notify
          vm_prepare_start
          vm_start
          dump_cleanup
          dump_process
          dump_thread
          start_thread
          clone
      
      vm_start need BQL, acquire it if doing cleaning up from main thread.
      Signed-off-by: 's avatarFam Zheng <famz@redhat.com>
      Message-Id: <20170503072819.14462-1-famz@redhat.com>
      Signed-off-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
      6796b400
  12. 20 Jun, 2016 1 commit
  13. 22 Mar, 2016 1 commit
  14. 22 Feb, 2016 10 commits
  15. 04 Feb, 2016 1 commit
    • Peter Maydell's avatar
      all: Clean up includes · d38ea87a
      Peter Maydell authored
      Clean up includes so that osdep.h is included first and headers
      which it implies are not included manually.
      
      This commit was created with scripts/clean-includes.
      Signed-off-by: 's avatarPeter Maydell <peter.maydell@linaro.org>
      Message-id: 1454089805-5470-16-git-send-email-peter.maydell@linaro.org
      d38ea87a
  16. 15 Jan, 2016 2 commits
  17. 22 Jun, 2015 2 commits
  18. 02 Nov, 2014 1 commit
    • Gonglei's avatar
      dump: Fix dump-guest-memory termination and use-after-close · 08a655be
      Gonglei authored
      dump_iterate() dumps blocks in a loop.  Eventually, get_next_block()
      returns "no more".  We then call dump_completed().  But we neglect to
      break the loop!  Broken in commit 4c7e251a.
      
      Because of that, we dump the last block again.  This attempts to write
      to s->fd, which fails if we're lucky.  The error makes dump_iterate()
      return failure.  It's the only way it can ever return.
      
      Theoretical: if we're not so lucky, something else has opened something
      for writing and got the same fd.  dump_iterate() then keeps looping,
      messing up the something else's output, until a write fails, or the
      process mercifully terminates.
      
      The obvious fix is to restore the return lost in commit 4c7e251a.  But
      the root cause of the bug is needlessly opaque loop control.  Replace it
      by a clean do ... while loop.
      
      This makes the badly chosen return values of get_next_block() more
      visible.  Cleaning that up is outside the scope of this bug fix.
      Signed-off-by: 's avatarGonglei <arei.gonglei@huawei.com>
      Signed-off-by: 's avatarMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: 's avatarMichael Tokarev <mjt@tls.msk.ru>
      08a655be
  19. 23 Oct, 2014 2 commits
  20. 18 Aug, 2014 1 commit
  21. 16 Jun, 2014 1 commit
  22. 11 Jun, 2014 5 commits
    • Laszlo Ersek's avatar
      dump: simplify get_len_buf_out() · b87ef351
      Laszlo Ersek authored
      We can (and should) rely on the fact that s->flag_compress is exactly one
      of DUMP_DH_COMPRESSED_ZLIB, DUMP_DH_COMPRESSED_LZO, and
      DUMP_DH_COMPRESSED_SNAPPY.
      
      This is ensured by the QMP schema and dump_init() in combination.
      Suggested-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: 's avatarLaszlo Ersek <lersek@redhat.com>
      Reviewed-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: 's avatarLuiz Capitulino <lcapitulino@redhat.com>
      b87ef351
    • Laszlo Ersek's avatar
      dump: hoist lzo_init() from get_len_buf_out() to dump_init() · c998acb0
      Laszlo Ersek authored
      qmp_dump_guest_memory()
        dump_init()
          lzo_init() <---------+
        create_kdump_vmcore()  |
          write_dump_pages()   |
            get_len_buf_out()  |
              lzo_init() ------+
      
      This patch doesn't change the fact that lzo_init() is called for every
      LZO-compressed dump, but it makes get_len_buf_out() more focused (single
      responsibility).
      Suggested-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: 's avatarLaszlo Ersek <lersek@redhat.com>
      Reviewed-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: 's avatarLuiz Capitulino <lcapitulino@redhat.com>
      c998acb0
    • Laszlo Ersek's avatar
      dump: select header bitness based on ELF class, not ELF architecture · 24aeeace
      Laszlo Ersek authored
      The specific ELF architecture (d_machine) carries Too Much Information
      (TM) for deciding between create_header32() and create_header64(), use
      "d_class" instead (ELFCLASS32 vs. ELFCLASS64).
      
      This change adapts write_dump_header() to write_elf_loads(), dump_begin()
      etc. that also rely on the ELF class of the target for bitness selection.
      
      Considering the current targets that support dumping, cpu_get_dump_info()
      works as follows:
      - target-s390x/arch_dump.c: (EM_S390, ELFCLASS64) only
      - target-ppc/arch_dump.c (EM_PPC64, ELFCLASS64) only
      - target-i386/arch_dump.c: sets (EM_X86_64, ELFCLASS64) vs. (EM_386,
        ELFCLASS32) keying off the same Long Mode Active flag.
      
      Hence no observable change.
      Approximately-suggested-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: 's avatarLaszlo Ersek <lersek@redhat.com>
      Reviewed-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: 's avatarLuiz Capitulino <lcapitulino@redhat.com>
      24aeeace
    • Laszlo Ersek's avatar
      dump: eliminate DumpState.page_size ("guest's page size") · 2f859f80
      Laszlo Ersek authored
      Use TARGET_PAGE_SIZE and ~TARGET_PAGE_MASK instead.
      
      "DumpState.page_size" has type "size_t", whereas TARGET_PAGE_SIZE has type
      "int". TARGET_PAGE_MASK is of type "int" and has negative value. The patch
      affects the implicit type conversions as follows:
      
      - create_header32() and create_header64(): assigned to "block_size", which
        has type "uint32_t". No change.
      
      - get_next_page(): "block->target_start", "block->target_end" and "addr"
        have type "hwaddr" (uint64_t).
      
        Before the patch,
        - if "size_t" was "uint64_t", then no additional conversion was done as
          part of the usual arithmetic conversions,
        - If "size_t" was "uint32_t", then it was widened to uint64_t as part of
          the usual arithmetic conversions,
        for the remainder and addition operators.
      
        After the patch,
        - "~TARGET_PAGE_MASK" expands to  ~~((1 << TARGET_PAGE_BITS) - 1). It
          has type "int" and positive value (only least significant bits set).
          That's converted (widened) to "uint64_t" for the bit-ands. No visible
          change.
        - The same holds for the (addr + TARGET_PAGE_SIZE) addition.
      
      - write_dump_pages():
        - TARGET_PAGE_SIZE passed as argument to a bunch of functions that all
          have prototypes. No change.
      
        - When incrementing "offset_data" (of type "off_t"): given that we never
          build for ILP32_OFF32 (see "-D_FILE_OFFSET_BITS=64" in configure),
          "off_t" is always "int64_t", and we only need to consider:
          - ILP32_OFFBIG: "size_t" is "uint32_t".
            - before: int64_t += uint32_t. Page size converted to int64_t for
              the addition.
            - after:  int64_t += int32_t. No change.
          - LP64_OFF64: "size_t" is "uint64_t".
            - before: int64_t += uint64_t. Offset converted to uint64_t for the
              addition, then the uint64_t result is converted to int64_t for
              storage.
            - after:  int64_t += int32_t. Same as the ILP32_OFFBIG/after case.
              No visible change.
      
        - (size_out < s->page_size) comparisons, and (size_out = s->page_size)
          assignment:
          - before: "size_out" is of type "size_t", no implicit conversion for
                    either operator.
          - after: TARGET_PAGE_SIZE (of type "int" and positive value) is
                   converted to "size_t" (for the relop because the latter is
                   one of "uint32_t" and "uint64_t"). No visible change.
      
      - dump_init():
        - DIV_ROUND_UP(DIV_ROUND_UP(s->max_mapnr, CHAR_BIT), s->page_size): The
          innermost "DumpState.max_mapnr" field has type uint64_t, which
          propagates through all implicit conversions at hand:
      
          #define DIV_ROUND_UP(n,d) (((n) + (d) - 1) / (d))
      
          regardless of the page size macro argument's type. In the outer macro
          replacement, the page size is converted from uint32_t and int32_t
          alike to uint64_t.
      
        - (tmp * s->page_size) multiplication: "tmp" has size "uint64_t"; the
          RHS is converted to that type from uint32_t and int32_t just the same
          if it's not uint64_t to begin with.
      Signed-off-by: 's avatarLaszlo Ersek <lersek@redhat.com>
      Reviewed-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: 's avatarLuiz Capitulino <lcapitulino@redhat.com>
      2f859f80
    • Laszlo Ersek's avatar
      dump: eliminate DumpState.page_shift ("guest's page shift") · 22227f12
      Laszlo Ersek authored
      Just use TARGET_PAGE_BITS.
      
      "DumpState.page_shift" used to have type "uint32_t", while the replacement
      TARGET_PAGE_BITS has type "int". Since "DumpState.page_shift" was only
      used as bit shift counts in the paddr_to_pfn() and pfn_to_paddr() macros,
      this is safe.
      Suggested-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: 's avatarLaszlo Ersek <lersek@redhat.com>
      Reviewed-by: 's avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: 's avatarLuiz Capitulino <lcapitulino@redhat.com>
      22227f12