On 06/05/20 14:23, Christian Borntraeger wrote: > > the problem is that z/VM seems to have disabled that bit. The interpretion > only works when all layers have this bit set. (Its called an effective bit). > So we have > LPAR -> ECA_APIE = 1 > Z/VM -> ECA_APIE = 0 > KVM -> ECA_APIE = 1 > nested KVM guest --> does during boot in ap_instructions_available PQAP with > FC==0 to test if crypto is available. > > As the nested guest is in fact a shadow guest of z/VM > this will now intercept to z/VM, which will forward that to KVM. Right, and I'd understand, that since KVM has set ECA_APIE=1, z/VM should either: * not forward the intercept to KVM unless FC==3 * toggle ECA_APIE back to 1 while running the KVM nested guest. Of course I have no idea if either of these choices is impossible, or too expensive, but this is how we'd try to handle it for x86 features. So it would be a z/VM bug, because it's not virtualizing ECA_APIE=1 correctly. The next question is, if removing the WARN_ON is okay for you, should KVM not bother setting ECA_APIE=1 so that you don't trigger the z/VM bug at all? Thanks, Paolo > > As PQAP with FC==0 DOES work in the KVM, KVM believes that we have crypto > support and we will enable it for our guests. So all the early checks in > handle_pqap will succeed until we run in the check for fc!=3. > > In the end this is obviously a case how this warning can trigger. So we better > remove it and rely on the error path to clean up.
