1. 14 12月, 2016 1 次提交
  2. 30 11月, 2016 1 次提交
    • F
      tcp: SOF_TIMESTAMPING_OPT_STATS option for SO_TIMESTAMPING · 1c885808
      Francis Yan 提交于
      This patch exports the sender chronograph stats via the socket
      SO_TIMESTAMPING channel. Currently we can instrument how long a
      particular application unit of data was queued in TCP by tracking
      SOF_TIMESTAMPING_TX_SOFTWARE and SOF_TIMESTAMPING_TX_SCHED. Having
      these sender chronograph stats exported simultaneously along with
      these timestamps allow further breaking down the various sender
      limitation.  For example, a video server can tell if a particular
      chunk of video on a connection takes a long time to deliver because
      TCP was experiencing small receive window. It is not possible to
      tell before this patch without packet traces.
      
      To prepare these stats, the user needs to set
      SOF_TIMESTAMPING_OPT_STATS and SOF_TIMESTAMPING_OPT_TSONLY flags
      while requesting other SOF_TIMESTAMPING TX timestamps. When the
      timestamps are available in the error queue, the stats are returned
      in a separate control message of type SCM_TIMESTAMPING_OPT_STATS,
      in a list of TLVs (struct nlattr) of types: TCP_NLA_BUSY_TIME,
      TCP_NLA_RWND_LIMITED, TCP_NLA_SNDBUF_LIMITED. Unit is microsecond.
      Signed-off-by: NFrancis Yan <francisyyan@gmail.com>
      Signed-off-by: NYuchung Cheng <ycheng@google.com>
      Signed-off-by: NSoheil Hassas Yeganeh <soheil@google.com>
      Acked-by: NNeal Cardwell <ncardwell@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1c885808
  3. 29 11月, 2016 2 次提交
  4. 20 9月, 2016 1 次提交
  5. 31 7月, 2016 1 次提交
    • J
      s390: Define AT_VECTOR_SIZE_ARCH for ARCH_DLINFO · 68c5cf5a
      James Hogan 提交于
      AT_VECTOR_SIZE_ARCH should be defined with the maximum number of
      NEW_AUX_ENT entries that ARCH_DLINFO can contain, but it wasn't defined
      for s390 at all even though ARCH_DLINFO can contain one NEW_AUX_ENT when
      VDSO is enabled.
      
      This shouldn't be a problem as AT_VECTOR_SIZE_BASE includes space for
      AT_BASE_PLATFORM which s390 doesn't use, but lets define it now and add
      the comment above ARCH_DLINFO as found in several other architectures to
      remind future modifiers of ARCH_DLINFO to keep AT_VECTOR_SIZE_ARCH up to
      date.
      
      Fixes: b020632e ("[S390] introduce vdso on s390")
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: linux-s390@vger.kernel.org
      68c5cf5a
  6. 28 6月, 2016 1 次提交
  7. 21 6月, 2016 9 次提交
  8. 10 6月, 2016 4 次提交
    • 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: forward ESOP if available · 22be5a13
      David Hildenbrand 提交于
      ESOP guarantees that during a protection exception, bit 61 of real location
      168-175 will only be set to 1 if it was because of ALCP or DATP. If the
      exception is due to LAP or KCP, the bit will always be set to 0.
      
      The old SOP definition allowed bit 61 to be unpredictable in case of LAP
      or KCP in some conditions. So ESOP replaces this unpredictability by
      a guarantee.
      
      Therefore, we can directly forward ESOP if it is available on our machine.
      We don't have to do anything when ESOP is disabled - the guest will simply
      expect unpredictable values. Our guest access functions are already
      handling ESOP properly.
      
      Please note that future functionality in KVM will require knowledge about
      ESOP being enabled for a guest or not.
      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>
      22be5a13
    • 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
    • J
      KVM: s390: Add sthyi emulation · 95ca2cb5
      Janosch Frank 提交于
      Store Hypervisor Information is an emulated z/VM instruction that
      provides a guest with basic information about the layers it is running
      on. This includes information about the cpu configuration of both the
      machine and the lpar, as well as their names, machine model and
      machine type. This information enables an application to determine the
      maximum capacity of CPs and IFLs available to software.
      
      The instruction is available whenever the facility bit 74 is set,
      otherwise executing it results in an operation exception.
      
      It is important to check the validity flags in the sections before
      using data from any structure member. It is not guaranteed that all
      members will be valid on all machines / machine configurations.
      Signed-off-by: NJanosch Frank <frankja@linux.vnet.ibm.com>
      Reviewed-by: NDavid Hildenbrand <dahi@linux.vnet.ibm.com>
      Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
      95ca2cb5
  9. 20 4月, 2016 2 次提交
  10. 16 4月, 2016 1 次提交
  11. 01 4月, 2016 1 次提交
  12. 08 3月, 2016 1 次提交
  13. 07 3月, 2016 1 次提交
  14. 26 2月, 2016 1 次提交
    • T
      net: Facility to report route quality of connected sockets · a87cb3e4
      Tom Herbert 提交于
      This patch add the SO_CNX_ADVICE socket option (setsockopt only). The
      purpose is to allow an application to give feedback to the kernel about
      the quality of the network path for a connected socket. The value
      argument indicates the type of quality report. For this initial patch
      the only supported advice is a value of 1 which indicates "bad path,
      please reroute"-- the action taken by the kernel is to call
      dst_negative_advice which will attempt to choose a different ECMP route,
      reset the TX hash for flow label and UDP source port in encapsulation,
      etc.
      
      This facility should be useful for connected UDP sockets where only the
      application can provide any feedback about path quality. It could also
      be useful for TCP applications that have additional knowledge about the
      path outside of the normal TCP control loop.
      Signed-off-by: NTom Herbert <tom@herbertland.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a87cb3e4
  15. 10 2月, 2016 1 次提交
  16. 19 1月, 2016 1 次提交
  17. 07 1月, 2016 1 次提交
  18. 05 1月, 2016 1 次提交
  19. 16 12月, 2015 1 次提交
  20. 16 11月, 2015 1 次提交
  21. 09 11月, 2015 1 次提交
  22. 18 9月, 2015 1 次提交
  23. 17 9月, 2015 2 次提交
  24. 04 8月, 2015 1 次提交
  25. 06 3月, 2015 2 次提交