Hi all,
This new spin adds bug correction and simplification of ipte_lock
to the series for the implementation of interpretation for the PTF
instruction and the handling of the STSI 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 (3):
s390x: KVM: ipte lock for SCA access should be contained in KVM
s390x: KVM: guest support for topology function
s390x: KVM: resetting the Topology-Change-Report
Documentation/virt/kvm/api.rst | 16 ++++
arch/s390/include/asm/kvm_host.h | 12 ++-
arch/s390/include/uapi/asm/kvm.h | 5 ++
arch/s390/kvm/gaccess.c | 96 +++++++++++------------
arch/s390/kvm/gaccess.h | 6 +-
arch/s390/kvm/kvm-s390.c | 128 ++++++++++++++++++++++++++++++-
arch/s390/kvm/kvm-s390.h | 25 ++++++
arch/s390/kvm/priv.c | 20 +++--
arch/s390/kvm/vsie.c | 3 +
include/uapi/linux/kvm.h | 1 +
10 files changed, 250 insertions(+), 62 deletions(-)
--
2.27.0
Changelog:
from v8 to v9
- bug correction in kvm_s390_topology_changed
(Heiko)
- simplification for ipte_lock/unlock to use kvm
as arg instead of vcpu and test on sclp.has_siif
instead of the SIE ECA_SII.
(David)
- use of a single value for reporting if the
topology changed instead of a structure
(David)
from v7 to v8
- implement reset handling
(Janosch)
- change the way to check if the topology changed
(Nico, Heiko)
from v6 to v7
- rebase
from v5 to v6
- make the subject more accurate
(Claudio)
- Change the kvm_s390_set_mtcr() function to have vcpu in the name
(Janosch)
- Replace the checks on ECB_PTF wit the check of facility 11
(Janosch)
- modify kvm_arch_vcpu_load, move the check in a function in
the header file
(Janosh)
- No magical number replace the "new cpu value" of -1 with a define
(Janosch)
- Make the checks for STSI validity clearer
(Janosch)
from v4 tp v5
- modify the way KVM_CAP is tested to be OK with vsie
(David)
from v3 to v4
- squatch both patches
(David)
- Added Documentation
(David)
- Modified the detection for new vCPUs
(Pierre)
from v2 to v3
- use PTF interpretation
(Christian)
- optimize arch_update_cpu_topology using PTF
(Pierre)
from v1 to v2:
- Add a KVM capability to let QEMU know we support PTF and STSI 15
(David)
- check KVM facility 11 before accepting STSI fc 15
(David)
- handle all we can in userland
(David)
- add tracing to STSI fc 15
(Connie)
During a subsystem reset the Topology-Change-Report is cleared.
Let's give userland the possibility to clear the MTCR in the case
of a subsystem reset.
To migrate the MTCR, let's give userland the possibility to
query the MTCR state.
Signed-off-by: Pierre Morel <[email protected]>
---
arch/s390/include/uapi/asm/kvm.h | 5 ++
arch/s390/kvm/kvm-s390.c | 79 ++++++++++++++++++++++++++++++++
2 files changed, 84 insertions(+)
diff --git a/arch/s390/include/uapi/asm/kvm.h b/arch/s390/include/uapi/asm/kvm.h
index 7a6b14874d65..abdcf4069343 100644
--- a/arch/s390/include/uapi/asm/kvm.h
+++ b/arch/s390/include/uapi/asm/kvm.h
@@ -74,6 +74,7 @@ struct kvm_s390_io_adapter_req {
#define KVM_S390_VM_CRYPTO 2
#define KVM_S390_VM_CPU_MODEL 3
#define KVM_S390_VM_MIGRATION 4
+#define KVM_S390_VM_CPU_TOPOLOGY 5
/* kvm attributes for mem_ctrl */
#define KVM_S390_VM_MEM_ENABLE_CMMA 0
@@ -171,6 +172,10 @@ struct kvm_s390_vm_cpu_subfunc {
#define KVM_S390_VM_MIGRATION_START 1
#define KVM_S390_VM_MIGRATION_STATUS 2
+/* kvm attributes for cpu topology */
+#define KVM_S390_VM_CPU_TOPO_MTR_CLEAR 0
+#define KVM_S390_VM_CPU_TOPO_MTR_SET 1
+
/* for KVM_GET_REGS and KVM_SET_REGS */
struct kvm_regs {
/* general purpose regs for s390 */
diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index c8bdce31464f..80a1244f0ead 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -1731,6 +1731,76 @@ static void kvm_s390_sca_set_mtcr(struct kvm *kvm)
ipte_unlock(kvm);
}
+/**
+ * kvm_s390_sca_clear_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_clear_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_set_topology(struct kvm *kvm, struct kvm_device_attr *attr)
+{
+ if (!test_kvm_facility(kvm, 11))
+ return -ENXIO;
+
+ switch (attr->attr) {
+ case KVM_S390_VM_CPU_TOPO_MTR_SET:
+ kvm_s390_sca_set_mtcr(kvm);
+ break;
+ case KVM_S390_VM_CPU_TOPO_MTR_CLEAR:
+ kvm_s390_sca_clear_mtcr(kvm);
+ break;
+ }
+ return 0;
+}
+
+/**
+ * kvm_s390_sca_get_mtcr
+ * @kvm: guest KVM description
+ *
+ * Is only relevant if the topology facility is present,
+ * the caller should check KVM facility 11
+ *
+ * reports to QEMU the Multiprocessor Topology-Change-Report.
+ */
+static int kvm_s390_sca_get_mtcr(struct kvm *kvm)
+{
+ struct bsca_block *sca = kvm->arch.sca; /* SCA version doesn't matter */
+ int val;
+
+ ipte_lock(kvm);
+ val = !!(sca->utility & SCA_UTILITY_MTCR);
+ ipte_unlock(kvm);
+
+ return val;
+}
+
+static int kvm_s390_get_topology(struct kvm *kvm, struct kvm_device_attr *attr)
+{
+ int mtcr;
+
+ if (!test_kvm_facility(kvm, 11))
+ return -ENXIO;
+
+ mtcr = kvm_s390_sca_get_mtcr(kvm);
+ if (copy_to_user((void __user *)attr->addr, &mtcr, sizeof(mtcr)))
+ return -EFAULT;
+
+ return 0;
+}
+
static int kvm_s390_vm_set_attr(struct kvm *kvm, struct kvm_device_attr *attr)
{
int ret;
@@ -1751,6 +1821,9 @@ static int kvm_s390_vm_set_attr(struct kvm *kvm, struct kvm_device_attr *attr)
case KVM_S390_VM_MIGRATION:
ret = kvm_s390_vm_set_migration(kvm, attr);
break;
+ case KVM_S390_VM_CPU_TOPOLOGY:
+ ret = kvm_s390_set_topology(kvm, attr);
+ break;
default:
ret = -ENXIO;
break;
@@ -1776,6 +1849,9 @@ static int kvm_s390_vm_get_attr(struct kvm *kvm, struct kvm_device_attr *attr)
case KVM_S390_VM_MIGRATION:
ret = kvm_s390_vm_get_migration(kvm, attr);
break;
+ case KVM_S390_VM_CPU_TOPOLOGY:
+ ret = kvm_s390_get_topology(kvm, attr);
+ break;
default:
ret = -ENXIO;
break;
@@ -1849,6 +1925,9 @@ static int kvm_s390_vm_has_attr(struct kvm *kvm, struct kvm_device_attr *attr)
case KVM_S390_VM_MIGRATION:
ret = 0;
break;
+ case KVM_S390_VM_CPU_TOPOLOGY:
+ ret = test_kvm_facility(kvm, 11) ? 0 : -ENXIO;
+ break;
default:
ret = -ENXIO;
break;
--
2.27.0
On Thu, 12 May 2022 11:31:18 +0200
David Hildenbrand <[email protected]> wrote:
> On 06.05.22 11:24, Pierre Morel wrote:
> > During a subsystem reset the Topology-Change-Report is cleared.
> > Let's give userland the possibility to clear the MTCR in the case
> > of a subsystem reset.
> >
> > To migrate the MTCR, let's give userland the possibility to
> > query the MTCR state.
> >
> > Signed-off-by: Pierre Morel <[email protected]>
> > ---
> > arch/s390/include/uapi/asm/kvm.h | 5 ++
> > arch/s390/kvm/kvm-s390.c | 79 ++++++++++++++++++++++++++++++++
> > 2 files changed, 84 insertions(+)
> >
> > diff --git a/arch/s390/include/uapi/asm/kvm.h b/arch/s390/include/uapi/asm/kvm.h
> > index 7a6b14874d65..abdcf4069343 100644
> > --- a/arch/s390/include/uapi/asm/kvm.h
> > +++ b/arch/s390/include/uapi/asm/kvm.h
> > @@ -74,6 +74,7 @@ struct kvm_s390_io_adapter_req {
> > #define KVM_S390_VM_CRYPTO 2
> > #define KVM_S390_VM_CPU_MODEL 3
> > #define KVM_S390_VM_MIGRATION 4
> > +#define KVM_S390_VM_CPU_TOPOLOGY 5
> >
> > /* kvm attributes for mem_ctrl */
> > #define KVM_S390_VM_MEM_ENABLE_CMMA 0
> > @@ -171,6 +172,10 @@ struct kvm_s390_vm_cpu_subfunc {
> > #define KVM_S390_VM_MIGRATION_START 1
> > #define KVM_S390_VM_MIGRATION_STATUS 2
> >
> > +/* kvm attributes for cpu topology */
> > +#define KVM_S390_VM_CPU_TOPO_MTR_CLEAR 0
> > +#define KVM_S390_VM_CPU_TOPO_MTR_SET 1
> > +
> > /* for KVM_GET_REGS and KVM_SET_REGS */
> > struct kvm_regs {
> > /* general purpose regs for s390 */
> > diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> > index c8bdce31464f..80a1244f0ead 100644
> > --- a/arch/s390/kvm/kvm-s390.c
> > +++ b/arch/s390/kvm/kvm-s390.c
> > @@ -1731,6 +1731,76 @@ static void kvm_s390_sca_set_mtcr(struct kvm *kvm)
> > ipte_unlock(kvm);
> > }
> >
> > +/**
> > + * kvm_s390_sca_clear_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_clear_mtcr(struct kvm *kvm)
> > +{
> > + struct bsca_block *sca = kvm->arch.sca; /* SCA version doesn't matter */
> > +
> > + ipte_lock(kvm);
> > + sca->utility &= ~SCA_UTILITY_MTCR;
>
>
> One space too much.
>
> sca->utility &= ~SCA_UTILITY_MTCR;
>
> > + ipte_unlock(kvm);
> > +}
> > +
> > +static int kvm_s390_set_topology(struct kvm *kvm, struct kvm_device_attr *attr)
> > +{
> > + if (!test_kvm_facility(kvm, 11))
> > + return -ENXIO;
> > +
> > + switch (attr->attr) {
> > + case KVM_S390_VM_CPU_TOPO_MTR_SET:
> > + kvm_s390_sca_set_mtcr(kvm);
> > + break;
> > + case KVM_S390_VM_CPU_TOPO_MTR_CLEAR:
> > + kvm_s390_sca_clear_mtcr(kvm);
> > + break;
> > + }
> > + return 0;
> > +}
> > +
> > +/**
> > + * kvm_s390_sca_get_mtcr
> > + * @kvm: guest KVM description
> > + *
> > + * Is only relevant if the topology facility is present,
> > + * the caller should check KVM facility 11
> > + *
> > + * reports to QEMU the Multiprocessor Topology-Change-Report.
> > + */
> > +static int kvm_s390_sca_get_mtcr(struct kvm *kvm)
> > +{
> > + struct bsca_block *sca = kvm->arch.sca; /* SCA version doesn't matter */
> > + int val;
> > +
> > + ipte_lock(kvm);
> > + val = !!(sca->utility & SCA_UTILITY_MTCR);
> > + ipte_unlock(kvm);
> > +
> > + return val;
> > +}
> > +
> > +static int kvm_s390_get_topology(struct kvm *kvm, struct kvm_device_attr *attr)
> > +{
> > + int mtcr;
>
> I think we prefer something like u16 when copying to user space.
but then userspace also has to expect a u16, right?
>
> > +
> > + if (!test_kvm_facility(kvm, 11))
> > + return -ENXIO;
> > +
> > + mtcr = kvm_s390_sca_get_mtcr(kvm);
> > + if (copy_to_user((void __user *)attr->addr, &mtcr, sizeof(mtcr)))
> > + return -EFAULT;
> > +
> > + return 0;
> > +}
>
> You should probably add documentation, and document that only the last
> bit (0x1) has a meaning.
>
> Apart from that LGTM.
>
On 06.05.22 11:24, Pierre Morel wrote:
> During a subsystem reset the Topology-Change-Report is cleared.
> Let's give userland the possibility to clear the MTCR in the case
> of a subsystem reset.
>
> To migrate the MTCR, let's give userland the possibility to
> query the MTCR state.
>
> Signed-off-by: Pierre Morel <[email protected]>
> ---
> arch/s390/include/uapi/asm/kvm.h | 5 ++
> arch/s390/kvm/kvm-s390.c | 79 ++++++++++++++++++++++++++++++++
> 2 files changed, 84 insertions(+)
>
> diff --git a/arch/s390/include/uapi/asm/kvm.h b/arch/s390/include/uapi/asm/kvm.h
> index 7a6b14874d65..abdcf4069343 100644
> --- a/arch/s390/include/uapi/asm/kvm.h
> +++ b/arch/s390/include/uapi/asm/kvm.h
> @@ -74,6 +74,7 @@ struct kvm_s390_io_adapter_req {
> #define KVM_S390_VM_CRYPTO 2
> #define KVM_S390_VM_CPU_MODEL 3
> #define KVM_S390_VM_MIGRATION 4
> +#define KVM_S390_VM_CPU_TOPOLOGY 5
>
> /* kvm attributes for mem_ctrl */
> #define KVM_S390_VM_MEM_ENABLE_CMMA 0
> @@ -171,6 +172,10 @@ struct kvm_s390_vm_cpu_subfunc {
> #define KVM_S390_VM_MIGRATION_START 1
> #define KVM_S390_VM_MIGRATION_STATUS 2
>
> +/* kvm attributes for cpu topology */
> +#define KVM_S390_VM_CPU_TOPO_MTR_CLEAR 0
> +#define KVM_S390_VM_CPU_TOPO_MTR_SET 1
> +
> /* for KVM_GET_REGS and KVM_SET_REGS */
> struct kvm_regs {
> /* general purpose regs for s390 */
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index c8bdce31464f..80a1244f0ead 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -1731,6 +1731,76 @@ static void kvm_s390_sca_set_mtcr(struct kvm *kvm)
> ipte_unlock(kvm);
> }
>
> +/**
> + * kvm_s390_sca_clear_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_clear_mtcr(struct kvm *kvm)
> +{
> + struct bsca_block *sca = kvm->arch.sca; /* SCA version doesn't matter */
> +
> + ipte_lock(kvm);
> + sca->utility &= ~SCA_UTILITY_MTCR;
One space too much.
sca->utility &= ~SCA_UTILITY_MTCR;
> + ipte_unlock(kvm);
> +}
> +
> +static int kvm_s390_set_topology(struct kvm *kvm, struct kvm_device_attr *attr)
> +{
> + if (!test_kvm_facility(kvm, 11))
> + return -ENXIO;
> +
> + switch (attr->attr) {
> + case KVM_S390_VM_CPU_TOPO_MTR_SET:
> + kvm_s390_sca_set_mtcr(kvm);
> + break;
> + case KVM_S390_VM_CPU_TOPO_MTR_CLEAR:
> + kvm_s390_sca_clear_mtcr(kvm);
> + break;
> + }
> + return 0;
> +}
> +
> +/**
> + * kvm_s390_sca_get_mtcr
> + * @kvm: guest KVM description
> + *
> + * Is only relevant if the topology facility is present,
> + * the caller should check KVM facility 11
> + *
> + * reports to QEMU the Multiprocessor Topology-Change-Report.
> + */
> +static int kvm_s390_sca_get_mtcr(struct kvm *kvm)
> +{
> + struct bsca_block *sca = kvm->arch.sca; /* SCA version doesn't matter */
> + int val;
> +
> + ipte_lock(kvm);
> + val = !!(sca->utility & SCA_UTILITY_MTCR);
> + ipte_unlock(kvm);
> +
> + return val;
> +}
> +
> +static int kvm_s390_get_topology(struct kvm *kvm, struct kvm_device_attr *attr)
> +{
> + int mtcr;
I think we prefer something like u16 when copying to user space.
> +
> + if (!test_kvm_facility(kvm, 11))
> + return -ENXIO;
> +
> + mtcr = kvm_s390_sca_get_mtcr(kvm);
> + if (copy_to_user((void __user *)attr->addr, &mtcr, sizeof(mtcr)))
> + return -EFAULT;
> +
> + return 0;
> +}
You should probably add documentation, and document that only the last
bit (0x1) has a meaning.
Apart from that LGTM.
--
Thanks,
David / dhildenb
>>
>> I think we prefer something like u16 when copying to user space.
>
> but then userspace also has to expect a u16, right?
Yep.
--
Thanks,
David / dhildenb
On 5/12/22 11:31, David Hildenbrand wrote:
> On 06.05.22 11:24, Pierre Morel wrote:
>> During a subsystem reset the Topology-Change-Report is cleared.
>> Let's give userland the possibility to clear the MTCR in the case
>> of a subsystem reset.
>>
>> To migrate the MTCR, let's give userland the possibility to
>> query the MTCR state.
>>
>> Signed-off-by: Pierre Morel <[email protected]>
>> ---
>> arch/s390/include/uapi/asm/kvm.h | 5 ++
>> arch/s390/kvm/kvm-s390.c | 79 ++++++++++++++++++++++++++++++++
>> 2 files changed, 84 insertions(+)
>>
>> diff --git a/arch/s390/include/uapi/asm/kvm.h b/arch/s390/include/uapi/asm/kvm.h
>> index 7a6b14874d65..abdcf4069343 100644
>> --- a/arch/s390/include/uapi/asm/kvm.h
>> +++ b/arch/s390/include/uapi/asm/kvm.h
>> @@ -74,6 +74,7 @@ struct kvm_s390_io_adapter_req {
>> #define KVM_S390_VM_CRYPTO 2
>> #define KVM_S390_VM_CPU_MODEL 3
>> #define KVM_S390_VM_MIGRATION 4
>> +#define KVM_S390_VM_CPU_TOPOLOGY 5
>>
>> /* kvm attributes for mem_ctrl */
>> #define KVM_S390_VM_MEM_ENABLE_CMMA 0
>> @@ -171,6 +172,10 @@ struct kvm_s390_vm_cpu_subfunc {
>> #define KVM_S390_VM_MIGRATION_START 1
>> #define KVM_S390_VM_MIGRATION_STATUS 2
>>
>> +/* kvm attributes for cpu topology */
>> +#define KVM_S390_VM_CPU_TOPO_MTR_CLEAR 0
>> +#define KVM_S390_VM_CPU_TOPO_MTR_SET 1
>> +
>> /* for KVM_GET_REGS and KVM_SET_REGS */
>> struct kvm_regs {
>> /* general purpose regs for s390 */
>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
>> index c8bdce31464f..80a1244f0ead 100644
>> --- a/arch/s390/kvm/kvm-s390.c
>> +++ b/arch/s390/kvm/kvm-s390.c
>> @@ -1731,6 +1731,76 @@ static void kvm_s390_sca_set_mtcr(struct kvm *kvm)
>> ipte_unlock(kvm);
>> }
>>
>> +/**
>> + * kvm_s390_sca_clear_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_clear_mtcr(struct kvm *kvm)
>> +{
>> + struct bsca_block *sca = kvm->arch.sca; /* SCA version doesn't matter */
>> +
>> + ipte_lock(kvm);
>> + sca->utility &= ~SCA_UTILITY_MTCR;
>
>
> One space too much.
>
> sca->utility &= ~SCA_UTILITY_MTCR;
>
>> + ipte_unlock(kvm);
>> +}
>> +
>> +static int kvm_s390_set_topology(struct kvm *kvm, struct kvm_device_attr *attr)
>> +{
>> + if (!test_kvm_facility(kvm, 11))
>> + return -ENXIO;
>> +
>> + switch (attr->attr) {
>> + case KVM_S390_VM_CPU_TOPO_MTR_SET:
>> + kvm_s390_sca_set_mtcr(kvm);
>> + break;
>> + case KVM_S390_VM_CPU_TOPO_MTR_CLEAR:
>> + kvm_s390_sca_clear_mtcr(kvm);
>> + break;
>> + }
>> + return 0;
>> +}
>> +
>> +/**
>> + * kvm_s390_sca_get_mtcr
>> + * @kvm: guest KVM description
>> + *
>> + * Is only relevant if the topology facility is present,
>> + * the caller should check KVM facility 11
>> + *
>> + * reports to QEMU the Multiprocessor Topology-Change-Report.
>> + */
>> +static int kvm_s390_sca_get_mtcr(struct kvm *kvm)
>> +{
>> + struct bsca_block *sca = kvm->arch.sca; /* SCA version doesn't matter */
>> + int val;
>> +
>> + ipte_lock(kvm);
>> + val = !!(sca->utility & SCA_UTILITY_MTCR);
>> + ipte_unlock(kvm);
>> +
>> + return val;
>> +}
>> +
>> +static int kvm_s390_get_topology(struct kvm *kvm, struct kvm_device_attr *attr)
>> +{
>> + int mtcr;
>
> I think we prefer something like u16 when copying to user space.
If you prefer.
The original idea was to have something like a bool but then I should
have change get_mtcr to has_mtcr.
>
>> +
>> + if (!test_kvm_facility(kvm, 11))
>> + return -ENXIO;
>> +
>> + mtcr = kvm_s390_sca_get_mtcr(kvm);
>> + if (copy_to_user((void __user *)attr->addr, &mtcr, sizeof(mtcr)))
>> + return -EFAULT;
>> +
>> + return 0;
>> +}
>
> You should probably add documentation, and document that only the last
> bit (0x1) has a meaning.
>
> Apart from that LGTM.
>
--
Pierre Morel
IBM Lab Boeblingen
On 5/12/22 12:01, David Hildenbrand wrote:
>>>
>>> I think we prefer something like u16 when copying to user space.
>>
>> but then userspace also has to expect a u16, right?
>
> Yep.
>
Yes but in fact, inspired by previous discussion I had on the VFIO
interface, that is the reason why I did prefer an int.
It is much simpler than a u16 and the definition of a bit.
Despite a bit in a u16 is what the s3990 achitecture proposes I thought
we could make it easier on the KVM/QEMU interface.
But if the discussion stops here, I will do as you both propose change
to u16 in KVM and userland and add the documentation for the interface.
Regards,
Pierre
--
Pierre Morel
IBM Lab Boeblingen
On 5/12/22 11:31, David Hildenbrand wrote:
> On 06.05.22 11:24, Pierre Morel wrote:
>> During a subsystem reset the Topology-Change-Report is cleared.
>> Let's give userland the possibility to clear the MTCR in the case
>> of a subsystem reset.
>>
>> To migrate the MTCR, let's give userland the possibility to
>> query the MTCR state.
>>
>> Signed-off-by: Pierre Morel <[email protected]>
>> ---
>> arch/s390/include/uapi/asm/kvm.h | 5 ++
>> arch/s390/kvm/kvm-s390.c | 79 ++++++++++++++++++++++++++++++++
>> 2 files changed, 84 insertions(+)
>>
>> diff --git a/arch/s390/include/uapi/asm/kvm.h b/arch/s390/include/uapi/asm/kvm.h
>> index 7a6b14874d65..abdcf4069343 100644
>> --- a/arch/s390/include/uapi/asm/kvm.h
>> +++ b/arch/s390/include/uapi/asm/kvm.h
>> @@ -74,6 +74,7 @@ struct kvm_s390_io_adapter_req {
>> #define KVM_S390_VM_CRYPTO 2
>> #define KVM_S390_VM_CPU_MODEL 3
>> #define KVM_S390_VM_MIGRATION 4
>> +#define KVM_S390_VM_CPU_TOPOLOGY 5
>>
>> /* kvm attributes for mem_ctrl */
>> #define KVM_S390_VM_MEM_ENABLE_CMMA 0
>> @@ -171,6 +172,10 @@ struct kvm_s390_vm_cpu_subfunc {
>> #define KVM_S390_VM_MIGRATION_START 1
>> #define KVM_S390_VM_MIGRATION_STATUS 2
>>
>> +/* kvm attributes for cpu topology */
>> +#define KVM_S390_VM_CPU_TOPO_MTR_CLEAR 0
>> +#define KVM_S390_VM_CPU_TOPO_MTR_SET 1
>> +
>> /* for KVM_GET_REGS and KVM_SET_REGS */
>> struct kvm_regs {
>> /* general purpose regs for s390 */
>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
>> index c8bdce31464f..80a1244f0ead 100644
>> --- a/arch/s390/kvm/kvm-s390.c
>> +++ b/arch/s390/kvm/kvm-s390.c
>> @@ -1731,6 +1731,76 @@ static void kvm_s390_sca_set_mtcr(struct kvm *kvm)
>> ipte_unlock(kvm);
>> }
>>
>> +/**
>> + * kvm_s390_sca_clear_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_clear_mtcr(struct kvm *kvm)
>> +{
>> + struct bsca_block *sca = kvm->arch.sca; /* SCA version doesn't matter */
>> +
>> + ipte_lock(kvm);
>> + sca->utility &= ~SCA_UTILITY_MTCR;
>
>
> One space too much.
>
> sca->utility &= ~SCA_UTILITY_MTCR;
>
>> + ipte_unlock(kvm);
>> +}
>> +
>> +static int kvm_s390_set_topology(struct kvm *kvm, struct kvm_device_attr *attr)
>> +{
>> + if (!test_kvm_facility(kvm, 11))
>> + return -ENXIO;
>> +
>> + switch (attr->attr) {
>> + case KVM_S390_VM_CPU_TOPO_MTR_SET:
>> + kvm_s390_sca_set_mtcr(kvm);
>> + break;
>> + case KVM_S390_VM_CPU_TOPO_MTR_CLEAR:
>> + kvm_s390_sca_clear_mtcr(kvm);
>> + break;
>> + }
>> + return 0;
>> +}
>> +
>> +/**
>> + * kvm_s390_sca_get_mtcr
>> + * @kvm: guest KVM description
>> + *
>> + * Is only relevant if the topology facility is present,
>> + * the caller should check KVM facility 11
>> + *
>> + * reports to QEMU the Multiprocessor Topology-Change-Report.
>> + */
>> +static int kvm_s390_sca_get_mtcr(struct kvm *kvm)
>> +{
>> + struct bsca_block *sca = kvm->arch.sca; /* SCA version doesn't matter */
>> + int val;
>> +
>> + ipte_lock(kvm);
>> + val = !!(sca->utility & SCA_UTILITY_MTCR);
>> + ipte_unlock(kvm);
>> +
>> + return val;
>> +}
>> +
>> +static int kvm_s390_get_topology(struct kvm *kvm, struct kvm_device_attr *attr)
>> +{
>> + int mtcr;
>
> I think we prefer something like u16 when copying to user space.
I come back here.
I think I prefer to keep the int.
the u16 is more than the MTCR but the entire utility field, so what
should I do:
rename the function to kvm_s390_get_sca_utility() ?
and then should I modify the KVM_S390_VM_CPU_TOPOLOGY
to KVM_S390_VM_SCA_UTILITY ?
I do not like that, I do not think we should report/handle more
information than expected/needed.
I can mask the MTCR bit and return a u16 with bit 0 (0x8000) set
but I find this a little weird
I admit an int is may be not optimal.
logically I should report a bool but I do not like to report a bool
through the UAPI.
The more I think about it the more I think an int is OK.
Or in the case we want to spare memory space I can create a flag in a
u16 but it should theoretically be different than the firmware MTCR bit.
Could be 0x0001.
But still, it is only to leave during the copy_to_user where the copy of
an int may be as good or better than the copy of a u16.
So any more opinion on this?
Regards,
Pierre
>
>> +
>> + if (!test_kvm_facility(kvm, 11))
>> + return -ENXIO;
>> +
>> + mtcr = kvm_s390_sca_get_mtcr(kvm);
>> + if (copy_to_user((void __user *)attr->addr, &mtcr, sizeof(mtcr)))
>> + return -EFAULT;
>> +
>> + return 0;
>> +}
>
> You should probably add documentation, and document that only the last
> bit (0x1) has a meaning.
>
> Apart from that LGTM.
>
--
Pierre Morel
IBM Lab Boeblingen
On 16.05.22 16:21, Pierre Morel wrote:
>
>
> On 5/12/22 12:01, David Hildenbrand wrote:
>>>>
>>>> I think we prefer something like u16 when copying to user space.
>>>
>>> but then userspace also has to expect a u16, right?
>>
>> Yep.
>>
>
> Yes but in fact, inspired by previous discussion I had on the VFIO
> interface, that is the reason why I did prefer an int.
> It is much simpler than a u16 and the definition of a bit.
>
> Despite a bit in a u16 is what the s3990 achitecture proposes I thought
> we could make it easier on the KVM/QEMU interface.
>
> But if the discussion stops here, I will do as you both propose change
> to u16 in KVM and userland and add the documentation for the interface.
In general, we pass via the ABI fixed-sized values -- u8, u16, u32, u64
... instead of int. Simply because sizeof(int) is in theory variable
(e.g., 32bit vs 64bit).
Take a look at arch/s390/include/uapi/asm/kvm.h and you won't find any
usage of int or bool.
Having that said, I'll let the maintainers decide. Using e.g., u8 is
just the natural thing to do on a Linux ABI, but we don't really support
32 bit ... maybe we'll support 128bit at one point? ;)
--
Thanks,
David / dhildenb
Pierre,
please use "KVM: s390x:" and not "s390x: KVM:" for future series.
On 5/18/22 17:26, Christian Borntraeger wrote:
> Pierre,
>
> please use "KVM: s390x:" and not "s390x: KVM:" for future series.
OK, thanks
--
Pierre Morel
IBM Lab Boeblingen
On 5/18/22 16:33, David Hildenbrand wrote:
> On 16.05.22 16:21, Pierre Morel wrote:
>>
>>
>> On 5/12/22 12:01, David Hildenbrand wrote:
>>>>>
>>>>> I think we prefer something like u16 when copying to user space.
>>>>
>>>> but then userspace also has to expect a u16, right?
>>>
>>> Yep.
>>>
>>
>> Yes but in fact, inspired by previous discussion I had on the VFIO
>> interface, that is the reason why I did prefer an int.
>> It is much simpler than a u16 and the definition of a bit.
>>
>> Despite a bit in a u16 is what the s3990 achitecture proposes I thought
>> we could make it easier on the KVM/QEMU interface.
>>
>> But if the discussion stops here, I will do as you both propose change
>> to u16 in KVM and userland and add the documentation for the interface.
>
> In general, we pass via the ABI fixed-sized values -- u8, u16, u32, u64
> ... instead of int. Simply because sizeof(int) is in theory variable
> (e.g., 32bit vs 64bit).
>
> Take a look at arch/s390/include/uapi/asm/kvm.h and you won't find any
> usage of int or bool.
>
> Having that said, I'll let the maintainers decide. Using e.g., u8 is
> just the natural thing to do on a Linux ABI, but we don't really support
> 32 bit ... maybe we'll support 128bit at one point? ;)
>
OK then I use u16 with a flag in case we get something in the utilities
which is related to the topology in the future.
Thanks,
Pierre
--
Pierre Morel
IBM Lab Boeblingen
On Wed, May 18, 2022 at 05:26:59PM +0200, Christian Borntraeger wrote:
> Pierre,
>
> please use "KVM: s390x:" and not "s390x: KVM:" for future series.
My grep arts ;) tell me that you probably want "KVM: s390:" without
"x" for the kernel.
On 5/19/22 10:07, Christian Borntraeger wrote:
> Am 19.05.22 um 07:46 schrieb Heiko Carstens:
>> On Wed, May 18, 2022 at 05:26:59PM +0200, Christian Borntraeger wrote:
>>> Pierre,
>>>
>>> please use "KVM: s390x:" and not "s390x: KVM:" for future series.
>>
>> My grep arts ;) tell me that you probably want "KVM: s390:" without
>> "x" for the kernel.
>
> yes :-)
Thanks, both of you.
I change it accordingly.
Regards,
Pierre
--
Pierre Morel
IBM Lab Boeblingen
Am 19.05.22 um 07:46 schrieb Heiko Carstens:
> On Wed, May 18, 2022 at 05:26:59PM +0200, Christian Borntraeger wrote:
>> Pierre,
>>
>> please use "KVM: s390x:" and not "s390x: KVM:" for future series.
>
> My grep arts ;) tell me that you probably want "KVM: s390:" without
> "x" for the kernel.
yes :-)