1. 07 1月, 2015 7 次提交
    • T
      target-ppc: Fix Floating Point Move Instructions That Set CR1 · 4814f2d1
      Tom Musta 提交于
      The Floating Point Move instructions (fmr., fabs., fnabs., fneg.,
      and fcpsgn.) incorrectly copy FPSCR[FPCC] instead of [FX,FEX,VX,OX].
      Furthermore, the current code does this via a call to gen_compute_fprf,
      which is awkward since these instructions do not actually set FPRF.
      
      Change the code to use the gen_set_cr1_from_fpscr utility.
      Signed-off-by: NTom Musta <tommusta@gmail.com>
      [agraf: whitespace fixes]
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      4814f2d1
    • T
      target-ppc: VXSQRT Should Not Be Set for NaNs · b748863a
      Tom Musta 提交于
      The Power ISA square root instructions (fsqrt[s], frsqrte[s]) must
      set the FPSCR[VXSQRT] flag when operating on a negative value.
      However, NaNs have no sign and therefore this flag should not
      be set when operating on one.
      
      Change the order of the checks in the helper code.  Move the
      SNaN-to-QNaN macro to the top of the file so that it can be
      re-used.
      Signed-off-by: NTom Musta <tommusta@gmail.com>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      b748863a
    • T
      target-ppc: Load/Store Vector Element Storage Alignment · 2791128e
      Tom Musta 提交于
      The Load Vector Element Indexed and Store Vector Element Indexed
      instructions compute an effective address in the usual manner.
      However, they truncate that address to the natural boundary.
      For example, the lvewx instruction will ignore the least significant
      two bits of the address and thus load the aligned word of storage.
      
      Fix the generators for these instruction to properly perform this
      truncation.
      Signed-off-by: NTom Musta <tommusta@gmail.com>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      2791128e
    • A
      PPC: e500 pci host: Add support for ATMUs · cb3778a0
      Alexander Graf 提交于
      The e500 PCI controller has configurable windows that allow a guest OS
      to selectively map parts of the PCI bus space to CPU address space and
      to selectively map parts of the CPU address space for DMA requests into
      PCI visible address ranges.
      
      So far, we've simply assumed that this mapping is 1:1 and ignored it.
      
      However, the PCICSRBAR (CCSR mapped in PCI bus space) always has to live
      inside the first 32bits of address space. This means if we always treat
      all mappings as 1:1, this map will collide with our RAM map from the CPU's
      point of view.
      
      So this patch adds proper ATMU support which allows us to keep the PCICSRBAR
      below 32bits local to the PCI bus and have another, different window to PCI
      BARs at the upper end of address space. We leverage this on e500plat though,
      mpc8544ds stays virtually 1:1 like it was before, but now also goes via ATMU.
      
      With this patch, I can run guests with lots of RAM and not coincidently access
      MSI-X mappings while I really want to access RAM.
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      cb3778a0
    • A
      PPC: mpc8554ds: Tell user about exceeding RAM limits · 44045ce9
      Alexander Graf 提交于
      The mpc8544ds board only supports up to 3GB of RAM due to its limited
      address space.
      
      When the user requests more, abort and tell him that he should use less.
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      44045ce9
    • A
      PPC: e500: Move CCSR and MMIO space to upper end of address space · e6b4e5f4
      Alexander Graf 提交于
      On e500 we're basically guaranteed to have 36bits of physical address space
      available for our enjoyment. Older chips (like the mpc8544) only had 32bits,
      but everything from e500v2 onwards bumped it up.
      
      It's reasonably safe to assume that if you're using the PV machine, your guest
      kernel is configured to support 36bit physical address space. So in order to
      support more guest RAM, we can move CCSR and other MMIO windows right below the
      end of our 36bit address space, just like later SoC versions of e500 do.
      
      With this patch, I'm able to successfully spawn an e500 VM with -m 48G.
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      e6b4e5f4
    • A
      PPC: e500: Move CCSR definition to params · 2eaaac1f
      Alexander Graf 提交于
      We want to have different MMIO region offsets for the mpc8544ds machine
      and our e500 PV machine, so move the definitions of those into the machine
      specific params struct.
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      2eaaac1f
  2. 23 12月, 2014 33 次提交