On 06.05.20 15:04, Paolo Bonzini wrote: > 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 It would be kind of a z/VM bug, but its ok according to the docs. > 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? We need ECA_APIE as this is the only way to provide hardware passthrough. In the end running KVM under z/VM kind of works but it is not something that I would consider supported.
