1. 30 Oct, 2010 1 commit
  2. 13 Oct, 2010 1 commit
  3. 30 Sep, 2010 1 commit
  4. 24 Sep, 2010 1 commit
  5. 03 Jul, 2010 2 commits
  6. 12 Mar, 2010 2 commits
  7. 27 Feb, 2010 1 commit
  8. 21 Dec, 2009 3 commits
  9. 07 Nov, 2009 1 commit
  10. 22 Oct, 2009 1 commit
  11. 01 Oct, 2009 2 commits
  12. 24 Aug, 2009 1 commit
    • Nathan Froyd's avatar
      cleanup cpu-exec.c, part 0/N: consolidate handle_cpu_signal · 0b5c1ce8
      Nathan Froyd authored
      handle_cpu_signal is very nearly copy-paste code for each target, with a
      few minor variations.  This patch sets up appropriate defaults for a
      generic handle_cpu_signal and provides overrides for particular targets
      that did things differently.  Fixing things like the persistent (XXX:
      use sigsetjmp) should now become somewhat easier.
      
      Previous comments on this patch suggest that the "activate soft MMU for
      this block" comments refer to defunct functionality.  I have removed
      such blocks for the appropriate targets in this patch.
      Signed-off-by: default avatarNathan Froyd <froydnj@codesourcery.com>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      0b5c1ce8
  13. 16 Aug, 2009 3 commits
  14. 03 Aug, 2009 4 commits
  15. 16 Jul, 2009 1 commit
  16. 19 May, 2009 1 commit
    • Paul Brook's avatar
      Hardware convenience library · 1ad2134f
      Paul Brook authored
      The only target dependency for most hardware is sizeof(target_phys_addr_t).
      Build these files into a convenience library, and use that instead of
      building for every target.
      
      Remove and poison various target specific macros to avoid bogus target
      dependencies creeping back in.
      
      Big/Little endian is not handled because devices should not know or care
      about this to start with.
      Signed-off-by: default avatarPaul Brook <paul@codesourcery.com>
      1ad2134f
  17. 15 May, 2009 1 commit
  18. 28 Apr, 2009 1 commit
  19. 13 Mar, 2009 1 commit
    • blueswir1's avatar
      Make the ELF loader aware of backwards compatibility · 7f70c937
      blueswir1 authored
      Most 64 bit architectures I'm aware of support running 32 bit code
      of the same architecture as well.
      
      So x86_64 can run i386 code easily and ppc64 can run ppc code.
      
      Unfortunately, the current checks are pretty strict. So you can only
      load e.g. an x86_64 elf binary on qemu-system-x86_64, but no i386 one.
      
      This can get really annoying. I first encountered this issue with
      my multiboot patch, where qemu-system-x86_64 was unable to load an
      i386 elf binary because the elf loader rejected it.
      
      The same thing happened again on PPC64 now. The firmware we're loading
      is a PPC32 elf binary, as it's shared with PPC32. But the platform is
      PPC64.
      
      Right now there is a hack for this in the ppc cpu.h definition, that
      simply sets the type to PPC32 in system emulation mode. While that
      works fine for the firmware, it's no good if you also want to load a
      PPC64 kernel with -kernel.
      
      So in order to solve this mess, I figured the easiest way is to make
      the elf loader aware of platforms that are backwards compatible. For
      now I was only sure that x86_64 does i386 and ppc64 does ppc32, but
      maybe there are other combinations too.
      
      This patch is a prerequisite for having a working -kernel option on
      PPC64.
      Signed-off-by: default avatarAlexander Graf <alex@csgraf.de>
      
      
      git-svn-id: svn://svn.savannah.nongnu.org/qemu/trunk@6855 c046a42c-6fe2-441c-8c8c-71466251a162
      7f70c937
  20. 07 Mar, 2009 4 commits
  21. 02 Mar, 2009 1 commit
  22. 08 Feb, 2009 1 commit
  23. 03 Feb, 2009 2 commits
  24. 04 Jan, 2009 1 commit
  25. 03 Jan, 2009 1 commit
  26. 18 Dec, 2008 1 commit