If a guest wants to use more than 64 and use sigp interpretation it needs to use the extended system control area. When the ESCA is not already used and the 65th cpu is added the VM host will kick all cpus destroy the old basic system control area (BSCA) and create a new ESCA for the guest configuration. In VSIE execution using vsie sigpif this also means the SSCA need to be updated. The structure of the SSCA remains the same but the pointers to the original SCA as well as its entries will have changed. In guest-1 we can detect this change relatively simple as the original SCA address changes. Signed-off-by: Christoph Schlameuss --- arch/s390/kvm/vsie.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/arch/s390/kvm/vsie.c b/arch/s390/kvm/vsie.c index 1e15220e1f1ecfd83b10aa0620ca84ff0ff3c1ac..b69ef763b55296875522f2e63169446b5e2d5053 100644 --- a/arch/s390/kvm/vsie.c +++ b/arch/s390/kvm/vsie.c @@ -932,8 +932,16 @@ static struct vsie_sca *get_vsie_sca(struct kvm_vcpu *vcpu, struct vsie_page *vs if (sca) goto out; + if (vsie_page->sca) { + /* switch to extended system control area (esca) */ + sca = vsie_page->sca; + WARN_ON_ONCE(atomic_read(&sca->ref_count)); + unpin_sca(kvm, sca); + /* trigger init_ssca() later */ + if (sca->ssca) + sca->ssca->osca = 0; /* check again under write lock if we are still under our sca_count limit */ - if (sca_new && kvm->arch.vsie.sca_count < max_sca) { + } else if (sca_new && kvm->arch.vsie.sca_count < max_sca) { /* make use of vsie_sca just created */ sca = sca_new; sca_new = NULL; -- 2.51.1