1. 18 Jan, 2018 23 commits
  2. 16 Jan, 2018 17 commits
    • Luc MICHEL's avatar
      target-ppc: Fix booke206 tlbwe TLB instruction · 2e569845
      Luc MICHEL authored
      When overwritting a valid TLB entry with a new one, the previous page
      were not flushed in QEMU TLB, leading to incoherent mapping. This commit
      fixes this.
      Signed-off-by: 's avatarLuc MICHEL <luc.michel@git.antfield.fr>
      Signed-off-by: 's avatarDavid Gibson <david@gibson.dropbear.id.au>
      2e569845
    • Cédric Le Goater's avatar
      0bfc0cf0
    • Cédric Le Goater's avatar
      ppc/pnv: change initrd address · fef592f9
      Cédric Le Goater authored
      When skiboot starts, it first clears the CPU structs for all possible
      CPUs on a system :
      
      	for (i = 0; i <= cpu_max_pir; i++)
      		memset(&cpu_stacks[i].cpu, 0, sizeof(struct cpu_thread));
      
      On POWER9, cpu_max_pir is quite big, 0x7fff, and the skiboot cpu_stacks
      array overlaps with the memory region in which QEMU maps the initramfs
      file. Move it upwards in memory to keep it safe.
      Signed-off-by: 's avatarCédric Le Goater <clg@kaod.org>
      Signed-off-by: 's avatarDavid Gibson <david@gibson.dropbear.id.au>
      fef592f9
    • Cédric Le Goater's avatar
      ppc/pnv: fix XSCOM core addressing on POWER9 · c035851a
      Cédric Le Goater authored
      The XSCOM base address of the core chiplet was wrongly calculated. Use
      the OPAL macros to fix that and do a couple of renames.
      Signed-off-by: 's avatarCédric Le Goater <clg@kaod.org>
      Signed-off-by: 's avatarDavid Gibson <david@gibson.dropbear.id.au>
      c035851a
    • Cédric Le Goater's avatar
      ppc/pnv: introduce pnv*_is_power9() helpers · b3b066e9
      Cédric Le Goater authored
      These are useful when instantiating device models which are shared
      between the POWER8 and the POWER9 processor families.
      Signed-off-by: 's avatarCédric Le Goater <clg@kaod.org>
      Signed-off-by: 's avatarDavid Gibson <david@gibson.dropbear.id.au>
      b3b066e9
    • Cédric Le Goater's avatar
      ppc/pnv: change core mask for POWER9 · 09279d7e
      Cédric Le Goater authored
      When addressed by XSCOM, the first core has the 0x20 chiplet ID but
      the CPU PIR can start at 0x0.
      Signed-off-by: 's avatarCédric Le Goater <clg@kaod.org>
      Signed-off-by: 's avatarDavid Gibson <david@gibson.dropbear.id.au>
      09279d7e
    • Cédric Le Goater's avatar
      ppc/pnv: use POWER9 DD2 processor · 83028a2b
      Cédric Le Goater authored
      commit 1ed9c8af ("target/ppc: Add POWER9 DD2.0 model information")
      deprecated the POWER9 model v1.0.
      Signed-off-by: 's avatarCédric Le Goater <clg@kaod.org>
      Signed-off-by: 's avatarDavid Gibson <david@gibson.dropbear.id.au>
      83028a2b
    • Cédric Le Goater's avatar
      tests/boot-serial-test: fix powernv support · 459bb44c
      Cédric Le Goater authored
      Recent commit introduced the firmware image skiboot 5.9 which
      has a different first line ouput.
      Signed-off-by: 's avatarCédric Le Goater <clg@kaod.org>
      Signed-off-by: 's avatarDavid Gibson <david@gibson.dropbear.id.au>
      459bb44c
    • Cédric Le Goater's avatar
      ppc/pnv: Update skiboot firmware image · 60e58bd9
      Cédric Le Goater authored
      This is skiboot 5.9 (commit e0ee24c2). It brings improved POWER9
      support among many other things. Built from submodule.
      Signed-off-by: 's avatarCédric Le Goater <clg@kaod.org>
      Signed-off-by: 's avatarDavid Gibson <david@gibson.dropbear.id.au>
      60e58bd9
    • David Gibson's avatar
      spapr: Adjust default VSMT value for better migration compatibility · 8904e5a7
      David Gibson authored
      fa98fbfc "PC: KVM: Support machine option to set VSMT mode" introduced the
      "vsmt" parameter for the pseries machine type, which controls the spacing
      of the vcpu ids of thread 0 for each virtual core.  This was done to bring
      some consistency and stability to how that was done, while still allowing
      backwards compatibility for migration and otherwise.
      
      The default value we used for vsmt was set to the max of the host's
      advertised default number of threads and the number of vthreads per vcore
      in the guest.  This was done to continue running without extra parameters
      on older KVM versions which don't allow the VSMT value to be changed.
      
      Unfortunately, even that smaller than before leakage of host configuration
      into guest visible configuration still breaks things.  Specifically a guest
      with 4 (or less) vthread/vcore will get a different vsmt value when
      running on a POWER8 (vsmt==8) and POWER9 (vsmt==4) host.  That means the
      vcpu ids don't line up so you can't migrate between them, though you should
      be able to.
      
      Long term we really want to make vsmt == smp_threads for sufficiently
      new machine types.  However, that means that qemu will then require a
      sufficiently recent KVM (one which supports changing VSMT) - that's still
      not widely enough deployed to be really comfortable to do.
      
      In the meantime we need some default that will work as often as
      possible.  This patch changes that default to 8 in all circumstances.
      This does change guest visible behaviour (including for existing
      machine versions) for many cases - just not the most common/important
      case.
      
      Following is case by case justification for why this is still the least
      worst option.  Note that any of the old behaviours can still be duplicated
      after this patch, it's just that it requires manual intervention by
      setting the vsmt property on the command line.
      
      KVM HV on POWER8 host:
         This is the overwhelmingly common case in production setups, and is
         unchanged by design.  POWER8 hosts will advertise a default VSMT mode
         of 8, and > 8 vthreads/vcore isn't permitted
      
      KVM HV on POWER7 host:
         Will break, but POWER7s allowing KVM were never released to the public.
      
      KVM HV on POWER9 host:
         Not yet released to the public, breaking this now will reduce other
         breakage later.
      
      KVM HV on PowerPC 970:
         Will theoretically break it, but it was barely supported to begin with
         and already required various user visible hacks to work.  Also so old
         that I just don't care.
      
      TCG:
         This is the nastiest one; it means migration of TCG guests (without
         manual vsmt setting) will break.  Since TCG is rarely used in production
         I think this is worth it for the other benefits.  It does also remove
         one more barrier to TCG<->KVM migration which could be interesting for
         debugging applications.
      
      KVM PR:
         As with TCG, this will break migration of existing configurations,
         without adding extra manual vsmt options.  As with TCG, it is rare in
         production so I think the benefits outweigh breakages.
      Signed-off-by: 's avatarDavid Gibson <david@gibson.dropbear.id.au>
      Reviewed-by: 's avatarLaurent Vivier <lvivier@redhat.com>
      Reviewed-by: 's avatarJose Ricardo Ziviani <joserz@linux.vnet.ibm.com>
      Reviewed-by: 's avatarGreg Kurz <groug@kaod.org>
      8904e5a7
    • David Gibson's avatar
      spapr: Allow some cases where we can't set VSMT mode in the kernel · 1f20f2e0
      David Gibson authored
      At present if we require a vsmt mode that's not equal to the kernel's
      default, and the kernel doesn't let us change it (e.g. because it's an old
      kernel without support) then we always fail.
      
      But in fact we can cope with the kernel having a different vsmt as long as
        a) it's >= the actual number of vthreads/vcore (so that guest threads
           that are supposed to be on the same core act like it)
        b) it's a submultiple of the requested vsmt mode (so that guest threads
           spaced by the vsmt value will act like they're on different cores)
      
      Allowing this case gives us a bit more freedom to adjust the vsmt behaviour
      without breaking existing cases.
      Signed-off-by: 's avatarDavid Gibson <david@gibson.dropbear.id.au>
      Reviewed-by: 's avatarLaurent Vivier <lvivier@redhat.com>
      Tested-by: 's avatarGreg Kurz <groug@kaod.org>
      Reviewed-by: 's avatarGreg Kurz <groug@kaod.org>
      1f20f2e0
    • David Gibson's avatar
      target/ppc: Clarify compat mode max_threads value · abbc1247
      David Gibson authored
      We recently had some discussions that were sidetracked for a while, because
      nearly everyone misapprehended the purpose of the 'max_threads' field in
      the compatiblity modes table.  It's all about guest expectations, not host
      expectations or support (that's handled elsewhere).
      
      In an attempt to avoid a repeat of that confusion, rename the field to
      'max_vthreads' and add an explanatory comment.
      Signed-off-by: 's avatarDavid Gibson <david@gibson.dropbear.id.au>
      Reviewed-by: 's avatarLaurent Vivier <lvivier@redhat.com>
      Reviewed-by: 's avatarGreg Kurz <groug@kaod.org>
      Reviewed-by: 's avatarJose Ricardo Ziviani <joserz@linux.vnet.ibm.com>
      abbc1247
    • Jose Ricardo Ziviani's avatar
      ppc: Change Power9 compat table to support at most 8 threads/core · 03ee51d3
      Jose Ricardo Ziviani authored
      Increases the max smt mode to 8 for Power9. That's because KVM supports
      smt emulation in this platform so QEMU should allow users to use it as
      well.
      
      Today if we try to pass -smp ...,threads=8, QEMU will silently truncate
      it to smt4 mode and may cause a crash if we try to perform a cpu
      hotplug.
      Signed-off-by: 's avatarJose Ricardo Ziviani <joserz@linux.vnet.ibm.com>
      [dwg: Added an explanatory comment]
      Signed-off-by: 's avatarDavid Gibson <david@gibson.dropbear.id.au>
      03ee51d3
    • David Gibson's avatar
      spapr: Remove unnecessary 'options' field from sPAPRCapabilityInfo · 895d5cd6
      David Gibson authored
      The options field here is intended to list the available values for the
      capability.  It's not used yet, because the existing capabilities are
      boolean.
      
      We're going to add capabilities that aren't, but in that case the info on
      the possible values can be folded into the .description field.
      Signed-off-by: 's avatarDavid Gibson <david@gibson.dropbear.id.au>
      895d5cd6
    • Suraj Jitindar Singh's avatar
      hw/ppc/spapr_caps: Rework spapr_caps to use uint8 internal representation · 4e5fe368
      Suraj Jitindar Singh authored
      Currently spapr_caps are tied to boolean values (on or off). This patch
      reworks the caps so that they can have any uint8 value. This allows more
      capabilities with various values to be represented in the same way
      internally. Capabilities are numbered in ascending order. The internal
      representation of capability values is an array of uint8s in the
      sPAPRMachineState, indexed by capability number.
      
      Capabilities can have their own name, description, options, getter and
      setter functions, type and allow functions. They also each have their own
      section in the migration stream. Capabilities are only migrated if they
      were explictly set on the command line, with the assumption that
      otherwise the default will match.
      
      On migration we ensure that the capability value on the destination
      is greater than or equal to the capability value from the source. So
      long at this remains the case then the migration is considered
      compatible and allowed to continue.
      
      This patch implements generic getter and setter functions for boolean
      capabilities. It also converts the existings cap-htm, cap-vsx and
      cap-dfp capabilities to this new format.
      Signed-off-by: 's avatarDavid Gibson <david@gibson.dropbear.id.au>
      4e5fe368
    • David Gibson's avatar
      spapr: Handle Decimal Floating Point (DFP) as an optional capability · 2d1fb9bc
      David Gibson authored
      Decimal Floating Point has been available on POWER7 and later (server)
      cpus.  However, it can be disabled on the hypervisor, meaning that it's
      not available to guests.
      
      We currently handle this by conditionally advertising DFP support in the
      device tree depending on whether the guest CPU model supports it - which
      can also depend on what's allowed in the host for -cpu host.  That can lead
      to confusion on migration, since host properties are silently affecting
      guest visible properties.
      
      This patch handles it by treating it as an optional capability for the
      pseries machine type.
      Signed-off-by: 's avatarDavid Gibson <david@gibson.dropbear.id.au>
      Reviewed-by: 's avatarGreg Kurz <groug@kaod.org>
      2d1fb9bc
    • David Gibson's avatar
      spapr: Handle VMX/VSX presence as an spapr capability flag · 29386642
      David Gibson authored
      We currently have some conditionals in the spapr device tree code to decide
      whether or not to advertise the availability of the VMX (aka Altivec) and
      VSX vector extensions to the guest, based on whether the guest cpu has
      those features.
      
      This can lead to confusion and subtle failures on migration, since it makes
      a guest visible change based only on host capabilities.  We now have a
      better mechanism for this, in spapr capabilities flags, which explicitly
      depend on user options rather than host capabilities.
      
      Rework the advertisement of VSX and VMX based on a new VSX capability.  We
      no longer bother with a conditional for VMX support, because every CPU
      that's ever been supported by the pseries machine type supports VMX.
      
      NOTE: Some userspace distributions (e.g. RHEL7.4) already rely on
      availability of VSX in libc, so using cap-vsx=off may lead to a fatal
      SIGILL in init.
      Signed-off-by: 's avatarDavid Gibson <david@gibson.dropbear.id.au>
      Reviewed-by: 's avatarGreg Kurz <groug@kaod.org>
      29386642