Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

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

切换分支/标签
  1. 27 9月, 2017 2 次提交
  3. 26 9月, 2017 1 次提交
  5. 19 9月, 2017 1 次提交
  7. 01 9月, 2017 1 次提交
  9. 15 7月, 2017 2 次提交
  11. 11 5月, 2017 1 次提交
  13. 22 2月, 2017 1 次提交
  15. 21 2月, 2017 1 次提交
    • M
      hw: Default -drive to if=ide explicitly where it works · 2059839b
      由 Markus Armbruster 提交于 
      Block backends defined with -drive if=ide are meant to be picked up by
machine initialization code: a suitable frontend gets created and
wired up automatically.

if=ide drives not picked up that way can still be used with -device as
if they had if=none, but that's unclean and best avoided.  Unused ones
produce an "Orphaned drive without device" warning.

-drive parameter "if" is optional, and the default depends on the
machine type.  If a machine type doesn't specify a default, the
default is "ide".

Many machine types default to if=ide, even though they don't actually
have an IDE controller.  A future patch will change these defaults to
something more sensible.  To prepare for it, this patch makes default
"ide" explicit for the machines that actually pick up if=ide drives:

* alpha: clipper
* arm/aarch64: spitz borzoi terrier tosa
* i386/x86_64: generic-pc-machine (with concrete subtypes pc-q35-*
  pc-i440fx-* pc-* isapc xenfv)
* mips64el: fulong2e
* mips/mipsel/mips64el: malta mips
* ppc/ppc64: mac99 g3beige prep
* sh4/sh4eb: r2d
* sparc64: sun4u sun4v

Note that ppc64 machine powernv already sets an "ide" default
explicitly.  Its IDE controller isn't implemented, yet.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NThomas Huth <thuth@redhat.com>
Message-Id: <1487153147-11530-2-git-send-email-armbru@redhat.com>
      2059839b
  17. 16 11月, 2016 1 次提交
  19. 04 7月, 2016 1 次提交
  21. 23 3月, 2016 2 次提交
    • V
      util: move declarations out of qemu-common.h · f348b6d1
      由 Veronia Bahaa 提交于 
      Move declarations out of qemu-common.h for functions declared in
utils/ files: e.g. include/qemu/path.h for utils/path.c.
Move inline functions out of qemu-common.h and into new files (e.g.
include/qemu/bcd.h)
Signed-off-by: NVeronia Bahaa <veroniabahaa@gmail.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      f348b6d1
    • 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
  23. 04 3月, 2016 1 次提交
    • P
      loader: Add data swap option to load-elf · 7ef295ea
      由 Peter Crosthwaite 提交于 
      Some CPUs are of an opposite data-endianness to other components in the
system. Sometimes elfs have the data sections layed out with this CPU
data-endianness accounting for when loaded via the CPU, so byte swaps
(relative to other system components) will occur.

The leading example, is ARM's BE32 mode, which is is basically LE with
address manipulation on half-word and byte accesses to access the
hw/byte reversed address. This means that word data is invariant
across LE and BE32. This also means that instructions are still LE.
The expectation is that the elf will be loaded via the CPU in this
endianness scheme, which means the data in the elf is reversed at
compile time.

As QEMU loads via the system memory directly, rather than the CPU, we
need a mechanism to reverse elf data endianness to implement this
possibility.
Reviewed-by: NPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: NPeter Crosthwaite <crosthwaite.peter@gmail.com>
Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      7ef295ea
  25. 29 1月, 2016 1 次提交
    • P
      ppc: Clean up includes · 0d75590d
      由 Peter Maydell 提交于 
      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: NPeter Maydell <peter.maydell@linaro.org>
Message-id: 1453832250-766-6-git-send-email-peter.maydell@linaro.org
      0d75590d
  27. 13 1月, 2016 1 次提交
  29. 12 11月, 2015 1 次提交
  31. 25 9月, 2015 1 次提交
  33. 19 9月, 2015 2 次提交
  35. 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
  37. 07 7月, 2015 1 次提交
  39. 10 6月, 2015 1 次提交
  41. 26 3月, 2015 1 次提交
  43. 25 3月, 2015 1 次提交
    • G
      fw_cfg: factor out initialization of FW_CFG_ID (rev. number) · 3a5c76ba
      由 Gabriel L. Somlo 提交于 
      The fw_cfg documentation says this of the revision key (0x0001, FW_CFG_ID):

> A 32-bit little-endian unsigned int, this item is used as an interface
> revision number, and is currently set to 1 by all QEMU architectures
> which expose a fw_cfg device.

arm/virt doesn't.  It could be argued that that's an error in
"hw/arm/virt.c"; on the other hand, all of the other fw_cfg providing
boards set the interface version to 1 manually, despite the device
coming from the same, shared implementation. Therefore, instead of
adding

    fw_cfg_add_i32(fw_cfg, FW_CFG_ID, 1);

to arm/virt, consolidate all such existing calls in the fw_cfg
initialization code.
Signed-off-by: NGabriel Somlo <somlo@cmu.edu>
Message-Id: <1426789244-26318-1-git-send-email-somlo@cmu.edu>
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      3a5c76ba
  45. 18 2月, 2015 1 次提交
  47. 09 1月, 2015 4 次提交
  49. 07 1月, 2015 4 次提交
  51. 23 12月, 2014 1 次提交
  53. 22 12月, 2014 1 次提交
  55. 20 10月, 2014 1 次提交
    • M
      hw: Convert from BlockDriverState to BlockBackend, mostly · 4be74634
      由 Markus Armbruster 提交于 
      Device models should access their block backends only through the
block-backend.h API.  Convert them, and drop direct includes of
inappropriate headers.

Just four uses of BlockDriverState are left:

* The Xen paravirtual block device backend (xen_disk.c) opens images
  itself when set up via xenbus, bypassing blockdev.c.  I figure it
  should go through qmp_blockdev_add() instead.

* Device model "usb-storage" prompts for keys.  No other device model
  does, and this one probably shouldn't do it, either.

* ide_issue_trim_cb() uses bdrv_aio_discard() instead of
  blk_aio_discard() because it fishes its backend out of a BlockAIOCB,
  which has only the BlockDriverState.

* PC87312State has an unused BlockDriverState[] member.

The next two commits take care of the latter two.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NMax Reitz <mreitz@redhat.com>
Signed-off-by: NKevin Wolf <kwolf@redhat.com>
      4be74634
  57. 03 10月, 2014 1 次提交
    • J
      ide: Update ide_drive_get to be HBA agnostic · d8f94e1b
      由 John Snow 提交于 
      Instead of duplicating the logic for the if_ide
(bus,unit) mappings, rely on the blockdev layer
for managing those mappings for us, and use the
drive_get_by_index call instead.

This allows ide_drive_get to work for AHCI HBAs
as well, and can be used in the Q35 initialization.

Lastly, change the nature of the argument to
ide_drive_get so that represents the number of
total drives we can support, and not the total
number of buses. This will prevent array overflows
if the units-per-default-bus property ever needs
to be adjusted for compatibility reasons.
Signed-off-by: NJohn Snow <jsnow@redhat.com>
Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Message-id: 1412187569-23452-5-git-send-email-jsnow@redhat.com
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      d8f94e1b
  59. 09 9月, 2014 1 次提交