1. 08 Oct, 2018 1 commit
  2. 05 Oct, 2018 3 commits
  3. 28 Sep, 2018 16 commits
  4. 26 Sep, 2018 10 commits
    • Tony Krowiak's avatar
      KVM: s390: interface to clear CRYCB masks · 42104598
      Tony Krowiak authored
      Introduces a new KVM function to clear the APCB0 and APCB1 in the guest's
      CRYCB. This effectively clears all bits of the APM, AQM and ADM masks
      configured for the guest. The VCPUs are taken out of SIE to ensure the
      VCPUs do not get out of sync.
      Signed-off-by: default avatarTony Krowiak <akrowiak@linux.ibm.com>
      Acked-by: default avatarHalil Pasic <pasic@linux.ibm.com>
      Tested-by: default avatarMichael Mueller <mimu@linux.ibm.com>
      Tested-by: default avatarFarhan Ali <alifm@linux.ibm.com>
      Tested-by: default avatarPierre Morel <pmorel@linux.ibm.com>
      Reviewed-by: default avatarCornelia Huck <cohuck@redhat.com>
      Message-Id: <20180925231641.4954-11-akrowiak@linux.vnet.ibm.com>
      Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      42104598
    • Tony Krowiak's avatar
      s390: vfio-ap: sysfs interface to view matrix mdev matrix · 81b2b4b7
      Tony Krowiak authored
      Provides a sysfs interface to view the AP matrix configured for the
      mediated matrix device.
      
      The relevant sysfs structures are:
      
      /sys/devices/vfio_ap/matrix/
      ...... [mdev_supported_types]
      ......... [vfio_ap-passthrough]
      ............ [devices]
      ...............[$uuid]
      .................. matrix
      
      To view the matrix configured for the mediated matrix device,
      print the matrix file:
      
      	cat matrix
      
      Below are examples of the output from the above command:
      
      Example 1: Adapters and domains assigned
      	Assignments:
      		Adapters 5 and 6
      		Domains 4 and 71 (0x47)
      
      	Output
      		05.0004
      		05.0047
      		06.0004
      	06.0047
      
      Examples 2: Only adapters assigned
      	Assignments:
      		Adapters 5 and 6
      
      	Output:
      		05.
      		06.
      
      Examples 3: Only domains assigned
      	Assignments:
      		Domains 4 and 71 (0x47)
      
      	Output:
      		.0004
      		.0047
      Signed-off-by: default avatarTony Krowiak <akrowiak@linux.ibm.com>
      Reviewed-by: default avatarHalil Pasic <pasic@linux.ibm.com>
      Reviewed-by: default avatarCornelia Huck <cohuck@redhat.com>
      Tested-by: default avatarMichael Mueller <mimu@linux.ibm.com>
      Tested-by: default avatarFarhan Ali <alifm@linux.ibm.com>
      Tested-by: default avatarPierre Morel <pmorel@linux.ibm.com>
      Message-Id: <20180925231641.4954-10-akrowiak@linux.vnet.ibm.com>
      Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      81b2b4b7
    • Tony Krowiak's avatar
      s390: vfio-ap: sysfs interfaces to configure control domains · 3b1eab7f
      Tony Krowiak authored
      Provides the sysfs interfaces for:
      
      1. Assigning AP control domains to the mediated matrix device
      
      2. Unassigning AP control domains from a mediated matrix device
      
      3. Displaying the control domains assigned to a mediated matrix
         device
      
      The IDs of the AP control domains assigned to the mediated matrix
      device are stored in an AP domain mask (ADM). The bits in the ADM,
      from most significant to least significant bit, correspond to
      AP domain numbers 0 to 255. On some systems, the maximum allowable
      domain number may be less than 255 - depending upon the host's
      AP configuration - and assignment may be rejected if the input
      domain ID exceeds the limit.
      
      When a control domain is assigned, the bit corresponding its domain
      ID will be set in the ADM. Likewise, when a domain is unassigned,
      the bit corresponding to its domain ID will be cleared in the ADM.
      
      The relevant sysfs structures are:
      
      /sys/devices/vfio_ap/matrix/
      ...... [mdev_supported_types]
      ......... [vfio_ap-passthrough]
      ............ [devices]
      ...............[$uuid]
      .................. assign_control_domain
      .................. unassign_control_domain
      
      To assign a control domain to the $uuid mediated matrix device's
      ADM, write its domain number to the assign_control_domain file.
      To unassign a domain, write its domain number to the
      unassign_control_domain file. The domain number is specified
      using conventional semantics: If it begins with 0x the number
      will be parsed as a hexadecimal (case insensitive) number;
      if it begins with 0, it is parsed as an octal number;
      otherwise, it will be parsed as a decimal number.
      
      For example, to assign control domain 173 (0xad) to the mediated
      matrix device $uuid:
      
      	echo 173 > assign_control_domain
      
      	or
      
      	echo 0255 > assign_control_domain
      
      	or
      
      	echo 0xad > assign_control_domain
      
      To unassign control domain 173 (0xad):
      
      	echo 173 > unassign_control_domain
      
      	or
      
      	echo 0255 > unassign_control_domain
      
      	or
      
      	echo 0xad > unassign_control_domain
      
      The assignment will be rejected if the APQI exceeds the maximum
      value for an AP domain:
        * If the AP Extended Addressing (APXA) facility is installed,
          the max value is 255
        * Else the max value is 15
      Signed-off-by: default avatarTony Krowiak <akrowiak@linux.ibm.com>
      Reviewed-by: default avatarHalil Pasic <pasic@linux.ibm.com>
      Reviewed-by: default avatarCornelia Huck <cohuck@redhat.com>
      Tested-by: default avatarMichael Mueller <mimu@linux.ibm.com>
      Tested-by: default avatarFarhan Ali <alifm@linux.ibm.com>
      Tested-by: default avatarPierre Morel <pmorel@linux.ibm.com>
      Message-Id: <20180925231641.4954-9-akrowiak@linux.vnet.ibm.com>
      Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      3b1eab7f
    • Tony Krowiak's avatar
      s390: vfio-ap: sysfs interfaces to configure domains · 3211da0c
      Tony Krowiak authored
      Introduces two new sysfs attributes for the VFIO mediated
      matrix device for assigning AP domains to and unassigning
      AP domains from a mediated matrix device. The IDs of the
      AP domains assigned to the mediated matrix device will be
      stored in an AP queue mask (AQM).
      
      The bits in the AQM, from most significant to least
      significant bit, correspond to AP queue index (APQI) 0 to
      255 (note that an APQI is synonymous with with a domain ID).
      On some systems, the maximum allowable domain number may be
      less than 255 - depending upon the host's AP configuration -
      and assignment may be rejected if the input domain ID exceeds
      the limit.
      
      When a domain is assigned, the bit corresponding to the APQI
      will be set in the AQM. Likewise, when a domain is unassigned,
      the bit corresponding to the APQI will be cleared from the AQM.
      
      In order to successfully assign a domain, the APQNs derived from
      the domain ID being assigned and the adapter numbers of all
      adapters previously assigned:
      
      1. Must be bound to the vfio_ap device driver.
      
      2. Must not be assigned to any other mediated matrix device.
      
      If there are no adapters assigned to the mdev, then there must
      be an AP queue bound to the vfio_ap device driver with an
      APQN containing the domain ID (i.e., APQI), otherwise all
      adapters subsequently assigned will fail because there will be no
      AP queues bound with an APQN containing the APQI.
      
      Assigning or un-assigning an AP domain will also be rejected if
      a guest using the mediated matrix device is running.
      
      The relevant sysfs structures are:
      
      /sys/devices/vfio_ap/matrix/
      ...... [mdev_supported_types]
      ......... [vfio_ap-passthrough]
      ............ [devices]
      ...............[$uuid]
      .................. assign_domain
      .................. unassign_domain
      
      To assign a domain to the $uuid mediated matrix device,
      write the domain's ID to the assign_domain file. To
      unassign a domain, write the domain's ID to the
      unassign_domain file. The ID is specified using
      conventional semantics: If it begins with 0x, the number
      will be parsed as a hexadecimal (case insensitive) number;
      if it begins with 0, it will be parsed as an octal number;
      otherwise, it will be parsed as a decimal number.
      
      For example, to assign domain 173 (0xad) to the mediated matrix
      device $uuid:
      
      	echo 173 > assign_domain
      
      	or
      
      	echo 0255 > assign_domain
      
      	or
      
      	echo 0xad > assign_domain
      
      To unassign domain 173 (0xad):
      
      	echo 173 > unassign_domain
      
      	or
      
      	echo 0255 > unassign_domain
      
      	or
      
      	echo 0xad > unassign_domain
      Signed-off-by: default avatarTony Krowiak <akrowiak@linux.ibm.com>
      Reviewed-by: default avatarHalil Pasic <pasic@linux.ibm.com>
      Reviewed-by: default avatarCornelia Huck <cohuck@redhat.com>
      Tested-by: default avatarMichael Mueller <mimu@linux.ibm.com>
      Tested-by: default avatarFarhan Ali <alifm@linux.ibm.com>
      Tested-by: default avatarPierre Morel <pmorel@linux.ibm.com>
      Message-Id: <20180925231641.4954-8-akrowiak@linux.vnet.ibm.com>
      Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      3211da0c
    • Tony Krowiak's avatar
      s390: vfio-ap: sysfs interfaces to configure adapters · 96d152bd
      Tony Krowiak authored
      Introduces two new sysfs attributes for the VFIO mediated
      matrix device for assigning AP adapters to and unassigning
      AP adapters from a mediated matrix device. The IDs of the
      AP adapters assigned to the mediated matrix device will be
      stored in an AP mask (APM).
      
      The bits in the APM, from most significant to least significant
      bit, correspond to AP adapter IDs (APID) 0 to 255. On
      some systems, the maximum allowable adapter number may be less
      than 255 - depending upon the host's AP configuration - and
      assignment may be rejected if the input adapter ID exceeds the
      limit.
      
      When an adapter is assigned, the bit corresponding to the APID
      will be set in the APM. Likewise, when an adapter is
      unassigned, the bit corresponding to the APID will be cleared
      from the APM.
      
      In order to successfully assign an adapter, the APQNs derived from
      the adapter ID being assigned and the queue indexes of all domains
      previously assigned:
      
      1. Must be bound to the vfio_ap device driver.
      
      2. Must not be assigned to any other mediated matrix device
      
      If there are no domains assigned to the mdev, then there must
      be an AP queue bound to the vfio_ap device driver with an
      APQN containing the APID, otherwise all domains
      subsequently assigned will fail because there will be no
      AP queues bound with an APQN containing the adapter ID.
      
      Assigning or un-assigning an AP adapter will be rejected if
      a guest using the mediated matrix device is running.
      
      The relevant sysfs structures are:
      
      /sys/devices/vfio_ap/matrix/
      ...... [mdev_supported_types]
      ......... [vfio_ap-passthrough]
      ............ [devices]
      ...............[$uuid]
      .................. assign_adapter
      .................. unassign_adapter
      
      To assign an adapter to the $uuid mediated matrix device's APM,
      write the APID to the assign_adapter file. To unassign an adapter,
      write the APID to the unassign_adapter file. The APID is specified
      using conventional semantics: If it begins with 0x the number will
      be parsed as a hexadecimal number; if it begins with a 0 the number
      will be parsed as an octal number; otherwise, it will be parsed as a
      decimal number.
      
      For example, to assign adapter 173 (0xad) to the mediated matrix
      device $uuid:
      
      	echo 173 > assign_adapter
      
      	or
      
      	echo 0xad > assign_adapter
      
      	or
      
      	echo 0255 > assign_adapter
      
      To unassign adapter 173 (0xad):
      
      	echo 173 > unassign_adapter
      
      	or
      
      	echo 0xad > unassign_adapter
      
      	or
      
      	echo 0255 > unassign_adapter
      Signed-off-by: default avatarTony Krowiak <akrowiak@linux.ibm.com>
      Reviewed-by: default avatarHalil Pasic <pasic@linux.ibm.com>
      Tested-by: default avatarMichael Mueller <mimu@linux.ibm.com>
      Tested-by: default avatarFarhan Ali <alifm@linux.ibm.com>
      Tested-by: default avatarPierre Morel <pmorel@linux.ibm.com>
      Reviewed-by: default avatarCornelia Huck <cohuck@redhat.com>
      Message-Id: <20180925231641.4954-7-akrowiak@linux.vnet.ibm.com>
      Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      96d152bd
    • Tony Krowiak's avatar
      s390: vfio-ap: register matrix device with VFIO mdev framework · 65f06713
      Tony Krowiak authored
      Registers the matrix device created by the VFIO AP device
      driver with the VFIO mediated device framework.
      Registering the matrix device will create the sysfs
      structures needed to create mediated matrix devices
      each of which will be used to configure the AP matrix
      for a guest and connect it to the VFIO AP device driver.
      
      Registering the matrix device with the VFIO mediated device
      framework will create the following sysfs structures:
      
      /sys/devices/vfio_ap/matrix/
      ...... [mdev_supported_types]
      ......... [vfio_ap-passthrough]
      ............ create
      
      To create a mediated device for the AP matrix device, write a UUID
      to the create file:
      
      	uuidgen > create
      
      A symbolic link to the mediated device's directory will be created in the
      devices subdirectory named after the generated $uuid:
      
      /sys/devices/vfio_ap/matrix/
      ...... [mdev_supported_types]
      ......... [vfio_ap-passthrough]
      ............ [devices]
      ............... [$uuid]
      
      A symbolic link to the mediated device will also be created
      in the vfio_ap matrix's directory:
      
      /sys/devices/vfio_ap/matrix/[$uuid]
      Signed-off-by: default avatarTony Krowiak <akrowiak@linux.ibm.com>
      Reviewed-by: default avatarHalil Pasic <pasic@linux.ibm.com>
      Reviewed-by: default avatarCornelia Huck <cohuck@redhat.com>
      Tested-by: default avatarMichael Mueller <mimu@linux.ibm.com>
      Tested-by: default avatarFarhan Ali <alifm@linux.ibm.com>
      Message-Id: <20180925231641.4954-6-akrowiak@linux.vnet.ibm.com>
      Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      65f06713
    • Tony Krowiak's avatar
      s390: vfio-ap: base implementation of VFIO AP device driver · 1fde5734
      Tony Krowiak authored
      Introduces a new AP device driver. This device driver
      is built on the VFIO mediated device framework. The framework
      provides sysfs interfaces that facilitate passthrough
      access by guests to devices installed on the linux host.
      
      The VFIO AP device driver will serve two purposes:
      
      1. Provide the interfaces to reserve AP devices for exclusive
         use by KVM guests. This is accomplished by unbinding the
         devices to be reserved for guest usage from the zcrypt
         device driver and binding them to the VFIO AP device driver.
      
      2. Implements the functions, callbacks and sysfs attribute
         interfaces required to create one or more VFIO mediated
         devices each of which will be used to configure the AP
         matrix for a guest and serve as a file descriptor
         for facilitating communication between QEMU and the
         VFIO AP device driver.
      
      When the VFIO AP device driver is initialized:
      
      * It registers with the AP bus for control of type 10 (CEX4
        and newer) AP queue devices. This limitation was imposed
        due to:
      
        1. A desire to keep the code as simple as possible;
      
        2. Some older models are no longer supported by the kernel
           and others are getting close to end of service.
      
        3. A lack of older systems on which to test older devices.
      
        The probe and remove callbacks will be provided to support
        the binding/unbinding of AP queue devices to/from the VFIO
        AP device driver.
      
      * Creates a matrix device, /sys/devices/vfio_ap/matrix,
        to serve as the parent of the mediated devices created, one
        for each guest, and to hold the APQNs of the AP devices bound to
        the VFIO AP device driver.
      Signed-off-by: default avatarTony Krowiak <akrowiak@linux.ibm.com>
      Reviewed-by: default avatarHalil Pasic <pasic@linux.ibm.com>
      Tested-by: default avatarMichael Mueller <mimu@linux.ibm.com>
      Tested-by: default avatarFarhan Ali <alifm@linux.ibm.com>
      Acked-by: default avatarDavid Hildenbrand <david@redhat.com>
      Reviewed-by: default avatarCornelia Huck <cohuck@redhat.com>
      Message-Id: <20180925231641.4954-5-akrowiak@linux.vnet.ibm.com>
      Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      1fde5734
    • Tony Krowiak's avatar
      KVM: s390: refactor crypto initialization · e585b24a
      Tony Krowiak authored
      This patch refactors the code that initializes and sets up the
      crypto configuration for a guest. The following changes are
      implemented via this patch:
      
      1. Introduces a flag indicating AP instructions executed on
         the guest shall be interpreted by the firmware. This flag
         is used to set a bit in the guest's state description
         indicating AP instructions are to be interpreted.
      
      2. Replace code implementing AP interfaces with code supplied
         by the AP bus to query the AP configuration.
      Signed-off-by: default avatarTony Krowiak <akrowiak@linux.ibm.com>
      Reviewed-by: default avatarHalil Pasic <pasic@linux.ibm.com>
      Acked-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Acked-by: default avatarJanosch Frank <frankja@linux.ibm.com>
      Reviewed-by: default avatarCornelia Huck <cohuck@redhat.com>
      Tested-by: default avatarMichael Mueller <mimu@linux.ibm.com>
      Tested-by: default avatarFarhan Ali <alifm@linux.ibm.com>
      Message-Id: <20180925231641.4954-4-akrowiak@linux.vnet.ibm.com>
      Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      e585b24a
    • David Hildenbrand's avatar
      KVM: s390: introduce and use KVM_REQ_VSIE_RESTART · 3194cdb7
      David Hildenbrand authored
      When we change the crycb (or execution controls), we also have to make sure
      that the vSIE shadow datastructures properly consider the changed
      values before rerunning the vSIE. We can achieve that by simply using a
      VCPU request now.
      
      This has to be a synchronous request (== handled before entering the
      (v)SIE again).
      
      The request will make sure that the vSIE handler is left, and that the
      request will be processed (NOP), therefore forcing a reload of all
      vSIE data (including rebuilding the crycb) when re-entering the vSIE
      interception handler the next time.
      Signed-off-by: default avatarDavid Hildenbrand <david@redhat.com>
      Signed-off-by: default avatarTony Krowiak <akrowiak@linux.ibm.com>
      Reviewed-by: default avatarPierre Morel <pmorel@linux.ibm.com>
      Reviewed-by: default avatarCornelia Huck <cohuck@redhat.com>
      Reviewed-by: default avatarJanosch Frank <frankja@linux.ibm.com>
      Reviewed-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Message-Id: <20180925231641.4954-3-akrowiak@linux.vnet.ibm.com>
      Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      3194cdb7
    • David Hildenbrand's avatar
      KVM: s390: vsie: simulate VCPU SIE entry/exit · 9ea59728
      David Hildenbrand authored
      VCPU requests and VCPU blocking right now don't take care of the vSIE
      (as it was not necessary until now). But we want to have synchronous VCPU
      requests that will also be handled before running the vSIE again.
      
      So let's simulate a SIE entry of the VCPU when calling the sie during
      vSIE handling and check for PROG_ flags. The existing infrastructure
      (e.g. exit_sie()) will then detect that the SIE (in form of the vSIE) is
      running and properly kick the vSIE CPU, resulting in it leaving the vSIE
      loop and therefore the vSIE interception handler, allowing it to handle
      VCPU requests.
      
      E.g. if we want to modify the crycb of the VCPU and make sure that any
      masks also get applied to the VSIE crycb shadow (which uses masks from the
      VCPU crycb), we will need a way to hinder the vSIE from running and make
      sure to process the updated crycb before reentering the vSIE again.
      Signed-off-by: default avatarDavid Hildenbrand <david@redhat.com>
      Signed-off-by: default avatarTony Krowiak <akrowiak@linux.ibm.com>
      Reviewed-by: default avatarPierre Morel <pmorel@linux.ibm.com>
      Reviewed-by: default avatarCornelia Huck <cohuck@redhat.com>
      Reviewed-by: default avatarJanosch Frank <frankja@linux.ibm.com>
      Reviewed-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      Message-Id: <20180925231641.4954-2-akrowiak@linux.vnet.ibm.com>
      Signed-off-by: default avatarChristian Borntraeger <borntraeger@de.ibm.com>
      9ea59728
  5. 16 Sep, 2018 2 commits
  6. 15 Sep, 2018 8 commits