[Top][All Lists]

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

Re: [qemu-s390x] [PATCH v2 0/5] s390x: vfio-ap: guest dedicated crypto a

From: Pierre Morel
Subject: Re: [qemu-s390x] [PATCH v2 0/5] s390x: vfio-ap: guest dedicated crypto adapters
Date: Wed, 7 Mar 2018 11:22:47 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

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.


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

reply via email to

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