Skip to content

Q
Qemu

mirror_resources / Qemu
12 个月 前同步成功

通知 4
Star 0
Fork 0
Q
Qemu

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

切换分支/标签
  1. 22 2月, 2017 1 次提交
    • P
      loader: Support Flattened Image Trees (FIT images) · 51b58561
      由 Paul Burton 提交于 
      Introduce support for loading Flattened Image Trees, as used by modern
U-Boot. FIT images are essentially flattened device tree files which
contain binary images such as kernels, FDTs or ramdisks along with one
or more configuration nodes describing boot configurations.

The MIPS Boston board typically boots kernels in the form of FIT images,
and will make use of this code.
Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
[yongbok.kim@imgtec.com:
  fixed potential memory leaks,
  isolated building option]
Signed-off-by: NYongbok Kim <yongbok.kim@imgtec.com>
      51b58561
  3. 06 2月, 2017 2 次提交
  5. 28 1月, 2017 1 次提交
  7. 25 1月, 2017 1 次提交
  9. 24 1月, 2017 1 次提交
    • T
      hw/core/null-machine: Add the possibility to instantiate a CPU and RAM · 3964ec6c
      由 Thomas Huth 提交于 
      Sometimes it is useful to have just a machine with CPU and RAM, without
any further hardware in it, e.g. if you just want to do some instruction
debugging for TCG with a remote GDB attached to QEMU, or run some embedded
code with the "-semihosting" QEMU parameter. qemu-system-m68k already
features a "dummy" machine, and xtensa a "sim" machine for exactly this
purpose.
All target architectures have nowadays also a "none" machine, which would
be a perfect match for this, too - but it currently does not allow to add
CPU and RAM yet. Thus let's add these possibilities in a generic way to the
"none" machine, too, so that we hopefully do not need additional "dummy"
machines in the future anymore (and maybe can also get rid of the already
existing "dummy"/"sim" machines one day).
Note that the default behaviour of the "none" machine is not changed, i.e.
no CPU and no RAM is instantiated by default. You have explicitely got to
specify the CPU model with "-cpu" and the amount of RAM with "-m" to get
these new features.
Signed-off-by: NThomas Huth <thuth@redhat.com>
Message-Id: <1484743490-24721-1-git-send-email-thuth@redhat.com>
Reviewed-by: NEduardo Habkost <ehabkost@redhat.com>
Reviewed-by: NAlistair Francis <alistair.francis@xilinx.com>
Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      3964ec6c
  11. 19 1月, 2017 1 次提交
  13. 17 1月, 2017 1 次提交
  15. 30 11月, 2016 2 次提交
    • L
      loader: fix undefined behavior in rom_order_compare() · 1b57bd4f
      由 Laszlo Ersek 提交于 
      According to ISO C99 / N1256 (referenced in HACKING):

> 6.5.8 Relational operators
>
> 4 For the purposes of these operators, a pointer to an object that is
>   not an element of an array behaves the same as a pointer to the first
>   element of an array of length one with the type of the object as its
>   element type.
>
> 5 When two pointers are compared, the result depends on the relative
>   locations in the address space of the objects pointed to. If two
>   pointers to object or incomplete types both point to the same object,
>   or both point one past the last element of the same array object, they
>   compare equal. If the objects pointed to are members of the same
>   aggregate object, pointers to structure members declared later compare
>   greater than pointers to members declared earlier in the structure,
>   and pointers to array elements with larger subscript values compare
>   greater than pointers to elements of the same array with lower
>   subscript values. All pointers to members of the same union object
>   compare equal. If the expression /P/ points to an element of an array
>   object and the expression /Q/ points to the last element of the same
>   array object, the pointer expression /Q+1/ compares greater than /P/.
>   In all other cases, the behavior is undefined.

Our AddressSpace objects are allocated generally individually, and kept in
the "address_spaces" linked list, so we mustn't compare their addresses
with relops.

Convert the pointers subjected to the relop in rom_order_compare() to
"uintptr_t":

