On 2020-05-05 10:27, Christian Borntraeger wrote:
On 05.05.20 10:04, David Hildenbrand wrote:
On 05.05.20 09:55, Christian Borntraeger wrote:
On 05.05.20 09:53, Cornelia Huck wrote:
On Tue, 5 May 2020 09:35:25 +0200
Christian Borntraeger <borntraeger@xxxxxxxxxx> wrote:
In LPAR we will only get an intercept for FC==3 for the PQAP
instruction. Running nested under z/VM can result in other intercepts as
well, for example PQAP(QCI). So the WARN_ON_ONCE is not right. Let
us simply remove it.
While I agree with removing the WARN_ON_ONCE, I'm wondering why z/VM
gives us intercepts for those fcs... is that just a result of nesting
(or the z/VM implementation), or is there anything we might want to do?
Yes nesting.
The ECA bit for interpretion is an effective one. So if the ECA bit is off
in z/VM (no crypto cards) our ECA bit is basically ignored as these bits
are ANDed.
I asked Tony to ask the z/VM team if that is the case here.
So we can't detect if we have support for ECA_APIE, because there is no
explicit feature bit, right? Rings a bell. Still an ugly
hardware/firmware specification.
Sorry to be late but you were really too fast for me. :)
AFAIK we detect if we have AP instructions enabled by ECA_APIE for the
host by probing with a PQAP(TESTQ) during the boot.
If the hypervizor accept this instruction it is supposed to work as if
it has set APIE present for the Linux host.
If the instruction is rejected we do not enable AP instructions for the
guest
We also detect if we can use QCI by testing the facility bit and
propagate only the facility bits we have earned or emulate don't we?
So here I am curious why we got an interception.
Did we give false information to the guest?
Is the guest right to issue the instruction intercepted?
Did z/VM provide the host with false facility information?
Did z/VM dynamically change the virtualization scheme after the boot?
I did not find evidence of the first assumption which would have been a
legitimate warning.
The next 3 are, IMHO, misbehavior from the guest or z/VM, and do not
justify a warning there so I find right to remove it.
consider it as a "late" reviewed-by.
Regards,
Pierre
Yes, no matter if this is the case here, we cannot rely on ECA_APIE to not
trigger intercepts. So we must remove the WARN_ON.
cc stable?
Seems to be the right thing to do
Reviewed-by: David Hildenbrand <david@xxxxxxxxxx>
--
Pierre Morel
IBM Lab Boeblingen
