Re: [PATCH] KVM: s390: Remove false WARN_ON_ONCE for the PQAP instruction

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

 





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



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Kernel Development]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Info]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Linux Media]     [Device Mapper]

  Powered by Linux