This series enables general QEMU support for AP pass-through for Secure
Execution guests (pv-guests).

To enable AP-PT on pv-guests QEMU has to turn on the corresponding bits
in the KVM CPU-model[1] if the CPU firmware supports it. However, it
only makes sense to turn on AP-PT if the QEMU user enabled (general) AP
for that guest. If AP is turned on (ap=on) QEMU also turns on AP-PT for
secure execution guests(appv=on) if the CPU supports it.

The series consists of three patches:
 1) update kvm-s390 header for this series
 2) small cleanup for kvm_s390_set_attr()
    refactor code to add ap_available()
 3) Add UV_CALL CPU model enablement

There is **one** problem with the current implementation:
If the user does not enable AP in the cpu model QEMU produces the
following warning:
```
qemu-system-s390x: warning: 'appv' requires 'ap'.
```

During `check_consistency()` the model has appv=on and ap=offi, hence
the warning. However, appv is not turned on during the model
realization, as the code checks for AP in beforehand.

appv is in the default z16 model so that it is automatically enabled if
ap=on was specified.

I did not find a concept of dynamic defaults to model this behavior
(ap=on -> appv=on -> appvi=on). So I hope someone on the list can help
me and give some pointers on how to implement that.


Steffen


Steffen Eiden (3):
  linux-headers: update asm-s390/kvm.h
  target/s390x: refractor AP functionalities
  target/s390x: AP-passthrough for PV guests

 linux-headers/asm-s390/kvm.h        | 21 +++++++
 target/s390x/cpu_features.h         |  1 +
 target/s390x/cpu_features_def.h.inc |  4 ++
 target/s390x/cpu_models.c           |  2 +
 target/s390x/gen-features.c         |  4 ++
 target/s390x/kvm/kvm.c              | 91 ++++++++++++++++++++++++++---
 6 files changed, 116 insertions(+), 7 deletions(-)

-- 
2.40.1

On 7/27/23 14:25, Steffen Eiden wrote:
> This series enables general QEMU support for AP pass-through for Secure
> Execution guests (pv-guests).
> 
> To enable AP-PT on pv-guests QEMU has to turn on the corresponding bits
> in the KVM CPU-model[1] if the CPU firmware supports it. However, it
> only makes sense to turn on AP-PT if the QEMU user enabled (general) AP
> for that guest. If AP is turned on (ap=on) QEMU also turns on AP-PT for
> secure execution guests(appv=on) if the CPU supports it.
> 
> The series consists of three patches:
>   1) update kvm-s390 header for this series
>   2) small cleanup for kvm_s390_set_attr()
>      refactor code to add ap_available()
>   3) Add UV_CALL CPU model enablement
> 
> There is **one** problem with the current implementation:
> If the user does not enable AP in the cpu model QEMU produces the
> following warning:
> ```
> qemu-system-s390x: warning: 'appv' requires 'ap'.
> ```
> 
> During `check_consistency()` the model has appv=on and ap=offi, hence
> the warning. However, appv is not turned on during the model
> realization, as the code checks for AP in beforehand.
> 
> appv is in the default z16 model so that it is automatically enabled if
> ap=on was specified.
> 
> I did not find a concept of dynamic defaults to model this behavior
> (ap=on -> appv=on -> appvi=on). So I hope someone on the list can help
> me and give some pointers on how to implement that.
> 
> 
> Steffen

[1] v2 KVM series:
https://lore.kernel.org/linux-s390/20230728092341.1131787-1-seiden@linux.ibm.com/T/#t

> 
> Steffen Eiden (3):
>    linux-headers: update asm-s390/kvm.h
>    target/s390x: refractor AP functionalities
>    target/s390x: AP-passthrough for PV guests
> 
>   linux-headers/asm-s390/kvm.h        | 21 +++++++
>   target/s390x/cpu_features.h         |  1 +
>   target/s390x/cpu_features_def.h.inc |  4 ++
>   target/s390x/cpu_models.c           |  2 +
>   target/s390x/gen-features.c         |  4 ++
>   target/s390x/kvm/kvm.c              | 91 ++++++++++++++++++++++++++---
>   6 files changed, 116 insertions(+), 7 deletions(-)
>