Hi all,
This is only a new rebase to keep on sync with Linux development.
This new series add the implementation of interpretation for
the PTF instruction.
The series provides:
1- interception of the STSI instruction forwarding the CPU topology
2- interpretation of the PTF instruction
3- a KVM capability for the userland hypervisor to ask KVM to
setup PTF interpretation.
0- Foreword
The S390 CPU topology is reported using two instructions:
- PTF, to get information if the CPU topology did change since last
PTF instruction or a subsystem reset.
- STSI, to get the topology information, consisting of the topology
of the CPU inside the sockets, of the sockets inside the books etc.
The PTF(2) instruction report a change if the STSI(15.1.2) instruction
will report a difference with the last STSI(15.1.2) instruction*.
With the SIE interpretation, the PTF(2) instruction will report a
change to the guest if the host sets the SCA.MTCR bit.
*The STSI(15.1.2) instruction reports:
- The cores address within a socket
- The polarization of the cores
- The CPU type of the cores
- If the cores are dedicated or not
We decided to implement the CPU topology for S390 in several steps:
- first we report CPU hotplug
- modification of the CPU mask inside sockets
In future development we will provide:
- handling of shared CPUs
- reporting of the CPU Type
- reporting of the polarization
1- Interception of STSI
To provide Topology information to the guest through the STSI
instruction, we forward STSI with Function Code 15 to the
userland hypervisor which will take care to provide the right
information to the guest.
To let the guest use both the PTF instruction to check if a topology
change occurred and sthe STSI_15.x.x instruction we add a new KVM
capability to enable the topology facility.
2- Interpretation of PTF with FC(2)
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 prev_cpu, 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, this field is initialized to -1 on vCPU creation.
Regards,
Pierre
Pierre Morel (1):
s390x: KVM: guest support for topology function
Documentation/virt/kvm/api.rst | 16 +++++++++++
arch/s390/include/asm/kvm_host.h | 12 ++++++--
arch/s390/kvm/kvm-s390.c | 48 +++++++++++++++++++++++++++++++-
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, 111 insertions(+), 8 deletions(-)
--
2.27.0
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 <[email protected]>
Reviewed-by: Claudio Imbrenda <[email protected]>
---
Documentation/virt/kvm/api.rst | 16 +++++++++++
arch/s390/include/asm/kvm_host.h | 12 ++++++--
arch/s390/kvm/kvm-s390.c | 48 +++++++++++++++++++++++++++++++-
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, 111 insertions(+), 8 deletions(-)
diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
index a4267104db50..8b8e8b5758e0 100644
--- a/Documentation/virt/kvm/api.rst
+++ b/Documentation/virt/kvm/api.rst
@@ -7561,3 +7561,19 @@ The argument to KVM_ENABLE_CAP is also a bitmask, and must be a subset
of the result of KVM_CHECK_EXTENSION. KVM will forward to userspace
the hypercalls whose corresponding bit is in the argument, and return
ENOSYS for the others.
+
+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 a22c9266ea05..c7d5720d6aec 100644
--- a/arch/s390/include/asm/kvm_host.h
+++ b/arch/s390/include/asm/kvm_host.h
@@ -95,15 +95,19 @@ struct bsca_block {
union ipte_control ipte_control;
__u64 reserved[5];
__u64 mcn;
- __u64 reserved2;
+#define ESCA_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];
};
@@ -247,6 +251,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
@@ -748,6 +753,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 2296b1ff1e02..af7ea8488fa2 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;
@@ -3043,18 +3060,40 @@ __u64 kvm_s390_get_cpu_timer(struct kvm_vcpu *vcpu)
return value;
}
-void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
+/**
+ * kvm_s390_vcpu_set_mtcr
+ * @vcp: the virtual CPU
+ *
+ * Is only relevant if the topology facility is present.
+ *
+ * Updates the Multiprocessor Topology-Change-Report to signal
+ * the guest with a topology change.
+ */
+static void kvm_s390_vcpu_set_mtcr(struct kvm_vcpu *vcpu)
{
+ struct esca_block *esca = vcpu->kvm->arch.sca;
+
+ ipte_lock(vcpu);
+ WRITE_ONCE(esca->utility, ESCA_UTILITY_MTCR);
+ ipte_unlock(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_vcpu_set_mtcr(vcpu);
}
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);
@@ -3174,6 +3213,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 098831e815e6..af04ffbfd587 100644
--- a/arch/s390/kvm/kvm-s390.h
+++ b/arch/s390/kvm/kvm-s390.h
@@ -503,4 +503,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 moved to another socket */
+ if (topology_physical_package_id(vcpu->cpu) !=
+ topology_physical_package_id(vcpu->arch.prev_cpu))
+ return true;
+
+ return false;
+}
+
#endif
diff --git a/arch/s390/kvm/priv.c b/arch/s390/kvm/priv.c
index 417154b314a6..5ff6be498cbd 100644
--- a/arch/s390/kvm/priv.c
+++ b/arch/s390/kvm/priv.c
@@ -861,10 +861,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)
@@ -898,6 +900,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 acda4b6fc851..da0397cf2cc7 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 5191b57e1562..23e3913992c5 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -1134,6 +1134,7 @@ struct kvm_ppc_resize_hpt {
#define KVM_CAP_VM_GPA_BITS 207
#define KVM_CAP_XSAVE2 208
#define KVM_CAP_SYS_ATTRIBUTES 209
+#define KVM_CAP_S390_CPU_TOPOLOGY 210
#ifdef KVM_CAP_IRQ_ROUTING
--
2.27.0
On Thu, 2022-02-17 at 10:59 +0100, Pierre Morel wrote:
[...]
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index 2296b1ff1e02..af7ea8488fa2 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
[...]
>
> -void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
> +/**
> + * kvm_s390_vcpu_set_mtcr
> + * @vcp: the virtual CPU
> + *
> + * Is only relevant if the topology facility is present.
> + *
> + * Updates the Multiprocessor Topology-Change-Report to signal
> + * the guest with a topology change.
> + */
> +static void kvm_s390_vcpu_set_mtcr(struct kvm_vcpu *vcpu)
> {
> + struct esca_block *esca = vcpu->kvm->arch.sca;
utility is at the same offset for the bsca and the esca, still
wondering whether it is a good idea to assume esca here...
[...]
> diff --git a/arch/s390/kvm/kvm-s390.h b/arch/s390/kvm/kvm-s390.h
> index 098831e815e6..af04ffbfd587 100644
> --- a/arch/s390/kvm/kvm-s390.h
> +++ b/arch/s390/kvm/kvm-s390.h
> @@ -503,4 +503,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 moved to another socket
> */
> + if (topology_physical_package_id(vcpu->cpu) !=
> + topology_physical_package_id(vcpu->arch.prev_cpu))
> + return true;
Why is it OK to look just at the physical package ID here? What if the
vcpu for example moves to a different book, which has a core with the
same physical package ID?
On 2/17/22 18:17, Nico Boehr wrote:
> On Thu, 2022-02-17 at 10:59 +0100, Pierre Morel wrote:
> [...]
>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
>> index 2296b1ff1e02..af7ea8488fa2 100644
>> --- a/arch/s390/kvm/kvm-s390.c
>> +++ b/arch/s390/kvm/kvm-s390.c
> [...]
>>
>> -void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
>> +/**
>> + * kvm_s390_vcpu_set_mtcr
>> + * @vcp: the virtual CPU
>> + *
>> + * Is only relevant if the topology facility is present.
>> + *
>> + * Updates the Multiprocessor Topology-Change-Report to signal
>> + * the guest with a topology change.
>> + */
>> +static void kvm_s390_vcpu_set_mtcr(struct kvm_vcpu *vcpu)
>> {
>> + struct esca_block *esca = vcpu->kvm->arch.sca;
>
> utility is at the same offset for the bsca and the esca, still
> wondering whether it is a good idea to assume esca here...
We can take bsca to be coherent with the include file where we define
ESCA_UTILITY_MTCR inside the bsca.
And we can rename the define to SCA_UTILITY_MTCR as it is common for
both BSCA and ESCA the (E) is too much.
>
> [...]
>> diff --git a/arch/s390/kvm/kvm-s390.h b/arch/s390/kvm/kvm-s390.h
>> index 098831e815e6..af04ffbfd587 100644
>> --- a/arch/s390/kvm/kvm-s390.h
>> +++ b/arch/s390/kvm/kvm-s390.h
>> @@ -503,4 +503,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 moved to another socket
>> */
>> + if (topology_physical_package_id(vcpu->cpu) !=
>> + topology_physical_package_id(vcpu->arch.prev_cpu))
>> + return true;
>
> Why is it OK to look just at the physical package ID here? What if the
> vcpu for example moves to a different book, which has a core with the
> same physical package ID?
>
You are right, we should look at the drawer and book id too.
Something like that I think:
if ((topology_physical_package_id(vcpu->cpu) !=
topology_physical_package_id(vcpu->arch.prev_cpu)) ||
(topology_book_id(vcpu->cpu) !=
topology_book_id(vcpu->arch.prev_cpu)) ||
(topology_drawer_id(vcpu->cpu) !=
topology_drawer_id(vcpu->arch.prev_cpu)))
return true;
Thanks,
regards,
Pierre
--
Pierre Morel
IBM Lab Boeblingen
On 2/18/22 14:13, Pierre Morel wrote:
>
>
> On 2/17/22 18:17, Nico Boehr wrote:
>> On Thu, 2022-02-17 at 10:59 +0100, Pierre Morel wrote:
>> [...]
>>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
>>> index 2296b1ff1e02..af7ea8488fa2 100644
>>> --- a/arch/s390/kvm/kvm-s390.c
>>> +++ b/arch/s390/kvm/kvm-s390.c
>> [...]
Why is there no interface to clear the SCA_UTILITY_MTCR on a subsystem
reset?
>>>
>>> -void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
>>> +/**
>>> + * kvm_s390_vcpu_set_mtcr
>>> + * @vcp: the virtual CPU
>>> + *
>>> + * Is only relevant if the topology facility is present.
>>> + *
>>> + * Updates the Multiprocessor Topology-Change-Report to signal
>>> + * the guest with a topology change.
>>> + */
>>> +static void kvm_s390_vcpu_set_mtcr(struct kvm_vcpu *vcpu)
>>> {
>>> + struct esca_block *esca = vcpu->kvm->arch.sca;
>>
>> utility is at the same offset for the bsca and the esca, still
>> wondering whether it is a good idea to assume esca here...
>
> We can take bsca to be coherent with the include file where we define
> ESCA_UTILITY_MTCR inside the bsca.
> And we can rename the define to SCA_UTILITY_MTCR as it is common for
> both BSCA and ESCA the (E) is too much.
Yes and maybe add a comment that it's at the same offset for esca so
there won't come up further questions in the future.
>
>>
>> [...]
>>> diff --git a/arch/s390/kvm/kvm-s390.h b/arch/s390/kvm/kvm-s390.h
>>> index 098831e815e6..af04ffbfd587 100644
>>> --- a/arch/s390/kvm/kvm-s390.h
>>> +++ b/arch/s390/kvm/kvm-s390.h
>>> @@ -503,4 +503,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 moved to another socket
>>> */
>>> + if (topology_physical_package_id(vcpu->cpu) !=
>>> + topology_physical_package_id(vcpu->arch.prev_cpu))
>>> + return true;
>>
>> Why is it OK to look just at the physical package ID here? What if the
>> vcpu for example moves to a different book, which has a core with the
>> same physical package ID?
I'll need to look up stsi 15* output to understand this.
But the architecture states that any change to the stsi 15 output sets
the change bit so I'd guess Nico is correct.
>>
>
> You are right, we should look at the drawer and book id too.
> Something like that I think:
>
> if ((topology_physical_package_id(vcpu->cpu) !=
> topology_physical_package_id(vcpu->arch.prev_cpu)) ||
> (topology_book_id(vcpu->cpu) !=
> topology_book_id(vcpu->arch.prev_cpu)) ||
> (topology_drawer_id(vcpu->cpu) !=
> topology_drawer_id(vcpu->arch.prev_cpu)))
> return true;
>
>
> Thanks,
> regards,
> Pierre
On 2/18/22 15:28, Janosch Frank wrote:
> On 2/18/22 14:13, Pierre Morel wrote:
>>
>>
>> On 2/17/22 18:17, Nico Boehr wrote:
>>> On Thu, 2022-02-17 at 10:59 +0100, Pierre Morel wrote:
>>> [...]
>>>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
>>>> index 2296b1ff1e02..af7ea8488fa2 100644
>>>> --- a/arch/s390/kvm/kvm-s390.c
>>>> +++ b/arch/s390/kvm/kvm-s390.c
>>> [...]
>
> Why is there no interface to clear the SCA_UTILITY_MTCR on a subsystem
> reset?
Right, I had one in my first version based on interception but I forgot
to implement an equivalent for KVM as I modified the implementation for
interpretation.
I will add this.
>
>
>>>> -void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
>>>> +/**
>>>> + * kvm_s390_vcpu_set_mtcr
>>>> + * @vcp: the virtual CPU
>>>> + *
>>>> + * Is only relevant if the topology facility is present.
>>>> + *
>>>> + * Updates the Multiprocessor Topology-Change-Report to signal
>>>> + * the guest with a topology change.
>>>> + */
>>>> +static void kvm_s390_vcpu_set_mtcr(struct kvm_vcpu *vcpu)
>>>> {
>>>> + struct esca_block *esca = vcpu->kvm->arch.sca;
>>>
>>> utility is at the same offset for the bsca and the esca, still
>>> wondering whether it is a good idea to assume esca here...
>>
>> We can take bsca to be coherent with the include file where we define
>> ESCA_UTILITY_MTCR inside the bsca.
>> And we can rename the define to SCA_UTILITY_MTCR as it is common for
>> both BSCA and ESCA the (E) is too much.
>
> Yes and maybe add a comment that it's at the same offset for esca so
> there won't come up further questions in the future.
OK
>
>>
>>>
>>> [...]
>>>> diff --git a/arch/s390/kvm/kvm-s390.h b/arch/s390/kvm/kvm-s390.h
>>>> index 098831e815e6..af04ffbfd587 100644
>>>> --- a/arch/s390/kvm/kvm-s390.h
>>>> +++ b/arch/s390/kvm/kvm-s390.h
>>>> @@ -503,4 +503,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 moved to another socket
>>>> */
>>>> + if (topology_physical_package_id(vcpu->cpu) !=
>>>> + topology_physical_package_id(vcpu->arch.prev_cpu))
>>>> + return true;
>>>
>>> Why is it OK to look just at the physical package ID here? What if the
>>> vcpu for example moves to a different book, which has a core with the
>>> same physical package ID?
>
> I'll need to look up stsi 15* output to understand this.
> But the architecture states that any change to the stsi 15 output sets
> the change bit so I'd guess Nico is correct.
>
Yes, Nico is correct, as I already answered, however it is not any
change of stsi(15) but a change of stsi(15.1.2) output which sets the
change bit.
However the socket identifier is relative to the book and not unique for
the all system.
The solution given by Heiko is, of course, the most elegant so I will
use it.
Thanks,
regards,
Pierre
>
--
Pierre Morel
IBM Lab Boeblingen
On 2/18/22 16:10, Heiko Carstens wrote:
>>>> + /* The real CPU backing up the vCPU moved to another socket
>>>> */
>>>> + if (topology_physical_package_id(vcpu->cpu) !=
>>>> + topology_physical_package_id(vcpu->arch.prev_cpu))
>>>> + return true;
>>>
>>> Why is it OK to look just at the physical package ID here? What if the
>>> vcpu for example moves to a different book, which has a core with the
>>> same physical package ID?
>>>
>>
>> You are right, we should look at the drawer and book id too.
>> Something like that I think:
>>
>> if ((topology_physical_package_id(vcpu->cpu) !=
>> topology_physical_package_id(vcpu->arch.prev_cpu)) ||
>> (topology_book_id(vcpu->cpu) !=
>> topology_book_id(vcpu->arch.prev_cpu)) ||
>> (topology_drawer_id(vcpu->cpu) !=
>> topology_drawer_id(vcpu->arch.prev_cpu)))
>> return true;
>
> You only need to check if prev_cpu is present in topology_core_cpumask(cpu).
>
Yes, thanks.
Regards,
Pierre
--
Pierre Morel
IBM Lab Boeblingen
On 2/18/22 18:27, Pierre Morel wrote:
>
>
> On 2/18/22 15:28, Janosch Frank wrote:
>> On 2/18/22 14:13, Pierre Morel wrote:
>>>
>>>
>>> On 2/17/22 18:17, Nico Boehr wrote:
>>>> On Thu, 2022-02-17 at 10:59 +0100, Pierre Morel wrote:
>>>> [...]
>>>>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
>>>>> index 2296b1ff1e02..af7ea8488fa2 100644
>>>>> --- a/arch/s390/kvm/kvm-s390.c
>>>>> +++ b/arch/s390/kvm/kvm-s390.c
>>>> [...]
>>
>> Why is there no interface to clear the SCA_UTILITY_MTCR on a subsystem
>> reset?
>
> Right, I had one in my first version based on interception but I forgot
> to implement an equivalent for KVM as I modified the implementation for
> interpretation.
> I will add this.
>
>>
>>
>>>>> -void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
>>>>> +/**
>>>>> + * kvm_s390_vcpu_set_mtcr
>>>>> + * @vcp: the virtual CPU
>>>>> + *
>>>>> + * Is only relevant if the topology facility is present.
>>>>> + *
>>>>> + * Updates the Multiprocessor Topology-Change-Report to signal
>>>>> + * the guest with a topology change.
>>>>> + */
>>>>> +static void kvm_s390_vcpu_set_mtcr(struct kvm_vcpu *vcpu)
>>>>> {
>>>>> + struct esca_block *esca = vcpu->kvm->arch.sca;
>>>>
>>>> utility is at the same offset for the bsca and the esca, still
>>>> wondering whether it is a good idea to assume esca here...
>>>
>>> We can take bsca to be coherent with the include file where we define
>>> ESCA_UTILITY_MTCR inside the bsca.
>>> And we can rename the define to SCA_UTILITY_MTCR as it is common for
>>> both BSCA and ESCA the (E) is too much.
>>
>> Yes and maybe add a comment that it's at the same offset for esca so
>> there won't come up further questions in the future.
>
> OK
>
>>
>>>
>>>>
>>>> [...]
>>>>> diff --git a/arch/s390/kvm/kvm-s390.h b/arch/s390/kvm/kvm-s390.h
>>>>> index 098831e815e6..af04ffbfd587 100644
>>>>> --- a/arch/s390/kvm/kvm-s390.h
>>>>> +++ b/arch/s390/kvm/kvm-s390.h
>>>>> @@ -503,4 +503,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 moved to another socket
>>>>> */
>>>>> + if (topology_physical_package_id(vcpu->cpu) !=
>>>>> + topology_physical_package_id(vcpu->arch.prev_cpu))
>>>>> + return true;
>>>>
>>>> Why is it OK to look just at the physical package ID here? What if the
>>>> vcpu for example moves to a different book, which has a core with the
>>>> same physical package ID?
>>
>> I'll need to look up stsi 15* output to understand this.
>> But the architecture states that any change to the stsi 15 output sets
>> the change bit so I'd guess Nico is correct.
>>
>
> Yes, Nico is correct, as I already answered, however it is not any
> change of stsi(15) but a change of stsi(15.1.2) output which sets the
> change bit.
hum, that is what the POP says but in fact you are right a change of
topology that changes the output of any STSI(15) sets the topology
change report bit as the output of STSI(15.1.2) would be changed too
obviously.
Regards,
Pierre
--
Pierre Morel
IBM Lab Boeblingen
> > > +???????/* The real CPU backing up the vCPU moved to another socket
> > > */
> > > +???????if (topology_physical_package_id(vcpu->cpu) !=
> > > +?????????? topology_physical_package_id(vcpu->arch.prev_cpu))
> > > +???????????????return true;
> >
> > Why is it OK to look just at the physical package ID here? What if the
> > vcpu for example moves to a different book, which has a core with the
> > same physical package ID?
> >
>
> You are right, we should look at the drawer and book id too.
> Something like that I think:
>
> if ((topology_physical_package_id(vcpu->cpu) !=
> topology_physical_package_id(vcpu->arch.prev_cpu)) ||
> (topology_book_id(vcpu->cpu) !=
> topology_book_id(vcpu->arch.prev_cpu)) ||
> (topology_drawer_id(vcpu->cpu) !=
> topology_drawer_id(vcpu->arch.prev_cpu)))
> return true;
You only need to check if prev_cpu is present in topology_core_cpumask(cpu).
On 2/18/22 19:24, Pierre Morel wrote:
>
>
> On 2/18/22 18:27, Pierre Morel wrote:
>>
>>
>> On 2/18/22 15:28, Janosch Frank wrote:
>>> On 2/18/22 14:13, Pierre Morel wrote:
>>>>
>>>>
>>>> On 2/17/22 18:17, Nico Boehr wrote:
>>>>> On Thu, 2022-02-17 at 10:59 +0100, Pierre Morel wrote:
>>>>> [...]
>>>>>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
>>>>>> index 2296b1ff1e02..af7ea8488fa2 100644
>>>>>> --- a/arch/s390/kvm/kvm-s390.c
>>>>>> +++ b/arch/s390/kvm/kvm-s390.c
>>>>> [...]
>>>
>>> Why is there no interface to clear the SCA_UTILITY_MTCR on a subsystem
>>> reset?
>>
>> Right, I had one in my first version based on interception but I forgot
>> to implement an equivalent for KVM as I modified the implementation for
>> interpretation.
>> I will add this.
>>
>>>
>>>
>>>>>> -void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
>>>>>> +/**
>>>>>> + * kvm_s390_vcpu_set_mtcr
>>>>>> + * @vcp: the virtual CPU
>>>>>> + *
>>>>>> + * Is only relevant if the topology facility is present.
>>>>>> + *
>>>>>> + * Updates the Multiprocessor Topology-Change-Report to signal
>>>>>> + * the guest with a topology change.
>>>>>> + */
>>>>>> +static void kvm_s390_vcpu_set_mtcr(struct kvm_vcpu *vcpu)
>>>>>> {
>>>>>> + struct esca_block *esca = vcpu->kvm->arch.sca;
>>>>>
>>>>> utility is at the same offset for the bsca and the esca, still
>>>>> wondering whether it is a good idea to assume esca here...
>>>>
>>>> We can take bsca to be coherent with the include file where we define
>>>> ESCA_UTILITY_MTCR inside the bsca.
>>>> And we can rename the define to SCA_UTILITY_MTCR as it is common for
>>>> both BSCA and ESCA the (E) is too much.
>>>
>>> Yes and maybe add a comment that it's at the same offset for esca so
>>> there won't come up further questions in the future.
>>
>> OK
>>
>>>
>>>>
>>>>>
>>>>> [...]
>>>>>> diff --git a/arch/s390/kvm/kvm-s390.h b/arch/s390/kvm/kvm-s390.h
>>>>>> index 098831e815e6..af04ffbfd587 100644
>>>>>> --- a/arch/s390/kvm/kvm-s390.h
>>>>>> +++ b/arch/s390/kvm/kvm-s390.h
>>>>>> @@ -503,4 +503,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 moved to another socket
>>>>>> */
>>>>>> + if (topology_physical_package_id(vcpu->cpu) !=
>>>>>> + topology_physical_package_id(vcpu->arch.prev_cpu))
>>>>>> + return true;
>>>>>
>>>>> Why is it OK to look just at the physical package ID here? What if the
>>>>> vcpu for example moves to a different book, which has a core with the
>>>>> same physical package ID?
>>>
>>> I'll need to look up stsi 15* output to understand this.
>>> But the architecture states that any change to the stsi 15 output sets
>>> the change bit so I'd guess Nico is correct.
>>>
>>
>> Yes, Nico is correct, as I already answered, however it is not any
>> change of stsi(15) but a change of stsi(15.1.2) output which sets the
>> change bit.
>
> hum, that is what the POP says but in fact you are right a change of
> topology that changes the output of any STSI(15) sets the topology
> change report bit as the output of STSI(15.1.2) would be changed too
> obviously.
In this case I was just being too lazy to look up the correct query code
but I knew it started with fc 15. It was Friday after all :-)
>
> Regards,
> Pierre
>