[Qemu-devel] [PATCH 00/10] s390x: new guest features

[Qemu-devel] [PATCH 00/10] s390x: new guest features

[Christian Borntraeger]

Adding generation 15.

Some interesting aspects:
- conditional SSKE and bpb are deprecated. This patch set addresses that
  for csske.
- no name yet for gen15, I suggest to use the assigned numbers and
  provide an alias later on. (I have split out this into a separate
  patch)

Christian Borntraeger (10):
  linux header sync
  s390x/cpumodel: remove CSSKE from base model
  s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3
  s390x/cpumodel: msa9 facility
  s390x/cpumodel: vector enhancements
  s390x/cpumodel: enhanced sort facility
  s390x/cpumodel: deflate
  s390x/cpumodel: add gen15 defintions
  s390x/cpumodel: wire up 8561 and 8562 as gen15 machines
  s390x/cpumodel: do not claim csske for expanded models in qmp

 hw/s390x/s390-virtio-ccw.c      |  6 +++
 linux-headers/asm-s390/kvm.h    |  5 +-
 target/s390x/cpu_features.c     | 54 +++++++++++++++++++
 target/s390x/cpu_features.h     |  3 ++
 target/s390x/cpu_features_def.h | 49 +++++++++++++++++
 target/s390x/cpu_models.c       | 35 ++++++++++++
 target/s390x/cpu_models.h       |  1 +
 target/s390x/gen-features.c     | 94 ++++++++++++++++++++++++++++++++-
 target/s390x/kvm.c              | 18 +++++++
 9 files changed, 263 insertions(+), 2 deletions(-)

-- 
2.19.1

[Qemu-devel] [PATCH 00/10] s390x: new guest features

[Christian Borntraeger]

Adding generation 15.

Some interesting aspects:
- conditional SSKE and bpb are deprecated. This patch set addresses that
  for csske.
- no name yet for gen15, I suggest to use the assigned numbers and
  provide an alias later on. (I have split out this into a separate
  patch)

Christian Borntraeger (10):
  linux header sync
  s390x/cpumodel: remove CSSKE from base model
  s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3
  s390x/cpumodel: msa9 facility
  s390x/cpumodel: vector enhancements
  s390x/cpumodel: enhanced sort facility
  s390x/cpumodel: deflate
  s390x/cpumodel: add gen15 defintions
  s390x/cpumodel: wire up 8561 and 8562 as gen15 machines
  s390x/cpumodel: do not claim csske for expanded models in qmp

 hw/s390x/s390-virtio-ccw.c      |  6 +++
 linux-headers/asm-s390/kvm.h    |  5 +-
 target/s390x/cpu_features.c     | 54 +++++++++++++++++++
 target/s390x/cpu_features.h     |  3 ++
 target/s390x/cpu_features_def.h | 49 +++++++++++++++++
 target/s390x/cpu_models.c       | 35 ++++++++++++
 target/s390x/cpu_models.h       |  1 +
 target/s390x/gen-features.c     | 94 ++++++++++++++++++++++++++++++++-
 target/s390x/kvm.c              | 18 +++++++
 9 files changed, 263 insertions(+), 2 deletions(-)

-- 
2.19.1

[Qemu-devel] [PATCH 01/10] linux header sync

[Christian Borntraeger]

to be replaced by a proper one

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
 linux-headers/asm-s390/kvm.h | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/linux-headers/asm-s390/kvm.h b/linux-headers/asm-s390/kvm.h
index 0265482f8f..03ab5968c7 100644
--- a/linux-headers/asm-s390/kvm.h
+++ b/linux-headers/asm-s390/kvm.h
@@ -152,7 +152,10 @@ struct kvm_s390_vm_cpu_subfunc {
 	__u8 pcc[16];		/* with MSA4 */
 	__u8 ppno[16];		/* with MSA5 */
 	__u8 kma[16];		/* with MSA8 */
-	__u8 reserved[1808];
+	__u8 kdsa[16];		/* with MSA9 */
+	__u8 sortl[32];		/* with STFLE.150 */
+	__u8 dfltcc[32];	/* with STFLE.151 */
+	__u8 reserved[1728];
 };
 
 /* kvm attributes for crypto */
-- 
2.19.1

[Qemu-devel] [PATCH 01/10] linux header sync

[Christian Borntraeger]

to be replaced by a proper one

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
 linux-headers/asm-s390/kvm.h | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/linux-headers/asm-s390/kvm.h b/linux-headers/asm-s390/kvm.h
index 0265482f8f..03ab5968c7 100644
--- a/linux-headers/asm-s390/kvm.h
+++ b/linux-headers/asm-s390/kvm.h
@@ -152,7 +152,10 @@ struct kvm_s390_vm_cpu_subfunc {
 	__u8 pcc[16];		/* with MSA4 */
 	__u8 ppno[16];		/* with MSA5 */
 	__u8 kma[16];		/* with MSA8 */
-	__u8 reserved[1808];
+	__u8 kdsa[16];		/* with MSA9 */
+	__u8 sortl[32];		/* with STFLE.150 */
+	__u8 dfltcc[32];	/* with STFLE.151 */
+	__u8 reserved[1728];
 };
 
 /* kvm attributes for crypto */
-- 
2.19.1

[Qemu-devel] [PATCH 02/10] s390x/cpumodel: remove CSSKE from base model

[Christian Borntraeger]

conditional sske is deprecated and a distant future machine (will be one
where the IBC will not allow to fully go back to z14) will remove this
feature. To prepare for this and allow for the z14 and older cpu model
to still run on systems without csske, remove csske from the base (and
thus the default models for z10..z14). For compat machines we have to
add those back.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
 hw/s390x/s390-virtio-ccw.c  |  2 ++
 target/s390x/cpu_models.c   | 21 +++++++++++++++++++++
 target/s390x/cpu_models.h   |  1 +
 target/s390x/gen-features.c |  1 -
 4 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index d11069b860..3415948b2c 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -648,6 +648,8 @@ bool css_migration_enabled(void)
 
 static void ccw_machine_4_0_instance_options(MachineState *machine)
 {
+    /* re-enable csske for compat machines in the base model */
+    s390_cpumodel_fixup_csske();
 }
 
 static void ccw_machine_4_0_class_options(MachineClass *mc)
diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
index eb125d4d0d..4e5aa879f3 100644
--- a/target/s390x/cpu_models.c
+++ b/target/s390x/cpu_models.c
@@ -93,6 +93,27 @@ static S390FeatBitmap qemu_max_cpu_feat;
 /* features part of a base model but not relevant for finding a base model */
 S390FeatBitmap ignored_base_feat;
 
+/*
+ * We removed CSSKE from the base features. This is a hook for compat machines
+ * to put this back for gen10..gen14. As the base model is also part of the
+ * default model to have to fixup both bitfields
+ */
+void s390_cpumodel_fixup_csske(void)
+{
+    int i;
+
+    for (i = 0; i < ARRAY_SIZE(s390_cpu_defs); i++) {
+        const S390CPUDef *def = &s390_cpu_defs[i];
+
+        if (def->gen < 10 || def->gen > 14) {
+            continue;
+        }
+
+        set_bit(S390_FEAT_CONDITIONAL_SSKE, (unsigned long *)&def->base_feat);
+        set_bit(S390_FEAT_CONDITIONAL_SSKE, (unsigned long *)&def->default_feat);
+    }
+}
+
 void s390_cpudef_featoff(uint8_t gen, uint8_t ec_ga, S390Feat feat)
 {
     const S390CPUDef *def;
diff --git a/target/s390x/cpu_models.h b/target/s390x/cpu_models.h
index 174a99e561..b2e37bc8cf 100644
--- a/target/s390x/cpu_models.h
+++ b/target/s390x/cpu_models.h
@@ -73,6 +73,7 @@ struct S390CPUModel {
 #define ibc_gen(x)        (x == 0 ? 0 : ((x >> 4) + S390_GEN_Z10))
 #define ibc_ec_ga(x)      (x & 0xf)
 
+void s390_cpumodel_fixup_csske(void);
 void s390_cpudef_featoff(uint8_t gen, uint8_t ec_ga, S390Feat feat);
 void s390_cpudef_featoff_greater(uint8_t gen, uint8_t ec_ga, S390Feat feat);
 void s390_cpudef_group_featoff_greater(uint8_t gen, uint8_t ec_ga,
diff --git a/target/s390x/gen-features.c b/target/s390x/gen-features.c
index e4739a6b9f..bea2f80c49 100644
--- a/target/s390x/gen-features.c
+++ b/target/s390x/gen-features.c
@@ -301,7 +301,6 @@ static uint16_t base_GEN9_GA1[] = {
 #define base_GEN9_GA3 EmptyFeat
 
 static uint16_t base_GEN10_GA1[] = {
-    S390_FEAT_CONDITIONAL_SSKE,
     S390_FEAT_PARSING_ENH,
     S390_FEAT_MOVE_WITH_OPTIONAL_SPEC,
     S390_FEAT_EXTRACT_CPU_TIME,
-- 
2.19.1

[Qemu-devel] [PATCH 02/10] s390x/cpumodel: remove CSSKE from base model

[Christian Borntraeger]

conditional sske is deprecated and a distant future machine (will be one
where the IBC will not allow to fully go back to z14) will remove this
feature. To prepare for this and allow for the z14 and older cpu model
to still run on systems without csske, remove csske from the base (and
thus the default models for z10..z14). For compat machines we have to
add those back.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
 hw/s390x/s390-virtio-ccw.c  |  2 ++
 target/s390x/cpu_models.c   | 21 +++++++++++++++++++++
 target/s390x/cpu_models.h   |  1 +
 target/s390x/gen-features.c |  1 -
 4 files changed, 24 insertions(+), 1 deletion(-)

diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index d11069b860..3415948b2c 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -648,6 +648,8 @@ bool css_migration_enabled(void)
 
 static void ccw_machine_4_0_instance_options(MachineState *machine)
 {
+    /* re-enable csske for compat machines in the base model */
+    s390_cpumodel_fixup_csske();
 }
 
 static void ccw_machine_4_0_class_options(MachineClass *mc)
diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
index eb125d4d0d..4e5aa879f3 100644
--- a/target/s390x/cpu_models.c
+++ b/target/s390x/cpu_models.c
@@ -93,6 +93,27 @@ static S390FeatBitmap qemu_max_cpu_feat;
 /* features part of a base model but not relevant for finding a base model */
 S390FeatBitmap ignored_base_feat;
 
+/*
+ * We removed CSSKE from the base features. This is a hook for compat machines
+ * to put this back for gen10..gen14. As the base model is also part of the
+ * default model to have to fixup both bitfields
+ */
+void s390_cpumodel_fixup_csske(void)
+{
+    int i;
+
+    for (i = 0; i < ARRAY_SIZE(s390_cpu_defs); i++) {
+        const S390CPUDef *def = &s390_cpu_defs[i];
+
+        if (def->gen < 10 || def->gen > 14) {
+            continue;
+        }
+
+        set_bit(S390_FEAT_CONDITIONAL_SSKE, (unsigned long *)&def->base_feat);
+        set_bit(S390_FEAT_CONDITIONAL_SSKE, (unsigned long *)&def->default_feat);
+    }
+}
+
 void s390_cpudef_featoff(uint8_t gen, uint8_t ec_ga, S390Feat feat)
 {
     const S390CPUDef *def;
diff --git a/target/s390x/cpu_models.h b/target/s390x/cpu_models.h
index 174a99e561..b2e37bc8cf 100644
--- a/target/s390x/cpu_models.h
+++ b/target/s390x/cpu_models.h
@@ -73,6 +73,7 @@ struct S390CPUModel {
 #define ibc_gen(x)        (x == 0 ? 0 : ((x >> 4) + S390_GEN_Z10))
 #define ibc_ec_ga(x)      (x & 0xf)
 
+void s390_cpumodel_fixup_csske(void);
 void s390_cpudef_featoff(uint8_t gen, uint8_t ec_ga, S390Feat feat);
 void s390_cpudef_featoff_greater(uint8_t gen, uint8_t ec_ga, S390Feat feat);
 void s390_cpudef_group_featoff_greater(uint8_t gen, uint8_t ec_ga,
diff --git a/target/s390x/gen-features.c b/target/s390x/gen-features.c
index e4739a6b9f..bea2f80c49 100644
--- a/target/s390x/gen-features.c
+++ b/target/s390x/gen-features.c
@@ -301,7 +301,6 @@ static uint16_t base_GEN9_GA1[] = {
 #define base_GEN9_GA3 EmptyFeat
 
 static uint16_t base_GEN10_GA1[] = {
-    S390_FEAT_CONDITIONAL_SSKE,
     S390_FEAT_PARSING_ENH,
     S390_FEAT_MOVE_WITH_OPTIONAL_SPEC,
     S390_FEAT_EXTRACT_CPU_TIME,
-- 
2.19.1

[Qemu-devel] [PATCH 03/10] s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3

[Christian Borntraeger]

Provide the "Miscellaneous-Instruction-Extensions Facility 3" via
stfle.61.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
 target/s390x/cpu_features.c     | 1 +
 target/s390x/cpu_features_def.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
index 1843c84aaa..bbd8902087 100644
--- a/target/s390x/cpu_features.c
+++ b/target/s390x/cpu_features.c
@@ -83,6 +83,7 @@ static const S390FeatDef s390_features[] = {
     FEAT_INIT("minste2", S390_FEAT_TYPE_STFL, 58, "Miscellaneous-instruction-extensions facility 2"),
     FEAT_INIT("sema", S390_FEAT_TYPE_STFL, 59, "Semaphore-assist facility"),
     FEAT_INIT("tsi", S390_FEAT_TYPE_STFL, 60, "Time-slice Instrumentation facility"),
+    FEAT_INIT("minste3", S390_FEAT_TYPE_STFL, 61, "Miscellaneous-Instruction-Extensions Facility 3"),
     FEAT_INIT("ri", S390_FEAT_TYPE_STFL, 64, "CPU runtime-instrumentation facility"),
     FEAT_INIT("zpci", S390_FEAT_TYPE_STFL, 69, "z/PCI facility"),
     FEAT_INIT("aen", S390_FEAT_TYPE_STFL, 71, "General-purpose-adapter-event-notification facility"),
diff --git a/target/s390x/cpu_features_def.h b/target/s390x/cpu_features_def.h
index 5fc7e7bf01..31dd678301 100644
--- a/target/s390x/cpu_features_def.h
+++ b/target/s390x/cpu_features_def.h
@@ -71,6 +71,7 @@ typedef enum {
     S390_FEAT_MISC_INSTRUCTION_EXT,
     S390_FEAT_SEMAPHORE_ASSIST,
     S390_FEAT_TIME_SLICE_INSTRUMENTATION,
+    S390_FEAT_MISC_INSTRUCTION_EXT3,
     S390_FEAT_RUNTIME_INSTRUMENTATION,
     S390_FEAT_ZPCI,
     S390_FEAT_ADAPTER_EVENT_NOTIFICATION,
-- 
2.19.1

[Qemu-devel] [PATCH 03/10] s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3

[Christian Borntraeger]

Provide the "Miscellaneous-Instruction-Extensions Facility 3" via
stfle.61.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
 target/s390x/cpu_features.c     | 1 +
 target/s390x/cpu_features_def.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
index 1843c84aaa..bbd8902087 100644
--- a/target/s390x/cpu_features.c
+++ b/target/s390x/cpu_features.c
@@ -83,6 +83,7 @@ static const S390FeatDef s390_features[] = {
     FEAT_INIT("minste2", S390_FEAT_TYPE_STFL, 58, "Miscellaneous-instruction-extensions facility 2"),
     FEAT_INIT("sema", S390_FEAT_TYPE_STFL, 59, "Semaphore-assist facility"),
     FEAT_INIT("tsi", S390_FEAT_TYPE_STFL, 60, "Time-slice Instrumentation facility"),
+    FEAT_INIT("minste3", S390_FEAT_TYPE_STFL, 61, "Miscellaneous-Instruction-Extensions Facility 3"),
     FEAT_INIT("ri", S390_FEAT_TYPE_STFL, 64, "CPU runtime-instrumentation facility"),
     FEAT_INIT("zpci", S390_FEAT_TYPE_STFL, 69, "z/PCI facility"),
     FEAT_INIT("aen", S390_FEAT_TYPE_STFL, 71, "General-purpose-adapter-event-notification facility"),
diff --git a/target/s390x/cpu_features_def.h b/target/s390x/cpu_features_def.h
index 5fc7e7bf01..31dd678301 100644
--- a/target/s390x/cpu_features_def.h
+++ b/target/s390x/cpu_features_def.h
@@ -71,6 +71,7 @@ typedef enum {
     S390_FEAT_MISC_INSTRUCTION_EXT,
     S390_FEAT_SEMAPHORE_ASSIST,
     S390_FEAT_TIME_SLICE_INSTRUMENTATION,
+    S390_FEAT_MISC_INSTRUCTION_EXT3,
     S390_FEAT_RUNTIME_INSTRUMENTATION,
     S390_FEAT_ZPCI,
     S390_FEAT_ADAPTER_EVENT_NOTIFICATION,
-- 
2.19.1

[Qemu-devel] [PATCH 04/10] s390x/cpumodel: msa9 facility

[Christian Borntraeger]

Provide the MSA9 facility (stfle.155).  This also contains pckmo
functions for key wrapping. Keep them in a separate group to allow
disabling/enabling those as a block if necessary.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
 target/s390x/cpu_features.c     | 32 +++++++++++++++++++++++++
 target/s390x/cpu_features.h     |  1 +
 target/s390x/cpu_features_def.h | 31 ++++++++++++++++++++++++
 target/s390x/cpu_models.c       |  1 +
 target/s390x/gen-features.c     | 42 +++++++++++++++++++++++++++++++++
 target/s390x/kvm.c              |  6 +++++
 6 files changed, 113 insertions(+)

diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
index bbd8902087..4d624b2256 100644
--- a/target/s390x/cpu_features.c
+++ b/target/s390x/cpu_features.c
@@ -108,6 +108,7 @@ static const S390FeatDef s390_features[] = {
     FEAT_INIT("irbm", S390_FEAT_TYPE_STFL, 145, "Insert-reference-bits-multiple facility"),
     FEAT_INIT("msa8-base", S390_FEAT_TYPE_STFL, 146, "Message-security-assist-extension-8 facility (excluding subfunctions)"),
     FEAT_INIT("cmmnt", S390_FEAT_TYPE_STFL, 147, "CMM: ESSA-enhancement (no translate) facility"),
+    FEAT_INIT("msa9-base", S390_FEAT_TYPE_STFL, 155, "Message-security-assist-extension-9 facility (excluding subfunctions)"),
     FEAT_INIT("etoken", S390_FEAT_TYPE_STFL, 156, "Etoken facility"),
 
     /* SCLP SCCB Byte 80 - 98  (bit numbers relative to byte-80) */
@@ -242,6 +243,11 @@ static const S390FeatDef s390_features[] = {
     FEAT_INIT("pckmo-aes-128", S390_FEAT_TYPE_PCKMO, 18, "PCKMO Encrypted-AES-128-Key"),
     FEAT_INIT("pckmo-aes-192", S390_FEAT_TYPE_PCKMO, 19, "PCKMO Encrypted-AES-192-Key"),
     FEAT_INIT("pckmo-aes-256", S390_FEAT_TYPE_PCKMO, 20, "PCKMO Encrypted-AES-256-Key"),
+    FEAT_INIT("pckmo-ecc-p256", S390_FEAT_TYPE_PCKMO,32, "PCKMO Encrypt-ECC-P256-Key"),
+    FEAT_INIT("pckmo-ecc-p384", S390_FEAT_TYPE_PCKMO,33, "PCKMO Encrypt-ECC-P384-Key"),
+    FEAT_INIT("pckmo-ecc-p521", S390_FEAT_TYPE_PCKMO,34, "PCKMO Encrypt-ECC-P521-Key"),
+    FEAT_INIT("pckmo-ecc-ed25519", S390_FEAT_TYPE_PCKMO,40 , "PCKMO Encrypt-ECC-Ed25519-Key"),
+    FEAT_INIT("pckmo-ecc-ed448", S390_FEAT_TYPE_PCKMO,41 , "PCKMO Encrypt-ECC-Ed448-Key"),
 
     FEAT_INIT("kmctr-dea", S390_FEAT_TYPE_KMCTR, 1, "KMCTR DEA"),
     FEAT_INIT("kmctr-tdea-128", S390_FEAT_TYPE_KMCTR, 2, "KMCTR TDEA-128"),
@@ -298,6 +304,13 @@ static const S390FeatDef s390_features[] = {
     FEAT_INIT("pcc-xts-aes-256", S390_FEAT_TYPE_PCC, 52, "PCC Compute-XTS-Parameter-Using-AES-256"),
     FEAT_INIT("pcc-xts-eaes-128", S390_FEAT_TYPE_PCC, 58, "PCC Compute-XTS-Parameter-Using-Encrypted-AES-128"),
     FEAT_INIT("pcc-xts-eaes-256", S390_FEAT_TYPE_PCC, 60, "PCC Compute-XTS-Parameter-Using-Encrypted-AES-256"),
+    FEAT_INIT("pcc-scalar-mult-p256", S390_FEAT_TYPE_PCC, 64, "PCC Scalar-Multiply-P256"),
+    FEAT_INIT("pcc-scalar-mult-p384", S390_FEAT_TYPE_PCC, 65, "PCC Scalar-Multiply-P384"),
+    FEAT_INIT("pcc-scalar-mult-p521", S390_FEAT_TYPE_PCC, 66, "PCC Scalar-Multiply-P521"),
+    FEAT_INIT("pcc-scalar-mult-ed25519", S390_FEAT_TYPE_PCC, 72, "PCC Scalar-Multiply-Ed25519"),
+    FEAT_INIT("pcc-scalar-mult-ed448", S390_FEAT_TYPE_PCC, 73, "PCC Scalar-Multiply-Ed448"),
+    FEAT_INIT("pcc-scalar-mult-x25519", S390_FEAT_TYPE_PCC, 80, "PCC Scalar-Multiply-X25519"),
+    FEAT_INIT("pcc-scalar-mult-x448", S390_FEAT_TYPE_PCC, 81, "PCC Scalar-Multiply-X448"),
 
     FEAT_INIT("ppno-sha-512-drng", S390_FEAT_TYPE_PPNO, 3, "PPNO SHA-512-DRNG"),
     FEAT_INIT("prno-trng-qrtcr", S390_FEAT_TYPE_PPNO, 112, "PRNO TRNG-Query-Raw-to-Conditioned-Ratio"),
@@ -309,6 +322,22 @@ static const S390FeatDef s390_features[] = {
     FEAT_INIT("kma-gcm-eaes-128", S390_FEAT_TYPE_KMA, 26, "KMA GCM-Encrypted-AES-128"),
     FEAT_INIT("kma-gcm-eaes-192", S390_FEAT_TYPE_KMA, 27, "KMA GCM-Encrypted-AES-192"),
     FEAT_INIT("kma-gcm-eaes-256", S390_FEAT_TYPE_KMA, 28, "KMA GCM-Encrypted-AES-256"),
+
+    FEAT_INIT("kdsa-ecdsa-verify-p256", S390_FEAT_TYPE_KDSA, 1, "KDSA ECDSA-Verify-P256"),
+    FEAT_INIT("kdsa-ecdsa-verify-p384", S390_FEAT_TYPE_KDSA, 2, "KDSA ECDSA-Verify-P384"),
+    FEAT_INIT("kdsa-ecdsa-verify-p521", S390_FEAT_TYPE_KDSA, 3, "KDSA ECDSA-Verify-P521"),
+    FEAT_INIT("kdsa-ecdsa-sign-p256", S390_FEAT_TYPE_KDSA, 9, "KDSA ECDSA-Sign-P256"),
+    FEAT_INIT("kdsa-ecdsa-sign-p384", S390_FEAT_TYPE_KDSA, 10, "KDSA ECDSA-Sign-P384"),
+    FEAT_INIT("kdsa-ecdsa-sign-p521", S390_FEAT_TYPE_KDSA, 11, "KDSA ECDSA-Sign-P521"),
+    FEAT_INIT("kdsa-eecdsa-sign-p256", S390_FEAT_TYPE_KDSA, 17, "KDSA Encrypted-ECDSA-Sign-P256"),
+    FEAT_INIT("kdsa-eecdsa-sign-p384", S390_FEAT_TYPE_KDSA, 18, "KDSA Encrypted-ECDSA-Sign-P384"),
+    FEAT_INIT("kdsa-eecdsa-sign-p521", S390_FEAT_TYPE_KDSA, 19, "KDSA Encrypted-ECDSA-Sign-P521"),
+    FEAT_INIT("kdsa-eddsa-verify-ed25519", S390_FEAT_TYPE_KDSA, 32, "KDSA EdDSA-Verify-Ed25519"),
+    FEAT_INIT("kdsa-eddsa-verify-ed448", S390_FEAT_TYPE_KDSA, 36, "KDSA EdDSA-Verify-Ed448"),
+    FEAT_INIT("kdsa-eddsa-sign-ed25519", S390_FEAT_TYPE_KDSA, 40, "KDSA EdDSA-Sign-Ed25519"),
+    FEAT_INIT("kdsa-eddsa-sign-ed448", S390_FEAT_TYPE_KDSA, 44, "KDSA EdDSA-Sign-Ed448"),
+    FEAT_INIT("kdsa-eeddsa-sign-ed25519", S390_FEAT_TYPE_KDSA, 48, "KDSA Encrypted-EdDSA-Sign-Ed25519"),
+    FEAT_INIT("kdsa-eeddsa-sign-ed448", S390_FEAT_TYPE_KDSA, 52, "KDSA Encrypted-EdDSA-Sign-Ed448"),
 };
 
 const S390FeatDef *s390_feat_def(S390Feat feat)
@@ -371,6 +400,7 @@ void s390_fill_feat_block(const S390FeatBitmap features, S390FeatType type,
     case S390_FEAT_TYPE_PCC:
     case S390_FEAT_TYPE_PPNO:
     case S390_FEAT_TYPE_KMA:
+    case S390_FEAT_TYPE_KDSA:
         set_be_bit(0, data); /* query is always available */
         break;
     default:
@@ -466,6 +496,8 @@ static S390FeatGroupDef s390_feature_groups[] = {
     FEAT_GROUP_INIT("msa6", MSA_EXT_6, "Message-security-assist-extension 6 facility"),
     FEAT_GROUP_INIT("msa7", MSA_EXT_7, "Message-security-assist-extension 7 facility"),
     FEAT_GROUP_INIT("msa8", MSA_EXT_8, "Message-security-assist-extension 8 facility"),
+    FEAT_GROUP_INIT("msa9", MSA_EXT_9, "Message-security-assist-extension 9 facility"),
+    FEAT_GROUP_INIT("msa9_pckmo", MSA_EXT_9_PCKMO, "Message-security-assist-extension 9 PCKMO subfunctions"),
     FEAT_GROUP_INIT("mepochptff", MULTIPLE_EPOCH_PTFF, "PTFF enhancements introduced with Multiple-epoch facility"),
 };
 
diff --git a/target/s390x/cpu_features.h b/target/s390x/cpu_features.h
index effe790271..5ffd3db083 100644
--- a/target/s390x/cpu_features.h
+++ b/target/s390x/cpu_features.h
@@ -39,6 +39,7 @@ typedef enum {
     S390_FEAT_TYPE_PCC,
     S390_FEAT_TYPE_PPNO,
     S390_FEAT_TYPE_KMA,
+    S390_FEAT_TYPE_KDSA,
 } S390FeatType;
 
 /* Definition of a CPU feature */
diff --git a/target/s390x/cpu_features_def.h b/target/s390x/cpu_features_def.h
index 31dd678301..030784811b 100644
--- a/target/s390x/cpu_features_def.h
+++ b/target/s390x/cpu_features_def.h
@@ -96,6 +96,7 @@ typedef enum {
     S390_FEAT_INSERT_REFERENCE_BITS_MULT,
     S390_FEAT_MSA_EXT_8,
     S390_FEAT_CMM_NT,
+    S390_FEAT_MSA_EXT_9,
     S390_FEAT_ETOKEN,
 
     /* Sclp Conf Char */
@@ -240,6 +241,11 @@ typedef enum {
     S390_FEAT_PCKMO_AES_128,
     S390_FEAT_PCKMO_AES_192,
     S390_FEAT_PCKMO_AES_256,
+    S390_FEAT_PCKMO_ECC_P256,
+    S390_FEAT_PCKMO_ECC_P384,
+    S390_FEAT_PCKMO_ECC_P521,
+    S390_FEAT_PCKMO_ECC_ED25519,
+    S390_FEAT_PCKMO_ECC_ED448,
 
     /* KMCTR */
     S390_FEAT_KMCTR_DEA,
@@ -300,6 +306,13 @@ typedef enum {
     S390_FEAT_PCC_XTS_AES_256,
     S390_FEAT_PCC_XTS_EAES_128,
     S390_FEAT_PCC_XTS_EAES_256,
+    S390_FEAT_PCC_SCALAR_MULT_P256,
+    S390_FEAT_PCC_SCALAR_MULT_P384,
+    S390_FEAT_PCC_SCALAR_MULT_P512,
+    S390_FEAT_PCC_SCALAR_MULT_ED25519,
+    S390_FEAT_PCC_SCALAR_MULT_ED448,
+    S390_FEAT_PCC_SCALAR_MULT_X25519,
+    S390_FEAT_PCC_SCALAR_MULT_X448,
 
     /* PPNO/PRNO */
     S390_FEAT_PPNO_SHA_512_DRNG,
@@ -313,6 +326,24 @@ typedef enum {
     S390_FEAT_KMA_GCM_EAES_128,
     S390_FEAT_KMA_GCM_EAES_192,
     S390_FEAT_KMA_GCM_EAES_256,
+
+    /* KDSA */
+    S390_FEAT_ECDSA_VERIFY_P256,
+    S390_FEAT_ECDSA_VERIFY_P384,
+    S390_FEAT_ECDSA_VERIFY_P512,
+    S390_FEAT_ECDSA_SIGN_P256,
+    S390_FEAT_ECDSA_SIGN_P384,
+    S390_FEAT_ECDSA_SIGN_P512,
+    S390_FEAT_EECDSA_SIGN_P256,
+    S390_FEAT_EECDSA_SIGN_P384,
+    S390_FEAT_EECDSA_SIGN_P512,
+    S390_FEAT_EDDSA_VERIFY_ED25519,
+    S390_FEAT_EDDSA_VERIFY_ED448,
+    S390_FEAT_EDDSA_SIGN_ED25519,
+    S390_FEAT_EDDSA_SIGN_ED448,
+    S390_FEAT_EEDDSA_SIGN_ED25519,
+    S390_FEAT_EEDDSA_SIGN_ED448,
+
     S390_FEAT_MAX,
 } S390Feat;
 
diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
index 4e5aa879f3..4c355e936e 100644
--- a/target/s390x/cpu_models.c
+++ b/target/s390x/cpu_models.c
@@ -808,6 +808,7 @@ static void check_consistency(const S390CPUModel *model)
         { S390_FEAT_SIE_CMMA, S390_FEAT_SIE_GSLS },
         { S390_FEAT_SIE_PFMFI, S390_FEAT_EDAT },
         { S390_FEAT_MSA_EXT_8, S390_FEAT_MSA_EXT_3 },
+        { S390_FEAT_MSA_EXT_9, S390_FEAT_MSA_EXT_3 },
         { S390_FEAT_MULTIPLE_EPOCH, S390_FEAT_TOD_CLOCK_STEERING },
         { S390_FEAT_VECTOR_PACKED_DECIMAL, S390_FEAT_VECTOR },
         { S390_FEAT_VECTOR_ENH, S390_FEAT_VECTOR },
diff --git a/target/s390x/gen-features.c b/target/s390x/gen-features.c
index bea2f80c49..64fe850ff2 100644
--- a/target/s390x/gen-features.c
+++ b/target/s390x/gen-features.c
@@ -213,6 +213,38 @@
     S390_FEAT_KMA_GCM_EAES_192, \
     S390_FEAT_KMA_GCM_EAES_256
 
+#define S390_FEAT_GROUP_MSA_EXT_9 \
+    S390_FEAT_MSA_EXT_9,	\
+    S390_FEAT_ECDSA_VERIFY_P256, \
+    S390_FEAT_ECDSA_VERIFY_P384, \
+    S390_FEAT_ECDSA_VERIFY_P512, \
+    S390_FEAT_ECDSA_SIGN_P256, \
+    S390_FEAT_ECDSA_SIGN_P384, \
+    S390_FEAT_ECDSA_SIGN_P512, \
+    S390_FEAT_EECDSA_SIGN_P256, \
+    S390_FEAT_EECDSA_SIGN_P384, \
+    S390_FEAT_EECDSA_SIGN_P512, \
+    S390_FEAT_EDDSA_VERIFY_ED25519, \
+    S390_FEAT_EDDSA_VERIFY_ED448, \
+    S390_FEAT_EDDSA_SIGN_ED25519, \
+    S390_FEAT_EDDSA_SIGN_ED448, \
+    S390_FEAT_EEDDSA_SIGN_ED25519, \
+    S390_FEAT_EEDDSA_SIGN_ED448, \
+    S390_FEAT_PCC_SCALAR_MULT_P256, \
+    S390_FEAT_PCC_SCALAR_MULT_P384, \
+    S390_FEAT_PCC_SCALAR_MULT_P512, \
+    S390_FEAT_PCC_SCALAR_MULT_ED25519, \
+    S390_FEAT_PCC_SCALAR_MULT_ED448, \
+    S390_FEAT_PCC_SCALAR_MULT_X25519, \
+    S390_FEAT_PCC_SCALAR_MULT_X448
+
+#define S390_FEAT_GROUP_MSA_EXT_9_PCKMO \
+    S390_FEAT_PCKMO_ECC_P256, \
+    S390_FEAT_PCKMO_ECC_P384, \
+    S390_FEAT_PCKMO_ECC_P521, \
+    S390_FEAT_PCKMO_ECC_ED25519, \
+    S390_FEAT_PCKMO_ECC_ED448
+
 /* cpu feature groups */
 static uint16_t group_PLO[] = {
     S390_FEAT_GROUP_PLO,
@@ -254,6 +286,14 @@ static uint16_t group_MSA_EXT_8[] = {
     S390_FEAT_GROUP_MSA_EXT_8,
 };
 
+static uint16_t group_MSA_EXT_9[] = {
+    S390_FEAT_GROUP_MSA_EXT_9,
+};
+
+static uint16_t group_MSA_EXT_9_PCKMO[] = {
+    S390_FEAT_GROUP_MSA_EXT_9_PCKMO,
+};
+
 /* Base features (in order of release)
  * Only non-hypervisor managed features belong here.
  * Base feature sets are static meaning they do not change in future QEMU
@@ -708,6 +748,8 @@ static FeatGroupDefSpec FeatGroupDef[] = {
     FEAT_GROUP_INITIALIZER(MSA_EXT_6),
     FEAT_GROUP_INITIALIZER(MSA_EXT_7),
     FEAT_GROUP_INITIALIZER(MSA_EXT_8),
+    FEAT_GROUP_INITIALIZER(MSA_EXT_9),
+    FEAT_GROUP_INITIALIZER(MSA_EXT_9_PCKMO),
     FEAT_GROUP_INITIALIZER(MULTIPLE_EPOCH_PTFF),
 };
 
diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
index 19530fb94e..88cef3476c 100644
--- a/target/s390x/kvm.c
+++ b/target/s390x/kvm.c
@@ -2080,6 +2080,9 @@ static int query_cpu_subfunc(S390FeatBitmap features)
     if (test_bit(S390_FEAT_MSA_EXT_8, features)) {
         s390_add_from_feat_block(features, S390_FEAT_TYPE_KMA, prop.kma);
     }
+    if (test_bit(S390_FEAT_MSA_EXT_9, features)) {
+        s390_add_from_feat_block(features, S390_FEAT_TYPE_KDSA, prop.kdsa);
+    }
     return 0;
 }
 
@@ -2124,6 +2127,9 @@ static int configure_cpu_subfunc(const S390FeatBitmap features)
     if (test_bit(S390_FEAT_MSA_EXT_8, features)) {
         s390_fill_feat_block(features, S390_FEAT_TYPE_KMA, prop.kma);
     }
+    if (test_bit(S390_FEAT_MSA_EXT_9, features)) {
+        s390_fill_feat_block(features, S390_FEAT_TYPE_KDSA, prop.kdsa);
+    }
     return kvm_vm_ioctl(kvm_state, KVM_SET_DEVICE_ATTR, &attr);
 }
 
-- 
2.19.1

[Qemu-devel] [PATCH 04/10] s390x/cpumodel: msa9 facility

[Christian Borntraeger]

Provide the MSA9 facility (stfle.155).  This also contains pckmo
functions for key wrapping. Keep them in a separate group to allow
disabling/enabling those as a block if necessary.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
 target/s390x/cpu_features.c     | 32 +++++++++++++++++++++++++
 target/s390x/cpu_features.h     |  1 +
 target/s390x/cpu_features_def.h | 31 ++++++++++++++++++++++++
 target/s390x/cpu_models.c       |  1 +
 target/s390x/gen-features.c     | 42 +++++++++++++++++++++++++++++++++
 target/s390x/kvm.c              |  6 +++++
 6 files changed, 113 insertions(+)

diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
index bbd8902087..4d624b2256 100644
--- a/target/s390x/cpu_features.c
+++ b/target/s390x/cpu_features.c
@@ -108,6 +108,7 @@ static const S390FeatDef s390_features[] = {
     FEAT_INIT("irbm", S390_FEAT_TYPE_STFL, 145, "Insert-reference-bits-multiple facility"),
     FEAT_INIT("msa8-base", S390_FEAT_TYPE_STFL, 146, "Message-security-assist-extension-8 facility (excluding subfunctions)"),
     FEAT_INIT("cmmnt", S390_FEAT_TYPE_STFL, 147, "CMM: ESSA-enhancement (no translate) facility"),
+    FEAT_INIT("msa9-base", S390_FEAT_TYPE_STFL, 155, "Message-security-assist-extension-9 facility (excluding subfunctions)"),
     FEAT_INIT("etoken", S390_FEAT_TYPE_STFL, 156, "Etoken facility"),
 
     /* SCLP SCCB Byte 80 - 98  (bit numbers relative to byte-80) */
@@ -242,6 +243,11 @@ static const S390FeatDef s390_features[] = {
     FEAT_INIT("pckmo-aes-128", S390_FEAT_TYPE_PCKMO, 18, "PCKMO Encrypted-AES-128-Key"),
     FEAT_INIT("pckmo-aes-192", S390_FEAT_TYPE_PCKMO, 19, "PCKMO Encrypted-AES-192-Key"),
     FEAT_INIT("pckmo-aes-256", S390_FEAT_TYPE_PCKMO, 20, "PCKMO Encrypted-AES-256-Key"),
+    FEAT_INIT("pckmo-ecc-p256", S390_FEAT_TYPE_PCKMO,32, "PCKMO Encrypt-ECC-P256-Key"),
+    FEAT_INIT("pckmo-ecc-p384", S390_FEAT_TYPE_PCKMO,33, "PCKMO Encrypt-ECC-P384-Key"),
+    FEAT_INIT("pckmo-ecc-p521", S390_FEAT_TYPE_PCKMO,34, "PCKMO Encrypt-ECC-P521-Key"),
+    FEAT_INIT("pckmo-ecc-ed25519", S390_FEAT_TYPE_PCKMO,40 , "PCKMO Encrypt-ECC-Ed25519-Key"),
+    FEAT_INIT("pckmo-ecc-ed448", S390_FEAT_TYPE_PCKMO,41 , "PCKMO Encrypt-ECC-Ed448-Key"),
 
     FEAT_INIT("kmctr-dea", S390_FEAT_TYPE_KMCTR, 1, "KMCTR DEA"),
     FEAT_INIT("kmctr-tdea-128", S390_FEAT_TYPE_KMCTR, 2, "KMCTR TDEA-128"),
@@ -298,6 +304,13 @@ static const S390FeatDef s390_features[] = {
     FEAT_INIT("pcc-xts-aes-256", S390_FEAT_TYPE_PCC, 52, "PCC Compute-XTS-Parameter-Using-AES-256"),
     FEAT_INIT("pcc-xts-eaes-128", S390_FEAT_TYPE_PCC, 58, "PCC Compute-XTS-Parameter-Using-Encrypted-AES-128"),
     FEAT_INIT("pcc-xts-eaes-256", S390_FEAT_TYPE_PCC, 60, "PCC Compute-XTS-Parameter-Using-Encrypted-AES-256"),
+    FEAT_INIT("pcc-scalar-mult-p256", S390_FEAT_TYPE_PCC, 64, "PCC Scalar-Multiply-P256"),
+    FEAT_INIT("pcc-scalar-mult-p384", S390_FEAT_TYPE_PCC, 65, "PCC Scalar-Multiply-P384"),
+    FEAT_INIT("pcc-scalar-mult-p521", S390_FEAT_TYPE_PCC, 66, "PCC Scalar-Multiply-P521"),
+    FEAT_INIT("pcc-scalar-mult-ed25519", S390_FEAT_TYPE_PCC, 72, "PCC Scalar-Multiply-Ed25519"),
+    FEAT_INIT("pcc-scalar-mult-ed448", S390_FEAT_TYPE_PCC, 73, "PCC Scalar-Multiply-Ed448"),
+    FEAT_INIT("pcc-scalar-mult-x25519", S390_FEAT_TYPE_PCC, 80, "PCC Scalar-Multiply-X25519"),
+    FEAT_INIT("pcc-scalar-mult-x448", S390_FEAT_TYPE_PCC, 81, "PCC Scalar-Multiply-X448"),
 
     FEAT_INIT("ppno-sha-512-drng", S390_FEAT_TYPE_PPNO, 3, "PPNO SHA-512-DRNG"),
     FEAT_INIT("prno-trng-qrtcr", S390_FEAT_TYPE_PPNO, 112, "PRNO TRNG-Query-Raw-to-Conditioned-Ratio"),
@@ -309,6 +322,22 @@ static const S390FeatDef s390_features[] = {
     FEAT_INIT("kma-gcm-eaes-128", S390_FEAT_TYPE_KMA, 26, "KMA GCM-Encrypted-AES-128"),
     FEAT_INIT("kma-gcm-eaes-192", S390_FEAT_TYPE_KMA, 27, "KMA GCM-Encrypted-AES-192"),
     FEAT_INIT("kma-gcm-eaes-256", S390_FEAT_TYPE_KMA, 28, "KMA GCM-Encrypted-AES-256"),
+
+    FEAT_INIT("kdsa-ecdsa-verify-p256", S390_FEAT_TYPE_KDSA, 1, "KDSA ECDSA-Verify-P256"),
+    FEAT_INIT("kdsa-ecdsa-verify-p384", S390_FEAT_TYPE_KDSA, 2, "KDSA ECDSA-Verify-P384"),
+    FEAT_INIT("kdsa-ecdsa-verify-p521", S390_FEAT_TYPE_KDSA, 3, "KDSA ECDSA-Verify-P521"),
+    FEAT_INIT("kdsa-ecdsa-sign-p256", S390_FEAT_TYPE_KDSA, 9, "KDSA ECDSA-Sign-P256"),
+    FEAT_INIT("kdsa-ecdsa-sign-p384", S390_FEAT_TYPE_KDSA, 10, "KDSA ECDSA-Sign-P384"),
+    FEAT_INIT("kdsa-ecdsa-sign-p521", S390_FEAT_TYPE_KDSA, 11, "KDSA ECDSA-Sign-P521"),
+    FEAT_INIT("kdsa-eecdsa-sign-p256", S390_FEAT_TYPE_KDSA, 17, "KDSA Encrypted-ECDSA-Sign-P256"),
+    FEAT_INIT("kdsa-eecdsa-sign-p384", S390_FEAT_TYPE_KDSA, 18, "KDSA Encrypted-ECDSA-Sign-P384"),
+    FEAT_INIT("kdsa-eecdsa-sign-p521", S390_FEAT_TYPE_KDSA, 19, "KDSA Encrypted-ECDSA-Sign-P521"),
+    FEAT_INIT("kdsa-eddsa-verify-ed25519", S390_FEAT_TYPE_KDSA, 32, "KDSA EdDSA-Verify-Ed25519"),
+    FEAT_INIT("kdsa-eddsa-verify-ed448", S390_FEAT_TYPE_KDSA, 36, "KDSA EdDSA-Verify-Ed448"),
+    FEAT_INIT("kdsa-eddsa-sign-ed25519", S390_FEAT_TYPE_KDSA, 40, "KDSA EdDSA-Sign-Ed25519"),
+    FEAT_INIT("kdsa-eddsa-sign-ed448", S390_FEAT_TYPE_KDSA, 44, "KDSA EdDSA-Sign-Ed448"),
+    FEAT_INIT("kdsa-eeddsa-sign-ed25519", S390_FEAT_TYPE_KDSA, 48, "KDSA Encrypted-EdDSA-Sign-Ed25519"),
+    FEAT_INIT("kdsa-eeddsa-sign-ed448", S390_FEAT_TYPE_KDSA, 52, "KDSA Encrypted-EdDSA-Sign-Ed448"),
 };
 
 const S390FeatDef *s390_feat_def(S390Feat feat)
@@ -371,6 +400,7 @@ void s390_fill_feat_block(const S390FeatBitmap features, S390FeatType type,
     case S390_FEAT_TYPE_PCC:
     case S390_FEAT_TYPE_PPNO:
     case S390_FEAT_TYPE_KMA:
+    case S390_FEAT_TYPE_KDSA:
         set_be_bit(0, data); /* query is always available */
         break;
     default:
@@ -466,6 +496,8 @@ static S390FeatGroupDef s390_feature_groups[] = {
     FEAT_GROUP_INIT("msa6", MSA_EXT_6, "Message-security-assist-extension 6 facility"),
     FEAT_GROUP_INIT("msa7", MSA_EXT_7, "Message-security-assist-extension 7 facility"),
     FEAT_GROUP_INIT("msa8", MSA_EXT_8, "Message-security-assist-extension 8 facility"),
+    FEAT_GROUP_INIT("msa9", MSA_EXT_9, "Message-security-assist-extension 9 facility"),
+    FEAT_GROUP_INIT("msa9_pckmo", MSA_EXT_9_PCKMO, "Message-security-assist-extension 9 PCKMO subfunctions"),
     FEAT_GROUP_INIT("mepochptff", MULTIPLE_EPOCH_PTFF, "PTFF enhancements introduced with Multiple-epoch facility"),
 };
 
diff --git a/target/s390x/cpu_features.h b/target/s390x/cpu_features.h
index effe790271..5ffd3db083 100644
--- a/target/s390x/cpu_features.h
+++ b/target/s390x/cpu_features.h
@@ -39,6 +39,7 @@ typedef enum {
     S390_FEAT_TYPE_PCC,
     S390_FEAT_TYPE_PPNO,
     S390_FEAT_TYPE_KMA,
+    S390_FEAT_TYPE_KDSA,
 } S390FeatType;
 
 /* Definition of a CPU feature */
diff --git a/target/s390x/cpu_features_def.h b/target/s390x/cpu_features_def.h
index 31dd678301..030784811b 100644
--- a/target/s390x/cpu_features_def.h
+++ b/target/s390x/cpu_features_def.h
@@ -96,6 +96,7 @@ typedef enum {
     S390_FEAT_INSERT_REFERENCE_BITS_MULT,
     S390_FEAT_MSA_EXT_8,
     S390_FEAT_CMM_NT,
+    S390_FEAT_MSA_EXT_9,
     S390_FEAT_ETOKEN,
 
     /* Sclp Conf Char */
@@ -240,6 +241,11 @@ typedef enum {
     S390_FEAT_PCKMO_AES_128,
     S390_FEAT_PCKMO_AES_192,
     S390_FEAT_PCKMO_AES_256,
+    S390_FEAT_PCKMO_ECC_P256,
+    S390_FEAT_PCKMO_ECC_P384,
+    S390_FEAT_PCKMO_ECC_P521,
+    S390_FEAT_PCKMO_ECC_ED25519,
+    S390_FEAT_PCKMO_ECC_ED448,
 
     /* KMCTR */
     S390_FEAT_KMCTR_DEA,
@@ -300,6 +306,13 @@ typedef enum {
     S390_FEAT_PCC_XTS_AES_256,
     S390_FEAT_PCC_XTS_EAES_128,
     S390_FEAT_PCC_XTS_EAES_256,
+    S390_FEAT_PCC_SCALAR_MULT_P256,
+    S390_FEAT_PCC_SCALAR_MULT_P384,
+    S390_FEAT_PCC_SCALAR_MULT_P512,
+    S390_FEAT_PCC_SCALAR_MULT_ED25519,
+    S390_FEAT_PCC_SCALAR_MULT_ED448,
+    S390_FEAT_PCC_SCALAR_MULT_X25519,
+    S390_FEAT_PCC_SCALAR_MULT_X448,
 
     /* PPNO/PRNO */
     S390_FEAT_PPNO_SHA_512_DRNG,
@@ -313,6 +326,24 @@ typedef enum {
     S390_FEAT_KMA_GCM_EAES_128,
     S390_FEAT_KMA_GCM_EAES_192,
     S390_FEAT_KMA_GCM_EAES_256,
+
+    /* KDSA */
+    S390_FEAT_ECDSA_VERIFY_P256,
+    S390_FEAT_ECDSA_VERIFY_P384,
+    S390_FEAT_ECDSA_VERIFY_P512,
+    S390_FEAT_ECDSA_SIGN_P256,
+    S390_FEAT_ECDSA_SIGN_P384,
+    S390_FEAT_ECDSA_SIGN_P512,
+    S390_FEAT_EECDSA_SIGN_P256,
+    S390_FEAT_EECDSA_SIGN_P384,
+    S390_FEAT_EECDSA_SIGN_P512,
+    S390_FEAT_EDDSA_VERIFY_ED25519,
+    S390_FEAT_EDDSA_VERIFY_ED448,
+    S390_FEAT_EDDSA_SIGN_ED25519,
+    S390_FEAT_EDDSA_SIGN_ED448,
+    S390_FEAT_EEDDSA_SIGN_ED25519,
+    S390_FEAT_EEDDSA_SIGN_ED448,
+
     S390_FEAT_MAX,
 } S390Feat;
 
diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
index 4e5aa879f3..4c355e936e 100644
--- a/target/s390x/cpu_models.c
+++ b/target/s390x/cpu_models.c
@@ -808,6 +808,7 @@ static void check_consistency(const S390CPUModel *model)
         { S390_FEAT_SIE_CMMA, S390_FEAT_SIE_GSLS },
         { S390_FEAT_SIE_PFMFI, S390_FEAT_EDAT },
         { S390_FEAT_MSA_EXT_8, S390_FEAT_MSA_EXT_3 },
+        { S390_FEAT_MSA_EXT_9, S390_FEAT_MSA_EXT_3 },
         { S390_FEAT_MULTIPLE_EPOCH, S390_FEAT_TOD_CLOCK_STEERING },
         { S390_FEAT_VECTOR_PACKED_DECIMAL, S390_FEAT_VECTOR },
         { S390_FEAT_VECTOR_ENH, S390_FEAT_VECTOR },
diff --git a/target/s390x/gen-features.c b/target/s390x/gen-features.c
index bea2f80c49..64fe850ff2 100644
--- a/target/s390x/gen-features.c
+++ b/target/s390x/gen-features.c
@@ -213,6 +213,38 @@
     S390_FEAT_KMA_GCM_EAES_192, \
     S390_FEAT_KMA_GCM_EAES_256
 
+#define S390_FEAT_GROUP_MSA_EXT_9 \
+    S390_FEAT_MSA_EXT_9,	\
+    S390_FEAT_ECDSA_VERIFY_P256, \
+    S390_FEAT_ECDSA_VERIFY_P384, \
+    S390_FEAT_ECDSA_VERIFY_P512, \
+    S390_FEAT_ECDSA_SIGN_P256, \
+    S390_FEAT_ECDSA_SIGN_P384, \
+    S390_FEAT_ECDSA_SIGN_P512, \
+    S390_FEAT_EECDSA_SIGN_P256, \
+    S390_FEAT_EECDSA_SIGN_P384, \
+    S390_FEAT_EECDSA_SIGN_P512, \
+    S390_FEAT_EDDSA_VERIFY_ED25519, \
+    S390_FEAT_EDDSA_VERIFY_ED448, \
+    S390_FEAT_EDDSA_SIGN_ED25519, \
+    S390_FEAT_EDDSA_SIGN_ED448, \
+    S390_FEAT_EEDDSA_SIGN_ED25519, \
+    S390_FEAT_EEDDSA_SIGN_ED448, \
+    S390_FEAT_PCC_SCALAR_MULT_P256, \
+    S390_FEAT_PCC_SCALAR_MULT_P384, \
+    S390_FEAT_PCC_SCALAR_MULT_P512, \
+    S390_FEAT_PCC_SCALAR_MULT_ED25519, \
+    S390_FEAT_PCC_SCALAR_MULT_ED448, \
+    S390_FEAT_PCC_SCALAR_MULT_X25519, \
+    S390_FEAT_PCC_SCALAR_MULT_X448
+
+#define S390_FEAT_GROUP_MSA_EXT_9_PCKMO \
+    S390_FEAT_PCKMO_ECC_P256, \
+    S390_FEAT_PCKMO_ECC_P384, \
+    S390_FEAT_PCKMO_ECC_P521, \
+    S390_FEAT_PCKMO_ECC_ED25519, \
+    S390_FEAT_PCKMO_ECC_ED448
+
 /* cpu feature groups */
 static uint16_t group_PLO[] = {
     S390_FEAT_GROUP_PLO,
@@ -254,6 +286,14 @@ static uint16_t group_MSA_EXT_8[] = {
     S390_FEAT_GROUP_MSA_EXT_8,
 };
 
+static uint16_t group_MSA_EXT_9[] = {
+    S390_FEAT_GROUP_MSA_EXT_9,
+};
+
+static uint16_t group_MSA_EXT_9_PCKMO[] = {
+    S390_FEAT_GROUP_MSA_EXT_9_PCKMO,
+};
+
 /* Base features (in order of release)
  * Only non-hypervisor managed features belong here.
  * Base feature sets are static meaning they do not change in future QEMU
@@ -708,6 +748,8 @@ static FeatGroupDefSpec FeatGroupDef[] = {
     FEAT_GROUP_INITIALIZER(MSA_EXT_6),
     FEAT_GROUP_INITIALIZER(MSA_EXT_7),
     FEAT_GROUP_INITIALIZER(MSA_EXT_8),
+    FEAT_GROUP_INITIALIZER(MSA_EXT_9),
+    FEAT_GROUP_INITIALIZER(MSA_EXT_9_PCKMO),
     FEAT_GROUP_INITIALIZER(MULTIPLE_EPOCH_PTFF),
 };
 
diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
index 19530fb94e..88cef3476c 100644
--- a/target/s390x/kvm.c
+++ b/target/s390x/kvm.c
@@ -2080,6 +2080,9 @@ static int query_cpu_subfunc(S390FeatBitmap features)
     if (test_bit(S390_FEAT_MSA_EXT_8, features)) {
         s390_add_from_feat_block(features, S390_FEAT_TYPE_KMA, prop.kma);
     }
+    if (test_bit(S390_FEAT_MSA_EXT_9, features)) {
+        s390_add_from_feat_block(features, S390_FEAT_TYPE_KDSA, prop.kdsa);
+    }
     return 0;
 }
 
@@ -2124,6 +2127,9 @@ static int configure_cpu_subfunc(const S390FeatBitmap features)
     if (test_bit(S390_FEAT_MSA_EXT_8, features)) {
         s390_fill_feat_block(features, S390_FEAT_TYPE_KMA, prop.kma);
     }
+    if (test_bit(S390_FEAT_MSA_EXT_9, features)) {
+        s390_fill_feat_block(features, S390_FEAT_TYPE_KDSA, prop.kdsa);
+    }
     return kvm_vm_ioctl(kvm_state, KVM_SET_DEVICE_ATTR, &attr);
 }
 
-- 
2.19.1

[Qemu-devel] [PATCH 05/10] s390x/cpumodel: vector enhancements

[Christian Borntraeger]

Add vector enhancements to the cpu model.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
 target/s390x/cpu_features.c     | 2 ++
 target/s390x/cpu_features_def.h | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
index 4d624b2256..ed3f6aa969 100644
--- a/target/s390x/cpu_features.c
+++ b/target/s390x/cpu_features.c
@@ -108,6 +108,8 @@ static const S390FeatDef s390_features[] = {
     FEAT_INIT("irbm", S390_FEAT_TYPE_STFL, 145, "Insert-reference-bits-multiple facility"),
     FEAT_INIT("msa8-base", S390_FEAT_TYPE_STFL, 146, "Message-security-assist-extension-8 facility (excluding subfunctions)"),
     FEAT_INIT("cmmnt", S390_FEAT_TYPE_STFL, 147, "CMM: ESSA-enhancement (no translate) facility"),
+    FEAT_INIT("vxeh2", S390_FEAT_TYPE_STFL, 148, "Vector Enhancements facility 2"),
+    FEAT_INIT("vxbeh", S390_FEAT_TYPE_STFL, 152, "Vector BCD enhancements facility 1"),
     FEAT_INIT("msa9-base", S390_FEAT_TYPE_STFL, 155, "Message-security-assist-extension-9 facility (excluding subfunctions)"),
     FEAT_INIT("etoken", S390_FEAT_TYPE_STFL, 156, "Etoken facility"),
 
diff --git a/target/s390x/cpu_features_def.h b/target/s390x/cpu_features_def.h
index 030784811b..ce2223c9d7 100644
--- a/target/s390x/cpu_features_def.h
+++ b/target/s390x/cpu_features_def.h
@@ -96,6 +96,8 @@ typedef enum {
     S390_FEAT_INSERT_REFERENCE_BITS_MULT,
     S390_FEAT_MSA_EXT_8,
     S390_FEAT_CMM_NT,
+    S390_FEAT_VECTOR_ENH2,
+    S390_FEAT_VECTOR_BCD_ENH,
     S390_FEAT_MSA_EXT_9,
     S390_FEAT_ETOKEN,
 
-- 
2.19.1

[Qemu-devel] [PATCH 05/10] s390x/cpumodel: vector enhancements

[Christian Borntraeger]

Add vector enhancements to the cpu model.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
 target/s390x/cpu_features.c     | 2 ++
 target/s390x/cpu_features_def.h | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
index 4d624b2256..ed3f6aa969 100644
--- a/target/s390x/cpu_features.c
+++ b/target/s390x/cpu_features.c
@@ -108,6 +108,8 @@ static const S390FeatDef s390_features[] = {
     FEAT_INIT("irbm", S390_FEAT_TYPE_STFL, 145, "Insert-reference-bits-multiple facility"),
     FEAT_INIT("msa8-base", S390_FEAT_TYPE_STFL, 146, "Message-security-assist-extension-8 facility (excluding subfunctions)"),
     FEAT_INIT("cmmnt", S390_FEAT_TYPE_STFL, 147, "CMM: ESSA-enhancement (no translate) facility"),
+    FEAT_INIT("vxeh2", S390_FEAT_TYPE_STFL, 148, "Vector Enhancements facility 2"),
+    FEAT_INIT("vxbeh", S390_FEAT_TYPE_STFL, 152, "Vector BCD enhancements facility 1"),
     FEAT_INIT("msa9-base", S390_FEAT_TYPE_STFL, 155, "Message-security-assist-extension-9 facility (excluding subfunctions)"),
     FEAT_INIT("etoken", S390_FEAT_TYPE_STFL, 156, "Etoken facility"),
 
diff --git a/target/s390x/cpu_features_def.h b/target/s390x/cpu_features_def.h
index 030784811b..ce2223c9d7 100644
--- a/target/s390x/cpu_features_def.h
+++ b/target/s390x/cpu_features_def.h
@@ -96,6 +96,8 @@ typedef enum {
     S390_FEAT_INSERT_REFERENCE_BITS_MULT,
     S390_FEAT_MSA_EXT_8,
     S390_FEAT_CMM_NT,
+    S390_FEAT_VECTOR_ENH2,
+    S390_FEAT_VECTOR_BCD_ENH,
     S390_FEAT_MSA_EXT_9,
     S390_FEAT_ETOKEN,
 
-- 
2.19.1

[Qemu-devel] [PATCH 06/10] s390x/cpumodel: enhanced sort facility

[Christian Borntraeger]

add the enhanced sort facility.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
 target/s390x/cpu_features.c     | 10 ++++++++++
 target/s390x/cpu_features.h     |  1 +
 target/s390x/cpu_features_def.h |  8 ++++++++
 target/s390x/gen-features.c     | 14 ++++++++++++++
 target/s390x/kvm.c              |  6 ++++++
 5 files changed, 39 insertions(+)

diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
index ed3f6aa969..e0a4769c19 100644
--- a/target/s390x/cpu_features.c
+++ b/target/s390x/cpu_features.c
@@ -109,6 +109,7 @@ static const S390FeatDef s390_features[] = {
     FEAT_INIT("msa8-base", S390_FEAT_TYPE_STFL, 146, "Message-security-assist-extension-8 facility (excluding subfunctions)"),
     FEAT_INIT("cmmnt", S390_FEAT_TYPE_STFL, 147, "CMM: ESSA-enhancement (no translate) facility"),
     FEAT_INIT("vxeh2", S390_FEAT_TYPE_STFL, 148, "Vector Enhancements facility 2"),
+    FEAT_INIT("esort-base", S390_FEAT_TYPE_STFL, 150, "Enhanced-sort facility (excluding subfunctions)"),
     FEAT_INIT("vxbeh", S390_FEAT_TYPE_STFL, 152, "Vector BCD enhancements facility 1"),
     FEAT_INIT("msa9-base", S390_FEAT_TYPE_STFL, 155, "Message-security-assist-extension-9 facility (excluding subfunctions)"),
     FEAT_INIT("etoken", S390_FEAT_TYPE_STFL, 156, "Etoken facility"),
@@ -340,6 +341,12 @@ static const S390FeatDef s390_features[] = {
     FEAT_INIT("kdsa-eddsa-sign-ed448", S390_FEAT_TYPE_KDSA, 44, "KDSA EdDSA-Sign-Ed448"),
     FEAT_INIT("kdsa-eeddsa-sign-ed25519", S390_FEAT_TYPE_KDSA, 48, "KDSA Encrypted-EdDSA-Sign-Ed25519"),
     FEAT_INIT("kdsa-eeddsa-sign-ed448", S390_FEAT_TYPE_KDSA, 52, "KDSA Encrypted-EdDSA-Sign-Ed448"),
+
+    FEAT_INIT("sortl-sflr", S390_FEAT_TYPE_SORTL, 1, "SORTL SFLR"),
+    FEAT_INIT("sortl-svlr", S390_FEAT_TYPE_SORTL, 2, "SORTL SVLR"),
+    FEAT_INIT("sortl-32", S390_FEAT_TYPE_SORTL, 130, "SORTL 32 input lists"),
+    FEAT_INIT("sortl-128", S390_FEAT_TYPE_SORTL, 132, "SORTL 128 input lists"),
+    FEAT_INIT("sortl-f0", S390_FEAT_TYPE_SORTL, 192, "SORTL format 0 parameter-block"),
 };
 
 const S390FeatDef *s390_feat_def(S390Feat feat)
@@ -403,6 +410,7 @@ void s390_fill_feat_block(const S390FeatBitmap features, S390FeatType type,
     case S390_FEAT_TYPE_PPNO:
     case S390_FEAT_TYPE_KMA:
     case S390_FEAT_TYPE_KDSA:
+    case S390_FEAT_TYPE_SORTL:
         set_be_bit(0, data); /* query is always available */
         break;
     default:
@@ -430,6 +438,7 @@ void s390_add_from_feat_block(S390FeatBitmap features, S390FeatType type,
        nr_bits = 16384;
        break;
     case S390_FEAT_TYPE_PLO:
+    case S390_FEAT_TYPE_SORTL:
        nr_bits = 256;
        break;
     default:
@@ -501,6 +510,7 @@ static S390FeatGroupDef s390_feature_groups[] = {
     FEAT_GROUP_INIT("msa9", MSA_EXT_9, "Message-security-assist-extension 9 facility"),
     FEAT_GROUP_INIT("msa9_pckmo", MSA_EXT_9_PCKMO, "Message-security-assist-extension 9 PCKMO subfunctions"),
     FEAT_GROUP_INIT("mepochptff", MULTIPLE_EPOCH_PTFF, "PTFF enhancements introduced with Multiple-epoch facility"),
+    FEAT_GROUP_INIT("esort", ENH_SORT, "Enhanced-sort facility"),
 };
 
 const S390FeatGroupDef *s390_feat_group_def(S390FeatGroup group)
diff --git a/target/s390x/cpu_features.h b/target/s390x/cpu_features.h
index 5ffd3db083..3b8c5b25dd 100644
--- a/target/s390x/cpu_features.h
+++ b/target/s390x/cpu_features.h
@@ -40,6 +40,7 @@ typedef enum {
     S390_FEAT_TYPE_PPNO,
     S390_FEAT_TYPE_KMA,
     S390_FEAT_TYPE_KDSA,
+    S390_FEAT_TYPE_SORTL,
 } S390FeatType;
 
 /* Definition of a CPU feature */
diff --git a/target/s390x/cpu_features_def.h b/target/s390x/cpu_features_def.h
index ce2223c9d7..bb8585847f 100644
--- a/target/s390x/cpu_features_def.h
+++ b/target/s390x/cpu_features_def.h
@@ -97,6 +97,7 @@ typedef enum {
     S390_FEAT_MSA_EXT_8,
     S390_FEAT_CMM_NT,
     S390_FEAT_VECTOR_ENH2,
+    S390_FEAT_ESORT_BASE,
     S390_FEAT_VECTOR_BCD_ENH,
     S390_FEAT_MSA_EXT_9,
     S390_FEAT_ETOKEN,
@@ -346,6 +347,13 @@ typedef enum {
     S390_FEAT_EEDDSA_SIGN_ED25519,
     S390_FEAT_EEDDSA_SIGN_ED448,
 
+    /* SORTL */
+    S390_FEAT_SORTL_SFLR,
+    S390_FEAT_SORTL_SVLR,
+    S390_FEAT_SORTL_32,
+    S390_FEAT_SORTL_128,
+    S390_FEAT_SORTL_F0,
+
     S390_FEAT_MAX,
 } S390Feat;
 
diff --git a/target/s390x/gen-features.c b/target/s390x/gen-features.c
index 64fe850ff2..3db323fc0c 100644
--- a/target/s390x/gen-features.c
+++ b/target/s390x/gen-features.c
@@ -245,6 +245,15 @@
     S390_FEAT_PCKMO_ECC_ED25519, \
     S390_FEAT_PCKMO_ECC_ED448
 
+#define S390_FEAT_GROUP_ENH_SORT \
+    S390_FEAT_ESORT_BASE, \
+    S390_FEAT_SORTL_SFLR, \
+    S390_FEAT_SORTL_SVLR, \
+    S390_FEAT_SORTL_32, \
+    S390_FEAT_SORTL_128, \
+    S390_FEAT_SORTL_F0
+
+
 /* cpu feature groups */
 static uint16_t group_PLO[] = {
     S390_FEAT_GROUP_PLO,
@@ -294,6 +303,10 @@ static uint16_t group_MSA_EXT_9_PCKMO[] = {
     S390_FEAT_GROUP_MSA_EXT_9_PCKMO,
 };
 
+static uint16_t group_ENH_SORT[] = {
+    S390_FEAT_GROUP_ENH_SORT,
+};
+
 /* Base features (in order of release)
  * Only non-hypervisor managed features belong here.
  * Base feature sets are static meaning they do not change in future QEMU
@@ -751,6 +764,7 @@ static FeatGroupDefSpec FeatGroupDef[] = {
     FEAT_GROUP_INITIALIZER(MSA_EXT_9),
     FEAT_GROUP_INITIALIZER(MSA_EXT_9_PCKMO),
     FEAT_GROUP_INITIALIZER(MULTIPLE_EPOCH_PTFF),
+    FEAT_GROUP_INITIALIZER(ENH_SORT),
 };
 
 #define QEMU_FEAT_INITIALIZER(_name)                   \
diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
index 88cef3476c..7681492c41 100644
--- a/target/s390x/kvm.c
+++ b/target/s390x/kvm.c
@@ -2083,6 +2083,9 @@ static int query_cpu_subfunc(S390FeatBitmap features)
     if (test_bit(S390_FEAT_MSA_EXT_9, features)) {
         s390_add_from_feat_block(features, S390_FEAT_TYPE_KDSA, prop.kdsa);
     }
+    if (test_bit(S390_FEAT_ESORT_BASE, features)) {
+        s390_add_from_feat_block(features, S390_FEAT_TYPE_SORTL, prop.sortl);
+    }
     return 0;
 }
 
@@ -2130,6 +2133,9 @@ static int configure_cpu_subfunc(const S390FeatBitmap features)
     if (test_bit(S390_FEAT_MSA_EXT_9, features)) {
         s390_fill_feat_block(features, S390_FEAT_TYPE_KDSA, prop.kdsa);
     }
+    if (test_bit(S390_FEAT_ESORT_BASE, features)) {
+        s390_fill_feat_block(features, S390_FEAT_TYPE_SORTL, prop.sortl);
+    }
     return kvm_vm_ioctl(kvm_state, KVM_SET_DEVICE_ATTR, &attr);
 }
 
-- 
2.19.1

[Qemu-devel] [PATCH 06/10] s390x/cpumodel: enhanced sort facility

[Christian Borntraeger]

add the enhanced sort facility.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
 target/s390x/cpu_features.c     | 10 ++++++++++
 target/s390x/cpu_features.h     |  1 +
 target/s390x/cpu_features_def.h |  8 ++++++++
 target/s390x/gen-features.c     | 14 ++++++++++++++
 target/s390x/kvm.c              |  6 ++++++
 5 files changed, 39 insertions(+)

diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
index ed3f6aa969..e0a4769c19 100644
--- a/target/s390x/cpu_features.c
+++ b/target/s390x/cpu_features.c
@@ -109,6 +109,7 @@ static const S390FeatDef s390_features[] = {
     FEAT_INIT("msa8-base", S390_FEAT_TYPE_STFL, 146, "Message-security-assist-extension-8 facility (excluding subfunctions)"),
     FEAT_INIT("cmmnt", S390_FEAT_TYPE_STFL, 147, "CMM: ESSA-enhancement (no translate) facility"),
     FEAT_INIT("vxeh2", S390_FEAT_TYPE_STFL, 148, "Vector Enhancements facility 2"),
+    FEAT_INIT("esort-base", S390_FEAT_TYPE_STFL, 150, "Enhanced-sort facility (excluding subfunctions)"),
     FEAT_INIT("vxbeh", S390_FEAT_TYPE_STFL, 152, "Vector BCD enhancements facility 1"),
     FEAT_INIT("msa9-base", S390_FEAT_TYPE_STFL, 155, "Message-security-assist-extension-9 facility (excluding subfunctions)"),
     FEAT_INIT("etoken", S390_FEAT_TYPE_STFL, 156, "Etoken facility"),
@@ -340,6 +341,12 @@ static const S390FeatDef s390_features[] = {
     FEAT_INIT("kdsa-eddsa-sign-ed448", S390_FEAT_TYPE_KDSA, 44, "KDSA EdDSA-Sign-Ed448"),
     FEAT_INIT("kdsa-eeddsa-sign-ed25519", S390_FEAT_TYPE_KDSA, 48, "KDSA Encrypted-EdDSA-Sign-Ed25519"),
     FEAT_INIT("kdsa-eeddsa-sign-ed448", S390_FEAT_TYPE_KDSA, 52, "KDSA Encrypted-EdDSA-Sign-Ed448"),
+
+    FEAT_INIT("sortl-sflr", S390_FEAT_TYPE_SORTL, 1, "SORTL SFLR"),
+    FEAT_INIT("sortl-svlr", S390_FEAT_TYPE_SORTL, 2, "SORTL SVLR"),
+    FEAT_INIT("sortl-32", S390_FEAT_TYPE_SORTL, 130, "SORTL 32 input lists"),
+    FEAT_INIT("sortl-128", S390_FEAT_TYPE_SORTL, 132, "SORTL 128 input lists"),
+    FEAT_INIT("sortl-f0", S390_FEAT_TYPE_SORTL, 192, "SORTL format 0 parameter-block"),
 };
 
 const S390FeatDef *s390_feat_def(S390Feat feat)
@@ -403,6 +410,7 @@ void s390_fill_feat_block(const S390FeatBitmap features, S390FeatType type,
     case S390_FEAT_TYPE_PPNO:
     case S390_FEAT_TYPE_KMA:
     case S390_FEAT_TYPE_KDSA:
+    case S390_FEAT_TYPE_SORTL:
         set_be_bit(0, data); /* query is always available */
         break;
     default:
@@ -430,6 +438,7 @@ void s390_add_from_feat_block(S390FeatBitmap features, S390FeatType type,
        nr_bits = 16384;
        break;
     case S390_FEAT_TYPE_PLO:
+    case S390_FEAT_TYPE_SORTL:
        nr_bits = 256;
        break;
     default:
@@ -501,6 +510,7 @@ static S390FeatGroupDef s390_feature_groups[] = {
     FEAT_GROUP_INIT("msa9", MSA_EXT_9, "Message-security-assist-extension 9 facility"),
     FEAT_GROUP_INIT("msa9_pckmo", MSA_EXT_9_PCKMO, "Message-security-assist-extension 9 PCKMO subfunctions"),
     FEAT_GROUP_INIT("mepochptff", MULTIPLE_EPOCH_PTFF, "PTFF enhancements introduced with Multiple-epoch facility"),
+    FEAT_GROUP_INIT("esort", ENH_SORT, "Enhanced-sort facility"),
 };
 
 const S390FeatGroupDef *s390_feat_group_def(S390FeatGroup group)
diff --git a/target/s390x/cpu_features.h b/target/s390x/cpu_features.h
index 5ffd3db083..3b8c5b25dd 100644
--- a/target/s390x/cpu_features.h
+++ b/target/s390x/cpu_features.h
@@ -40,6 +40,7 @@ typedef enum {
     S390_FEAT_TYPE_PPNO,
     S390_FEAT_TYPE_KMA,
     S390_FEAT_TYPE_KDSA,
+    S390_FEAT_TYPE_SORTL,
 } S390FeatType;
 
 /* Definition of a CPU feature */
diff --git a/target/s390x/cpu_features_def.h b/target/s390x/cpu_features_def.h
index ce2223c9d7..bb8585847f 100644
--- a/target/s390x/cpu_features_def.h
+++ b/target/s390x/cpu_features_def.h
@@ -97,6 +97,7 @@ typedef enum {
     S390_FEAT_MSA_EXT_8,
     S390_FEAT_CMM_NT,
     S390_FEAT_VECTOR_ENH2,
+    S390_FEAT_ESORT_BASE,
     S390_FEAT_VECTOR_BCD_ENH,
     S390_FEAT_MSA_EXT_9,
     S390_FEAT_ETOKEN,
@@ -346,6 +347,13 @@ typedef enum {
     S390_FEAT_EEDDSA_SIGN_ED25519,
     S390_FEAT_EEDDSA_SIGN_ED448,
 
+    /* SORTL */
+    S390_FEAT_SORTL_SFLR,
+    S390_FEAT_SORTL_SVLR,
+    S390_FEAT_SORTL_32,
+    S390_FEAT_SORTL_128,
+    S390_FEAT_SORTL_F0,
+
     S390_FEAT_MAX,
 } S390Feat;
 
diff --git a/target/s390x/gen-features.c b/target/s390x/gen-features.c
index 64fe850ff2..3db323fc0c 100644
--- a/target/s390x/gen-features.c
+++ b/target/s390x/gen-features.c
@@ -245,6 +245,15 @@
     S390_FEAT_PCKMO_ECC_ED25519, \
     S390_FEAT_PCKMO_ECC_ED448
 
+#define S390_FEAT_GROUP_ENH_SORT \
+    S390_FEAT_ESORT_BASE, \
+    S390_FEAT_SORTL_SFLR, \
+    S390_FEAT_SORTL_SVLR, \
+    S390_FEAT_SORTL_32, \
+    S390_FEAT_SORTL_128, \
+    S390_FEAT_SORTL_F0
+
+
 /* cpu feature groups */
 static uint16_t group_PLO[] = {
     S390_FEAT_GROUP_PLO,
@@ -294,6 +303,10 @@ static uint16_t group_MSA_EXT_9_PCKMO[] = {
     S390_FEAT_GROUP_MSA_EXT_9_PCKMO,
 };
 
+static uint16_t group_ENH_SORT[] = {
+    S390_FEAT_GROUP_ENH_SORT,
+};
+
 /* Base features (in order of release)
  * Only non-hypervisor managed features belong here.
  * Base feature sets are static meaning they do not change in future QEMU
@@ -751,6 +764,7 @@ static FeatGroupDefSpec FeatGroupDef[] = {
     FEAT_GROUP_INITIALIZER(MSA_EXT_9),
     FEAT_GROUP_INITIALIZER(MSA_EXT_9_PCKMO),
     FEAT_GROUP_INITIALIZER(MULTIPLE_EPOCH_PTFF),
+    FEAT_GROUP_INITIALIZER(ENH_SORT),
 };
 
 #define QEMU_FEAT_INITIALIZER(_name)                   \
diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
index 88cef3476c..7681492c41 100644
--- a/target/s390x/kvm.c
+++ b/target/s390x/kvm.c
@@ -2083,6 +2083,9 @@ static int query_cpu_subfunc(S390FeatBitmap features)
     if (test_bit(S390_FEAT_MSA_EXT_9, features)) {
         s390_add_from_feat_block(features, S390_FEAT_TYPE_KDSA, prop.kdsa);
     }
+    if (test_bit(S390_FEAT_ESORT_BASE, features)) {
+        s390_add_from_feat_block(features, S390_FEAT_TYPE_SORTL, prop.sortl);
+    }
     return 0;
 }
 
@@ -2130,6 +2133,9 @@ static int configure_cpu_subfunc(const S390FeatBitmap features)
     if (test_bit(S390_FEAT_MSA_EXT_9, features)) {
         s390_fill_feat_block(features, S390_FEAT_TYPE_KDSA, prop.kdsa);
     }
+    if (test_bit(S390_FEAT_ESORT_BASE, features)) {
+        s390_fill_feat_block(features, S390_FEAT_TYPE_SORTL, prop.sortl);
+    }
     return kvm_vm_ioctl(kvm_state, KVM_SET_DEVICE_ATTR, &attr);
 }
 
-- 
2.19.1

[Qemu-devel] [PATCH 07/10] s390x/cpumodel: deflate

[Christian Borntraeger]

add the deflate conversion facility.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
 target/s390x/cpu_features.c     |  9 +++++++++
 target/s390x/cpu_features.h     |  1 +
 target/s390x/cpu_features_def.h |  7 +++++++
 target/s390x/gen-features.c     | 12 ++++++++++++
 target/s390x/kvm.c              |  6 ++++++
 5 files changed, 35 insertions(+)

diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
index e0a4769c19..5f37e655fe 100644
--- a/target/s390x/cpu_features.c
+++ b/target/s390x/cpu_features.c
@@ -110,6 +110,7 @@ static const S390FeatDef s390_features[] = {
     FEAT_INIT("cmmnt", S390_FEAT_TYPE_STFL, 147, "CMM: ESSA-enhancement (no translate) facility"),
     FEAT_INIT("vxeh2", S390_FEAT_TYPE_STFL, 148, "Vector Enhancements facility 2"),
     FEAT_INIT("esort-base", S390_FEAT_TYPE_STFL, 150, "Enhanced-sort facility (excluding subfunctions)"),
+    FEAT_INIT("deflate-base", S390_FEAT_TYPE_STFL, 151, "Deflate-conversion facility (excluding subfunctions)"),
     FEAT_INIT("vxbeh", S390_FEAT_TYPE_STFL, 152, "Vector BCD enhancements facility 1"),
     FEAT_INIT("msa9-base", S390_FEAT_TYPE_STFL, 155, "Message-security-assist-extension-9 facility (excluding subfunctions)"),
     FEAT_INIT("etoken", S390_FEAT_TYPE_STFL, 156, "Etoken facility"),
@@ -347,6 +348,11 @@ static const S390FeatDef s390_features[] = {
     FEAT_INIT("sortl-32", S390_FEAT_TYPE_SORTL, 130, "SORTL 32 input lists"),
     FEAT_INIT("sortl-128", S390_FEAT_TYPE_SORTL, 132, "SORTL 128 input lists"),
     FEAT_INIT("sortl-f0", S390_FEAT_TYPE_SORTL, 192, "SORTL format 0 parameter-block"),
+
+    FEAT_INIT("dfltcc-gdht", S390_FEAT_TYPE_DFLTCC, 1, "DFLTCC GDHT"),
+    FEAT_INIT("dfltcc-cmpr", S390_FEAT_TYPE_DFLTCC, 2, "DFLTCC CMPR"),
+    FEAT_INIT("dfltcc-xpnd", S390_FEAT_TYPE_DFLTCC, 4, "DFLTCC XPND"),
+    FEAT_INIT("dfltcc-f0", S390_FEAT_TYPE_DFLTCC, 192, "DFLTCC format 0 parameter-block"),
 };
 
 const S390FeatDef *s390_feat_def(S390Feat feat)
@@ -411,6 +417,7 @@ void s390_fill_feat_block(const S390FeatBitmap features, S390FeatType type,
     case S390_FEAT_TYPE_KMA:
     case S390_FEAT_TYPE_KDSA:
     case S390_FEAT_TYPE_SORTL:
+    case S390_FEAT_TYPE_DFLTCC:
         set_be_bit(0, data); /* query is always available */
         break;
     default:
@@ -439,6 +446,7 @@ void s390_add_from_feat_block(S390FeatBitmap features, S390FeatType type,
        break;
     case S390_FEAT_TYPE_PLO:
     case S390_FEAT_TYPE_SORTL:
+    case S390_FEAT_TYPE_DFLTCC:
        nr_bits = 256;
        break;
     default:
@@ -511,6 +519,7 @@ static S390FeatGroupDef s390_feature_groups[] = {
     FEAT_GROUP_INIT("msa9_pckmo", MSA_EXT_9_PCKMO, "Message-security-assist-extension 9 PCKMO subfunctions"),
     FEAT_GROUP_INIT("mepochptff", MULTIPLE_EPOCH_PTFF, "PTFF enhancements introduced with Multiple-epoch facility"),
     FEAT_GROUP_INIT("esort", ENH_SORT, "Enhanced-sort facility"),
+    FEAT_GROUP_INIT("deflate", DEFLATE_CONVERSION, "Deflate-conversion facility"),
 };
 
 const S390FeatGroupDef *s390_feat_group_def(S390FeatGroup group)
diff --git a/target/s390x/cpu_features.h b/target/s390x/cpu_features.h
index 3b8c5b25dd..da695a8346 100644
--- a/target/s390x/cpu_features.h
+++ b/target/s390x/cpu_features.h
@@ -41,6 +41,7 @@ typedef enum {
     S390_FEAT_TYPE_KMA,
     S390_FEAT_TYPE_KDSA,
     S390_FEAT_TYPE_SORTL,
+    S390_FEAT_TYPE_DFLTCC,
 } S390FeatType;
 
 /* Definition of a CPU feature */
diff --git a/target/s390x/cpu_features_def.h b/target/s390x/cpu_features_def.h
index bb8585847f..292b17b35d 100644
--- a/target/s390x/cpu_features_def.h
+++ b/target/s390x/cpu_features_def.h
@@ -98,6 +98,7 @@ typedef enum {
     S390_FEAT_CMM_NT,
     S390_FEAT_VECTOR_ENH2,
     S390_FEAT_ESORT_BASE,
+    S390_FEAT_DEFLATE_BASE,
     S390_FEAT_VECTOR_BCD_ENH,
     S390_FEAT_MSA_EXT_9,
     S390_FEAT_ETOKEN,
@@ -354,6 +355,12 @@ typedef enum {
     S390_FEAT_SORTL_128,
     S390_FEAT_SORTL_F0,
 
+    /* DEFLATE */
+    S390_FEAT_DEFLATE_GHDT,
+    S390_FEAT_DEFLATE_CMPR,
+    S390_FEAT_DEFLATE_XPND,
+    S390_FEAT_DEFLATE_F0,
+
     S390_FEAT_MAX,
 } S390Feat;
 
diff --git a/target/s390x/gen-features.c b/target/s390x/gen-features.c
index 3db323fc0c..170226d3dd 100644
--- a/target/s390x/gen-features.c
+++ b/target/s390x/gen-features.c
@@ -254,6 +254,13 @@
     S390_FEAT_SORTL_F0
 
 
+#define S390_FEAT_GROUP_DEFLATE_CONVERSION \
+    S390_FEAT_DEFLATE_BASE, \
+    S390_FEAT_DEFLATE_GHDT, \
+    S390_FEAT_DEFLATE_CMPR, \
+    S390_FEAT_DEFLATE_XPND, \
+    S390_FEAT_DEFLATE_F0
+
 /* cpu feature groups */
 static uint16_t group_PLO[] = {
     S390_FEAT_GROUP_PLO,
@@ -307,6 +314,10 @@ static uint16_t group_ENH_SORT[] = {
     S390_FEAT_GROUP_ENH_SORT,
 };
 
+static uint16_t group_DEFLATE_CONVERSION[] = {
+    S390_FEAT_GROUP_DEFLATE_CONVERSION,
+};
+
 /* Base features (in order of release)
  * Only non-hypervisor managed features belong here.
  * Base feature sets are static meaning they do not change in future QEMU
@@ -765,6 +776,7 @@ static FeatGroupDefSpec FeatGroupDef[] = {
     FEAT_GROUP_INITIALIZER(MSA_EXT_9_PCKMO),
     FEAT_GROUP_INITIALIZER(MULTIPLE_EPOCH_PTFF),
     FEAT_GROUP_INITIALIZER(ENH_SORT),
+    FEAT_GROUP_INITIALIZER(DEFLATE_CONVERSION),
 };
 
 #define QEMU_FEAT_INITIALIZER(_name)                   \
diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
index 7681492c41..db9108b63c 100644
--- a/target/s390x/kvm.c
+++ b/target/s390x/kvm.c
@@ -2086,6 +2086,9 @@ static int query_cpu_subfunc(S390FeatBitmap features)
     if (test_bit(S390_FEAT_ESORT_BASE, features)) {
         s390_add_from_feat_block(features, S390_FEAT_TYPE_SORTL, prop.sortl);
     }
+    if (test_bit(S390_FEAT_DEFLATE_BASE, features)) {
+        s390_add_from_feat_block(features, S390_FEAT_TYPE_DFLTCC, prop.dfltcc);
+    }
     return 0;
 }
 
@@ -2136,6 +2139,9 @@ static int configure_cpu_subfunc(const S390FeatBitmap features)
     if (test_bit(S390_FEAT_ESORT_BASE, features)) {
         s390_fill_feat_block(features, S390_FEAT_TYPE_SORTL, prop.sortl);
     }
+    if (test_bit(S390_FEAT_DEFLATE_BASE, features)) {
+        s390_fill_feat_block(features, S390_FEAT_TYPE_DFLTCC, prop.dfltcc);
+    }
     return kvm_vm_ioctl(kvm_state, KVM_SET_DEVICE_ATTR, &attr);
 }
 
-- 
2.19.1

[Qemu-devel] [PATCH 07/10] s390x/cpumodel: deflate

[Christian Borntraeger]

add the deflate conversion facility.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
 target/s390x/cpu_features.c     |  9 +++++++++
 target/s390x/cpu_features.h     |  1 +
 target/s390x/cpu_features_def.h |  7 +++++++
 target/s390x/gen-features.c     | 12 ++++++++++++
 target/s390x/kvm.c              |  6 ++++++
 5 files changed, 35 insertions(+)

diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
index e0a4769c19..5f37e655fe 100644
--- a/target/s390x/cpu_features.c
+++ b/target/s390x/cpu_features.c
@@ -110,6 +110,7 @@ static const S390FeatDef s390_features[] = {
     FEAT_INIT("cmmnt", S390_FEAT_TYPE_STFL, 147, "CMM: ESSA-enhancement (no translate) facility"),
     FEAT_INIT("vxeh2", S390_FEAT_TYPE_STFL, 148, "Vector Enhancements facility 2"),
     FEAT_INIT("esort-base", S390_FEAT_TYPE_STFL, 150, "Enhanced-sort facility (excluding subfunctions)"),
+    FEAT_INIT("deflate-base", S390_FEAT_TYPE_STFL, 151, "Deflate-conversion facility (excluding subfunctions)"),
     FEAT_INIT("vxbeh", S390_FEAT_TYPE_STFL, 152, "Vector BCD enhancements facility 1"),
     FEAT_INIT("msa9-base", S390_FEAT_TYPE_STFL, 155, "Message-security-assist-extension-9 facility (excluding subfunctions)"),
     FEAT_INIT("etoken", S390_FEAT_TYPE_STFL, 156, "Etoken facility"),
@@ -347,6 +348,11 @@ static const S390FeatDef s390_features[] = {
     FEAT_INIT("sortl-32", S390_FEAT_TYPE_SORTL, 130, "SORTL 32 input lists"),
     FEAT_INIT("sortl-128", S390_FEAT_TYPE_SORTL, 132, "SORTL 128 input lists"),
     FEAT_INIT("sortl-f0", S390_FEAT_TYPE_SORTL, 192, "SORTL format 0 parameter-block"),
+
+    FEAT_INIT("dfltcc-gdht", S390_FEAT_TYPE_DFLTCC, 1, "DFLTCC GDHT"),
+    FEAT_INIT("dfltcc-cmpr", S390_FEAT_TYPE_DFLTCC, 2, "DFLTCC CMPR"),
+    FEAT_INIT("dfltcc-xpnd", S390_FEAT_TYPE_DFLTCC, 4, "DFLTCC XPND"),
+    FEAT_INIT("dfltcc-f0", S390_FEAT_TYPE_DFLTCC, 192, "DFLTCC format 0 parameter-block"),
 };
 
 const S390FeatDef *s390_feat_def(S390Feat feat)
@@ -411,6 +417,7 @@ void s390_fill_feat_block(const S390FeatBitmap features, S390FeatType type,
     case S390_FEAT_TYPE_KMA:
     case S390_FEAT_TYPE_KDSA:
     case S390_FEAT_TYPE_SORTL:
+    case S390_FEAT_TYPE_DFLTCC:
         set_be_bit(0, data); /* query is always available */
         break;
     default:
@@ -439,6 +446,7 @@ void s390_add_from_feat_block(S390FeatBitmap features, S390FeatType type,
        break;
     case S390_FEAT_TYPE_PLO:
     case S390_FEAT_TYPE_SORTL:
+    case S390_FEAT_TYPE_DFLTCC:
        nr_bits = 256;
        break;
     default:
@@ -511,6 +519,7 @@ static S390FeatGroupDef s390_feature_groups[] = {
     FEAT_GROUP_INIT("msa9_pckmo", MSA_EXT_9_PCKMO, "Message-security-assist-extension 9 PCKMO subfunctions"),
     FEAT_GROUP_INIT("mepochptff", MULTIPLE_EPOCH_PTFF, "PTFF enhancements introduced with Multiple-epoch facility"),
     FEAT_GROUP_INIT("esort", ENH_SORT, "Enhanced-sort facility"),
+    FEAT_GROUP_INIT("deflate", DEFLATE_CONVERSION, "Deflate-conversion facility"),
 };
 
 const S390FeatGroupDef *s390_feat_group_def(S390FeatGroup group)
diff --git a/target/s390x/cpu_features.h b/target/s390x/cpu_features.h
index 3b8c5b25dd..da695a8346 100644
--- a/target/s390x/cpu_features.h
+++ b/target/s390x/cpu_features.h
@@ -41,6 +41,7 @@ typedef enum {
     S390_FEAT_TYPE_KMA,
     S390_FEAT_TYPE_KDSA,
     S390_FEAT_TYPE_SORTL,
+    S390_FEAT_TYPE_DFLTCC,
 } S390FeatType;
 
 /* Definition of a CPU feature */
diff --git a/target/s390x/cpu_features_def.h b/target/s390x/cpu_features_def.h
index bb8585847f..292b17b35d 100644
--- a/target/s390x/cpu_features_def.h
+++ b/target/s390x/cpu_features_def.h
@@ -98,6 +98,7 @@ typedef enum {
     S390_FEAT_CMM_NT,
     S390_FEAT_VECTOR_ENH2,
     S390_FEAT_ESORT_BASE,
+    S390_FEAT_DEFLATE_BASE,
     S390_FEAT_VECTOR_BCD_ENH,
     S390_FEAT_MSA_EXT_9,
     S390_FEAT_ETOKEN,
@@ -354,6 +355,12 @@ typedef enum {
     S390_FEAT_SORTL_128,
     S390_FEAT_SORTL_F0,
 
+    /* DEFLATE */
+    S390_FEAT_DEFLATE_GHDT,
+    S390_FEAT_DEFLATE_CMPR,
+    S390_FEAT_DEFLATE_XPND,
+    S390_FEAT_DEFLATE_F0,
+
     S390_FEAT_MAX,
 } S390Feat;
 
diff --git a/target/s390x/gen-features.c b/target/s390x/gen-features.c
index 3db323fc0c..170226d3dd 100644
--- a/target/s390x/gen-features.c
+++ b/target/s390x/gen-features.c
@@ -254,6 +254,13 @@
     S390_FEAT_SORTL_F0
 
 
+#define S390_FEAT_GROUP_DEFLATE_CONVERSION \
+    S390_FEAT_DEFLATE_BASE, \
+    S390_FEAT_DEFLATE_GHDT, \
+    S390_FEAT_DEFLATE_CMPR, \
+    S390_FEAT_DEFLATE_XPND, \
+    S390_FEAT_DEFLATE_F0
+
 /* cpu feature groups */
 static uint16_t group_PLO[] = {
     S390_FEAT_GROUP_PLO,
@@ -307,6 +314,10 @@ static uint16_t group_ENH_SORT[] = {
     S390_FEAT_GROUP_ENH_SORT,
 };
 
+static uint16_t group_DEFLATE_CONVERSION[] = {
+    S390_FEAT_GROUP_DEFLATE_CONVERSION,
+};
+
 /* Base features (in order of release)
  * Only non-hypervisor managed features belong here.
  * Base feature sets are static meaning they do not change in future QEMU
@@ -765,6 +776,7 @@ static FeatGroupDefSpec FeatGroupDef[] = {
     FEAT_GROUP_INITIALIZER(MSA_EXT_9_PCKMO),
     FEAT_GROUP_INITIALIZER(MULTIPLE_EPOCH_PTFF),
     FEAT_GROUP_INITIALIZER(ENH_SORT),
+    FEAT_GROUP_INITIALIZER(DEFLATE_CONVERSION),
 };
 
 #define QEMU_FEAT_INITIALIZER(_name)                   \
diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
index 7681492c41..db9108b63c 100644
--- a/target/s390x/kvm.c
+++ b/target/s390x/kvm.c
@@ -2086,6 +2086,9 @@ static int query_cpu_subfunc(S390FeatBitmap features)
     if (test_bit(S390_FEAT_ESORT_BASE, features)) {
         s390_add_from_feat_block(features, S390_FEAT_TYPE_SORTL, prop.sortl);
     }
+    if (test_bit(S390_FEAT_DEFLATE_BASE, features)) {
+        s390_add_from_feat_block(features, S390_FEAT_TYPE_DFLTCC, prop.dfltcc);
+    }
     return 0;
 }
 
@@ -2136,6 +2139,9 @@ static int configure_cpu_subfunc(const S390FeatBitmap features)
     if (test_bit(S390_FEAT_ESORT_BASE, features)) {
         s390_fill_feat_block(features, S390_FEAT_TYPE_SORTL, prop.sortl);
     }
+    if (test_bit(S390_FEAT_DEFLATE_BASE, features)) {
+        s390_fill_feat_block(features, S390_FEAT_TYPE_DFLTCC, prop.dfltcc);
+    }
     return kvm_vm_ioctl(kvm_state, KVM_SET_DEVICE_ATTR, &attr);
 }
 
-- 
2.19.1

[Qemu-devel] [PATCH 08/10] s390x/cpumodel: add gen15 defintions

[Christian Borntraeger]

add several new features (msa9, sort, deflate, additional vector
instructions, new general purpose instructions) to generation 15.

Also disable csske and bpb from the default model. This will allow to
migrate generation 15 machines to future machines that do not have these
features.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
 hw/s390x/s390-virtio-ccw.c  |  4 ++++
 target/s390x/gen-features.c | 25 +++++++++++++++++++++++++
 2 files changed, 29 insertions(+)

diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index 3415948b2c..d7a9e487e0 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -594,6 +594,10 @@ static inline void s390_machine_initfn(Object *obj)
             " to upper case) to pass to machine loader, boot manager,"
             " and guest kernel",
             NULL);
+
+    /* deprecated functionality for gen15 and later */
+    s390_cpudef_featoff_greater(15, 1, S390_FEAT_BPB);
+    s390_cpudef_featoff_greater(15, 1, S390_FEAT_CONDITIONAL_SSKE);
 }
 
 static const TypeInfo ccw_machine_info = {
diff --git a/target/s390x/gen-features.c b/target/s390x/gen-features.c
index 170226d3dd..4cf5a21cc1 100644
--- a/target/s390x/gen-features.c
+++ b/target/s390x/gen-features.c
@@ -418,6 +418,10 @@ static uint16_t base_GEN14_GA1[] = {
 
 #define base_GEN14_GA2 EmptyFeat
 
+static uint16_t base_GEN15_GA1[] = {
+    S390_FEAT_MISC_INSTRUCTION_EXT3,
+};
+
 /* Full features (in order of release)
  * Automatically includes corresponding base features.
  * Full features are all features this hardware supports even if kvm/QEMU do not
@@ -547,6 +551,16 @@ static uint16_t full_GEN14_GA1[] = {
 
 #define full_GEN14_GA2 EmptyFeat
 
+static uint16_t full_GEN15_GA1[] = {
+    S390_FEAT_VECTOR_ENH2,
+    S390_FEAT_GROUP_ENH_SORT,
+    S390_FEAT_GROUP_DEFLATE_CONVERSION,
+    S390_FEAT_VECTOR_BCD_ENH,
+    S390_FEAT_GROUP_MSA_EXT_9,
+    S390_FEAT_GROUP_MSA_EXT_9_PCKMO,
+    S390_FEAT_ETOKEN,
+};
+
 /* Default features (in order of release)
  * Automatically includes corresponding base features.
  * Default features are all features this version of QEMU supports for this
@@ -623,6 +637,16 @@ static uint16_t default_GEN14_GA1[] = {
 
 #define default_GEN14_GA2 EmptyFeat
 
+static uint16_t default_GEN15_GA1[] = {
+    S390_FEAT_VECTOR_ENH2,
+    S390_FEAT_GROUP_ENH_SORT,
+    S390_FEAT_GROUP_DEFLATE_CONVERSION,
+    S390_FEAT_VECTOR_BCD_ENH,
+    S390_FEAT_GROUP_MSA_EXT_9,
+    S390_FEAT_GROUP_MSA_EXT_9_PCKMO,
+    S390_FEAT_ETOKEN,
+};
+
 /* QEMU (CPU model) features */
 
 static uint16_t qemu_V2_11[] = {
@@ -739,6 +763,7 @@ static CpuFeatDefSpec CpuFeatDef[] = {
     CPU_FEAT_INITIALIZER(GEN13_GA2),
     CPU_FEAT_INITIALIZER(GEN14_GA1),
     CPU_FEAT_INITIALIZER(GEN14_GA2),
+    CPU_FEAT_INITIALIZER(GEN15_GA1),
 };
 
 #define FEAT_GROUP_INITIALIZER(_name)                  \
-- 
2.19.1

[Qemu-devel] [PATCH 08/10] s390x/cpumodel: add gen15 defintions

[Christian Borntraeger]

add several new features (msa9, sort, deflate, additional vector
instructions, new general purpose instructions) to generation 15.

Also disable csske and bpb from the default model. This will allow to
migrate generation 15 machines to future machines that do not have these
features.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
 hw/s390x/s390-virtio-ccw.c  |  4 ++++
 target/s390x/gen-features.c | 25 +++++++++++++++++++++++++
 2 files changed, 29 insertions(+)

diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index 3415948b2c..d7a9e487e0 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -594,6 +594,10 @@ static inline void s390_machine_initfn(Object *obj)
             " to upper case) to pass to machine loader, boot manager,"
             " and guest kernel",
             NULL);
+
+    /* deprecated functionality for gen15 and later */
+    s390_cpudef_featoff_greater(15, 1, S390_FEAT_BPB);
+    s390_cpudef_featoff_greater(15, 1, S390_FEAT_CONDITIONAL_SSKE);
 }
 
 static const TypeInfo ccw_machine_info = {
diff --git a/target/s390x/gen-features.c b/target/s390x/gen-features.c
index 170226d3dd..4cf5a21cc1 100644
--- a/target/s390x/gen-features.c
+++ b/target/s390x/gen-features.c
@@ -418,6 +418,10 @@ static uint16_t base_GEN14_GA1[] = {
 
 #define base_GEN14_GA2 EmptyFeat
 
+static uint16_t base_GEN15_GA1[] = {
+    S390_FEAT_MISC_INSTRUCTION_EXT3,
+};
+
 /* Full features (in order of release)
  * Automatically includes corresponding base features.
  * Full features are all features this hardware supports even if kvm/QEMU do not
@@ -547,6 +551,16 @@ static uint16_t full_GEN14_GA1[] = {
 
 #define full_GEN14_GA2 EmptyFeat
 
+static uint16_t full_GEN15_GA1[] = {
+    S390_FEAT_VECTOR_ENH2,
+    S390_FEAT_GROUP_ENH_SORT,
+    S390_FEAT_GROUP_DEFLATE_CONVERSION,
+    S390_FEAT_VECTOR_BCD_ENH,
+    S390_FEAT_GROUP_MSA_EXT_9,
+    S390_FEAT_GROUP_MSA_EXT_9_PCKMO,
+    S390_FEAT_ETOKEN,
+};
+
 /* Default features (in order of release)
  * Automatically includes corresponding base features.
  * Default features are all features this version of QEMU supports for this
@@ -623,6 +637,16 @@ static uint16_t default_GEN14_GA1[] = {
 
 #define default_GEN14_GA2 EmptyFeat
 
+static uint16_t default_GEN15_GA1[] = {
+    S390_FEAT_VECTOR_ENH2,
+    S390_FEAT_GROUP_ENH_SORT,
+    S390_FEAT_GROUP_DEFLATE_CONVERSION,
+    S390_FEAT_VECTOR_BCD_ENH,
+    S390_FEAT_GROUP_MSA_EXT_9,
+    S390_FEAT_GROUP_MSA_EXT_9_PCKMO,
+    S390_FEAT_ETOKEN,
+};
+
 /* QEMU (CPU model) features */
 
 static uint16_t qemu_V2_11[] = {
@@ -739,6 +763,7 @@ static CpuFeatDefSpec CpuFeatDef[] = {
     CPU_FEAT_INITIALIZER(GEN13_GA2),
     CPU_FEAT_INITIALIZER(GEN14_GA1),
     CPU_FEAT_INITIALIZER(GEN14_GA2),
+    CPU_FEAT_INITIALIZER(GEN15_GA1),
 };
 
 #define FEAT_GROUP_INITIALIZER(_name)                  \
-- 
2.19.1

[Qemu-devel] [PATCH 09/10] s390x/cpumodel: wire up 8561 and 8562 as gen15 machines

[Christian Borntraeger]

8561 and 8562 will be gen15 machines. There is no name yet, lets us use
the cpu id as base name. Later on we can provide aliases with the proper
name.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
 target/s390x/cpu_models.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
index 4c355e936e..e727519686 100644
--- a/target/s390x/cpu_models.c
+++ b/target/s390x/cpu_models.c
@@ -82,6 +82,8 @@ static S390CPUDef s390_cpu_defs[] = {
     CPUDEF_INIT(0x3906, 14, 1, 47, 0x08000000U, "z14", "IBM z14 GA1"),
     CPUDEF_INIT(0x3906, 14, 2, 47, 0x08000000U, "z14.2", "IBM z14 GA2"),
     CPUDEF_INIT(0x3907, 14, 1, 47, 0x08000000U, "z14ZR1", "IBM z14 Model ZR1 GA1"),
+    CPUDEF_INIT(0x8561, 15, 1, 47, 0x08000000U, "8561", "IBM 8561 GA1"),
+    CPUDEF_INIT(0x8562, 15, 1, 47, 0x08000000U, "8562", "IBM 8562 GA1"),
 };
 
 #define QEMU_MAX_CPU_TYPE 0x2827
-- 
2.19.1

[Qemu-devel] [PATCH 09/10] s390x/cpumodel: wire up 8561 and 8562 as gen15 machines

[Christian Borntraeger]

8561 and 8562 will be gen15 machines. There is no name yet, lets us use
the cpu id as base name. Later on we can provide aliases with the proper
name.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
 target/s390x/cpu_models.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
index 4c355e936e..e727519686 100644
--- a/target/s390x/cpu_models.c
+++ b/target/s390x/cpu_models.c
@@ -82,6 +82,8 @@ static S390CPUDef s390_cpu_defs[] = {
     CPUDEF_INIT(0x3906, 14, 1, 47, 0x08000000U, "z14", "IBM z14 GA1"),
     CPUDEF_INIT(0x3906, 14, 2, 47, 0x08000000U, "z14.2", "IBM z14 GA2"),
     CPUDEF_INIT(0x3907, 14, 1, 47, 0x08000000U, "z14ZR1", "IBM z14 Model ZR1 GA1"),
+    CPUDEF_INIT(0x8561, 15, 1, 47, 0x08000000U, "8561", "IBM 8561 GA1"),
+    CPUDEF_INIT(0x8562, 15, 1, 47, 0x08000000U, "8562", "IBM 8562 GA1"),
 };
 
 #define QEMU_MAX_CPU_TYPE 0x2827
-- 
2.19.1

[Qemu-devel] [PATCH 10/10] s390x/cpumodel: do not claim csske for expanded models in qmp

[Christian Borntraeger]

While we have removed csske and bpb from the default model, the very
common case of "host-model" in libvirt (expanded to a base model
+ features) would still contain bpb and csske. This can prevent
migration to a future machine for a host-model machine. Let us fence
bpb and csske when we run on a generation 15. If necessary the
user can still use -cpu 8561,csske=on,bpb=on to force enable these
features.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
 target/s390x/cpu_models.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
index e727519686..03bdca1fb8 100644
--- a/target/s390x/cpu_models.c
+++ b/target/s390x/cpu_models.c
@@ -629,6 +629,17 @@ CpuModelExpansionInfo *qmp_query_cpu_model_expansion(CpuModelExpansionType type,
         return NULL;
     }
 
+    /*
+     * Do not claim CSSKE and BPB if the host model expands to
+     * generation 15 or newer
+     */
+    if (s390_model.def->gen >= 15) {
+        clear_bit(S390_FEAT_CONDITIONAL_SSKE,
+                  (unsigned long *) &s390_model.features);
+        clear_bit(S390_FEAT_BPB,
+                  (unsigned long *) &s390_model.features);
+    }
+
     if (type == CPU_MODEL_EXPANSION_TYPE_STATIC) {
         delta_changes = true;
     } else if (type != CPU_MODEL_EXPANSION_TYPE_FULL) {
-- 
2.19.1

[Qemu-devel] [PATCH 10/10] s390x/cpumodel: do not claim csske for expanded models in qmp

[Christian Borntraeger]

While we have removed csske and bpb from the default model, the very
common case of "host-model" in libvirt (expanded to a base model
+ features) would still contain bpb and csske. This can prevent
migration to a future machine for a host-model machine. Let us fence
bpb and csske when we run on a generation 15. If necessary the
user can still use -cpu 8561,csske=on,bpb=on to force enable these
features.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
 target/s390x/cpu_models.c | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
index e727519686..03bdca1fb8 100644
--- a/target/s390x/cpu_models.c
+++ b/target/s390x/cpu_models.c
@@ -629,6 +629,17 @@ CpuModelExpansionInfo *qmp_query_cpu_model_expansion(CpuModelExpansionType type,
         return NULL;
     }
 
+    /*
+     * Do not claim CSSKE and BPB if the host model expands to
+     * generation 15 or newer
+     */
+    if (s390_model.def->gen >= 15) {
+        clear_bit(S390_FEAT_CONDITIONAL_SSKE,
+                  (unsigned long *) &s390_model.features);
+        clear_bit(S390_FEAT_BPB,
+                  (unsigned long *) &s390_model.features);
+    }
+
     if (type == CPU_MODEL_EXPANSION_TYPE_STATIC) {
         delta_changes = true;
     } else if (type != CPU_MODEL_EXPANSION_TYPE_FULL) {
-- 
2.19.1

Re: [Qemu-devel] [PATCH 00/10] s390x: new guest features

[no-reply]

Patchew URL: https://patchew.org/QEMU/20190418113110.160664-1-borntraeger@de.ibm.com/



Hi,

This series seems to have some coding style problems. See output below for
more information:

Message-id: 20190418113110.160664-1-borntraeger@de.ibm.com
Type: series
Subject: [Qemu-devel] [PATCH 00/10]  s390x: new guest features

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag]         patchew/1555587766-985-1-git-send-email-mateja.marjanovic@rt-rk.com -> patchew/1555587766-985-1-git-send-email-mateja.marjanovic@rt-rk.com
 * [new tag]         patchew/20190418113110.160664-1-borntraeger@de.ibm.com -> patchew/20190418113110.160664-1-borntraeger@de.ibm.com
Switched to a new branch 'test'
c4c9ad7 s390x/cpumodel: do not claim csske for expanded models in qmp
76c71e3 s390x/cpumodel: wire up 8561 and 8562 as gen15 machines
544a8a6 s390x/cpumodel: add gen15 defintions
9ad6b30 s390x/cpumodel: deflate
d77001b s390x/cpumodel: enhanced sort facility
5971793 s390x/cpumodel: vector enhancements
f5fadd1 s390x/cpumodel: msa9 facility
06fb20b s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3
54ab59d s390x/cpumodel: remove CSSKE from base model
60aaa57 linux header sync

=== OUTPUT BEGIN ===
1/10 Checking commit 60aaa5790659 (linux header sync)
2/10 Checking commit 54ab59dbdbd8 (s390x/cpumodel: remove CSSKE from base model)
WARNING: line over 80 characters
#55: FILE: target/s390x/cpu_models.c:113:
+        set_bit(S390_FEAT_CONDITIONAL_SSKE, (unsigned long *)&def->default_feat);

total: 0 errors, 1 warnings, 49 lines checked

Patch 2/10 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
3/10 Checking commit 06fb20b97263 (s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3)
ERROR: line over 90 characters
#21: FILE: target/s390x/cpu_features.c:86:
+    FEAT_INIT("minste3", S390_FEAT_TYPE_STFL, 61, "Miscellaneous-Instruction-Extensions Facility 3"),

total: 1 errors, 0 warnings, 14 lines checked

Patch 3/10 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

4/10 Checking commit f5fadd1a9543 (s390x/cpumodel: msa9 facility)
ERROR: line over 90 characters
#22: FILE: target/s390x/cpu_features.c:111:
+    FEAT_INIT("msa9-base", S390_FEAT_TYPE_STFL, 155, "Message-security-assist-extension-9 facility (excluding subfunctions)"),

WARNING: line over 80 characters
#30: FILE: target/s390x/cpu_features.c:246:
+    FEAT_INIT("pckmo-ecc-p256", S390_FEAT_TYPE_PCKMO,32, "PCKMO Encrypt-ECC-P256-Key"),

ERROR: space required after that ',' (ctx:VxV)
#30: FILE: target/s390x/cpu_features.c:246:
+    FEAT_INIT("pckmo-ecc-p256", S390_FEAT_TYPE_PCKMO,32, "PCKMO Encrypt-ECC-P256-Key"),
                                                     ^

WARNING: line over 80 characters
#31: FILE: target/s390x/cpu_features.c:247:
+    FEAT_INIT("pckmo-ecc-p384", S390_FEAT_TYPE_PCKMO,33, "PCKMO Encrypt-ECC-P384-Key"),

ERROR: space required after that ',' (ctx:VxV)
#31: FILE: target/s390x/cpu_features.c:247:
+    FEAT_INIT("pckmo-ecc-p384", S390_FEAT_TYPE_PCKMO,33, "PCKMO Encrypt-ECC-P384-Key"),
                                                     ^

WARNING: line over 80 characters
#32: FILE: target/s390x/cpu_features.c:248:
+    FEAT_INIT("pckmo-ecc-p521", S390_FEAT_TYPE_PCKMO,34, "PCKMO Encrypt-ECC-P521-Key"),

ERROR: space required after that ',' (ctx:VxV)
#32: FILE: target/s390x/cpu_features.c:248:
+    FEAT_INIT("pckmo-ecc-p521", S390_FEAT_TYPE_PCKMO,34, "PCKMO Encrypt-ECC-P521-Key"),
                                                     ^

ERROR: line over 90 characters
#33: FILE: target/s390x/cpu_features.c:249:
+    FEAT_INIT("pckmo-ecc-ed25519", S390_FEAT_TYPE_PCKMO,40 , "PCKMO Encrypt-ECC-Ed25519-Key"),

ERROR: space required after that ',' (ctx:VxV)
#33: FILE: target/s390x/cpu_features.c:249:
+    FEAT_INIT("pckmo-ecc-ed25519", S390_FEAT_TYPE_PCKMO,40 , "PCKMO Encrypt-ECC-Ed25519-Key"),
                                                        ^

WARNING: line over 80 characters
#34: FILE: target/s390x/cpu_features.c:250:
+    FEAT_INIT("pckmo-ecc-ed448", S390_FEAT_TYPE_PCKMO,41 , "PCKMO Encrypt-ECC-Ed448-Key"),

ERROR: space required after that ',' (ctx:VxV)
#34: FILE: target/s390x/cpu_features.c:250:
+    FEAT_INIT("pckmo-ecc-ed448", S390_FEAT_TYPE_PCKMO,41 , "PCKMO Encrypt-ECC-Ed448-Key"),
                                                      ^

WARNING: line over 80 characters
#42: FILE: target/s390x/cpu_features.c:307:
+    FEAT_INIT("pcc-scalar-mult-p256", S390_FEAT_TYPE_PCC, 64, "PCC Scalar-Multiply-P256"),

WARNING: line over 80 characters
#43: FILE: target/s390x/cpu_features.c:308:
+    FEAT_INIT("pcc-scalar-mult-p384", S390_FEAT_TYPE_PCC, 65, "PCC Scalar-Multiply-P384"),

WARNING: line over 80 characters
#44: FILE: target/s390x/cpu_features.c:309:
+    FEAT_INIT("pcc-scalar-mult-p521", S390_FEAT_TYPE_PCC, 66, "PCC Scalar-Multiply-P521"),

ERROR: line over 90 characters
#45: FILE: target/s390x/cpu_features.c:310:
+    FEAT_INIT("pcc-scalar-mult-ed25519", S390_FEAT_TYPE_PCC, 72, "PCC Scalar-Multiply-Ed25519"),

ERROR: line over 90 characters
#46: FILE: target/s390x/cpu_features.c:311:
+    FEAT_INIT("pcc-scalar-mult-ed448", S390_FEAT_TYPE_PCC, 73, "PCC Scalar-Multiply-Ed448"),

ERROR: line over 90 characters
#47: FILE: target/s390x/cpu_features.c:312:
+    FEAT_INIT("pcc-scalar-mult-x25519", S390_FEAT_TYPE_PCC, 80, "PCC Scalar-Multiply-X25519"),

WARNING: line over 80 characters
#48: FILE: target/s390x/cpu_features.c:313:
+    FEAT_INIT("pcc-scalar-mult-x448", S390_FEAT_TYPE_PCC, 81, "PCC Scalar-Multiply-X448"),

WARNING: line over 80 characters
#57: FILE: target/s390x/cpu_features.c:326:
+    FEAT_INIT("kdsa-ecdsa-verify-p256", S390_FEAT_TYPE_KDSA, 1, "KDSA ECDSA-Verify-P256"),

WARNING: line over 80 characters
#58: FILE: target/s390x/cpu_features.c:327:
+    FEAT_INIT("kdsa-ecdsa-verify-p384", S390_FEAT_TYPE_KDSA, 2, "KDSA ECDSA-Verify-P384"),

WARNING: line over 80 characters
#59: FILE: target/s390x/cpu_features.c:328:
+    FEAT_INIT("kdsa-ecdsa-verify-p521", S390_FEAT_TYPE_KDSA, 3, "KDSA ECDSA-Verify-P521"),

WARNING: line over 80 characters
#60: FILE: target/s390x/cpu_features.c:329:
+    FEAT_INIT("kdsa-ecdsa-sign-p256", S390_FEAT_TYPE_KDSA, 9, "KDSA ECDSA-Sign-P256"),

WARNING: line over 80 characters
#61: FILE: target/s390x/cpu_features.c:330:
+    FEAT_INIT("kdsa-ecdsa-sign-p384", S390_FEAT_TYPE_KDSA, 10, "KDSA ECDSA-Sign-P384"),

WARNING: line over 80 characters
#62: FILE: target/s390x/cpu_features.c:331:
+    FEAT_INIT("kdsa-ecdsa-sign-p521", S390_FEAT_TYPE_KDSA, 11, "KDSA ECDSA-Sign-P521"),

ERROR: line over 90 characters
#63: FILE: target/s390x/cpu_features.c:332:
+    FEAT_INIT("kdsa-eecdsa-sign-p256", S390_FEAT_TYPE_KDSA, 17, "KDSA Encrypted-ECDSA-Sign-P256"),

ERROR: line over 90 characters
#64: FILE: target/s390x/cpu_features.c:333:
+    FEAT_INIT("kdsa-eecdsa-sign-p384", S390_FEAT_TYPE_KDSA, 18, "KDSA Encrypted-ECDSA-Sign-P384"),

ERROR: line over 90 characters
#65: FILE: target/s390x/cpu_features.c:334:
+    FEAT_INIT("kdsa-eecdsa-sign-p521", S390_FEAT_TYPE_KDSA, 19, "KDSA Encrypted-ECDSA-Sign-P521"),

ERROR: line over 90 characters
#66: FILE: target/s390x/cpu_features.c:335:
+    FEAT_INIT("kdsa-eddsa-verify-ed25519", S390_FEAT_TYPE_KDSA, 32, "KDSA EdDSA-Verify-Ed25519"),

ERROR: line over 90 characters
#67: FILE: target/s390x/cpu_features.c:336:
+    FEAT_INIT("kdsa-eddsa-verify-ed448", S390_FEAT_TYPE_KDSA, 36, "KDSA EdDSA-Verify-Ed448"),

ERROR: line over 90 characters
#68: FILE: target/s390x/cpu_features.c:337:
+    FEAT_INIT("kdsa-eddsa-sign-ed25519", S390_FEAT_TYPE_KDSA, 40, "KDSA EdDSA-Sign-Ed25519"),

WARNING: line over 80 characters
#69: FILE: target/s390x/cpu_features.c:338:
+    FEAT_INIT("kdsa-eddsa-sign-ed448", S390_FEAT_TYPE_KDSA, 44, "KDSA EdDSA-Sign-Ed448"),

ERROR: line over 90 characters
#70: FILE: target/s390x/cpu_features.c:339:
+    FEAT_INIT("kdsa-eeddsa-sign-ed25519", S390_FEAT_TYPE_KDSA, 48, "KDSA Encrypted-EdDSA-Sign-Ed25519"),

ERROR: line over 90 characters
#71: FILE: target/s390x/cpu_features.c:340:
+    FEAT_INIT("kdsa-eeddsa-sign-ed448", S390_FEAT_TYPE_KDSA, 52, "KDSA Encrypted-EdDSA-Sign-Ed448"),

WARNING: line over 80 characters
#87: FILE: target/s390x/cpu_features.c:499:
+    FEAT_GROUP_INIT("msa9", MSA_EXT_9, "Message-security-assist-extension 9 facility"),

ERROR: line over 90 characters
#88: FILE: target/s390x/cpu_features.c:500:
+    FEAT_GROUP_INIT("msa9_pckmo", MSA_EXT_9_PCKMO, "Message-security-assist-extension 9 PCKMO subfunctions"),

ERROR: Macros with complex values should be enclosed in parenthesis
#187: FILE: target/s390x/gen-features.c:216:
+#define S390_FEAT_GROUP_MSA_EXT_9 \
+    S390_FEAT_MSA_EXT_9,       \
+    S390_FEAT_ECDSA_VERIFY_P256, \
+    S390_FEAT_ECDSA_VERIFY_P384, \
+    S390_FEAT_ECDSA_VERIFY_P512, \
+    S390_FEAT_ECDSA_SIGN_P256, \
+    S390_FEAT_ECDSA_SIGN_P384, \
+    S390_FEAT_ECDSA_SIGN_P512, \
+    S390_FEAT_EECDSA_SIGN_P256, \
+    S390_FEAT_EECDSA_SIGN_P384, \
+    S390_FEAT_EECDSA_SIGN_P512, \
+    S390_FEAT_EDDSA_VERIFY_ED25519, \
+    S390_FEAT_EDDSA_VERIFY_ED448, \
+    S390_FEAT_EDDSA_SIGN_ED25519, \
+    S390_FEAT_EDDSA_SIGN_ED448, \
+    S390_FEAT_EEDDSA_SIGN_ED25519, \
+    S390_FEAT_EEDDSA_SIGN_ED448, \
+    S390_FEAT_PCC_SCALAR_MULT_P256, \
+    S390_FEAT_PCC_SCALAR_MULT_P384, \
+    S390_FEAT_PCC_SCALAR_MULT_P512, \
+    S390_FEAT_PCC_SCALAR_MULT_ED25519, \
+    S390_FEAT_PCC_SCALAR_MULT_ED448, \
+    S390_FEAT_PCC_SCALAR_MULT_X25519, \
+    S390_FEAT_PCC_SCALAR_MULT_X448

ERROR: code indent should never use tabs
#188: FILE: target/s390x/gen-features.c:217:
+    S390_FEAT_MSA_EXT_9,^I\$

ERROR: Macros with complex values should be enclosed in parenthesis
#212: FILE: target/s390x/gen-features.c:241:
+#define S390_FEAT_GROUP_MSA_EXT_9_PCKMO \
+    S390_FEAT_PCKMO_ECC_P256, \
+    S390_FEAT_PCKMO_ECC_P384, \
+    S390_FEAT_PCKMO_ECC_P521, \
+    S390_FEAT_PCKMO_ECC_ED25519, \
+    S390_FEAT_PCKMO_ECC_ED448

total: 22 errors, 16 warnings, 215 lines checked

Patch 4/10 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

5/10 Checking commit 59717937a65d (s390x/cpumodel: vector enhancements)
WARNING: line over 80 characters
#20: FILE: target/s390x/cpu_features.c:111:
+    FEAT_INIT("vxeh2", S390_FEAT_TYPE_STFL, 148, "Vector Enhancements facility 2"),

WARNING: line over 80 characters
#21: FILE: target/s390x/cpu_features.c:112:
+    FEAT_INIT("vxbeh", S390_FEAT_TYPE_STFL, 152, "Vector BCD enhancements facility 1"),

total: 0 errors, 2 warnings, 16 lines checked

Patch 5/10 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
6/10 Checking commit d77001b8807f (s390x/cpumodel: enhanced sort facility)
ERROR: line over 90 characters
#20: FILE: target/s390x/cpu_features.c:112:
+    FEAT_INIT("esort-base", S390_FEAT_TYPE_STFL, 150, "Enhanced-sort facility (excluding subfunctions)"),

WARNING: line over 80 characters
#33: FILE: target/s390x/cpu_features.c:349:
+    FEAT_INIT("sortl-f0", S390_FEAT_TYPE_SORTL, 192, "SORTL format 0 parameter-block"),

ERROR: Macros with complex values should be enclosed in parenthesis
#107: FILE: target/s390x/gen-features.c:248:
+#define S390_FEAT_GROUP_ENH_SORT \
+    S390_FEAT_ESORT_BASE, \
+    S390_FEAT_SORTL_SFLR, \
+    S390_FEAT_SORTL_SVLR, \
+    S390_FEAT_SORTL_32, \
+    S390_FEAT_SORTL_128, \
+    S390_FEAT_SORTL_F0

total: 2 errors, 1 warnings, 117 lines checked

Patch 6/10 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

7/10 Checking commit 9ad6b308af81 (s390x/cpumodel: deflate)
ERROR: line over 90 characters
#20: FILE: target/s390x/cpu_features.c:113:
+    FEAT_INIT("deflate-base", S390_FEAT_TYPE_STFL, 151, "Deflate-conversion facility (excluding subfunctions)"),

WARNING: line over 80 characters
#32: FILE: target/s390x/cpu_features.c:355:
+    FEAT_INIT("dfltcc-f0", S390_FEAT_TYPE_DFLTCC, 192, "DFLTCC format 0 parameter-block"),

WARNING: line over 80 characters
#56: FILE: target/s390x/cpu_features.c:522:
+    FEAT_GROUP_INIT("deflate", DEFLATE_CONVERSION, "Deflate-conversion facility"),

ERROR: Macros with complex values should be enclosed in parenthesis
#105: FILE: target/s390x/gen-features.c:257:
+#define S390_FEAT_GROUP_DEFLATE_CONVERSION \
+    S390_FEAT_DEFLATE_BASE, \
+    S390_FEAT_DEFLATE_GHDT, \
+    S390_FEAT_DEFLATE_CMPR, \
+    S390_FEAT_DEFLATE_XPND, \
+    S390_FEAT_DEFLATE_F0

total: 2 errors, 2 warnings, 113 lines checked

Patch 7/10 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

8/10 Checking commit 544a8a6ed245 (s390x/cpumodel: add gen15 defintions)
9/10 Checking commit 76c71e310434 (s390x/cpumodel: wire up 8561 and 8562 as gen15 machines)
10/10 Checking commit c4c9ad736e1a (s390x/cpumodel: do not claim csske for expanded models in qmp)
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/20190418113110.160664-1-borntraeger@de.ibm.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-devel@redhat.com

Re: [Qemu-devel] [PATCH 00/10] s390x: new guest features

[no-reply]

Patchew URL: https://patchew.org/QEMU/20190418113110.160664-1-borntraeger@de.ibm.com/



Hi,

This series seems to have some coding style problems. See output below for
more information:

Message-id: 20190418113110.160664-1-borntraeger@de.ibm.com
Type: series
Subject: [Qemu-devel] [PATCH 00/10]  s390x: new guest features

=== TEST SCRIPT BEGIN ===
#!/bin/bash
git rev-parse base > /dev/null || exit 0
git config --local diff.renamelimit 0
git config --local diff.renames True
git config --local diff.algorithm histogram
./scripts/checkpatch.pl --mailback base..
=== TEST SCRIPT END ===

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
 * [new tag]         patchew/1555587766-985-1-git-send-email-mateja.marjanovic@rt-rk.com -> patchew/1555587766-985-1-git-send-email-mateja.marjanovic@rt-rk.com
 * [new tag]         patchew/20190418113110.160664-1-borntraeger@de.ibm.com -> patchew/20190418113110.160664-1-borntraeger@de.ibm.com
Switched to a new branch 'test'
c4c9ad7 s390x/cpumodel: do not claim csske for expanded models in qmp
76c71e3 s390x/cpumodel: wire up 8561 and 8562 as gen15 machines
544a8a6 s390x/cpumodel: add gen15 defintions
9ad6b30 s390x/cpumodel: deflate
d77001b s390x/cpumodel: enhanced sort facility
5971793 s390x/cpumodel: vector enhancements
f5fadd1 s390x/cpumodel: msa9 facility
06fb20b s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3
54ab59d s390x/cpumodel: remove CSSKE from base model
60aaa57 linux header sync

=== OUTPUT BEGIN ===
1/10 Checking commit 60aaa5790659 (linux header sync)
2/10 Checking commit 54ab59dbdbd8 (s390x/cpumodel: remove CSSKE from base model)
WARNING: line over 80 characters
#55: FILE: target/s390x/cpu_models.c:113:
+        set_bit(S390_FEAT_CONDITIONAL_SSKE, (unsigned long *)&def->default_feat);

total: 0 errors, 1 warnings, 49 lines checked

Patch 2/10 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
3/10 Checking commit 06fb20b97263 (s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3)
ERROR: line over 90 characters
#21: FILE: target/s390x/cpu_features.c:86:
+    FEAT_INIT("minste3", S390_FEAT_TYPE_STFL, 61, "Miscellaneous-Instruction-Extensions Facility 3"),

total: 1 errors, 0 warnings, 14 lines checked

Patch 3/10 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

4/10 Checking commit f5fadd1a9543 (s390x/cpumodel: msa9 facility)
ERROR: line over 90 characters
#22: FILE: target/s390x/cpu_features.c:111:
+    FEAT_INIT("msa9-base", S390_FEAT_TYPE_STFL, 155, "Message-security-assist-extension-9 facility (excluding subfunctions)"),

WARNING: line over 80 characters
#30: FILE: target/s390x/cpu_features.c:246:
+    FEAT_INIT("pckmo-ecc-p256", S390_FEAT_TYPE_PCKMO,32, "PCKMO Encrypt-ECC-P256-Key"),

ERROR: space required after that ',' (ctx:VxV)
#30: FILE: target/s390x/cpu_features.c:246:
+    FEAT_INIT("pckmo-ecc-p256", S390_FEAT_TYPE_PCKMO,32, "PCKMO Encrypt-ECC-P256-Key"),
                                                     ^

WARNING: line over 80 characters
#31: FILE: target/s390x/cpu_features.c:247:
+    FEAT_INIT("pckmo-ecc-p384", S390_FEAT_TYPE_PCKMO,33, "PCKMO Encrypt-ECC-P384-Key"),

ERROR: space required after that ',' (ctx:VxV)
#31: FILE: target/s390x/cpu_features.c:247:
+    FEAT_INIT("pckmo-ecc-p384", S390_FEAT_TYPE_PCKMO,33, "PCKMO Encrypt-ECC-P384-Key"),
                                                     ^

WARNING: line over 80 characters
#32: FILE: target/s390x/cpu_features.c:248:
+    FEAT_INIT("pckmo-ecc-p521", S390_FEAT_TYPE_PCKMO,34, "PCKMO Encrypt-ECC-P521-Key"),

ERROR: space required after that ',' (ctx:VxV)
#32: FILE: target/s390x/cpu_features.c:248:
+    FEAT_INIT("pckmo-ecc-p521", S390_FEAT_TYPE_PCKMO,34, "PCKMO Encrypt-ECC-P521-Key"),
                                                     ^

ERROR: line over 90 characters
#33: FILE: target/s390x/cpu_features.c:249:
+    FEAT_INIT("pckmo-ecc-ed25519", S390_FEAT_TYPE_PCKMO,40 , "PCKMO Encrypt-ECC-Ed25519-Key"),

ERROR: space required after that ',' (ctx:VxV)
#33: FILE: target/s390x/cpu_features.c:249:
+    FEAT_INIT("pckmo-ecc-ed25519", S390_FEAT_TYPE_PCKMO,40 , "PCKMO Encrypt-ECC-Ed25519-Key"),
                                                        ^

WARNING: line over 80 characters
#34: FILE: target/s390x/cpu_features.c:250:
+    FEAT_INIT("pckmo-ecc-ed448", S390_FEAT_TYPE_PCKMO,41 , "PCKMO Encrypt-ECC-Ed448-Key"),

ERROR: space required after that ',' (ctx:VxV)
#34: FILE: target/s390x/cpu_features.c:250:
+    FEAT_INIT("pckmo-ecc-ed448", S390_FEAT_TYPE_PCKMO,41 , "PCKMO Encrypt-ECC-Ed448-Key"),
                                                      ^

WARNING: line over 80 characters
#42: FILE: target/s390x/cpu_features.c:307:
+    FEAT_INIT("pcc-scalar-mult-p256", S390_FEAT_TYPE_PCC, 64, "PCC Scalar-Multiply-P256"),

WARNING: line over 80 characters
#43: FILE: target/s390x/cpu_features.c:308:
+    FEAT_INIT("pcc-scalar-mult-p384", S390_FEAT_TYPE_PCC, 65, "PCC Scalar-Multiply-P384"),

WARNING: line over 80 characters
#44: FILE: target/s390x/cpu_features.c:309:
+    FEAT_INIT("pcc-scalar-mult-p521", S390_FEAT_TYPE_PCC, 66, "PCC Scalar-Multiply-P521"),

ERROR: line over 90 characters
#45: FILE: target/s390x/cpu_features.c:310:
+    FEAT_INIT("pcc-scalar-mult-ed25519", S390_FEAT_TYPE_PCC, 72, "PCC Scalar-Multiply-Ed25519"),

ERROR: line over 90 characters
#46: FILE: target/s390x/cpu_features.c:311:
+    FEAT_INIT("pcc-scalar-mult-ed448", S390_FEAT_TYPE_PCC, 73, "PCC Scalar-Multiply-Ed448"),

ERROR: line over 90 characters
#47: FILE: target/s390x/cpu_features.c:312:
+    FEAT_INIT("pcc-scalar-mult-x25519", S390_FEAT_TYPE_PCC, 80, "PCC Scalar-Multiply-X25519"),

WARNING: line over 80 characters
#48: FILE: target/s390x/cpu_features.c:313:
+    FEAT_INIT("pcc-scalar-mult-x448", S390_FEAT_TYPE_PCC, 81, "PCC Scalar-Multiply-X448"),

WARNING: line over 80 characters
#57: FILE: target/s390x/cpu_features.c:326:
+    FEAT_INIT("kdsa-ecdsa-verify-p256", S390_FEAT_TYPE_KDSA, 1, "KDSA ECDSA-Verify-P256"),

WARNING: line over 80 characters
#58: FILE: target/s390x/cpu_features.c:327:
+    FEAT_INIT("kdsa-ecdsa-verify-p384", S390_FEAT_TYPE_KDSA, 2, "KDSA ECDSA-Verify-P384"),

WARNING: line over 80 characters
#59: FILE: target/s390x/cpu_features.c:328:
+    FEAT_INIT("kdsa-ecdsa-verify-p521", S390_FEAT_TYPE_KDSA, 3, "KDSA ECDSA-Verify-P521"),

WARNING: line over 80 characters
#60: FILE: target/s390x/cpu_features.c:329:
+    FEAT_INIT("kdsa-ecdsa-sign-p256", S390_FEAT_TYPE_KDSA, 9, "KDSA ECDSA-Sign-P256"),

WARNING: line over 80 characters
#61: FILE: target/s390x/cpu_features.c:330:
+    FEAT_INIT("kdsa-ecdsa-sign-p384", S390_FEAT_TYPE_KDSA, 10, "KDSA ECDSA-Sign-P384"),

WARNING: line over 80 characters
#62: FILE: target/s390x/cpu_features.c:331:
+    FEAT_INIT("kdsa-ecdsa-sign-p521", S390_FEAT_TYPE_KDSA, 11, "KDSA ECDSA-Sign-P521"),

ERROR: line over 90 characters
#63: FILE: target/s390x/cpu_features.c:332:
+    FEAT_INIT("kdsa-eecdsa-sign-p256", S390_FEAT_TYPE_KDSA, 17, "KDSA Encrypted-ECDSA-Sign-P256"),

ERROR: line over 90 characters
#64: FILE: target/s390x/cpu_features.c:333:
+    FEAT_INIT("kdsa-eecdsa-sign-p384", S390_FEAT_TYPE_KDSA, 18, "KDSA Encrypted-ECDSA-Sign-P384"),

ERROR: line over 90 characters
#65: FILE: target/s390x/cpu_features.c:334:
+    FEAT_INIT("kdsa-eecdsa-sign-p521", S390_FEAT_TYPE_KDSA, 19, "KDSA Encrypted-ECDSA-Sign-P521"),

ERROR: line over 90 characters
#66: FILE: target/s390x/cpu_features.c:335:
+    FEAT_INIT("kdsa-eddsa-verify-ed25519", S390_FEAT_TYPE_KDSA, 32, "KDSA EdDSA-Verify-Ed25519"),

ERROR: line over 90 characters
#67: FILE: target/s390x/cpu_features.c:336:
+    FEAT_INIT("kdsa-eddsa-verify-ed448", S390_FEAT_TYPE_KDSA, 36, "KDSA EdDSA-Verify-Ed448"),

ERROR: line over 90 characters
#68: FILE: target/s390x/cpu_features.c:337:
+    FEAT_INIT("kdsa-eddsa-sign-ed25519", S390_FEAT_TYPE_KDSA, 40, "KDSA EdDSA-Sign-Ed25519"),

WARNING: line over 80 characters
#69: FILE: target/s390x/cpu_features.c:338:
+    FEAT_INIT("kdsa-eddsa-sign-ed448", S390_FEAT_TYPE_KDSA, 44, "KDSA EdDSA-Sign-Ed448"),

ERROR: line over 90 characters
#70: FILE: target/s390x/cpu_features.c:339:
+    FEAT_INIT("kdsa-eeddsa-sign-ed25519", S390_FEAT_TYPE_KDSA, 48, "KDSA Encrypted-EdDSA-Sign-Ed25519"),

ERROR: line over 90 characters
#71: FILE: target/s390x/cpu_features.c:340:
+    FEAT_INIT("kdsa-eeddsa-sign-ed448", S390_FEAT_TYPE_KDSA, 52, "KDSA Encrypted-EdDSA-Sign-Ed448"),

WARNING: line over 80 characters
#87: FILE: target/s390x/cpu_features.c:499:
+    FEAT_GROUP_INIT("msa9", MSA_EXT_9, "Message-security-assist-extension 9 facility"),

ERROR: line over 90 characters
#88: FILE: target/s390x/cpu_features.c:500:
+    FEAT_GROUP_INIT("msa9_pckmo", MSA_EXT_9_PCKMO, "Message-security-assist-extension 9 PCKMO subfunctions"),

ERROR: Macros with complex values should be enclosed in parenthesis
#187: FILE: target/s390x/gen-features.c:216:
+#define S390_FEAT_GROUP_MSA_EXT_9 \
+    S390_FEAT_MSA_EXT_9,       \
+    S390_FEAT_ECDSA_VERIFY_P256, \
+    S390_FEAT_ECDSA_VERIFY_P384, \
+    S390_FEAT_ECDSA_VERIFY_P512, \
+    S390_FEAT_ECDSA_SIGN_P256, \
+    S390_FEAT_ECDSA_SIGN_P384, \
+    S390_FEAT_ECDSA_SIGN_P512, \
+    S390_FEAT_EECDSA_SIGN_P256, \
+    S390_FEAT_EECDSA_SIGN_P384, \
+    S390_FEAT_EECDSA_SIGN_P512, \
+    S390_FEAT_EDDSA_VERIFY_ED25519, \
+    S390_FEAT_EDDSA_VERIFY_ED448, \
+    S390_FEAT_EDDSA_SIGN_ED25519, \
+    S390_FEAT_EDDSA_SIGN_ED448, \
+    S390_FEAT_EEDDSA_SIGN_ED25519, \
+    S390_FEAT_EEDDSA_SIGN_ED448, \
+    S390_FEAT_PCC_SCALAR_MULT_P256, \
+    S390_FEAT_PCC_SCALAR_MULT_P384, \
+    S390_FEAT_PCC_SCALAR_MULT_P512, \
+    S390_FEAT_PCC_SCALAR_MULT_ED25519, \
+    S390_FEAT_PCC_SCALAR_MULT_ED448, \
+    S390_FEAT_PCC_SCALAR_MULT_X25519, \
+    S390_FEAT_PCC_SCALAR_MULT_X448

ERROR: code indent should never use tabs
#188: FILE: target/s390x/gen-features.c:217:
+    S390_FEAT_MSA_EXT_9,^I\$

ERROR: Macros with complex values should be enclosed in parenthesis
#212: FILE: target/s390x/gen-features.c:241:
+#define S390_FEAT_GROUP_MSA_EXT_9_PCKMO \
+    S390_FEAT_PCKMO_ECC_P256, \
+    S390_FEAT_PCKMO_ECC_P384, \
+    S390_FEAT_PCKMO_ECC_P521, \
+    S390_FEAT_PCKMO_ECC_ED25519, \
+    S390_FEAT_PCKMO_ECC_ED448

total: 22 errors, 16 warnings, 215 lines checked

Patch 4/10 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

5/10 Checking commit 59717937a65d (s390x/cpumodel: vector enhancements)
WARNING: line over 80 characters
#20: FILE: target/s390x/cpu_features.c:111:
+    FEAT_INIT("vxeh2", S390_FEAT_TYPE_STFL, 148, "Vector Enhancements facility 2"),

WARNING: line over 80 characters
#21: FILE: target/s390x/cpu_features.c:112:
+    FEAT_INIT("vxbeh", S390_FEAT_TYPE_STFL, 152, "Vector BCD enhancements facility 1"),

total: 0 errors, 2 warnings, 16 lines checked

Patch 5/10 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
6/10 Checking commit d77001b8807f (s390x/cpumodel: enhanced sort facility)
ERROR: line over 90 characters
#20: FILE: target/s390x/cpu_features.c:112:
+    FEAT_INIT("esort-base", S390_FEAT_TYPE_STFL, 150, "Enhanced-sort facility (excluding subfunctions)"),

WARNING: line over 80 characters
#33: FILE: target/s390x/cpu_features.c:349:
+    FEAT_INIT("sortl-f0", S390_FEAT_TYPE_SORTL, 192, "SORTL format 0 parameter-block"),

ERROR: Macros with complex values should be enclosed in parenthesis
#107: FILE: target/s390x/gen-features.c:248:
+#define S390_FEAT_GROUP_ENH_SORT \
+    S390_FEAT_ESORT_BASE, \
+    S390_FEAT_SORTL_SFLR, \
+    S390_FEAT_SORTL_SVLR, \
+    S390_FEAT_SORTL_32, \
+    S390_FEAT_SORTL_128, \
+    S390_FEAT_SORTL_F0

total: 2 errors, 1 warnings, 117 lines checked

Patch 6/10 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

7/10 Checking commit 9ad6b308af81 (s390x/cpumodel: deflate)
ERROR: line over 90 characters
#20: FILE: target/s390x/cpu_features.c:113:
+    FEAT_INIT("deflate-base", S390_FEAT_TYPE_STFL, 151, "Deflate-conversion facility (excluding subfunctions)"),

WARNING: line over 80 characters
#32: FILE: target/s390x/cpu_features.c:355:
+    FEAT_INIT("dfltcc-f0", S390_FEAT_TYPE_DFLTCC, 192, "DFLTCC format 0 parameter-block"),

WARNING: line over 80 characters
#56: FILE: target/s390x/cpu_features.c:522:
+    FEAT_GROUP_INIT("deflate", DEFLATE_CONVERSION, "Deflate-conversion facility"),

ERROR: Macros with complex values should be enclosed in parenthesis
#105: FILE: target/s390x/gen-features.c:257:
+#define S390_FEAT_GROUP_DEFLATE_CONVERSION \
+    S390_FEAT_DEFLATE_BASE, \
+    S390_FEAT_DEFLATE_GHDT, \
+    S390_FEAT_DEFLATE_CMPR, \
+    S390_FEAT_DEFLATE_XPND, \
+    S390_FEAT_DEFLATE_F0

total: 2 errors, 2 warnings, 113 lines checked

Patch 7/10 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.

8/10 Checking commit 544a8a6ed245 (s390x/cpumodel: add gen15 defintions)
9/10 Checking commit 76c71e310434 (s390x/cpumodel: wire up 8561 and 8562 as gen15 machines)
10/10 Checking commit c4c9ad736e1a (s390x/cpumodel: do not claim csske for expanded models in qmp)
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/20190418113110.160664-1-borntraeger@de.ibm.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-devel@redhat.com

Re: [Qemu-devel] [PATCH 02/10] s390x/cpumodel: remove CSSKE from base model

[David Hildenbrand]

On 18.04.19 13:31, Christian Borntraeger wrote:
> conditional sske is deprecated and a distant future machine (will be one
> where the IBC will not allow to fully go back to z14) will remove this
> feature. To prepare for this and allow for the z14 and older cpu model
> to still run on systems without csske, remove csske from the base (and

will csske feature be a default feature for zNext? Or is it not
available *at all*.

In case it is not available, baselining and cpu model comparison have to
be thought about "ignoring csske".

> thus the default models for z10..z14). For compat machines we have to
> add those back.

Base models are machine-independent. That means, changing base models is
not supported. Once we introduce new models like here, we can set the
new base models into stone.

> 
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
>  hw/s390x/s390-virtio-ccw.c  |  2 ++
>  target/s390x/cpu_models.c   | 21 +++++++++++++++++++++
>  target/s390x/cpu_models.h   |  1 +
>  target/s390x/gen-features.c |  1 -
>  4 files changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
> index d11069b860..3415948b2c 100644
> --- a/hw/s390x/s390-virtio-ccw.c
> +++ b/hw/s390x/s390-virtio-ccw.c
> @@ -648,6 +648,8 @@ bool css_migration_enabled(void)
>  
>  static void ccw_machine_4_0_instance_options(MachineState *machine)
>  {
> +    /* re-enable csske for compat machines in the base model */
> +    s390_cpumodel_fixup_csske();
>  }
>  
>  static void ccw_machine_4_0_class_options(MachineClass *mc)
> diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
> index eb125d4d0d..4e5aa879f3 100644
> --- a/target/s390x/cpu_models.c
> +++ b/target/s390x/cpu_models.c
> @@ -93,6 +93,27 @@ static S390FeatBitmap qemu_max_cpu_feat;
>  /* features part of a base model but not relevant for finding a base model */
>  S390FeatBitmap ignored_base_feat;
>  
> +/*
> + * We removed CSSKE from the base features. This is a hook for compat machines
> + * to put this back for gen10..gen14. As the base model is also part of the
> + * default model to have to fixup both bitfields
> + */
> +void s390_cpumodel_fixup_csske(void)
> +{
> +    int i;
> +
> +    for (i = 0; i < ARRAY_SIZE(s390_cpu_defs); i++) {
> +        const S390CPUDef *def = &s390_cpu_defs[i];
> +
> +        if (def->gen < 10 || def->gen > 14) {
> +            continue;
> +        }
> +
> +        set_bit(S390_FEAT_CONDITIONAL_SSKE, (unsigned long *)&def->base_feat);
> +        set_bit(S390_FEAT_CONDITIONAL_SSKE, (unsigned long *)&def->default_feat);
> +    }
> +}

I think that can be avoided by smarter generation of the models, which I
would prefer.

> +
>  void s390_cpudef_featoff(uint8_t gen, uint8_t ec_ga, S390Feat feat)
>  {
>      const S390CPUDef *def;
> diff --git a/target/s390x/cpu_models.h b/target/s390x/cpu_models.h
> index 174a99e561..b2e37bc8cf 100644
> --- a/target/s390x/cpu_models.h
> +++ b/target/s390x/cpu_models.h
> @@ -73,6 +73,7 @@ struct S390CPUModel {
>  #define ibc_gen(x)        (x == 0 ? 0 : ((x >> 4) + S390_GEN_Z10))
>  #define ibc_ec_ga(x)      (x & 0xf)
>  
> +void s390_cpumodel_fixup_csske(void);
>  void s390_cpudef_featoff(uint8_t gen, uint8_t ec_ga, S390Feat feat);
>  void s390_cpudef_featoff_greater(uint8_t gen, uint8_t ec_ga, S390Feat feat);
>  void s390_cpudef_group_featoff_greater(uint8_t gen, uint8_t ec_ga,
> diff --git a/target/s390x/gen-features.c b/target/s390x/gen-features.c
> index e4739a6b9f..bea2f80c49 100644
> --- a/target/s390x/gen-features.c
> +++ b/target/s390x/gen-features.c
> @@ -301,7 +301,6 @@ static uint16_t base_GEN9_GA1[] = {
>  #define base_GEN9_GA3 EmptyFeat
>  
>  static uint16_t base_GEN10_GA1[] = {
> -    S390_FEAT_CONDITIONAL_SSKE,
>      S390_FEAT_PARSING_ENH,
>      S390_FEAT_MOVE_WITH_OPTIONAL_SPEC,
>      S390_FEAT_EXTRACT_CPU_TIME,
> 

Instead of doing that, can we rather start generating the next
generation "fresh", listing all base model features it contains instead
of doing it incrementally? Could end up "nicer"


In target/s390x/cpu_models.c we have:

"... For now, base features of a following release are always a subset
of base features of the previous release. Same is correct for the other
feature sets."

This is especially relevant for "s390_find_cpu_def", and goes into the
direction of baselining, as previously mentioned.

Luckily, we already have "ignored_base_feat", maybe we can simply add
csske there and have it working.

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH 02/10] s390x/cpumodel: remove CSSKE from base model

[David Hildenbrand]

On 18.04.19 13:31, Christian Borntraeger wrote:
> conditional sske is deprecated and a distant future machine (will be one
> where the IBC will not allow to fully go back to z14) will remove this
> feature. To prepare for this and allow for the z14 and older cpu model
> to still run on systems without csske, remove csske from the base (and

will csske feature be a default feature for zNext? Or is it not
available *at all*.

In case it is not available, baselining and cpu model comparison have to
be thought about "ignoring csske".

> thus the default models for z10..z14). For compat machines we have to
> add those back.

Base models are machine-independent. That means, changing base models is
not supported. Once we introduce new models like here, we can set the
new base models into stone.

> 
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
>  hw/s390x/s390-virtio-ccw.c  |  2 ++
>  target/s390x/cpu_models.c   | 21 +++++++++++++++++++++
>  target/s390x/cpu_models.h   |  1 +
>  target/s390x/gen-features.c |  1 -
>  4 files changed, 24 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
> index d11069b860..3415948b2c 100644
> --- a/hw/s390x/s390-virtio-ccw.c
> +++ b/hw/s390x/s390-virtio-ccw.c
> @@ -648,6 +648,8 @@ bool css_migration_enabled(void)
>  
>  static void ccw_machine_4_0_instance_options(MachineState *machine)
>  {
> +    /* re-enable csske for compat machines in the base model */
> +    s390_cpumodel_fixup_csske();
>  }
>  
>  static void ccw_machine_4_0_class_options(MachineClass *mc)
> diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
> index eb125d4d0d..4e5aa879f3 100644
> --- a/target/s390x/cpu_models.c
> +++ b/target/s390x/cpu_models.c
> @@ -93,6 +93,27 @@ static S390FeatBitmap qemu_max_cpu_feat;
>  /* features part of a base model but not relevant for finding a base model */
>  S390FeatBitmap ignored_base_feat;
>  
> +/*
> + * We removed CSSKE from the base features. This is a hook for compat machines
> + * to put this back for gen10..gen14. As the base model is also part of the
> + * default model to have to fixup both bitfields
> + */
> +void s390_cpumodel_fixup_csske(void)
> +{
> +    int i;
> +
> +    for (i = 0; i < ARRAY_SIZE(s390_cpu_defs); i++) {
> +        const S390CPUDef *def = &s390_cpu_defs[i];
> +
> +        if (def->gen < 10 || def->gen > 14) {
> +            continue;
> +        }
> +
> +        set_bit(S390_FEAT_CONDITIONAL_SSKE, (unsigned long *)&def->base_feat);
> +        set_bit(S390_FEAT_CONDITIONAL_SSKE, (unsigned long *)&def->default_feat);
> +    }
> +}

I think that can be avoided by smarter generation of the models, which I
would prefer.

> +
>  void s390_cpudef_featoff(uint8_t gen, uint8_t ec_ga, S390Feat feat)
>  {
>      const S390CPUDef *def;
> diff --git a/target/s390x/cpu_models.h b/target/s390x/cpu_models.h
> index 174a99e561..b2e37bc8cf 100644
> --- a/target/s390x/cpu_models.h
> +++ b/target/s390x/cpu_models.h
> @@ -73,6 +73,7 @@ struct S390CPUModel {
>  #define ibc_gen(x)        (x == 0 ? 0 : ((x >> 4) + S390_GEN_Z10))
>  #define ibc_ec_ga(x)      (x & 0xf)
>  
> +void s390_cpumodel_fixup_csske(void);
>  void s390_cpudef_featoff(uint8_t gen, uint8_t ec_ga, S390Feat feat);
>  void s390_cpudef_featoff_greater(uint8_t gen, uint8_t ec_ga, S390Feat feat);
>  void s390_cpudef_group_featoff_greater(uint8_t gen, uint8_t ec_ga,
> diff --git a/target/s390x/gen-features.c b/target/s390x/gen-features.c
> index e4739a6b9f..bea2f80c49 100644
> --- a/target/s390x/gen-features.c
> +++ b/target/s390x/gen-features.c
> @@ -301,7 +301,6 @@ static uint16_t base_GEN9_GA1[] = {
>  #define base_GEN9_GA3 EmptyFeat
>  
>  static uint16_t base_GEN10_GA1[] = {
> -    S390_FEAT_CONDITIONAL_SSKE,
>      S390_FEAT_PARSING_ENH,
>      S390_FEAT_MOVE_WITH_OPTIONAL_SPEC,
>      S390_FEAT_EXTRACT_CPU_TIME,
> 

Instead of doing that, can we rather start generating the next
generation "fresh", listing all base model features it contains instead
of doing it incrementally? Could end up "nicer"


In target/s390x/cpu_models.c we have:

"... For now, base features of a following release are always a subset
of base features of the previous release. Same is correct for the other
feature sets."

This is especially relevant for "s390_find_cpu_def", and goes into the
direction of baselining, as previously mentioned.

Luckily, we already have "ignored_base_feat", maybe we can simply add
csske there and have it working.

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH 10/10] s390x/cpumodel: do not claim csske for expanded models in qmp

[David Hildenbrand]

On 18.04.19 13:31, Christian Borntraeger wrote:
> While we have removed csske and bpb from the default model, the very
> common case of "host-model" in libvirt (expanded to a base model
> + features) would still contain bpb and csske. This can prevent
> migration to a future machine for a host-model machine. Let us fence
> bpb and csske when we run on a generation 15. If necessary the
> user can still use -cpu 8561,csske=on,bpb=on to force enable these
> features.
> 
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
>  target/s390x/cpu_models.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
> index e727519686..03bdca1fb8 100644
> --- a/target/s390x/cpu_models.c
> +++ b/target/s390x/cpu_models.c
> @@ -629,6 +629,17 @@ CpuModelExpansionInfo *qmp_query_cpu_model_expansion(CpuModelExpansionType type,
>          return NULL;
>      }
>  
> +    /*
> +     * Do not claim CSSKE and BPB if the host model expands to
> +     * generation 15 or newer
> +     */
> +    if (s390_model.def->gen >= 15) {
> +        clear_bit(S390_FEAT_CONDITIONAL_SSKE,
> +                  (unsigned long *) &s390_model.features);
> +        clear_bit(S390_FEAT_BPB,
> +                  (unsigned long *) &s390_model.features);
> +    }
> +
>      if (type == CPU_MODEL_EXPANSION_TYPE_STATIC) {
>          delta_changes = true;
>      } else if (type != CPU_MODEL_EXPANSION_TYPE_FULL) {
> 

The bad thing about it is, it hinders migration *to* this hw generation.
Will have to think about this some more. As alternative, simply ignore
S390_FEAT_CONDITIONAL_SSKE and S390_FEAT_BPB when baselining/comparing.

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH 10/10] s390x/cpumodel: do not claim csske for expanded models in qmp

[David Hildenbrand]

On 18.04.19 13:31, Christian Borntraeger wrote:
> While we have removed csske and bpb from the default model, the very
> common case of "host-model" in libvirt (expanded to a base model
> + features) would still contain bpb and csske. This can prevent
> migration to a future machine for a host-model machine. Let us fence
> bpb and csske when we run on a generation 15. If necessary the
> user can still use -cpu 8561,csske=on,bpb=on to force enable these
> features.
> 
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
>  target/s390x/cpu_models.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
> index e727519686..03bdca1fb8 100644
> --- a/target/s390x/cpu_models.c
> +++ b/target/s390x/cpu_models.c
> @@ -629,6 +629,17 @@ CpuModelExpansionInfo *qmp_query_cpu_model_expansion(CpuModelExpansionType type,
>          return NULL;
>      }
>  
> +    /*
> +     * Do not claim CSSKE and BPB if the host model expands to
> +     * generation 15 or newer
> +     */
> +    if (s390_model.def->gen >= 15) {
> +        clear_bit(S390_FEAT_CONDITIONAL_SSKE,
> +                  (unsigned long *) &s390_model.features);
> +        clear_bit(S390_FEAT_BPB,
> +                  (unsigned long *) &s390_model.features);
> +    }
> +
>      if (type == CPU_MODEL_EXPANSION_TYPE_STATIC) {
>          delta_changes = true;
>      } else if (type != CPU_MODEL_EXPANSION_TYPE_FULL) {
> 

The bad thing about it is, it hinders migration *to* this hw generation.
Will have to think about this some more. As alternative, simply ignore
S390_FEAT_CONDITIONAL_SSKE and S390_FEAT_BPB when baselining/comparing.

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH 03/10] s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3

[David Hildenbrand]

On 18.04.19 13:31, Christian Borntraeger wrote:
> Provide the "Miscellaneous-Instruction-Extensions Facility 3" via
> stfle.61.
> 
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
>  target/s390x/cpu_features.c     | 1 +
>  target/s390x/cpu_features_def.h | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
> index 1843c84aaa..bbd8902087 100644
> --- a/target/s390x/cpu_features.c
> +++ b/target/s390x/cpu_features.c
> @@ -83,6 +83,7 @@ static const S390FeatDef s390_features[] = {
>      FEAT_INIT("minste2", S390_FEAT_TYPE_STFL, 58, "Miscellaneous-instruction-extensions facility 2"),
>      FEAT_INIT("sema", S390_FEAT_TYPE_STFL, 59, "Semaphore-assist facility"),
>      FEAT_INIT("tsi", S390_FEAT_TYPE_STFL, 60, "Time-slice Instrumentation facility"),
> +    FEAT_INIT("minste3", S390_FEAT_TYPE_STFL, 61, "Miscellaneous-Instruction-Extensions Facility 3"),
>      FEAT_INIT("ri", S390_FEAT_TYPE_STFL, 64, "CPU runtime-instrumentation facility"),
>      FEAT_INIT("zpci", S390_FEAT_TYPE_STFL, 69, "z/PCI facility"),
>      FEAT_INIT("aen", S390_FEAT_TYPE_STFL, 71, "General-purpose-adapter-event-notification facility"),
> diff --git a/target/s390x/cpu_features_def.h b/target/s390x/cpu_features_def.h
> index 5fc7e7bf01..31dd678301 100644
> --- a/target/s390x/cpu_features_def.h
> +++ b/target/s390x/cpu_features_def.h
> @@ -71,6 +71,7 @@ typedef enum {
>      S390_FEAT_MISC_INSTRUCTION_EXT,
>      S390_FEAT_SEMAPHORE_ASSIST,
>      S390_FEAT_TIME_SLICE_INSTRUMENTATION,
> +    S390_FEAT_MISC_INSTRUCTION_EXT3,
>      S390_FEAT_RUNTIME_INSTRUMENTATION,
>      S390_FEAT_ZPCI,
>      S390_FEAT_ADAPTER_EVENT_NOTIFICATION,
> 

Reviewed-by: David Hildenbrand <david@redhat.com>

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH 03/10] s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3

[David Hildenbrand]

On 18.04.19 13:31, Christian Borntraeger wrote:
> Provide the "Miscellaneous-Instruction-Extensions Facility 3" via
> stfle.61.
> 
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
>  target/s390x/cpu_features.c     | 1 +
>  target/s390x/cpu_features_def.h | 1 +
>  2 files changed, 2 insertions(+)
> 
> diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
> index 1843c84aaa..bbd8902087 100644
> --- a/target/s390x/cpu_features.c
> +++ b/target/s390x/cpu_features.c
> @@ -83,6 +83,7 @@ static const S390FeatDef s390_features[] = {
>      FEAT_INIT("minste2", S390_FEAT_TYPE_STFL, 58, "Miscellaneous-instruction-extensions facility 2"),
>      FEAT_INIT("sema", S390_FEAT_TYPE_STFL, 59, "Semaphore-assist facility"),
>      FEAT_INIT("tsi", S390_FEAT_TYPE_STFL, 60, "Time-slice Instrumentation facility"),
> +    FEAT_INIT("minste3", S390_FEAT_TYPE_STFL, 61, "Miscellaneous-Instruction-Extensions Facility 3"),
>      FEAT_INIT("ri", S390_FEAT_TYPE_STFL, 64, "CPU runtime-instrumentation facility"),
>      FEAT_INIT("zpci", S390_FEAT_TYPE_STFL, 69, "z/PCI facility"),
>      FEAT_INIT("aen", S390_FEAT_TYPE_STFL, 71, "General-purpose-adapter-event-notification facility"),
> diff --git a/target/s390x/cpu_features_def.h b/target/s390x/cpu_features_def.h
> index 5fc7e7bf01..31dd678301 100644
> --- a/target/s390x/cpu_features_def.h
> +++ b/target/s390x/cpu_features_def.h
> @@ -71,6 +71,7 @@ typedef enum {
>      S390_FEAT_MISC_INSTRUCTION_EXT,
>      S390_FEAT_SEMAPHORE_ASSIST,
>      S390_FEAT_TIME_SLICE_INSTRUMENTATION,
> +    S390_FEAT_MISC_INSTRUCTION_EXT3,
>      S390_FEAT_RUNTIME_INSTRUMENTATION,
>      S390_FEAT_ZPCI,
>      S390_FEAT_ADAPTER_EVENT_NOTIFICATION,
> 

Reviewed-by: David Hildenbrand <david@redhat.com>

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH 04/10] s390x/cpumodel: msa9 facility

[David Hildenbrand]

On 18.04.19 13:31, Christian Borntraeger wrote:
> Provide the MSA9 facility (stfle.155).  This also contains pckmo
> functions for key wrapping. Keep them in a separate group to allow
> disabling/enabling those as a block if necessary.
> 
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
>  target/s390x/cpu_features.c     | 32 +++++++++++++++++++++++++
>  target/s390x/cpu_features.h     |  1 +
>  target/s390x/cpu_features_def.h | 31 ++++++++++++++++++++++++
>  target/s390x/cpu_models.c       |  1 +
>  target/s390x/gen-features.c     | 42 +++++++++++++++++++++++++++++++++
>  target/s390x/kvm.c              |  6 +++++
>  6 files changed, 113 insertions(+)
> 
> diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
> index bbd8902087..4d624b2256 100644
> --- a/target/s390x/cpu_features.c
> +++ b/target/s390x/cpu_features.c
> @@ -108,6 +108,7 @@ static const S390FeatDef s390_features[] = {
>      FEAT_INIT("irbm", S390_FEAT_TYPE_STFL, 145, "Insert-reference-bits-multiple facility"),
>      FEAT_INIT("msa8-base", S390_FEAT_TYPE_STFL, 146, "Message-security-assist-extension-8 facility (excluding subfunctions)"),
>      FEAT_INIT("cmmnt", S390_FEAT_TYPE_STFL, 147, "CMM: ESSA-enhancement (no translate) facility"),
> +    FEAT_INIT("msa9-base", S390_FEAT_TYPE_STFL, 155, "Message-security-assist-extension-9 facility (excluding subfunctions)"),
>      FEAT_INIT("etoken", S390_FEAT_TYPE_STFL, 156, "Etoken facility"),
>  
>      /* SCLP SCCB Byte 80 - 98  (bit numbers relative to byte-80) */
> @@ -242,6 +243,11 @@ static const S390FeatDef s390_features[] = {
>      FEAT_INIT("pckmo-aes-128", S390_FEAT_TYPE_PCKMO, 18, "PCKMO Encrypted-AES-128-Key"),
>      FEAT_INIT("pckmo-aes-192", S390_FEAT_TYPE_PCKMO, 19, "PCKMO Encrypted-AES-192-Key"),
>      FEAT_INIT("pckmo-aes-256", S390_FEAT_TYPE_PCKMO, 20, "PCKMO Encrypted-AES-256-Key"),
> +    FEAT_INIT("pckmo-ecc-p256", S390_FEAT_TYPE_PCKMO,32, "PCKMO Encrypt-ECC-P256-Key"),
> +    FEAT_INIT("pckmo-ecc-p384", S390_FEAT_TYPE_PCKMO,33, "PCKMO Encrypt-ECC-P384-Key"),
> +    FEAT_INIT("pckmo-ecc-p521", S390_FEAT_TYPE_PCKMO,34, "PCKMO Encrypt-ECC-P521-Key"),
> +    FEAT_INIT("pckmo-ecc-ed25519", S390_FEAT_TYPE_PCKMO,40 , "PCKMO Encrypt-ECC-Ed25519-Key"),
> +    FEAT_INIT("pckmo-ecc-ed448", S390_FEAT_TYPE_PCKMO,41 , "PCKMO Encrypt-ECC-Ed448-Key"),
>  
>      FEAT_INIT("kmctr-dea", S390_FEAT_TYPE_KMCTR, 1, "KMCTR DEA"),
>      FEAT_INIT("kmctr-tdea-128", S390_FEAT_TYPE_KMCTR, 2, "KMCTR TDEA-128"),
> @@ -298,6 +304,13 @@ static const S390FeatDef s390_features[] = {
>      FEAT_INIT("pcc-xts-aes-256", S390_FEAT_TYPE_PCC, 52, "PCC Compute-XTS-Parameter-Using-AES-256"),
>      FEAT_INIT("pcc-xts-eaes-128", S390_FEAT_TYPE_PCC, 58, "PCC Compute-XTS-Parameter-Using-Encrypted-AES-128"),
>      FEAT_INIT("pcc-xts-eaes-256", S390_FEAT_TYPE_PCC, 60, "PCC Compute-XTS-Parameter-Using-Encrypted-AES-256"),
> +    FEAT_INIT("pcc-scalar-mult-p256", S390_FEAT_TYPE_PCC, 64, "PCC Scalar-Multiply-P256"),
> +    FEAT_INIT("pcc-scalar-mult-p384", S390_FEAT_TYPE_PCC, 65, "PCC Scalar-Multiply-P384"),
> +    FEAT_INIT("pcc-scalar-mult-p521", S390_FEAT_TYPE_PCC, 66, "PCC Scalar-Multiply-P521"),
> +    FEAT_INIT("pcc-scalar-mult-ed25519", S390_FEAT_TYPE_PCC, 72, "PCC Scalar-Multiply-Ed25519"),
> +    FEAT_INIT("pcc-scalar-mult-ed448", S390_FEAT_TYPE_PCC, 73, "PCC Scalar-Multiply-Ed448"),
> +    FEAT_INIT("pcc-scalar-mult-x25519", S390_FEAT_TYPE_PCC, 80, "PCC Scalar-Multiply-X25519"),
> +    FEAT_INIT("pcc-scalar-mult-x448", S390_FEAT_TYPE_PCC, 81, "PCC Scalar-Multiply-X448"),
>  
>      FEAT_INIT("ppno-sha-512-drng", S390_FEAT_TYPE_PPNO, 3, "PPNO SHA-512-DRNG"),
>      FEAT_INIT("prno-trng-qrtcr", S390_FEAT_TYPE_PPNO, 112, "PRNO TRNG-Query-Raw-to-Conditioned-Ratio"),
> @@ -309,6 +322,22 @@ static const S390FeatDef s390_features[] = {
>      FEAT_INIT("kma-gcm-eaes-128", S390_FEAT_TYPE_KMA, 26, "KMA GCM-Encrypted-AES-128"),
>      FEAT_INIT("kma-gcm-eaes-192", S390_FEAT_TYPE_KMA, 27, "KMA GCM-Encrypted-AES-192"),
>      FEAT_INIT("kma-gcm-eaes-256", S390_FEAT_TYPE_KMA, 28, "KMA GCM-Encrypted-AES-256"),
> +
> +    FEAT_INIT("kdsa-ecdsa-verify-p256", S390_FEAT_TYPE_KDSA, 1, "KDSA ECDSA-Verify-P256"),
> +    FEAT_INIT("kdsa-ecdsa-verify-p384", S390_FEAT_TYPE_KDSA, 2, "KDSA ECDSA-Verify-P384"),
> +    FEAT_INIT("kdsa-ecdsa-verify-p521", S390_FEAT_TYPE_KDSA, 3, "KDSA ECDSA-Verify-P521"),
> +    FEAT_INIT("kdsa-ecdsa-sign-p256", S390_FEAT_TYPE_KDSA, 9, "KDSA ECDSA-Sign-P256"),
> +    FEAT_INIT("kdsa-ecdsa-sign-p384", S390_FEAT_TYPE_KDSA, 10, "KDSA ECDSA-Sign-P384"),
> +    FEAT_INIT("kdsa-ecdsa-sign-p521", S390_FEAT_TYPE_KDSA, 11, "KDSA ECDSA-Sign-P521"),
> +    FEAT_INIT("kdsa-eecdsa-sign-p256", S390_FEAT_TYPE_KDSA, 17, "KDSA Encrypted-ECDSA-Sign-P256"),
> +    FEAT_INIT("kdsa-eecdsa-sign-p384", S390_FEAT_TYPE_KDSA, 18, "KDSA Encrypted-ECDSA-Sign-P384"),
> +    FEAT_INIT("kdsa-eecdsa-sign-p521", S390_FEAT_TYPE_KDSA, 19, "KDSA Encrypted-ECDSA-Sign-P521"),
> +    FEAT_INIT("kdsa-eddsa-verify-ed25519", S390_FEAT_TYPE_KDSA, 32, "KDSA EdDSA-Verify-Ed25519"),
> +    FEAT_INIT("kdsa-eddsa-verify-ed448", S390_FEAT_TYPE_KDSA, 36, "KDSA EdDSA-Verify-Ed448"),
> +    FEAT_INIT("kdsa-eddsa-sign-ed25519", S390_FEAT_TYPE_KDSA, 40, "KDSA EdDSA-Sign-Ed25519"),
> +    FEAT_INIT("kdsa-eddsa-sign-ed448", S390_FEAT_TYPE_KDSA, 44, "KDSA EdDSA-Sign-Ed448"),
> +    FEAT_INIT("kdsa-eeddsa-sign-ed25519", S390_FEAT_TYPE_KDSA, 48, "KDSA Encrypted-EdDSA-Sign-Ed25519"),
> +    FEAT_INIT("kdsa-eeddsa-sign-ed448", S390_FEAT_TYPE_KDSA, 52, "KDSA Encrypted-EdDSA-Sign-Ed448"),
>  };
>  
>  const S390FeatDef *s390_feat_def(S390Feat feat)
> @@ -371,6 +400,7 @@ void s390_fill_feat_block(const S390FeatBitmap features, S390FeatType type,
>      case S390_FEAT_TYPE_PCC:
>      case S390_FEAT_TYPE_PPNO:
>      case S390_FEAT_TYPE_KMA:
> +    case S390_FEAT_TYPE_KDSA:
>          set_be_bit(0, data); /* query is always available */
>          break;
>      default:
> @@ -466,6 +496,8 @@ static S390FeatGroupDef s390_feature_groups[] = {
>      FEAT_GROUP_INIT("msa6", MSA_EXT_6, "Message-security-assist-extension 6 facility"),
>      FEAT_GROUP_INIT("msa7", MSA_EXT_7, "Message-security-assist-extension 7 facility"),
>      FEAT_GROUP_INIT("msa8", MSA_EXT_8, "Message-security-assist-extension 8 facility"),
> +    FEAT_GROUP_INIT("msa9", MSA_EXT_9, "Message-security-assist-extension 9 facility"),
> +    FEAT_GROUP_INIT("msa9_pckmo", MSA_EXT_9_PCKMO, "Message-security-assist-extension 9 PCKMO subfunctions"),
>      FEAT_GROUP_INIT("mepochptff", MULTIPLE_EPOCH_PTFF, "PTFF enhancements introduced with Multiple-epoch facility"),
>  };
>  
> diff --git a/target/s390x/cpu_features.h b/target/s390x/cpu_features.h
> index effe790271..5ffd3db083 100644
> --- a/target/s390x/cpu_features.h
> +++ b/target/s390x/cpu_features.h
> @@ -39,6 +39,7 @@ typedef enum {
>      S390_FEAT_TYPE_PCC,
>      S390_FEAT_TYPE_PPNO,
>      S390_FEAT_TYPE_KMA,
> +    S390_FEAT_TYPE_KDSA,
>  } S390FeatType;
>  
>  /* Definition of a CPU feature */
> diff --git a/target/s390x/cpu_features_def.h b/target/s390x/cpu_features_def.h
> index 31dd678301..030784811b 100644
> --- a/target/s390x/cpu_features_def.h
> +++ b/target/s390x/cpu_features_def.h
> @@ -96,6 +96,7 @@ typedef enum {
>      S390_FEAT_INSERT_REFERENCE_BITS_MULT,
>      S390_FEAT_MSA_EXT_8,
>      S390_FEAT_CMM_NT,
> +    S390_FEAT_MSA_EXT_9,
>      S390_FEAT_ETOKEN,
>  
>      /* Sclp Conf Char */
> @@ -240,6 +241,11 @@ typedef enum {
>      S390_FEAT_PCKMO_AES_128,
>      S390_FEAT_PCKMO_AES_192,
>      S390_FEAT_PCKMO_AES_256,
> +    S390_FEAT_PCKMO_ECC_P256,
> +    S390_FEAT_PCKMO_ECC_P384,
> +    S390_FEAT_PCKMO_ECC_P521,
> +    S390_FEAT_PCKMO_ECC_ED25519,
> +    S390_FEAT_PCKMO_ECC_ED448,
>  
>      /* KMCTR */
>      S390_FEAT_KMCTR_DEA,
> @@ -300,6 +306,13 @@ typedef enum {
>      S390_FEAT_PCC_XTS_AES_256,
>      S390_FEAT_PCC_XTS_EAES_128,
>      S390_FEAT_PCC_XTS_EAES_256,
> +    S390_FEAT_PCC_SCALAR_MULT_P256,
> +    S390_FEAT_PCC_SCALAR_MULT_P384,
> +    S390_FEAT_PCC_SCALAR_MULT_P512,
> +    S390_FEAT_PCC_SCALAR_MULT_ED25519,
> +    S390_FEAT_PCC_SCALAR_MULT_ED448,
> +    S390_FEAT_PCC_SCALAR_MULT_X25519,
> +    S390_FEAT_PCC_SCALAR_MULT_X448,
>  
>      /* PPNO/PRNO */
>      S390_FEAT_PPNO_SHA_512_DRNG,
> @@ -313,6 +326,24 @@ typedef enum {
>      S390_FEAT_KMA_GCM_EAES_128,
>      S390_FEAT_KMA_GCM_EAES_192,
>      S390_FEAT_KMA_GCM_EAES_256,
> +
> +    /* KDSA */
> +    S390_FEAT_ECDSA_VERIFY_P256,
> +    S390_FEAT_ECDSA_VERIFY_P384,
> +    S390_FEAT_ECDSA_VERIFY_P512,
> +    S390_FEAT_ECDSA_SIGN_P256,
> +    S390_FEAT_ECDSA_SIGN_P384,
> +    S390_FEAT_ECDSA_SIGN_P512,
> +    S390_FEAT_EECDSA_SIGN_P256,
> +    S390_FEAT_EECDSA_SIGN_P384,
> +    S390_FEAT_EECDSA_SIGN_P512,
> +    S390_FEAT_EDDSA_VERIFY_ED25519,
> +    S390_FEAT_EDDSA_VERIFY_ED448,
> +    S390_FEAT_EDDSA_SIGN_ED25519,
> +    S390_FEAT_EDDSA_SIGN_ED448,
> +    S390_FEAT_EEDDSA_SIGN_ED25519,
> +    S390_FEAT_EEDDSA_SIGN_ED448,
> +
>      S390_FEAT_MAX,
>  } S390Feat;
>  
> diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
> index 4e5aa879f3..4c355e936e 100644
> --- a/target/s390x/cpu_models.c
> +++ b/target/s390x/cpu_models.c
> @@ -808,6 +808,7 @@ static void check_consistency(const S390CPUModel *model)
>          { S390_FEAT_SIE_CMMA, S390_FEAT_SIE_GSLS },
>          { S390_FEAT_SIE_PFMFI, S390_FEAT_EDAT },
>          { S390_FEAT_MSA_EXT_8, S390_FEAT_MSA_EXT_3 },
> +        { S390_FEAT_MSA_EXT_9, S390_FEAT_MSA_EXT_3 },

This is sufficient to handle key wrapping, right?


-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH 04/10] s390x/cpumodel: msa9 facility

[David Hildenbrand]

On 18.04.19 13:31, Christian Borntraeger wrote:
> Provide the MSA9 facility (stfle.155).  This also contains pckmo
> functions for key wrapping. Keep them in a separate group to allow
> disabling/enabling those as a block if necessary.
> 
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
>  target/s390x/cpu_features.c     | 32 +++++++++++++++++++++++++
>  target/s390x/cpu_features.h     |  1 +
>  target/s390x/cpu_features_def.h | 31 ++++++++++++++++++++++++
>  target/s390x/cpu_models.c       |  1 +
>  target/s390x/gen-features.c     | 42 +++++++++++++++++++++++++++++++++
>  target/s390x/kvm.c              |  6 +++++
>  6 files changed, 113 insertions(+)
> 
> diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
> index bbd8902087..4d624b2256 100644
> --- a/target/s390x/cpu_features.c
> +++ b/target/s390x/cpu_features.c
> @@ -108,6 +108,7 @@ static const S390FeatDef s390_features[] = {
>      FEAT_INIT("irbm", S390_FEAT_TYPE_STFL, 145, "Insert-reference-bits-multiple facility"),
>      FEAT_INIT("msa8-base", S390_FEAT_TYPE_STFL, 146, "Message-security-assist-extension-8 facility (excluding subfunctions)"),
>      FEAT_INIT("cmmnt", S390_FEAT_TYPE_STFL, 147, "CMM: ESSA-enhancement (no translate) facility"),
> +    FEAT_INIT("msa9-base", S390_FEAT_TYPE_STFL, 155, "Message-security-assist-extension-9 facility (excluding subfunctions)"),
>      FEAT_INIT("etoken", S390_FEAT_TYPE_STFL, 156, "Etoken facility"),
>  
>      /* SCLP SCCB Byte 80 - 98  (bit numbers relative to byte-80) */
> @@ -242,6 +243,11 @@ static const S390FeatDef s390_features[] = {
>      FEAT_INIT("pckmo-aes-128", S390_FEAT_TYPE_PCKMO, 18, "PCKMO Encrypted-AES-128-Key"),
>      FEAT_INIT("pckmo-aes-192", S390_FEAT_TYPE_PCKMO, 19, "PCKMO Encrypted-AES-192-Key"),
>      FEAT_INIT("pckmo-aes-256", S390_FEAT_TYPE_PCKMO, 20, "PCKMO Encrypted-AES-256-Key"),
> +    FEAT_INIT("pckmo-ecc-p256", S390_FEAT_TYPE_PCKMO,32, "PCKMO Encrypt-ECC-P256-Key"),
> +    FEAT_INIT("pckmo-ecc-p384", S390_FEAT_TYPE_PCKMO,33, "PCKMO Encrypt-ECC-P384-Key"),
> +    FEAT_INIT("pckmo-ecc-p521", S390_FEAT_TYPE_PCKMO,34, "PCKMO Encrypt-ECC-P521-Key"),
> +    FEAT_INIT("pckmo-ecc-ed25519", S390_FEAT_TYPE_PCKMO,40 , "PCKMO Encrypt-ECC-Ed25519-Key"),
> +    FEAT_INIT("pckmo-ecc-ed448", S390_FEAT_TYPE_PCKMO,41 , "PCKMO Encrypt-ECC-Ed448-Key"),
>  
>      FEAT_INIT("kmctr-dea", S390_FEAT_TYPE_KMCTR, 1, "KMCTR DEA"),
>      FEAT_INIT("kmctr-tdea-128", S390_FEAT_TYPE_KMCTR, 2, "KMCTR TDEA-128"),
> @@ -298,6 +304,13 @@ static const S390FeatDef s390_features[] = {
>      FEAT_INIT("pcc-xts-aes-256", S390_FEAT_TYPE_PCC, 52, "PCC Compute-XTS-Parameter-Using-AES-256"),
>      FEAT_INIT("pcc-xts-eaes-128", S390_FEAT_TYPE_PCC, 58, "PCC Compute-XTS-Parameter-Using-Encrypted-AES-128"),
>      FEAT_INIT("pcc-xts-eaes-256", S390_FEAT_TYPE_PCC, 60, "PCC Compute-XTS-Parameter-Using-Encrypted-AES-256"),
> +    FEAT_INIT("pcc-scalar-mult-p256", S390_FEAT_TYPE_PCC, 64, "PCC Scalar-Multiply-P256"),
> +    FEAT_INIT("pcc-scalar-mult-p384", S390_FEAT_TYPE_PCC, 65, "PCC Scalar-Multiply-P384"),
> +    FEAT_INIT("pcc-scalar-mult-p521", S390_FEAT_TYPE_PCC, 66, "PCC Scalar-Multiply-P521"),
> +    FEAT_INIT("pcc-scalar-mult-ed25519", S390_FEAT_TYPE_PCC, 72, "PCC Scalar-Multiply-Ed25519"),
> +    FEAT_INIT("pcc-scalar-mult-ed448", S390_FEAT_TYPE_PCC, 73, "PCC Scalar-Multiply-Ed448"),
> +    FEAT_INIT("pcc-scalar-mult-x25519", S390_FEAT_TYPE_PCC, 80, "PCC Scalar-Multiply-X25519"),
> +    FEAT_INIT("pcc-scalar-mult-x448", S390_FEAT_TYPE_PCC, 81, "PCC Scalar-Multiply-X448"),
>  
>      FEAT_INIT("ppno-sha-512-drng", S390_FEAT_TYPE_PPNO, 3, "PPNO SHA-512-DRNG"),
>      FEAT_INIT("prno-trng-qrtcr", S390_FEAT_TYPE_PPNO, 112, "PRNO TRNG-Query-Raw-to-Conditioned-Ratio"),
> @@ -309,6 +322,22 @@ static const S390FeatDef s390_features[] = {
>      FEAT_INIT("kma-gcm-eaes-128", S390_FEAT_TYPE_KMA, 26, "KMA GCM-Encrypted-AES-128"),
>      FEAT_INIT("kma-gcm-eaes-192", S390_FEAT_TYPE_KMA, 27, "KMA GCM-Encrypted-AES-192"),
>      FEAT_INIT("kma-gcm-eaes-256", S390_FEAT_TYPE_KMA, 28, "KMA GCM-Encrypted-AES-256"),
> +
> +    FEAT_INIT("kdsa-ecdsa-verify-p256", S390_FEAT_TYPE_KDSA, 1, "KDSA ECDSA-Verify-P256"),
> +    FEAT_INIT("kdsa-ecdsa-verify-p384", S390_FEAT_TYPE_KDSA, 2, "KDSA ECDSA-Verify-P384"),
> +    FEAT_INIT("kdsa-ecdsa-verify-p521", S390_FEAT_TYPE_KDSA, 3, "KDSA ECDSA-Verify-P521"),
> +    FEAT_INIT("kdsa-ecdsa-sign-p256", S390_FEAT_TYPE_KDSA, 9, "KDSA ECDSA-Sign-P256"),
> +    FEAT_INIT("kdsa-ecdsa-sign-p384", S390_FEAT_TYPE_KDSA, 10, "KDSA ECDSA-Sign-P384"),
> +    FEAT_INIT("kdsa-ecdsa-sign-p521", S390_FEAT_TYPE_KDSA, 11, "KDSA ECDSA-Sign-P521"),
> +    FEAT_INIT("kdsa-eecdsa-sign-p256", S390_FEAT_TYPE_KDSA, 17, "KDSA Encrypted-ECDSA-Sign-P256"),
> +    FEAT_INIT("kdsa-eecdsa-sign-p384", S390_FEAT_TYPE_KDSA, 18, "KDSA Encrypted-ECDSA-Sign-P384"),
> +    FEAT_INIT("kdsa-eecdsa-sign-p521", S390_FEAT_TYPE_KDSA, 19, "KDSA Encrypted-ECDSA-Sign-P521"),
> +    FEAT_INIT("kdsa-eddsa-verify-ed25519", S390_FEAT_TYPE_KDSA, 32, "KDSA EdDSA-Verify-Ed25519"),
> +    FEAT_INIT("kdsa-eddsa-verify-ed448", S390_FEAT_TYPE_KDSA, 36, "KDSA EdDSA-Verify-Ed448"),
> +    FEAT_INIT("kdsa-eddsa-sign-ed25519", S390_FEAT_TYPE_KDSA, 40, "KDSA EdDSA-Sign-Ed25519"),
> +    FEAT_INIT("kdsa-eddsa-sign-ed448", S390_FEAT_TYPE_KDSA, 44, "KDSA EdDSA-Sign-Ed448"),
> +    FEAT_INIT("kdsa-eeddsa-sign-ed25519", S390_FEAT_TYPE_KDSA, 48, "KDSA Encrypted-EdDSA-Sign-Ed25519"),
> +    FEAT_INIT("kdsa-eeddsa-sign-ed448", S390_FEAT_TYPE_KDSA, 52, "KDSA Encrypted-EdDSA-Sign-Ed448"),
>  };
>  
>  const S390FeatDef *s390_feat_def(S390Feat feat)
> @@ -371,6 +400,7 @@ void s390_fill_feat_block(const S390FeatBitmap features, S390FeatType type,
>      case S390_FEAT_TYPE_PCC:
>      case S390_FEAT_TYPE_PPNO:
>      case S390_FEAT_TYPE_KMA:
> +    case S390_FEAT_TYPE_KDSA:
>          set_be_bit(0, data); /* query is always available */
>          break;
>      default:
> @@ -466,6 +496,8 @@ static S390FeatGroupDef s390_feature_groups[] = {
>      FEAT_GROUP_INIT("msa6", MSA_EXT_6, "Message-security-assist-extension 6 facility"),
>      FEAT_GROUP_INIT("msa7", MSA_EXT_7, "Message-security-assist-extension 7 facility"),
>      FEAT_GROUP_INIT("msa8", MSA_EXT_8, "Message-security-assist-extension 8 facility"),
> +    FEAT_GROUP_INIT("msa9", MSA_EXT_9, "Message-security-assist-extension 9 facility"),
> +    FEAT_GROUP_INIT("msa9_pckmo", MSA_EXT_9_PCKMO, "Message-security-assist-extension 9 PCKMO subfunctions"),
>      FEAT_GROUP_INIT("mepochptff", MULTIPLE_EPOCH_PTFF, "PTFF enhancements introduced with Multiple-epoch facility"),
>  };
>  
> diff --git a/target/s390x/cpu_features.h b/target/s390x/cpu_features.h
> index effe790271..5ffd3db083 100644
> --- a/target/s390x/cpu_features.h
> +++ b/target/s390x/cpu_features.h
> @@ -39,6 +39,7 @@ typedef enum {
>      S390_FEAT_TYPE_PCC,
>      S390_FEAT_TYPE_PPNO,
>      S390_FEAT_TYPE_KMA,
> +    S390_FEAT_TYPE_KDSA,
>  } S390FeatType;
>  
>  /* Definition of a CPU feature */
> diff --git a/target/s390x/cpu_features_def.h b/target/s390x/cpu_features_def.h
> index 31dd678301..030784811b 100644
> --- a/target/s390x/cpu_features_def.h
> +++ b/target/s390x/cpu_features_def.h
> @@ -96,6 +96,7 @@ typedef enum {
>      S390_FEAT_INSERT_REFERENCE_BITS_MULT,
>      S390_FEAT_MSA_EXT_8,
>      S390_FEAT_CMM_NT,
> +    S390_FEAT_MSA_EXT_9,
>      S390_FEAT_ETOKEN,
>  
>      /* Sclp Conf Char */
> @@ -240,6 +241,11 @@ typedef enum {
>      S390_FEAT_PCKMO_AES_128,
>      S390_FEAT_PCKMO_AES_192,
>      S390_FEAT_PCKMO_AES_256,
> +    S390_FEAT_PCKMO_ECC_P256,
> +    S390_FEAT_PCKMO_ECC_P384,
> +    S390_FEAT_PCKMO_ECC_P521,
> +    S390_FEAT_PCKMO_ECC_ED25519,
> +    S390_FEAT_PCKMO_ECC_ED448,
>  
>      /* KMCTR */
>      S390_FEAT_KMCTR_DEA,
> @@ -300,6 +306,13 @@ typedef enum {
>      S390_FEAT_PCC_XTS_AES_256,
>      S390_FEAT_PCC_XTS_EAES_128,
>      S390_FEAT_PCC_XTS_EAES_256,
> +    S390_FEAT_PCC_SCALAR_MULT_P256,
> +    S390_FEAT_PCC_SCALAR_MULT_P384,
> +    S390_FEAT_PCC_SCALAR_MULT_P512,
> +    S390_FEAT_PCC_SCALAR_MULT_ED25519,
> +    S390_FEAT_PCC_SCALAR_MULT_ED448,
> +    S390_FEAT_PCC_SCALAR_MULT_X25519,
> +    S390_FEAT_PCC_SCALAR_MULT_X448,
>  
>      /* PPNO/PRNO */
>      S390_FEAT_PPNO_SHA_512_DRNG,
> @@ -313,6 +326,24 @@ typedef enum {
>      S390_FEAT_KMA_GCM_EAES_128,
>      S390_FEAT_KMA_GCM_EAES_192,
>      S390_FEAT_KMA_GCM_EAES_256,
> +
> +    /* KDSA */
> +    S390_FEAT_ECDSA_VERIFY_P256,
> +    S390_FEAT_ECDSA_VERIFY_P384,
> +    S390_FEAT_ECDSA_VERIFY_P512,
> +    S390_FEAT_ECDSA_SIGN_P256,
> +    S390_FEAT_ECDSA_SIGN_P384,
> +    S390_FEAT_ECDSA_SIGN_P512,
> +    S390_FEAT_EECDSA_SIGN_P256,
> +    S390_FEAT_EECDSA_SIGN_P384,
> +    S390_FEAT_EECDSA_SIGN_P512,
> +    S390_FEAT_EDDSA_VERIFY_ED25519,
> +    S390_FEAT_EDDSA_VERIFY_ED448,
> +    S390_FEAT_EDDSA_SIGN_ED25519,
> +    S390_FEAT_EDDSA_SIGN_ED448,
> +    S390_FEAT_EEDDSA_SIGN_ED25519,
> +    S390_FEAT_EEDDSA_SIGN_ED448,
> +
>      S390_FEAT_MAX,
>  } S390Feat;
>  
> diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
> index 4e5aa879f3..4c355e936e 100644
> --- a/target/s390x/cpu_models.c
> +++ b/target/s390x/cpu_models.c
> @@ -808,6 +808,7 @@ static void check_consistency(const S390CPUModel *model)
>          { S390_FEAT_SIE_CMMA, S390_FEAT_SIE_GSLS },
>          { S390_FEAT_SIE_PFMFI, S390_FEAT_EDAT },
>          { S390_FEAT_MSA_EXT_8, S390_FEAT_MSA_EXT_3 },
> +        { S390_FEAT_MSA_EXT_9, S390_FEAT_MSA_EXT_3 },

This is sufficient to handle key wrapping, right?


-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH 10/10] s390x/cpumodel: do not claim csske for expanded models in qmp

[Christian Borntraeger]

On 18.04.19 14:48, David Hildenbrand wrote:
> On 18.04.19 13:31, Christian Borntraeger wrote:
>> While we have removed csske and bpb from the default model, the very
>> common case of "host-model" in libvirt (expanded to a base model
>> + features) would still contain bpb and csske. This can prevent
>> migration to a future machine for a host-model machine. Let us fence
>> bpb and csske when we run on a generation 15. If necessary the
>> user can still use -cpu 8561,csske=on,bpb=on to force enable these
>> features.
>>
>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>> ---
>>  target/s390x/cpu_models.c | 11 +++++++++++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
>> index e727519686..03bdca1fb8 100644
>> --- a/target/s390x/cpu_models.c
>> +++ b/target/s390x/cpu_models.c
>> @@ -629,6 +629,17 @@ CpuModelExpansionInfo *qmp_query_cpu_model_expansion(CpuModelExpansionType type,
>>          return NULL;
>>      }
>>  
>> +    /*
>> +     * Do not claim CSSKE and BPB if the host model expands to
>> +     * generation 15 or newer
>> +     */
>> +    if (s390_model.def->gen >= 15) {
>> +        clear_bit(S390_FEAT_CONDITIONAL_SSKE,
>> +                  (unsigned long *) &s390_model.features);
>> +        clear_bit(S390_FEAT_BPB,
>> +                  (unsigned long *) &s390_model.features);
>> +    }
>> +
>>      if (type == CPU_MODEL_EXPANSION_TYPE_STATIC) {
>>          delta_changes = true;
>>      } else if (type != CPU_MODEL_EXPANSION_TYPE_FULL) {
>>
> 
> The bad thing about it is, it hinders migration *to* this hw generation.

It does not, at least not with todays libvirt. It will happily ask for
-cpu z14,bpb=on and the guest will have it. the current checking is done
by starting a qemu with a "wished" model and then check for success. 

PS: I tested that with managedsave


> Will have to think about this some more. As alternative, simply ignore
> S390_FEAT_CONDITIONAL_SSKE and S390_FEAT_BPB when baselining/comparing.

Re: [Qemu-devel] [PATCH 10/10] s390x/cpumodel: do not claim csske for expanded models in qmp

[Christian Borntraeger]

On 18.04.19 14:48, David Hildenbrand wrote:
> On 18.04.19 13:31, Christian Borntraeger wrote:
>> While we have removed csske and bpb from the default model, the very
>> common case of "host-model" in libvirt (expanded to a base model
>> + features) would still contain bpb and csske. This can prevent
>> migration to a future machine for a host-model machine. Let us fence
>> bpb and csske when we run on a generation 15. If necessary the
>> user can still use -cpu 8561,csske=on,bpb=on to force enable these
>> features.
>>
>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>> ---
>>  target/s390x/cpu_models.c | 11 +++++++++++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
>> index e727519686..03bdca1fb8 100644
>> --- a/target/s390x/cpu_models.c
>> +++ b/target/s390x/cpu_models.c
>> @@ -629,6 +629,17 @@ CpuModelExpansionInfo *qmp_query_cpu_model_expansion(CpuModelExpansionType type,
>>          return NULL;
>>      }
>>  
>> +    /*
>> +     * Do not claim CSSKE and BPB if the host model expands to
>> +     * generation 15 or newer
>> +     */
>> +    if (s390_model.def->gen >= 15) {
>> +        clear_bit(S390_FEAT_CONDITIONAL_SSKE,
>> +                  (unsigned long *) &s390_model.features);
>> +        clear_bit(S390_FEAT_BPB,
>> +                  (unsigned long *) &s390_model.features);
>> +    }
>> +
>>      if (type == CPU_MODEL_EXPANSION_TYPE_STATIC) {
>>          delta_changes = true;
>>      } else if (type != CPU_MODEL_EXPANSION_TYPE_FULL) {
>>
> 
> The bad thing about it is, it hinders migration *to* this hw generation.

It does not, at least not with todays libvirt. It will happily ask for
-cpu z14,bpb=on and the guest will have it. the current checking is done
by starting a qemu with a "wished" model and then check for success. 

PS: I tested that with managedsave


> Will have to think about this some more. As alternative, simply ignore
> S390_FEAT_CONDITIONAL_SSKE and S390_FEAT_BPB when baselining/comparing.

Re: [Qemu-devel] [PATCH 05/10] s390x/cpumodel: vector enhancements

[David Hildenbrand]

On 18.04.19 13:31, Christian Borntraeger wrote:
> Add vector enhancements to the cpu model.
> 
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
>  target/s390x/cpu_features.c     | 2 ++
>  target/s390x/cpu_features_def.h | 2 ++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
> index 4d624b2256..ed3f6aa969 100644
> --- a/target/s390x/cpu_features.c
> +++ b/target/s390x/cpu_features.c
> @@ -108,6 +108,8 @@ static const S390FeatDef s390_features[] = {
>      FEAT_INIT("irbm", S390_FEAT_TYPE_STFL, 145, "Insert-reference-bits-multiple facility"),
>      FEAT_INIT("msa8-base", S390_FEAT_TYPE_STFL, 146, "Message-security-assist-extension-8 facility (excluding subfunctions)"),
>      FEAT_INIT("cmmnt", S390_FEAT_TYPE_STFL, 147, "CMM: ESSA-enhancement (no translate) facility"),
> +    FEAT_INIT("vxeh2", S390_FEAT_TYPE_STFL, 148, "Vector Enhancements facility 2"),
> +    FEAT_INIT("vxbeh", S390_FEAT_TYPE_STFL, 152, "Vector BCD enhancements facility 1"),
>      FEAT_INIT("msa9-base", S390_FEAT_TYPE_STFL, 155, "Message-security-assist-extension-9 facility (excluding subfunctions)"),
>      FEAT_INIT("etoken", S390_FEAT_TYPE_STFL, 156, "Etoken facility"),

BTW, to make this less error prone I thought about converting this into
something like

FEAT_INIT(VECTOR_ENH2, "vxeh2", S390_FEAT_TYPE_STFL, 148, "Vector
Enhancements facility 2"),

and internally use

.[S390_FEAT_##FEAT] = { ...

Or similar. But don't have time for that right now.

>  
> diff --git a/target/s390x/cpu_features_def.h b/target/s390x/cpu_features_def.h
> index 030784811b..ce2223c9d7 100644
> --- a/target/s390x/cpu_features_def.h
> +++ b/target/s390x/cpu_features_def.h
> @@ -96,6 +96,8 @@ typedef enum {
>      S390_FEAT_INSERT_REFERENCE_BITS_MULT,
>      S390_FEAT_MSA_EXT_8,
>      S390_FEAT_CMM_NT,
> +    S390_FEAT_VECTOR_ENH2,
> +    S390_FEAT_VECTOR_BCD_ENH,
>      S390_FEAT_MSA_EXT_9,
>      S390_FEAT_ETOKEN,
>  
> 

Reviewed-by: David Hildenbrand <david@redhat.com>

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH 05/10] s390x/cpumodel: vector enhancements

[David Hildenbrand]

On 18.04.19 13:31, Christian Borntraeger wrote:
> Add vector enhancements to the cpu model.
> 
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
>  target/s390x/cpu_features.c     | 2 ++
>  target/s390x/cpu_features_def.h | 2 ++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
> index 4d624b2256..ed3f6aa969 100644
> --- a/target/s390x/cpu_features.c
> +++ b/target/s390x/cpu_features.c
> @@ -108,6 +108,8 @@ static const S390FeatDef s390_features[] = {
>      FEAT_INIT("irbm", S390_FEAT_TYPE_STFL, 145, "Insert-reference-bits-multiple facility"),
>      FEAT_INIT("msa8-base", S390_FEAT_TYPE_STFL, 146, "Message-security-assist-extension-8 facility (excluding subfunctions)"),
>      FEAT_INIT("cmmnt", S390_FEAT_TYPE_STFL, 147, "CMM: ESSA-enhancement (no translate) facility"),
> +    FEAT_INIT("vxeh2", S390_FEAT_TYPE_STFL, 148, "Vector Enhancements facility 2"),
> +    FEAT_INIT("vxbeh", S390_FEAT_TYPE_STFL, 152, "Vector BCD enhancements facility 1"),
>      FEAT_INIT("msa9-base", S390_FEAT_TYPE_STFL, 155, "Message-security-assist-extension-9 facility (excluding subfunctions)"),
>      FEAT_INIT("etoken", S390_FEAT_TYPE_STFL, 156, "Etoken facility"),

BTW, to make this less error prone I thought about converting this into
something like

FEAT_INIT(VECTOR_ENH2, "vxeh2", S390_FEAT_TYPE_STFL, 148, "Vector
Enhancements facility 2"),

and internally use

.[S390_FEAT_##FEAT] = { ...

Or similar. But don't have time for that right now.

>  
> diff --git a/target/s390x/cpu_features_def.h b/target/s390x/cpu_features_def.h
> index 030784811b..ce2223c9d7 100644
> --- a/target/s390x/cpu_features_def.h
> +++ b/target/s390x/cpu_features_def.h
> @@ -96,6 +96,8 @@ typedef enum {
>      S390_FEAT_INSERT_REFERENCE_BITS_MULT,
>      S390_FEAT_MSA_EXT_8,
>      S390_FEAT_CMM_NT,
> +    S390_FEAT_VECTOR_ENH2,
> +    S390_FEAT_VECTOR_BCD_ENH,
>      S390_FEAT_MSA_EXT_9,
>      S390_FEAT_ETOKEN,
>  
> 

Reviewed-by: David Hildenbrand <david@redhat.com>

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH 02/10] s390x/cpumodel: remove CSSKE from base model

[Christian Borntraeger]

On 18.04.19 14:45, David Hildenbrand wrote:
> On 18.04.19 13:31, Christian Borntraeger wrote:
>> conditional sske is deprecated and a distant future machine (will be one
>> where the IBC will not allow to fully go back to z14) will remove this
>> feature. To prepare for this and allow for the z14 and older cpu model
>> to still run on systems without csske, remove csske from the base (and
> 
> will csske feature be a default feature for zNext? Or is it not
> available *at all*.
> 
> In case it is not available, baselining and cpu model comparison have to
> be thought about "ignoring csske".
> 
>> thus the default models for z10..z14). For compat machines we have to
>> add those back.
> 
> Base models are machine-independent. That means, changing base models is
> not supported.

Why is that? for the expansion?

> Once we introduce new models like here, we can set the
> new base models into stone.

the new model is easy (and yes I could only disable CSSKE in the base
model for gen15 but not for gen14. 

The problem is that without some kind of fixup for older base models like
z10-z14 expansion will fall back to z9 on anything that no longer has
csske. 

> 
>>
[....]
>>
> 
> Instead of doing that, can we rather start generating the next
> generation "fresh", listing all base model features it contains instead
> of doing it incrementally? Could end up "nicer"
> 
> 
> In target/s390x/cpu_models.c we have:
> 
> "... For now, base features of a following release are always a subset
> of base features of the previous release. Same is correct for the other
> feature sets."
> 
> This is especially relevant for "s390_find_cpu_def", and goes into the
> direction of baselining, as previously mentioned.
> 
> Luckily, we already have "ignored_base_feat", maybe we can simply add
> csske there and have it working.

Yes, maybe we could ignore csske. 

Re: [Qemu-devel] [PATCH 02/10] s390x/cpumodel: remove CSSKE from base model

[Christian Borntraeger]

On 18.04.19 14:45, David Hildenbrand wrote:
> On 18.04.19 13:31, Christian Borntraeger wrote:
>> conditional sske is deprecated and a distant future machine (will be one
>> where the IBC will not allow to fully go back to z14) will remove this
>> feature. To prepare for this and allow for the z14 and older cpu model
>> to still run on systems without csske, remove csske from the base (and
> 
> will csske feature be a default feature for zNext? Or is it not
> available *at all*.
> 
> In case it is not available, baselining and cpu model comparison have to
> be thought about "ignoring csske".
> 
>> thus the default models for z10..z14). For compat machines we have to
>> add those back.
> 
> Base models are machine-independent. That means, changing base models is
> not supported.

Why is that? for the expansion?

> Once we introduce new models like here, we can set the
> new base models into stone.

the new model is easy (and yes I could only disable CSSKE in the base
model for gen15 but not for gen14. 

The problem is that without some kind of fixup for older base models like
z10-z14 expansion will fall back to z9 on anything that no longer has
csske. 

> 
>>
[....]
>>
> 
> Instead of doing that, can we rather start generating the next
> generation "fresh", listing all base model features it contains instead
> of doing it incrementally? Could end up "nicer"
> 
> 
> In target/s390x/cpu_models.c we have:
> 
> "... For now, base features of a following release are always a subset
> of base features of the previous release. Same is correct for the other
> feature sets."
> 
> This is especially relevant for "s390_find_cpu_def", and goes into the
> direction of baselining, as previously mentioned.
> 
> Luckily, we already have "ignored_base_feat", maybe we can simply add
> csske there and have it working.

Yes, maybe we could ignore csske. 

Re: [Qemu-devel] [PATCH 04/10] s390x/cpumodel: msa9 facility

[Christian Borntraeger]

On 18.04.19 14:54, David Hildenbrand wrote:
> On 18.04.19 13:31, Christian Borntraeger wrote:
>> Provide the MSA9 facility (stfle.155).  This also contains pckmo
>> functions for key wrapping. Keep them in a separate group to allow
>> disabling/enabling those as a block if necessary.
>>
>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>> ---
>>  target/s390x/cpu_features.c     | 32 +++++++++++++++++++++++++
>>  target/s390x/cpu_features.h     |  1 +
>>  target/s390x/cpu_features_def.h | 31 ++++++++++++++++++++++++
>>  target/s390x/cpu_models.c       |  1 +
>>  target/s390x/gen-features.c     | 42 +++++++++++++++++++++++++++++++++
>>  target/s390x/kvm.c              |  6 +++++
>>  6 files changed, 113 insertions(+)
>>
>> diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
>> index bbd8902087..4d624b2256 100644
>> --- a/target/s390x/cpu_features.c
>> +++ b/target/s390x/cpu_features.c
>> @@ -108,6 +108,7 @@ static const S390FeatDef s390_features[] = {
>>      FEAT_INIT("irbm", S390_FEAT_TYPE_STFL, 145, "Insert-reference-bits-multiple facility"),
>>      FEAT_INIT("msa8-base", S390_FEAT_TYPE_STFL, 146, "Message-security-assist-extension-8 facility (excluding subfunctions)"),
>>      FEAT_INIT("cmmnt", S390_FEAT_TYPE_STFL, 147, "CMM: ESSA-enhancement (no translate) facility"),
>> +    FEAT_INIT("msa9-base", S390_FEAT_TYPE_STFL, 155, "Message-security-assist-extension-9 facility (excluding subfunctions)"),
>>      FEAT_INIT("etoken", S390_FEAT_TYPE_STFL, 156, "Etoken facility"),
>>  
>>      /* SCLP SCCB Byte 80 - 98  (bit numbers relative to byte-80) */
>> @@ -242,6 +243,11 @@ static const S390FeatDef s390_features[] = {
>>      FEAT_INIT("pckmo-aes-128", S390_FEAT_TYPE_PCKMO, 18, "PCKMO Encrypted-AES-128-Key"),
>>      FEAT_INIT("pckmo-aes-192", S390_FEAT_TYPE_PCKMO, 19, "PCKMO Encrypted-AES-192-Key"),
>>      FEAT_INIT("pckmo-aes-256", S390_FEAT_TYPE_PCKMO, 20, "PCKMO Encrypted-AES-256-Key"),
>> +    FEAT_INIT("pckmo-ecc-p256", S390_FEAT_TYPE_PCKMO,32, "PCKMO Encrypt-ECC-P256-Key"),
>> +    FEAT_INIT("pckmo-ecc-p384", S390_FEAT_TYPE_PCKMO,33, "PCKMO Encrypt-ECC-P384-Key"),
>> +    FEAT_INIT("pckmo-ecc-p521", S390_FEAT_TYPE_PCKMO,34, "PCKMO Encrypt-ECC-P521-Key"),
>> +    FEAT_INIT("pckmo-ecc-ed25519", S390_FEAT_TYPE_PCKMO,40 , "PCKMO Encrypt-ECC-Ed25519-Key"),
>> +    FEAT_INIT("pckmo-ecc-ed448", S390_FEAT_TYPE_PCKMO,41 , "PCKMO Encrypt-ECC-Ed448-Key"),
>>  
>>      FEAT_INIT("kmctr-dea", S390_FEAT_TYPE_KMCTR, 1, "KMCTR DEA"),
>>      FEAT_INIT("kmctr-tdea-128", S390_FEAT_TYPE_KMCTR, 2, "KMCTR TDEA-128"),
>> @@ -298,6 +304,13 @@ static const S390FeatDef s390_features[] = {
>>      FEAT_INIT("pcc-xts-aes-256", S390_FEAT_TYPE_PCC, 52, "PCC Compute-XTS-Parameter-Using-AES-256"),
>>      FEAT_INIT("pcc-xts-eaes-128", S390_FEAT_TYPE_PCC, 58, "PCC Compute-XTS-Parameter-Using-Encrypted-AES-128"),
>>      FEAT_INIT("pcc-xts-eaes-256", S390_FEAT_TYPE_PCC, 60, "PCC Compute-XTS-Parameter-Using-Encrypted-AES-256"),
>> +    FEAT_INIT("pcc-scalar-mult-p256", S390_FEAT_TYPE_PCC, 64, "PCC Scalar-Multiply-P256"),
>> +    FEAT_INIT("pcc-scalar-mult-p384", S390_FEAT_TYPE_PCC, 65, "PCC Scalar-Multiply-P384"),
>> +    FEAT_INIT("pcc-scalar-mult-p521", S390_FEAT_TYPE_PCC, 66, "PCC Scalar-Multiply-P521"),
>> +    FEAT_INIT("pcc-scalar-mult-ed25519", S390_FEAT_TYPE_PCC, 72, "PCC Scalar-Multiply-Ed25519"),
>> +    FEAT_INIT("pcc-scalar-mult-ed448", S390_FEAT_TYPE_PCC, 73, "PCC Scalar-Multiply-Ed448"),
>> +    FEAT_INIT("pcc-scalar-mult-x25519", S390_FEAT_TYPE_PCC, 80, "PCC Scalar-Multiply-X25519"),
>> +    FEAT_INIT("pcc-scalar-mult-x448", S390_FEAT_TYPE_PCC, 81, "PCC Scalar-Multiply-X448"),
>>  
>>      FEAT_INIT("ppno-sha-512-drng", S390_FEAT_TYPE_PPNO, 3, "PPNO SHA-512-DRNG"),
>>      FEAT_INIT("prno-trng-qrtcr", S390_FEAT_TYPE_PPNO, 112, "PRNO TRNG-Query-Raw-to-Conditioned-Ratio"),
>> @@ -309,6 +322,22 @@ static const S390FeatDef s390_features[] = {
>>      FEAT_INIT("kma-gcm-eaes-128", S390_FEAT_TYPE_KMA, 26, "KMA GCM-Encrypted-AES-128"),
>>      FEAT_INIT("kma-gcm-eaes-192", S390_FEAT_TYPE_KMA, 27, "KMA GCM-Encrypted-AES-192"),
>>      FEAT_INIT("kma-gcm-eaes-256", S390_FEAT_TYPE_KMA, 28, "KMA GCM-Encrypted-AES-256"),
>> +
>> +    FEAT_INIT("kdsa-ecdsa-verify-p256", S390_FEAT_TYPE_KDSA, 1, "KDSA ECDSA-Verify-P256"),
>> +    FEAT_INIT("kdsa-ecdsa-verify-p384", S390_FEAT_TYPE_KDSA, 2, "KDSA ECDSA-Verify-P384"),
>> +    FEAT_INIT("kdsa-ecdsa-verify-p521", S390_FEAT_TYPE_KDSA, 3, "KDSA ECDSA-Verify-P521"),
>> +    FEAT_INIT("kdsa-ecdsa-sign-p256", S390_FEAT_TYPE_KDSA, 9, "KDSA ECDSA-Sign-P256"),
>> +    FEAT_INIT("kdsa-ecdsa-sign-p384", S390_FEAT_TYPE_KDSA, 10, "KDSA ECDSA-Sign-P384"),
>> +    FEAT_INIT("kdsa-ecdsa-sign-p521", S390_FEAT_TYPE_KDSA, 11, "KDSA ECDSA-Sign-P521"),
>> +    FEAT_INIT("kdsa-eecdsa-sign-p256", S390_FEAT_TYPE_KDSA, 17, "KDSA Encrypted-ECDSA-Sign-P256"),
>> +    FEAT_INIT("kdsa-eecdsa-sign-p384", S390_FEAT_TYPE_KDSA, 18, "KDSA Encrypted-ECDSA-Sign-P384"),
>> +    FEAT_INIT("kdsa-eecdsa-sign-p521", S390_FEAT_TYPE_KDSA, 19, "KDSA Encrypted-ECDSA-Sign-P521"),
>> +    FEAT_INIT("kdsa-eddsa-verify-ed25519", S390_FEAT_TYPE_KDSA, 32, "KDSA EdDSA-Verify-Ed25519"),
>> +    FEAT_INIT("kdsa-eddsa-verify-ed448", S390_FEAT_TYPE_KDSA, 36, "KDSA EdDSA-Verify-Ed448"),
>> +    FEAT_INIT("kdsa-eddsa-sign-ed25519", S390_FEAT_TYPE_KDSA, 40, "KDSA EdDSA-Sign-Ed25519"),
>> +    FEAT_INIT("kdsa-eddsa-sign-ed448", S390_FEAT_TYPE_KDSA, 44, "KDSA EdDSA-Sign-Ed448"),
>> +    FEAT_INIT("kdsa-eeddsa-sign-ed25519", S390_FEAT_TYPE_KDSA, 48, "KDSA Encrypted-EdDSA-Sign-Ed25519"),
>> +    FEAT_INIT("kdsa-eeddsa-sign-ed448", S390_FEAT_TYPE_KDSA, 52, "KDSA Encrypted-EdDSA-Sign-Ed448"),
>>  };
>>  
>>  const S390FeatDef *s390_feat_def(S390Feat feat)
>> @@ -371,6 +400,7 @@ void s390_fill_feat_block(const S390FeatBitmap features, S390FeatType type,
>>      case S390_FEAT_TYPE_PCC:
>>      case S390_FEAT_TYPE_PPNO:
>>      case S390_FEAT_TYPE_KMA:
>> +    case S390_FEAT_TYPE_KDSA:
>>          set_be_bit(0, data); /* query is always available */
>>          break;
>>      default:
>> @@ -466,6 +496,8 @@ static S390FeatGroupDef s390_feature_groups[] = {
>>      FEAT_GROUP_INIT("msa6", MSA_EXT_6, "Message-security-assist-extension 6 facility"),
>>      FEAT_GROUP_INIT("msa7", MSA_EXT_7, "Message-security-assist-extension 7 facility"),
>>      FEAT_GROUP_INIT("msa8", MSA_EXT_8, "Message-security-assist-extension 8 facility"),
>> +    FEAT_GROUP_INIT("msa9", MSA_EXT_9, "Message-security-assist-extension 9 facility"),
>> +    FEAT_GROUP_INIT("msa9_pckmo", MSA_EXT_9_PCKMO, "Message-security-assist-extension 9 PCKMO subfunctions"),
>>      FEAT_GROUP_INIT("mepochptff", MULTIPLE_EPOCH_PTFF, "PTFF enhancements introduced with Multiple-epoch facility"),
>>  };
>>  
>> diff --git a/target/s390x/cpu_features.h b/target/s390x/cpu_features.h
>> index effe790271..5ffd3db083 100644
>> --- a/target/s390x/cpu_features.h
>> +++ b/target/s390x/cpu_features.h
>> @@ -39,6 +39,7 @@ typedef enum {
>>      S390_FEAT_TYPE_PCC,
>>      S390_FEAT_TYPE_PPNO,
>>      S390_FEAT_TYPE_KMA,
>> +    S390_FEAT_TYPE_KDSA,
>>  } S390FeatType;
>>  
>>  /* Definition of a CPU feature */
>> diff --git a/target/s390x/cpu_features_def.h b/target/s390x/cpu_features_def.h
>> index 31dd678301..030784811b 100644
>> --- a/target/s390x/cpu_features_def.h
>> +++ b/target/s390x/cpu_features_def.h
>> @@ -96,6 +96,7 @@ typedef enum {
>>      S390_FEAT_INSERT_REFERENCE_BITS_MULT,
>>      S390_FEAT_MSA_EXT_8,
>>      S390_FEAT_CMM_NT,
>> +    S390_FEAT_MSA_EXT_9,
>>      S390_FEAT_ETOKEN,
>>  
>>      /* Sclp Conf Char */
>> @@ -240,6 +241,11 @@ typedef enum {
>>      S390_FEAT_PCKMO_AES_128,
>>      S390_FEAT_PCKMO_AES_192,
>>      S390_FEAT_PCKMO_AES_256,
>> +    S390_FEAT_PCKMO_ECC_P256,
>> +    S390_FEAT_PCKMO_ECC_P384,
>> +    S390_FEAT_PCKMO_ECC_P521,
>> +    S390_FEAT_PCKMO_ECC_ED25519,
>> +    S390_FEAT_PCKMO_ECC_ED448,
>>  
>>      /* KMCTR */
>>      S390_FEAT_KMCTR_DEA,
>> @@ -300,6 +306,13 @@ typedef enum {
>>      S390_FEAT_PCC_XTS_AES_256,
>>      S390_FEAT_PCC_XTS_EAES_128,
>>      S390_FEAT_PCC_XTS_EAES_256,
>> +    S390_FEAT_PCC_SCALAR_MULT_P256,
>> +    S390_FEAT_PCC_SCALAR_MULT_P384,
>> +    S390_FEAT_PCC_SCALAR_MULT_P512,
>> +    S390_FEAT_PCC_SCALAR_MULT_ED25519,
>> +    S390_FEAT_PCC_SCALAR_MULT_ED448,
>> +    S390_FEAT_PCC_SCALAR_MULT_X25519,
>> +    S390_FEAT_PCC_SCALAR_MULT_X448,
>>  
>>      /* PPNO/PRNO */
>>      S390_FEAT_PPNO_SHA_512_DRNG,
>> @@ -313,6 +326,24 @@ typedef enum {
>>      S390_FEAT_KMA_GCM_EAES_128,
>>      S390_FEAT_KMA_GCM_EAES_192,
>>      S390_FEAT_KMA_GCM_EAES_256,
>> +
>> +    /* KDSA */
>> +    S390_FEAT_ECDSA_VERIFY_P256,
>> +    S390_FEAT_ECDSA_VERIFY_P384,
>> +    S390_FEAT_ECDSA_VERIFY_P512,
>> +    S390_FEAT_ECDSA_SIGN_P256,
>> +    S390_FEAT_ECDSA_SIGN_P384,
>> +    S390_FEAT_ECDSA_SIGN_P512,
>> +    S390_FEAT_EECDSA_SIGN_P256,
>> +    S390_FEAT_EECDSA_SIGN_P384,
>> +    S390_FEAT_EECDSA_SIGN_P512,
>> +    S390_FEAT_EDDSA_VERIFY_ED25519,
>> +    S390_FEAT_EDDSA_VERIFY_ED448,
>> +    S390_FEAT_EDDSA_SIGN_ED25519,
>> +    S390_FEAT_EDDSA_SIGN_ED448,
>> +    S390_FEAT_EEDDSA_SIGN_ED25519,
>> +    S390_FEAT_EEDDSA_SIGN_ED448,
>> +
>>      S390_FEAT_MAX,
>>  } S390Feat;
>>  
>> diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
>> index 4e5aa879f3..4c355e936e 100644
>> --- a/target/s390x/cpu_models.c
>> +++ b/target/s390x/cpu_models.c
>> @@ -808,6 +808,7 @@ static void check_consistency(const S390CPUModel *model)
>>          { S390_FEAT_SIE_CMMA, S390_FEAT_SIE_GSLS },
>>          { S390_FEAT_SIE_PFMFI, S390_FEAT_EDAT },
>>          { S390_FEAT_MSA_EXT_8, S390_FEAT_MSA_EXT_3 },
>> +        { S390_FEAT_MSA_EXT_9, S390_FEAT_MSA_EXT_3 },
> 
> This is sufficient to handle key wrapping, right?

Right. I think I should also add a dependency to MSA_EXT_4.

Re: [Qemu-devel] [PATCH 04/10] s390x/cpumodel: msa9 facility

[Christian Borntraeger]

On 18.04.19 14:54, David Hildenbrand wrote:
> On 18.04.19 13:31, Christian Borntraeger wrote:
>> Provide the MSA9 facility (stfle.155).  This also contains pckmo
>> functions for key wrapping. Keep them in a separate group to allow
>> disabling/enabling those as a block if necessary.
>>
>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>> ---
>>  target/s390x/cpu_features.c     | 32 +++++++++++++++++++++++++
>>  target/s390x/cpu_features.h     |  1 +
>>  target/s390x/cpu_features_def.h | 31 ++++++++++++++++++++++++
>>  target/s390x/cpu_models.c       |  1 +
>>  target/s390x/gen-features.c     | 42 +++++++++++++++++++++++++++++++++
>>  target/s390x/kvm.c              |  6 +++++
>>  6 files changed, 113 insertions(+)
>>
>> diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
>> index bbd8902087..4d624b2256 100644
>> --- a/target/s390x/cpu_features.c
>> +++ b/target/s390x/cpu_features.c
>> @@ -108,6 +108,7 @@ static const S390FeatDef s390_features[] = {
>>      FEAT_INIT("irbm", S390_FEAT_TYPE_STFL, 145, "Insert-reference-bits-multiple facility"),
>>      FEAT_INIT("msa8-base", S390_FEAT_TYPE_STFL, 146, "Message-security-assist-extension-8 facility (excluding subfunctions)"),
>>      FEAT_INIT("cmmnt", S390_FEAT_TYPE_STFL, 147, "CMM: ESSA-enhancement (no translate) facility"),
>> +    FEAT_INIT("msa9-base", S390_FEAT_TYPE_STFL, 155, "Message-security-assist-extension-9 facility (excluding subfunctions)"),
>>      FEAT_INIT("etoken", S390_FEAT_TYPE_STFL, 156, "Etoken facility"),
>>  
>>      /* SCLP SCCB Byte 80 - 98  (bit numbers relative to byte-80) */
>> @@ -242,6 +243,11 @@ static const S390FeatDef s390_features[] = {
>>      FEAT_INIT("pckmo-aes-128", S390_FEAT_TYPE_PCKMO, 18, "PCKMO Encrypted-AES-128-Key"),
>>      FEAT_INIT("pckmo-aes-192", S390_FEAT_TYPE_PCKMO, 19, "PCKMO Encrypted-AES-192-Key"),
>>      FEAT_INIT("pckmo-aes-256", S390_FEAT_TYPE_PCKMO, 20, "PCKMO Encrypted-AES-256-Key"),
>> +    FEAT_INIT("pckmo-ecc-p256", S390_FEAT_TYPE_PCKMO,32, "PCKMO Encrypt-ECC-P256-Key"),
>> +    FEAT_INIT("pckmo-ecc-p384", S390_FEAT_TYPE_PCKMO,33, "PCKMO Encrypt-ECC-P384-Key"),
>> +    FEAT_INIT("pckmo-ecc-p521", S390_FEAT_TYPE_PCKMO,34, "PCKMO Encrypt-ECC-P521-Key"),
>> +    FEAT_INIT("pckmo-ecc-ed25519", S390_FEAT_TYPE_PCKMO,40 , "PCKMO Encrypt-ECC-Ed25519-Key"),
>> +    FEAT_INIT("pckmo-ecc-ed448", S390_FEAT_TYPE_PCKMO,41 , "PCKMO Encrypt-ECC-Ed448-Key"),
>>  
>>      FEAT_INIT("kmctr-dea", S390_FEAT_TYPE_KMCTR, 1, "KMCTR DEA"),
>>      FEAT_INIT("kmctr-tdea-128", S390_FEAT_TYPE_KMCTR, 2, "KMCTR TDEA-128"),
>> @@ -298,6 +304,13 @@ static const S390FeatDef s390_features[] = {
>>      FEAT_INIT("pcc-xts-aes-256", S390_FEAT_TYPE_PCC, 52, "PCC Compute-XTS-Parameter-Using-AES-256"),
>>      FEAT_INIT("pcc-xts-eaes-128", S390_FEAT_TYPE_PCC, 58, "PCC Compute-XTS-Parameter-Using-Encrypted-AES-128"),
>>      FEAT_INIT("pcc-xts-eaes-256", S390_FEAT_TYPE_PCC, 60, "PCC Compute-XTS-Parameter-Using-Encrypted-AES-256"),
>> +    FEAT_INIT("pcc-scalar-mult-p256", S390_FEAT_TYPE_PCC, 64, "PCC Scalar-Multiply-P256"),
>> +    FEAT_INIT("pcc-scalar-mult-p384", S390_FEAT_TYPE_PCC, 65, "PCC Scalar-Multiply-P384"),
>> +    FEAT_INIT("pcc-scalar-mult-p521", S390_FEAT_TYPE_PCC, 66, "PCC Scalar-Multiply-P521"),
>> +    FEAT_INIT("pcc-scalar-mult-ed25519", S390_FEAT_TYPE_PCC, 72, "PCC Scalar-Multiply-Ed25519"),
>> +    FEAT_INIT("pcc-scalar-mult-ed448", S390_FEAT_TYPE_PCC, 73, "PCC Scalar-Multiply-Ed448"),
>> +    FEAT_INIT("pcc-scalar-mult-x25519", S390_FEAT_TYPE_PCC, 80, "PCC Scalar-Multiply-X25519"),
>> +    FEAT_INIT("pcc-scalar-mult-x448", S390_FEAT_TYPE_PCC, 81, "PCC Scalar-Multiply-X448"),
>>  
>>      FEAT_INIT("ppno-sha-512-drng", S390_FEAT_TYPE_PPNO, 3, "PPNO SHA-512-DRNG"),
>>      FEAT_INIT("prno-trng-qrtcr", S390_FEAT_TYPE_PPNO, 112, "PRNO TRNG-Query-Raw-to-Conditioned-Ratio"),
>> @@ -309,6 +322,22 @@ static const S390FeatDef s390_features[] = {
>>      FEAT_INIT("kma-gcm-eaes-128", S390_FEAT_TYPE_KMA, 26, "KMA GCM-Encrypted-AES-128"),
>>      FEAT_INIT("kma-gcm-eaes-192", S390_FEAT_TYPE_KMA, 27, "KMA GCM-Encrypted-AES-192"),
>>      FEAT_INIT("kma-gcm-eaes-256", S390_FEAT_TYPE_KMA, 28, "KMA GCM-Encrypted-AES-256"),
>> +
>> +    FEAT_INIT("kdsa-ecdsa-verify-p256", S390_FEAT_TYPE_KDSA, 1, "KDSA ECDSA-Verify-P256"),
>> +    FEAT_INIT("kdsa-ecdsa-verify-p384", S390_FEAT_TYPE_KDSA, 2, "KDSA ECDSA-Verify-P384"),
>> +    FEAT_INIT("kdsa-ecdsa-verify-p521", S390_FEAT_TYPE_KDSA, 3, "KDSA ECDSA-Verify-P521"),
>> +    FEAT_INIT("kdsa-ecdsa-sign-p256", S390_FEAT_TYPE_KDSA, 9, "KDSA ECDSA-Sign-P256"),
>> +    FEAT_INIT("kdsa-ecdsa-sign-p384", S390_FEAT_TYPE_KDSA, 10, "KDSA ECDSA-Sign-P384"),
>> +    FEAT_INIT("kdsa-ecdsa-sign-p521", S390_FEAT_TYPE_KDSA, 11, "KDSA ECDSA-Sign-P521"),
>> +    FEAT_INIT("kdsa-eecdsa-sign-p256", S390_FEAT_TYPE_KDSA, 17, "KDSA Encrypted-ECDSA-Sign-P256"),
>> +    FEAT_INIT("kdsa-eecdsa-sign-p384", S390_FEAT_TYPE_KDSA, 18, "KDSA Encrypted-ECDSA-Sign-P384"),
>> +    FEAT_INIT("kdsa-eecdsa-sign-p521", S390_FEAT_TYPE_KDSA, 19, "KDSA Encrypted-ECDSA-Sign-P521"),
>> +    FEAT_INIT("kdsa-eddsa-verify-ed25519", S390_FEAT_TYPE_KDSA, 32, "KDSA EdDSA-Verify-Ed25519"),
>> +    FEAT_INIT("kdsa-eddsa-verify-ed448", S390_FEAT_TYPE_KDSA, 36, "KDSA EdDSA-Verify-Ed448"),
>> +    FEAT_INIT("kdsa-eddsa-sign-ed25519", S390_FEAT_TYPE_KDSA, 40, "KDSA EdDSA-Sign-Ed25519"),
>> +    FEAT_INIT("kdsa-eddsa-sign-ed448", S390_FEAT_TYPE_KDSA, 44, "KDSA EdDSA-Sign-Ed448"),
>> +    FEAT_INIT("kdsa-eeddsa-sign-ed25519", S390_FEAT_TYPE_KDSA, 48, "KDSA Encrypted-EdDSA-Sign-Ed25519"),
>> +    FEAT_INIT("kdsa-eeddsa-sign-ed448", S390_FEAT_TYPE_KDSA, 52, "KDSA Encrypted-EdDSA-Sign-Ed448"),
>>  };
>>  
>>  const S390FeatDef *s390_feat_def(S390Feat feat)
>> @@ -371,6 +400,7 @@ void s390_fill_feat_block(const S390FeatBitmap features, S390FeatType type,
>>      case S390_FEAT_TYPE_PCC:
>>      case S390_FEAT_TYPE_PPNO:
>>      case S390_FEAT_TYPE_KMA:
>> +    case S390_FEAT_TYPE_KDSA:
>>          set_be_bit(0, data); /* query is always available */
>>          break;
>>      default:
>> @@ -466,6 +496,8 @@ static S390FeatGroupDef s390_feature_groups[] = {
>>      FEAT_GROUP_INIT("msa6", MSA_EXT_6, "Message-security-assist-extension 6 facility"),
>>      FEAT_GROUP_INIT("msa7", MSA_EXT_7, "Message-security-assist-extension 7 facility"),
>>      FEAT_GROUP_INIT("msa8", MSA_EXT_8, "Message-security-assist-extension 8 facility"),
>> +    FEAT_GROUP_INIT("msa9", MSA_EXT_9, "Message-security-assist-extension 9 facility"),
>> +    FEAT_GROUP_INIT("msa9_pckmo", MSA_EXT_9_PCKMO, "Message-security-assist-extension 9 PCKMO subfunctions"),
>>      FEAT_GROUP_INIT("mepochptff", MULTIPLE_EPOCH_PTFF, "PTFF enhancements introduced with Multiple-epoch facility"),
>>  };
>>  
>> diff --git a/target/s390x/cpu_features.h b/target/s390x/cpu_features.h
>> index effe790271..5ffd3db083 100644
>> --- a/target/s390x/cpu_features.h
>> +++ b/target/s390x/cpu_features.h
>> @@ -39,6 +39,7 @@ typedef enum {
>>      S390_FEAT_TYPE_PCC,
>>      S390_FEAT_TYPE_PPNO,
>>      S390_FEAT_TYPE_KMA,
>> +    S390_FEAT_TYPE_KDSA,
>>  } S390FeatType;
>>  
>>  /* Definition of a CPU feature */
>> diff --git a/target/s390x/cpu_features_def.h b/target/s390x/cpu_features_def.h
>> index 31dd678301..030784811b 100644
>> --- a/target/s390x/cpu_features_def.h
>> +++ b/target/s390x/cpu_features_def.h
>> @@ -96,6 +96,7 @@ typedef enum {
>>      S390_FEAT_INSERT_REFERENCE_BITS_MULT,
>>      S390_FEAT_MSA_EXT_8,
>>      S390_FEAT_CMM_NT,
>> +    S390_FEAT_MSA_EXT_9,
>>      S390_FEAT_ETOKEN,
>>  
>>      /* Sclp Conf Char */
>> @@ -240,6 +241,11 @@ typedef enum {
>>      S390_FEAT_PCKMO_AES_128,
>>      S390_FEAT_PCKMO_AES_192,
>>      S390_FEAT_PCKMO_AES_256,
>> +    S390_FEAT_PCKMO_ECC_P256,
>> +    S390_FEAT_PCKMO_ECC_P384,
>> +    S390_FEAT_PCKMO_ECC_P521,
>> +    S390_FEAT_PCKMO_ECC_ED25519,
>> +    S390_FEAT_PCKMO_ECC_ED448,
>>  
>>      /* KMCTR */
>>      S390_FEAT_KMCTR_DEA,
>> @@ -300,6 +306,13 @@ typedef enum {
>>      S390_FEAT_PCC_XTS_AES_256,
>>      S390_FEAT_PCC_XTS_EAES_128,
>>      S390_FEAT_PCC_XTS_EAES_256,
>> +    S390_FEAT_PCC_SCALAR_MULT_P256,
>> +    S390_FEAT_PCC_SCALAR_MULT_P384,
>> +    S390_FEAT_PCC_SCALAR_MULT_P512,
>> +    S390_FEAT_PCC_SCALAR_MULT_ED25519,
>> +    S390_FEAT_PCC_SCALAR_MULT_ED448,
>> +    S390_FEAT_PCC_SCALAR_MULT_X25519,
>> +    S390_FEAT_PCC_SCALAR_MULT_X448,
>>  
>>      /* PPNO/PRNO */
>>      S390_FEAT_PPNO_SHA_512_DRNG,
>> @@ -313,6 +326,24 @@ typedef enum {
>>      S390_FEAT_KMA_GCM_EAES_128,
>>      S390_FEAT_KMA_GCM_EAES_192,
>>      S390_FEAT_KMA_GCM_EAES_256,
>> +
>> +    /* KDSA */
>> +    S390_FEAT_ECDSA_VERIFY_P256,
>> +    S390_FEAT_ECDSA_VERIFY_P384,
>> +    S390_FEAT_ECDSA_VERIFY_P512,
>> +    S390_FEAT_ECDSA_SIGN_P256,
>> +    S390_FEAT_ECDSA_SIGN_P384,
>> +    S390_FEAT_ECDSA_SIGN_P512,
>> +    S390_FEAT_EECDSA_SIGN_P256,
>> +    S390_FEAT_EECDSA_SIGN_P384,
>> +    S390_FEAT_EECDSA_SIGN_P512,
>> +    S390_FEAT_EDDSA_VERIFY_ED25519,
>> +    S390_FEAT_EDDSA_VERIFY_ED448,
>> +    S390_FEAT_EDDSA_SIGN_ED25519,
>> +    S390_FEAT_EDDSA_SIGN_ED448,
>> +    S390_FEAT_EEDDSA_SIGN_ED25519,
>> +    S390_FEAT_EEDDSA_SIGN_ED448,
>> +
>>      S390_FEAT_MAX,
>>  } S390Feat;
>>  
>> diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
>> index 4e5aa879f3..4c355e936e 100644
>> --- a/target/s390x/cpu_models.c
>> +++ b/target/s390x/cpu_models.c
>> @@ -808,6 +808,7 @@ static void check_consistency(const S390CPUModel *model)
>>          { S390_FEAT_SIE_CMMA, S390_FEAT_SIE_GSLS },
>>          { S390_FEAT_SIE_PFMFI, S390_FEAT_EDAT },
>>          { S390_FEAT_MSA_EXT_8, S390_FEAT_MSA_EXT_3 },
>> +        { S390_FEAT_MSA_EXT_9, S390_FEAT_MSA_EXT_3 },
> 
> This is sufficient to handle key wrapping, right?

Right. I think I should also add a dependency to MSA_EXT_4.

Re: [Qemu-devel] [PATCH 05/10] s390x/cpumodel: vector enhancements

[Christian Borntraeger]

On 18.04.19 14:56, David Hildenbrand wrote:
> On 18.04.19 13:31, Christian Borntraeger wrote:
>> Add vector enhancements to the cpu model.
>>
>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>> ---
>>  target/s390x/cpu_features.c     | 2 ++
>>  target/s390x/cpu_features_def.h | 2 ++
>>  2 files changed, 4 insertions(+)
>>
>> diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
>> index 4d624b2256..ed3f6aa969 100644
>> --- a/target/s390x/cpu_features.c
>> +++ b/target/s390x/cpu_features.c
>> @@ -108,6 +108,8 @@ static const S390FeatDef s390_features[] = {
>>      FEAT_INIT("irbm", S390_FEAT_TYPE_STFL, 145, "Insert-reference-bits-multiple facility"),
>>      FEAT_INIT("msa8-base", S390_FEAT_TYPE_STFL, 146, "Message-security-assist-extension-8 facility (excluding subfunctions)"),
>>      FEAT_INIT("cmmnt", S390_FEAT_TYPE_STFL, 147, "CMM: ESSA-enhancement (no translate) facility"),
>> +    FEAT_INIT("vxeh2", S390_FEAT_TYPE_STFL, 148, "Vector Enhancements facility 2"),
>> +    FEAT_INIT("vxbeh", S390_FEAT_TYPE_STFL, 152, "Vector BCD enhancements facility 1"),
>>      FEAT_INIT("msa9-base", S390_FEAT_TYPE_STFL, 155, "Message-security-assist-extension-9 facility (excluding subfunctions)"),
>>      FEAT_INIT("etoken", S390_FEAT_TYPE_STFL, 156, "Etoken facility"),
> 
> BTW, to make this less error prone I thought about converting this into
> something like
> 
> FEAT_INIT(VECTOR_ENH2, "vxeh2", S390_FEAT_TYPE_STFL, 148, "Vector
> Enhancements facility 2"),
> 
> and internally use
> 
> .[S390_FEAT_##FEAT] = { ...
> 
> Or similar. But don't have time for that right now.

Yes, we can make the model code simpler. Lots of ideas.
> 
>>  
>> diff --git a/target/s390x/cpu_features_def.h b/target/s390x/cpu_features_def.h
>> index 030784811b..ce2223c9d7 100644
>> --- a/target/s390x/cpu_features_def.h
>> +++ b/target/s390x/cpu_features_def.h
>> @@ -96,6 +96,8 @@ typedef enum {
>>      S390_FEAT_INSERT_REFERENCE_BITS_MULT,
>>      S390_FEAT_MSA_EXT_8,
>>      S390_FEAT_CMM_NT,
>> +    S390_FEAT_VECTOR_ENH2,
>> +    S390_FEAT_VECTOR_BCD_ENH,
>>      S390_FEAT_MSA_EXT_9,
>>      S390_FEAT_ETOKEN,
>>  
>>
> 
> Reviewed-by: David Hildenbrand <david@redhat.com>
> 

Re: [Qemu-devel] [PATCH 05/10] s390x/cpumodel: vector enhancements

[Christian Borntraeger]

On 18.04.19 14:56, David Hildenbrand wrote:
> On 18.04.19 13:31, Christian Borntraeger wrote:
>> Add vector enhancements to the cpu model.
>>
>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>> ---
>>  target/s390x/cpu_features.c     | 2 ++
>>  target/s390x/cpu_features_def.h | 2 ++
>>  2 files changed, 4 insertions(+)
>>
>> diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
>> index 4d624b2256..ed3f6aa969 100644
>> --- a/target/s390x/cpu_features.c
>> +++ b/target/s390x/cpu_features.c
>> @@ -108,6 +108,8 @@ static const S390FeatDef s390_features[] = {
>>      FEAT_INIT("irbm", S390_FEAT_TYPE_STFL, 145, "Insert-reference-bits-multiple facility"),
>>      FEAT_INIT("msa8-base", S390_FEAT_TYPE_STFL, 146, "Message-security-assist-extension-8 facility (excluding subfunctions)"),
>>      FEAT_INIT("cmmnt", S390_FEAT_TYPE_STFL, 147, "CMM: ESSA-enhancement (no translate) facility"),
>> +    FEAT_INIT("vxeh2", S390_FEAT_TYPE_STFL, 148, "Vector Enhancements facility 2"),
>> +    FEAT_INIT("vxbeh", S390_FEAT_TYPE_STFL, 152, "Vector BCD enhancements facility 1"),
>>      FEAT_INIT("msa9-base", S390_FEAT_TYPE_STFL, 155, "Message-security-assist-extension-9 facility (excluding subfunctions)"),
>>      FEAT_INIT("etoken", S390_FEAT_TYPE_STFL, 156, "Etoken facility"),
> 
> BTW, to make this less error prone I thought about converting this into
> something like
> 
> FEAT_INIT(VECTOR_ENH2, "vxeh2", S390_FEAT_TYPE_STFL, 148, "Vector
> Enhancements facility 2"),
> 
> and internally use
> 
> .[S390_FEAT_##FEAT] = { ...
> 
> Or similar. But don't have time for that right now.

Yes, we can make the model code simpler. Lots of ideas.
> 
>>  
>> diff --git a/target/s390x/cpu_features_def.h b/target/s390x/cpu_features_def.h
>> index 030784811b..ce2223c9d7 100644
>> --- a/target/s390x/cpu_features_def.h
>> +++ b/target/s390x/cpu_features_def.h
>> @@ -96,6 +96,8 @@ typedef enum {
>>      S390_FEAT_INSERT_REFERENCE_BITS_MULT,
>>      S390_FEAT_MSA_EXT_8,
>>      S390_FEAT_CMM_NT,
>> +    S390_FEAT_VECTOR_ENH2,
>> +    S390_FEAT_VECTOR_BCD_ENH,
>>      S390_FEAT_MSA_EXT_9,
>>      S390_FEAT_ETOKEN,
>>  
>>
> 
> Reviewed-by: David Hildenbrand <david@redhat.com>
> 

Re: [Qemu-devel] [PATCH 02/10] s390x/cpumodel: remove CSSKE from base model

[David Hildenbrand]

On 18.04.19 15:00, Christian Borntraeger wrote:
> 
> 
> On 18.04.19 14:45, David Hildenbrand wrote:
>> On 18.04.19 13:31, Christian Borntraeger wrote:
>>> conditional sske is deprecated and a distant future machine (will be one
>>> where the IBC will not allow to fully go back to z14) will remove this
>>> feature. To prepare for this and allow for the z14 and older cpu model
>>> to still run on systems without csske, remove csske from the base (and
>>
>> will csske feature be a default feature for zNext? Or is it not
>> available *at all*.
>>
>> In case it is not available, baselining and cpu model comparison have to
>> be thought about "ignoring csske".
>>
>>> thus the default models for z10..z14). For compat machines we have to
>>> add those back.
>>
>> Base models are machine-independent. That means, changing base models is
>> not supported.
> 
> Why is that? for the expansion?

Yes, and baselining. It's what the QAPI interface promises.

> 
>> Once we introduce new models like here, we can set the
>> new base models into stone.
> 
> the new model is easy (and yes I could only disable CSSKE in the base
> model for gen15 but not for gen14. 
> 
> The problem is that without some kind of fixup for older base models like
> z10-z14 expansion will fall back to z9 on anything that no longer has
> csske. 

I'd prefer to do generate the "right" base models right away and not fix
them up at runtime. They should never change, so fixing them up at
runtime feels wrong.

>> Luckily, we already have "ignored_base_feat", maybe we can simply add
>> csske there and have it working.
> 
> Yes, maybe we could ignore csske. 
> 

Yes, that should at least avoid falling back to a z9.

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH 02/10] s390x/cpumodel: remove CSSKE from base model

[David Hildenbrand]

On 18.04.19 15:00, Christian Borntraeger wrote:
> 
> 
> On 18.04.19 14:45, David Hildenbrand wrote:
>> On 18.04.19 13:31, Christian Borntraeger wrote:
>>> conditional sske is deprecated and a distant future machine (will be one
>>> where the IBC will not allow to fully go back to z14) will remove this
>>> feature. To prepare for this and allow for the z14 and older cpu model
>>> to still run on systems without csske, remove csske from the base (and
>>
>> will csske feature be a default feature for zNext? Or is it not
>> available *at all*.
>>
>> In case it is not available, baselining and cpu model comparison have to
>> be thought about "ignoring csske".
>>
>>> thus the default models for z10..z14). For compat machines we have to
>>> add those back.
>>
>> Base models are machine-independent. That means, changing base models is
>> not supported.
> 
> Why is that? for the expansion?

Yes, and baselining. It's what the QAPI interface promises.

> 
>> Once we introduce new models like here, we can set the
>> new base models into stone.
> 
> the new model is easy (and yes I could only disable CSSKE in the base
> model for gen15 but not for gen14. 
> 
> The problem is that without some kind of fixup for older base models like
> z10-z14 expansion will fall back to z9 on anything that no longer has
> csske. 

I'd prefer to do generate the "right" base models right away and not fix
them up at runtime. They should never change, so fixing them up at
runtime feels wrong.

>> Luckily, we already have "ignored_base_feat", maybe we can simply add
>> csske there and have it working.
> 
> Yes, maybe we could ignore csske. 
> 

Yes, that should at least avoid falling back to a z9.

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH 02/10] s390x/cpumodel: remove CSSKE from base model

[Christian Borntraeger]

On 18.04.19 14:45, David Hildenbrand wrote:
> On 18.04.19 13:31, Christian Borntraeger wrote:
>> conditional sske is deprecated and a distant future machine (will be one
>> where the IBC will not allow to fully go back to z14) will remove this
>> feature. To prepare for this and allow for the z14 and older cpu model
>> to still run on systems without csske, remove csske from the base (and
> 
> will csske feature be a default feature for zNext? Or is it not
> available *at all*.
> 
> In case it is not available, baselining and cpu model comparison have to
> be thought about "ignoring csske".
> 
>> thus the default models for z10..z14). For compat machines we have to
>> add those back.
> 
> Base models are machine-independent. That means, changing base models is
> not supported. Once we introduce new models like here, we can set the
> new base models into stone.
> 
>>
>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>> ---
>>  hw/s390x/s390-virtio-ccw.c  |  2 ++
>>  target/s390x/cpu_models.c   | 21 +++++++++++++++++++++
>>  target/s390x/cpu_models.h   |  1 +
>>  target/s390x/gen-features.c |  1 -
>>  4 files changed, 24 insertions(+), 1 deletion(-)
>>
>> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
>> index d11069b860..3415948b2c 100644
>> --- a/hw/s390x/s390-virtio-ccw.c
>> +++ b/hw/s390x/s390-virtio-ccw.c
>> @@ -648,6 +648,8 @@ bool css_migration_enabled(void)
>>  
>>  static void ccw_machine_4_0_instance_options(MachineState *machine)
>>  {
>> +    /* re-enable csske for compat machines in the base model */
>> +    s390_cpumodel_fixup_csske();
>>  }
>>  
>>  static void ccw_machine_4_0_class_options(MachineClass *mc)
>> diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
>> index eb125d4d0d..4e5aa879f3 100644
>> --- a/target/s390x/cpu_models.c
>> +++ b/target/s390x/cpu_models.c
>> @@ -93,6 +93,27 @@ static S390FeatBitmap qemu_max_cpu_feat;
>>  /* features part of a base model but not relevant for finding a base model */
>>  S390FeatBitmap ignored_base_feat;
>>  
>> +/*
>> + * We removed CSSKE from the base features. This is a hook for compat machines
>> + * to put this back for gen10..gen14. As the base model is also part of the
>> + * default model to have to fixup both bitfields
>> + */
>> +void s390_cpumodel_fixup_csske(void)
>> +{
>> +    int i;
>> +
>> +    for (i = 0; i < ARRAY_SIZE(s390_cpu_defs); i++) {
>> +        const S390CPUDef *def = &s390_cpu_defs[i];
>> +
>> +        if (def->gen < 10 || def->gen > 14) {
>> +            continue;
>> +        }
>> +
>> +        set_bit(S390_FEAT_CONDITIONAL_SSKE, (unsigned long *)&def->base_feat);
>> +        set_bit(S390_FEAT_CONDITIONAL_SSKE, (unsigned long *)&def->default_feat);
>> +    }
>> +}
> 
> I think that can be avoided by smarter generation of the models, which I
> would prefer.
> 

Very rough, but something like this (I have to find a nice way to use the qemu
clear_bit).

diff --git a/target/s390x/gen-features.c b/target/s390x/gen-features.c
index 15cd9836c4..21c786127a 100644
--- a/target/s390x/gen-features.c
+++ b/target/s390x/gen-features.c
@@ -13,6 +13,7 @@
 
 #include <inttypes.h>
 #include <stdio.h>
+#include <string.h>
 #include "cpu_features_def.h"
 
 #define ARRAY_SIZE(array) (sizeof(array) / sizeof(array[0]))
@@ -833,6 +834,16 @@ static void set_bits(uint64_t list[], BitSpec bits)
     }
 }
 
+#define BIT_MASK(nr)            (1UL << ((nr) % 64))
+#define BIT_WORD(nr)            ((nr) / 64)
+static inline void clear_bit(long nr, uint64_t *addr)
+{
+    unsigned long mask = BIT_MASK(nr);
+    unsigned long *p = addr + BIT_WORD(nr);
+
+    *p &= ~mask;
+}
+
 static void print_feature_defs(void)
 {
     uint64_t base_feat[S390_FEAT_MAX / 64 + 1] = {};
@@ -843,6 +854,11 @@ static void print_feature_defs(void)
     printf("\n/* CPU model feature list data */\n");
 
     for (i = 0; i < ARRAY_SIZE(CpuFeatDef); i++) {
+       /* With gen15 CSSKE is deprecated */
+       if (strcmp(CpuFeatDef[i].name, "S390_FEAT_LIST_GEN15_GA1") == 0) {
+               clear_bit(S390_FEAT_CONDITIONAL_SSKE, base_feat);
+               clear_bit(S390_FEAT_CONDITIONAL_SSKE, default_feat);
+       }
         set_bits(base_feat, CpuFeatDef[i].base_bits);
         /* add the base to the default features */
         set_bits(default_feat, CpuFeatDef[i].base_bits);

Re: [Qemu-devel] [PATCH 02/10] s390x/cpumodel: remove CSSKE from base model

[Christian Borntraeger]

On 18.04.19 14:45, David Hildenbrand wrote:
> On 18.04.19 13:31, Christian Borntraeger wrote:
>> conditional sske is deprecated and a distant future machine (will be one
>> where the IBC will not allow to fully go back to z14) will remove this
>> feature. To prepare for this and allow for the z14 and older cpu model
>> to still run on systems without csske, remove csske from the base (and
> 
> will csske feature be a default feature for zNext? Or is it not
> available *at all*.
> 
> In case it is not available, baselining and cpu model comparison have to
> be thought about "ignoring csske".
> 
>> thus the default models for z10..z14). For compat machines we have to
>> add those back.
> 
> Base models are machine-independent. That means, changing base models is
> not supported. Once we introduce new models like here, we can set the
> new base models into stone.
> 
>>
>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>> ---
>>  hw/s390x/s390-virtio-ccw.c  |  2 ++
>>  target/s390x/cpu_models.c   | 21 +++++++++++++++++++++
>>  target/s390x/cpu_models.h   |  1 +
>>  target/s390x/gen-features.c |  1 -
>>  4 files changed, 24 insertions(+), 1 deletion(-)
>>
>> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
>> index d11069b860..3415948b2c 100644
>> --- a/hw/s390x/s390-virtio-ccw.c
>> +++ b/hw/s390x/s390-virtio-ccw.c
>> @@ -648,6 +648,8 @@ bool css_migration_enabled(void)
>>  
>>  static void ccw_machine_4_0_instance_options(MachineState *machine)
>>  {
>> +    /* re-enable csske for compat machines in the base model */
>> +    s390_cpumodel_fixup_csske();
>>  }
>>  
>>  static void ccw_machine_4_0_class_options(MachineClass *mc)
>> diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
>> index eb125d4d0d..4e5aa879f3 100644
>> --- a/target/s390x/cpu_models.c
>> +++ b/target/s390x/cpu_models.c
>> @@ -93,6 +93,27 @@ static S390FeatBitmap qemu_max_cpu_feat;
>>  /* features part of a base model but not relevant for finding a base model */
>>  S390FeatBitmap ignored_base_feat;
>>  
>> +/*
>> + * We removed CSSKE from the base features. This is a hook for compat machines
>> + * to put this back for gen10..gen14. As the base model is also part of the
>> + * default model to have to fixup both bitfields
>> + */
>> +void s390_cpumodel_fixup_csske(void)
>> +{
>> +    int i;
>> +
>> +    for (i = 0; i < ARRAY_SIZE(s390_cpu_defs); i++) {
>> +        const S390CPUDef *def = &s390_cpu_defs[i];
>> +
>> +        if (def->gen < 10 || def->gen > 14) {
>> +            continue;
>> +        }
>> +
>> +        set_bit(S390_FEAT_CONDITIONAL_SSKE, (unsigned long *)&def->base_feat);
>> +        set_bit(S390_FEAT_CONDITIONAL_SSKE, (unsigned long *)&def->default_feat);
>> +    }
>> +}
> 
> I think that can be avoided by smarter generation of the models, which I
> would prefer.
> 

Very rough, but something like this (I have to find a nice way to use the qemu
clear_bit).

diff --git a/target/s390x/gen-features.c b/target/s390x/gen-features.c
index 15cd9836c4..21c786127a 100644
--- a/target/s390x/gen-features.c
+++ b/target/s390x/gen-features.c
@@ -13,6 +13,7 @@
 
 #include <inttypes.h>
 #include <stdio.h>
+#include <string.h>
 #include "cpu_features_def.h"
 
 #define ARRAY_SIZE(array) (sizeof(array) / sizeof(array[0]))
@@ -833,6 +834,16 @@ static void set_bits(uint64_t list[], BitSpec bits)
     }
 }
 
+#define BIT_MASK(nr)            (1UL << ((nr) % 64))
+#define BIT_WORD(nr)            ((nr) / 64)
+static inline void clear_bit(long nr, uint64_t *addr)
+{
+    unsigned long mask = BIT_MASK(nr);
+    unsigned long *p = addr + BIT_WORD(nr);
+
+    *p &= ~mask;
+}
+
 static void print_feature_defs(void)
 {
     uint64_t base_feat[S390_FEAT_MAX / 64 + 1] = {};
@@ -843,6 +854,11 @@ static void print_feature_defs(void)
     printf("\n/* CPU model feature list data */\n");
 
     for (i = 0; i < ARRAY_SIZE(CpuFeatDef); i++) {
+       /* With gen15 CSSKE is deprecated */
+       if (strcmp(CpuFeatDef[i].name, "S390_FEAT_LIST_GEN15_GA1") == 0) {
+               clear_bit(S390_FEAT_CONDITIONAL_SSKE, base_feat);
+               clear_bit(S390_FEAT_CONDITIONAL_SSKE, default_feat);
+       }
         set_bits(base_feat, CpuFeatDef[i].base_bits);
         /* add the base to the default features */
         set_bits(default_feat, CpuFeatDef[i].base_bits);

Re: [Qemu-devel] [PATCH 02/10] s390x/cpumodel: remove CSSKE from base model

[David Hildenbrand]

On 18.04.19 16:01, Christian Borntraeger wrote:
> 
> 
> On 18.04.19 14:45, David Hildenbrand wrote:
>> On 18.04.19 13:31, Christian Borntraeger wrote:
>>> conditional sske is deprecated and a distant future machine (will be one
>>> where the IBC will not allow to fully go back to z14) will remove this
>>> feature. To prepare for this and allow for the z14 and older cpu model
>>> to still run on systems without csske, remove csske from the base (and
>>
>> will csske feature be a default feature for zNext? Or is it not
>> available *at all*.
>>
>> In case it is not available, baselining and cpu model comparison have to
>> be thought about "ignoring csske".
>>
>>> thus the default models for z10..z14). For compat machines we have to
>>> add those back.
>>
>> Base models are machine-independent. That means, changing base models is
>> not supported. Once we introduce new models like here, we can set the
>> new base models into stone.
>>
>>>
>>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>>> ---
>>>  hw/s390x/s390-virtio-ccw.c  |  2 ++
>>>  target/s390x/cpu_models.c   | 21 +++++++++++++++++++++
>>>  target/s390x/cpu_models.h   |  1 +
>>>  target/s390x/gen-features.c |  1 -
>>>  4 files changed, 24 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
>>> index d11069b860..3415948b2c 100644
>>> --- a/hw/s390x/s390-virtio-ccw.c
>>> +++ b/hw/s390x/s390-virtio-ccw.c
>>> @@ -648,6 +648,8 @@ bool css_migration_enabled(void)
>>>  
>>>  static void ccw_machine_4_0_instance_options(MachineState *machine)
>>>  {
>>> +    /* re-enable csske for compat machines in the base model */
>>> +    s390_cpumodel_fixup_csske();
>>>  }
>>>  
>>>  static void ccw_machine_4_0_class_options(MachineClass *mc)
>>> diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
>>> index eb125d4d0d..4e5aa879f3 100644
>>> --- a/target/s390x/cpu_models.c
>>> +++ b/target/s390x/cpu_models.c
>>> @@ -93,6 +93,27 @@ static S390FeatBitmap qemu_max_cpu_feat;
>>>  /* features part of a base model but not relevant for finding a base model */
>>>  S390FeatBitmap ignored_base_feat;
>>>  
>>> +/*
>>> + * We removed CSSKE from the base features. This is a hook for compat machines
>>> + * to put this back for gen10..gen14. As the base model is also part of the
>>> + * default model to have to fixup both bitfields
>>> + */
>>> +void s390_cpumodel_fixup_csske(void)
>>> +{
>>> +    int i;
>>> +
>>> +    for (i = 0; i < ARRAY_SIZE(s390_cpu_defs); i++) {
>>> +        const S390CPUDef *def = &s390_cpu_defs[i];
>>> +
>>> +        if (def->gen < 10 || def->gen > 14) {
>>> +            continue;
>>> +        }
>>> +
>>> +        set_bit(S390_FEAT_CONDITIONAL_SSKE, (unsigned long *)&def->base_feat);
>>> +        set_bit(S390_FEAT_CONDITIONAL_SSKE, (unsigned long *)&def->default_feat);
>>> +    }
>>> +}
>>
>> I think that can be avoided by smarter generation of the models, which I
>> would prefer.
>>
> 
> Very rough, but something like this (I have to find a nice way to use the qemu
> clear_bit).

We work on uint64_t, not unsigned long, therefore using existing bitmap
operations would be theoretically wrong (and even make compilation more
complicated). Just use a custom helper.

> 
> diff --git a/target/s390x/gen-features.c b/target/s390x/gen-features.c
> index 15cd9836c4..21c786127a 100644
> --- a/target/s390x/gen-features.c
> +++ b/target/s390x/gen-features.c
> @@ -13,6 +13,7 @@
>  
>  #include <inttypes.h>
>  #include <stdio.h>
> +#include <string.h>
>  #include "cpu_features_def.h"
>  
>  #define ARRAY_SIZE(array) (sizeof(array) / sizeof(array[0]))
> @@ -833,6 +834,16 @@ static void set_bits(uint64_t list[], BitSpec bits)
>      }
>  }
>  
> +#define BIT_MASK(nr)            (1UL << ((nr) % 64))
> +#define BIT_WORD(nr)            ((nr) / 64)
> +static inline void clear_bit(long nr, uint64_t *addr)
> +{
> +    unsigned long mask = BIT_MASK(nr);
> +    unsigned long *p = addr + BIT_WORD(nr);
> +
> +    *p &= ~mask;
> +}
> +

Looking at set_bits(), clear_bit() could be as simple as

list[nr / 64] &= ~(1ULL << (nr % 64));

>  static void print_feature_defs(void)
>  {
>      uint64_t base_feat[S390_FEAT_MAX / 64 + 1] = {};
> @@ -843,6 +854,11 @@ static void print_feature_defs(void)
>      printf("\n/* CPU model feature list data */\n");
>  
>      for (i = 0; i < ARRAY_SIZE(CpuFeatDef); i++) {
> +       /* With gen15 CSSKE is deprecated */
> +       if (strcmp(CpuFeatDef[i].name, "S390_FEAT_LIST_GEN15_GA1") == 0) {
> +               clear_bit(S390_FEAT_CONDITIONAL_SSKE, base_feat);
> +               clear_bit(S390_FEAT_CONDITIONAL_SSKE, default_feat);
> +       }
>          set_bits(base_feat, CpuFeatDef[i].base_bits);
>          /* add the base to the default features */
>          set_bits(default_feat, CpuFeatDef[i].base_bits);
> 

That's even better. We could also add clear_bits() with deprecation
lists, similar to set_bits.


-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH 02/10] s390x/cpumodel: remove CSSKE from base model

[David Hildenbrand]

On 18.04.19 16:01, Christian Borntraeger wrote:
> 
> 
> On 18.04.19 14:45, David Hildenbrand wrote:
>> On 18.04.19 13:31, Christian Borntraeger wrote:
>>> conditional sske is deprecated and a distant future machine (will be one
>>> where the IBC will not allow to fully go back to z14) will remove this
>>> feature. To prepare for this and allow for the z14 and older cpu model
>>> to still run on systems without csske, remove csske from the base (and
>>
>> will csske feature be a default feature for zNext? Or is it not
>> available *at all*.
>>
>> In case it is not available, baselining and cpu model comparison have to
>> be thought about "ignoring csske".
>>
>>> thus the default models for z10..z14). For compat machines we have to
>>> add those back.
>>
>> Base models are machine-independent. That means, changing base models is
>> not supported. Once we introduce new models like here, we can set the
>> new base models into stone.
>>
>>>
>>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>>> ---
>>>  hw/s390x/s390-virtio-ccw.c  |  2 ++
>>>  target/s390x/cpu_models.c   | 21 +++++++++++++++++++++
>>>  target/s390x/cpu_models.h   |  1 +
>>>  target/s390x/gen-features.c |  1 -
>>>  4 files changed, 24 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
>>> index d11069b860..3415948b2c 100644
>>> --- a/hw/s390x/s390-virtio-ccw.c
>>> +++ b/hw/s390x/s390-virtio-ccw.c
>>> @@ -648,6 +648,8 @@ bool css_migration_enabled(void)
>>>  
>>>  static void ccw_machine_4_0_instance_options(MachineState *machine)
>>>  {
>>> +    /* re-enable csske for compat machines in the base model */
>>> +    s390_cpumodel_fixup_csske();
>>>  }
>>>  
>>>  static void ccw_machine_4_0_class_options(MachineClass *mc)
>>> diff --git a/target/s390x/cpu_models.c b/target/s390x/cpu_models.c
>>> index eb125d4d0d..4e5aa879f3 100644
>>> --- a/target/s390x/cpu_models.c
>>> +++ b/target/s390x/cpu_models.c
>>> @@ -93,6 +93,27 @@ static S390FeatBitmap qemu_max_cpu_feat;
>>>  /* features part of a base model but not relevant for finding a base model */
>>>  S390FeatBitmap ignored_base_feat;
>>>  
>>> +/*
>>> + * We removed CSSKE from the base features. This is a hook for compat machines
>>> + * to put this back for gen10..gen14. As the base model is also part of the
>>> + * default model to have to fixup both bitfields
>>> + */
>>> +void s390_cpumodel_fixup_csske(void)
>>> +{
>>> +    int i;
>>> +
>>> +    for (i = 0; i < ARRAY_SIZE(s390_cpu_defs); i++) {
>>> +        const S390CPUDef *def = &s390_cpu_defs[i];
>>> +
>>> +        if (def->gen < 10 || def->gen > 14) {
>>> +            continue;
>>> +        }
>>> +
>>> +        set_bit(S390_FEAT_CONDITIONAL_SSKE, (unsigned long *)&def->base_feat);
>>> +        set_bit(S390_FEAT_CONDITIONAL_SSKE, (unsigned long *)&def->default_feat);
>>> +    }
>>> +}
>>
>> I think that can be avoided by smarter generation of the models, which I
>> would prefer.
>>
> 
> Very rough, but something like this (I have to find a nice way to use the qemu
> clear_bit).

We work on uint64_t, not unsigned long, therefore using existing bitmap
operations would be theoretically wrong (and even make compilation more
complicated). Just use a custom helper.

> 
> diff --git a/target/s390x/gen-features.c b/target/s390x/gen-features.c
> index 15cd9836c4..21c786127a 100644
> --- a/target/s390x/gen-features.c
> +++ b/target/s390x/gen-features.c
> @@ -13,6 +13,7 @@
>  
>  #include <inttypes.h>
>  #include <stdio.h>
> +#include <string.h>
>  #include "cpu_features_def.h"
>  
>  #define ARRAY_SIZE(array) (sizeof(array) / sizeof(array[0]))
> @@ -833,6 +834,16 @@ static void set_bits(uint64_t list[], BitSpec bits)
>      }
>  }
>  
> +#define BIT_MASK(nr)            (1UL << ((nr) % 64))
> +#define BIT_WORD(nr)            ((nr) / 64)
> +static inline void clear_bit(long nr, uint64_t *addr)
> +{
> +    unsigned long mask = BIT_MASK(nr);
> +    unsigned long *p = addr + BIT_WORD(nr);
> +
> +    *p &= ~mask;
> +}
> +

Looking at set_bits(), clear_bit() could be as simple as

list[nr / 64] &= ~(1ULL << (nr % 64));

>  static void print_feature_defs(void)
>  {
>      uint64_t base_feat[S390_FEAT_MAX / 64 + 1] = {};
> @@ -843,6 +854,11 @@ static void print_feature_defs(void)
>      printf("\n/* CPU model feature list data */\n");
>  
>      for (i = 0; i < ARRAY_SIZE(CpuFeatDef); i++) {
> +       /* With gen15 CSSKE is deprecated */
> +       if (strcmp(CpuFeatDef[i].name, "S390_FEAT_LIST_GEN15_GA1") == 0) {
> +               clear_bit(S390_FEAT_CONDITIONAL_SSKE, base_feat);
> +               clear_bit(S390_FEAT_CONDITIONAL_SSKE, default_feat);
> +       }
>          set_bits(base_feat, CpuFeatDef[i].base_bits);
>          /* add the base to the default features */
>          set_bits(default_feat, CpuFeatDef[i].base_bits);
> 

That's even better. We could also add clear_bits() with deprecation
lists, similar to set_bits.


-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH 07/10] s390x/cpumodel: deflate

[David Hildenbrand]

On 18.04.19 13:31, Christian Borntraeger wrote:
> add the deflate conversion facility.

Nit:

"s390x/cpumodel: add Deflate-conversion facility"

> 
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
>  target/s390x/cpu_features.c     |  9 +++++++++
>  target/s390x/cpu_features.h     |  1 +
>  target/s390x/cpu_features_def.h |  7 +++++++
>  target/s390x/gen-features.c     | 12 ++++++++++++
>  target/s390x/kvm.c              |  6 ++++++
>  5 files changed, 35 insertions(+)
> 
> diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
> index e0a4769c19..5f37e655fe 100644
> --- a/target/s390x/cpu_features.c
> +++ b/target/s390x/cpu_features.c
> @@ -110,6 +110,7 @@ static const S390FeatDef s390_features[] = {
>      FEAT_INIT("cmmnt", S390_FEAT_TYPE_STFL, 147, "CMM: ESSA-enhancement (no translate) facility"),
>      FEAT_INIT("vxeh2", S390_FEAT_TYPE_STFL, 148, "Vector Enhancements facility 2"),
>      FEAT_INIT("esort-base", S390_FEAT_TYPE_STFL, 150, "Enhanced-sort facility (excluding subfunctions)"),
> +    FEAT_INIT("deflate-base", S390_FEAT_TYPE_STFL, 151, "Deflate-conversion facility (excluding subfunctions)"),
>      FEAT_INIT("vxbeh", S390_FEAT_TYPE_STFL, 152, "Vector BCD enhancements facility 1"),
>      FEAT_INIT("msa9-base", S390_FEAT_TYPE_STFL, 155, "Message-security-assist-extension-9 facility (excluding subfunctions)"),
>      FEAT_INIT("etoken", S390_FEAT_TYPE_STFL, 156, "Etoken facility"),
> @@ -347,6 +348,11 @@ static const S390FeatDef s390_features[] = {
>      FEAT_INIT("sortl-32", S390_FEAT_TYPE_SORTL, 130, "SORTL 32 input lists"),
>      FEAT_INIT("sortl-128", S390_FEAT_TYPE_SORTL, 132, "SORTL 128 input lists"),
>      FEAT_INIT("sortl-f0", S390_FEAT_TYPE_SORTL, 192, "SORTL format 0 parameter-block"),
> +
> +    FEAT_INIT("dfltcc-gdht", S390_FEAT_TYPE_DFLTCC, 1, "DFLTCC GDHT"),
> +    FEAT_INIT("dfltcc-cmpr", S390_FEAT_TYPE_DFLTCC, 2, "DFLTCC CMPR"),
> +    FEAT_INIT("dfltcc-xpnd", S390_FEAT_TYPE_DFLTCC, 4, "DFLTCC XPND"),
> +    FEAT_INIT("dfltcc-f0", S390_FEAT_TYPE_DFLTCC, 192, "DFLTCC format 0 parameter-block"),
>  };

Just wonder, "format 0 parameter-block" is actually a feature right,
like "format 0 can be used". Can we hide format-0, IOW could that be
like "query" and always supported? (especially due to backwards
compatibility)


-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH 07/10] s390x/cpumodel: deflate

[David Hildenbrand]

On 18.04.19 13:31, Christian Borntraeger wrote:
> add the deflate conversion facility.

Nit:

"s390x/cpumodel: add Deflate-conversion facility"

> 
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
>  target/s390x/cpu_features.c     |  9 +++++++++
>  target/s390x/cpu_features.h     |  1 +
>  target/s390x/cpu_features_def.h |  7 +++++++
>  target/s390x/gen-features.c     | 12 ++++++++++++
>  target/s390x/kvm.c              |  6 ++++++
>  5 files changed, 35 insertions(+)
> 
> diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
> index e0a4769c19..5f37e655fe 100644
> --- a/target/s390x/cpu_features.c
> +++ b/target/s390x/cpu_features.c
> @@ -110,6 +110,7 @@ static const S390FeatDef s390_features[] = {
>      FEAT_INIT("cmmnt", S390_FEAT_TYPE_STFL, 147, "CMM: ESSA-enhancement (no translate) facility"),
>      FEAT_INIT("vxeh2", S390_FEAT_TYPE_STFL, 148, "Vector Enhancements facility 2"),
>      FEAT_INIT("esort-base", S390_FEAT_TYPE_STFL, 150, "Enhanced-sort facility (excluding subfunctions)"),
> +    FEAT_INIT("deflate-base", S390_FEAT_TYPE_STFL, 151, "Deflate-conversion facility (excluding subfunctions)"),
>      FEAT_INIT("vxbeh", S390_FEAT_TYPE_STFL, 152, "Vector BCD enhancements facility 1"),
>      FEAT_INIT("msa9-base", S390_FEAT_TYPE_STFL, 155, "Message-security-assist-extension-9 facility (excluding subfunctions)"),
>      FEAT_INIT("etoken", S390_FEAT_TYPE_STFL, 156, "Etoken facility"),
> @@ -347,6 +348,11 @@ static const S390FeatDef s390_features[] = {
>      FEAT_INIT("sortl-32", S390_FEAT_TYPE_SORTL, 130, "SORTL 32 input lists"),
>      FEAT_INIT("sortl-128", S390_FEAT_TYPE_SORTL, 132, "SORTL 128 input lists"),
>      FEAT_INIT("sortl-f0", S390_FEAT_TYPE_SORTL, 192, "SORTL format 0 parameter-block"),
> +
> +    FEAT_INIT("dfltcc-gdht", S390_FEAT_TYPE_DFLTCC, 1, "DFLTCC GDHT"),
> +    FEAT_INIT("dfltcc-cmpr", S390_FEAT_TYPE_DFLTCC, 2, "DFLTCC CMPR"),
> +    FEAT_INIT("dfltcc-xpnd", S390_FEAT_TYPE_DFLTCC, 4, "DFLTCC XPND"),
> +    FEAT_INIT("dfltcc-f0", S390_FEAT_TYPE_DFLTCC, 192, "DFLTCC format 0 parameter-block"),
>  };

Just wonder, "format 0 parameter-block" is actually a feature right,
like "format 0 can be used". Can we hide format-0, IOW could that be
like "query" and always supported? (especially due to backwards
compatibility)


-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH 07/10] s390x/cpumodel: deflate

[Christian Borntraeger]

On 18.04.19 17:36, David Hildenbrand wrote:
> On 18.04.19 13:31, Christian Borntraeger wrote:
>> add the deflate conversion facility.
> 
> Nit:
> 
> "s390x/cpumodel: add Deflate-conversion facility"
> 
>>
>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>> ---
>>  target/s390x/cpu_features.c     |  9 +++++++++
>>  target/s390x/cpu_features.h     |  1 +
>>  target/s390x/cpu_features_def.h |  7 +++++++
>>  target/s390x/gen-features.c     | 12 ++++++++++++
>>  target/s390x/kvm.c              |  6 ++++++
>>  5 files changed, 35 insertions(+)
>>
>> diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
>> index e0a4769c19..5f37e655fe 100644
>> --- a/target/s390x/cpu_features.c
>> +++ b/target/s390x/cpu_features.c
>> @@ -110,6 +110,7 @@ static const S390FeatDef s390_features[] = {
>>      FEAT_INIT("cmmnt", S390_FEAT_TYPE_STFL, 147, "CMM: ESSA-enhancement (no translate) facility"),
>>      FEAT_INIT("vxeh2", S390_FEAT_TYPE_STFL, 148, "Vector Enhancements facility 2"),
>>      FEAT_INIT("esort-base", S390_FEAT_TYPE_STFL, 150, "Enhanced-sort facility (excluding subfunctions)"),
>> +    FEAT_INIT("deflate-base", S390_FEAT_TYPE_STFL, 151, "Deflate-conversion facility (excluding subfunctions)"),
>>      FEAT_INIT("vxbeh", S390_FEAT_TYPE_STFL, 152, "Vector BCD enhancements facility 1"),
>>      FEAT_INIT("msa9-base", S390_FEAT_TYPE_STFL, 155, "Message-security-assist-extension-9 facility (excluding subfunctions)"),
>>      FEAT_INIT("etoken", S390_FEAT_TYPE_STFL, 156, "Etoken facility"),
>> @@ -347,6 +348,11 @@ static const S390FeatDef s390_features[] = {
>>      FEAT_INIT("sortl-32", S390_FEAT_TYPE_SORTL, 130, "SORTL 32 input lists"),
>>      FEAT_INIT("sortl-128", S390_FEAT_TYPE_SORTL, 132, "SORTL 128 input lists"),
>>      FEAT_INIT("sortl-f0", S390_FEAT_TYPE_SORTL, 192, "SORTL format 0 parameter-block"),
>> +
>> +    FEAT_INIT("dfltcc-gdht", S390_FEAT_TYPE_DFLTCC, 1, "DFLTCC GDHT"),
>> +    FEAT_INIT("dfltcc-cmpr", S390_FEAT_TYPE_DFLTCC, 2, "DFLTCC CMPR"),
>> +    FEAT_INIT("dfltcc-xpnd", S390_FEAT_TYPE_DFLTCC, 4, "DFLTCC XPND"),
>> +    FEAT_INIT("dfltcc-f0", S390_FEAT_TYPE_DFLTCC, 192, "DFLTCC format 0 parameter-block"),
>>  };
> 
> Just wonder, "format 0 parameter-block" is actually a feature right,
> like "format 0 can be used". Can we hide format-0, IOW could that be
> like "query" and always supported? (especially due to backwards
> compatibility)

It hopefully will be there forever but since the CSSKE thing I would not
bet on that. So I see your point but making this explicit seems a bit
safer.

Re: [Qemu-devel] [PATCH 07/10] s390x/cpumodel: deflate

[Christian Borntraeger]

On 18.04.19 17:36, David Hildenbrand wrote:
> On 18.04.19 13:31, Christian Borntraeger wrote:
>> add the deflate conversion facility.
> 
> Nit:
> 
> "s390x/cpumodel: add Deflate-conversion facility"
> 
>>
>> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
>> ---
>>  target/s390x/cpu_features.c     |  9 +++++++++
>>  target/s390x/cpu_features.h     |  1 +
>>  target/s390x/cpu_features_def.h |  7 +++++++
>>  target/s390x/gen-features.c     | 12 ++++++++++++
>>  target/s390x/kvm.c              |  6 ++++++
>>  5 files changed, 35 insertions(+)
>>
>> diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
>> index e0a4769c19..5f37e655fe 100644
>> --- a/target/s390x/cpu_features.c
>> +++ b/target/s390x/cpu_features.c
>> @@ -110,6 +110,7 @@ static const S390FeatDef s390_features[] = {
>>      FEAT_INIT("cmmnt", S390_FEAT_TYPE_STFL, 147, "CMM: ESSA-enhancement (no translate) facility"),
>>      FEAT_INIT("vxeh2", S390_FEAT_TYPE_STFL, 148, "Vector Enhancements facility 2"),
>>      FEAT_INIT("esort-base", S390_FEAT_TYPE_STFL, 150, "Enhanced-sort facility (excluding subfunctions)"),
>> +    FEAT_INIT("deflate-base", S390_FEAT_TYPE_STFL, 151, "Deflate-conversion facility (excluding subfunctions)"),
>>      FEAT_INIT("vxbeh", S390_FEAT_TYPE_STFL, 152, "Vector BCD enhancements facility 1"),
>>      FEAT_INIT("msa9-base", S390_FEAT_TYPE_STFL, 155, "Message-security-assist-extension-9 facility (excluding subfunctions)"),
>>      FEAT_INIT("etoken", S390_FEAT_TYPE_STFL, 156, "Etoken facility"),
>> @@ -347,6 +348,11 @@ static const S390FeatDef s390_features[] = {
>>      FEAT_INIT("sortl-32", S390_FEAT_TYPE_SORTL, 130, "SORTL 32 input lists"),
>>      FEAT_INIT("sortl-128", S390_FEAT_TYPE_SORTL, 132, "SORTL 128 input lists"),
>>      FEAT_INIT("sortl-f0", S390_FEAT_TYPE_SORTL, 192, "SORTL format 0 parameter-block"),
>> +
>> +    FEAT_INIT("dfltcc-gdht", S390_FEAT_TYPE_DFLTCC, 1, "DFLTCC GDHT"),
>> +    FEAT_INIT("dfltcc-cmpr", S390_FEAT_TYPE_DFLTCC, 2, "DFLTCC CMPR"),
>> +    FEAT_INIT("dfltcc-xpnd", S390_FEAT_TYPE_DFLTCC, 4, "DFLTCC XPND"),
>> +    FEAT_INIT("dfltcc-f0", S390_FEAT_TYPE_DFLTCC, 192, "DFLTCC format 0 parameter-block"),
>>  };
> 
> Just wonder, "format 0 parameter-block" is actually a feature right,
> like "format 0 can be used". Can we hide format-0, IOW could that be
> like "query" and always supported? (especially due to backwards
> compatibility)

It hopefully will be there forever but since the CSSKE thing I would not
bet on that. So I see your point but making this explicit seems a bit
safer.

Re: [Qemu-devel] [PATCH 00/10] s390x: new guest features

[David Hildenbrand]

On 18.04.19 13:31, Christian Borntraeger wrote:
> Adding generation 15.
> 
> Some interesting aspects:
> - conditional SSKE and bpb are deprecated. This patch set addresses that
>   for csske.
> - no name yet for gen15, I suggest to use the assigned numbers and
>   provide an alias later on. (I have split out this into a separate
>   patch)
> 
> Christian Borntraeger (10):
>   linux header sync
>   s390x/cpumodel: remove CSSKE from base model
>   s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3
>   s390x/cpumodel: msa9 facility
>   s390x/cpumodel: vector enhancements
>   s390x/cpumodel: enhanced sort facility
>   s390x/cpumodel: deflate
>   s390x/cpumodel: add gen15 defintions
>   s390x/cpumodel: wire up 8561 and 8562 as gen15 machines
>   s390x/cpumodel: do not claim csske for expanded models in qmp
> 
>  hw/s390x/s390-virtio-ccw.c      |  6 +++
>  linux-headers/asm-s390/kvm.h    |  5 +-
>  target/s390x/cpu_features.c     | 54 +++++++++++++++++++
>  target/s390x/cpu_features.h     |  3 ++
>  target/s390x/cpu_features_def.h | 49 +++++++++++++++++
>  target/s390x/cpu_models.c       | 35 ++++++++++++
>  target/s390x/cpu_models.h       |  1 +
>  target/s390x/gen-features.c     | 94 ++++++++++++++++++++++++++++++++-
>  target/s390x/kvm.c              | 18 +++++++
>  9 files changed, 263 insertions(+), 2 deletions(-)
> 

I guess to handle deprecation of CSSKE:

1. Remove it from the base + default model of the gen15, keep it in the
max model. This is completely done in target/s390x/gen-features.c.
Existing base models are not modified.

2. Add CSSKE to "ignored_base_feat", so fallback of gen15 to e.g. z14
will work. We can backport this to distros/stable.


CPU model expansion:

cpu_info_from_model() should already properly be based on the base
features. "gen15" vs. "gen15,csske=on" should be automatically generated
when expanding.

CPU model baseline:

s390_find_cpu_def() should make sure that CSSKE is basically ignored
when determining maximum model, however it will properly be indicated if
both models had the feature.

CPU model comparison:

Should work as expected. Availability of CSSKE will be considered when
calculating the result.

gen14,csske=on and gen15,csske=off will result in
CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE.

gen14,csske=off and gen15,csske=off should result in
CPU_MODEL_COMPARE_RESULT_SUBSET

gen14,csske=on and gen15,csske=on should result in
CPU_MODEL_COMPARE_RESULT_SUBSET

Forward migration:

Now, the only issue is when csske is actually turned of in future
machines. We would e.g. have

gen15,csske=on and gen16,csske=off

While baselining will work correctly (gen15,csske=off), forward
migration is broken (comparison will properly indicate
CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE), which is expected when ripping
out features. Same applies to BPB.


Your patch "[PATCH 10/10] s390x/cpumodel: do not claim csske for
expanded models in qmp" tried to address this, however I am not really
happy with this approach. We should not play such tricks when expanding
the host model. "-cpu host" and "-cpu $expanded_host" would be
different, that is really confusing, especially think about baselining
or comparing against "host", where your patch does not apply..


Whenever users would specify "-cpu gen15", everything would be fine in
regards to forward migration. Maybe clients really have to be taught
about upcoming forward migration issues. "Don't use the host model, make
sure bpa and csske are disabled".

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH 00/10] s390x: new guest features

[David Hildenbrand]

On 18.04.19 13:31, Christian Borntraeger wrote:
> Adding generation 15.
> 
> Some interesting aspects:
> - conditional SSKE and bpb are deprecated. This patch set addresses that
>   for csske.
> - no name yet for gen15, I suggest to use the assigned numbers and
>   provide an alias later on. (I have split out this into a separate
>   patch)
> 
> Christian Borntraeger (10):
>   linux header sync
>   s390x/cpumodel: remove CSSKE from base model
>   s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3
>   s390x/cpumodel: msa9 facility
>   s390x/cpumodel: vector enhancements
>   s390x/cpumodel: enhanced sort facility
>   s390x/cpumodel: deflate
>   s390x/cpumodel: add gen15 defintions
>   s390x/cpumodel: wire up 8561 and 8562 as gen15 machines
>   s390x/cpumodel: do not claim csske for expanded models in qmp
> 
>  hw/s390x/s390-virtio-ccw.c      |  6 +++
>  linux-headers/asm-s390/kvm.h    |  5 +-
>  target/s390x/cpu_features.c     | 54 +++++++++++++++++++
>  target/s390x/cpu_features.h     |  3 ++
>  target/s390x/cpu_features_def.h | 49 +++++++++++++++++
>  target/s390x/cpu_models.c       | 35 ++++++++++++
>  target/s390x/cpu_models.h       |  1 +
>  target/s390x/gen-features.c     | 94 ++++++++++++++++++++++++++++++++-
>  target/s390x/kvm.c              | 18 +++++++
>  9 files changed, 263 insertions(+), 2 deletions(-)
> 

I guess to handle deprecation of CSSKE:

1. Remove it from the base + default model of the gen15, keep it in the
max model. This is completely done in target/s390x/gen-features.c.
Existing base models are not modified.

2. Add CSSKE to "ignored_base_feat", so fallback of gen15 to e.g. z14
will work. We can backport this to distros/stable.


CPU model expansion:

cpu_info_from_model() should already properly be based on the base
features. "gen15" vs. "gen15,csske=on" should be automatically generated
when expanding.

CPU model baseline:

s390_find_cpu_def() should make sure that CSSKE is basically ignored
when determining maximum model, however it will properly be indicated if
both models had the feature.

CPU model comparison:

Should work as expected. Availability of CSSKE will be considered when
calculating the result.

gen14,csske=on and gen15,csske=off will result in
CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE.

gen14,csske=off and gen15,csske=off should result in
CPU_MODEL_COMPARE_RESULT_SUBSET

gen14,csske=on and gen15,csske=on should result in
CPU_MODEL_COMPARE_RESULT_SUBSET

Forward migration:

Now, the only issue is when csske is actually turned of in future
machines. We would e.g. have

gen15,csske=on and gen16,csske=off

While baselining will work correctly (gen15,csske=off), forward
migration is broken (comparison will properly indicate
CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE), which is expected when ripping
out features. Same applies to BPB.


Your patch "[PATCH 10/10] s390x/cpumodel: do not claim csske for
expanded models in qmp" tried to address this, however I am not really
happy with this approach. We should not play such tricks when expanding
the host model. "-cpu host" and "-cpu $expanded_host" would be
different, that is really confusing, especially think about baselining
or comparing against "host", where your patch does not apply..


Whenever users would specify "-cpu gen15", everything would be fine in
regards to forward migration. Maybe clients really have to be taught
about upcoming forward migration issues. "Don't use the host model, make
sure bpa and csske are disabled".

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH 06/10] s390x/cpumodel: enhanced sort facility

[David Hildenbrand]

On 18.04.19 13:31, Christian Borntraeger wrote:
> add the enhanced sort facility.
> 
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
>  target/s390x/cpu_features.c     | 10 ++++++++++
>  target/s390x/cpu_features.h     |  1 +
>  target/s390x/cpu_features_def.h |  8 ++++++++
>  target/s390x/gen-features.c     | 14 ++++++++++++++
>  target/s390x/kvm.c              |  6 ++++++
>  5 files changed, 39 insertions(+)
> 
> diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
> index ed3f6aa969..e0a4769c19 100644
> --- a/target/s390x/cpu_features.c
> +++ b/target/s390x/cpu_features.c
> @@ -109,6 +109,7 @@ static const S390FeatDef s390_features[] = {
>      FEAT_INIT("msa8-base", S390_FEAT_TYPE_STFL, 146, "Message-security-assist-extension-8 facility (excluding subfunctions)"),
>      FEAT_INIT("cmmnt", S390_FEAT_TYPE_STFL, 147, "CMM: ESSA-enhancement (no translate) facility"),
>      FEAT_INIT("vxeh2", S390_FEAT_TYPE_STFL, 148, "Vector Enhancements facility 2"),
> +    FEAT_INIT("esort-base", S390_FEAT_TYPE_STFL, 150, "Enhanced-sort facility (excluding subfunctions)"),
>      FEAT_INIT("vxbeh", S390_FEAT_TYPE_STFL, 152, "Vector BCD enhancements facility 1"),
>      FEAT_INIT("msa9-base", S390_FEAT_TYPE_STFL, 155, "Message-security-assist-extension-9 facility (excluding subfunctions)"),
>      FEAT_INIT("etoken", S390_FEAT_TYPE_STFL, 156, "Etoken facility"),
> @@ -340,6 +341,12 @@ static const S390FeatDef s390_features[] = {
>      FEAT_INIT("kdsa-eddsa-sign-ed448", S390_FEAT_TYPE_KDSA, 44, "KDSA EdDSA-Sign-Ed448"),
>      FEAT_INIT("kdsa-eeddsa-sign-ed25519", S390_FEAT_TYPE_KDSA, 48, "KDSA Encrypted-EdDSA-Sign-Ed25519"),
>      FEAT_INIT("kdsa-eeddsa-sign-ed448", S390_FEAT_TYPE_KDSA, 52, "KDSA Encrypted-EdDSA-Sign-Ed448"),
> +
> +    FEAT_INIT("sortl-sflr", S390_FEAT_TYPE_SORTL, 1, "SORTL SFLR"),
> +    FEAT_INIT("sortl-svlr", S390_FEAT_TYPE_SORTL, 2, "SORTL SVLR"),
> +    FEAT_INIT("sortl-32", S390_FEAT_TYPE_SORTL, 130, "SORTL 32 input lists"),
> +    FEAT_INIT("sortl-128", S390_FEAT_TYPE_SORTL, 132, "SORTL 128 input lists"),
> +    FEAT_INIT("sortl-f0", S390_FEAT_TYPE_SORTL, 192, "SORTL format 0 parameter-block"),
>  };
>  
>  const S390FeatDef *s390_feat_def(S390Feat feat)
> @@ -403,6 +410,7 @@ void s390_fill_feat_block(const S390FeatBitmap features, S390FeatType type,
>      case S390_FEAT_TYPE_PPNO:
>      case S390_FEAT_TYPE_KMA:
>      case S390_FEAT_TYPE_KDSA:
> +    case S390_FEAT_TYPE_SORTL:
>          set_be_bit(0, data); /* query is always available */
>          break;
>      default:
> @@ -430,6 +438,7 @@ void s390_add_from_feat_block(S390FeatBitmap features, S390FeatType type,
>         nr_bits = 16384;
>         break;
>      case S390_FEAT_TYPE_PLO:
> +    case S390_FEAT_TYPE_SORTL:
>         nr_bits = 256;
>         break;
>      default:
> @@ -501,6 +510,7 @@ static S390FeatGroupDef s390_feature_groups[] = {
>      FEAT_GROUP_INIT("msa9", MSA_EXT_9, "Message-security-assist-extension 9 facility"),
>      FEAT_GROUP_INIT("msa9_pckmo", MSA_EXT_9_PCKMO, "Message-security-assist-extension 9 PCKMO subfunctions"),
>      FEAT_GROUP_INIT("mepochptff", MULTIPLE_EPOCH_PTFF, "PTFF enhancements introduced with Multiple-epoch facility"),
> +    FEAT_GROUP_INIT("esort", ENH_SORT, "Enhanced-sort facility"),
>  };
>  
>  const S390FeatGroupDef *s390_feat_group_def(S390FeatGroup group)
> diff --git a/target/s390x/cpu_features.h b/target/s390x/cpu_features.h
> index 5ffd3db083..3b8c5b25dd 100644
> --- a/target/s390x/cpu_features.h
> +++ b/target/s390x/cpu_features.h
> @@ -40,6 +40,7 @@ typedef enum {
>      S390_FEAT_TYPE_PPNO,
>      S390_FEAT_TYPE_KMA,
>      S390_FEAT_TYPE_KDSA,
> +    S390_FEAT_TYPE_SORTL,
>  } S390FeatType;
>  
>  /* Definition of a CPU feature */
> diff --git a/target/s390x/cpu_features_def.h b/target/s390x/cpu_features_def.h
> index ce2223c9d7..bb8585847f 100644
> --- a/target/s390x/cpu_features_def.h
> +++ b/target/s390x/cpu_features_def.h
> @@ -97,6 +97,7 @@ typedef enum {
>      S390_FEAT_MSA_EXT_8,
>      S390_FEAT_CMM_NT,
>      S390_FEAT_VECTOR_ENH2,
> +    S390_FEAT_ESORT_BASE,
>      S390_FEAT_VECTOR_BCD_ENH,
>      S390_FEAT_MSA_EXT_9,
>      S390_FEAT_ETOKEN,
> @@ -346,6 +347,13 @@ typedef enum {
>      S390_FEAT_EEDDSA_SIGN_ED25519,
>      S390_FEAT_EEDDSA_SIGN_ED448,
>  
> +    /* SORTL */
> +    S390_FEAT_SORTL_SFLR,
> +    S390_FEAT_SORTL_SVLR,
> +    S390_FEAT_SORTL_32,
> +    S390_FEAT_SORTL_128,
> +    S390_FEAT_SORTL_F0,
> +
>      S390_FEAT_MAX,
>  } S390Feat;
>  
> diff --git a/target/s390x/gen-features.c b/target/s390x/gen-features.c
> index 64fe850ff2..3db323fc0c 100644
> --- a/target/s390x/gen-features.c
> +++ b/target/s390x/gen-features.c
> @@ -245,6 +245,15 @@
>      S390_FEAT_PCKMO_ECC_ED25519, \
>      S390_FEAT_PCKMO_ECC_ED448
>  
> +#define S390_FEAT_GROUP_ENH_SORT \
> +    S390_FEAT_ESORT_BASE, \
> +    S390_FEAT_SORTL_SFLR, \
> +    S390_FEAT_SORTL_SVLR, \
> +    S390_FEAT_SORTL_32, \
> +    S390_FEAT_SORTL_128, \
> +    S390_FEAT_SORTL_F0
> +
> +
>  /* cpu feature groups */
>  static uint16_t group_PLO[] = {
>      S390_FEAT_GROUP_PLO,
> @@ -294,6 +303,10 @@ static uint16_t group_MSA_EXT_9_PCKMO[] = {
>      S390_FEAT_GROUP_MSA_EXT_9_PCKMO,
>  };
>  
> +static uint16_t group_ENH_SORT[] = {
> +    S390_FEAT_GROUP_ENH_SORT,
> +};
> +
>  /* Base features (in order of release)
>   * Only non-hypervisor managed features belong here.
>   * Base feature sets are static meaning they do not change in future QEMU
> @@ -751,6 +764,7 @@ static FeatGroupDefSpec FeatGroupDef[] = {
>      FEAT_GROUP_INITIALIZER(MSA_EXT_9),
>      FEAT_GROUP_INITIALIZER(MSA_EXT_9_PCKMO),
>      FEAT_GROUP_INITIALIZER(MULTIPLE_EPOCH_PTFF),
> +    FEAT_GROUP_INITIALIZER(ENH_SORT),
>  };
>  
>  #define QEMU_FEAT_INITIALIZER(_name)                   \
> diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
> index 88cef3476c..7681492c41 100644
> --- a/target/s390x/kvm.c
> +++ b/target/s390x/kvm.c
> @@ -2083,6 +2083,9 @@ static int query_cpu_subfunc(S390FeatBitmap features)
>      if (test_bit(S390_FEAT_MSA_EXT_9, features)) {
>          s390_add_from_feat_block(features, S390_FEAT_TYPE_KDSA, prop.kdsa);
>      }
> +    if (test_bit(S390_FEAT_ESORT_BASE, features)) {
> +        s390_add_from_feat_block(features, S390_FEAT_TYPE_SORTL, prop.sortl);
> +    }
>      return 0;
>  }
>  
> @@ -2130,6 +2133,9 @@ static int configure_cpu_subfunc(const S390FeatBitmap features)
>      if (test_bit(S390_FEAT_MSA_EXT_9, features)) {
>          s390_fill_feat_block(features, S390_FEAT_TYPE_KDSA, prop.kdsa);
>      }
> +    if (test_bit(S390_FEAT_ESORT_BASE, features)) {
> +        s390_fill_feat_block(features, S390_FEAT_TYPE_SORTL, prop.sortl);
> +    }
>      return kvm_vm_ioctl(kvm_state, KVM_SET_DEVICE_ATTR, &attr);
>  }
>  
> 

Reviewed-by: David Hildenbrand <david@redhat.com>

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH 06/10] s390x/cpumodel: enhanced sort facility

[David Hildenbrand]

On 18.04.19 13:31, Christian Borntraeger wrote:
> add the enhanced sort facility.
> 
> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
> ---
>  target/s390x/cpu_features.c     | 10 ++++++++++
>  target/s390x/cpu_features.h     |  1 +
>  target/s390x/cpu_features_def.h |  8 ++++++++
>  target/s390x/gen-features.c     | 14 ++++++++++++++
>  target/s390x/kvm.c              |  6 ++++++
>  5 files changed, 39 insertions(+)
> 
> diff --git a/target/s390x/cpu_features.c b/target/s390x/cpu_features.c
> index ed3f6aa969..e0a4769c19 100644
> --- a/target/s390x/cpu_features.c
> +++ b/target/s390x/cpu_features.c
> @@ -109,6 +109,7 @@ static const S390FeatDef s390_features[] = {
>      FEAT_INIT("msa8-base", S390_FEAT_TYPE_STFL, 146, "Message-security-assist-extension-8 facility (excluding subfunctions)"),
>      FEAT_INIT("cmmnt", S390_FEAT_TYPE_STFL, 147, "CMM: ESSA-enhancement (no translate) facility"),
>      FEAT_INIT("vxeh2", S390_FEAT_TYPE_STFL, 148, "Vector Enhancements facility 2"),
> +    FEAT_INIT("esort-base", S390_FEAT_TYPE_STFL, 150, "Enhanced-sort facility (excluding subfunctions)"),
>      FEAT_INIT("vxbeh", S390_FEAT_TYPE_STFL, 152, "Vector BCD enhancements facility 1"),
>      FEAT_INIT("msa9-base", S390_FEAT_TYPE_STFL, 155, "Message-security-assist-extension-9 facility (excluding subfunctions)"),
>      FEAT_INIT("etoken", S390_FEAT_TYPE_STFL, 156, "Etoken facility"),
> @@ -340,6 +341,12 @@ static const S390FeatDef s390_features[] = {
>      FEAT_INIT("kdsa-eddsa-sign-ed448", S390_FEAT_TYPE_KDSA, 44, "KDSA EdDSA-Sign-Ed448"),
>      FEAT_INIT("kdsa-eeddsa-sign-ed25519", S390_FEAT_TYPE_KDSA, 48, "KDSA Encrypted-EdDSA-Sign-Ed25519"),
>      FEAT_INIT("kdsa-eeddsa-sign-ed448", S390_FEAT_TYPE_KDSA, 52, "KDSA Encrypted-EdDSA-Sign-Ed448"),
> +
> +    FEAT_INIT("sortl-sflr", S390_FEAT_TYPE_SORTL, 1, "SORTL SFLR"),
> +    FEAT_INIT("sortl-svlr", S390_FEAT_TYPE_SORTL, 2, "SORTL SVLR"),
> +    FEAT_INIT("sortl-32", S390_FEAT_TYPE_SORTL, 130, "SORTL 32 input lists"),
> +    FEAT_INIT("sortl-128", S390_FEAT_TYPE_SORTL, 132, "SORTL 128 input lists"),
> +    FEAT_INIT("sortl-f0", S390_FEAT_TYPE_SORTL, 192, "SORTL format 0 parameter-block"),
>  };
>  
>  const S390FeatDef *s390_feat_def(S390Feat feat)
> @@ -403,6 +410,7 @@ void s390_fill_feat_block(const S390FeatBitmap features, S390FeatType type,
>      case S390_FEAT_TYPE_PPNO:
>      case S390_FEAT_TYPE_KMA:
>      case S390_FEAT_TYPE_KDSA:
> +    case S390_FEAT_TYPE_SORTL:
>          set_be_bit(0, data); /* query is always available */
>          break;
>      default:
> @@ -430,6 +438,7 @@ void s390_add_from_feat_block(S390FeatBitmap features, S390FeatType type,
>         nr_bits = 16384;
>         break;
>      case S390_FEAT_TYPE_PLO:
> +    case S390_FEAT_TYPE_SORTL:
>         nr_bits = 256;
>         break;
>      default:
> @@ -501,6 +510,7 @@ static S390FeatGroupDef s390_feature_groups[] = {
>      FEAT_GROUP_INIT("msa9", MSA_EXT_9, "Message-security-assist-extension 9 facility"),
>      FEAT_GROUP_INIT("msa9_pckmo", MSA_EXT_9_PCKMO, "Message-security-assist-extension 9 PCKMO subfunctions"),
>      FEAT_GROUP_INIT("mepochptff", MULTIPLE_EPOCH_PTFF, "PTFF enhancements introduced with Multiple-epoch facility"),
> +    FEAT_GROUP_INIT("esort", ENH_SORT, "Enhanced-sort facility"),
>  };
>  
>  const S390FeatGroupDef *s390_feat_group_def(S390FeatGroup group)
> diff --git a/target/s390x/cpu_features.h b/target/s390x/cpu_features.h
> index 5ffd3db083..3b8c5b25dd 100644
> --- a/target/s390x/cpu_features.h
> +++ b/target/s390x/cpu_features.h
> @@ -40,6 +40,7 @@ typedef enum {
>      S390_FEAT_TYPE_PPNO,
>      S390_FEAT_TYPE_KMA,
>      S390_FEAT_TYPE_KDSA,
> +    S390_FEAT_TYPE_SORTL,
>  } S390FeatType;
>  
>  /* Definition of a CPU feature */
> diff --git a/target/s390x/cpu_features_def.h b/target/s390x/cpu_features_def.h
> index ce2223c9d7..bb8585847f 100644
> --- a/target/s390x/cpu_features_def.h
> +++ b/target/s390x/cpu_features_def.h
> @@ -97,6 +97,7 @@ typedef enum {
>      S390_FEAT_MSA_EXT_8,
>      S390_FEAT_CMM_NT,
>      S390_FEAT_VECTOR_ENH2,
> +    S390_FEAT_ESORT_BASE,
>      S390_FEAT_VECTOR_BCD_ENH,
>      S390_FEAT_MSA_EXT_9,
>      S390_FEAT_ETOKEN,
> @@ -346,6 +347,13 @@ typedef enum {
>      S390_FEAT_EEDDSA_SIGN_ED25519,
>      S390_FEAT_EEDDSA_SIGN_ED448,
>  
> +    /* SORTL */
> +    S390_FEAT_SORTL_SFLR,
> +    S390_FEAT_SORTL_SVLR,
> +    S390_FEAT_SORTL_32,
> +    S390_FEAT_SORTL_128,
> +    S390_FEAT_SORTL_F0,
> +
>      S390_FEAT_MAX,
>  } S390Feat;
>  
> diff --git a/target/s390x/gen-features.c b/target/s390x/gen-features.c
> index 64fe850ff2..3db323fc0c 100644
> --- a/target/s390x/gen-features.c
> +++ b/target/s390x/gen-features.c
> @@ -245,6 +245,15 @@
>      S390_FEAT_PCKMO_ECC_ED25519, \
>      S390_FEAT_PCKMO_ECC_ED448
>  
> +#define S390_FEAT_GROUP_ENH_SORT \
> +    S390_FEAT_ESORT_BASE, \
> +    S390_FEAT_SORTL_SFLR, \
> +    S390_FEAT_SORTL_SVLR, \
> +    S390_FEAT_SORTL_32, \
> +    S390_FEAT_SORTL_128, \
> +    S390_FEAT_SORTL_F0
> +
> +
>  /* cpu feature groups */
>  static uint16_t group_PLO[] = {
>      S390_FEAT_GROUP_PLO,
> @@ -294,6 +303,10 @@ static uint16_t group_MSA_EXT_9_PCKMO[] = {
>      S390_FEAT_GROUP_MSA_EXT_9_PCKMO,
>  };
>  
> +static uint16_t group_ENH_SORT[] = {
> +    S390_FEAT_GROUP_ENH_SORT,
> +};
> +
>  /* Base features (in order of release)
>   * Only non-hypervisor managed features belong here.
>   * Base feature sets are static meaning they do not change in future QEMU
> @@ -751,6 +764,7 @@ static FeatGroupDefSpec FeatGroupDef[] = {
>      FEAT_GROUP_INITIALIZER(MSA_EXT_9),
>      FEAT_GROUP_INITIALIZER(MSA_EXT_9_PCKMO),
>      FEAT_GROUP_INITIALIZER(MULTIPLE_EPOCH_PTFF),
> +    FEAT_GROUP_INITIALIZER(ENH_SORT),
>  };
>  
>  #define QEMU_FEAT_INITIALIZER(_name)                   \
> diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
> index 88cef3476c..7681492c41 100644
> --- a/target/s390x/kvm.c
> +++ b/target/s390x/kvm.c
> @@ -2083,6 +2083,9 @@ static int query_cpu_subfunc(S390FeatBitmap features)
>      if (test_bit(S390_FEAT_MSA_EXT_9, features)) {
>          s390_add_from_feat_block(features, S390_FEAT_TYPE_KDSA, prop.kdsa);
>      }
> +    if (test_bit(S390_FEAT_ESORT_BASE, features)) {
> +        s390_add_from_feat_block(features, S390_FEAT_TYPE_SORTL, prop.sortl);
> +    }
>      return 0;
>  }
>  
> @@ -2130,6 +2133,9 @@ static int configure_cpu_subfunc(const S390FeatBitmap features)
>      if (test_bit(S390_FEAT_MSA_EXT_9, features)) {
>          s390_fill_feat_block(features, S390_FEAT_TYPE_KDSA, prop.kdsa);
>      }
> +    if (test_bit(S390_FEAT_ESORT_BASE, features)) {
> +        s390_fill_feat_block(features, S390_FEAT_TYPE_SORTL, prop.sortl);
> +    }
>      return kvm_vm_ioctl(kvm_state, KVM_SET_DEVICE_ATTR, &attr);
>  }
>  
> 

Reviewed-by: David Hildenbrand <david@redhat.com>

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH 00/10] s390x: new guest features

[Christian Borntraeger]

On 23.04.19 14:11, David Hildenbrand wrote:
> On 18.04.19 13:31, Christian Borntraeger wrote:
>> Adding generation 15.
>>
>> Some interesting aspects:
>> - conditional SSKE and bpb are deprecated. This patch set addresses that
>>   for csske.
>> - no name yet for gen15, I suggest to use the assigned numbers and
>>   provide an alias later on. (I have split out this into a separate
>>   patch)
>>
>> Christian Borntraeger (10):
>>   linux header sync
>>   s390x/cpumodel: remove CSSKE from base model
>>   s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3
>>   s390x/cpumodel: msa9 facility
>>   s390x/cpumodel: vector enhancements
>>   s390x/cpumodel: enhanced sort facility
>>   s390x/cpumodel: deflate
>>   s390x/cpumodel: add gen15 defintions
>>   s390x/cpumodel: wire up 8561 and 8562 as gen15 machines
>>   s390x/cpumodel: do not claim csske for expanded models in qmp
>>
>>  hw/s390x/s390-virtio-ccw.c      |  6 +++
>>  linux-headers/asm-s390/kvm.h    |  5 +-
>>  target/s390x/cpu_features.c     | 54 +++++++++++++++++++
>>  target/s390x/cpu_features.h     |  3 ++
>>  target/s390x/cpu_features_def.h | 49 +++++++++++++++++
>>  target/s390x/cpu_models.c       | 35 ++++++++++++
>>  target/s390x/cpu_models.h       |  1 +
>>  target/s390x/gen-features.c     | 94 ++++++++++++++++++++++++++++++++-
>>  target/s390x/kvm.c              | 18 +++++++
>>  9 files changed, 263 insertions(+), 2 deletions(-)
>>
> 
> I guess to handle deprecation of CSSKE:
> 
> 1. Remove it from the base + default model of the gen15, keep it in the
> max model. This is completely done in target/s390x/gen-features.c.
> Existing base models are not modified.
> 
> 2. Add CSSKE to "ignored_base_feat", so fallback of gen15 to e.g. z14
> will work. We can backport this to distros/stable.

Yes, I have already implemented that, still doing some testing and polishinh.
> 
> 
> CPU model expansion:
> 
> cpu_info_from_model() should already properly be based on the base
> features. "gen15" vs. "gen15,csske=on" should be automatically generated
> when expanding.
> 
> CPU model baseline:
> 
> s390_find_cpu_def() should make sure that CSSKE is basically ignored
> when determining maximum model, however it will properly be indicated if
> both models had the feature.
> 
> CPU model comparison:
> 
> Should work as expected. Availability of CSSKE will be considered when
> calculating the result.
> 
> gen14,csske=on and gen15,csske=off will result in
> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE.
> 
> gen14,csske=off and gen15,csske=off should result in
> CPU_MODEL_COMPARE_RESULT_SUBSET
> 
> gen14,csske=on and gen15,csske=on should result in
> CPU_MODEL_COMPARE_RESULT_SUBSET
> 
> Forward migration:
> 
> Now, the only issue is when csske is actually turned of in future
> machines. We would e.g. have
> 
> gen15,csske=on and gen16,csske=off
> 
> While baselining will work correctly (gen15,csske=off), forward
> migration is broken (comparison will properly indicate
> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE), which is expected when ripping
> out features. Same applies to BPB.
> 
> 
> Your patch "[PATCH 10/10] s390x/cpumodel: do not claim csske for
> expanded models in qmp" tried to address this, however I am not really
> happy with this approach. We should not play such tricks when expanding
> the host model. "-cpu host" and "-cpu $expanded_host" would be
> different,

We discussed this some time ago and I think we agreed that for host passthrough
it is ok to be different that host-model (e.g. passing through the cpuid, passing
through all non-hypervisor managed features etc).


> that is really confusing, especially think about baselining
> or comparing against "host", where your patch does not apply..
> 
> 
> Whenever users would specify "-cpu gen15", everything would be fine in
> regards to forward migration. Maybe clients really have to be taught
> about upcoming forward migration issues. "Don't use the host model, make
> sure bpa and csske are disabled".


the thing is, I think the host-model is actually the preferred setting so I
would like to have this forward-migrateable as well. I will focus on patches
1-9 first and lets have a side discussion on patch 10.

Re: [Qemu-devel] [PATCH 00/10] s390x: new guest features

[Christian Borntraeger]

On 23.04.19 14:11, David Hildenbrand wrote:
> On 18.04.19 13:31, Christian Borntraeger wrote:
>> Adding generation 15.
>>
>> Some interesting aspects:
>> - conditional SSKE and bpb are deprecated. This patch set addresses that
>>   for csske.
>> - no name yet for gen15, I suggest to use the assigned numbers and
>>   provide an alias later on. (I have split out this into a separate
>>   patch)
>>
>> Christian Borntraeger (10):
>>   linux header sync
>>   s390x/cpumodel: remove CSSKE from base model
>>   s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3
>>   s390x/cpumodel: msa9 facility
>>   s390x/cpumodel: vector enhancements
>>   s390x/cpumodel: enhanced sort facility
>>   s390x/cpumodel: deflate
>>   s390x/cpumodel: add gen15 defintions
>>   s390x/cpumodel: wire up 8561 and 8562 as gen15 machines
>>   s390x/cpumodel: do not claim csske for expanded models in qmp
>>
>>  hw/s390x/s390-virtio-ccw.c      |  6 +++
>>  linux-headers/asm-s390/kvm.h    |  5 +-
>>  target/s390x/cpu_features.c     | 54 +++++++++++++++++++
>>  target/s390x/cpu_features.h     |  3 ++
>>  target/s390x/cpu_features_def.h | 49 +++++++++++++++++
>>  target/s390x/cpu_models.c       | 35 ++++++++++++
>>  target/s390x/cpu_models.h       |  1 +
>>  target/s390x/gen-features.c     | 94 ++++++++++++++++++++++++++++++++-
>>  target/s390x/kvm.c              | 18 +++++++
>>  9 files changed, 263 insertions(+), 2 deletions(-)
>>
> 
> I guess to handle deprecation of CSSKE:
> 
> 1. Remove it from the base + default model of the gen15, keep it in the
> max model. This is completely done in target/s390x/gen-features.c.
> Existing base models are not modified.
> 
> 2. Add CSSKE to "ignored_base_feat", so fallback of gen15 to e.g. z14
> will work. We can backport this to distros/stable.

Yes, I have already implemented that, still doing some testing and polishinh.
> 
> 
> CPU model expansion:
> 
> cpu_info_from_model() should already properly be based on the base
> features. "gen15" vs. "gen15,csske=on" should be automatically generated
> when expanding.
> 
> CPU model baseline:
> 
> s390_find_cpu_def() should make sure that CSSKE is basically ignored
> when determining maximum model, however it will properly be indicated if
> both models had the feature.
> 
> CPU model comparison:
> 
> Should work as expected. Availability of CSSKE will be considered when
> calculating the result.
> 
> gen14,csske=on and gen15,csske=off will result in
> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE.
> 
> gen14,csske=off and gen15,csske=off should result in
> CPU_MODEL_COMPARE_RESULT_SUBSET
> 
> gen14,csske=on and gen15,csske=on should result in
> CPU_MODEL_COMPARE_RESULT_SUBSET
> 
> Forward migration:
> 
> Now, the only issue is when csske is actually turned of in future
> machines. We would e.g. have
> 
> gen15,csske=on and gen16,csske=off
> 
> While baselining will work correctly (gen15,csske=off), forward
> migration is broken (comparison will properly indicate
> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE), which is expected when ripping
> out features. Same applies to BPB.
> 
> 
> Your patch "[PATCH 10/10] s390x/cpumodel: do not claim csske for
> expanded models in qmp" tried to address this, however I am not really
> happy with this approach. We should not play such tricks when expanding
> the host model. "-cpu host" and "-cpu $expanded_host" would be
> different,

We discussed this some time ago and I think we agreed that for host passthrough
it is ok to be different that host-model (e.g. passing through the cpuid, passing
through all non-hypervisor managed features etc).


> that is really confusing, especially think about baselining
> or comparing against "host", where your patch does not apply..
> 
> 
> Whenever users would specify "-cpu gen15", everything would be fine in
> regards to forward migration. Maybe clients really have to be taught
> about upcoming forward migration issues. "Don't use the host model, make
> sure bpa and csske are disabled".


the thing is, I think the host-model is actually the preferred setting so I
would like to have this forward-migrateable as well. I will focus on patches
1-9 first and lets have a side discussion on patch 10.

Re: [Qemu-devel] [PATCH 00/10] s390x: new guest features

[David Hildenbrand]

On 24.04.19 10:40, Christian Borntraeger wrote:
> 
> 
> On 23.04.19 14:11, David Hildenbrand wrote:
>> On 18.04.19 13:31, Christian Borntraeger wrote:
>>> Adding generation 15.
>>>
>>> Some interesting aspects:
>>> - conditional SSKE and bpb are deprecated. This patch set addresses that
>>>   for csske.
>>> - no name yet for gen15, I suggest to use the assigned numbers and
>>>   provide an alias later on. (I have split out this into a separate
>>>   patch)
>>>
>>> Christian Borntraeger (10):
>>>   linux header sync
>>>   s390x/cpumodel: remove CSSKE from base model
>>>   s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3
>>>   s390x/cpumodel: msa9 facility
>>>   s390x/cpumodel: vector enhancements
>>>   s390x/cpumodel: enhanced sort facility
>>>   s390x/cpumodel: deflate
>>>   s390x/cpumodel: add gen15 defintions
>>>   s390x/cpumodel: wire up 8561 and 8562 as gen15 machines
>>>   s390x/cpumodel: do not claim csske for expanded models in qmp
>>>
>>>  hw/s390x/s390-virtio-ccw.c      |  6 +++
>>>  linux-headers/asm-s390/kvm.h    |  5 +-
>>>  target/s390x/cpu_features.c     | 54 +++++++++++++++++++
>>>  target/s390x/cpu_features.h     |  3 ++
>>>  target/s390x/cpu_features_def.h | 49 +++++++++++++++++
>>>  target/s390x/cpu_models.c       | 35 ++++++++++++
>>>  target/s390x/cpu_models.h       |  1 +
>>>  target/s390x/gen-features.c     | 94 ++++++++++++++++++++++++++++++++-
>>>  target/s390x/kvm.c              | 18 +++++++
>>>  9 files changed, 263 insertions(+), 2 deletions(-)
>>>
>>
>> I guess to handle deprecation of CSSKE:
>>
>> 1. Remove it from the base + default model of the gen15, keep it in the
>> max model. This is completely done in target/s390x/gen-features.c.
>> Existing base models are not modified.
>>
>> 2. Add CSSKE to "ignored_base_feat", so fallback of gen15 to e.g. z14
>> will work. We can backport this to distros/stable.
> 
> Yes, I have already implemented that, still doing some testing and polishinh.
>>
>>
>> CPU model expansion:
>>
>> cpu_info_from_model() should already properly be based on the base
>> features. "gen15" vs. "gen15,csske=on" should be automatically generated
>> when expanding.
>>
>> CPU model baseline:
>>
>> s390_find_cpu_def() should make sure that CSSKE is basically ignored
>> when determining maximum model, however it will properly be indicated if
>> both models had the feature.
>>
>> CPU model comparison:
>>
>> Should work as expected. Availability of CSSKE will be considered when
>> calculating the result.
>>
>> gen14,csske=on and gen15,csske=off will result in
>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE.
>>
>> gen14,csske=off and gen15,csske=off should result in
>> CPU_MODEL_COMPARE_RESULT_SUBSET
>>
>> gen14,csske=on and gen15,csske=on should result in
>> CPU_MODEL_COMPARE_RESULT_SUBSET
>>
>> Forward migration:
>>
>> Now, the only issue is when csske is actually turned of in future
>> machines. We would e.g. have
>>
>> gen15,csske=on and gen16,csske=off
>>
>> While baselining will work correctly (gen15,csske=off), forward
>> migration is broken (comparison will properly indicate
>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE), which is expected when ripping
>> out features. Same applies to BPB.
>>
>>
>> Your patch "[PATCH 10/10] s390x/cpumodel: do not claim csske for
>> expanded models in qmp" tried to address this, however I am not really
>> happy with this approach. We should not play such tricks when expanding
>> the host model. "-cpu host" and "-cpu $expanded_host" would be
>> different,
> 
> We discussed this some time ago and I think we agreed that for host passthrough
> it is ok to be different that host-model (e.g. passing through the cpuid, passing
> through all non-hypervisor managed features etc).

I remember the plan was to use the "max" model to do such stuff. E.g.
-cpu max / no -cpu

Versus
-cpu host

We can have features in "host" we don't have in "max". But "-cpu host"
and it's expansion should look 100% the same.

> 
> 
>> that is really confusing, especially think about baselining
>> or comparing against "host", where your patch does not apply..
>>
>>
>> Whenever users would specify "-cpu gen15", everything would be fine in
>> regards to forward migration. Maybe clients really have to be taught
>> about upcoming forward migration issues. "Don't use the host model, make
>> sure bpa and csske are disabled".
> 
> 
> the thing is, I think the host-model is actually the preferred setting so I
> would like to have this forward-migrateable as well. I will focus on patches
> 1-9 first and lets have a side discussion on patch 10.
> 

Makes sense. This is also something that can be fixed on higher layers
(disable cpu feature for gen15 to prepare for migration).

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH 00/10] s390x: new guest features

[David Hildenbrand]

On 24.04.19 10:40, Christian Borntraeger wrote:
> 
> 
> On 23.04.19 14:11, David Hildenbrand wrote:
>> On 18.04.19 13:31, Christian Borntraeger wrote:
>>> Adding generation 15.
>>>
>>> Some interesting aspects:
>>> - conditional SSKE and bpb are deprecated. This patch set addresses that
>>>   for csske.
>>> - no name yet for gen15, I suggest to use the assigned numbers and
>>>   provide an alias later on. (I have split out this into a separate
>>>   patch)
>>>
>>> Christian Borntraeger (10):
>>>   linux header sync
>>>   s390x/cpumodel: remove CSSKE from base model
>>>   s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3
>>>   s390x/cpumodel: msa9 facility
>>>   s390x/cpumodel: vector enhancements
>>>   s390x/cpumodel: enhanced sort facility
>>>   s390x/cpumodel: deflate
>>>   s390x/cpumodel: add gen15 defintions
>>>   s390x/cpumodel: wire up 8561 and 8562 as gen15 machines
>>>   s390x/cpumodel: do not claim csske for expanded models in qmp
>>>
>>>  hw/s390x/s390-virtio-ccw.c      |  6 +++
>>>  linux-headers/asm-s390/kvm.h    |  5 +-
>>>  target/s390x/cpu_features.c     | 54 +++++++++++++++++++
>>>  target/s390x/cpu_features.h     |  3 ++
>>>  target/s390x/cpu_features_def.h | 49 +++++++++++++++++
>>>  target/s390x/cpu_models.c       | 35 ++++++++++++
>>>  target/s390x/cpu_models.h       |  1 +
>>>  target/s390x/gen-features.c     | 94 ++++++++++++++++++++++++++++++++-
>>>  target/s390x/kvm.c              | 18 +++++++
>>>  9 files changed, 263 insertions(+), 2 deletions(-)
>>>
>>
>> I guess to handle deprecation of CSSKE:
>>
>> 1. Remove it from the base + default model of the gen15, keep it in the
>> max model. This is completely done in target/s390x/gen-features.c.
>> Existing base models are not modified.
>>
>> 2. Add CSSKE to "ignored_base_feat", so fallback of gen15 to e.g. z14
>> will work. We can backport this to distros/stable.
> 
> Yes, I have already implemented that, still doing some testing and polishinh.
>>
>>
>> CPU model expansion:
>>
>> cpu_info_from_model() should already properly be based on the base
>> features. "gen15" vs. "gen15,csske=on" should be automatically generated
>> when expanding.
>>
>> CPU model baseline:
>>
>> s390_find_cpu_def() should make sure that CSSKE is basically ignored
>> when determining maximum model, however it will properly be indicated if
>> both models had the feature.
>>
>> CPU model comparison:
>>
>> Should work as expected. Availability of CSSKE will be considered when
>> calculating the result.
>>
>> gen14,csske=on and gen15,csske=off will result in
>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE.
>>
>> gen14,csske=off and gen15,csske=off should result in
>> CPU_MODEL_COMPARE_RESULT_SUBSET
>>
>> gen14,csske=on and gen15,csske=on should result in
>> CPU_MODEL_COMPARE_RESULT_SUBSET
>>
>> Forward migration:
>>
>> Now, the only issue is when csske is actually turned of in future
>> machines. We would e.g. have
>>
>> gen15,csske=on and gen16,csske=off
>>
>> While baselining will work correctly (gen15,csske=off), forward
>> migration is broken (comparison will properly indicate
>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE), which is expected when ripping
>> out features. Same applies to BPB.
>>
>>
>> Your patch "[PATCH 10/10] s390x/cpumodel: do not claim csske for
>> expanded models in qmp" tried to address this, however I am not really
>> happy with this approach. We should not play such tricks when expanding
>> the host model. "-cpu host" and "-cpu $expanded_host" would be
>> different,
> 
> We discussed this some time ago and I think we agreed that for host passthrough
> it is ok to be different that host-model (e.g. passing through the cpuid, passing
> through all non-hypervisor managed features etc).

I remember the plan was to use the "max" model to do such stuff. E.g.
-cpu max / no -cpu

Versus
-cpu host

We can have features in "host" we don't have in "max". But "-cpu host"
and it's expansion should look 100% the same.

> 
> 
>> that is really confusing, especially think about baselining
>> or comparing against "host", where your patch does not apply..
>>
>>
>> Whenever users would specify "-cpu gen15", everything would be fine in
>> regards to forward migration. Maybe clients really have to be taught
>> about upcoming forward migration issues. "Don't use the host model, make
>> sure bpa and csske are disabled".
> 
> 
> the thing is, I think the host-model is actually the preferred setting so I
> would like to have this forward-migrateable as well. I will focus on patches
> 1-9 first and lets have a side discussion on patch 10.
> 

Makes sense. This is also something that can be fixed on higher layers
(disable cpu feature for gen15 to prepare for migration).

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH 00/10] s390x: new guest features

[Daniel P. Berrangé]

On Wed, Apr 24, 2019 at 11:03:03AM +0200, David Hildenbrand wrote:
> On 24.04.19 10:40, Christian Borntraeger wrote:
> > 
> > 
> > On 23.04.19 14:11, David Hildenbrand wrote:
> >> On 18.04.19 13:31, Christian Borntraeger wrote:
> >>> Adding generation 15.
> >>>
> >>> Some interesting aspects:
> >>> - conditional SSKE and bpb are deprecated. This patch set addresses that
> >>>   for csske.
> >>> - no name yet for gen15, I suggest to use the assigned numbers and
> >>>   provide an alias later on. (I have split out this into a separate
> >>>   patch)
> >>>
> >>> Christian Borntraeger (10):
> >>>   linux header sync
> >>>   s390x/cpumodel: remove CSSKE from base model
> >>>   s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3
> >>>   s390x/cpumodel: msa9 facility
> >>>   s390x/cpumodel: vector enhancements
> >>>   s390x/cpumodel: enhanced sort facility
> >>>   s390x/cpumodel: deflate
> >>>   s390x/cpumodel: add gen15 defintions
> >>>   s390x/cpumodel: wire up 8561 and 8562 as gen15 machines
> >>>   s390x/cpumodel: do not claim csske for expanded models in qmp
> >>>
> >>>  hw/s390x/s390-virtio-ccw.c      |  6 +++
> >>>  linux-headers/asm-s390/kvm.h    |  5 +-
> >>>  target/s390x/cpu_features.c     | 54 +++++++++++++++++++
> >>>  target/s390x/cpu_features.h     |  3 ++
> >>>  target/s390x/cpu_features_def.h | 49 +++++++++++++++++
> >>>  target/s390x/cpu_models.c       | 35 ++++++++++++
> >>>  target/s390x/cpu_models.h       |  1 +
> >>>  target/s390x/gen-features.c     | 94 ++++++++++++++++++++++++++++++++-
> >>>  target/s390x/kvm.c              | 18 +++++++
> >>>  9 files changed, 263 insertions(+), 2 deletions(-)
> >>>
> >>
> >> I guess to handle deprecation of CSSKE:
> >>
> >> 1. Remove it from the base + default model of the gen15, keep it in the
> >> max model. This is completely done in target/s390x/gen-features.c.
> >> Existing base models are not modified.
> >>
> >> 2. Add CSSKE to "ignored_base_feat", so fallback of gen15 to e.g. z14
> >> will work. We can backport this to distros/stable.
> > 
> > Yes, I have already implemented that, still doing some testing and polishinh.
> >>
> >>
> >> CPU model expansion:
> >>
> >> cpu_info_from_model() should already properly be based on the base
> >> features. "gen15" vs. "gen15,csske=on" should be automatically generated
> >> when expanding.
> >>
> >> CPU model baseline:
> >>
> >> s390_find_cpu_def() should make sure that CSSKE is basically ignored
> >> when determining maximum model, however it will properly be indicated if
> >> both models had the feature.
> >>
> >> CPU model comparison:
> >>
> >> Should work as expected. Availability of CSSKE will be considered when
> >> calculating the result.
> >>
> >> gen14,csske=on and gen15,csske=off will result in
> >> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE.
> >>
> >> gen14,csske=off and gen15,csske=off should result in
> >> CPU_MODEL_COMPARE_RESULT_SUBSET
> >>
> >> gen14,csske=on and gen15,csske=on should result in
> >> CPU_MODEL_COMPARE_RESULT_SUBSET
> >>
> >> Forward migration:
> >>
> >> Now, the only issue is when csske is actually turned of in future
> >> machines. We would e.g. have
> >>
> >> gen15,csske=on and gen16,csske=off
> >>
> >> While baselining will work correctly (gen15,csske=off), forward
> >> migration is broken (comparison will properly indicate
> >> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE), which is expected when ripping
> >> out features. Same applies to BPB.
> >>
> >>
> >> Your patch "[PATCH 10/10] s390x/cpumodel: do not claim csske for
> >> expanded models in qmp" tried to address this, however I am not really
> >> happy with this approach. We should not play such tricks when expanding
> >> the host model. "-cpu host" and "-cpu $expanded_host" would be
> >> different,
> > 
> > We discussed this some time ago and I think we agreed that for host passthrough
> > it is ok to be different that host-model (e.g. passing through the cpuid, passing
> > through all non-hypervisor managed features etc).
> 
> I remember the plan was to use the "max" model to do such stuff. E.g.
> -cpu max / no -cpu
> 
> Versus
> -cpu host
> 
> We can have features in "host" we don't have in "max". But "-cpu host"
> and it's expansion should look 100% the same.

I don't think that's the intended semantics of "max" vs "host".

The "max" CPU model is supposed to enable all features that are possible to
enable.

For KVM, thus "max" should be identical to "host".

For TCG, "max" should be everything that QEMU currently knows how to emulate.

Essentially think of "max" as a better name for "host", since "host" as
a name concept didn't make sense for TCG.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [PATCH 00/10] s390x: new guest features

[Daniel P. Berrangé]

On Wed, Apr 24, 2019 at 11:03:03AM +0200, David Hildenbrand wrote:
> On 24.04.19 10:40, Christian Borntraeger wrote:
> > 
> > 
> > On 23.04.19 14:11, David Hildenbrand wrote:
> >> On 18.04.19 13:31, Christian Borntraeger wrote:
> >>> Adding generation 15.
> >>>
> >>> Some interesting aspects:
> >>> - conditional SSKE and bpb are deprecated. This patch set addresses that
> >>>   for csske.
> >>> - no name yet for gen15, I suggest to use the assigned numbers and
> >>>   provide an alias later on. (I have split out this into a separate
> >>>   patch)
> >>>
> >>> Christian Borntraeger (10):
> >>>   linux header sync
> >>>   s390x/cpumodel: remove CSSKE from base model
> >>>   s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3
> >>>   s390x/cpumodel: msa9 facility
> >>>   s390x/cpumodel: vector enhancements
> >>>   s390x/cpumodel: enhanced sort facility
> >>>   s390x/cpumodel: deflate
> >>>   s390x/cpumodel: add gen15 defintions
> >>>   s390x/cpumodel: wire up 8561 and 8562 as gen15 machines
> >>>   s390x/cpumodel: do not claim csske for expanded models in qmp
> >>>
> >>>  hw/s390x/s390-virtio-ccw.c      |  6 +++
> >>>  linux-headers/asm-s390/kvm.h    |  5 +-
> >>>  target/s390x/cpu_features.c     | 54 +++++++++++++++++++
> >>>  target/s390x/cpu_features.h     |  3 ++
> >>>  target/s390x/cpu_features_def.h | 49 +++++++++++++++++
> >>>  target/s390x/cpu_models.c       | 35 ++++++++++++
> >>>  target/s390x/cpu_models.h       |  1 +
> >>>  target/s390x/gen-features.c     | 94 ++++++++++++++++++++++++++++++++-
> >>>  target/s390x/kvm.c              | 18 +++++++
> >>>  9 files changed, 263 insertions(+), 2 deletions(-)
> >>>
> >>
> >> I guess to handle deprecation of CSSKE:
> >>
> >> 1. Remove it from the base + default model of the gen15, keep it in the
> >> max model. This is completely done in target/s390x/gen-features.c.
> >> Existing base models are not modified.
> >>
> >> 2. Add CSSKE to "ignored_base_feat", so fallback of gen15 to e.g. z14
> >> will work. We can backport this to distros/stable.
> > 
> > Yes, I have already implemented that, still doing some testing and polishinh.
> >>
> >>
> >> CPU model expansion:
> >>
> >> cpu_info_from_model() should already properly be based on the base
> >> features. "gen15" vs. "gen15,csske=on" should be automatically generated
> >> when expanding.
> >>
> >> CPU model baseline:
> >>
> >> s390_find_cpu_def() should make sure that CSSKE is basically ignored
> >> when determining maximum model, however it will properly be indicated if
> >> both models had the feature.
> >>
> >> CPU model comparison:
> >>
> >> Should work as expected. Availability of CSSKE will be considered when
> >> calculating the result.
> >>
> >> gen14,csske=on and gen15,csske=off will result in
> >> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE.
> >>
> >> gen14,csske=off and gen15,csske=off should result in
> >> CPU_MODEL_COMPARE_RESULT_SUBSET
> >>
> >> gen14,csske=on and gen15,csske=on should result in
> >> CPU_MODEL_COMPARE_RESULT_SUBSET
> >>
> >> Forward migration:
> >>
> >> Now, the only issue is when csske is actually turned of in future
> >> machines. We would e.g. have
> >>
> >> gen15,csske=on and gen16,csske=off
> >>
> >> While baselining will work correctly (gen15,csske=off), forward
> >> migration is broken (comparison will properly indicate
> >> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE), which is expected when ripping
> >> out features. Same applies to BPB.
> >>
> >>
> >> Your patch "[PATCH 10/10] s390x/cpumodel: do not claim csske for
> >> expanded models in qmp" tried to address this, however I am not really
> >> happy with this approach. We should not play such tricks when expanding
> >> the host model. "-cpu host" and "-cpu $expanded_host" would be
> >> different,
> > 
> > We discussed this some time ago and I think we agreed that for host passthrough
> > it is ok to be different that host-model (e.g. passing through the cpuid, passing
> > through all non-hypervisor managed features etc).
> 
> I remember the plan was to use the "max" model to do such stuff. E.g.
> -cpu max / no -cpu
> 
> Versus
> -cpu host
> 
> We can have features in "host" we don't have in "max". But "-cpu host"
> and it's expansion should look 100% the same.

I don't think that's the intended semantics of "max" vs "host".

The "max" CPU model is supposed to enable all features that are possible to
enable.

For KVM, thus "max" should be identical to "host".

For TCG, "max" should be everything that QEMU currently knows how to emulate.

Essentially think of "max" as a better name for "host", since "host" as
a name concept didn't make sense for TCG.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [PATCH 00/10] s390x: new guest features

[David Hildenbrand]

On 24.04.19 11:30, Daniel P. Berrangé wrote:
> On Wed, Apr 24, 2019 at 11:03:03AM +0200, David Hildenbrand wrote:
>> On 24.04.19 10:40, Christian Borntraeger wrote:
>>>
>>>
>>> On 23.04.19 14:11, David Hildenbrand wrote:
>>>> On 18.04.19 13:31, Christian Borntraeger wrote:
>>>>> Adding generation 15.
>>>>>
>>>>> Some interesting aspects:
>>>>> - conditional SSKE and bpb are deprecated. This patch set addresses that
>>>>>   for csske.
>>>>> - no name yet for gen15, I suggest to use the assigned numbers and
>>>>>   provide an alias later on. (I have split out this into a separate
>>>>>   patch)
>>>>>
>>>>> Christian Borntraeger (10):
>>>>>   linux header sync
>>>>>   s390x/cpumodel: remove CSSKE from base model
>>>>>   s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3
>>>>>   s390x/cpumodel: msa9 facility
>>>>>   s390x/cpumodel: vector enhancements
>>>>>   s390x/cpumodel: enhanced sort facility
>>>>>   s390x/cpumodel: deflate
>>>>>   s390x/cpumodel: add gen15 defintions
>>>>>   s390x/cpumodel: wire up 8561 and 8562 as gen15 machines
>>>>>   s390x/cpumodel: do not claim csske for expanded models in qmp
>>>>>
>>>>>  hw/s390x/s390-virtio-ccw.c      |  6 +++
>>>>>  linux-headers/asm-s390/kvm.h    |  5 +-
>>>>>  target/s390x/cpu_features.c     | 54 +++++++++++++++++++
>>>>>  target/s390x/cpu_features.h     |  3 ++
>>>>>  target/s390x/cpu_features_def.h | 49 +++++++++++++++++
>>>>>  target/s390x/cpu_models.c       | 35 ++++++++++++
>>>>>  target/s390x/cpu_models.h       |  1 +
>>>>>  target/s390x/gen-features.c     | 94 ++++++++++++++++++++++++++++++++-
>>>>>  target/s390x/kvm.c              | 18 +++++++
>>>>>  9 files changed, 263 insertions(+), 2 deletions(-)
>>>>>
>>>>
>>>> I guess to handle deprecation of CSSKE:
>>>>
>>>> 1. Remove it from the base + default model of the gen15, keep it in the
>>>> max model. This is completely done in target/s390x/gen-features.c.
>>>> Existing base models are not modified.
>>>>
>>>> 2. Add CSSKE to "ignored_base_feat", so fallback of gen15 to e.g. z14
>>>> will work. We can backport this to distros/stable.
>>>
>>> Yes, I have already implemented that, still doing some testing and polishinh.
>>>>
>>>>
>>>> CPU model expansion:
>>>>
>>>> cpu_info_from_model() should already properly be based on the base
>>>> features. "gen15" vs. "gen15,csske=on" should be automatically generated
>>>> when expanding.
>>>>
>>>> CPU model baseline:
>>>>
>>>> s390_find_cpu_def() should make sure that CSSKE is basically ignored
>>>> when determining maximum model, however it will properly be indicated if
>>>> both models had the feature.
>>>>
>>>> CPU model comparison:
>>>>
>>>> Should work as expected. Availability of CSSKE will be considered when
>>>> calculating the result.
>>>>
>>>> gen14,csske=on and gen15,csske=off will result in
>>>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE.
>>>>
>>>> gen14,csske=off and gen15,csske=off should result in
>>>> CPU_MODEL_COMPARE_RESULT_SUBSET
>>>>
>>>> gen14,csske=on and gen15,csske=on should result in
>>>> CPU_MODEL_COMPARE_RESULT_SUBSET
>>>>
>>>> Forward migration:
>>>>
>>>> Now, the only issue is when csske is actually turned of in future
>>>> machines. We would e.g. have
>>>>
>>>> gen15,csske=on and gen16,csske=off
>>>>
>>>> While baselining will work correctly (gen15,csske=off), forward
>>>> migration is broken (comparison will properly indicate
>>>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE), which is expected when ripping
>>>> out features. Same applies to BPB.
>>>>
>>>>
>>>> Your patch "[PATCH 10/10] s390x/cpumodel: do not claim csske for
>>>> expanded models in qmp" tried to address this, however I am not really
>>>> happy with this approach. We should not play such tricks when expanding
>>>> the host model. "-cpu host" and "-cpu $expanded_host" would be
>>>> different,
>>>
>>> We discussed this some time ago and I think we agreed that for host passthrough
>>> it is ok to be different that host-model (e.g. passing through the cpuid, passing
>>> through all non-hypervisor managed features etc).
>>
>> I remember the plan was to use the "max" model to do such stuff. E.g.
>> -cpu max / no -cpu
>>
>> Versus
>> -cpu host
>>
>> We can have features in "host" we don't have in "max". But "-cpu host"
>> and it's expansion should look 100% the same.
> 
> I don't think that's the intended semantics of "max" vs "host".
> 
> The "max" CPU model is supposed to enable all features that are possible to
> enable.
> 
> For KVM, thus "max" should be identical to "host".

There once was a mode used by x86-64 to simply pipe through cpuid
features that were not even supported. (I remember something like
passthorugh=true), do you remember if something like that still exists?

> 
> For TCG, "max" should be everything that QEMU currently knows how to emulate.

Yes, and on s390x. "max" contains more features than "qemu".

> 
> Essentially think of "max" as a better name for "host", since "host" as
> a name concept didn't make sense for TCG.

I agree. The main question is, is it acceptable that

"-cpu host" and "-cpu $expanded_host" produce different results, after
expanding "host" via query-cpu-model-expansion?

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH 00/10] s390x: new guest features

[David Hildenbrand]

On 24.04.19 11:30, Daniel P. Berrangé wrote:
> On Wed, Apr 24, 2019 at 11:03:03AM +0200, David Hildenbrand wrote:
>> On 24.04.19 10:40, Christian Borntraeger wrote:
>>>
>>>
>>> On 23.04.19 14:11, David Hildenbrand wrote:
>>>> On 18.04.19 13:31, Christian Borntraeger wrote:
>>>>> Adding generation 15.
>>>>>
>>>>> Some interesting aspects:
>>>>> - conditional SSKE and bpb are deprecated. This patch set addresses that
>>>>>   for csske.
>>>>> - no name yet for gen15, I suggest to use the assigned numbers and
>>>>>   provide an alias later on. (I have split out this into a separate
>>>>>   patch)
>>>>>
>>>>> Christian Borntraeger (10):
>>>>>   linux header sync
>>>>>   s390x/cpumodel: remove CSSKE from base model
>>>>>   s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3
>>>>>   s390x/cpumodel: msa9 facility
>>>>>   s390x/cpumodel: vector enhancements
>>>>>   s390x/cpumodel: enhanced sort facility
>>>>>   s390x/cpumodel: deflate
>>>>>   s390x/cpumodel: add gen15 defintions
>>>>>   s390x/cpumodel: wire up 8561 and 8562 as gen15 machines
>>>>>   s390x/cpumodel: do not claim csske for expanded models in qmp
>>>>>
>>>>>  hw/s390x/s390-virtio-ccw.c      |  6 +++
>>>>>  linux-headers/asm-s390/kvm.h    |  5 +-
>>>>>  target/s390x/cpu_features.c     | 54 +++++++++++++++++++
>>>>>  target/s390x/cpu_features.h     |  3 ++
>>>>>  target/s390x/cpu_features_def.h | 49 +++++++++++++++++
>>>>>  target/s390x/cpu_models.c       | 35 ++++++++++++
>>>>>  target/s390x/cpu_models.h       |  1 +
>>>>>  target/s390x/gen-features.c     | 94 ++++++++++++++++++++++++++++++++-
>>>>>  target/s390x/kvm.c              | 18 +++++++
>>>>>  9 files changed, 263 insertions(+), 2 deletions(-)
>>>>>
>>>>
>>>> I guess to handle deprecation of CSSKE:
>>>>
>>>> 1. Remove it from the base + default model of the gen15, keep it in the
>>>> max model. This is completely done in target/s390x/gen-features.c.
>>>> Existing base models are not modified.
>>>>
>>>> 2. Add CSSKE to "ignored_base_feat", so fallback of gen15 to e.g. z14
>>>> will work. We can backport this to distros/stable.
>>>
>>> Yes, I have already implemented that, still doing some testing and polishinh.
>>>>
>>>>
>>>> CPU model expansion:
>>>>
>>>> cpu_info_from_model() should already properly be based on the base
>>>> features. "gen15" vs. "gen15,csske=on" should be automatically generated
>>>> when expanding.
>>>>
>>>> CPU model baseline:
>>>>
>>>> s390_find_cpu_def() should make sure that CSSKE is basically ignored
>>>> when determining maximum model, however it will properly be indicated if
>>>> both models had the feature.
>>>>
>>>> CPU model comparison:
>>>>
>>>> Should work as expected. Availability of CSSKE will be considered when
>>>> calculating the result.
>>>>
>>>> gen14,csske=on and gen15,csske=off will result in
>>>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE.
>>>>
>>>> gen14,csske=off and gen15,csske=off should result in
>>>> CPU_MODEL_COMPARE_RESULT_SUBSET
>>>>
>>>> gen14,csske=on and gen15,csske=on should result in
>>>> CPU_MODEL_COMPARE_RESULT_SUBSET
>>>>
>>>> Forward migration:
>>>>
>>>> Now, the only issue is when csske is actually turned of in future
>>>> machines. We would e.g. have
>>>>
>>>> gen15,csske=on and gen16,csske=off
>>>>
>>>> While baselining will work correctly (gen15,csske=off), forward
>>>> migration is broken (comparison will properly indicate
>>>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE), which is expected when ripping
>>>> out features. Same applies to BPB.
>>>>
>>>>
>>>> Your patch "[PATCH 10/10] s390x/cpumodel: do not claim csske for
>>>> expanded models in qmp" tried to address this, however I am not really
>>>> happy with this approach. We should not play such tricks when expanding
>>>> the host model. "-cpu host" and "-cpu $expanded_host" would be
>>>> different,
>>>
>>> We discussed this some time ago and I think we agreed that for host passthrough
>>> it is ok to be different that host-model (e.g. passing through the cpuid, passing
>>> through all non-hypervisor managed features etc).
>>
>> I remember the plan was to use the "max" model to do such stuff. E.g.
>> -cpu max / no -cpu
>>
>> Versus
>> -cpu host
>>
>> We can have features in "host" we don't have in "max". But "-cpu host"
>> and it's expansion should look 100% the same.
> 
> I don't think that's the intended semantics of "max" vs "host".
> 
> The "max" CPU model is supposed to enable all features that are possible to
> enable.
> 
> For KVM, thus "max" should be identical to "host".

There once was a mode used by x86-64 to simply pipe through cpuid
features that were not even supported. (I remember something like
passthorugh=true), do you remember if something like that still exists?

> 
> For TCG, "max" should be everything that QEMU currently knows how to emulate.

Yes, and on s390x. "max" contains more features than "qemu".

> 
> Essentially think of "max" as a better name for "host", since "host" as
> a name concept didn't make sense for TCG.

I agree. The main question is, is it acceptable that

"-cpu host" and "-cpu $expanded_host" produce different results, after
expanding "host" via query-cpu-model-expansion?

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH 00/10] s390x: new guest features

[Daniel P. Berrangé]

On Wed, Apr 24, 2019 at 11:35:40AM +0200, David Hildenbrand wrote:
> On 24.04.19 11:30, Daniel P. Berrangé wrote:
> > On Wed, Apr 24, 2019 at 11:03:03AM +0200, David Hildenbrand wrote:
> >> On 24.04.19 10:40, Christian Borntraeger wrote:
> >>>
> >>>
> >>> On 23.04.19 14:11, David Hildenbrand wrote:
> >>>> On 18.04.19 13:31, Christian Borntraeger wrote:
> >>>>> Adding generation 15.
> >>>>>
> >>>>> Some interesting aspects:
> >>>>> - conditional SSKE and bpb are deprecated. This patch set addresses that
> >>>>>   for csske.
> >>>>> - no name yet for gen15, I suggest to use the assigned numbers and
> >>>>>   provide an alias later on. (I have split out this into a separate
> >>>>>   patch)
> >>>>>
> >>>>> Christian Borntraeger (10):
> >>>>>   linux header sync
> >>>>>   s390x/cpumodel: remove CSSKE from base model
> >>>>>   s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3
> >>>>>   s390x/cpumodel: msa9 facility
> >>>>>   s390x/cpumodel: vector enhancements
> >>>>>   s390x/cpumodel: enhanced sort facility
> >>>>>   s390x/cpumodel: deflate
> >>>>>   s390x/cpumodel: add gen15 defintions
> >>>>>   s390x/cpumodel: wire up 8561 and 8562 as gen15 machines
> >>>>>   s390x/cpumodel: do not claim csske for expanded models in qmp
> >>>>>
> >>>>>  hw/s390x/s390-virtio-ccw.c      |  6 +++
> >>>>>  linux-headers/asm-s390/kvm.h    |  5 +-
> >>>>>  target/s390x/cpu_features.c     | 54 +++++++++++++++++++
> >>>>>  target/s390x/cpu_features.h     |  3 ++
> >>>>>  target/s390x/cpu_features_def.h | 49 +++++++++++++++++
> >>>>>  target/s390x/cpu_models.c       | 35 ++++++++++++
> >>>>>  target/s390x/cpu_models.h       |  1 +
> >>>>>  target/s390x/gen-features.c     | 94 ++++++++++++++++++++++++++++++++-
> >>>>>  target/s390x/kvm.c              | 18 +++++++
> >>>>>  9 files changed, 263 insertions(+), 2 deletions(-)
> >>>>>
> >>>>
> >>>> I guess to handle deprecation of CSSKE:
> >>>>
> >>>> 1. Remove it from the base + default model of the gen15, keep it in the
> >>>> max model. This is completely done in target/s390x/gen-features.c.
> >>>> Existing base models are not modified.
> >>>>
> >>>> 2. Add CSSKE to "ignored_base_feat", so fallback of gen15 to e.g. z14
> >>>> will work. We can backport this to distros/stable.
> >>>
> >>> Yes, I have already implemented that, still doing some testing and polishinh.
> >>>>
> >>>>
> >>>> CPU model expansion:
> >>>>
> >>>> cpu_info_from_model() should already properly be based on the base
> >>>> features. "gen15" vs. "gen15,csske=on" should be automatically generated
> >>>> when expanding.
> >>>>
> >>>> CPU model baseline:
> >>>>
> >>>> s390_find_cpu_def() should make sure that CSSKE is basically ignored
> >>>> when determining maximum model, however it will properly be indicated if
> >>>> both models had the feature.
> >>>>
> >>>> CPU model comparison:
> >>>>
> >>>> Should work as expected. Availability of CSSKE will be considered when
> >>>> calculating the result.
> >>>>
> >>>> gen14,csske=on and gen15,csske=off will result in
> >>>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE.
> >>>>
> >>>> gen14,csske=off and gen15,csske=off should result in
> >>>> CPU_MODEL_COMPARE_RESULT_SUBSET
> >>>>
> >>>> gen14,csske=on and gen15,csske=on should result in
> >>>> CPU_MODEL_COMPARE_RESULT_SUBSET
> >>>>
> >>>> Forward migration:
> >>>>
> >>>> Now, the only issue is when csske is actually turned of in future
> >>>> machines. We would e.g. have
> >>>>
> >>>> gen15,csske=on and gen16,csske=off
> >>>>
> >>>> While baselining will work correctly (gen15,csske=off), forward
> >>>> migration is broken (comparison will properly indicate
> >>>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE), which is expected when ripping
> >>>> out features. Same applies to BPB.
> >>>>
> >>>>
> >>>> Your patch "[PATCH 10/10] s390x/cpumodel: do not claim csske for
> >>>> expanded models in qmp" tried to address this, however I am not really
> >>>> happy with this approach. We should not play such tricks when expanding
> >>>> the host model. "-cpu host" and "-cpu $expanded_host" would be
> >>>> different,
> >>>
> >>> We discussed this some time ago and I think we agreed that for host passthrough
> >>> it is ok to be different that host-model (e.g. passing through the cpuid, passing
> >>> through all non-hypervisor managed features etc).
> >>
> >> I remember the plan was to use the "max" model to do such stuff. E.g.
> >> -cpu max / no -cpu
> >>
> >> Versus
> >> -cpu host
> >>
> >> We can have features in "host" we don't have in "max". But "-cpu host"
> >> and it's expansion should look 100% the same.
> > 
> > I don't think that's the intended semantics of "max" vs "host".
> > 
> > The "max" CPU model is supposed to enable all features that are possible to
> > enable.
> > 
> > For KVM, thus "max" should be identical to "host".
> 
> There once was a mode used by x86-64 to simply pipe through cpuid
> features that were not even supported. (I remember something like
> passthorugh=true), do you remember if something like that still exists?

I don't recall such a feature existing even in the past !

> > For TCG, "max" should be everything that QEMU currently knows how to emulate.
> 
> Yes, and on s390x. "max" contains more features than "qemu".
> 
> > 
> > Essentially think of "max" as a better name for "host", since "host" as
> > a name concept didn't make sense for TCG.
> 
> I agree. The main question is, is it acceptable that

Hmm, maybe I misinterpreted when you wrote

      We can have features in "host" we don't have in "max"

I read that as meaning that "-cpu host" and "-cpu max" would be
different.

> "-cpu host" and "-cpu $expanded_host" produce different results, after
> expanding "host" via query-cpu-model-expansion?

That has always been the case on x86-64, since it is not possible to set
the level, xlevel, vendor, family, model & stepping properties via -cpu,
only the feature flags.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [PATCH 00/10] s390x: new guest features

[Daniel P. Berrangé]

On Wed, Apr 24, 2019 at 11:35:40AM +0200, David Hildenbrand wrote:
> On 24.04.19 11:30, Daniel P. Berrangé wrote:
> > On Wed, Apr 24, 2019 at 11:03:03AM +0200, David Hildenbrand wrote:
> >> On 24.04.19 10:40, Christian Borntraeger wrote:
> >>>
> >>>
> >>> On 23.04.19 14:11, David Hildenbrand wrote:
> >>>> On 18.04.19 13:31, Christian Borntraeger wrote:
> >>>>> Adding generation 15.
> >>>>>
> >>>>> Some interesting aspects:
> >>>>> - conditional SSKE and bpb are deprecated. This patch set addresses that
> >>>>>   for csske.
> >>>>> - no name yet for gen15, I suggest to use the assigned numbers and
> >>>>>   provide an alias later on. (I have split out this into a separate
> >>>>>   patch)
> >>>>>
> >>>>> Christian Borntraeger (10):
> >>>>>   linux header sync
> >>>>>   s390x/cpumodel: remove CSSKE from base model
> >>>>>   s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3
> >>>>>   s390x/cpumodel: msa9 facility
> >>>>>   s390x/cpumodel: vector enhancements
> >>>>>   s390x/cpumodel: enhanced sort facility
> >>>>>   s390x/cpumodel: deflate
> >>>>>   s390x/cpumodel: add gen15 defintions
> >>>>>   s390x/cpumodel: wire up 8561 and 8562 as gen15 machines
> >>>>>   s390x/cpumodel: do not claim csske for expanded models in qmp
> >>>>>
> >>>>>  hw/s390x/s390-virtio-ccw.c      |  6 +++
> >>>>>  linux-headers/asm-s390/kvm.h    |  5 +-
> >>>>>  target/s390x/cpu_features.c     | 54 +++++++++++++++++++
> >>>>>  target/s390x/cpu_features.h     |  3 ++
> >>>>>  target/s390x/cpu_features_def.h | 49 +++++++++++++++++
> >>>>>  target/s390x/cpu_models.c       | 35 ++++++++++++
> >>>>>  target/s390x/cpu_models.h       |  1 +
> >>>>>  target/s390x/gen-features.c     | 94 ++++++++++++++++++++++++++++++++-
> >>>>>  target/s390x/kvm.c              | 18 +++++++
> >>>>>  9 files changed, 263 insertions(+), 2 deletions(-)
> >>>>>
> >>>>
> >>>> I guess to handle deprecation of CSSKE:
> >>>>
> >>>> 1. Remove it from the base + default model of the gen15, keep it in the
> >>>> max model. This is completely done in target/s390x/gen-features.c.
> >>>> Existing base models are not modified.
> >>>>
> >>>> 2. Add CSSKE to "ignored_base_feat", so fallback of gen15 to e.g. z14
> >>>> will work. We can backport this to distros/stable.
> >>>
> >>> Yes, I have already implemented that, still doing some testing and polishinh.
> >>>>
> >>>>
> >>>> CPU model expansion:
> >>>>
> >>>> cpu_info_from_model() should already properly be based on the base
> >>>> features. "gen15" vs. "gen15,csske=on" should be automatically generated
> >>>> when expanding.
> >>>>
> >>>> CPU model baseline:
> >>>>
> >>>> s390_find_cpu_def() should make sure that CSSKE is basically ignored
> >>>> when determining maximum model, however it will properly be indicated if
> >>>> both models had the feature.
> >>>>
> >>>> CPU model comparison:
> >>>>
> >>>> Should work as expected. Availability of CSSKE will be considered when
> >>>> calculating the result.
> >>>>
> >>>> gen14,csske=on and gen15,csske=off will result in
> >>>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE.
> >>>>
> >>>> gen14,csske=off and gen15,csske=off should result in
> >>>> CPU_MODEL_COMPARE_RESULT_SUBSET
> >>>>
> >>>> gen14,csske=on and gen15,csske=on should result in
> >>>> CPU_MODEL_COMPARE_RESULT_SUBSET
> >>>>
> >>>> Forward migration:
> >>>>
> >>>> Now, the only issue is when csske is actually turned of in future
> >>>> machines. We would e.g. have
> >>>>
> >>>> gen15,csske=on and gen16,csske=off
> >>>>
> >>>> While baselining will work correctly (gen15,csske=off), forward
> >>>> migration is broken (comparison will properly indicate
> >>>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE), which is expected when ripping
> >>>> out features. Same applies to BPB.
> >>>>
> >>>>
> >>>> Your patch "[PATCH 10/10] s390x/cpumodel: do not claim csske for
> >>>> expanded models in qmp" tried to address this, however I am not really
> >>>> happy with this approach. We should not play such tricks when expanding
> >>>> the host model. "-cpu host" and "-cpu $expanded_host" would be
> >>>> different,
> >>>
> >>> We discussed this some time ago and I think we agreed that for host passthrough
> >>> it is ok to be different that host-model (e.g. passing through the cpuid, passing
> >>> through all non-hypervisor managed features etc).
> >>
> >> I remember the plan was to use the "max" model to do such stuff. E.g.
> >> -cpu max / no -cpu
> >>
> >> Versus
> >> -cpu host
> >>
> >> We can have features in "host" we don't have in "max". But "-cpu host"
> >> and it's expansion should look 100% the same.
> > 
> > I don't think that's the intended semantics of "max" vs "host".
> > 
> > The "max" CPU model is supposed to enable all features that are possible to
> > enable.
> > 
> > For KVM, thus "max" should be identical to "host".
> 
> There once was a mode used by x86-64 to simply pipe through cpuid
> features that were not even supported. (I remember something like
> passthorugh=true), do you remember if something like that still exists?

I don't recall such a feature existing even in the past !

> > For TCG, "max" should be everything that QEMU currently knows how to emulate.
> 
> Yes, and on s390x. "max" contains more features than "qemu".
> 
> > 
> > Essentially think of "max" as a better name for "host", since "host" as
> > a name concept didn't make sense for TCG.
> 
> I agree. The main question is, is it acceptable that

Hmm, maybe I misinterpreted when you wrote

      We can have features in "host" we don't have in "max"

I read that as meaning that "-cpu host" and "-cpu max" would be
different.

> "-cpu host" and "-cpu $expanded_host" produce different results, after
> expanding "host" via query-cpu-model-expansion?

That has always been the case on x86-64, since it is not possible to set
the level, xlevel, vendor, family, model & stepping properties via -cpu,
only the feature flags.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [PATCH 00/10] s390x: new guest features

[David Hildenbrand]

On 24.04.19 11:41, Daniel P. Berrangé wrote:
> On Wed, Apr 24, 2019 at 11:35:40AM +0200, David Hildenbrand wrote:
>> On 24.04.19 11:30, Daniel P. Berrangé wrote:
>>> On Wed, Apr 24, 2019 at 11:03:03AM +0200, David Hildenbrand wrote:
>>>> On 24.04.19 10:40, Christian Borntraeger wrote:
>>>>>
>>>>>
>>>>> On 23.04.19 14:11, David Hildenbrand wrote:
>>>>>> On 18.04.19 13:31, Christian Borntraeger wrote:
>>>>>>> Adding generation 15.
>>>>>>>
>>>>>>> Some interesting aspects:
>>>>>>> - conditional SSKE and bpb are deprecated. This patch set addresses that
>>>>>>>   for csske.
>>>>>>> - no name yet for gen15, I suggest to use the assigned numbers and
>>>>>>>   provide an alias later on. (I have split out this into a separate
>>>>>>>   patch)
>>>>>>>
>>>>>>> Christian Borntraeger (10):
>>>>>>>   linux header sync
>>>>>>>   s390x/cpumodel: remove CSSKE from base model
>>>>>>>   s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3
>>>>>>>   s390x/cpumodel: msa9 facility
>>>>>>>   s390x/cpumodel: vector enhancements
>>>>>>>   s390x/cpumodel: enhanced sort facility
>>>>>>>   s390x/cpumodel: deflate
>>>>>>>   s390x/cpumodel: add gen15 defintions
>>>>>>>   s390x/cpumodel: wire up 8561 and 8562 as gen15 machines
>>>>>>>   s390x/cpumodel: do not claim csske for expanded models in qmp
>>>>>>>
>>>>>>>  hw/s390x/s390-virtio-ccw.c      |  6 +++
>>>>>>>  linux-headers/asm-s390/kvm.h    |  5 +-
>>>>>>>  target/s390x/cpu_features.c     | 54 +++++++++++++++++++
>>>>>>>  target/s390x/cpu_features.h     |  3 ++
>>>>>>>  target/s390x/cpu_features_def.h | 49 +++++++++++++++++
>>>>>>>  target/s390x/cpu_models.c       | 35 ++++++++++++
>>>>>>>  target/s390x/cpu_models.h       |  1 +
>>>>>>>  target/s390x/gen-features.c     | 94 ++++++++++++++++++++++++++++++++-
>>>>>>>  target/s390x/kvm.c              | 18 +++++++
>>>>>>>  9 files changed, 263 insertions(+), 2 deletions(-)
>>>>>>>
>>>>>>
>>>>>> I guess to handle deprecation of CSSKE:
>>>>>>
>>>>>> 1. Remove it from the base + default model of the gen15, keep it in the
>>>>>> max model. This is completely done in target/s390x/gen-features.c.
>>>>>> Existing base models are not modified.
>>>>>>
>>>>>> 2. Add CSSKE to "ignored_base_feat", so fallback of gen15 to e.g. z14
>>>>>> will work. We can backport this to distros/stable.
>>>>>
>>>>> Yes, I have already implemented that, still doing some testing and polishinh.
>>>>>>
>>>>>>
>>>>>> CPU model expansion:
>>>>>>
>>>>>> cpu_info_from_model() should already properly be based on the base
>>>>>> features. "gen15" vs. "gen15,csske=on" should be automatically generated
>>>>>> when expanding.
>>>>>>
>>>>>> CPU model baseline:
>>>>>>
>>>>>> s390_find_cpu_def() should make sure that CSSKE is basically ignored
>>>>>> when determining maximum model, however it will properly be indicated if
>>>>>> both models had the feature.
>>>>>>
>>>>>> CPU model comparison:
>>>>>>
>>>>>> Should work as expected. Availability of CSSKE will be considered when
>>>>>> calculating the result.
>>>>>>
>>>>>> gen14,csske=on and gen15,csske=off will result in
>>>>>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE.
>>>>>>
>>>>>> gen14,csske=off and gen15,csske=off should result in
>>>>>> CPU_MODEL_COMPARE_RESULT_SUBSET
>>>>>>
>>>>>> gen14,csske=on and gen15,csske=on should result in
>>>>>> CPU_MODEL_COMPARE_RESULT_SUBSET
>>>>>>
>>>>>> Forward migration:
>>>>>>
>>>>>> Now, the only issue is when csske is actually turned of in future
>>>>>> machines. We would e.g. have
>>>>>>
>>>>>> gen15,csske=on and gen16,csske=off
>>>>>>
>>>>>> While baselining will work correctly (gen15,csske=off), forward
>>>>>> migration is broken (comparison will properly indicate
>>>>>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE), which is expected when ripping
>>>>>> out features. Same applies to BPB.
>>>>>>
>>>>>>
>>>>>> Your patch "[PATCH 10/10] s390x/cpumodel: do not claim csske for
>>>>>> expanded models in qmp" tried to address this, however I am not really
>>>>>> happy with this approach. We should not play such tricks when expanding
>>>>>> the host model. "-cpu host" and "-cpu $expanded_host" would be
>>>>>> different,
>>>>>
>>>>> We discussed this some time ago and I think we agreed that for host passthrough
>>>>> it is ok to be different that host-model (e.g. passing through the cpuid, passing
>>>>> through all non-hypervisor managed features etc).
>>>>
>>>> I remember the plan was to use the "max" model to do such stuff. E.g.
>>>> -cpu max / no -cpu
>>>>
>>>> Versus
>>>> -cpu host
>>>>
>>>> We can have features in "host" we don't have in "max". But "-cpu host"
>>>> and it's expansion should look 100% the same.
>>>
>>> I don't think that's the intended semantics of "max" vs "host".
>>>
>>> The "max" CPU model is supposed to enable all features that are possible to
>>> enable.
>>>
>>> For KVM, thus "max" should be identical to "host".
>>
>> There once was a mode used by x86-64 to simply pipe through cpuid
>> features that were not even supported. (I remember something like
>> passthorugh=true), do you remember if something like that still exists?
> 
> I don't recall such a feature existing even in the past !

Maybe my mind is tricking me, or maybe that has long been removed :)

> 
>>> For TCG, "max" should be everything that QEMU currently knows how to emulate.
>>
>> Yes, and on s390x. "max" contains more features than "qemu".
>>
>>>
>>> Essentially think of "max" as a better name for "host", since "host" as
>>> a name concept didn't make sense for TCG.
>>
>> I agree. The main question is, is it acceptable that
> 
> Hmm, maybe I misinterpreted when you wrote
> 
>       We can have features in "host" we don't have in "max"
> 
> I read that as meaning that "-cpu host" and "-cpu max" would be
> different.

No you didn't misinterpret it, I agreed after you spelled it out :)

> 
>> "-cpu host" and "-cpu $expanded_host" produce different results, after
>> expanding "host" via query-cpu-model-expansion?
> 
> That has always been the case on x86-64, since it is not possible to set
> the level, xlevel, vendor, family, model & stepping properties via -cpu,
> only the feature flags.

Fair enough, but the question is if we should mess with feature flags we
can indicate on that level.

It would mean that on a specific host e.g.

"-cpu gen15,csske=on" and "-cpu gen15,csske=off"

Would work. However, "host" model expansion would give us

"-cpu gen15,csske=off"

So trying to e.g. do a query-cpu-model-comparison or
query-cpu-model-baseline against "host" and against the expanded host
model will produce different results.

Libvirt could detect "-cpu gen14,csske=on" as not runnable on the host,
because comparing "-cpu gen14,csske=on" vs. "-cpu gen15,csske=off" would
be "incompatible". But running "-cpu gen14,csske=on" on the host would
work perfectly fine.


https://wiki.qemu.org/index.php/Features/CPUModels

"-cpu host vs -cpu best" is an outdated but interesting read.
-> "-cpu host will be the "all-you-can-enable" mode"
-> "We're not going to have a mode for match-host-CPU, probably "
-> "A "best-predefined-model" mode can be implemented by libvirt. "

Sounds to me, that at least here, the issue should be sorted out either
using a new cpu model type or on the libvirt level.

"Feature deprecated and will be removed soon, remove it from the host
cpu model list if gen15 is used when setting up a new machine".

> 
> Regards,
> Daniel
> 


-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH 00/10] s390x: new guest features

[David Hildenbrand]

On 24.04.19 11:41, Daniel P. Berrangé wrote:
> On Wed, Apr 24, 2019 at 11:35:40AM +0200, David Hildenbrand wrote:
>> On 24.04.19 11:30, Daniel P. Berrangé wrote:
>>> On Wed, Apr 24, 2019 at 11:03:03AM +0200, David Hildenbrand wrote:
>>>> On 24.04.19 10:40, Christian Borntraeger wrote:
>>>>>
>>>>>
>>>>> On 23.04.19 14:11, David Hildenbrand wrote:
>>>>>> On 18.04.19 13:31, Christian Borntraeger wrote:
>>>>>>> Adding generation 15.
>>>>>>>
>>>>>>> Some interesting aspects:
>>>>>>> - conditional SSKE and bpb are deprecated. This patch set addresses that
>>>>>>>   for csske.
>>>>>>> - no name yet for gen15, I suggest to use the assigned numbers and
>>>>>>>   provide an alias later on. (I have split out this into a separate
>>>>>>>   patch)
>>>>>>>
>>>>>>> Christian Borntraeger (10):
>>>>>>>   linux header sync
>>>>>>>   s390x/cpumodel: remove CSSKE from base model
>>>>>>>   s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3
>>>>>>>   s390x/cpumodel: msa9 facility
>>>>>>>   s390x/cpumodel: vector enhancements
>>>>>>>   s390x/cpumodel: enhanced sort facility
>>>>>>>   s390x/cpumodel: deflate
>>>>>>>   s390x/cpumodel: add gen15 defintions
>>>>>>>   s390x/cpumodel: wire up 8561 and 8562 as gen15 machines
>>>>>>>   s390x/cpumodel: do not claim csske for expanded models in qmp
>>>>>>>
>>>>>>>  hw/s390x/s390-virtio-ccw.c      |  6 +++
>>>>>>>  linux-headers/asm-s390/kvm.h    |  5 +-
>>>>>>>  target/s390x/cpu_features.c     | 54 +++++++++++++++++++
>>>>>>>  target/s390x/cpu_features.h     |  3 ++
>>>>>>>  target/s390x/cpu_features_def.h | 49 +++++++++++++++++
>>>>>>>  target/s390x/cpu_models.c       | 35 ++++++++++++
>>>>>>>  target/s390x/cpu_models.h       |  1 +
>>>>>>>  target/s390x/gen-features.c     | 94 ++++++++++++++++++++++++++++++++-
>>>>>>>  target/s390x/kvm.c              | 18 +++++++
>>>>>>>  9 files changed, 263 insertions(+), 2 deletions(-)
>>>>>>>
>>>>>>
>>>>>> I guess to handle deprecation of CSSKE:
>>>>>>
>>>>>> 1. Remove it from the base + default model of the gen15, keep it in the
>>>>>> max model. This is completely done in target/s390x/gen-features.c.
>>>>>> Existing base models are not modified.
>>>>>>
>>>>>> 2. Add CSSKE to "ignored_base_feat", so fallback of gen15 to e.g. z14
>>>>>> will work. We can backport this to distros/stable.
>>>>>
>>>>> Yes, I have already implemented that, still doing some testing and polishinh.
>>>>>>
>>>>>>
>>>>>> CPU model expansion:
>>>>>>
>>>>>> cpu_info_from_model() should already properly be based on the base
>>>>>> features. "gen15" vs. "gen15,csske=on" should be automatically generated
>>>>>> when expanding.
>>>>>>
>>>>>> CPU model baseline:
>>>>>>
>>>>>> s390_find_cpu_def() should make sure that CSSKE is basically ignored
>>>>>> when determining maximum model, however it will properly be indicated if
>>>>>> both models had the feature.
>>>>>>
>>>>>> CPU model comparison:
>>>>>>
>>>>>> Should work as expected. Availability of CSSKE will be considered when
>>>>>> calculating the result.
>>>>>>
>>>>>> gen14,csske=on and gen15,csske=off will result in
>>>>>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE.
>>>>>>
>>>>>> gen14,csske=off and gen15,csske=off should result in
>>>>>> CPU_MODEL_COMPARE_RESULT_SUBSET
>>>>>>
>>>>>> gen14,csske=on and gen15,csske=on should result in
>>>>>> CPU_MODEL_COMPARE_RESULT_SUBSET
>>>>>>
>>>>>> Forward migration:
>>>>>>
>>>>>> Now, the only issue is when csske is actually turned of in future
>>>>>> machines. We would e.g. have
>>>>>>
>>>>>> gen15,csske=on and gen16,csske=off
>>>>>>
>>>>>> While baselining will work correctly (gen15,csske=off), forward
>>>>>> migration is broken (comparison will properly indicate
>>>>>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE), which is expected when ripping
>>>>>> out features. Same applies to BPB.
>>>>>>
>>>>>>
>>>>>> Your patch "[PATCH 10/10] s390x/cpumodel: do not claim csske for
>>>>>> expanded models in qmp" tried to address this, however I am not really
>>>>>> happy with this approach. We should not play such tricks when expanding
>>>>>> the host model. "-cpu host" and "-cpu $expanded_host" would be
>>>>>> different,
>>>>>
>>>>> We discussed this some time ago and I think we agreed that for host passthrough
>>>>> it is ok to be different that host-model (e.g. passing through the cpuid, passing
>>>>> through all non-hypervisor managed features etc).
>>>>
>>>> I remember the plan was to use the "max" model to do such stuff. E.g.
>>>> -cpu max / no -cpu
>>>>
>>>> Versus
>>>> -cpu host
>>>>
>>>> We can have features in "host" we don't have in "max". But "-cpu host"
>>>> and it's expansion should look 100% the same.
>>>
>>> I don't think that's the intended semantics of "max" vs "host".
>>>
>>> The "max" CPU model is supposed to enable all features that are possible to
>>> enable.
>>>
>>> For KVM, thus "max" should be identical to "host".
>>
>> There once was a mode used by x86-64 to simply pipe through cpuid
>> features that were not even supported. (I remember something like
>> passthorugh=true), do you remember if something like that still exists?
> 
> I don't recall such a feature existing even in the past !

Maybe my mind is tricking me, or maybe that has long been removed :)

> 
>>> For TCG, "max" should be everything that QEMU currently knows how to emulate.
>>
>> Yes, and on s390x. "max" contains more features than "qemu".
>>
>>>
>>> Essentially think of "max" as a better name for "host", since "host" as
>>> a name concept didn't make sense for TCG.
>>
>> I agree. The main question is, is it acceptable that
> 
> Hmm, maybe I misinterpreted when you wrote
> 
>       We can have features in "host" we don't have in "max"
> 
> I read that as meaning that "-cpu host" and "-cpu max" would be
> different.

No you didn't misinterpret it, I agreed after you spelled it out :)

> 
>> "-cpu host" and "-cpu $expanded_host" produce different results, after
>> expanding "host" via query-cpu-model-expansion?
> 
> That has always been the case on x86-64, since it is not possible to set
> the level, xlevel, vendor, family, model & stepping properties via -cpu,
> only the feature flags.

Fair enough, but the question is if we should mess with feature flags we
can indicate on that level.

It would mean that on a specific host e.g.

"-cpu gen15,csske=on" and "-cpu gen15,csske=off"

Would work. However, "host" model expansion would give us

"-cpu gen15,csske=off"

So trying to e.g. do a query-cpu-model-comparison or
query-cpu-model-baseline against "host" and against the expanded host
model will produce different results.

Libvirt could detect "-cpu gen14,csske=on" as not runnable on the host,
because comparing "-cpu gen14,csske=on" vs. "-cpu gen15,csske=off" would
be "incompatible". But running "-cpu gen14,csske=on" on the host would
work perfectly fine.


https://wiki.qemu.org/index.php/Features/CPUModels

"-cpu host vs -cpu best" is an outdated but interesting read.
-> "-cpu host will be the "all-you-can-enable" mode"
-> "We're not going to have a mode for match-host-CPU, probably "
-> "A "best-predefined-model" mode can be implemented by libvirt. "

Sounds to me, that at least here, the issue should be sorted out either
using a new cpu model type or on the libvirt level.

"Feature deprecated and will be removed soon, remove it from the host
cpu model list if gen15 is used when setting up a new machine".

> 
> Regards,
> Daniel
> 


-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH 00/10] s390x: new guest features

[Christian Borntraeger]

On 24.04.19 11:56, David Hildenbrand wrote:
> On 24.04.19 11:41, Daniel P. Berrangé wrote:
>> On Wed, Apr 24, 2019 at 11:35:40AM +0200, David Hildenbrand wrote:
>>> On 24.04.19 11:30, Daniel P. Berrangé wrote:
>>>> On Wed, Apr 24, 2019 at 11:03:03AM +0200, David Hildenbrand wrote:
>>>>> On 24.04.19 10:40, Christian Borntraeger wrote:
>>>>>>
>>>>>>
>>>>>> On 23.04.19 14:11, David Hildenbrand wrote:
>>>>>>> On 18.04.19 13:31, Christian Borntraeger wrote:
>>>>>>>> Adding generation 15.
>>>>>>>>
>>>>>>>> Some interesting aspects:
>>>>>>>> - conditional SSKE and bpb are deprecated. This patch set addresses that
>>>>>>>>   for csske.
>>>>>>>> - no name yet for gen15, I suggest to use the assigned numbers and
>>>>>>>>   provide an alias later on. (I have split out this into a separate
>>>>>>>>   patch)
>>>>>>>>
>>>>>>>> Christian Borntraeger (10):
>>>>>>>>   linux header sync
>>>>>>>>   s390x/cpumodel: remove CSSKE from base model
>>>>>>>>   s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3
>>>>>>>>   s390x/cpumodel: msa9 facility
>>>>>>>>   s390x/cpumodel: vector enhancements
>>>>>>>>   s390x/cpumodel: enhanced sort facility
>>>>>>>>   s390x/cpumodel: deflate
>>>>>>>>   s390x/cpumodel: add gen15 defintions
>>>>>>>>   s390x/cpumodel: wire up 8561 and 8562 as gen15 machines
>>>>>>>>   s390x/cpumodel: do not claim csske for expanded models in qmp
>>>>>>>>
>>>>>>>>  hw/s390x/s390-virtio-ccw.c      |  6 +++
>>>>>>>>  linux-headers/asm-s390/kvm.h    |  5 +-
>>>>>>>>  target/s390x/cpu_features.c     | 54 +++++++++++++++++++
>>>>>>>>  target/s390x/cpu_features.h     |  3 ++
>>>>>>>>  target/s390x/cpu_features_def.h | 49 +++++++++++++++++
>>>>>>>>  target/s390x/cpu_models.c       | 35 ++++++++++++
>>>>>>>>  target/s390x/cpu_models.h       |  1 +
>>>>>>>>  target/s390x/gen-features.c     | 94 ++++++++++++++++++++++++++++++++-
>>>>>>>>  target/s390x/kvm.c              | 18 +++++++
>>>>>>>>  9 files changed, 263 insertions(+), 2 deletions(-)
>>>>>>>>
>>>>>>>
>>>>>>> I guess to handle deprecation of CSSKE:
>>>>>>>
>>>>>>> 1. Remove it from the base + default model of the gen15, keep it in the
>>>>>>> max model. This is completely done in target/s390x/gen-features.c.
>>>>>>> Existing base models are not modified.
>>>>>>>
>>>>>>> 2. Add CSSKE to "ignored_base_feat", so fallback of gen15 to e.g. z14
>>>>>>> will work. We can backport this to distros/stable.
>>>>>>
>>>>>> Yes, I have already implemented that, still doing some testing and polishinh.
>>>>>>>
>>>>>>>
>>>>>>> CPU model expansion:
>>>>>>>
>>>>>>> cpu_info_from_model() should already properly be based on the base
>>>>>>> features. "gen15" vs. "gen15,csske=on" should be automatically generated
>>>>>>> when expanding.
>>>>>>>
>>>>>>> CPU model baseline:
>>>>>>>
>>>>>>> s390_find_cpu_def() should make sure that CSSKE is basically ignored
>>>>>>> when determining maximum model, however it will properly be indicated if
>>>>>>> both models had the feature.
>>>>>>>
>>>>>>> CPU model comparison:
>>>>>>>
>>>>>>> Should work as expected. Availability of CSSKE will be considered when
>>>>>>> calculating the result.
>>>>>>>
>>>>>>> gen14,csske=on and gen15,csske=off will result in
>>>>>>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE.
>>>>>>>
>>>>>>> gen14,csske=off and gen15,csske=off should result in
>>>>>>> CPU_MODEL_COMPARE_RESULT_SUBSET
>>>>>>>
>>>>>>> gen14,csske=on and gen15,csske=on should result in
>>>>>>> CPU_MODEL_COMPARE_RESULT_SUBSET
>>>>>>>
>>>>>>> Forward migration:
>>>>>>>
>>>>>>> Now, the only issue is when csske is actually turned of in future
>>>>>>> machines. We would e.g. have
>>>>>>>
>>>>>>> gen15,csske=on and gen16,csske=off
>>>>>>>
>>>>>>> While baselining will work correctly (gen15,csske=off), forward
>>>>>>> migration is broken (comparison will properly indicate
>>>>>>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE), which is expected when ripping
>>>>>>> out features. Same applies to BPB.
>>>>>>>
>>>>>>>
>>>>>>> Your patch "[PATCH 10/10] s390x/cpumodel: do not claim csske for
>>>>>>> expanded models in qmp" tried to address this, however I am not really
>>>>>>> happy with this approach. We should not play such tricks when expanding
>>>>>>> the host model. "-cpu host" and "-cpu $expanded_host" would be
>>>>>>> different,
>>>>>>
>>>>>> We discussed this some time ago and I think we agreed that for host passthrough
>>>>>> it is ok to be different that host-model (e.g. passing through the cpuid, passing
>>>>>> through all non-hypervisor managed features etc).
>>>>>
>>>>> I remember the plan was to use the "max" model to do such stuff. E.g.
>>>>> -cpu max / no -cpu
>>>>>
>>>>> Versus
>>>>> -cpu host
>>>>>
>>>>> We can have features in "host" we don't have in "max". But "-cpu host"
>>>>> and it's expansion should look 100% the same.
>>>>
>>>> I don't think that's the intended semantics of "max" vs "host".
>>>>
>>>> The "max" CPU model is supposed to enable all features that are possible to
>>>> enable.
>>>>
>>>> For KVM, thus "max" should be identical to "host".
>>>
>>> There once was a mode used by x86-64 to simply pipe through cpuid
>>> features that were not even supported. (I remember something like
>>> passthorugh=true), do you remember if something like that still exists?
>>
>> I don't recall such a feature existing even in the past !
> 
> Maybe my mind is tricking me, or maybe that has long been removed :)
> 
>>
>>>> For TCG, "max" should be everything that QEMU currently knows how to emulate.
>>>
>>> Yes, and on s390x. "max" contains more features than "qemu".
>>>
>>>>
>>>> Essentially think of "max" as a better name for "host", since "host" as
>>>> a name concept didn't make sense for TCG.
>>>
>>> I agree. The main question is, is it acceptable that
>>
>> Hmm, maybe I misinterpreted when you wrote
>>
>>       We can have features in "host" we don't have in "max"
>>
>> I read that as meaning that "-cpu host" and "-cpu max" would be
>> different.
> 
> No you didn't misinterpret it, I agreed after you spelled it out :)
> 
>>
>>> "-cpu host" and "-cpu $expanded_host" produce different results, after
>>> expanding "host" via query-cpu-model-expansion?
>>
>> That has always been the case on x86-64, since it is not possible to set
>> the level, xlevel, vendor, family, model & stepping properties via -cpu,
>> only the feature flags.
> 
> Fair enough, but the question is if we should mess with feature flags we
> can indicate on that level.
> 
> It would mean that on a specific host e.g.
> 
> "-cpu gen15,csske=on" and "-cpu gen15,csske=off"
> 
> Would work. However, "host" model expansion would give us
> 
> "-cpu gen15,csske=off"
> 
> So trying to e.g. do a query-cpu-model-comparison or
> query-cpu-model-baseline against "host" and against the expanded host
> model will produce different results.
> 
> Libvirt could detect "-cpu gen14,csske=on" as not runnable on the host,
> because comparing "-cpu gen14,csske=on" vs. "-cpu gen15,csske=off" would
> be "incompatible". But running "-cpu gen14,csske=on" on the host would
> work perfectly fine.

I would like to avoid special knowledge in libvirt (since we moved to have
everything in qemu). 

A more complex idea would be to extend the qmp query with a list of deprecated
features and libvirt could then disable that for expansion but allow it for
baselining.

> 
> 
> https://wiki.qemu.org/index.php/Features/CPUModels
> 
> "-cpu host vs -cpu best" is an outdated but interesting read.
> -> "-cpu host will be the "all-you-can-enable" mode"
> -> "We're not going to have a mode for match-host-CPU, probably "
> -> "A "best-predefined-model" mode can be implemented by libvirt. "
> 
> Sounds to me, that at least here, the issue should be sorted out either
> using a new cpu model type or on the libvirt level.
> 
> "Feature deprecated and will be removed soon, remove it from the host
> cpu model list if gen15 is used when setting up a new machine".
> 
>>
>> Regards,
>> Daniel
>>
> 
> 

Re: [Qemu-devel] [PATCH 00/10] s390x: new guest features

[Christian Borntraeger]

On 24.04.19 11:56, David Hildenbrand wrote:
> On 24.04.19 11:41, Daniel P. Berrangé wrote:
>> On Wed, Apr 24, 2019 at 11:35:40AM +0200, David Hildenbrand wrote:
>>> On 24.04.19 11:30, Daniel P. Berrangé wrote:
>>>> On Wed, Apr 24, 2019 at 11:03:03AM +0200, David Hildenbrand wrote:
>>>>> On 24.04.19 10:40, Christian Borntraeger wrote:
>>>>>>
>>>>>>
>>>>>> On 23.04.19 14:11, David Hildenbrand wrote:
>>>>>>> On 18.04.19 13:31, Christian Borntraeger wrote:
>>>>>>>> Adding generation 15.
>>>>>>>>
>>>>>>>> Some interesting aspects:
>>>>>>>> - conditional SSKE and bpb are deprecated. This patch set addresses that
>>>>>>>>   for csske.
>>>>>>>> - no name yet for gen15, I suggest to use the assigned numbers and
>>>>>>>>   provide an alias later on. (I have split out this into a separate
>>>>>>>>   patch)
>>>>>>>>
>>>>>>>> Christian Borntraeger (10):
>>>>>>>>   linux header sync
>>>>>>>>   s390x/cpumodel: remove CSSKE from base model
>>>>>>>>   s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3
>>>>>>>>   s390x/cpumodel: msa9 facility
>>>>>>>>   s390x/cpumodel: vector enhancements
>>>>>>>>   s390x/cpumodel: enhanced sort facility
>>>>>>>>   s390x/cpumodel: deflate
>>>>>>>>   s390x/cpumodel: add gen15 defintions
>>>>>>>>   s390x/cpumodel: wire up 8561 and 8562 as gen15 machines
>>>>>>>>   s390x/cpumodel: do not claim csske for expanded models in qmp
>>>>>>>>
>>>>>>>>  hw/s390x/s390-virtio-ccw.c      |  6 +++
>>>>>>>>  linux-headers/asm-s390/kvm.h    |  5 +-
>>>>>>>>  target/s390x/cpu_features.c     | 54 +++++++++++++++++++
>>>>>>>>  target/s390x/cpu_features.h     |  3 ++
>>>>>>>>  target/s390x/cpu_features_def.h | 49 +++++++++++++++++
>>>>>>>>  target/s390x/cpu_models.c       | 35 ++++++++++++
>>>>>>>>  target/s390x/cpu_models.h       |  1 +
>>>>>>>>  target/s390x/gen-features.c     | 94 ++++++++++++++++++++++++++++++++-
>>>>>>>>  target/s390x/kvm.c              | 18 +++++++
>>>>>>>>  9 files changed, 263 insertions(+), 2 deletions(-)
>>>>>>>>
>>>>>>>
>>>>>>> I guess to handle deprecation of CSSKE:
>>>>>>>
>>>>>>> 1. Remove it from the base + default model of the gen15, keep it in the
>>>>>>> max model. This is completely done in target/s390x/gen-features.c.
>>>>>>> Existing base models are not modified.
>>>>>>>
>>>>>>> 2. Add CSSKE to "ignored_base_feat", so fallback of gen15 to e.g. z14
>>>>>>> will work. We can backport this to distros/stable.
>>>>>>
>>>>>> Yes, I have already implemented that, still doing some testing and polishinh.
>>>>>>>
>>>>>>>
>>>>>>> CPU model expansion:
>>>>>>>
>>>>>>> cpu_info_from_model() should already properly be based on the base
>>>>>>> features. "gen15" vs. "gen15,csske=on" should be automatically generated
>>>>>>> when expanding.
>>>>>>>
>>>>>>> CPU model baseline:
>>>>>>>
>>>>>>> s390_find_cpu_def() should make sure that CSSKE is basically ignored
>>>>>>> when determining maximum model, however it will properly be indicated if
>>>>>>> both models had the feature.
>>>>>>>
>>>>>>> CPU model comparison:
>>>>>>>
>>>>>>> Should work as expected. Availability of CSSKE will be considered when
>>>>>>> calculating the result.
>>>>>>>
>>>>>>> gen14,csske=on and gen15,csske=off will result in
>>>>>>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE.
>>>>>>>
>>>>>>> gen14,csske=off and gen15,csske=off should result in
>>>>>>> CPU_MODEL_COMPARE_RESULT_SUBSET
>>>>>>>
>>>>>>> gen14,csske=on and gen15,csske=on should result in
>>>>>>> CPU_MODEL_COMPARE_RESULT_SUBSET
>>>>>>>
>>>>>>> Forward migration:
>>>>>>>
>>>>>>> Now, the only issue is when csske is actually turned of in future
>>>>>>> machines. We would e.g. have
>>>>>>>
>>>>>>> gen15,csske=on and gen16,csske=off
>>>>>>>
>>>>>>> While baselining will work correctly (gen15,csske=off), forward
>>>>>>> migration is broken (comparison will properly indicate
>>>>>>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE), which is expected when ripping
>>>>>>> out features. Same applies to BPB.
>>>>>>>
>>>>>>>
>>>>>>> Your patch "[PATCH 10/10] s390x/cpumodel: do not claim csske for
>>>>>>> expanded models in qmp" tried to address this, however I am not really
>>>>>>> happy with this approach. We should not play such tricks when expanding
>>>>>>> the host model. "-cpu host" and "-cpu $expanded_host" would be
>>>>>>> different,
>>>>>>
>>>>>> We discussed this some time ago and I think we agreed that for host passthrough
>>>>>> it is ok to be different that host-model (e.g. passing through the cpuid, passing
>>>>>> through all non-hypervisor managed features etc).
>>>>>
>>>>> I remember the plan was to use the "max" model to do such stuff. E.g.
>>>>> -cpu max / no -cpu
>>>>>
>>>>> Versus
>>>>> -cpu host
>>>>>
>>>>> We can have features in "host" we don't have in "max". But "-cpu host"
>>>>> and it's expansion should look 100% the same.
>>>>
>>>> I don't think that's the intended semantics of "max" vs "host".
>>>>
>>>> The "max" CPU model is supposed to enable all features that are possible to
>>>> enable.
>>>>
>>>> For KVM, thus "max" should be identical to "host".
>>>
>>> There once was a mode used by x86-64 to simply pipe through cpuid
>>> features that were not even supported. (I remember something like
>>> passthorugh=true), do you remember if something like that still exists?
>>
>> I don't recall such a feature existing even in the past !
> 
> Maybe my mind is tricking me, or maybe that has long been removed :)
> 
>>
>>>> For TCG, "max" should be everything that QEMU currently knows how to emulate.
>>>
>>> Yes, and on s390x. "max" contains more features than "qemu".
>>>
>>>>
>>>> Essentially think of "max" as a better name for "host", since "host" as
>>>> a name concept didn't make sense for TCG.
>>>
>>> I agree. The main question is, is it acceptable that
>>
>> Hmm, maybe I misinterpreted when you wrote
>>
>>       We can have features in "host" we don't have in "max"
>>
>> I read that as meaning that "-cpu host" and "-cpu max" would be
>> different.
> 
> No you didn't misinterpret it, I agreed after you spelled it out :)
> 
>>
>>> "-cpu host" and "-cpu $expanded_host" produce different results, after
>>> expanding "host" via query-cpu-model-expansion?
>>
>> That has always been the case on x86-64, since it is not possible to set
>> the level, xlevel, vendor, family, model & stepping properties via -cpu,
>> only the feature flags.
> 
> Fair enough, but the question is if we should mess with feature flags we
> can indicate on that level.
> 
> It would mean that on a specific host e.g.
> 
> "-cpu gen15,csske=on" and "-cpu gen15,csske=off"
> 
> Would work. However, "host" model expansion would give us
> 
> "-cpu gen15,csske=off"
> 
> So trying to e.g. do a query-cpu-model-comparison or
> query-cpu-model-baseline against "host" and against the expanded host
> model will produce different results.
> 
> Libvirt could detect "-cpu gen14,csske=on" as not runnable on the host,
> because comparing "-cpu gen14,csske=on" vs. "-cpu gen15,csske=off" would
> be "incompatible". But running "-cpu gen14,csske=on" on the host would
> work perfectly fine.

I would like to avoid special knowledge in libvirt (since we moved to have
everything in qemu). 

A more complex idea would be to extend the qmp query with a list of deprecated
features and libvirt could then disable that for expansion but allow it for
baselining.

> 
> 
> https://wiki.qemu.org/index.php/Features/CPUModels
> 
> "-cpu host vs -cpu best" is an outdated but interesting read.
> -> "-cpu host will be the "all-you-can-enable" mode"
> -> "We're not going to have a mode for match-host-CPU, probably "
> -> "A "best-predefined-model" mode can be implemented by libvirt. "
> 
> Sounds to me, that at least here, the issue should be sorted out either
> using a new cpu model type or on the libvirt level.
> 
> "Feature deprecated and will be removed soon, remove it from the host
> cpu model list if gen15 is used when setting up a new machine".
> 
>>
>> Regards,
>> Daniel
>>
> 
> 

Re: [Qemu-devel] [PATCH 00/10] s390x: new guest features

[David Hildenbrand]

On 24.04.19 12:26, Christian Borntraeger wrote:
> 
> 
> On 24.04.19 11:56, David Hildenbrand wrote:
>> On 24.04.19 11:41, Daniel P. Berrangé wrote:
>>> On Wed, Apr 24, 2019 at 11:35:40AM +0200, David Hildenbrand wrote:
>>>> On 24.04.19 11:30, Daniel P. Berrangé wrote:
>>>>> On Wed, Apr 24, 2019 at 11:03:03AM +0200, David Hildenbrand wrote:
>>>>>> On 24.04.19 10:40, Christian Borntraeger wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 23.04.19 14:11, David Hildenbrand wrote:
>>>>>>>> On 18.04.19 13:31, Christian Borntraeger wrote:
>>>>>>>>> Adding generation 15.
>>>>>>>>>
>>>>>>>>> Some interesting aspects:
>>>>>>>>> - conditional SSKE and bpb are deprecated. This patch set addresses that
>>>>>>>>>   for csske.
>>>>>>>>> - no name yet for gen15, I suggest to use the assigned numbers and
>>>>>>>>>   provide an alias later on. (I have split out this into a separate
>>>>>>>>>   patch)
>>>>>>>>>
>>>>>>>>> Christian Borntraeger (10):
>>>>>>>>>   linux header sync
>>>>>>>>>   s390x/cpumodel: remove CSSKE from base model
>>>>>>>>>   s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3
>>>>>>>>>   s390x/cpumodel: msa9 facility
>>>>>>>>>   s390x/cpumodel: vector enhancements
>>>>>>>>>   s390x/cpumodel: enhanced sort facility
>>>>>>>>>   s390x/cpumodel: deflate
>>>>>>>>>   s390x/cpumodel: add gen15 defintions
>>>>>>>>>   s390x/cpumodel: wire up 8561 and 8562 as gen15 machines
>>>>>>>>>   s390x/cpumodel: do not claim csske for expanded models in qmp
>>>>>>>>>
>>>>>>>>>  hw/s390x/s390-virtio-ccw.c      |  6 +++
>>>>>>>>>  linux-headers/asm-s390/kvm.h    |  5 +-
>>>>>>>>>  target/s390x/cpu_features.c     | 54 +++++++++++++++++++
>>>>>>>>>  target/s390x/cpu_features.h     |  3 ++
>>>>>>>>>  target/s390x/cpu_features_def.h | 49 +++++++++++++++++
>>>>>>>>>  target/s390x/cpu_models.c       | 35 ++++++++++++
>>>>>>>>>  target/s390x/cpu_models.h       |  1 +
>>>>>>>>>  target/s390x/gen-features.c     | 94 ++++++++++++++++++++++++++++++++-
>>>>>>>>>  target/s390x/kvm.c              | 18 +++++++
>>>>>>>>>  9 files changed, 263 insertions(+), 2 deletions(-)
>>>>>>>>>
>>>>>>>>
>>>>>>>> I guess to handle deprecation of CSSKE:
>>>>>>>>
>>>>>>>> 1. Remove it from the base + default model of the gen15, keep it in the
>>>>>>>> max model. This is completely done in target/s390x/gen-features.c.
>>>>>>>> Existing base models are not modified.
>>>>>>>>
>>>>>>>> 2. Add CSSKE to "ignored_base_feat", so fallback of gen15 to e.g. z14
>>>>>>>> will work. We can backport this to distros/stable.
>>>>>>>
>>>>>>> Yes, I have already implemented that, still doing some testing and polishinh.
>>>>>>>>
>>>>>>>>
>>>>>>>> CPU model expansion:
>>>>>>>>
>>>>>>>> cpu_info_from_model() should already properly be based on the base
>>>>>>>> features. "gen15" vs. "gen15,csske=on" should be automatically generated
>>>>>>>> when expanding.
>>>>>>>>
>>>>>>>> CPU model baseline:
>>>>>>>>
>>>>>>>> s390_find_cpu_def() should make sure that CSSKE is basically ignored
>>>>>>>> when determining maximum model, however it will properly be indicated if
>>>>>>>> both models had the feature.
>>>>>>>>
>>>>>>>> CPU model comparison:
>>>>>>>>
>>>>>>>> Should work as expected. Availability of CSSKE will be considered when
>>>>>>>> calculating the result.
>>>>>>>>
>>>>>>>> gen14,csske=on and gen15,csske=off will result in
>>>>>>>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE.
>>>>>>>>
>>>>>>>> gen14,csske=off and gen15,csske=off should result in
>>>>>>>> CPU_MODEL_COMPARE_RESULT_SUBSET
>>>>>>>>
>>>>>>>> gen14,csske=on and gen15,csske=on should result in
>>>>>>>> CPU_MODEL_COMPARE_RESULT_SUBSET
>>>>>>>>
>>>>>>>> Forward migration:
>>>>>>>>
>>>>>>>> Now, the only issue is when csske is actually turned of in future
>>>>>>>> machines. We would e.g. have
>>>>>>>>
>>>>>>>> gen15,csske=on and gen16,csske=off
>>>>>>>>
>>>>>>>> While baselining will work correctly (gen15,csske=off), forward
>>>>>>>> migration is broken (comparison will properly indicate
>>>>>>>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE), which is expected when ripping
>>>>>>>> out features. Same applies to BPB.
>>>>>>>>
>>>>>>>>
>>>>>>>> Your patch "[PATCH 10/10] s390x/cpumodel: do not claim csske for
>>>>>>>> expanded models in qmp" tried to address this, however I am not really
>>>>>>>> happy with this approach. We should not play such tricks when expanding
>>>>>>>> the host model. "-cpu host" and "-cpu $expanded_host" would be
>>>>>>>> different,
>>>>>>>
>>>>>>> We discussed this some time ago and I think we agreed that for host passthrough
>>>>>>> it is ok to be different that host-model (e.g. passing through the cpuid, passing
>>>>>>> through all non-hypervisor managed features etc).
>>>>>>
>>>>>> I remember the plan was to use the "max" model to do such stuff. E.g.
>>>>>> -cpu max / no -cpu
>>>>>>
>>>>>> Versus
>>>>>> -cpu host
>>>>>>
>>>>>> We can have features in "host" we don't have in "max". But "-cpu host"
>>>>>> and it's expansion should look 100% the same.
>>>>>
>>>>> I don't think that's the intended semantics of "max" vs "host".
>>>>>
>>>>> The "max" CPU model is supposed to enable all features that are possible to
>>>>> enable.
>>>>>
>>>>> For KVM, thus "max" should be identical to "host".
>>>>
>>>> There once was a mode used by x86-64 to simply pipe through cpuid
>>>> features that were not even supported. (I remember something like
>>>> passthorugh=true), do you remember if something like that still exists?
>>>
>>> I don't recall such a feature existing even in the past !
>>
>> Maybe my mind is tricking me, or maybe that has long been removed :)
>>
>>>
>>>>> For TCG, "max" should be everything that QEMU currently knows how to emulate.
>>>>
>>>> Yes, and on s390x. "max" contains more features than "qemu".
>>>>
>>>>>
>>>>> Essentially think of "max" as a better name for "host", since "host" as
>>>>> a name concept didn't make sense for TCG.
>>>>
>>>> I agree. The main question is, is it acceptable that
>>>
>>> Hmm, maybe I misinterpreted when you wrote
>>>
>>>       We can have features in "host" we don't have in "max"
>>>
>>> I read that as meaning that "-cpu host" and "-cpu max" would be
>>> different.
>>
>> No you didn't misinterpret it, I agreed after you spelled it out :)
>>
>>>
>>>> "-cpu host" and "-cpu $expanded_host" produce different results, after
>>>> expanding "host" via query-cpu-model-expansion?
>>>
>>> That has always been the case on x86-64, since it is not possible to set
>>> the level, xlevel, vendor, family, model & stepping properties via -cpu,
>>> only the feature flags.
>>
>> Fair enough, but the question is if we should mess with feature flags we
>> can indicate on that level.
>>
>> It would mean that on a specific host e.g.
>>
>> "-cpu gen15,csske=on" and "-cpu gen15,csske=off"
>>
>> Would work. However, "host" model expansion would give us
>>
>> "-cpu gen15,csske=off"
>>
>> So trying to e.g. do a query-cpu-model-comparison or
>> query-cpu-model-baseline against "host" and against the expanded host
>> model will produce different results.
>>
>> Libvirt could detect "-cpu gen14,csske=on" as not runnable on the host,
>> because comparing "-cpu gen14,csske=on" vs. "-cpu gen15,csske=off" would
>> be "incompatible". But running "-cpu gen14,csske=on" on the host would
>> work perfectly fine.
> 
> I would like to avoid special knowledge in libvirt (since we moved to have
> everything in qemu). 
> 
> A more complex idea would be to extend the qmp query with a list of deprecated
> features and libvirt could then disable that for expansion but allow it for
> baselining.

That would fit in nicely into query-cpu-model-expansion. Nice idea.

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH 00/10] s390x: new guest features

[David Hildenbrand]

On 24.04.19 12:26, Christian Borntraeger wrote:
> 
> 
> On 24.04.19 11:56, David Hildenbrand wrote:
>> On 24.04.19 11:41, Daniel P. Berrangé wrote:
>>> On Wed, Apr 24, 2019 at 11:35:40AM +0200, David Hildenbrand wrote:
>>>> On 24.04.19 11:30, Daniel P. Berrangé wrote:
>>>>> On Wed, Apr 24, 2019 at 11:03:03AM +0200, David Hildenbrand wrote:
>>>>>> On 24.04.19 10:40, Christian Borntraeger wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 23.04.19 14:11, David Hildenbrand wrote:
>>>>>>>> On 18.04.19 13:31, Christian Borntraeger wrote:
>>>>>>>>> Adding generation 15.
>>>>>>>>>
>>>>>>>>> Some interesting aspects:
>>>>>>>>> - conditional SSKE and bpb are deprecated. This patch set addresses that
>>>>>>>>>   for csske.
>>>>>>>>> - no name yet for gen15, I suggest to use the assigned numbers and
>>>>>>>>>   provide an alias later on. (I have split out this into a separate
>>>>>>>>>   patch)
>>>>>>>>>
>>>>>>>>> Christian Borntraeger (10):
>>>>>>>>>   linux header sync
>>>>>>>>>   s390x/cpumodel: remove CSSKE from base model
>>>>>>>>>   s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3
>>>>>>>>>   s390x/cpumodel: msa9 facility
>>>>>>>>>   s390x/cpumodel: vector enhancements
>>>>>>>>>   s390x/cpumodel: enhanced sort facility
>>>>>>>>>   s390x/cpumodel: deflate
>>>>>>>>>   s390x/cpumodel: add gen15 defintions
>>>>>>>>>   s390x/cpumodel: wire up 8561 and 8562 as gen15 machines
>>>>>>>>>   s390x/cpumodel: do not claim csske for expanded models in qmp
>>>>>>>>>
>>>>>>>>>  hw/s390x/s390-virtio-ccw.c      |  6 +++
>>>>>>>>>  linux-headers/asm-s390/kvm.h    |  5 +-
>>>>>>>>>  target/s390x/cpu_features.c     | 54 +++++++++++++++++++
>>>>>>>>>  target/s390x/cpu_features.h     |  3 ++
>>>>>>>>>  target/s390x/cpu_features_def.h | 49 +++++++++++++++++
>>>>>>>>>  target/s390x/cpu_models.c       | 35 ++++++++++++
>>>>>>>>>  target/s390x/cpu_models.h       |  1 +
>>>>>>>>>  target/s390x/gen-features.c     | 94 ++++++++++++++++++++++++++++++++-
>>>>>>>>>  target/s390x/kvm.c              | 18 +++++++
>>>>>>>>>  9 files changed, 263 insertions(+), 2 deletions(-)
>>>>>>>>>
>>>>>>>>
>>>>>>>> I guess to handle deprecation of CSSKE:
>>>>>>>>
>>>>>>>> 1. Remove it from the base + default model of the gen15, keep it in the
>>>>>>>> max model. This is completely done in target/s390x/gen-features.c.
>>>>>>>> Existing base models are not modified.
>>>>>>>>
>>>>>>>> 2. Add CSSKE to "ignored_base_feat", so fallback of gen15 to e.g. z14
>>>>>>>> will work. We can backport this to distros/stable.
>>>>>>>
>>>>>>> Yes, I have already implemented that, still doing some testing and polishinh.
>>>>>>>>
>>>>>>>>
>>>>>>>> CPU model expansion:
>>>>>>>>
>>>>>>>> cpu_info_from_model() should already properly be based on the base
>>>>>>>> features. "gen15" vs. "gen15,csske=on" should be automatically generated
>>>>>>>> when expanding.
>>>>>>>>
>>>>>>>> CPU model baseline:
>>>>>>>>
>>>>>>>> s390_find_cpu_def() should make sure that CSSKE is basically ignored
>>>>>>>> when determining maximum model, however it will properly be indicated if
>>>>>>>> both models had the feature.
>>>>>>>>
>>>>>>>> CPU model comparison:
>>>>>>>>
>>>>>>>> Should work as expected. Availability of CSSKE will be considered when
>>>>>>>> calculating the result.
>>>>>>>>
>>>>>>>> gen14,csske=on and gen15,csske=off will result in
>>>>>>>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE.
>>>>>>>>
>>>>>>>> gen14,csske=off and gen15,csske=off should result in
>>>>>>>> CPU_MODEL_COMPARE_RESULT_SUBSET
>>>>>>>>
>>>>>>>> gen14,csske=on and gen15,csske=on should result in
>>>>>>>> CPU_MODEL_COMPARE_RESULT_SUBSET
>>>>>>>>
>>>>>>>> Forward migration:
>>>>>>>>
>>>>>>>> Now, the only issue is when csske is actually turned of in future
>>>>>>>> machines. We would e.g. have
>>>>>>>>
>>>>>>>> gen15,csske=on and gen16,csske=off
>>>>>>>>
>>>>>>>> While baselining will work correctly (gen15,csske=off), forward
>>>>>>>> migration is broken (comparison will properly indicate
>>>>>>>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE), which is expected when ripping
>>>>>>>> out features. Same applies to BPB.
>>>>>>>>
>>>>>>>>
>>>>>>>> Your patch "[PATCH 10/10] s390x/cpumodel: do not claim csske for
>>>>>>>> expanded models in qmp" tried to address this, however I am not really
>>>>>>>> happy with this approach. We should not play such tricks when expanding
>>>>>>>> the host model. "-cpu host" and "-cpu $expanded_host" would be
>>>>>>>> different,
>>>>>>>
>>>>>>> We discussed this some time ago and I think we agreed that for host passthrough
>>>>>>> it is ok to be different that host-model (e.g. passing through the cpuid, passing
>>>>>>> through all non-hypervisor managed features etc).
>>>>>>
>>>>>> I remember the plan was to use the "max" model to do such stuff. E.g.
>>>>>> -cpu max / no -cpu
>>>>>>
>>>>>> Versus
>>>>>> -cpu host
>>>>>>
>>>>>> We can have features in "host" we don't have in "max". But "-cpu host"
>>>>>> and it's expansion should look 100% the same.
>>>>>
>>>>> I don't think that's the intended semantics of "max" vs "host".
>>>>>
>>>>> The "max" CPU model is supposed to enable all features that are possible to
>>>>> enable.
>>>>>
>>>>> For KVM, thus "max" should be identical to "host".
>>>>
>>>> There once was a mode used by x86-64 to simply pipe through cpuid
>>>> features that were not even supported. (I remember something like
>>>> passthorugh=true), do you remember if something like that still exists?
>>>
>>> I don't recall such a feature existing even in the past !
>>
>> Maybe my mind is tricking me, or maybe that has long been removed :)
>>
>>>
>>>>> For TCG, "max" should be everything that QEMU currently knows how to emulate.
>>>>
>>>> Yes, and on s390x. "max" contains more features than "qemu".
>>>>
>>>>>
>>>>> Essentially think of "max" as a better name for "host", since "host" as
>>>>> a name concept didn't make sense for TCG.
>>>>
>>>> I agree. The main question is, is it acceptable that
>>>
>>> Hmm, maybe I misinterpreted when you wrote
>>>
>>>       We can have features in "host" we don't have in "max"
>>>
>>> I read that as meaning that "-cpu host" and "-cpu max" would be
>>> different.
>>
>> No you didn't misinterpret it, I agreed after you spelled it out :)
>>
>>>
>>>> "-cpu host" and "-cpu $expanded_host" produce different results, after
>>>> expanding "host" via query-cpu-model-expansion?
>>>
>>> That has always been the case on x86-64, since it is not possible to set
>>> the level, xlevel, vendor, family, model & stepping properties via -cpu,
>>> only the feature flags.
>>
>> Fair enough, but the question is if we should mess with feature flags we
>> can indicate on that level.
>>
>> It would mean that on a specific host e.g.
>>
>> "-cpu gen15,csske=on" and "-cpu gen15,csske=off"
>>
>> Would work. However, "host" model expansion would give us
>>
>> "-cpu gen15,csske=off"
>>
>> So trying to e.g. do a query-cpu-model-comparison or
>> query-cpu-model-baseline against "host" and against the expanded host
>> model will produce different results.
>>
>> Libvirt could detect "-cpu gen14,csske=on" as not runnable on the host,
>> because comparing "-cpu gen14,csske=on" vs. "-cpu gen15,csske=off" would
>> be "incompatible". But running "-cpu gen14,csske=on" on the host would
>> work perfectly fine.
> 
> I would like to avoid special knowledge in libvirt (since we moved to have
> everything in qemu). 
> 
> A more complex idea would be to extend the qmp query with a list of deprecated
> features and libvirt could then disable that for expansion but allow it for
> baselining.

That would fit in nicely into query-cpu-model-expansion. Nice idea.

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH 00/10] s390x: new guest features

[Daniel P. Berrangé]

On Wed, Apr 24, 2019 at 12:26:26PM +0200, Christian Borntraeger wrote:
> 
> 
> On 24.04.19 11:56, David Hildenbrand wrote:
> > On 24.04.19 11:41, Daniel P. Berrangé wrote:
> >> On Wed, Apr 24, 2019 at 11:35:40AM +0200, David Hildenbrand wrote:
> >>> On 24.04.19 11:30, Daniel P. Berrangé wrote:
> >>>> On Wed, Apr 24, 2019 at 11:03:03AM +0200, David Hildenbrand wrote:
> >>>>> On 24.04.19 10:40, Christian Borntraeger wrote:
> >>>>>>
> >>>>>>
> >>>>>> On 23.04.19 14:11, David Hildenbrand wrote:
> >>>>>>> On 18.04.19 13:31, Christian Borntraeger wrote:
> >>>>>>>> Adding generation 15.
> >>>>>>>>
> >>>>>>>> Some interesting aspects:
> >>>>>>>> - conditional SSKE and bpb are deprecated. This patch set addresses that
> >>>>>>>>   for csske.
> >>>>>>>> - no name yet for gen15, I suggest to use the assigned numbers and
> >>>>>>>>   provide an alias later on. (I have split out this into a separate
> >>>>>>>>   patch)
> >>>>>>>>
> >>>>>>>> Christian Borntraeger (10):
> >>>>>>>>   linux header sync
> >>>>>>>>   s390x/cpumodel: remove CSSKE from base model
> >>>>>>>>   s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3
> >>>>>>>>   s390x/cpumodel: msa9 facility
> >>>>>>>>   s390x/cpumodel: vector enhancements
> >>>>>>>>   s390x/cpumodel: enhanced sort facility
> >>>>>>>>   s390x/cpumodel: deflate
> >>>>>>>>   s390x/cpumodel: add gen15 defintions
> >>>>>>>>   s390x/cpumodel: wire up 8561 and 8562 as gen15 machines
> >>>>>>>>   s390x/cpumodel: do not claim csske for expanded models in qmp
> >>>>>>>>
> >>>>>>>>  hw/s390x/s390-virtio-ccw.c      |  6 +++
> >>>>>>>>  linux-headers/asm-s390/kvm.h    |  5 +-
> >>>>>>>>  target/s390x/cpu_features.c     | 54 +++++++++++++++++++
> >>>>>>>>  target/s390x/cpu_features.h     |  3 ++
> >>>>>>>>  target/s390x/cpu_features_def.h | 49 +++++++++++++++++
> >>>>>>>>  target/s390x/cpu_models.c       | 35 ++++++++++++
> >>>>>>>>  target/s390x/cpu_models.h       |  1 +
> >>>>>>>>  target/s390x/gen-features.c     | 94 ++++++++++++++++++++++++++++++++-
> >>>>>>>>  target/s390x/kvm.c              | 18 +++++++
> >>>>>>>>  9 files changed, 263 insertions(+), 2 deletions(-)
> >>>>>>>>
> >>>>>>>
> >>>>>>> I guess to handle deprecation of CSSKE:
> >>>>>>>
> >>>>>>> 1. Remove it from the base + default model of the gen15, keep it in the
> >>>>>>> max model. This is completely done in target/s390x/gen-features.c.
> >>>>>>> Existing base models are not modified.
> >>>>>>>
> >>>>>>> 2. Add CSSKE to "ignored_base_feat", so fallback of gen15 to e.g. z14
> >>>>>>> will work. We can backport this to distros/stable.
> >>>>>>
> >>>>>> Yes, I have already implemented that, still doing some testing and polishinh.
> >>>>>>>
> >>>>>>>
> >>>>>>> CPU model expansion:
> >>>>>>>
> >>>>>>> cpu_info_from_model() should already properly be based on the base
> >>>>>>> features. "gen15" vs. "gen15,csske=on" should be automatically generated
> >>>>>>> when expanding.
> >>>>>>>
> >>>>>>> CPU model baseline:
> >>>>>>>
> >>>>>>> s390_find_cpu_def() should make sure that CSSKE is basically ignored
> >>>>>>> when determining maximum model, however it will properly be indicated if
> >>>>>>> both models had the feature.
> >>>>>>>
> >>>>>>> CPU model comparison:
> >>>>>>>
> >>>>>>> Should work as expected. Availability of CSSKE will be considered when
> >>>>>>> calculating the result.
> >>>>>>>
> >>>>>>> gen14,csske=on and gen15,csske=off will result in
> >>>>>>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE.
> >>>>>>>
> >>>>>>> gen14,csske=off and gen15,csske=off should result in
> >>>>>>> CPU_MODEL_COMPARE_RESULT_SUBSET
> >>>>>>>
> >>>>>>> gen14,csske=on and gen15,csske=on should result in
> >>>>>>> CPU_MODEL_COMPARE_RESULT_SUBSET
> >>>>>>>
> >>>>>>> Forward migration:
> >>>>>>>
> >>>>>>> Now, the only issue is when csske is actually turned of in future
> >>>>>>> machines. We would e.g. have
> >>>>>>>
> >>>>>>> gen15,csske=on and gen16,csske=off
> >>>>>>>
> >>>>>>> While baselining will work correctly (gen15,csske=off), forward
> >>>>>>> migration is broken (comparison will properly indicate
> >>>>>>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE), which is expected when ripping
> >>>>>>> out features. Same applies to BPB.
> >>>>>>>
> >>>>>>>
> >>>>>>> Your patch "[PATCH 10/10] s390x/cpumodel: do not claim csske for
> >>>>>>> expanded models in qmp" tried to address this, however I am not really
> >>>>>>> happy with this approach. We should not play such tricks when expanding
> >>>>>>> the host model. "-cpu host" and "-cpu $expanded_host" would be
> >>>>>>> different,
> >>>>>>
> >>>>>> We discussed this some time ago and I think we agreed that for host passthrough
> >>>>>> it is ok to be different that host-model (e.g. passing through the cpuid, passing
> >>>>>> through all non-hypervisor managed features etc).
> >>>>>
> >>>>> I remember the plan was to use the "max" model to do such stuff. E.g.
> >>>>> -cpu max / no -cpu
> >>>>>
> >>>>> Versus
> >>>>> -cpu host
> >>>>>
> >>>>> We can have features in "host" we don't have in "max". But "-cpu host"
> >>>>> and it's expansion should look 100% the same.
> >>>>
> >>>> I don't think that's the intended semantics of "max" vs "host".
> >>>>
> >>>> The "max" CPU model is supposed to enable all features that are possible to
> >>>> enable.
> >>>>
> >>>> For KVM, thus "max" should be identical to "host".
> >>>
> >>> There once was a mode used by x86-64 to simply pipe through cpuid
> >>> features that were not even supported. (I remember something like
> >>> passthorugh=true), do you remember if something like that still exists?
> >>
> >> I don't recall such a feature existing even in the past !
> > 
> > Maybe my mind is tricking me, or maybe that has long been removed :)
> > 
> >>
> >>>> For TCG, "max" should be everything that QEMU currently knows how to emulate.
> >>>
> >>> Yes, and on s390x. "max" contains more features than "qemu".
> >>>
> >>>>
> >>>> Essentially think of "max" as a better name for "host", since "host" as
> >>>> a name concept didn't make sense for TCG.
> >>>
> >>> I agree. The main question is, is it acceptable that
> >>
> >> Hmm, maybe I misinterpreted when you wrote
> >>
> >>       We can have features in "host" we don't have in "max"
> >>
> >> I read that as meaning that "-cpu host" and "-cpu max" would be
> >> different.
> > 
> > No you didn't misinterpret it, I agreed after you spelled it out :)
> > 
> >>
> >>> "-cpu host" and "-cpu $expanded_host" produce different results, after
> >>> expanding "host" via query-cpu-model-expansion?
> >>
> >> That has always been the case on x86-64, since it is not possible to set
> >> the level, xlevel, vendor, family, model & stepping properties via -cpu,
> >> only the feature flags.
> > 
> > Fair enough, but the question is if we should mess with feature flags we
> > can indicate on that level.
> > 
> > It would mean that on a specific host e.g.
> > 
> > "-cpu gen15,csske=on" and "-cpu gen15,csske=off"
> > 
> > Would work. However, "host" model expansion would give us
> > 
> > "-cpu gen15,csske=off"
> > 
> > So trying to e.g. do a query-cpu-model-comparison or
> > query-cpu-model-baseline against "host" and against the expanded host
> > model will produce different results.
> > 
> > Libvirt could detect "-cpu gen14,csske=on" as not runnable on the host,
> > because comparing "-cpu gen14,csske=on" vs. "-cpu gen15,csske=off" would
> > be "incompatible". But running "-cpu gen14,csske=on" on the host would
> > work perfectly fine.
> 
> I would like to avoid special knowledge in libvirt (since we moved to have
> everything in qemu). 
> 
> A more complex idea would be to extend the qmp query with a list of deprecated
> features and libvirt could then disable that for expansion but allow it for
> baselining.

Funny that you mention deprecation with CPU features....

  https://lists.gnu.org/archive/html/qemu-devel/2019-04/msg03969.html

So that makes 4 things we want to report deprecation for. Devices,
machine types, cpu models and now cpu features.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [PATCH 00/10] s390x: new guest features

[Daniel P. Berrangé]

On Wed, Apr 24, 2019 at 12:26:26PM +0200, Christian Borntraeger wrote:
> 
> 
> On 24.04.19 11:56, David Hildenbrand wrote:
> > On 24.04.19 11:41, Daniel P. Berrangé wrote:
> >> On Wed, Apr 24, 2019 at 11:35:40AM +0200, David Hildenbrand wrote:
> >>> On 24.04.19 11:30, Daniel P. Berrangé wrote:
> >>>> On Wed, Apr 24, 2019 at 11:03:03AM +0200, David Hildenbrand wrote:
> >>>>> On 24.04.19 10:40, Christian Borntraeger wrote:
> >>>>>>
> >>>>>>
> >>>>>> On 23.04.19 14:11, David Hildenbrand wrote:
> >>>>>>> On 18.04.19 13:31, Christian Borntraeger wrote:
> >>>>>>>> Adding generation 15.
> >>>>>>>>
> >>>>>>>> Some interesting aspects:
> >>>>>>>> - conditional SSKE and bpb are deprecated. This patch set addresses that
> >>>>>>>>   for csske.
> >>>>>>>> - no name yet for gen15, I suggest to use the assigned numbers and
> >>>>>>>>   provide an alias later on. (I have split out this into a separate
> >>>>>>>>   patch)
> >>>>>>>>
> >>>>>>>> Christian Borntraeger (10):
> >>>>>>>>   linux header sync
> >>>>>>>>   s390x/cpumodel: remove CSSKE from base model
> >>>>>>>>   s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3
> >>>>>>>>   s390x/cpumodel: msa9 facility
> >>>>>>>>   s390x/cpumodel: vector enhancements
> >>>>>>>>   s390x/cpumodel: enhanced sort facility
> >>>>>>>>   s390x/cpumodel: deflate
> >>>>>>>>   s390x/cpumodel: add gen15 defintions
> >>>>>>>>   s390x/cpumodel: wire up 8561 and 8562 as gen15 machines
> >>>>>>>>   s390x/cpumodel: do not claim csske for expanded models in qmp
> >>>>>>>>
> >>>>>>>>  hw/s390x/s390-virtio-ccw.c      |  6 +++
> >>>>>>>>  linux-headers/asm-s390/kvm.h    |  5 +-
> >>>>>>>>  target/s390x/cpu_features.c     | 54 +++++++++++++++++++
> >>>>>>>>  target/s390x/cpu_features.h     |  3 ++
> >>>>>>>>  target/s390x/cpu_features_def.h | 49 +++++++++++++++++
> >>>>>>>>  target/s390x/cpu_models.c       | 35 ++++++++++++
> >>>>>>>>  target/s390x/cpu_models.h       |  1 +
> >>>>>>>>  target/s390x/gen-features.c     | 94 ++++++++++++++++++++++++++++++++-
> >>>>>>>>  target/s390x/kvm.c              | 18 +++++++
> >>>>>>>>  9 files changed, 263 insertions(+), 2 deletions(-)
> >>>>>>>>
> >>>>>>>
> >>>>>>> I guess to handle deprecation of CSSKE:
> >>>>>>>
> >>>>>>> 1. Remove it from the base + default model of the gen15, keep it in the
> >>>>>>> max model. This is completely done in target/s390x/gen-features.c.
> >>>>>>> Existing base models are not modified.
> >>>>>>>
> >>>>>>> 2. Add CSSKE to "ignored_base_feat", so fallback of gen15 to e.g. z14
> >>>>>>> will work. We can backport this to distros/stable.
> >>>>>>
> >>>>>> Yes, I have already implemented that, still doing some testing and polishinh.
> >>>>>>>
> >>>>>>>
> >>>>>>> CPU model expansion:
> >>>>>>>
> >>>>>>> cpu_info_from_model() should already properly be based on the base
> >>>>>>> features. "gen15" vs. "gen15,csske=on" should be automatically generated
> >>>>>>> when expanding.
> >>>>>>>
> >>>>>>> CPU model baseline:
> >>>>>>>
> >>>>>>> s390_find_cpu_def() should make sure that CSSKE is basically ignored
> >>>>>>> when determining maximum model, however it will properly be indicated if
> >>>>>>> both models had the feature.
> >>>>>>>
> >>>>>>> CPU model comparison:
> >>>>>>>
> >>>>>>> Should work as expected. Availability of CSSKE will be considered when
> >>>>>>> calculating the result.
> >>>>>>>
> >>>>>>> gen14,csske=on and gen15,csske=off will result in
> >>>>>>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE.
> >>>>>>>
> >>>>>>> gen14,csske=off and gen15,csske=off should result in
> >>>>>>> CPU_MODEL_COMPARE_RESULT_SUBSET
> >>>>>>>
> >>>>>>> gen14,csske=on and gen15,csske=on should result in
> >>>>>>> CPU_MODEL_COMPARE_RESULT_SUBSET
> >>>>>>>
> >>>>>>> Forward migration:
> >>>>>>>
> >>>>>>> Now, the only issue is when csske is actually turned of in future
> >>>>>>> machines. We would e.g. have
> >>>>>>>
> >>>>>>> gen15,csske=on and gen16,csske=off
> >>>>>>>
> >>>>>>> While baselining will work correctly (gen15,csske=off), forward
> >>>>>>> migration is broken (comparison will properly indicate
> >>>>>>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE), which is expected when ripping
> >>>>>>> out features. Same applies to BPB.
> >>>>>>>
> >>>>>>>
> >>>>>>> Your patch "[PATCH 10/10] s390x/cpumodel: do not claim csske for
> >>>>>>> expanded models in qmp" tried to address this, however I am not really
> >>>>>>> happy with this approach. We should not play such tricks when expanding
> >>>>>>> the host model. "-cpu host" and "-cpu $expanded_host" would be
> >>>>>>> different,
> >>>>>>
> >>>>>> We discussed this some time ago and I think we agreed that for host passthrough
> >>>>>> it is ok to be different that host-model (e.g. passing through the cpuid, passing
> >>>>>> through all non-hypervisor managed features etc).
> >>>>>
> >>>>> I remember the plan was to use the "max" model to do such stuff. E.g.
> >>>>> -cpu max / no -cpu
> >>>>>
> >>>>> Versus
> >>>>> -cpu host
> >>>>>
> >>>>> We can have features in "host" we don't have in "max". But "-cpu host"
> >>>>> and it's expansion should look 100% the same.
> >>>>
> >>>> I don't think that's the intended semantics of "max" vs "host".
> >>>>
> >>>> The "max" CPU model is supposed to enable all features that are possible to
> >>>> enable.
> >>>>
> >>>> For KVM, thus "max" should be identical to "host".
> >>>
> >>> There once was a mode used by x86-64 to simply pipe through cpuid
> >>> features that were not even supported. (I remember something like
> >>> passthorugh=true), do you remember if something like that still exists?
> >>
> >> I don't recall such a feature existing even in the past !
> > 
> > Maybe my mind is tricking me, or maybe that has long been removed :)
> > 
> >>
> >>>> For TCG, "max" should be everything that QEMU currently knows how to emulate.
> >>>
> >>> Yes, and on s390x. "max" contains more features than "qemu".
> >>>
> >>>>
> >>>> Essentially think of "max" as a better name for "host", since "host" as
> >>>> a name concept didn't make sense for TCG.
> >>>
> >>> I agree. The main question is, is it acceptable that
> >>
> >> Hmm, maybe I misinterpreted when you wrote
> >>
> >>       We can have features in "host" we don't have in "max"
> >>
> >> I read that as meaning that "-cpu host" and "-cpu max" would be
> >> different.
> > 
> > No you didn't misinterpret it, I agreed after you spelled it out :)
> > 
> >>
> >>> "-cpu host" and "-cpu $expanded_host" produce different results, after
> >>> expanding "host" via query-cpu-model-expansion?
> >>
> >> That has always been the case on x86-64, since it is not possible to set
> >> the level, xlevel, vendor, family, model & stepping properties via -cpu,
> >> only the feature flags.
> > 
> > Fair enough, but the question is if we should mess with feature flags we
> > can indicate on that level.
> > 
> > It would mean that on a specific host e.g.
> > 
> > "-cpu gen15,csske=on" and "-cpu gen15,csske=off"
> > 
> > Would work. However, "host" model expansion would give us
> > 
> > "-cpu gen15,csske=off"
> > 
> > So trying to e.g. do a query-cpu-model-comparison or
> > query-cpu-model-baseline against "host" and against the expanded host
> > model will produce different results.
> > 
> > Libvirt could detect "-cpu gen14,csske=on" as not runnable on the host,
> > because comparing "-cpu gen14,csske=on" vs. "-cpu gen15,csske=off" would
> > be "incompatible". But running "-cpu gen14,csske=on" on the host would
> > work perfectly fine.
> 
> I would like to avoid special knowledge in libvirt (since we moved to have
> everything in qemu). 
> 
> A more complex idea would be to extend the qmp query with a list of deprecated
> features and libvirt could then disable that for expansion but allow it for
> baselining.

Funny that you mention deprecation with CPU features....

  https://lists.gnu.org/archive/html/qemu-devel/2019-04/msg03969.html

So that makes 4 things we want to report deprecation for. Devices,
machine types, cpu models and now cpu features.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [Qemu-devel] [PATCH 00/10] s390x: new guest features

[Christian Borntraeger]

On 24.04.19 12:27, David Hildenbrand wrote:
> On 24.04.19 12:26, Christian Borntraeger wrote:
>>
>>
>> On 24.04.19 11:56, David Hildenbrand wrote:
>>> On 24.04.19 11:41, Daniel P. Berrangé wrote:
>>>> On Wed, Apr 24, 2019 at 11:35:40AM +0200, David Hildenbrand wrote:
>>>>> On 24.04.19 11:30, Daniel P. Berrangé wrote:
>>>>>> On Wed, Apr 24, 2019 at 11:03:03AM +0200, David Hildenbrand wrote:
>>>>>>> On 24.04.19 10:40, Christian Borntraeger wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 23.04.19 14:11, David Hildenbrand wrote:
>>>>>>>>> On 18.04.19 13:31, Christian Borntraeger wrote:
>>>>>>>>>> Adding generation 15.
>>>>>>>>>>
>>>>>>>>>> Some interesting aspects:
>>>>>>>>>> - conditional SSKE and bpb are deprecated. This patch set addresses that
>>>>>>>>>>   for csske.
>>>>>>>>>> - no name yet for gen15, I suggest to use the assigned numbers and
>>>>>>>>>>   provide an alias later on. (I have split out this into a separate
>>>>>>>>>>   patch)
>>>>>>>>>>
>>>>>>>>>> Christian Borntraeger (10):
>>>>>>>>>>   linux header sync
>>>>>>>>>>   s390x/cpumodel: remove CSSKE from base model
>>>>>>>>>>   s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3
>>>>>>>>>>   s390x/cpumodel: msa9 facility
>>>>>>>>>>   s390x/cpumodel: vector enhancements
>>>>>>>>>>   s390x/cpumodel: enhanced sort facility
>>>>>>>>>>   s390x/cpumodel: deflate
>>>>>>>>>>   s390x/cpumodel: add gen15 defintions
>>>>>>>>>>   s390x/cpumodel: wire up 8561 and 8562 as gen15 machines
>>>>>>>>>>   s390x/cpumodel: do not claim csske for expanded models in qmp
>>>>>>>>>>
>>>>>>>>>>  hw/s390x/s390-virtio-ccw.c      |  6 +++
>>>>>>>>>>  linux-headers/asm-s390/kvm.h    |  5 +-
>>>>>>>>>>  target/s390x/cpu_features.c     | 54 +++++++++++++++++++
>>>>>>>>>>  target/s390x/cpu_features.h     |  3 ++
>>>>>>>>>>  target/s390x/cpu_features_def.h | 49 +++++++++++++++++
>>>>>>>>>>  target/s390x/cpu_models.c       | 35 ++++++++++++
>>>>>>>>>>  target/s390x/cpu_models.h       |  1 +
>>>>>>>>>>  target/s390x/gen-features.c     | 94 ++++++++++++++++++++++++++++++++-
>>>>>>>>>>  target/s390x/kvm.c              | 18 +++++++
>>>>>>>>>>  9 files changed, 263 insertions(+), 2 deletions(-)
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I guess to handle deprecation of CSSKE:
>>>>>>>>>
>>>>>>>>> 1. Remove it from the base + default model of the gen15, keep it in the
>>>>>>>>> max model. This is completely done in target/s390x/gen-features.c.
>>>>>>>>> Existing base models are not modified.
>>>>>>>>>
>>>>>>>>> 2. Add CSSKE to "ignored_base_feat", so fallback of gen15 to e.g. z14
>>>>>>>>> will work. We can backport this to distros/stable.
>>>>>>>>
>>>>>>>> Yes, I have already implemented that, still doing some testing and polishinh.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> CPU model expansion:
>>>>>>>>>
>>>>>>>>> cpu_info_from_model() should already properly be based on the base
>>>>>>>>> features. "gen15" vs. "gen15,csske=on" should be automatically generated
>>>>>>>>> when expanding.
>>>>>>>>>
>>>>>>>>> CPU model baseline:
>>>>>>>>>
>>>>>>>>> s390_find_cpu_def() should make sure that CSSKE is basically ignored
>>>>>>>>> when determining maximum model, however it will properly be indicated if
>>>>>>>>> both models had the feature.
>>>>>>>>>
>>>>>>>>> CPU model comparison:
>>>>>>>>>
>>>>>>>>> Should work as expected. Availability of CSSKE will be considered when
>>>>>>>>> calculating the result.
>>>>>>>>>
>>>>>>>>> gen14,csske=on and gen15,csske=off will result in
>>>>>>>>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE.
>>>>>>>>>
>>>>>>>>> gen14,csske=off and gen15,csske=off should result in
>>>>>>>>> CPU_MODEL_COMPARE_RESULT_SUBSET
>>>>>>>>>
>>>>>>>>> gen14,csske=on and gen15,csske=on should result in
>>>>>>>>> CPU_MODEL_COMPARE_RESULT_SUBSET
>>>>>>>>>
>>>>>>>>> Forward migration:
>>>>>>>>>
>>>>>>>>> Now, the only issue is when csske is actually turned of in future
>>>>>>>>> machines. We would e.g. have
>>>>>>>>>
>>>>>>>>> gen15,csske=on and gen16,csske=off
>>>>>>>>>
>>>>>>>>> While baselining will work correctly (gen15,csske=off), forward
>>>>>>>>> migration is broken (comparison will properly indicate
>>>>>>>>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE), which is expected when ripping
>>>>>>>>> out features. Same applies to BPB.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Your patch "[PATCH 10/10] s390x/cpumodel: do not claim csske for
>>>>>>>>> expanded models in qmp" tried to address this, however I am not really
>>>>>>>>> happy with this approach. We should not play such tricks when expanding
>>>>>>>>> the host model. "-cpu host" and "-cpu $expanded_host" would be
>>>>>>>>> different,
>>>>>>>>
>>>>>>>> We discussed this some time ago and I think we agreed that for host passthrough
>>>>>>>> it is ok to be different that host-model (e.g. passing through the cpuid, passing
>>>>>>>> through all non-hypervisor managed features etc).
>>>>>>>
>>>>>>> I remember the plan was to use the "max" model to do such stuff. E.g.
>>>>>>> -cpu max / no -cpu
>>>>>>>
>>>>>>> Versus
>>>>>>> -cpu host
>>>>>>>
>>>>>>> We can have features in "host" we don't have in "max". But "-cpu host"
>>>>>>> and it's expansion should look 100% the same.
>>>>>>
>>>>>> I don't think that's the intended semantics of "max" vs "host".
>>>>>>
>>>>>> The "max" CPU model is supposed to enable all features that are possible to
>>>>>> enable.
>>>>>>
>>>>>> For KVM, thus "max" should be identical to "host".
>>>>>
>>>>> There once was a mode used by x86-64 to simply pipe through cpuid
>>>>> features that were not even supported. (I remember something like
>>>>> passthorugh=true), do you remember if something like that still exists?
>>>>
>>>> I don't recall such a feature existing even in the past !
>>>
>>> Maybe my mind is tricking me, or maybe that has long been removed :)
>>>
>>>>
>>>>>> For TCG, "max" should be everything that QEMU currently knows how to emulate.
>>>>>
>>>>> Yes, and on s390x. "max" contains more features than "qemu".
>>>>>
>>>>>>
>>>>>> Essentially think of "max" as a better name for "host", since "host" as
>>>>>> a name concept didn't make sense for TCG.
>>>>>
>>>>> I agree. The main question is, is it acceptable that
>>>>
>>>> Hmm, maybe I misinterpreted when you wrote
>>>>
>>>>       We can have features in "host" we don't have in "max"
>>>>
>>>> I read that as meaning that "-cpu host" and "-cpu max" would be
>>>> different.
>>>
>>> No you didn't misinterpret it, I agreed after you spelled it out :)
>>>
>>>>
>>>>> "-cpu host" and "-cpu $expanded_host" produce different results, after
>>>>> expanding "host" via query-cpu-model-expansion?
>>>>
>>>> That has always been the case on x86-64, since it is not possible to set
>>>> the level, xlevel, vendor, family, model & stepping properties via -cpu,
>>>> only the feature flags.
>>>
>>> Fair enough, but the question is if we should mess with feature flags we
>>> can indicate on that level.
>>>
>>> It would mean that on a specific host e.g.
>>>
>>> "-cpu gen15,csske=on" and "-cpu gen15,csske=off"
>>>
>>> Would work. However, "host" model expansion would give us
>>>
>>> "-cpu gen15,csske=off"
>>>
>>> So trying to e.g. do a query-cpu-model-comparison or
>>> query-cpu-model-baseline against "host" and against the expanded host
>>> model will produce different results.
>>>
>>> Libvirt could detect "-cpu gen14,csske=on" as not runnable on the host,
>>> because comparing "-cpu gen14,csske=on" vs. "-cpu gen15,csske=off" would
>>> be "incompatible". But running "-cpu gen14,csske=on" on the host would
>>> work perfectly fine.
>>
>> I would like to avoid special knowledge in libvirt (since we moved to have
>> everything in qemu). 
>>
>> A more complex idea would be to extend the qmp query with a list of deprecated
>> features and libvirt could then disable that for expansion but allow it for
>> baselining.
> 
> That would fit in nicely into query-cpu-model-expansion. Nice idea.

Hmm, I think that should also be possible as an add-on patch series later on
(e.g. in 6 month or so). We would have instances of gen15 machines with host-model
that start with csske but sooner or later they will be restarted and then they no 
longer have csske.
As we do not change anything for baselining this would allow us to separate patch10
from the other patches and deal with it later with a proper series on its on?
Need to think about that.

Re: [Qemu-devel] [PATCH 00/10] s390x: new guest features

[Christian Borntraeger]

On 24.04.19 12:27, David Hildenbrand wrote:
> On 24.04.19 12:26, Christian Borntraeger wrote:
>>
>>
>> On 24.04.19 11:56, David Hildenbrand wrote:
>>> On 24.04.19 11:41, Daniel P. Berrangé wrote:
>>>> On Wed, Apr 24, 2019 at 11:35:40AM +0200, David Hildenbrand wrote:
>>>>> On 24.04.19 11:30, Daniel P. Berrangé wrote:
>>>>>> On Wed, Apr 24, 2019 at 11:03:03AM +0200, David Hildenbrand wrote:
>>>>>>> On 24.04.19 10:40, Christian Borntraeger wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 23.04.19 14:11, David Hildenbrand wrote:
>>>>>>>>> On 18.04.19 13:31, Christian Borntraeger wrote:
>>>>>>>>>> Adding generation 15.
>>>>>>>>>>
>>>>>>>>>> Some interesting aspects:
>>>>>>>>>> - conditional SSKE and bpb are deprecated. This patch set addresses that
>>>>>>>>>>   for csske.
>>>>>>>>>> - no name yet for gen15, I suggest to use the assigned numbers and
>>>>>>>>>>   provide an alias later on. (I have split out this into a separate
>>>>>>>>>>   patch)
>>>>>>>>>>
>>>>>>>>>> Christian Borntraeger (10):
>>>>>>>>>>   linux header sync
>>>>>>>>>>   s390x/cpumodel: remove CSSKE from base model
>>>>>>>>>>   s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3
>>>>>>>>>>   s390x/cpumodel: msa9 facility
>>>>>>>>>>   s390x/cpumodel: vector enhancements
>>>>>>>>>>   s390x/cpumodel: enhanced sort facility
>>>>>>>>>>   s390x/cpumodel: deflate
>>>>>>>>>>   s390x/cpumodel: add gen15 defintions
>>>>>>>>>>   s390x/cpumodel: wire up 8561 and 8562 as gen15 machines
>>>>>>>>>>   s390x/cpumodel: do not claim csske for expanded models in qmp
>>>>>>>>>>
>>>>>>>>>>  hw/s390x/s390-virtio-ccw.c      |  6 +++
>>>>>>>>>>  linux-headers/asm-s390/kvm.h    |  5 +-
>>>>>>>>>>  target/s390x/cpu_features.c     | 54 +++++++++++++++++++
>>>>>>>>>>  target/s390x/cpu_features.h     |  3 ++
>>>>>>>>>>  target/s390x/cpu_features_def.h | 49 +++++++++++++++++
>>>>>>>>>>  target/s390x/cpu_models.c       | 35 ++++++++++++
>>>>>>>>>>  target/s390x/cpu_models.h       |  1 +
>>>>>>>>>>  target/s390x/gen-features.c     | 94 ++++++++++++++++++++++++++++++++-
>>>>>>>>>>  target/s390x/kvm.c              | 18 +++++++
>>>>>>>>>>  9 files changed, 263 insertions(+), 2 deletions(-)
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I guess to handle deprecation of CSSKE:
>>>>>>>>>
>>>>>>>>> 1. Remove it from the base + default model of the gen15, keep it in the
>>>>>>>>> max model. This is completely done in target/s390x/gen-features.c.
>>>>>>>>> Existing base models are not modified.
>>>>>>>>>
>>>>>>>>> 2. Add CSSKE to "ignored_base_feat", so fallback of gen15 to e.g. z14
>>>>>>>>> will work. We can backport this to distros/stable.
>>>>>>>>
>>>>>>>> Yes, I have already implemented that, still doing some testing and polishinh.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> CPU model expansion:
>>>>>>>>>
>>>>>>>>> cpu_info_from_model() should already properly be based on the base
>>>>>>>>> features. "gen15" vs. "gen15,csske=on" should be automatically generated
>>>>>>>>> when expanding.
>>>>>>>>>
>>>>>>>>> CPU model baseline:
>>>>>>>>>
>>>>>>>>> s390_find_cpu_def() should make sure that CSSKE is basically ignored
>>>>>>>>> when determining maximum model, however it will properly be indicated if
>>>>>>>>> both models had the feature.
>>>>>>>>>
>>>>>>>>> CPU model comparison:
>>>>>>>>>
>>>>>>>>> Should work as expected. Availability of CSSKE will be considered when
>>>>>>>>> calculating the result.
>>>>>>>>>
>>>>>>>>> gen14,csske=on and gen15,csske=off will result in
>>>>>>>>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE.
>>>>>>>>>
>>>>>>>>> gen14,csske=off and gen15,csske=off should result in
>>>>>>>>> CPU_MODEL_COMPARE_RESULT_SUBSET
>>>>>>>>>
>>>>>>>>> gen14,csske=on and gen15,csske=on should result in
>>>>>>>>> CPU_MODEL_COMPARE_RESULT_SUBSET
>>>>>>>>>
>>>>>>>>> Forward migration:
>>>>>>>>>
>>>>>>>>> Now, the only issue is when csske is actually turned of in future
>>>>>>>>> machines. We would e.g. have
>>>>>>>>>
>>>>>>>>> gen15,csske=on and gen16,csske=off
>>>>>>>>>
>>>>>>>>> While baselining will work correctly (gen15,csske=off), forward
>>>>>>>>> migration is broken (comparison will properly indicate
>>>>>>>>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE), which is expected when ripping
>>>>>>>>> out features. Same applies to BPB.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Your patch "[PATCH 10/10] s390x/cpumodel: do not claim csske for
>>>>>>>>> expanded models in qmp" tried to address this, however I am not really
>>>>>>>>> happy with this approach. We should not play such tricks when expanding
>>>>>>>>> the host model. "-cpu host" and "-cpu $expanded_host" would be
>>>>>>>>> different,
>>>>>>>>
>>>>>>>> We discussed this some time ago and I think we agreed that for host passthrough
>>>>>>>> it is ok to be different that host-model (e.g. passing through the cpuid, passing
>>>>>>>> through all non-hypervisor managed features etc).
>>>>>>>
>>>>>>> I remember the plan was to use the "max" model to do such stuff. E.g.
>>>>>>> -cpu max / no -cpu
>>>>>>>
>>>>>>> Versus
>>>>>>> -cpu host
>>>>>>>
>>>>>>> We can have features in "host" we don't have in "max". But "-cpu host"
>>>>>>> and it's expansion should look 100% the same.
>>>>>>
>>>>>> I don't think that's the intended semantics of "max" vs "host".
>>>>>>
>>>>>> The "max" CPU model is supposed to enable all features that are possible to
>>>>>> enable.
>>>>>>
>>>>>> For KVM, thus "max" should be identical to "host".
>>>>>
>>>>> There once was a mode used by x86-64 to simply pipe through cpuid
>>>>> features that were not even supported. (I remember something like
>>>>> passthorugh=true), do you remember if something like that still exists?
>>>>
>>>> I don't recall such a feature existing even in the past !
>>>
>>> Maybe my mind is tricking me, or maybe that has long been removed :)
>>>
>>>>
>>>>>> For TCG, "max" should be everything that QEMU currently knows how to emulate.
>>>>>
>>>>> Yes, and on s390x. "max" contains more features than "qemu".
>>>>>
>>>>>>
>>>>>> Essentially think of "max" as a better name for "host", since "host" as
>>>>>> a name concept didn't make sense for TCG.
>>>>>
>>>>> I agree. The main question is, is it acceptable that
>>>>
>>>> Hmm, maybe I misinterpreted when you wrote
>>>>
>>>>       We can have features in "host" we don't have in "max"
>>>>
>>>> I read that as meaning that "-cpu host" and "-cpu max" would be
>>>> different.
>>>
>>> No you didn't misinterpret it, I agreed after you spelled it out :)
>>>
>>>>
>>>>> "-cpu host" and "-cpu $expanded_host" produce different results, after
>>>>> expanding "host" via query-cpu-model-expansion?
>>>>
>>>> That has always been the case on x86-64, since it is not possible to set
>>>> the level, xlevel, vendor, family, model & stepping properties via -cpu,
>>>> only the feature flags.
>>>
>>> Fair enough, but the question is if we should mess with feature flags we
>>> can indicate on that level.
>>>
>>> It would mean that on a specific host e.g.
>>>
>>> "-cpu gen15,csske=on" and "-cpu gen15,csske=off"
>>>
>>> Would work. However, "host" model expansion would give us
>>>
>>> "-cpu gen15,csske=off"
>>>
>>> So trying to e.g. do a query-cpu-model-comparison or
>>> query-cpu-model-baseline against "host" and against the expanded host
>>> model will produce different results.
>>>
>>> Libvirt could detect "-cpu gen14,csske=on" as not runnable on the host,
>>> because comparing "-cpu gen14,csske=on" vs. "-cpu gen15,csske=off" would
>>> be "incompatible". But running "-cpu gen14,csske=on" on the host would
>>> work perfectly fine.
>>
>> I would like to avoid special knowledge in libvirt (since we moved to have
>> everything in qemu). 
>>
>> A more complex idea would be to extend the qmp query with a list of deprecated
>> features and libvirt could then disable that for expansion but allow it for
>> baselining.
> 
> That would fit in nicely into query-cpu-model-expansion. Nice idea.

Hmm, I think that should also be possible as an add-on patch series later on
(e.g. in 6 month or so). We would have instances of gen15 machines with host-model
that start with csske but sooner or later they will be restarted and then they no 
longer have csske.
As we do not change anything for baselining this would allow us to separate patch10
from the other patches and deal with it later with a proper series on its on?
Need to think about that.

Re: [Qemu-devel] [PATCH 00/10] s390x: new guest features

[David Hildenbrand]

On 24.04.19 12:38, Christian Borntraeger wrote:
> 
> 
> On 24.04.19 12:27, David Hildenbrand wrote:
>> On 24.04.19 12:26, Christian Borntraeger wrote:
>>>
>>>
>>> On 24.04.19 11:56, David Hildenbrand wrote:
>>>> On 24.04.19 11:41, Daniel P. Berrangé wrote:
>>>>> On Wed, Apr 24, 2019 at 11:35:40AM +0200, David Hildenbrand wrote:
>>>>>> On 24.04.19 11:30, Daniel P. Berrangé wrote:
>>>>>>> On Wed, Apr 24, 2019 at 11:03:03AM +0200, David Hildenbrand wrote:
>>>>>>>> On 24.04.19 10:40, Christian Borntraeger wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 23.04.19 14:11, David Hildenbrand wrote:
>>>>>>>>>> On 18.04.19 13:31, Christian Borntraeger wrote:
>>>>>>>>>>> Adding generation 15.
>>>>>>>>>>>
>>>>>>>>>>> Some interesting aspects:
>>>>>>>>>>> - conditional SSKE and bpb are deprecated. This patch set addresses that
>>>>>>>>>>>   for csske.
>>>>>>>>>>> - no name yet for gen15, I suggest to use the assigned numbers and
>>>>>>>>>>>   provide an alias later on. (I have split out this into a separate
>>>>>>>>>>>   patch)
>>>>>>>>>>>
>>>>>>>>>>> Christian Borntraeger (10):
>>>>>>>>>>>   linux header sync
>>>>>>>>>>>   s390x/cpumodel: remove CSSKE from base model
>>>>>>>>>>>   s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3
>>>>>>>>>>>   s390x/cpumodel: msa9 facility
>>>>>>>>>>>   s390x/cpumodel: vector enhancements
>>>>>>>>>>>   s390x/cpumodel: enhanced sort facility
>>>>>>>>>>>   s390x/cpumodel: deflate
>>>>>>>>>>>   s390x/cpumodel: add gen15 defintions
>>>>>>>>>>>   s390x/cpumodel: wire up 8561 and 8562 as gen15 machines
>>>>>>>>>>>   s390x/cpumodel: do not claim csske for expanded models in qmp
>>>>>>>>>>>
>>>>>>>>>>>  hw/s390x/s390-virtio-ccw.c      |  6 +++
>>>>>>>>>>>  linux-headers/asm-s390/kvm.h    |  5 +-
>>>>>>>>>>>  target/s390x/cpu_features.c     | 54 +++++++++++++++++++
>>>>>>>>>>>  target/s390x/cpu_features.h     |  3 ++
>>>>>>>>>>>  target/s390x/cpu_features_def.h | 49 +++++++++++++++++
>>>>>>>>>>>  target/s390x/cpu_models.c       | 35 ++++++++++++
>>>>>>>>>>>  target/s390x/cpu_models.h       |  1 +
>>>>>>>>>>>  target/s390x/gen-features.c     | 94 ++++++++++++++++++++++++++++++++-
>>>>>>>>>>>  target/s390x/kvm.c              | 18 +++++++
>>>>>>>>>>>  9 files changed, 263 insertions(+), 2 deletions(-)
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I guess to handle deprecation of CSSKE:
>>>>>>>>>>
>>>>>>>>>> 1. Remove it from the base + default model of the gen15, keep it in the
>>>>>>>>>> max model. This is completely done in target/s390x/gen-features.c.
>>>>>>>>>> Existing base models are not modified.
>>>>>>>>>>
>>>>>>>>>> 2. Add CSSKE to "ignored_base_feat", so fallback of gen15 to e.g. z14
>>>>>>>>>> will work. We can backport this to distros/stable.
>>>>>>>>>
>>>>>>>>> Yes, I have already implemented that, still doing some testing and polishinh.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> CPU model expansion:
>>>>>>>>>>
>>>>>>>>>> cpu_info_from_model() should already properly be based on the base
>>>>>>>>>> features. "gen15" vs. "gen15,csske=on" should be automatically generated
>>>>>>>>>> when expanding.
>>>>>>>>>>
>>>>>>>>>> CPU model baseline:
>>>>>>>>>>
>>>>>>>>>> s390_find_cpu_def() should make sure that CSSKE is basically ignored
>>>>>>>>>> when determining maximum model, however it will properly be indicated if
>>>>>>>>>> both models had the feature.
>>>>>>>>>>
>>>>>>>>>> CPU model comparison:
>>>>>>>>>>
>>>>>>>>>> Should work as expected. Availability of CSSKE will be considered when
>>>>>>>>>> calculating the result.
>>>>>>>>>>
>>>>>>>>>> gen14,csske=on and gen15,csske=off will result in
>>>>>>>>>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE.
>>>>>>>>>>
>>>>>>>>>> gen14,csske=off and gen15,csske=off should result in
>>>>>>>>>> CPU_MODEL_COMPARE_RESULT_SUBSET
>>>>>>>>>>
>>>>>>>>>> gen14,csske=on and gen15,csske=on should result in
>>>>>>>>>> CPU_MODEL_COMPARE_RESULT_SUBSET
>>>>>>>>>>
>>>>>>>>>> Forward migration:
>>>>>>>>>>
>>>>>>>>>> Now, the only issue is when csske is actually turned of in future
>>>>>>>>>> machines. We would e.g. have
>>>>>>>>>>
>>>>>>>>>> gen15,csske=on and gen16,csske=off
>>>>>>>>>>
>>>>>>>>>> While baselining will work correctly (gen15,csske=off), forward
>>>>>>>>>> migration is broken (comparison will properly indicate
>>>>>>>>>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE), which is expected when ripping
>>>>>>>>>> out features. Same applies to BPB.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Your patch "[PATCH 10/10] s390x/cpumodel: do not claim csske for
>>>>>>>>>> expanded models in qmp" tried to address this, however I am not really
>>>>>>>>>> happy with this approach. We should not play such tricks when expanding
>>>>>>>>>> the host model. "-cpu host" and "-cpu $expanded_host" would be
>>>>>>>>>> different,
>>>>>>>>>
>>>>>>>>> We discussed this some time ago and I think we agreed that for host passthrough
>>>>>>>>> it is ok to be different that host-model (e.g. passing through the cpuid, passing
>>>>>>>>> through all non-hypervisor managed features etc).
>>>>>>>>
>>>>>>>> I remember the plan was to use the "max" model to do such stuff. E.g.
>>>>>>>> -cpu max / no -cpu
>>>>>>>>
>>>>>>>> Versus
>>>>>>>> -cpu host
>>>>>>>>
>>>>>>>> We can have features in "host" we don't have in "max". But "-cpu host"
>>>>>>>> and it's expansion should look 100% the same.
>>>>>>>
>>>>>>> I don't think that's the intended semantics of "max" vs "host".
>>>>>>>
>>>>>>> The "max" CPU model is supposed to enable all features that are possible to
>>>>>>> enable.
>>>>>>>
>>>>>>> For KVM, thus "max" should be identical to "host".
>>>>>>
>>>>>> There once was a mode used by x86-64 to simply pipe through cpuid
>>>>>> features that were not even supported. (I remember something like
>>>>>> passthorugh=true), do you remember if something like that still exists?
>>>>>
>>>>> I don't recall such a feature existing even in the past !
>>>>
>>>> Maybe my mind is tricking me, or maybe that has long been removed :)
>>>>
>>>>>
>>>>>>> For TCG, "max" should be everything that QEMU currently knows how to emulate.
>>>>>>
>>>>>> Yes, and on s390x. "max" contains more features than "qemu".
>>>>>>
>>>>>>>
>>>>>>> Essentially think of "max" as a better name for "host", since "host" as
>>>>>>> a name concept didn't make sense for TCG.
>>>>>>
>>>>>> I agree. The main question is, is it acceptable that
>>>>>
>>>>> Hmm, maybe I misinterpreted when you wrote
>>>>>
>>>>>       We can have features in "host" we don't have in "max"
>>>>>
>>>>> I read that as meaning that "-cpu host" and "-cpu max" would be
>>>>> different.
>>>>
>>>> No you didn't misinterpret it, I agreed after you spelled it out :)
>>>>
>>>>>
>>>>>> "-cpu host" and "-cpu $expanded_host" produce different results, after
>>>>>> expanding "host" via query-cpu-model-expansion?
>>>>>
>>>>> That has always been the case on x86-64, since it is not possible to set
>>>>> the level, xlevel, vendor, family, model & stepping properties via -cpu,
>>>>> only the feature flags.
>>>>
>>>> Fair enough, but the question is if we should mess with feature flags we
>>>> can indicate on that level.
>>>>
>>>> It would mean that on a specific host e.g.
>>>>
>>>> "-cpu gen15,csske=on" and "-cpu gen15,csske=off"
>>>>
>>>> Would work. However, "host" model expansion would give us
>>>>
>>>> "-cpu gen15,csske=off"
>>>>
>>>> So trying to e.g. do a query-cpu-model-comparison or
>>>> query-cpu-model-baseline against "host" and against the expanded host
>>>> model will produce different results.
>>>>
>>>> Libvirt could detect "-cpu gen14,csske=on" as not runnable on the host,
>>>> because comparing "-cpu gen14,csske=on" vs. "-cpu gen15,csske=off" would
>>>> be "incompatible". But running "-cpu gen14,csske=on" on the host would
>>>> work perfectly fine.
>>>
>>> I would like to avoid special knowledge in libvirt (since we moved to have
>>> everything in qemu). 
>>>
>>> A more complex idea would be to extend the qmp query with a list of deprecated
>>> features and libvirt could then disable that for expansion but allow it for
>>> baselining.
>>
>> That would fit in nicely into query-cpu-model-expansion. Nice idea.
> 
> Hmm, I think that should also be possible as an add-on patch series later on
> (e.g. in 6 month or so). We would have instances of gen15 machines with host-model
> that start with csske but sooner or later they will be restarted and then they no 
> longer have csske.
> As we do not change anything for baselining this would allow us to separate patch10
> from the other patches and deal with it later with a proper series on its on?
> Need to think about that.

Makes sense, we already have forward migration issues to > gen15 with
guests started in the past when dropping features. No need to rush with
that.

-- 

Thanks,

David / dhildenb

Re: [Qemu-devel] [PATCH 00/10] s390x: new guest features

[David Hildenbrand]

On 24.04.19 12:38, Christian Borntraeger wrote:
> 
> 
> On 24.04.19 12:27, David Hildenbrand wrote:
>> On 24.04.19 12:26, Christian Borntraeger wrote:
>>>
>>>
>>> On 24.04.19 11:56, David Hildenbrand wrote:
>>>> On 24.04.19 11:41, Daniel P. Berrangé wrote:
>>>>> On Wed, Apr 24, 2019 at 11:35:40AM +0200, David Hildenbrand wrote:
>>>>>> On 24.04.19 11:30, Daniel P. Berrangé wrote:
>>>>>>> On Wed, Apr 24, 2019 at 11:03:03AM +0200, David Hildenbrand wrote:
>>>>>>>> On 24.04.19 10:40, Christian Borntraeger wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 23.04.19 14:11, David Hildenbrand wrote:
>>>>>>>>>> On 18.04.19 13:31, Christian Borntraeger wrote:
>>>>>>>>>>> Adding generation 15.
>>>>>>>>>>>
>>>>>>>>>>> Some interesting aspects:
>>>>>>>>>>> - conditional SSKE and bpb are deprecated. This patch set addresses that
>>>>>>>>>>>   for csske.
>>>>>>>>>>> - no name yet for gen15, I suggest to use the assigned numbers and
>>>>>>>>>>>   provide an alias later on. (I have split out this into a separate
>>>>>>>>>>>   patch)
>>>>>>>>>>>
>>>>>>>>>>> Christian Borntraeger (10):
>>>>>>>>>>>   linux header sync
>>>>>>>>>>>   s390x/cpumodel: remove CSSKE from base model
>>>>>>>>>>>   s390x/cpumodel: Miscellaneous-Instruction-Extensions Facility 3
>>>>>>>>>>>   s390x/cpumodel: msa9 facility
>>>>>>>>>>>   s390x/cpumodel: vector enhancements
>>>>>>>>>>>   s390x/cpumodel: enhanced sort facility
>>>>>>>>>>>   s390x/cpumodel: deflate
>>>>>>>>>>>   s390x/cpumodel: add gen15 defintions
>>>>>>>>>>>   s390x/cpumodel: wire up 8561 and 8562 as gen15 machines
>>>>>>>>>>>   s390x/cpumodel: do not claim csske for expanded models in qmp
>>>>>>>>>>>
>>>>>>>>>>>  hw/s390x/s390-virtio-ccw.c      |  6 +++
>>>>>>>>>>>  linux-headers/asm-s390/kvm.h    |  5 +-
>>>>>>>>>>>  target/s390x/cpu_features.c     | 54 +++++++++++++++++++
>>>>>>>>>>>  target/s390x/cpu_features.h     |  3 ++
>>>>>>>>>>>  target/s390x/cpu_features_def.h | 49 +++++++++++++++++
>>>>>>>>>>>  target/s390x/cpu_models.c       | 35 ++++++++++++
>>>>>>>>>>>  target/s390x/cpu_models.h       |  1 +
>>>>>>>>>>>  target/s390x/gen-features.c     | 94 ++++++++++++++++++++++++++++++++-
>>>>>>>>>>>  target/s390x/kvm.c              | 18 +++++++
>>>>>>>>>>>  9 files changed, 263 insertions(+), 2 deletions(-)
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I guess to handle deprecation of CSSKE:
>>>>>>>>>>
>>>>>>>>>> 1. Remove it from the base + default model of the gen15, keep it in the
>>>>>>>>>> max model. This is completely done in target/s390x/gen-features.c.
>>>>>>>>>> Existing base models are not modified.
>>>>>>>>>>
>>>>>>>>>> 2. Add CSSKE to "ignored_base_feat", so fallback of gen15 to e.g. z14
>>>>>>>>>> will work. We can backport this to distros/stable.
>>>>>>>>>
>>>>>>>>> Yes, I have already implemented that, still doing some testing and polishinh.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> CPU model expansion:
>>>>>>>>>>
>>>>>>>>>> cpu_info_from_model() should already properly be based on the base
>>>>>>>>>> features. "gen15" vs. "gen15,csske=on" should be automatically generated
>>>>>>>>>> when expanding.
>>>>>>>>>>
>>>>>>>>>> CPU model baseline:
>>>>>>>>>>
>>>>>>>>>> s390_find_cpu_def() should make sure that CSSKE is basically ignored
>>>>>>>>>> when determining maximum model, however it will properly be indicated if
>>>>>>>>>> both models had the feature.
>>>>>>>>>>
>>>>>>>>>> CPU model comparison:
>>>>>>>>>>
>>>>>>>>>> Should work as expected. Availability of CSSKE will be considered when
>>>>>>>>>> calculating the result.
>>>>>>>>>>
>>>>>>>>>> gen14,csske=on and gen15,csske=off will result in
>>>>>>>>>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE.
>>>>>>>>>>
>>>>>>>>>> gen14,csske=off and gen15,csske=off should result in
>>>>>>>>>> CPU_MODEL_COMPARE_RESULT_SUBSET
>>>>>>>>>>
>>>>>>>>>> gen14,csske=on and gen15,csske=on should result in
>>>>>>>>>> CPU_MODEL_COMPARE_RESULT_SUBSET
>>>>>>>>>>
>>>>>>>>>> Forward migration:
>>>>>>>>>>
>>>>>>>>>> Now, the only issue is when csske is actually turned of in future
>>>>>>>>>> machines. We would e.g. have
>>>>>>>>>>
>>>>>>>>>> gen15,csske=on and gen16,csske=off
>>>>>>>>>>
>>>>>>>>>> While baselining will work correctly (gen15,csske=off), forward
>>>>>>>>>> migration is broken (comparison will properly indicate
>>>>>>>>>> CPU_MODEL_COMPARE_RESULT_INCOMPATIBLE), which is expected when ripping
>>>>>>>>>> out features. Same applies to BPB.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Your patch "[PATCH 10/10] s390x/cpumodel: do not claim csske for
>>>>>>>>>> expanded models in qmp" tried to address this, however I am not really
>>>>>>>>>> happy with this approach. We should not play such tricks when expanding
>>>>>>>>>> the host model. "-cpu host" and "-cpu $expanded_host" would be
>>>>>>>>>> different,
>>>>>>>>>
>>>>>>>>> We discussed this some time ago and I think we agreed that for host passthrough
>>>>>>>>> it is ok to be different that host-model (e.g. passing through the cpuid, passing
>>>>>>>>> through all non-hypervisor managed features etc).
>>>>>>>>
>>>>>>>> I remember the plan was to use the "max" model to do such stuff. E.g.
>>>>>>>> -cpu max / no -cpu
>>>>>>>>
>>>>>>>> Versus
>>>>>>>> -cpu host
>>>>>>>>
>>>>>>>> We can have features in "host" we don't have in "max". But "-cpu host"
>>>>>>>> and it's expansion should look 100% the same.
>>>>>>>
>>>>>>> I don't think that's the intended semantics of "max" vs "host".
>>>>>>>
>>>>>>> The "max" CPU model is supposed to enable all features that are possible to
>>>>>>> enable.
>>>>>>>
>>>>>>> For KVM, thus "max" should be identical to "host".
>>>>>>
>>>>>> There once was a mode used by x86-64 to simply pipe through cpuid
>>>>>> features that were not even supported. (I remember something like
>>>>>> passthorugh=true), do you remember if something like that still exists?
>>>>>
>>>>> I don't recall such a feature existing even in the past !
>>>>
>>>> Maybe my mind is tricking me, or maybe that has long been removed :)
>>>>
>>>>>
>>>>>>> For TCG, "max" should be everything that QEMU currently knows how to emulate.
>>>>>>
>>>>>> Yes, and on s390x. "max" contains more features than "qemu".
>>>>>>
>>>>>>>
>>>>>>> Essentially think of "max" as a better name for "host", since "host" as
>>>>>>> a name concept didn't make sense for TCG.
>>>>>>
>>>>>> I agree. The main question is, is it acceptable that
>>>>>
>>>>> Hmm, maybe I misinterpreted when you wrote
>>>>>
>>>>>       We can have features in "host" we don't have in "max"
>>>>>
>>>>> I read that as meaning that "-cpu host" and "-cpu max" would be
>>>>> different.
>>>>
>>>> No you didn't misinterpret it, I agreed after you spelled it out :)
>>>>
>>>>>
>>>>>> "-cpu host" and "-cpu $expanded_host" produce different results, after
>>>>>> expanding "host" via query-cpu-model-expansion?
>>>>>
>>>>> That has always been the case on x86-64, since it is not possible to set
>>>>> the level, xlevel, vendor, family, model & stepping properties via -cpu,
>>>>> only the feature flags.
>>>>
>>>> Fair enough, but the question is if we should mess with feature flags we
>>>> can indicate on that level.
>>>>
>>>> It would mean that on a specific host e.g.
>>>>
>>>> "-cpu gen15,csske=on" and "-cpu gen15,csske=off"
>>>>
>>>> Would work. However, "host" model expansion would give us
>>>>
>>>> "-cpu gen15,csske=off"
>>>>
>>>> So trying to e.g. do a query-cpu-model-comparison or
>>>> query-cpu-model-baseline against "host" and against the expanded host
>>>> model will produce different results.
>>>>
>>>> Libvirt could detect "-cpu gen14,csske=on" as not runnable on the host,
>>>> because comparing "-cpu gen14,csske=on" vs. "-cpu gen15,csske=off" would
>>>> be "incompatible". But running "-cpu gen14,csske=on" on the host would
>>>> work perfectly fine.
>>>
>>> I would like to avoid special knowledge in libvirt (since we moved to have
>>> everything in qemu). 
>>>
>>> A more complex idea would be to extend the qmp query with a list of deprecated
>>> features and libvirt could then disable that for expansion but allow it for
>>> baselining.
>>
>> That would fit in nicely into query-cpu-model-expansion. Nice idea.
> 
> Hmm, I think that should also be possible as an add-on patch series later on
> (e.g. in 6 month or so). We would have instances of gen15 machines with host-model
> that start with csske but sooner or later they will be restarted and then they no 
> longer have csske.
> As we do not change anything for baselining this would allow us to separate patch10
> from the other patches and deal with it later with a proper series on its on?
> Need to think about that.

Makes sense, we already have forward migration issues to > gen15 with
guests started in the past when dropping features. No need to rush with
that.

-- 

Thanks,

David / dhildenb