1. 14 3月, 2017 1 次提交
  2. 03 3月, 2017 2 次提交
    • S
      spapr: Small cleanup of PPC MMU enums · ec975e83
      Sam Bobroff 提交于
      The PPC MMU types are sometimes treated as if they were a bit field
      and sometime as if they were an enum which causes maintenance
      problems: flipping bits in the MMU type (which is done on both the 1TB
      segment and 64K segment bits) currently produces new MMU type
      values that are not handled in every "switch" on it, sometimes causing
      an abort().
      
      This patch provides some macros that can be used to filter out the
      "bit field-like" bits so that the remainder of the value can be
      switched on, like an enum. This allows removal of all of the
      "degraded" types from the list and should ease maintenance.
      Signed-off-by: NSam Bobroff <sam.bobroff@au1.ibm.com>
      Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      ec975e83
    • S
      target/ppc: Don't gen an SDR1 on POWER9 and rework register creation · 4f4f28ff
      Suraj Jitindar Singh 提交于
      POWER9 doesn't have a storage description register 1 (SDR1) which is used
      to store the base and size of the hash table. Thus we don't need to
      generate this register on the POWER9 cpu model. While we're here, the
      register generation code for 970, POWER5+, POWER<7/8/9> in general is a
      mess where we call a generic function from a model specific function which
      then attempts to call model specific functions, so rework this for
      readability.
      
      We update ppc_cpu_dump_state so that "info registers" will only display
      the value of sdr1 if the register has been generated.
      
      As mentioned above the register generation for the pcc->init_proc
      function for 970, POWER5+, POWER7, POWER8 and POWER9 has been reworked
      for improved clarity. Instead of calling init_proc_book3s_64 which then
      attempts to generate the correct registers through a mess of if statements,
      we remove this function and instead call the appropriate register
      generation functions directly. This follows the register generation model
      used for earlier cpu models (pre-970) whereby cpu specific registers are
      generated directly in the init_proc function and makes it easier to
      add/remove specific registers for new cpu models.
      Signed-off-by: NSuraj Jitindar Singh <sjitindarsingh@gmail.com>
      Reviewed-by: NDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: NDavid Gibson <david@gibson.dropbear.id.au>
      4f4f28ff
  3. 01 3月, 2017 9 次提交
  4. 22 2月, 2017 6 次提交
  5. 02 2月, 2017 2 次提交
  6. 31 1月, 2017 6 次提交
  7. 11 1月, 2017 3 次提交
  8. 21 12月, 2016 1 次提交
    • T
      Move target-* CPU file into a target/ folder · fcf5ef2a
      Thomas Huth 提交于
      We've currently got 18 architectures in QEMU, and thus 18 target-xxx
      folders in the root folder of the QEMU source tree. More architectures
      (e.g. RISC-V, AVR) are likely to be included soon, too, so the main
      folder of the QEMU sources slowly gets quite overcrowded with the
      target-xxx folders.
      To disburden the main folder a little bit, let's move the target-xxx
      folders into a dedicated target/ folder, so that target-xxx/ simply
      becomes target/xxx/ instead.
      
      Acked-by: Laurent Vivier <laurent@vivier.eu> [m68k part]
      Acked-by: Bastian Koppelmann <kbastian@mail.uni-paderborn.de> [tricore part]
      Acked-by: Michael Walle <michael@walle.cc> [lm32 part]
      Acked-by: Cornelia Huck <cornelia.huck@de.ibm.com> [s390x part]
      Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com> [s390x part]
      Acked-by: Eduardo Habkost <ehabkost@redhat.com> [i386 part]
      Acked-by: Artyom Tarasenko <atar4qemu@gmail.com> [sparc part]
      Acked-by: Richard Henderson <rth@twiddle.net> [alpha part]
      Acked-by: Max Filippov <jcmvbkbc@gmail.com> [xtensa part]
      Reviewed-by: David Gibson <david@gibson.dropbear.id.au> [ppc part]
      Acked-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> [cris&microblaze part]
      Acked-by: Guan Xuetao <gxt@mprc.pku.edu.cn> [unicore32 part]
      Signed-off-by: NThomas Huth <thuth@redhat.com>
      fcf5ef2a
  9. 15 11月, 2016 1 次提交
  10. 02 11月, 2016 1 次提交
    • R
      log: Add locking to large logging blocks · 1ee73216
      Richard Henderson 提交于
      Reuse the existing locking provided by stdio to keep in_asm, cpu,
      op, op_opt, op_ind, and out_asm as contiguous blocks.
      
      While it isn't possible to interleave e.g. in_asm or op_opt logs
      because of the TB lock protecting all code generation, it is
      possible to interleave cpu logs, or to interleave a cpu dump with
      an out_asm dump.
      
      For mingw32, we appear to have no viable solution for this.  The locking
      functions are not properly exported from the system runtime library.
      Reviewed-by: NPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NRichard Henderson <rth@twiddle.net>
      1ee73216
  11. 28 10月, 2016 2 次提交
  12. 05 10月, 2016 1 次提交
  13. 23 9月, 2016 5 次提交