[Qemu-devel] [PATCH v9 0/6] s390x: vfio-ap: guest dedicated crypto adapters

Tony Krowiak posted 6 patches 5 years, 6 months ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20180926225440.6204-1-akrowiak@linux.vnet.ibm.com
Test docker-clang@ubuntu failed
Test checkpatch failed
There is a newer version of this series
MAINTAINERS                       |  14 +
default-configs/s390x-softmmu.mak |   1 +
docs/vfio-ap.txt                  | 787 ++++++++++++++++++++++++++++++
hw/s390x/Makefile.objs            |   2 +
hw/s390x/ap-bridge.c              |  81 +++
hw/s390x/ap-device.c              |  39 ++
hw/s390x/s390-virtio-ccw.c        |   4 +
hw/vfio/Makefile.objs             |   1 +
hw/vfio/ap.c                      | 181 +++++++
include/hw/s390x/ap-bridge.h      |  37 ++
include/hw/s390x/ap-device.h      |  38 ++
include/hw/vfio/vfio-common.h     |   1 +
linux-headers/asm-s390/kvm.h      |   3 +
linux-headers/linux/vfio.h        |   2 +
target/s390x/cpu_features.c       |   3 +
target/s390x/cpu_features_def.h   |   3 +
target/s390x/cpu_models.c         |   2 +
target/s390x/gen-features.c       |   3 +
target/s390x/kvm.c                |  19 +
19 files changed, 1221 insertions(+)
create mode 100644 docs/vfio-ap.txt
create mode 100644 hw/s390x/ap-bridge.c
create mode 100644 hw/s390x/ap-device.c
create mode 100644 hw/vfio/ap.c
create mode 100644 include/hw/s390x/ap-bridge.h
create mode 100644 include/hw/s390x/ap-device.h
[Qemu-devel] [PATCH v9 0/6] s390x: vfio-ap: guest dedicated crypto adapters
Posted by Tony Krowiak 5 years, 6 months ago
From: Tony Krowiak <akrowiak@linux.ibm.com>

This patch series is the QEMU counterpart to the KVM/kernel support for 
guest dedicated crypto adapters. The KVM/kernel model is built on the 
VFIO mediated device framework and provides the infrastructure for 
granting exclusive guest access to crypto devices installed on the linux 
host. This patch series introduces a new QEMU command line option, QEMU 
object model and CPU model features to exploit the KVM/kernel model.

See the detailed specifications for AP virtualization provided by this 
patch set in docs/vfio-ap.txt for a more complete discussion of the 
design introduced by this patch series.

v8 => v9 Change log:
===================
* Removed all references to VFIO in AP bridge and bus
* Expose AP feature only if the KVM_S390_VM_CRYPTO_ENABLE_APIE VM attribute
  is exposed by KVM - i.e., if AP instructions are available on the linux
  host.
* Enable AP interpretation only if AP feature is switched on; no need to
  disable because it is disabled by default.

v7 => v8 Change log:
===================
* Enable SIE interpretation AP instructions if the CPU model feature for
  AP instructions is turned on for the guest.

v6 => v7 Change log;
===================
* Changed email address for Signed-off-by

v5 => v6 Change log:
===================
* Added reset handling fo vfio-ap device
* Added a bridge/bus to AP device object model - thanks to Halil Pasic

v4 => v5 Change log:
===================
* Added MAINTAINERS entries for VFIO AP
* Added explanation for why we are only supporting zEC12 and newer CPU 
  models.
* Changed CPU model feature qci=on|off to apqci=on|off
* Misc. minor changes

v3 => v4 Change log:
===================
* Made vfio-ap device unpluggable for now
* Renamed command line CPU model feature for QCI: qci=on -> apqci=on
* Removed call to KVM_S390_VM_CRYPTO_INTERPRET_AP ioctl - ioctl was 
  removed from kernel and AP instruction interpretation is set from the
  VFIO device driver
* Added check to ensure only one vfio-ap device can be configured per 
  guest
* Removed AP instruction interception handlers: AP instructions will be 
  interpreted by default if AP facilities are installed to handle the case
  where feature ap=on and no vfio-ap device is configured for the guest.

