Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu
切换分支/标签
  1. 18 9月, 2015 6 次提交
    • 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
    • M
      error: New error_fatal · a29a37b9
      由 Markus Armbruster 提交于 
      Similar to error_abort, but doesn't report where the error was
created, and terminates the process with exit(1) rather than abort().
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Message-Id: <1441983105-26376-2-git-send-email-armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NPeter Crosthwaite <crosthwaite.peter@gmail.com>
      a29a37b9
    • M
      MAINTAINERS: Add "Error reporting" entry · 4f966768
      由 Markus Armbruster 提交于 
      Error reporting work has been flowing through my tree for a while.
Time for MAINTAINERS to catch up.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Message-Id: <1442057396-21989-1-git-send-email-armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NPeter Crosthwaite <crosthwaite.peter@gmail.com>
      4f966768
    • E
      error: Copy location information in error_copy() · 88e2ce29
      由 Eric Blake 提交于 
      Commit 1e9b65bb forgot to propagate source information to copied
errors.
Signed-off-by: NEric Blake <eblake@redhat.com>
Message-Id: <1441902890-23064-1-git-send-email-eblake@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      88e2ce29
    • E
      hmp: Allow for error message hints on HMP · 50b7b000
      由 Eric Blake 提交于 
      Commits 7216ae3d and d2828429 disabled some error message hints,
all because a change to use modern error reporting meant that the
hint would be output prior to the actual error.  Fix this by making
hints a first-class member of Error.

For example, we are now back to the pleasant:

 $ qemu-system-x86_64 --nodefaults -S --vnc :0 --chardev null,id=,
 qemu-system-x86_64: --chardev null,id=,: Parameter 'id' expects an identifier
 Identifiers consist of letters, digits, '-', '.', '_', starting with a letter.
Signed-off-by: NEric Blake <eblake@redhat.com>
Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
Message-Id: <1441901956-21991-1-git-send-email-eblake@redhat.com>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      50b7b000
    • S
      error: only prepend timestamp on stderr · 615cf669
      由 Stefan Hajnoczi 提交于 
      The -msg timestamp=on option prepends a timestamp to error messages.
This is useful on stderr where it allows users to identify when an error
was raised.

Timestamps do not make sense on the monitor since error_report() is
called in response to a synchronous monitor command and the user already
knows "when" the command was issued.  Additionally, the rest of the
monitor conversation lacks timestamps so the error timestamp cannot be
correlated with other activity.

Only prepend timestamps on stderr.  This fixes libvirt's 'drive_del'
processing, which did not expect a timestamp.  Other QEMU monitor
clients are probably equally confused by timestamps on monitor error
messages.

Cc: Markus Armbruster <armbru@redhat.com>
Cc: Seiji Aguchi <seiji.aguchi@hds.com>
Cc: Frank Schreuder <fschreuder@transip.nl>
Cc: Daniel P. Berrange <berrange@redhat.com>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
Message-Id: <1439212541-16997-1-git-send-email-stefanha@redhat.com>
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>
Tested-by: NFrank Schreuder <fschreuder@transip.nl>
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      615cf669
  3. 17 9月, 2015 6 次提交
  5. 16 9月, 2015 28 次提交