> 7.18.1.4 Integer types capable of holding object pointers
>
> 1 [...]
>
>   The following type designates an unsigned integer type with the
>   property that any valid pointer to void can be converted to this type,
>   then converted back to pointer to void, and the result will compare
>   equal to the original pointer:
>
>   /uintptr_t/
>
>   These types are optional.

Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Alistair Francis <alistair.francis@xilinx.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: qemu-devel@nongnu.org
Fixes: 3e76099aSigned-off-by: NLaszlo Ersek <lersek@redhat.com>
Reviewed-by: NAlistair Francis <alistair.francis@xilinx.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      1b57bd4f
    • L
      loader: fix handling of custom address spaces when adding ROM blobs · aa6c6ae8
      由 Laszlo Ersek 提交于 
      * Commit 3e76099a ("loader: Allow a custom AddressSpace when loading
  ROMs") introduced the "Rom.as" field:

  (1) It modified the utility callers of rom_insert() to take "as" as a
      new parameter from *their* callers, and set "rom->as" from that
      parameter. The functions covered were rom_add_file() and
      rom_add_elf_program().

  (2) It also modified rom_insert() itself, to auto-assign
      "&address_space_memory", in case the external caller passed -- and
      the utility caller forwarded -- as=NULL.

  Except, commit 3e76099a forgot to update the third utility caller of
  rom_insert(), under point (1), namely rom_add_blob().

* Later, commit 5e774eb3 ("loader: Add AddressSpace loading support
  to uImages") added the load_uimage_as() function, and the
  rom_add_blob_fixed_as() function-like macro, with the necessary changes
  elsewhere to propagate the new "as" parameter to rom_add_blob():

    load_uimage_as()
      load_uboot_image()
        rom_add_blob_fixed_as()
          rom_add_blob()

  At this point, the signature (and workings) of rom_add_blob() had been
  broken already, and the rom_add_blob_fixed_as() macro passed its "_as"
  parameter to rom_add_blob() as "callback_opaque". Given that the
  "fw_callback" parameter itself was set to NULL (correctly), this did no
  additional damage (the opaque arg would never be used), but ultimately
  it broke the new functionality of load_uimage_as().

* The load_uimage_as() function would be put to use in one of the later
  patches, commit e481a1f6 ("generic-loader: Add a generic loader").

* We can fix this only in a unified patch now. Append "AddressSpace *as"
  to the signature of rom_add_blob(), and handle the new parameter. Pass
  NULL from all current callers, except from rom_add_blob_fixed_as(),
  where "_as" has to be bumped to the proper position.

* Note that rom_add_file() rejects the case when both "mr" and "as" are
  passed in as non-NULL. The action that this is apparently supposed to
  prevent is the

    rom->mr = mr;

  assignment (that's the only place where the "mr" parameter is used in
  rom_add_file()). In rom_add_blob() though, we have no "mr" parameter,
  and the actions done on the fw_cfg branch:

    if (fw_file_name && fw_cfg) {
        if (mc->rom_file_has_mr) {
            data = rom_set_mr(rom, OBJECT(fw_cfg), devpath);
            mr = rom->mr;
        } else {
            data = rom->data;
        }

  reflect those that are performed by rom_add_file() too (with mr==NULL):

    if (rom->fw_file && fw_cfg) {
        if ((!option_rom || mc->option_rom_has_mr) &&
            mc->rom_file_has_mr) {
            data = rom_set_mr(rom, OBJECT(fw_cfg), devpath);
        } else {
            data = rom->data;
        }

  Hence we need no additional restrictions in rom_add_blob().

* Stable is not affected as both problematic commits appeared first in
  v2.8.0-rc0.

Cc: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Alistair Francis <alistair.francis@xilinx.com>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Michael Walle <michael@walle.cc>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: Shannon Zhao <zhaoshenglong@huawei.com>
Cc: qemu-arm@nongnu.org
Cc: qemu-devel@nongnu.org
Fixes: 3e76099a
Fixes: 5e774eb3Signed-off-by: NLaszlo Ersek <lersek@redhat.com>
Reviewed-by: NAlistair Francis <alistair.francis@xilinx.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      aa6c6ae8
  17. 28 11月, 2016 1 次提交
  19. 16 11月, 2016 1 次提交
  21. 15 11月, 2016 1 次提交
  23. 10 11月, 2016 1 次提交
  25. 02 11月, 2016 1 次提交
    • X
      nvdimm acpi: introduce fit buffer · 75b0713e
      由 Xiao Guangrong 提交于 
      The buffer is used to save the FIT info for all the presented nvdimm
devices which is updated after the nvdimm device is plugged or
unplugged. In the later patch, it will be used to construct NVDIMM
ACPI _FIT method which reflects the presented nvdimm devices after
nvdimm hotplug

As FIT buffer can not completely mapped into guest address space,
OSPM will exit to QEMU multiple times, however, there is the race
condition - FIT may be changed during these multiple exits, so that
some rules are introduced:
1) the user should hold the @lock to access the buffer and
2) mark @dirty whenever the buffer is updated.

@dirty is cleared for the first time OSPM gets fit buffer, if
dirty is detected in the later access, OSPM will restart the
access

As fit should be updated after nvdimm device is successfully realized
so that a new hotplug callback, post_hotplug, is introduced
Signed-off-by: NXiao Guangrong <guangrong.xiao@linux.intel.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      75b0713e
  27. 24 10月, 2016 7 次提交
  29. 18 10月, 2016 1 次提交
  31. 04 10月, 2016 2 次提交
  33. 28 9月, 2016 1 次提交
  35. 23 9月, 2016 8 次提交
  37. 08 9月, 2016 2 次提交
  39. 08 8月, 2016 1 次提交
  41. 04 8月, 2016 1 次提交
  43. 27 7月, 2016 2 次提交