| Message ID | 20220506092403.47406-3-pmorel@linux.ibm.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | s390x: KVM: CPU Topology | expand |
On 06.05.22 11:24, Pierre Morel wrote: > We let the userland hypervisor know if the machine support the CPU > topology facility using a new KVM capability: KVM_CAP_S390_CPU_TOPOLOGY. > > The PTF instruction will report a topology change if there is any change > with a previous STSI_15_1_2 SYSIB. > Changes inside a STSI_15_1_2 SYSIB occur if CPU bits are set or clear > inside the CPU Topology List Entry CPU mask field, which happens with > changes in CPU polarization, dedication, CPU types and adding or > removing CPUs in a socket. > > The reporting to the guest is done using the Multiprocessor > Topology-Change-Report (MTCR) bit of the utility entry of the guest's > SCA which will be cleared during the interpretation of PTF. > > To check if the topology has been modified we use a new field of the > arch vCPU to save the previous real CPU ID at the end of a schedule > and verify on next schedule that the CPU used is in the same socket. > We do not report polarization, CPU Type or dedication change. > > STSI(15.1.x) gives information on the CPU configuration topology. > Let's accept the interception of STSI with the function code 15 and > let the userland part of the hypervisor handle it when userland > support the CPU Topology facility. > > Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> [...] > diff --git a/arch/s390/kvm/priv.c b/arch/s390/kvm/priv.c > index 0e8603acc105..d9e16b09c8bf 100644 > --- a/arch/s390/kvm/priv.c > +++ b/arch/s390/kvm/priv.c > @@ -874,10 +874,12 @@ static int handle_stsi(struct kvm_vcpu *vcpu) > if (vcpu->arch.sie_block->gpsw.mask & PSW_MASK_PSTATE) > return kvm_s390_inject_program_int(vcpu, PGM_PRIVILEGED_OP); > > - if (fc > 3) { > - kvm_s390_set_psw_cc(vcpu, 3); > - return 0; > - } > + if (fc > 3 && fc != 15) > + goto out_no_data; > + > + /* fc 15 is provided with PTF/CPU topology support */ > + if (fc == 15 && !test_kvm_facility(vcpu->kvm, 11)) > + goto out_no_data; Maybe shorter as if (fc == 15 && !test_kvm_facility(vcpu->kvm, 11)) goto out_no_data; else if (fc > 3) goto out_no_data; Apart from that, LGTM.
On 5/6/22 11:24, Pierre Morel wrote: > We let the userland hypervisor know if the machine support the CPU > topology facility using a new KVM capability: KVM_CAP_S390_CPU_TOPOLOGY. Nope, we indicate KVM's support which is based on the machine's support. On the same note: Shouldn't the CAP indication be part of the last patch? The resets are needed for a full support of this feature, no?
On 5/12/22 13:41, Janosch Frank wrote: > On 5/6/22 11:24, Pierre Morel wrote: >> We let the userland hypervisor know if the machine support the CPU >> topology facility using a new KVM capability: KVM_CAP_S390_CPU_TOPOLOGY. > > Nope, we indicate KVM's support which is based on the machine's support. OK I reword. > > On the same note: Shouldn't the CAP indication be part of the last > patch? The resets are needed for a full support of this feature, no? Looks right, I will move it last.
On 5/12/22 11:24, David Hildenbrand wrote: > On 06.05.22 11:24, Pierre Morel wrote: >> We let the userland hypervisor know if the machine support the CPU >> topology facility using a new KVM capability: KVM_CAP_S390_CPU_TOPOLOGY. >> >> The PTF instruction will report a topology change if there is any change >> with a previous STSI_15_1_2 SYSIB. >> Changes inside a STSI_15_1_2 SYSIB occur if CPU bits are set or clear >> inside the CPU Topology List Entry CPU mask field, which happens with >> changes in CPU polarization, dedication, CPU types and adding or >> removing CPUs in a socket. >> >> The reporting to the guest is done using the Multiprocessor >> Topology-Change-Report (MTCR) bit of the utility entry of the guest's >> SCA which will be cleared during the interpretation of PTF. >> >> To check if the topology has been modified we use a new field of the >> arch vCPU to save the previous real CPU ID at the end of a schedule >> and verify on next schedule that the CPU used is in the same socket. >> We do not report polarization, CPU Type or dedication change. >> >> STSI(15.1.x) gives information on the CPU configuration topology. >> Let's accept the interception of STSI with the function code 15 and >> let the userland part of the hypervisor handle it when userland >> support the CPU Topology facility. >> >> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> > > [...] > > >> diff --git a/arch/s390/kvm/priv.c b/arch/s390/kvm/priv.c >> index 0e8603acc105..d9e16b09c8bf 100644 >> --- a/arch/s390/kvm/priv.c >> +++ b/arch/s390/kvm/priv.c >> @@ -874,10 +874,12 @@ static int handle_stsi(struct kvm_vcpu *vcpu) >> if (vcpu->arch.sie_block->gpsw.mask & PSW_MASK_PSTATE) >> return kvm_s390_inject_program_int(vcpu, PGM_PRIVILEGED_OP); >> >> - if (fc > 3) { >> - kvm_s390_set_psw_cc(vcpu, 3); >> - return 0; >> - } >> + if (fc > 3 && fc != 15) >> + goto out_no_data; >> + >> + /* fc 15 is provided with PTF/CPU topology support */ >> + if (fc == 15 && !test_kvm_facility(vcpu->kvm, 11)) >> + goto out_no_data; > > > Maybe shorter as > > if (fc == 15 && !test_kvm_facility(vcpu->kvm, 11)) > goto out_no_data; > else if (fc > 3) > goto out_no_data; > yes. > > Apart from that, LGTM. > Thanks, Pierre
Am 06.05.22 um 11:24 schrieb Pierre Morel: > We let the userland hypervisor know if the machine support the CPU > topology facility using a new KVM capability: KVM_CAP_S390_CPU_TOPOLOGY. > > The PTF instruction will report a topology change if there is any change > with a previous STSI_15_1_2 SYSIB. > Changes inside a STSI_15_1_2 SYSIB occur if CPU bits are set or clear > inside the CPU Topology List Entry CPU mask field, which happens with > changes in CPU polarization, dedication, CPU types and adding or > removing CPUs in a socket. > > The reporting to the guest is done using the Multiprocessor > Topology-Change-Report (MTCR) bit of the utility entry of the guest's > SCA which will be cleared during the interpretation of PTF. > > To check if the topology has been modified we use a new field of the > arch vCPU to save the previous real CPU ID at the end of a schedule > and verify on next schedule that the CPU used is in the same socket. > We do not report polarization, CPU Type or dedication change. I think we should not do this. When PTF returns with "has changed" the guest Linux will rebuild its schedule domains. And this is a really expensive operation as far as I can tell. And the host Linux scheduler WILL schedule too often to other CPUs. So in essence this will result in Linux guests rebuilding their scheduler domains all the time. So remove the "previous CPU logic" for now and only trigger an MTCR when userspace says so. (eg. on config changes). The idea was to have user defined schedule domains. Following host schedule decisions will be nearly impossible.
On 5/19/22 11:01, Christian Borntraeger wrote: > > > Am 06.05.22 um 11:24 schrieb Pierre Morel: >> We let the userland hypervisor know if the machine support the CPU >> topology facility using a new KVM capability: KVM_CAP_S390_CPU_TOPOLOGY. >> >> The PTF instruction will report a topology change if there is any change >> with a previous STSI_15_1_2 SYSIB. >> Changes inside a STSI_15_1_2 SYSIB occur if CPU bits are set or clear >> inside the CPU Topology List Entry CPU mask field, which happens with >> changes in CPU polarization, dedication, CPU types and adding or >> removing CPUs in a socket. >> >> The reporting to the guest is done using the Multiprocessor >> Topology-Change-Report (MTCR) bit of the utility entry of the guest's >> SCA which will be cleared during the interpretation of PTF. >> >> To check if the topology has been modified we use a new field of the >> arch vCPU to save the previous real CPU ID at the end of a schedule >> and verify on next schedule that the CPU used is in the same socket. >> We do not report polarization, CPU Type or dedication change. > > I think we should not do this. When PTF returns with "has changed" the > guest > Linux will rebuild its schedule domains. And this is a really expensive > operation as far as I can tell. And the host Linux scheduler WILL schedule > too often to other CPUs. So in essence this will result in Linux guests > rebuilding their scheduler domains all the time. > So remove the "previous CPU logic" for now and only trigger an MTCR when > userspace says so. (eg. on config changes). The idea was to have user > defined schedule domains. Following host schedule decisions will be > nearly impossible. I guess you saw that the MTCR bit is set only if the previous and new CPU are on different sockets, like it is on the hardware, not on every scheduling to another CPU. However this can easily be done in an enhancement, if ever, since it has no implication on the UAPI. I change this for the next round. Thanks, Pierre
Am 19.05.22 um 11:23 schrieb Pierre Morel: > > > On 5/19/22 11:01, Christian Borntraeger wrote: >> >> >> Am 06.05.22 um 11:24 schrieb Pierre Morel: >>> We let the userland hypervisor know if the machine support the CPU >>> topology facility using a new KVM capability: KVM_CAP_S390_CPU_TOPOLOGY. >>> >>> The PTF instruction will report a topology change if there is any change >>> with a previous STSI_15_1_2 SYSIB. >>> Changes inside a STSI_15_1_2 SYSIB occur if CPU bits are set or clear >>> inside the CPU Topology List Entry CPU mask field, which happens with >>> changes in CPU polarization, dedication, CPU types and adding or >>> removing CPUs in a socket. >>> >>> The reporting to the guest is done using the Multiprocessor >>> Topology-Change-Report (MTCR) bit of the utility entry of the guest's >>> SCA which will be cleared during the interpretation of PTF. >>> >>> To check if the topology has been modified we use a new field of the >>> arch vCPU to save the previous real CPU ID at the end of a schedule >>> and verify on next schedule that the CPU used is in the same socket. >>> We do not report polarization, CPU Type or dedication change. >> >> I think we should not do this. When PTF returns with "has changed" the guest >> Linux will rebuild its schedule domains. And this is a really expensive >> operation as far as I can tell. And the host Linux scheduler WILL schedule >> too often to other CPUs. So in essence this will result in Linux guests >> rebuilding their scheduler domains all the time. >> So remove the "previous CPU logic" for now and only trigger an MTCR when >> userspace says so. (eg. on config changes). The idea was to have user >> defined schedule domains. Following host schedule decisions will be >> nearly impossible. > > > > I guess you saw that the MTCR bit is set only if the previous and new CPU are on different sockets, like it is on the hardware, not on every scheduling to another CPU. Yes, but even that happens too often as far as I can tell. > > However this can easily be done in an enhancement, if ever, since it has no implication on the UAPI. > I change this for the next round. Yes, lets defer that (we would need solid measurements).
On 5/16/22 16:13, Pierre Morel wrote: > > > On 5/12/22 11:24, David Hildenbrand wrote: >> On 06.05.22 11:24, Pierre Morel wrote: >>> We let the userland hypervisor know if the machine support the CPU >>> topology facility using a new KVM capability: KVM_CAP_S390_CPU_TOPOLOGY. >>> >>> The PTF instruction will report a topology change if there is any change >>> with a previous STSI_15_1_2 SYSIB. >>> Changes inside a STSI_15_1_2 SYSIB occur if CPU bits are set or clear >>> inside the CPU Topology List Entry CPU mask field, which happens with >>> changes in CPU polarization, dedication, CPU types and adding or >>> removing CPUs in a socket. >>> >>> The reporting to the guest is done using the Multiprocessor >>> Topology-Change-Report (MTCR) bit of the utility entry of the guest's >>> SCA which will be cleared during the interpretation of PTF. >>> >>> To check if the topology has been modified we use a new field of the >>> arch vCPU to save the previous real CPU ID at the end of a schedule >>> and verify on next schedule that the CPU used is in the same socket. >>> We do not report polarization, CPU Type or dedication change. >>> >>> STSI(15.1.x) gives information on the CPU configuration topology. >>> Let's accept the interception of STSI with the function code 15 and >>> let the userland part of the hypervisor handle it when userland >>> support the CPU Topology facility. >>> >>> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> >> >> [...] >> >> >>> diff --git a/arch/s390/kvm/priv.c b/arch/s390/kvm/priv.c >>> index 0e8603acc105..d9e16b09c8bf 100644 >>> --- a/arch/s390/kvm/priv.c >>> +++ b/arch/s390/kvm/priv.c >>> @@ -874,10 +874,12 @@ static int handle_stsi(struct kvm_vcpu *vcpu) >>> if (vcpu->arch.sie_block->gpsw.mask & PSW_MASK_PSTATE) >>> return kvm_s390_inject_program_int(vcpu, PGM_PRIVILEGED_OP); >>> - if (fc > 3) { >>> - kvm_s390_set_psw_cc(vcpu, 3); >>> - return 0; >>> - } >>> + if (fc > 3 && fc != 15) >>> + goto out_no_data; >>> + >>> + /* fc 15 is provided with PTF/CPU topology support */ >>> + if (fc == 15 && !test_kvm_facility(vcpu->kvm, 11)) >>> + goto out_no_data; >> >> >> Maybe shorter as >> >> if (fc == 15 && !test_kvm_facility(vcpu->kvm, 11)) >> goto out_no_data; >> else if (fc > 3) >> goto out_no_data; >> > > yes. hum, sorry, but no. when test_kvm_facility(11) is true then !test_kvm_facility(11) is false and the first test fails and the second succeed jumping to out_no_data for fc == 15 I can use what I proposed with a comment to make it better readable. What about: /* Bailout forbidden function codes */ if (fc > 3 && fc != 15) goto out_no_data; /* fc 15 is provided with PTF/CPU topology support */ if (fc == 15 && !test_kvm_facility(vcpu->kvm, 11)) goto out_no_data; > >> >> Apart from that, LGTM. >> > > Thanks, > Pierre >
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index 4a900cdbc62e..c15f5b9dafb6 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -7779,3 +7779,19 @@ Ordering of KVM_GET_*/KVM_SET_* ioctls ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ TBD + +8.17 KVM_CAP_S390_CPU_TOPOLOGY +------------------------------ + +:Capability: KVM_CAP_S390_CPU_TOPOLOGY +:Architectures: s390 +:Type: vm + +This capability indicates that kvm will provide the S390 CPU Topology facility +which consist of the interpretation of the PTF instruction for the Function +Code 2 along with interception and forwarding of both the PTF instruction +with Function Codes 0 or 1 and the STSI(15,1,x) instruction to the userland +hypervisor. + +The stfle facility 11, CPU Topology facility, should not be provided to the +guest without this capability. diff --git a/arch/s390/include/asm/kvm_host.h b/arch/s390/include/asm/kvm_host.h index 766028d54a3e..04653b43ccee 100644 --- a/arch/s390/include/asm/kvm_host.h +++ b/arch/s390/include/asm/kvm_host.h @@ -97,15 +97,19 @@ struct bsca_block { union ipte_control ipte_control; __u64 reserved[5]; __u64 mcn; - __u64 reserved2; +#define SCA_UTILITY_MTCR 0x8000 + __u16 utility; + __u8 reserved2[6]; struct bsca_entry cpu[KVM_S390_BSCA_CPU_SLOTS]; }; struct esca_block { union ipte_control ipte_control; - __u64 reserved1[7]; + __u64 reserved1[6]; + __u16 utility; + __u8 reserved2[6]; __u64 mcn[4]; - __u64 reserved2[20]; + __u64 reserved3[20]; struct esca_entry cpu[KVM_S390_ESCA_CPU_SLOTS]; }; @@ -249,6 +253,7 @@ struct kvm_s390_sie_block { #define ECB_SPECI 0x08 #define ECB_SRSI 0x04 #define ECB_HOSTPROTINT 0x02 +#define ECB_PTF 0x01 __u8 ecb; /* 0x0061 */ #define ECB2_CMMA 0x80 #define ECB2_IEP 0x20 @@ -750,6 +755,7 @@ struct kvm_vcpu_arch { bool skey_enabled; struct kvm_s390_pv_vcpu pv; union diag318_info diag318_info; + int prev_cpu; }; struct kvm_vm_stat { diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c index da3dabda1a12..c8bdce31464f 100644 --- a/arch/s390/kvm/kvm-s390.c +++ b/arch/s390/kvm/kvm-s390.c @@ -606,6 +606,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext) case KVM_CAP_S390_PROTECTED: r = is_prot_virt_host(); break; + case KVM_CAP_S390_CPU_TOPOLOGY: + r = test_facility(11); + break; default: r = 0; } @@ -817,6 +820,20 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm, struct kvm_enable_cap *cap) icpt_operexc_on_all_vcpus(kvm); r = 0; break; + case KVM_CAP_S390_CPU_TOPOLOGY: + r = -EINVAL; + mutex_lock(&kvm->lock); + if (kvm->created_vcpus) { + r = -EBUSY; + } else if (test_facility(11)) { + set_kvm_facility(kvm->arch.model.fac_mask, 11); + set_kvm_facility(kvm->arch.model.fac_list, 11); + r = 0; + } + mutex_unlock(&kvm->lock); + VM_EVENT(kvm, 3, "ENABLE: CPU TOPOLOGY %s", + r ? "(not available)" : "(success)"); + break; default: r = -EINVAL; break; @@ -1695,6 +1712,25 @@ static int kvm_s390_get_cpu_model(struct kvm *kvm, struct kvm_device_attr *attr) return ret; } +/** + * kvm_s390_sca_set_mtcr + * @kvm: guest KVM description + * + * Is only relevant if the topology facility is present, + * the caller should check KVM facility 11 + * + * Updates the Multiprocessor Topology-Change-Report to signal + * the guest with a topology change. + */ +static void kvm_s390_sca_set_mtcr(struct kvm *kvm) +{ + struct bsca_block *sca = kvm->arch.sca; /* SCA version doesn't matter */ + + ipte_lock(kvm); + sca->utility |= SCA_UTILITY_MTCR; + ipte_unlock(kvm); +} + static int kvm_s390_vm_set_attr(struct kvm *kvm, struct kvm_device_attr *attr) { int ret; @@ -3138,16 +3174,20 @@ __u64 kvm_s390_get_cpu_timer(struct kvm_vcpu *vcpu) void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu) { - gmap_enable(vcpu->arch.enabled_gmap); kvm_s390_set_cpuflags(vcpu, CPUSTAT_RUNNING); if (vcpu->arch.cputm_enabled && !is_vcpu_idle(vcpu)) __start_cpu_timer_accounting(vcpu); vcpu->cpu = cpu; + + if (kvm_s390_topology_changed(vcpu)) + kvm_s390_sca_set_mtcr(vcpu->kvm); } void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu) { + /* Remember which CPU was backing the vCPU */ + vcpu->arch.prev_cpu = vcpu->cpu; vcpu->cpu = -1; if (vcpu->arch.cputm_enabled && !is_vcpu_idle(vcpu)) __stop_cpu_timer_accounting(vcpu); @@ -3267,6 +3307,13 @@ static int kvm_s390_vcpu_setup(struct kvm_vcpu *vcpu) vcpu->arch.sie_block->ecb |= ECB_HOSTPROTINT; if (test_kvm_facility(vcpu->kvm, 9)) vcpu->arch.sie_block->ecb |= ECB_SRSI; + + /* PTF needs guest facilities to enable interpretation */ + if (test_kvm_facility(vcpu->kvm, 11)) + vcpu->arch.sie_block->ecb |= ECB_PTF; + /* Indicate this is a new vcpu */ + vcpu->arch.prev_cpu = S390_KVM_TOPOLOGY_NEW_CPU; + if (test_kvm_facility(vcpu->kvm, 73)) vcpu->arch.sie_block->ecb |= ECB_TE; if (!kvm_is_ucontrol(vcpu->kvm)) diff --git a/arch/s390/kvm/kvm-s390.h b/arch/s390/kvm/kvm-s390.h index 497d52a83c78..5fd5e635a611 100644 --- a/arch/s390/kvm/kvm-s390.h +++ b/arch/s390/kvm/kvm-s390.h @@ -514,4 +514,29 @@ void kvm_s390_vcpu_crypto_reset_all(struct kvm *kvm); */ extern unsigned int diag9c_forwarding_hz; +#define S390_KVM_TOPOLOGY_NEW_CPU -1 +/** + * kvm_s390_topology_changed + * @vcpu: the virtual CPU + * + * If the topology facility is present, checks if the CPU toplogy + * viewed by the guest changed due to load balancing or CPU hotplug. + */ +static inline bool kvm_s390_topology_changed(struct kvm_vcpu *vcpu) +{ + if (!test_kvm_facility(vcpu->kvm, 11)) + return false; + + /* A new vCPU has been hotplugged */ + if (vcpu->arch.prev_cpu == S390_KVM_TOPOLOGY_NEW_CPU) + return true; + + /* The real CPU backing up the vCPU is still on same socket */ + if (cpumask_test_cpu(vcpu->cpu, + topology_core_cpumask(vcpu->arch.prev_cpu))) + return false; + + return true; +} + #endif diff --git a/arch/s390/kvm/priv.c b/arch/s390/kvm/priv.c index 0e8603acc105..d9e16b09c8bf 100644 --- a/arch/s390/kvm/priv.c +++ b/arch/s390/kvm/priv.c @@ -874,10 +874,12 @@ static int handle_stsi(struct kvm_vcpu *vcpu) if (vcpu->arch.sie_block->gpsw.mask & PSW_MASK_PSTATE) return kvm_s390_inject_program_int(vcpu, PGM_PRIVILEGED_OP); - if (fc > 3) { - kvm_s390_set_psw_cc(vcpu, 3); - return 0; - } + if (fc > 3 && fc != 15) + goto out_no_data; + + /* fc 15 is provided with PTF/CPU topology support */ + if (fc == 15 && !test_kvm_facility(vcpu->kvm, 11)) + goto out_no_data; if (vcpu->run->s.regs.gprs[0] & 0x0fffff00 || vcpu->run->s.regs.gprs[1] & 0xffff0000) @@ -911,6 +913,10 @@ static int handle_stsi(struct kvm_vcpu *vcpu) goto out_no_data; handle_stsi_3_2_2(vcpu, (void *) mem); break; + case 15: + trace_kvm_s390_handle_stsi(vcpu, fc, sel1, sel2, operand2); + insert_stsi_usr_data(vcpu, operand2, ar, fc, sel1, sel2); + return -EREMOTE; } if (kvm_s390_pv_cpu_is_protected(vcpu)) { memcpy((void *)sida_origin(vcpu->arch.sie_block), (void *)mem, diff --git a/arch/s390/kvm/vsie.c b/arch/s390/kvm/vsie.c index dada78b92691..4f4fee697550 100644 --- a/arch/s390/kvm/vsie.c +++ b/arch/s390/kvm/vsie.c @@ -503,6 +503,9 @@ static int shadow_scb(struct kvm_vcpu *vcpu, struct vsie_page *vsie_page) /* Host-protection-interruption introduced with ESOP */ if (test_kvm_cpu_feat(vcpu->kvm, KVM_S390_VM_CPU_FEAT_ESOP)) scb_s->ecb |= scb_o->ecb & ECB_HOSTPROTINT; + /* CPU Topology */ + if (test_kvm_facility(vcpu->kvm, 11)) + scb_s->ecb |= scb_o->ecb & ECB_PTF; /* transactional execution */ if (test_kvm_facility(vcpu->kvm, 73) && wants_tx) { /* remap the prefix is tx is toggled on */ diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h index 6a184d260c7f..538a2f9cf42d 100644 --- a/include/uapi/linux/kvm.h +++ b/include/uapi/linux/kvm.h @@ -1152,6 +1152,7 @@ struct kvm_ppc_resize_hpt { #define KVM_CAP_DISABLE_QUIRKS2 213 /* #define KVM_CAP_VM_TSC_CONTROL 214 */ #define KVM_CAP_SYSTEM_EVENT_DATA 215 +#define KVM_CAP_S390_CPU_TOPOLOGY 216 #ifdef KVM_CAP_IRQ_ROUTING
We let the userland hypervisor know if the machine support the CPU topology facility using a new KVM capability: KVM_CAP_S390_CPU_TOPOLOGY. The PTF instruction will report a topology change if there is any change with a previous STSI_15_1_2 SYSIB. Changes inside a STSI_15_1_2 SYSIB occur if CPU bits are set or clear inside the CPU Topology List Entry CPU mask field, which happens with changes in CPU polarization, dedication, CPU types and adding or removing CPUs in a socket. The reporting to the guest is done using the Multiprocessor Topology-Change-Report (MTCR) bit of the utility entry of the guest's SCA which will be cleared during the interpretation of PTF. To check if the topology has been modified we use a new field of the arch vCPU to save the previous real CPU ID at the end of a schedule and verify on next schedule that the CPU used is in the same socket. We do not report polarization, CPU Type or dedication change. STSI(15.1.x) gives information on the CPU configuration topology. Let's accept the interception of STSI with the function code 15 and let the userland part of the hypervisor handle it when userland support the CPU Topology facility. Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> --- Documentation/virt/kvm/api.rst | 16 +++++++++++ arch/s390/include/asm/kvm_host.h | 12 ++++++-- arch/s390/kvm/kvm-s390.c | 49 +++++++++++++++++++++++++++++++- arch/s390/kvm/kvm-s390.h | 25 ++++++++++++++++ arch/s390/kvm/priv.c | 14 ++++++--- arch/s390/kvm/vsie.c | 3 ++ include/uapi/linux/kvm.h | 1 + 7 files changed, 112 insertions(+), 8 deletions(-)