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?