Re: [Qemu-devel] [PATCH v2 5/5] s390x/cpumodel: Set up CPU model for AP device support

[Cornelia Huck <cohuck@redhat.com>]

On Wed, 7 Mar 2018 11:09:46 +0100
Pierre Morel <pmorel@linux.vnet.ibm.com> wrote:

> What I mean is the reverse implication
> 
> ECA_APIE => ap=on
> 
> But you can have ap = on and ECA_APIE = off
> This is interception or emulation.
> 
> and the second thing is that we need two QEMU cpu features
> AP : guest API to say we provide AP instructions to the guest (what ever 
> we do to provide it)
> ECA_APIE : kernel will setup the SIE with interpretation
> 
> other said:
> if( !ap)
>      return -ENODEVICE
> if(ECA_API)
>      set_interpretation()
> else
>      set_interception()

This discussion is giving me a headache, so let's take a step back and
figure out what is needed/wanted/possible.

* straight passthrough of tuples, SIE doing the heavy lifting
  -> what this patchset is doing, and should be fine, even regarding
     nesting

* remapping of tuples, SIE doing most of the work (IIRC it's possible
  to only intercept for a subset of instructions?)
  -> that's where it gets complicated, and IIUC we can't have any mixed
     straight/remap setups, and we may have issues regarding nesting
  Question: How important is that use case? Can we drop it and make our
  lives much easier?

* full emulation (which would be the only option for tcg, obviously)
  -> even if it were doable, I doubt it would be very useful
  It would be great if we could have a design that would also
  accommodate this (and I have rooted for that in the past), but the
  more I hear about the issues here, the more I doubt whether this is
  something we should spend time on.

Another question: Can some of the use cases be serviced via
virtio-crypto as well (clear key)? Would that in combination with
straight passthrough be enough?