1. 16 6月, 2016 1 次提交
    • J
      MIPS: KVM: Add KScratch registers · 05108709
      James Hogan 提交于
      Allow up to 6 KVM guest KScratch registers to be enabled and accessed
      via the KVM guest register API and from the guest itself (the fallback
      reading and writing of commpage registers is sufficient for KScratch
      registers to work as expected).
      
      User mode can expose the registers by setting the appropriate bits of
      the guest Config4.KScrExist field. KScratch registers that aren't usable
      won't be writeable via the KVM Ioctl API.
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: linux-mips@linux-mips.org
      Cc: kvm@vger.kernel.org
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      05108709
  2. 14 6月, 2016 1 次提交
  3. 10 6月, 2016 3 次提交
    • D
      KVM: s390: provide CMMA attributes only if available · f9cbd9b0
      David Hildenbrand 提交于
      Let's not provide the device attribute for cmma enabling and clearing
      if the hardware doesn't support it.
      
      This also helps getting rid of the undocumented return value "-EINVAL"
      in case CMMA is not available when trying to enable it.
      
      Also properly document the meaning of -EINVAL for CMMA clearing.
      Reviewed-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      Signed-off-by: NDavid Hildenbrand <dahi@linux.vnet.ibm.com>
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      f9cbd9b0
    • D
      KVM: s390: interface to query and configure cpu subfunctions · 0a763c78
      David Hildenbrand 提交于
      We have certain instructions that indicate available subfunctions via
      a query subfunction (crypto functions and ptff), or via a test bit
      function (plo).
      
      By exposing these "subfunction blocks" to user space, we allow user space
      to
      1) query available subfunctions and make sure subfunctions won't get lost
         during migration - e.g. properly indicate them via a CPU model
      2) change the subfunctions to be reported to the guest (even adding
         unavailable ones)
      
      This mechanism works just like the way we indicate the stfl(e) list to
      user space.
      
      This way, user space could even emulate some subfunctions in QEMU in the
      future. If this is ever applicable, we have to make sure later on, that
      unsupported subfunctions result in an intercept to QEMU.
      
      Please note that support to indicate them to the guest is still missing
      and requires hardware support. Usually, the IBC takes already care of these
      subfunctions for migration safety. QEMU should make sure to always set
      these bits properly according to the machine generation to be emulated.
      
      Available subfunctions are only valid in combination with STFLE bits
      retrieved via KVM_S390_VM_CPU_MACHINE and enabled via
      KVM_S390_VM_CPU_PROCESSOR. If the applicable bits are available, the
      indicated subfunctions are guaranteed to be correct.
      Signed-off-by: NDavid Hildenbrand <dahi@linux.vnet.ibm.com>
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      0a763c78
    • D
      KVM: s390: interface to query and configure cpu features · 15c9705f
      David Hildenbrand 提交于
      For now, we only have an interface to query and configure facilities
      indicated via STFL(E). However, we also have features indicated via
      SCLP, that have to be indicated to the guest by user space and usually
      require KVM support.
      
      This patch allows user space to query and configure available cpu features
      for the guest.
      
      Please note that disabling a feature doesn't necessarily mean that it is
      completely disabled (e.g. ESOP is mostly handled by the SIE). We will try
      our best to disable it.
      
      Most features (e.g. SCLP) can't directly be forwarded, as most of them need
      in addition to hardware support, support in KVM. As we later on want to
      turn these features in KVM explicitly on/off (to simulate different
      behavior), we have to filter all features provided by the hardware and
      make them configurable.
      Signed-off-by: NDavid Hildenbrand <dahi@linux.vnet.ibm.com>
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      15c9705f
  4. 01 6月, 2016 1 次提交
  5. 30 5月, 2016 1 次提交
  6. 28 5月, 2016 9 次提交
  7. 27 5月, 2016 2 次提交
    • M
      ovl: update documentation · 942fd803
      Miklos Szeredi 提交于
      Two "fixme" items are actually fixed now.
      Signed-off-by: NMiklos Szeredi <mszeredi@redhat.com>
      942fd803
    • C
      IB/core: Make device counter infrastructure dynamic · b40f4757
      Christoph Lameter 提交于
      In practice, each RDMA device has a unique set of counters that the
      hardware implements.  Having a central set of counters that they must
      all adhere to is limiting and causes many useful counters to not be
      available.
      
      Therefore we create a dynamic counter registration infrastructure.
      
      The driver must implement a stats structure allocation routine, in
      which the driver must place the directory name it wants, a list of
      names for all of the counters, an array of u64 counters themselves,
      plus a few generic configuration options.
      
      We then implement a core routine to create a sysfs file for each
      of the named stats elements, and a core routine to retrieve the
      stats when any of the sysfs attribute files are read.
      
      To avoid excessive beating on the stats generation routine in the
      drivers, the core code also caches the stats for a short period of
      time so that someone attempting to read all of the stats in a
      given device's directory will not result in a stats generation
      call per file read.
      
      Future work will attempt to standardize just the shared stats
      elements, and possibly add a method to get the stats via netlink
      in addition to sysfs.
      Signed-off-by: NChristoph Lameter <cl@linux.com>
      Signed-off-by: NMark Bloch <markb@mellanox.com>
      Reviewed-by: NSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      [ Add caching, make structure names more informative, add i40iw support,
        other significant rewrites from the original patch ]
      b40f4757
  8. 26 5月, 2016 6 次提交
  9. 24 5月, 2016 4 次提交
  10. 23 5月, 2016 1 次提交
    • V
      drm: Add helper for DP++ adaptors · b3daa5ef
      Ville Syrjälä 提交于
      Add a helper which aids in the identification of DP dual mode
      (aka. DP++) adaptors. There are several types of adaptors
      specified: type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI
      
      Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2 adaptors
      may go as high as 300MHz and they provide a register informing the
      source device what the actual limit is. Supposedly also type 1 adaptors
      may optionally implement this register. This TMDS clock limit is the
      main reason why we need to identify these adaptors.
      
      Type 1 adaptors provide access to their internal registers and the sink
      DDC bus through I2C. Type 2 adaptors provide this access both via I2C
      and I2C-over-AUX. A type 2 source device may choose to implement either
      of these methods. If a source device implements the I2C-over-AUX
      method, then the driver will obviously need specific support for such
      adaptors since the port is driven like an HDMI port, but DDC
      communication happes over the AUX channel.
      
      This helper should be enough to identify the adaptor type (some
      type 1 DVI adaptors may be a slight exception) and the maximum TMDS
      clock limit. Another feature that may be available is control over
      the TMDS output buffers on the adaptor, possibly allowing for some
      power saving when the TMDS link is down.
      
      Other user controllable features that may be available in the adaptors
      are downstream i2c bus speed control when using i2c-over-aux, and
      some control over the CEC pin. I chose not to provide any helper
      functions for those since I have no use for them in i915 at this time.
      The rest of the registers in the adaptor are mostly just information,
      eg. IEEE OUI, hardware and firmware revision, etc.
      
      v2: Pass adaptor type to helper functions to ease driver implementation
          Fix a bunch of typoes (Paulo)
          Add DRM_DP_DUAL_MODE_UNKNOWN for the case where we don't (yet) know
          the type (Paulo)
          Reject 0x00 and 0xff DP_DUAL_MODE_MAX_TMDS_CLOCK values (Paulo)
          Adjust drm_dp_dual_mode_detect() type2 vs. type1 detection to
          ease future LSPCON enabling
          Remove the unused DP_DUAL_MODE_LAST_RESERVED define
      v3: Fix kernel doc function argument descriptions (Jani)
          s/NONE/UNKNOWN/ in drm_dp_dual_mode_detect() docs
          Add kernel doc for enum drm_dp_dual_mode_type
          Actually build the docs
          Fix more typoes
      v4: Adjust code indentation of type2 adaptor detection (Shashank)
          Add debug messages for failurs cases (Shashank)
      v5: EXPORT_SYMBOL(drm_dp_dual_mode_read) (Paulo)
      
      Cc: stable@vger.kernel.org
      Cc: Tore Anderson <tore@fud.no>
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: Shashank Sharma <shashank.sharma@intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Shashank Sharma <shashank.sharma@intel.com>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> (v4)
      Link: http://patchwork.freedesktop.org/patch/msgid/1462542412-25533-1-git-send-email-ville.syrjala@linux.intel.com
      (cherry picked from commit ede53344)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      b3daa5ef
  11. 21 5月, 2016 6 次提交
  12. 20 5月, 2016 5 次提交
    • G
    • S
      rtc: ds1302: rewrite using SPI · d25a5ed3
      Sergey Yanovich 提交于
      DS1302 is an half-duplex SPI device. The driver respects this fact now.
      Pin configurations should be implemented using SPI subsystem.
      Signed-off-by: NSergei Ianovich <ynvich@gmail.com>
      Acked-by: NRob Herring <robh@kernel.org>
      Signed-off-by: NAlexandre Belloni <alexandre.belloni@free-electrons.com>
      d25a5ed3
    • V
      memory_hotplug: introduce memhp_default_state= command line parameter · 86dd995d
      Vitaly Kuznetsov 提交于
      CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE specifies the default value for the
      memory hotplug onlining policy.  Add a command line parameter to make it
      possible to override the default.  It may come handy for debug and
      testing purposes.
      Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Igor Mammedov <imammedo@redhat.com>
      Cc: Lennart Poettering <lennart@poettering.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      86dd995d
    • V
      memory_hotplug: introduce CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE · 8604d9e5
      Vitaly Kuznetsov 提交于
      This patchset continues the work I started with commit 31bc3858
      ("memory-hotplug: add automatic onlining policy for the newly added
      memory").
      
      Initially I was going to stop there and bring the policy setting logic
      to userspace.  I met two issues on this way:
      
       1) It is possible to have memory hotplugged at boot (e.g.  with QEMU).
          These blocks stay offlined if we turn the onlining policy on by
          userspace.
      
       2) My attempt to bring this policy setting to systemd failed, systemd
          maintainers suggest to change the default in kernel or ...  to use
          tmpfiles.d to alter the policy (which looks like a hack to me):
              https://github.com/systemd/systemd/pull/2938
      
      Here I suggest to add a config option to set the default value for the
      policy and a kernel command line parameter to make the override.
      
      This patch (of 2):
      
      Introduce config option to set the default value for memory hotplug
      onlining policy (/sys/devices/system/memory/auto_online_blocks).  The
      reason one would want to turn this option on are to have early onlining
      for hotpluggable memory available at boot and to not require any
      userspace actions to make memory hotplug work.
      
      [akpm@linux-foundation.org: tweak Kconfig text]
      Signed-off-by: NVitaly Kuznetsov <vkuznets@redhat.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: David Vrabel <david.vrabel@citrix.com>
      Cc: David Rientjes <rientjes@google.com>
      Cc: Igor Mammedov <imammedo@redhat.com>
      Cc: Lennart Poettering <lennart@poettering.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8604d9e5
    • H
      mm: /proc/sys/vm/stat_refresh to force vmstat update · 52b6f46b
      Hugh Dickins 提交于
      Provide /proc/sys/vm/stat_refresh to force an immediate update of
      per-cpu into global vmstats: useful to avoid a sleep(2) or whatever
      before checking counts when testing.  Originally added to work around a
      bug which left counts stranded indefinitely on a cpu going idle (an
      inaccuracy magnified when small below-batch numbers represent "huge"
      amounts of memory), but I believe that bug is now fixed: nonetheless,
      this is still a useful knob.
      
      Its schedule_on_each_cpu() is probably too expensive just to fold into
      reading /proc/meminfo itself: give this mode 0600 to prevent abuse.
      Allow a write or a read to do the same: nothing to read, but "grep -h
      Shmem /proc/sys/vm/stat_refresh /proc/meminfo" is convenient.  Oh, and
      since global_page_state() itself is careful to disguise any underflow as
      0, hack in an "Invalid argument" and pr_warn() if a counter is negative
      after the refresh - this helped to fix a misaccounting of
      NR_ISOLATED_FILE in my migration code.
      
      But on recent kernels, I find that NR_ALLOC_BATCH and NR_PAGES_SCANNED
      often go negative some of the time.  I have not yet worked out why, but
      have no evidence that it's actually harmful.  Punt for the moment by
      just ignoring the anomaly on those.
      Signed-off-by: NHugh Dickins <hughd@google.com>
      Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Andres Lagar-Cavilla <andreslc@google.com>
      Cc: Yang Shi <yang.shi@linaro.org>
      Cc: Ning Qu <quning@gmail.com>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: Andres Lagar-Cavilla <andreslc@google.com>
      Cc: Konstantin Khlebnikov <koct9i@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      52b6f46b