[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
Thu, 8 Mar 2018 09:05:06 -0500
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0
On 03/07/2018 09:41 AM, Cornelia Huck wrote:
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
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?)
Under the current architecture, instructions are either interpreted (with
some instructions being intercepted under specific conditions) or
Therefore, when remapping tuples, it will be necessary to intercept all
-> that's where it gets complicated, and IIUC we can't have any mixed
straight/remap setups, and we may have issues regarding nesting
As I said above, under the current architecture instructions are either
interpreted (ECA.28 is set) or intercepted (ECA.28 is cleared).
we can't mix guests that use interpretation with guests that don't.
Question: How important is that use case? Can we drop it and make our
lives much easier?
We've already had requests.
* 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.
If I'm not mistaken, the discussions about full emulation centered around
problems related to second level guests (VSIE). It seems possible to
employ full emulation for guest level 1. I'm not in a position to say
whether it would be worth the effort or not.
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?
I don't know enough about virtio-crypto to say.
Re: [qemu-s390x] [PATCH v2 5/5] s390x/cpumodel: Set up CPU model for AP device support, Tony Krowiak, 2018/03/02