1. 21 4月, 2017 3 次提交
  2. 19 5月, 2016 2 次提交
  3. 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
  4. 29 1月, 2016 1 次提交
  5. 09 10月, 2015 1 次提交
  6. 18 9月, 2015 1 次提交
    • M
      Fix bad error handling after memory_region_init_ram() · f8ed85ac
      Markus Armbruster 提交于
      Symptom:
      
          $ qemu-system-x86_64 -m 10000000
          Unexpected error in ram_block_add() at /work/armbru/qemu/exec.c:1456:
          upstream-qemu: cannot set up guest memory 'pc.ram': Cannot allocate memory
          Aborted (core dumped)
      
      Root cause: commit ef701d7b screwed up handling of out-of-memory
      conditions.  Before the commit, we report the error and exit(1), in
      one place, ram_block_add().  The commit lifts the error handling up
      the call chain some, to three places.  Fine.  Except it uses
      &error_abort in these places, changing the behavior from exit(1) to
      abort(), and thus undoing the work of commit 39228250 "exec: Don't
      abort when we can't allocate guest memory".
      
      The three places are:
      
      * memory_region_init_ram()
      
        Commit 49946538 (right after commit ef701d7b) lifted the error
        handling further, through memory_region_init_ram(), multiplying the
        incorrect use of &error_abort.  Later on, imitation of existing
        (bad) code may have created more.
      
      * memory_region_init_ram_ptr()
      
        The &error_abort is still there.
      
      * memory_region_init_rom_device()
      
        Doesn't need fixing, because commit 33e0eb52 (soon after commit
        ef701d7b) lifted the error handling further, and in the process
        changed it from &error_abort to passing it up the call chain.
        Correct, because the callers are realize() methods.
      
      Fix the error handling after memory_region_init_ram() with a
      Coccinelle semantic patch:
      
          @r@
          expression mr, owner, name, size, err;
          position p;
          @@
                  memory_region_init_ram(mr, owner, name, size,
          (
          -                              &error_abort
          +                              &error_fatal
          |
                                         err@p
          )
                                        );
          @script:python@
              p << r.p;
          @@
          print "%s:%s:%s" % (p[0].file, p[0].line, p[0].column)
      
      When the last argument is &error_abort, it gets replaced by
      &error_fatal.  This is the fix.
      
      If the last argument is anything else, its position is reported.  This
      lets us check the fix is complete.  Four positions get reported:
      
      * ram_backend_memory_alloc()
      
        Error is passed up the call chain, ultimately through
        user_creatable_complete().  As far as I can tell, it's callers all
        handle the error sanely.
      
      * fsl_imx25_realize(), fsl_imx31_realize(), dp8393x_realize()
      
        DeviceClass.realize() methods, errors handled sanely further up the
        call chain.
      
      We're good.  Test case again behaves:
      
          $ qemu-system-x86_64 -m 10000000
          qemu-system-x86_64: cannot set up guest memory 'pc.ram': Cannot allocate memory
          [Exit 1 ]
      
      The next commits will repair the rest of commit ef701d7b's damage.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Message-Id: <1441983105-26376-3-git-send-email-armbru@redhat.com>
      Reviewed-by: NPeter Crosthwaite <crosthwaite.peter@gmail.com>
      f8ed85ac
  7. 24 6月, 2015 1 次提交
  8. 05 6月, 2015 2 次提交
  9. 09 9月, 2014 1 次提交
  10. 06 6月, 2014 2 次提交
  11. 14 5月, 2014 1 次提交
  12. 05 3月, 2014 1 次提交
  13. 27 2月, 2014 1 次提交