Re: [Qemu-devel] [PATCH v2 0/5] s390x: vfio-ap: guest dedicated crypto adapters

[Christian Borntraeger]

On 03/07/2018 11:22 AM, Pierre Morel wrote:
> On 06/03/2018 18:10, David Hildenbrand wrote:
>>> If L2 forward devices to L3 through SIE ECA.28 but no bit is set is in
>>> the CRYCB of L2,
>>> L3 will not see any device.
>> Exactly and this is the problem: How should L2 know that these devices
>> are special and cannot be forwarded.
>>
>>>> This is what we call the nightmare of nested virtualization (see x86),
>>>> because we have to emulate L3 instructions in L1 - but even worse, not
>>>> even in L1 kernel space but in L1 user space.
>>> As soon as one level begin to virtualize, all levels under it
>>> must virtualize too so that L3 instructions will be handled in L2
>>> which will issue instructions that will be handled in L1.
>> By virtualize I assume you mean emulate? If so, yes.
>>
>>>> So we could never provide the AP feature reliably with the SIE feature.
>>> I think we should change a little this sentence to:
>>> We can not provide SIE interpretation to a guest from which
>>> any guest level N-1 does not use SIE interpretation.
>> Exactly, and as said, there is no way to tell a guest that it has AP but
>> cannot use AP interpretation but has to intercept and handle manually.
> 
> 
> vSIE must clear ECA28 during running of the guest if the host itself do not 
> have ECA28 set.
> Since ECA28 set for the host means AP instructions available for the host
> then we can sum it up by: vSIE should never set ECA28 in the shadow SIE
> if no AP instructions available.

To say it differently, architecturally ECA28 is an effective control so we might
put the burden on the guest2 by saying even it you set eca.28 you might still
get exits for NQAP,PQAP,DQAP and handle it appropriately.


> 
> Pierre
> 
> 
>>
>>> Nothing bad will occur for the host, the hardware or other guests,
>>> but the guest will just not get any device.
>>>
>>>> We want to avoid interdependence between CPU features. (because
>>>> everything else makes CPU feature detection ugly - CMMA is a good
>>>> example and the only exception so far)
>>>>
>>>>
>>>> Long story even shorter:
>>>>
>>>> No emulated AP devices with KVM.
>>>>
>>> I agree with: KVM should never set bits in CRYCB for emulated devices.
>> I think this is stronger: emulated AP devices should not be used with
>> KVM because it can potentially lead to architectural (v)SIE conflicts.
>>
>> But the details are buried in some AP documentation not accessible to me.
>>
>> Anyhow, if the scenario I described cannot be worked around via:
>>
>> a) telling a guest that AP virtualization cannot be used - which doesn't
>> seem to be possible
>> b) provoking for selected devices a SIE exit when an AP instruction is
>> executed on these devices - and this is totally fine with the documented
>> AP architecture
>>
>> I assume we would have to live with !emualted AP devices.
>>
>