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