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

[Pierre Morel <pmorel@linux.vnet.ibm.com>]

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.

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.
>

-- 
Pierre Morel
Linux/KVM/QEMU in Böblingen - Germany