[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [qemu-s390x] [PATCH v2 5/5] s390x/cpumodel: Set up CPU model for AP
Re: [qemu-s390x] [PATCH v2 5/5] s390x/cpumodel: Set up CPU model for AP device support
Wed, 7 Mar 2018 15:41:51 +0100
On Wed, 7 Mar 2018 11:09:46 +0100
Pierre Morel <address@hidden> 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
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
* 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?
Re: [qemu-s390x] [PATCH v2 5/5] s390x/cpumodel: Set up CPU model for AP device support, Tony Krowiak, 2018/03/02