Re: [PATCH 0/3] KVM: s390: Use ESCA instead of BSCA at VM init

["Christoph Schlameuss" <schlameuss@linux.ibm.com>]

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