On 9/11/20 9:54 AM, Thomas Huth wrote: > On 11/09/2020 15.41, Thomas Huth wrote: >> On 10/09/2020 11.36, Collin Walling wrote: >>> As more features and facilities are added to the Read SCP Info (RSCPI) >>> response, more space is required to store them. The space used to store >>> these new features intrudes on the space originally used to store CPU >>> entries. This means as more features and facilities are added to the >>> RSCPI response, less space can be used to store CPU entries. >>> >>> With the Extended-Length SCCB (ELS) facility, a KVM guest can execute >>> the RSCPI command and determine if the SCCB is large enough to store a >>> complete reponse. If it is not large enough, then the required length >>> will be set in the SCCB header. >>> >>> The caller of the SCLP command is responsible for creating a >>> large-enough SCCB to store a complete response. Proper checking should >>> be in place, and the caller should execute the command once-more with >>> the large-enough SCCB. >>> >>> This facility also enables an extended SCCB for the Read CPU Info >>> (RCPUI) command. >>> >>> When this facility is enabled, the boundary violation response cannot >>> be a result from the RSCPI, RSCPI Forced, or RCPUI commands. >>> >>> In order to tolerate kernels that do not yet have full support for this >>> feature, a "fixed" offset to the start of the CPU Entries within the >>> Read SCP Info struct is set to allow for the original 248 max entries >>> when this feature is disabled. >>> >>> Additionally, this is introduced as a CPU feature to protect the guest >>> from migrating to a machine that does not support storing an extended >>> SCCB. This could otherwise hinder the VM from being able to read all >>> available CPU entries after migration (such as during re-ipl). >>> >>> Signed-off-by: Collin Walling <wall...@linux.ibm.com> >>> --- >> [...] >>> /* Provide information about the configuration, CPUs and storage */ >>> static void read_SCP_info(SCLPDevice *sclp, SCCB *sccb) >>> { >>> @@ -89,10 +112,15 @@ static void read_SCP_info(SCLPDevice *sclp, SCCB *sccb) >>> int rnsize, rnmax; >>> IplParameterBlock *ipib = s390_ipl_get_iplb(); >>> int required_len = SCCB_REQ_LEN(ReadInfo, machine->possible_cpus->len); >>> - int offset_cpu = offsetof(ReadInfo, entries); >>> + int offset_cpu = s390_has_feat(S390_FEAT_EXTENDED_LENGTH_SCCB) ? >>> + offsetof(ReadInfo, entries) : >>> + SCLP_READ_SCP_INFO_FIXED_CPU_OFFSET; >> >> Sorry, but I'm having somewhat trouble to understand this... >> What's the difference between offsetof(ReadInfo, entries) and >> SCLP_READ_SCP_INFO_FIXED_CPU_OFFSET ? Aren't both terms resulting in the >> value 128 ? > > Ah, well, the answer is clear after looking at patch 8/8 ... ReadInfo is > extended there, so offsetof(ReadInfo, entries) will result in a > different value. > Might have been better to move the above hunk into patch 8/8, but if you > want to keep it here, that's now ok for me, too. > > Reviewed-by: Thomas Huth <th...@redhat.com> > >
I see your point. In retrospect, it might've been better to include it in patch 8/8 so it's more clear why these features are introduced within the same patch set. If there are any requests to change / fixup this patch in any other regard, then I'll consider moving the offset_cpu calculation to 8/8. Otherwise, I'll leave it here :) Thanks! -- Regards, Collin Stay safe and stay healthy