Tony Krowiak (6):
  linux-headers: linux header updates for AP support
  s390x/cpumodel: Set up CPU model for AP device support
  s390x/kvm: enable AP instruction interpretation for guest
  s390x/ap: base Adjunct Processor (AP) object model
  s390x/vfio: ap: Introduce VFIO AP device
  s390: doc: detailed specifications for AP virtualization

 MAINTAINERS                       |  14 +
 default-configs/s390x-softmmu.mak |   1 +
 docs/vfio-ap.txt                  | 787 ++++++++++++++++++++++++++++++
 hw/s390x/Makefile.objs            |   2 +
 hw/s390x/ap-bridge.c              |  81 +++
 hw/s390x/ap-device.c              |  39 ++
 hw/s390x/s390-virtio-ccw.c        |   4 +
 hw/vfio/Makefile.objs             |   1 +
 hw/vfio/ap.c                      | 181 +++++++
 include/hw/s390x/ap-bridge.h      |  37 ++
 include/hw/s390x/ap-device.h      |  38 ++
 include/hw/vfio/vfio-common.h     |   1 +
 linux-headers/asm-s390/kvm.h      |   3 +
 linux-headers/linux/vfio.h        |   2 +
 target/s390x/cpu_features.c       |   3 +
 target/s390x/cpu_features_def.h   |   3 +
 target/s390x/cpu_models.c         |   2 +
 target/s390x/gen-features.c       |   3 +
 target/s390x/kvm.c                |  19 +
 19 files changed, 1221 insertions(+)
 create mode 100644 docs/vfio-ap.txt
 create mode 100644 hw/s390x/ap-bridge.c
 create mode 100644 hw/s390x/ap-device.c
 create mode 100644 hw/vfio/ap.c
 create mode 100644 include/hw/s390x/ap-bridge.h
 create mode 100644 include/hw/s390x/ap-device.h

-- 
2.19.0.221.g150f307


Re: [Qemu-devel] [PATCH v9 0/6] s390x: vfio-ap: guest dedicated crypto adapters
Posted by Cornelia Huck 5 years, 6 months ago
On Wed, 26 Sep 2018 18:54:34 -0400
Tony Krowiak <akrowiak@linux.vnet.ibm.com> wrote:

> From: Tony Krowiak <akrowiak@linux.ibm.com>
> 
> This patch series is the QEMU counterpart to the KVM/kernel support for 
> guest dedicated crypto adapters. The KVM/kernel model is built on the 
> VFIO mediated device framework and provides the infrastructure for 
> granting exclusive guest access to crypto devices installed on the linux 
> host. This patch series introduces a new QEMU command line option, QEMU 
> object model and CPU model features to exploit the KVM/kernel model.
> 
> See the detailed specifications for AP virtualization provided by this 
> patch set in docs/vfio-ap.txt for a more complete discussion of the 
> design introduced by this patch series.

This seems to look sane in general. However, before I merge this:

- This needs to wait for a proper headers sync, which can only be done
  after the Linux code hits upstream. Shouldn't be long, I guess (I can
  queue on a staging branch while waiting.)
- As I don't have the hardware, I cannot run more than some generic
  "verify it does not break anything" testing. So, I'd like to see a
  Tested-by by someone who actually does have access to the hardware.
- I'd like to see some more review/acks from others. If other (minor)
  things crop up, I'd prefer a respin (I don't want to juggle too many
  "minor changes"...)

Re: [Qemu-devel] [PATCH v9 0/6] s390x: vfio-ap: guest dedicated crypto adapters
Posted by Tony Krowiak 5 years, 6 months ago
On 09/27/2018 05:28 AM, Cornelia Huck wrote:
> On Wed, 26 Sep 2018 18:54:34 -0400
> Tony Krowiak <akrowiak@linux.vnet.ibm.com> wrote:
> 
>> From: Tony Krowiak <akrowiak@linux.ibm.com>
>>
>> This patch series is the QEMU counterpart to the KVM/kernel support for
>> guest dedicated crypto adapters. The KVM/kernel model is built on the
>> VFIO mediated device framework and provides the infrastructure for
>> granting exclusive guest access to crypto devices installed on the linux
>> host. This patch series introduces a new QEMU command line option, QEMU
>> object model and CPU model features to exploit the KVM/kernel model.
>>
>> See the detailed specifications for AP virtualization provided by this
>> patch set in docs/vfio-ap.txt for a more complete discussion of the
>> design introduced by this patch series.
> 
> This seems to look sane in general. However, before I merge this:
> 
> - This needs to wait for a proper headers sync, which can only be done
>    after the Linux code hits upstream. Shouldn't be long, I guess (I can
>    queue on a staging branch while waiting.)
> - As I don't have the hardware, I cannot run more than some generic
>    "verify it does not break anything" testing. So, I'd like to see a
>    Tested-by by someone who actually does have access to the hardware.
> - I'd like to see some more review/acks from others. If other (minor)
>    things crop up, I'd prefer a respin (I don't want to juggle too many
>    "minor changes"...)

I am planning on a v10 series to address issues raised by Thomas, David
and you.

>