qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Cornelia Huck
Subject: Re: [Qemu-devel] [PATCH v2 5/5] s390x/cpumodel: Set up CPU model for AP device support
Date: 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
> 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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]