On Wed May 14, 2025 at 7:34 PM CEST, David Hildenbrand wrote: > On 14.05.25 18:34, Christoph Schlameuss wrote: >> All modern IBM Z and Linux One machines do offer support for the >> Extended System Control Area (ESCA). The ESCA is available since the >> z114/z196 released in 2010. >> KVM needs to allocate and manage the SCA for guest VMs. Prior to this >> change the SCA was setup as Basic SCA only supporting a maximum of 64 >> vCPUs when initializing the VM. With addition of the 65th vCPU the SCA >> was needed to be converted to a ESCA. >> >> Instead we will now allocate the ESCA directly upon VM creation >> simplifying the code in multiple places as well as completely removing >> the need to convert an existing SCA. >> >> In cases where the ESCA is not supported (z10 and earlier) the use of >> the SCA entries and with that SIGP interpretation are disabled for VMs. >> This increases the number of exits from the VM in multiprocessor >> scenarios and thus decreases performance. > > Trying to remember vsie details ... I recall that for the vsie we never > cared about the layout, because we simply pin+forward the given block, > but disable any facility that would try de-referencing the vcpu > pointers. So we only pin a single page. > > pin_blocks() documents: "As we reuse the sca, the vcpu pointers > contained in it are invalid. We must therefore not enable any facilities > that access these pointers (e.g. SIGPIF)." > > > So I assume this change here will not affect (degrade) when being run as > a nested hypervisor, right? That is correct. In vsie we will simply continue running in the !kvm_s390_use_sca_entries() path as we are today. In that path we only need access to the SCA block header or really just the ipte_control. Which is even in the same byte position in BSCA and ESCA. This should really only have an impact where we do not have ESCA support in g1 / g2. -- Cheers, Christoph
