6.4.0 z/VM TCPIP looping/consuming excessive CPU

CP APAR VM66079 corrects a problem in release 6.4.0 CP code that can result in the z/VM TCPIP guest getting into a hot I/O loop where it is processing endless adapter interruptions and consuming excessive amounts of CPU.

APAR VM66079 is available for Release 6.4.0 as PTF UM35233.

Here is the APAR closing text for VM66079, which provides detailed information about this fix:

  ****************************************************************
  * USERS AFFECTED: All customers using the z/VM TCPIP Stack     *
  *                 configured with both QDIO and non-QDIO       *
  *                 network connections.                         *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  ****************************************************************
  Unlike Linux and a z/OS guest, z/VM's TCPIP Stack configures
  both subchannel and adapter I/O interruptions using the same
  priority.  This means both hardware and z/VM interruption
  reflection will insure no one interruption type will lock out
  the other.  It's in this logic where z/VM's I/O interruption
  reflection can get into a state constantly presenting an
  adapter interruption to the z/VM TCPIP Stack.  Once in this
  state, the guest remains in this hot I/O condition, causing
  the guest to consume an excessive amount of the CPU.
 
  CONCLUSION:
  z/VM's I/O interruption logic insures equal reflection of both
  subchannel and adapter interruptions occurring on the same
  interruption subclass (ISC).  This is achieved by alternating
  the reflection of the two interruption types.  First
  reflecting a subchannel interruption with a I/O PSW swap,
  followed by an adapter interruption, the next time the guest
  enables for an I/O interruption.
 
  If both an adapter and subchannel interruption are
  simultaneously pending on the same ISC, z/VM will queue an
  adapter interruption behind the subchannel interruption on its
  internal ISC queue.  Queuing the adapter interruption insures
  z/VM alternates between subchannel and adapter interruption
  reflection.  It is this additional queuing, which can
  potentially cause z/VM to get into a hot I/O situation.
 
  Once z/VM gets into a state where it had to queue an adapter
  interruption and then addition subchannel interruptions
  arrived, the z/VM logic which removes a queued interruption
  may cause a hot I/O condition.  If this logic removes the
  pending interruption when there is a pending adapter
  interruption in hardware, it queues another adapter
  interruption to insure fairness.
 
  The logic assumes a pending interrupt removed from its
  internal ISC queue is always for a subchannel interruption.
  If an adapter interruption was removed from the queue, the
  failing logic in this case ends up queueing another adapter
  interruption, causing the hot I/O condition for the guest.
 
  The logic is changed to make it sensitive to the type of
  interruption removed from the queue.  If an adapter
  interruption is removed from the queue, the logic will not
  queue another adapter interruption when there is a pending
  hardware interruption.  The adapter interruption is merged
  with the one pending in the hardware and a single adapter
  interruption is reflected to the guest.