Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 23 9月, 2016 1 次提交
  3. 14 6月, 2016 1 次提交
  5. 06 6月, 2016 5 次提交
  7. 23 3月, 2016 2 次提交
    • P
      hw: explicitly include qemu-common.h and cpu.h · 4771d756
      由 Paolo Bonzini 提交于 
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      4771d756
    • 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
  9. 18 2月, 2016 1 次提交
  11. 21 1月, 2016 1 次提交
  13. 19 1月, 2016 1 次提交
  15. 15 1月, 2016 1 次提交
    • A
      xlnx-zynqmp: Add support for high DDR memory regions · dc3b89ef
      由 Alistair Francis 提交于 
      The Xilinx ZynqMP SoC and EP108 board supports three memory regions:
 - A 2GB region starting at 0
 - A 32GB region starting at 32GB
 - A 256GB region starting at 768GB

This patch adds support for the first two memory regions, which is
automatically created based on the size specified by the QEMU memory
command line argument.

On hardware the physical memory region is one continuous region, it is then
mapped into the three different regions by the DDRC. As we don't model the
DDRC this is done at startup by QEMU. The board creates the memory region and
then passes that memory region to the SoC. The SoC then maps the memory
regions.
Signed-off-by: NAlistair Francis <alistair.francis@xilinx.com>
Reviewed-by: NPeter Crosthwaite <crosthwaite.peter@gmail.com>
Message-id: a1e47db941d65733724a300fcd98b74fbeeaaf22.1452637205.git.alistair.francis@xilinx.com
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      dc3b89ef
  17. 13 1月, 2016 1 次提交
  19. 30 10月, 2015 1 次提交
  21. 09 10月, 2015 1 次提交
    • M
      qdev: Protect device-list-properties against broken devices · 4c315c27
      由 Markus Armbruster 提交于 
      Several devices don't survive object_unref(object_new(T)): they crash
or hang during cleanup, or they leave dangling pointers behind.

This breaks at least device-list-properties, because
qmp_device_list_properties() needs to create a device to find its
properties.  Broken in commit f4eb32b5 "qmp: show QOM properties in
device-list-properties", v2.1.  Example reproducer:

    $ qemu-system-aarch64 -nodefaults -display none -machine none -S -qmp stdio
    {"QMP": {"version": {"qemu": {"micro": 50, "minor": 4, "major": 2}, "package": ""}, "capabilities": []}}
    { "execute": "qmp_capabilities" }
    {"return": {}}
    { "execute": "device-list-properties", "arguments": { "typename": "pxa2xx-pcmcia" } }
    qemu-system-aarch64: /home/armbru/work/qemu/memory.c:1307: memory_region_finalize: Assertion `((&mr->subregions)->tqh_first == ((void *)0))' failed.
    Aborted (core dumped)
    [Exit 134 (SIGABRT)]

Unfortunately, I can't fix the problems in these devices right now.
Instead, add DeviceClass member cannot_destroy_with_object_finalize_yet
to mark them:

* Hang during cleanup (didn't debug, so I can't say why):
  "realview_pci", "versatile_pci".

* Dangling pointer in cpus: most CPUs, plus "allwinner-a10", "digic",
  "fsl,imx25", "fsl,imx31", "xlnx,zynqmp", because they create such
  CPUs

* Assert kvm_enabled(): "host-x86_64-cpu", host-i386-cpu",
  "host-powerpc64-cpu", "host-embedded-powerpc-cpu",
  "host-powerpc-cpu" (the powerpc ones can't currently reach the
  assertion, because the CPUs are only registered when KVM is enabled,
  but the assertion is arguably in the wrong place all the same)

Make qmp_device_list_properties() fail cleanly when the device is so
marked.  This improves device-list-properties from "crashes, hangs or
leaves dangling pointers behind" to "fails".  Not a complete fix, just
a better-than-nothing work-around.  In the above reproducer,
device-list-properties now fails with "Can't list properties of device
'pxa2xx-pcmcia'".

This also protects -device FOO,help, which uses the same machinery
since commit ef523587 "qdev-monitor: include QOM properties in -device
FOO, help output", v2.2.  Example reproducer:

    $ qemu-system-aarch64 -machine none -device pxa2xx-pcmcia,help

Before:

    qemu-system-aarch64: .../memory.c:1307: memory_region_finalize: Assertion `((&mr->subregions)->tqh_first == ((void *)0))' failed.

After:

    Can't list properties of device 'pxa2xx-pcmcia'

Cc: "Andreas Färber" <afaerber@suse.de>
Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
Cc: Alexander Graf <agraf@suse.de>
Cc: Anthony Green <green@moxielogic.com>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
Cc: Blue Swirl <blauwirbel@gmail.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>
Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
Cc: Jia Liu <proljc@gmail.com>
Cc: Leon Alrae <leon.alrae@imgtec.com>
Cc: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Cc: Max Filippov <jcmvbkbc@gmail.com>
Cc: Michael Walle <michael@walle.cc>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Richard Henderson <rth@twiddle.net>
Cc: qemu-ppc@nongnu.org
Cc: qemu-stable@nongnu.org
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Message-Id: <1443689999-12182-10-git-send-email-armbru@redhat.com>
      4c315c27
  23. 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
  25. 14 9月, 2015 1 次提交
  27. 09 9月, 2015 2 次提交
  29. 25 8月, 2015 1 次提交
  31. 17 7月, 2015 1 次提交
  33. 19 6月, 2015 3 次提交
  35. 18 5月, 2015 5 次提交