On Wed, 7 Mar 2018 11:09:46 +0100
Pierre Morel <pmo...@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?
