Skip to content
Snippets Groups Projects
Select Git revision
  • feature/libtcg-rebase default protected
1 result
Search by author
  • Any Author
  • Anton Anton anjo
1 author
  1. Feb 18, 2017
  3. Feb 16, 2017
  5. Jan 20, 2017
    • Thomas Huth's avatar
      m68k: QOMify the MCF Fast Ethernet Controller device · 6ac38ed4
      Thomas Huth authored 
      
When running qemu-system-m68k with the "-net" parameter (for example
simply "-net nic -net user"), there is currently a confusing warning
message saying:

 Warning: requested NIC (anonymous, model mcf_fec) was not created
 (not supported by this machine?)

This seems to happen because the MCF NIC has never been adapted to
the currently expected QEMU device behavior. Thus let's QOMify the
NIC now to get rid of the warning message.

Signed-off-by: default avatarThomas Huth <huth@tuxfamily.org>
Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
      6ac38ed4
  7. Oct 08, 2016
  9. Sep 22, 2016
  11. Mar 22, 2016
    • Paolo Bonzini's avatar
      hw: explicitly include qemu-common.h and cpu.h · 4771d756
      Paolo Bonzini authored 
      
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      4771d756
    • Markus Armbruster's avatar
      include/qemu/osdep.h: Don't include qapi/error.h · da34e65c
      Markus Armbruster authored 
      
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: default avatarMarkus Armbruster <armbru@redhat.com>
[Fix compilation without the spice devel packages. - Paolo]
Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      da34e65c
  13. Mar 04, 2016
    • Peter Crosthwaite's avatar
      loader: Add data swap option to load-elf · 7ef295ea
      Peter Crosthwaite authored 
      
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: default avatarPeter Maydell <peter.maydell@linaro.org>
Signed-off-by: default avatarPeter Crosthwaite <crosthwaite.peter@gmail.com>
Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      7ef295ea
  15. Jan 29, 2016
  17. Jan 13, 2016
  19. Sep 25, 2015
  21. Sep 19, 2015
  23. Sep 18, 2015
    • Markus Armbruster's avatar
      Fix bad error handling after memory_region_init_ram() · f8ed85ac
      Markus Armbruster authored 
      
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: default avatarMarkus Armbruster <armbru@redhat.com>
Message-Id: <1441983105-26376-3-git-send-email-armbru@redhat.com>
Reviewed-by: default avatarPeter Crosthwaite <crosthwaite.peter@gmail.com>
      f8ed85ac
  25. Jun 22, 2015
  27. Mar 25, 2015
  29. Mar 10, 2015
  31. Nov 02, 2014
    • Max Filippov's avatar
      hw/core/loader: implement address translation in uimage loader · 25bda50a
      Max Filippov authored 
      
Such address translation is needed when load address recorded in uImage
is a virtual address. When the actual load address is requested, return
untranslated address: user that needs the translated address can always
apply translation function to it and those that need it untranslated
don't need to do the inverse translation.

Add translation function pointer and its parameter to uimage_load
prototype. Update all existing users.

No user-visible functional changes.

Cc: qemu-stable@nongnu.org
Signed-off-by: default avatarMax Filippov <jcmvbkbc@gmail.com>
Reviewed-by: default avatarAlexander Graf <agraf@suse.de>
      25bda50a
  33. Sep 09, 2014
  35. May 28, 2014
  37. Nov 05, 2013
  39. Aug 28, 2013
    • Markus Armbruster's avatar
      hw: Clean up bogus default boot order · c1654732
      Markus Armbruster authored 
      
We set default boot order "cad" in every single machine definition
except "pseries" and "moxiesim", even though very few boards actually
care for boot order, and "cad" makes sense for even fewer.

Machines that care:

* pc and its variants

  Accept up to three letters 'a', 'b' (undocumented alias for 'a'),
  'c', 'd' and 'n'.  Reject all others (fatal with -boot).

* nseries (n800, n810)

  Check whether order starts with 'n'.  Silently ignored otherwise.

* prep, g3beige, mac99

  Extract the first character the machine understands (subset of
  'a'..'f').  Silently ignored otherwise.

* spapr

  Accept an arbitrary string (vl.c restricts it to contain only
  'a'..'p', no duplicates).

* sun4[mdc]

  Use the first character.  Silently ignored otherwise.

Strip characters these machines ignore from their default boot order.

For all other machines, remove the unused default boot order
alltogether.

Note that my rename of QEMUMachine member boot_order to
default_boot_order and QEMUMachineInitArgs member boot_device to
boot_order has a welcome side effect: it makes every use of boot
orders visible in this patch, for easy review.

Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
Reviewed-by: default avatarLaszlo Ersek <lersek@redhat.com>
Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      c1654732
  41. Jul 04, 2013
  43. Apr 08, 2013
  45. Mar 01, 2013
  47. Jun 07, 2012