[PATCH v17 12/14] hmat acpi: Build Memory Side Cache Information Structure(s)

[Tao Xu]

From: Liu Jingqi 

This structure describes memory side cache information for memory
proximity domains if the memory side cache is present and the
physical device forms the memory side cache.
The software could use this information to effectively place
the data in memory to maximize the performance of the system
memory that use the memory side cache.

Reviewed-by: Daniel Black 
Reviewed-by: Jonathan Cameron 
Signed-off-by: Liu Jingqi 
Signed-off-by: Tao Xu 
---

No changes in v17.

Changes in v16:
- Use checks and assert to replace masks (Igor)
- Fields in Cache Attributes are promoted to uint32_t before
  shifting (Igor)
- Drop cpu_to_le32() (Igor)

Changes in v13:
- rename level as cache_level
---
 hw/acpi/hmat.c | 69 +-
 1 file changed, 68 insertions(+), 1 deletion(-)

diff --git a/hw/acpi/hmat.c b/hw/acpi/hmat.c
index e5ee8b4317..bb6adb0ccf 100644
--- a/hw/acpi/hmat.c
+++ b/hw/acpi/hmat.c
@@ -143,14 +143,62 @@ static void build_hmat_lb(GArray *table_data, 
HMAT_LB_Info *hmat_lb,
 g_free(entry_list);
 }
 
+/* ACPI 6.3: 5.2.27.5 Memory Side Cache Information Structure: Table 5-147 */
+static void build_hmat_cache(GArray *table_data, uint8_t total_levels,
+ NumaHmatCacheOptions *hmat_cache)
+{
+/*
+ * Cache Attributes: Bits [3:0] – Total Cache Levels
+ * for this Memory Proximity Domain
+ */
+uint32_t cache_attr = total_levels;
+
+/* Bits [7:4] : Cache Level described in this structure */
+cache_attr |= (uint32_t) hmat_cache->level << 4;
+
+/* Bits [11:8] - Cache Associativity */
+cache_attr |= (uint32_t) hmat_cache->assoc << 8;
+
+/* Bits [15:12] - Write Policy */
+cache_attr |= (uint32_t) hmat_cache->policy << 12;
+
+/* Bits [31:16] - Cache Line size in bytes */
+cache_attr |= (uint32_t) hmat_cache->line << 16;
+
+/* Type */
+build_append_int_noprefix(table_data, 2, 2);
+/* Reserved */
+build_append_int_noprefix(table_data, 0, 2);
+/* Length */
+build_append_int_noprefix(table_data, 32, 4);
+/* Proximity Domain for the Memory */
+build_append_int_noprefix(table_data, hmat_cache->node_id, 4);
+/* Reserved */
+build_append_int_noprefix(table_data, 0, 4);
+/* Memory Side Cache Size */
+build_append_int_noprefix(table_data, hmat_cache->size, 8);
+/* Cache Attributes */
+build_append_int_noprefix(table_data, cache_attr, 4);
+/* Reserved */
+build_append_int_noprefix(table_data, 0, 2);
+/*
+ * Number of SMBIOS handles (n)
+ * Linux kernel uses Memory Side Cache Information Structure
+ * without SMBIOS entries for now, so set Number of SMBIOS handles
+ * as 0.
+ */
+build_append_int_noprefix(table_data, 0, 2);
+}
+
 /* Build HMAT sub table structures */
 static void hmat_build_table_structs(GArray *table_data, NumaState *numa_state)
 {
 uint16_t flags;
 uint32_t num_initiator = 0;
 uint32_t initiator_list[MAX_NODES];
-int i, hierarchy, type;
+int i, hierarchy, type, cache_level, total_levels;
 HMAT_LB_Info *hmat_lb;
+NumaHmatCacheOptions *hmat_cache;
 
 for (i = 0; i < numa_state->num_nodes; i++) {
 flags = 0;
@@ -184,6 +232,25 @@ static void hmat_build_table_structs(GArray *table_data, 
NumaState *numa_state)
 }
 }
 }
+
+/*
+ * ACPI 6.3: 5.2.27.5 Memory Side Cache Information Structure:
+ * Table 5-147
+ */
+for (i = 0; i < numa_state->num_nodes; i++) {
+total_levels = 0;
+for (cache_level = 1; cache_level < HMAT_LB_LEVELS; cache_level++) {
+if (numa_state->hmat_cache[i][cache_level]) {
+total_levels++;
+}
+}
+for (cache_level = 0; cache_level <= total_levels; cache_level++) {
+hmat_cache = numa_state->hmat_cache[i][cache_level];
+if (hmat_cache) {
+build_hmat_cache(table_data, total_levels, hmat_cache);
+}
+}
+}
 }
 
 void build_hmat(GArray *table_data, BIOSLinker *linker, NumaState *numa_state)
-- 
2.20.1

[PATCH v3 0/2] Fix incorrect integer->float conversion caught by clang

[Markus Armbruster]

Fangrui Song's "[PATCH v2] Fix incorrect integer->float conversions
caught by clang -Wimplicit-int-float-conversion" doesn't apply with
git-am, and it mixes a bug fix, which should be considered for 4.2,
with a cleanup, which should go into 5.0.  I took the liberty to
respin, hope that's alright.

I propose the migration maintainers pick up PATCH 1 for 5.0.

I can submit PATCH 2 for 4.2-rc3.

Fangrui Song (2):
  migration: Fix incorrect integer->float conversion caught by clang
  util/cutils: Fix incorrect integer->float conversion caught by clang

 migration/migration.c | 3 +--
 util/cutils.c | 8 +---
 2 files changed, 6 insertions(+), 5 deletions(-)

-- 
2.21.0

[PATCH 2/4] s390x: Cleanup cpu resets

[Janosch Frank]

Let's move the resets into one function and switch by type, so we can
use fallthroughs for shared reset actions.

Signed-off-by: Janosch Frank 
---
 target/s390x/cpu.c | 110 -
 1 file changed, 48 insertions(+), 62 deletions(-)

diff --git a/target/s390x/cpu.c b/target/s390x/cpu.c
index 3abe7e80fd..556afecbc1 100644
--- a/target/s390x/cpu.c
+++ b/target/s390x/cpu.c
@@ -82,67 +82,52 @@ static void s390_cpu_load_normal(CPUState *s)
 }
 #endif
 
-/* S390CPUClass::cpu_reset() */
-static void s390_cpu_reset(CPUState *s)
+typedef enum cpu_reset_type {
+S390_CPU_RESET_NORMAL,
+S390_CPU_RESET_INITIAL,
+S390_CPU_RESET_CLEAR,
+} cpu_reset_type;
+
+static void s390_cpu_reset(CPUState *s, cpu_reset_type type)
 {
 S390CPU *cpu = S390_CPU(s);
 S390CPUClass *scc = S390_CPU_GET_CLASS(cpu);
 CPUS390XState *env = &cpu->env;
 
-env->pfault_token = -1UL;
-env->bpbc = false;
 scc->parent_reset(s);
 cpu->env.sigp_order = 0;
 s390_cpu_set_state(S390_CPU_STATE_STOPPED, cpu);
-}
 
-/* S390CPUClass::initial_reset() */
-static void s390_cpu_initial_reset(CPUState *s)
-{
-S390CPU *cpu = S390_CPU(s);
-CPUS390XState *env = &cpu->env;
+/* Set initial values after clearing */
+switch (type) {
+case S390_CPU_RESET_CLEAR:
+memset(env, 0, offsetof(CPUS390XState, start_initial_reset_fields));
+/* Fallthrough */
+case S390_CPU_RESET_INITIAL:
+memset(&env->start_initial_reset_fields, 0,
+   offsetof(CPUS390XState, end_reset_fields) -
+   offsetof(CPUS390XState, start_initial_reset_fields));
+/* architectured initial values for CR 0 and 14 */
+env->cregs[0] = CR0_RESET;
+env->cregs[14] = CR14_RESET;
 
-s390_cpu_reset(s);
-/* initial reset does not clear everything! */
-memset(&env->start_initial_reset_fields, 0,
-offsetof(CPUS390XState, end_reset_fields) -
-offsetof(CPUS390XState, start_initial_reset_fields));
-
-/* architectured initial values for CR 0 and 14 */
-env->cregs[0] = CR0_RESET;
-env->cregs[14] = CR14_RESET;
-
-/* architectured initial value for Breaking-Event-Address register */
-env->gbea = 1;
-
-env->pfault_token = -1UL;
-
-/* tininess for underflow is detected before rounding */
-set_float_detect_tininess(float_tininess_before_rounding,
-  &env->fpu_status);
+/* architectured initial value for Breaking-Event-Address register */
+env->gbea = 1;
+/* tininess for underflow is detected before rounding */
+set_float_detect_tininess(float_tininess_before_rounding,
+  &env->fpu_status);
+/* Fallthrough */
+case S390_CPU_RESET_NORMAL:
+env->pfault_token = -1UL;
+env->bpbc = false;
+break;
+}
 
 /* Reset state inside the kernel that we cannot access yet from QEMU. */
-if (kvm_enabled()) {
-kvm_s390_reset_vcpu(cpu);
+if (kvm_enabled() && (type == S390_CPU_RESET_CLEAR ||
+  type == S390_CPU_RESET_INITIAL)) {
+kvm_s390_reset_vcpu(cpu);
 }
-}
-
-/* CPUClass:reset() */
-static void s390_cpu_full_reset(CPUState *s)
-{
-S390CPU *cpu = S390_CPU(s);
-S390CPUClass *scc = S390_CPU_GET_CLASS(cpu);
-CPUS390XState *env = &cpu->env;
-
-scc->parent_reset(s);
-cpu->env.sigp_order = 0;
-s390_cpu_set_state(S390_CPU_STATE_STOPPED, cpu);
-
-memset(env, 0, offsetof(CPUS390XState, end_reset_fields));
-
-/* architectured initial values for CR 0 and 14 */
-env->cregs[0] = CR0_RESET;
-env->cregs[14] = CR14_RESET;
 
 #if defined(CONFIG_USER_ONLY)
 /* user mode should always be allowed to use the full FPU */
@@ -151,20 +136,21 @@ static void s390_cpu_full_reset(CPUState *s)
 env->cregs[0] |= CR0_VECTOR;
 }
 #endif
+}
 
-/* architectured initial value for Breaking-Event-Address register */
-env->gbea = 1;
+static void s390_cpu_reset_normal(CPUState *s)
+{
+return s390_cpu_reset(s, S390_CPU_RESET_NORMAL);
+}
 
-env->pfault_token = -1UL;
+static void s390_cpu_reset_initial(CPUState *s)
+{
+return s390_cpu_reset(s, S390_CPU_RESET_INITIAL);
+}
 
-/* tininess for underflow is detected before rounding */
-set_float_detect_tininess(float_tininess_before_rounding,
-  &env->fpu_status);
-
-/* Reset state inside the kernel that we cannot access yet from QEMU. */
-if (kvm_enabled()) {
-kvm_s390_reset_vcpu(cpu);
-}
+static void s390_cpu_reset_clear(CPUState *s)
+{
+return s390_cpu_reset(s, S390_CPU_RESET_CLEAR);
 }
 
 #if !defined(CONFIG_USER_ONLY)
@@ -473,9 +459,9 @@ static void s390_cpu_class_init(ObjectClass *oc, void *data)
 #if !defined(CONFIG_USER_ONLY)
 scc->load_normal = s390_cpu_load_normal;
 #endif
-scc->cpu_reset = s390_cpu_reset;
-scc->initial_cpu_reset = s390_cpu_initial_reset;
-cc->reset 

[PATCH v17 13/14] tests/numa: Add case for QMP build HMAT

[Tao Xu]

Check configuring HMAT usecase

Suggested-by: Igor Mammedov 
Signed-off-by: Tao Xu 
---

Chenges in v17:
- Add some fail test cases (Igor)
---
 tests/numa-test.c | 194 ++
 1 file changed, 194 insertions(+)

diff --git a/tests/numa-test.c b/tests/numa-test.c
index 8de8581231..9c69da973c 100644
--- a/tests/numa-test.c
+++ b/tests/numa-test.c
@@ -327,6 +327,197 @@ static void pc_dynamic_cpu_cfg(const void *data)
 qtest_quit(qs);
 }
 
+static void pc_hmat_build_cfg(const void *data)
+{
+QTestState *qs = qtest_initf("%s -nodefaults --preconfig -machine hmat=on "
+ "-smp 2,sockets=2 "
+ "-m 128M,slots=2,maxmem=1G "
+ "-object memory-backend-ram,size=64M,id=m0 "
+ "-object memory-backend-ram,size=64M,id=m1 "
+ "-numa node,nodeid=0,memdev=m0 "
+ "-numa node,nodeid=1,memdev=m1,initiator=0 "
+ "-numa cpu,node-id=0,socket-id=0 "
+ "-numa cpu,node-id=0,socket-id=1",
+ data ? (char *)data : "");
+
+/* Fail: Initiator should be less than the number of nodes */
+g_assert(qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
+" 'arguments': { 'type': 'hmat-lb', 'initiator': 2, 'target': 0,"
+" 'hierarchy': \"memory\", 'data-type': \"access-latency\" } }")));
+
+/* Fail: Target should be less than the number of nodes */
+g_assert(qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
+" 'arguments': { 'type': 'hmat-lb', 'initiator': 0, 'target': 2,"
+" 'hierarchy': \"memory\", 'data-type': \"access-latency\" } }")));
+
+/* Fail: Initiator should contain cpu */
+g_assert(qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
+" 'arguments': { 'type': 'hmat-lb', 'initiator': 1, 'target': 0,"
+" 'hierarchy': \"memory\", 'data-type': \"access-latency\" } }")));
+
+/* Fail: Data-type mismatch */
+g_assert(qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
+" 'arguments': { 'type': 'hmat-lb', 'initiator': 0, 'target': 0,"
+" 'hierarchy': \"memory\", 'data-type': \"write-latency\","
+" 'bandwidth': 524288000 } }")));
+g_assert(qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
+" 'arguments': { 'type': 'hmat-lb', 'initiator': 0, 'target': 0,"
+" 'hierarchy': \"memory\", 'data-type': \"read-bandwidth\","
+" 'latency': 5 } }")));
+
+/* Fail: Bandwidth should be 1MB (1048576) aligned */
+g_assert(qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
+" 'arguments': { 'type': 'hmat-lb', 'initiator': 0, 'target': 0,"
+" 'hierarchy': \"memory\", 'data-type': \"access-bandwidth\","
+" 'bandwidth': 1048575 } }")));
+
+/* Configuring HMAT bandwidth and latency details */
+g_assert(!qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
+" 'arguments': { 'type': 'hmat-lb', 'initiator': 0, 'target': 0,"
+" 'hierarchy': \"memory\", 'data-type': \"access-latency\","
+" 'latency': 1 } }")));/* 1 ns */
+g_assert(qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
+" 'arguments': { 'type': 'hmat-lb', 'initiator': 0, 'target': 0,"
+" 'hierarchy': \"memory\", 'data-type': \"access-latency\","
+" 'latency': 5 } }")));/* Fail: Duplicate configuration */
+g_assert(!qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
+" 'arguments': { 'type': 'hmat-lb', 'initiator': 0, 'target': 0,"
+" 'hierarchy': \"memory\", 'data-type': \"access-bandwidth\","
+" 'bandwidth': 68717379584 } }")));/* 65534 MB/s */
+g_assert(!qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
+" 'arguments': { 'type': 'hmat-lb', 'initiator': 0, 'target': 1,"
+" 'hierarchy': \"memory\", 'data-type': \"access-latency\","
+" 'latency': 65534 } }")));/* 65534 ns */
+g_assert(!qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
+" 'arguments': { 'type': 'hmat-lb', 'initiator': 0, 'target': 1,"
+" 'hierarchy': \"memory\", 'data-type': \"access-bandwidth\","
+" 'bandwidth': 34358689792 } }")));/* 32767 MB/s */
+
+/* Fail: node_id should be less than the number of nodes */
+g_assert(qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
+" 'arguments': { 'type': 'hmat-cache', 'node-id': 2, 'size': 10240,"
+" 'level': 1, 'assoc': \"direct\", 'policy': \"write-back\","
+" 'line': 8 } }")));
+
+/* Fail: level should be less than HMAT_LB_LEVELS (4) */
+g_assert(qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
+" 'arguments': { 'type': 'hmat-cache', 'node-id': 0, 'size': 10240,"
+" 'level': 4, 'assoc': \"direct\", 'policy': \"write-back\","
+" 'line': 8 } }")));
+
+/* Confi

[PATCH 0/4] s390x: Reset cleanup

[Janosch Frank]

Adding comments and reordering code for better readability in the
diag308 and machine reset functions.

Janosch Frank (4):
  s390x: Don't do a normal reset on the initial cpu
  s390x: Cleanup cpu resets
  s390x: Beautify diag308 handling
  s390x: Beautify machine reset

 hw/s390x/s390-virtio-ccw.c |  23 
 target/s390x/cpu.c | 110 -
 target/s390x/diag.c|  54 ++
 3 files changed, 93 insertions(+), 94 deletions(-)

-- 
2.20.1

[PATCH v3 2/2] util/cutils: Fix incorrect integer->float conversion caught by clang

[Markus Armbruster]

From: Fangrui Song 

Clang does not like do_strtosz()'s code to guard against overflow:

qemu/util/cutils.c:245:23: error: implicit conversion from 'unsigned long' 
to 'double' changes value from 18446744073709550592 to 18446744073709551616 
[-Werror,-Wimplicit-int-float-conversion]

The warning will be enabled by default in clang 10. It is not
available for clang <= 9.

val * mul >= 0xfc00 is indeed wrong.  0xfc00
is not representable exactly as double.  It's half-way between the
representable values 0xf800 and 0x1.
Which one we get is implementation-defined.  Bad.

We want val * mul > (the largest uint64_t exactly representable as
double).  That's 0xf800.  Write it as nextafter(0x1p64, 0)
with a suitable comment.

Signed-off-by: Fangrui Song 
Reviewed-by: Markus Armbruster 
[Patch split, commit message improved]
Signed-off-by: Markus Armbruster 
---
 util/cutils.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/util/cutils.c b/util/cutils.c
index fd591cadf0..77acadc70a 100644
--- a/util/cutils.c
+++ b/util/cutils.c
@@ -239,10 +239,12 @@ static int do_strtosz(const char *nptr, const char **end,
 goto out;
 }
 /*
- * Values >= 0xfc00 overflow uint64_t after their trip
- * through double (53 bits of precision).
+ * Values near UINT64_MAX overflow to 2**64 when converting to double
+ * precision.  Compare against the maximum representable double precision
+ * value below 2**64, computed as "the next value after 2**64 (0x1p64) in
+ * the direction of 0".
  */
-if ((val * mul >= 0xfc00) || val < 0) {
+if ((val * mul > nextafter(0x1p64, 0)) || val < 0) {
 retval = -ERANGE;
 goto out;
 }
-- 
2.21.0

[PATCH v3 1/2] migration: Fix incorrect integer->float conversion caught by clang

[Markus Armbruster]

From: Fangrui Song 

Clang does not like qmp_migrate_set_downtime()'s code to clamp double
@value to 0..INT64_MAX:

qemu/migration/migration.c:2038:24: error: implicit conversion from 'long' 
to 'double' changes value from 9223372036854775807 to 9223372036854775808 
[-Werror,-Wimplicit-int-float-conversion]

The warning will be enabled by default in clang 10. It is not
available for clang <= 9.

The clamp is actually useless; @value is checked to be within
0..MAX_MIGRATE_DOWNTIME_SECONDS immediately before.  Delete it.

While there, make the conversion from double to int64_t explicit.

Signed-off-by: Fangrui Song 
Reviewed-by: Markus Armbruster 
[Patch split, commit message improved]
Signed-off-by: Markus Armbruster 
---
 migration/migration.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/migration/migration.c b/migration/migration.c
index 354ad072fa..09b150663f 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -2035,11 +2035,10 @@ void qmp_migrate_set_downtime(double value, Error 
**errp)
 }
 
 value *= 1000; /* Convert to milliseconds */
-value = MAX(0, MIN(INT64_MAX, value));
 
 MigrateSetParameters p = {
 .has_downtime_limit = true,
-.downtime_limit = value,
+.downtime_limit = (int64_t)value,
 };
 
 qmp_migrate_set_parameters(&p, errp);
-- 
2.21.0

[PATCH v17 14/14] tests/bios-tables-test: add test cases for ACPI HMAT

[Tao Xu]

ACPI table HMAT has been introduced, QEMU now builds HMAT tables for
Heterogeneous Memory with boot option '-numa node'.

Add test cases on PC and Q35 machines with 2 numa nodes.
Because HMAT is generated when system enable numa, the
following tables need to be added for this test:
tests/data/acpi/pc/APIC.acpihmat
tests/data/acpi/pc/SRAT.acpihmat
tests/data/acpi/pc/HMAT.acpihmat
tests/data/acpi/pc/DSDT.acpihmat
tests/data/acpi/q35/APIC.acpihmat
tests/data/acpi/q35/SRAT.acpihmat
tests/data/acpi/q35/HMAT.acpihmat
tests/data/acpi/q35/DSDT.acpihmat

Reviewed-by: Igor Mammedov 
Reviewed-by: Daniel Black 
Reviewed-by: Jingqi Liu 
Suggested-by: Igor Mammedov 
Signed-off-by: Tao Xu 
---

Changes in v17:
- Update the latency and bandwidth

Changes in v15:
- Make tests without breaking CI (Michael)

Changes in v13:
- Use decimal notation with appropriate suffix for cache size
---
 tests/bios-tables-test-allowed-diff.h |  8 +
 tests/bios-tables-test.c  | 44 +++
 tests/data/acpi/pc/APIC.acpihmat  |  0
 tests/data/acpi/pc/DSDT.acpihmat  |  0
 tests/data/acpi/pc/HMAT.acpihmat  |  0
 tests/data/acpi/pc/SRAT.acpihmat  |  0
 tests/data/acpi/q35/APIC.acpihmat |  0
 tests/data/acpi/q35/DSDT.acpihmat |  0
 tests/data/acpi/q35/HMAT.acpihmat |  0
 tests/data/acpi/q35/SRAT.acpihmat |  0
 10 files changed, 52 insertions(+)
 create mode 100644 tests/data/acpi/pc/APIC.acpihmat
 create mode 100644 tests/data/acpi/pc/DSDT.acpihmat
 create mode 100644 tests/data/acpi/pc/HMAT.acpihmat
 create mode 100644 tests/data/acpi/pc/SRAT.acpihmat
 create mode 100644 tests/data/acpi/q35/APIC.acpihmat
 create mode 100644 tests/data/acpi/q35/DSDT.acpihmat
 create mode 100644 tests/data/acpi/q35/HMAT.acpihmat
 create mode 100644 tests/data/acpi/q35/SRAT.acpihmat

diff --git a/tests/bios-tables-test-allowed-diff.h 
b/tests/bios-tables-test-allowed-diff.h
index dfb8523c8b..3c9e0c979b 100644
--- a/tests/bios-tables-test-allowed-diff.h
+++ b/tests/bios-tables-test-allowed-diff.h
@@ -1 +1,9 @@
 /* List of comma-separated changed AML files to ignore */
+"tests/data/acpi/pc/APIC.acpihmat",
+"tests/data/acpi/pc/SRAT.acpihmat",
+"tests/data/acpi/pc/HMAT.acpihmat",
+"tests/data/acpi/pc/DSDT.acpihmat",
+"tests/data/acpi/q35/APIC.acpihmat",
+"tests/data/acpi/q35/SRAT.acpihmat",
+"tests/data/acpi/q35/HMAT.acpihmat",
+"tests/data/acpi/q35/DSDT.acpihmat",
diff --git a/tests/bios-tables-test.c b/tests/bios-tables-test.c
index 79f5da092f..9fab1d0459 100644
--- a/tests/bios-tables-test.c
+++ b/tests/bios-tables-test.c
@@ -947,6 +947,48 @@ static void test_acpi_virt_tcg_numamem(void)
 
 }
 
+static void test_acpi_tcg_acpi_hmat(const char *machine)
+{
+test_data data;
+
+memset(&data, 0, sizeof(data));
+data.machine = machine;
+data.variant = ".acpihmat";
+test_acpi_one(" -machine hmat=on"
+  " -smp 2,sockets=2"
+  " -m 128M,slots=2,maxmem=1G"
+  " -object memory-backend-ram,size=64M,id=m0"
+  " -object memory-backend-ram,size=64M,id=m1"
+  " -numa node,nodeid=0,memdev=m0"
+  " -numa node,nodeid=1,memdev=m1,initiator=0"
+  " -numa cpu,node-id=0,socket-id=0"
+  " -numa cpu,node-id=0,socket-id=1"
+  " -numa hmat-lb,initiator=0,target=0,hierarchy=memory,"
+  "data-type=access-latency,latency=1ns"
+  " -numa hmat-lb,initiator=0,target=0,hierarchy=memory,"
+  "data-type=access-bandwidth,bandwidth=65534M"
+  " -numa hmat-lb,initiator=0,target=1,hierarchy=memory,"
+  "data-type=access-latency,latency=65534ns"
+  " -numa hmat-lb,initiator=0,target=1,hierarchy=memory,"
+  "data-type=access-bandwidth,bandwidth=32767M"
+  " -numa hmat-cache,node-id=0,size=10K,level=1,assoc=direct,"
+  "policy=write-back,line=8"
+  " -numa hmat-cache,node-id=1,size=10K,level=1,assoc=direct,"
+  "policy=write-back,line=8",
+  &data);
+free_test_data(&data);
+}
+
+static void test_acpi_q35_tcg_acpi_hmat(void)
+{
+test_acpi_tcg_acpi_hmat(MACHINE_Q35);
+}
+
+static void test_acpi_piix4_tcg_acpi_hmat(void)
+{
+test_acpi_tcg_acpi_hmat(MACHINE_PC);
+}
+
 static void test_acpi_virt_tcg(void)
 {
 test_data data = {
@@ -991,6 +1033,8 @@ int main(int argc, char *argv[])
 qtest_add_func("acpi/q35/numamem", test_acpi_q35_tcg_numamem);
 qtest_add_func("acpi/piix4/dimmpxm", test_acpi_piix4_tcg_dimm_pxm);
 qtest_add_func("acpi/q35/dimmpxm", test_acpi_q35_tcg_dimm_pxm);
+qtest_add_func("acpi/piix4/acpihmat", test_acpi_piix4_tcg_acpi_hmat);
+qtest_add_func("acpi/q35/acpihmat", test_acpi_q35_tcg_acpi_hmat);
 } else if (strcmp(arch, "aarch64") == 0) {
 qtest_add_func("acpi/virt", test_ac

Re: [PATCH v2] Fix incorrect integer->float conversions caught by clang -Wimplicit-int-float-conversion

[Markus Armbruster]

Fangrui Song  writes:

> On 2019-11-21, Eric Blake wrote:
>>On 11/19/19 2:49 PM, Fangrui Song wrote:
>>

Can we simply drop the offending line statement instead?
>>>
>>>Fixed in the new patch.
>>>
>>
The first val * mul above this range is 0x1p64.  Rejecting it is
correct, because it overflows yint64_t.
>>>
>>>I am not subscribed, so apologize that this email may be off the thread.
>>>
>>>(The binutils mailing list allows a user to download the raw email so I
>>>can still reply to a specific email, but this list does not provide such
>>>feature.)

There's .

>> Actually, it's better to post a v2 patch as a new top-level thread,
>> rather than buried as an attachment to a reply to v1, because our CI
>> tooling doesn't see through the attachment (nor was it easy for me
>> to reply to the v2 patch - I had to open the attachment to paste its
>> text inline below...).
>>
>>More patch submission hints at https://wiki.qemu.org/Contribute/SubmitAPatch
>
> Retitled to [PATCH v2]

Good, such versioning is essential to avoid confusion.  Next time, start
a new top-level thread for v2.  Our patch submission processing
(automated as well as human) expects that.

I just did it for you: "[PATCH v3 0/2] Fix incorrect integer->float
conversion caught by clang".

Many thanks for your fixes!

[PATCH 3/4] s390x: Beautify diag308 handling

[Janosch Frank]

Let's improve readability by:
* Using constants for the subcodes
* Moving parameter checking into a function
* Removing subcode > 6 check as the default case catches that

Signed-off-by: Janosch Frank 
Reviewed-by: Cornelia Huck 
Reviewed-by: Thomas Huth 
---
 target/s390x/diag.c | 54 +++--
 1 file changed, 32 insertions(+), 22 deletions(-)

diff --git a/target/s390x/diag.c b/target/s390x/diag.c
index 53c2f81f2a..18d33c8492 100644
--- a/target/s390x/diag.c
+++ b/target/s390x/diag.c
@@ -53,6 +53,29 @@ int handle_diag_288(CPUS390XState *env, uint64_t r1, 
uint64_t r3)
 #define DIAG_308_RC_NO_CONF 0x0102
 #define DIAG_308_RC_INVALID 0x0402
 
+#define DIAG308_RESET_MOD_CLR  0
+#define DIAG308_RESET_LOAD_NORM1
+#define DIAG308_LOAD_CLEAR 3
+#define DIAG308_LOAD_NORMAL_DUMP   4
+#define DIAG308_SET5
+#define DIAG308_STORE  6
+
+static int diag308_parm_check(CPUS390XState *env, uint64_t r1, uint64_t addr,
+  uintptr_t ra, bool write)
+{
+if ((r1 & 1) || (addr & ~TARGET_PAGE_MASK)) {
+s390_program_interrupt(env, PGM_SPECIFICATION, ra);
+return -1;
+}
+if (!address_space_access_valid(&address_space_memory, addr,
+sizeof(IplParameterBlock), write,
+MEMTXATTRS_UNSPECIFIED)) {
+s390_program_interrupt(env, PGM_ADDRESSING, ra);
+return -1;
+}
+return 0;
+}
+
 void handle_diag_308(CPUS390XState *env, uint64_t r1, uint64_t r3, uintptr_t 
ra)
 {
 CPUState *cs = env_cpu(env);
@@ -65,30 +88,24 @@ void handle_diag_308(CPUS390XState *env, uint64_t r1, 
uint64_t r3, uintptr_t ra)
 return;
 }
 
-if ((subcode & ~0x0ULL) || (subcode > 6)) {
+if (subcode & ~0x0ULL) {
 s390_program_interrupt(env, PGM_SPECIFICATION, ra);
 return;
 }
 
 switch (subcode) {
-case 0:
+case DIAG308_RESET_MOD_CLR:
 s390_ipl_reset_request(cs, S390_RESET_MODIFIED_CLEAR);
 break;
-case 1:
+case DIAG308_RESET_LOAD_NORM:
 s390_ipl_reset_request(cs, S390_RESET_LOAD_NORMAL);
 break;
-case 3:
+case DIAG308_LOAD_CLEAR:
+/* Well we still lack the clearing bit... */
 s390_ipl_reset_request(cs, S390_RESET_REIPL);
 break;
-case 5:
-if ((r1 & 1) || (addr & 0x0fffULL)) {
-s390_program_interrupt(env, PGM_SPECIFICATION, ra);
-return;
-}
-if (!address_space_access_valid(&address_space_memory, addr,
-sizeof(IplParameterBlock), false,
-MEMTXATTRS_UNSPECIFIED)) {
-s390_program_interrupt(env, PGM_ADDRESSING, ra);
+case DIAG308_SET:
+if (diag308_parm_check(env, r1, addr, ra, false)) {
 return;
 }
 iplb = g_new0(IplParameterBlock, 1);
@@ -110,15 +127,8 @@ void handle_diag_308(CPUS390XState *env, uint64_t r1, 
uint64_t r3, uintptr_t ra)
 out:
 g_free(iplb);
 return;
-case 6:
-if ((r1 & 1) || (addr & 0x0fffULL)) {
-s390_program_interrupt(env, PGM_SPECIFICATION, ra);
-return;
-}
-if (!address_space_access_valid(&address_space_memory, addr,
-sizeof(IplParameterBlock), true,
-MEMTXATTRS_UNSPECIFIED)) {
-s390_program_interrupt(env, PGM_ADDRESSING, ra);
+case DIAG308_STORE:
+if (diag308_parm_check(env, r1, addr, ra, true)) {
 return;
 }
 iplb = s390_ipl_get_iplb();
-- 
2.20.1

Re: [PATCH v3 1/2] migration: Fix incorrect integer->float conversion caught by clang

[Richard Henderson]

On 11/22/19 9:00 AM, Markus Armbruster wrote:
> From: Fangrui Song 
> 
> Clang does not like qmp_migrate_set_downtime()'s code to clamp double
> @value to 0..INT64_MAX:
> 
> qemu/migration/migration.c:2038:24: error: implicit conversion from 
> 'long' to 'double' changes value from 9223372036854775807 to 
> 9223372036854775808 [-Werror,-Wimplicit-int-float-conversion]
> 
> The warning will be enabled by default in clang 10. It is not
> available for clang <= 9.
> 
> The clamp is actually useless; @value is checked to be within
> 0..MAX_MIGRATE_DOWNTIME_SECONDS immediately before.  Delete it.
> 
> While there, make the conversion from double to int64_t explicit.
> 
> Signed-off-by: Fangrui Song 
> Reviewed-by: Markus Armbruster 
> [Patch split, commit message improved]
> Signed-off-by: Markus Armbruster 
> ---
>  migration/migration.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

Reviewed-by: Richard Henderson 


r~

Re: [PATCH v3 2/2] util/cutils: Fix incorrect integer->float conversion caught by clang

[Richard Henderson]

On 11/22/19 9:00 AM, Markus Armbruster wrote:
> From: Fangrui Song 
> 
> Clang does not like do_strtosz()'s code to guard against overflow:
> 
> qemu/util/cutils.c:245:23: error: implicit conversion from 'unsigned 
> long' to 'double' changes value from 18446744073709550592 to 
> 18446744073709551616 [-Werror,-Wimplicit-int-float-conversion]
> 
> The warning will be enabled by default in clang 10. It is not
> available for clang <= 9.
> 
> val * mul >= 0xfc00 is indeed wrong.  0xfc00
> is not representable exactly as double.  It's half-way between the
> representable values 0xf800 and 0x1.
> Which one we get is implementation-defined.  Bad.
> 
> We want val * mul > (the largest uint64_t exactly representable as
> double).  That's 0xf800.  Write it as nextafter(0x1p64, 0)
> with a suitable comment.
> 
> Signed-off-by: Fangrui Song 
> Reviewed-by: Markus Armbruster 
> [Patch split, commit message improved]
> Signed-off-by: Markus Armbruster 
> ---
>  util/cutils.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)

Reviewed-by: Richard Henderson 


r~

Re: [PATCH v3 2/4] Memory: Enable writeback for given memory region

[Richard Henderson]

On 11/21/19 1:08 AM, Beata Michalska wrote:
> Add an option to trigger memory writeback to sync given memory region
> with the corresponding backing store, case one is available.
> This extends the support for persistent memory, allowing syncing on-demand.
> 
> Signed-off-by: Beata Michalska 
> ---
>  exec.c  | 36 
>  include/exec/memory.h   |  6 ++
>  include/exec/ram_addr.h |  8 
>  include/qemu/cutils.h   |  1 +
>  memory.c| 12 
>  util/cutils.c   | 38 ++
>  6 files changed, 101 insertions(+)

Reviewed-by: Richard Henderson 


r~

Re: [Qemu-devel] [libvirt] [PATCH 2/2] qapi: deprecate implicit filters

[Markus Armbruster]

Reviving this old thread, because I'd like to connect it to more recent
discussions.

Christophe de Dinechin  writes:

> Markus Armbruster writes:
>
>> Peter Krempa  writes:
>>
> [...]
>>> From my experience users report non-fatal messages mostly only if it is
>>> spamming the system log. One of instances are very unlikely to be
>>> noticed.
>>>
>>> In my experience it's better to notify us in libvirt of such change and
>>> we will try our best to fix it.
>>
>> How to best alert the layers above QEMU was one of the topic of the KVM
>> Forum 2018 BoF on deprecating stuff.  Minutes:
>>
>> Message-ID: <87mur0ls8o@dusky.pond.sub.org>
>> https://lists.nongnu.org/archive/html/qemu-devel/2018-10/msg05828.html
>>
>> Relevant part:
>>
>> * We need to communicate "you're using something that is deprecated".
>>   How?  Right now, we print a deprecation message.  Okay when humans use
>>   QEMU directly in a shell.  However, when QEMU sits at the bottom of a
>>   software stack, the message will likely end up in a log file that is
>>   effectively write-only.
>>
>>   - The one way to get people read log files is crashing their
>> application.  A command line option --future could make QEMU crash
>> right after printing a deprecation message.  This could help with
>> finding use of deprecated features in a testing environment.
>>
>>   - A less destructive way to grab people's attention is to make things
>> run really, really slow: have QEMU go to sleep for a while after
>> printing a deprecation message.
>>
>>   - We can also pass the buck to the next layer up: emit a QMP event.
>>
>> Sadly, by the time the next layer connects to QMP, plenty of stuff
>> already happened.  We'd have to buffer deprecation events somehow.
>>
>> What would libvirt do with such an event?  Log it, taint the domain,
>> emit a (libvirt) event to pass it on to the next layer up.
>>
>>   - A completely different idea is to have a configuratin linter.  To
>> support doing this at the libvirt level, QEMU could expose "is
>> deprecated" in interface introspection.  Feels feasible for QMP,
>> where we already have sufficiently expressive introspection.  For
>> CLI, we'd first have to provide that (but we want that anyway).
>>
>>   - We might also want to dispay deprecation messages in QEMU's GUI
>> somehow, or on serial consoles.
>
> Sorry for catching up late, this mail thread happened during my PTO.
>
> I remember bringing up at the time [1] that the correct solution needs
> to take into account usage models that vary from
>
> - a workstation case, where displaying an error box is easy and
>   convenient,
>
> - to local headless VMs where system-level notification would do the job
>   better, allowing us to leverage things like system-wide email notifications
>
> - to large-scale collections of VMs managed by some layered product,
>   where the correct reporting would be through something like Insights,
>   i.e. you don't scan individual logs, you want something like "913 VMs
>   are using deprecated X"
>
> To me, that implies that we need to have a clear division of roles, with
> a standard way to
>
> a) produce the errors,
> b) propagate them,
> c) consume them (at least up to libvirt)
>
> Notice that this work has already been done for "real" errors,
> i.e. there is a real QAPI notion of "errors". AFAICT, warn_report does
> not connect to it, though, it goes through error_vprintf which is really
> just basic logging.
>
> So would it make sense to:
>
> 1. Add a deprecation_report() alongside warn_report()?

"Grepability" alone would make that worthwhile, I think.

> 2. Connect warn_report() and all the error_vprintf output to QAPI,
>e.g. using John's suggestion of adding the messages using some
>"warning" or "deprecated" tag?

This is the difficult part.  See my "Exposing feature deprecation to
machine clients (was: [Qemu-devel] [PATCH 2/2] qapi: deprecate implicit
filters)" in this thread.  Quote:

Propagating errors is painful.  It has caused massive churn all over the
place.

I don't think we can hitch deprecation info to the existing error
propagation, since we need to take the success path back to the QMP
core, not an error path.

Propagating a second object for warnings... thanks, but no thanks.

The QMP core could provide a function for recording deprecation info for
the currently executing QMP command.  This is how we used to record
errors in QMP commands, until Anthony rammed through what we have now.
The commit messages (e.g. d5ec4f27c38) provide no justification.  I
dimly recall adamant (oral?) claims that recording errors in the Monitor
object cannot work for us.

I smell a swamp.

Can we avoid plumbing deprecation info from command code to QMP core?
Only if the QMP core itself can recognize deprecated interfaces.  I
believe it can for the cases we can expose in introspecion.  Let me
explain.

Re: [PATCH v17 00/14] Build ACPI Heterogeneous Memory Attribute Table (HMAT)

[no-reply]

Patchew URL: https://patchew.org/QEMU/20191122074826.1373-1-tao3...@intel.com/



Hi,

This series failed the docker-quick@centos7 build test. Please find the testing 
commands and
their output below. If you have Docker installed, you can probably reproduce it
locally.

=== TEST SCRIPT BEGIN ===
#!/bin/bash
make docker-image-centos7 V=1 NETWORK=1
time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1
=== TEST SCRIPT END ===

  TESTcheck-qtest-x86_64: tests/numa-test
Broken pipe
/tmp/qemu-test/src/tests/libqtest.c:149: kill_qemu() detected QEMU death from 
signal 8 (Floating point exception) (core dumped)
ERROR - too few tests run (expected 9, got 8)
make: *** [check-qtest-x86_64] Error 1
make: *** Waiting for unfinished jobs
  TESTiotest-qcow2: 172
  TESTiotest-qcow2: 174
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', 
'--label', 'com.qemu.instance.uuid=dcec428a97434211b9c0856da658ff0b', '-u', 
'1003', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=', 
'-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 
'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', 
'/home/patchew2/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', 
'/var/tmp/patchew-tester-tmp-zr9swotk/src/docker-src.2019-11-22-03.28.32.26341:/var/tmp/qemu:z,ro',
 'qemu:centos7', '/var/tmp/qemu/run', 'test-quick']' returned non-zero exit 
status 2.
filter=--filter=label=com.qemu.instance.uuid=dcec428a97434211b9c0856da658ff0b
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-zr9swotk/src'
make: *** [docker-run-test-quick@centos7] Error 2

real12m44.362s
user0m7.997s


The full log is available at
http://patchew.org/logs/20191122074826.1373-1-tao3...@intel.com/testing.docker-quick@centos7/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Re: [PATCH v35 01/13] target/avr: Add outward facing interfaces and core CPU logic

[Aleksandar Markovic]

On Friday, November 22, 2019, Richard Henderson <
richard.hender...@linaro.org> wrote:

> On 11/21/19 8:53 PM, Michael Rolnik wrote:
> > It seems to be a huge investment. this function should parse the
> > binary data as `decode_insn` does, so I suggest to modify decodetree
> > tool to make decoding information available to the instruction print
> > function.
> > what do you think?
>
> See target/openrisc/disas.c, which makes use of decodetree.
> It shouldn't be difficult to do something slimiar for avr.
>
>
I support Richard's suggested direction. Since you already implemenred core
AVR decoder using decodetree, and you have this openrisc QEMU disassembler
example, could you perhaps give a try to what Richard said, Michael?

Aleksandar



> r~
>

Re: [PATCH v3 1/4] tcg: cputlb: Add probe_read

[Richard Henderson]

On 11/21/19 1:08 AM, Beata Michalska wrote:
> Add probe_read alongside the write probing equivalent.
> 
> Signed-off-by: Beata Michalska 
> Reviewed-by: Alex Bennée 
> ---
>  include/exec/exec-all.h | 6 ++
>  1 file changed, 6 insertions(+)

Reviewed-by: Richard Henderson 


r~

Re: [PATCH v3 1/2] migration: Fix incorrect integer->float conversion caught by clang

[Juan Quintela]

Markus Armbruster  wrote:
> From: Fangrui Song 
>
> Clang does not like qmp_migrate_set_downtime()'s code to clamp double
> @value to 0..INT64_MAX:
>
> qemu/migration/migration.c:2038:24: error: implicit conversion from 
> 'long' to 'double' changes value from 9223372036854775807 to 
> 9223372036854775808 [-Werror,-Wimplicit-int-float-conversion]
>
> The warning will be enabled by default in clang 10. It is not
> available for clang <= 9.
>
> The clamp is actually useless; @value is checked to be within
> 0..MAX_MIGRATE_DOWNTIME_SECONDS immediately before.  Delete it.
>
> While there, make the conversion from double to int64_t explicit.
>
> Signed-off-by: Fangrui Song 
> Reviewed-by: Markus Armbruster 
> [Patch split, commit message improved]
> Signed-off-by: Markus Armbruster 

Reviewed-by: Juan Quintela 

Should I get this through migration tree, or are you going to pull it?

Later, Juan.

Re: [PATCH v3 2/2] util/cutils: Fix incorrect integer->float conversion caught by clang

[Juan Quintela]

Markus Armbruster  wrote:
> From: Fangrui Song 
>
> Clang does not like do_strtosz()'s code to guard against overflow:
>
> qemu/util/cutils.c:245:23: error: implicit conversion from 'unsigned 
> long' to 'double' changes value from 18446744073709550592 to 
> 18446744073709551616 [-Werror,-Wimplicit-int-float-conversion]
>
> The warning will be enabled by default in clang 10. It is not
> available for clang <= 9.
>
> val * mul >= 0xfc00 is indeed wrong.  0xfc00
> is not representable exactly as double.  It's half-way between the
> representable values 0xf800 and 0x1.
> Which one we get is implementation-defined.  Bad.
>
> We want val * mul > (the largest uint64_t exactly representable as
> double).  That's 0xf800.  Write it as nextafter(0x1p64, 0)
> with a suitable comment.
>
> Signed-off-by: Fangrui Song 
> Reviewed-by: Markus Armbruster 
> [Patch split, commit message improved]
> Signed-off-by: Markus Armbruster 

Reviewed-by: Juan Quintela 

Learning this *new* C99 float format O:-)

Re: [PATCH v17 00/14] Build ACPI Heterogeneous Memory Attribute Table (HMAT)

[no-reply]

Patchew URL: https://patchew.org/QEMU/20191122074826.1373-1-tao3...@intel.com/



Hi,

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

Subject: [PATCH v17 00/14] Build ACPI Heterogeneous Memory Attribute Table 
(HMAT)
Type: series
Message-id: 20191122074826.1373-1-tao3...@intel.com

=== 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
 - [tag update]  patchew/20191121000843.24844-1-beata.michal...@linaro.org 
-> patchew/20191121000843.24844-1-beata.michal...@linaro.org
 - [tag update]  patchew/20191122080039.12771-1-arm...@redhat.com -> 
patchew/20191122080039.12771-1-arm...@redhat.com
Switched to a new branch 'test'
9192aa6 tests/bios-tables-test: add test cases for ACPI HMAT
309fd85 tests/numa: Add case for QMP build HMAT
864da49 hmat acpi: Build Memory Side Cache Information Structure(s)
6d92931 hmat acpi: Build System Locality Latency and Bandwidth Information 
Structure(s)
39ba308 hmat acpi: Build Memory Proximity Domain Attributes Structure(s)
7d0bffc numa: Extend CLI to provide memory side cache information
3fc8a54 numa: Extend CLI to provide memory latency and bandwidth information
592a96a numa: Extend CLI to provide initiator information for numa nodes
7032fc4 tests: Add test for QAPI builtin type time
2d89c93 qapi: Add builtin type time
dbe82f5 util/cutils: Add qemu_strtotime_ns()
2fef66f util/cutils: refactor do_strtosz() to support suffixes list
2cae457 util/cutils: Use qemu_strtold_finite to parse size
a691b5f util/cutils: Add Add qemu_strtold and qemu_strtold_finite

=== OUTPUT BEGIN ===
1/14 Checking commit a691b5f92191 (util/cutils: Add Add qemu_strtold and 
qemu_strtold_finite)
ERROR: consider using qemu_strtold in preference to strtold
#61: FILE: util/cutils.c:636:
+*result = strtold(nptr, &ep);

total: 1 errors, 0 warnings, 69 lines checked

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

2/14 Checking commit 2cae457669b9 (util/cutils: Use qemu_strtold_finite to 
parse size)
3/14 Checking commit 2fef66fd2a82 (util/cutils: refactor do_strtosz() to 
support suffixes list)
4/14 Checking commit dbe82f50cf86 (util/cutils: Add qemu_strtotime_ns())
5/14 Checking commit 2d89c9350115 (qapi: Add builtin type time)
6/14 Checking commit 7032fc4756a0 (tests: Add test for QAPI builtin type time)
7/14 Checking commit 592a96a0ff21 (numa: Extend CLI to provide initiator 
information for numa nodes)
8/14 Checking commit 3fc8a542a4b7 (numa: Extend CLI to provide memory latency 
and bandwidth information)
WARNING: line over 80 characters
#130: FILE: hw/core/numa.c:299:
+/* Set lb_info_provided bit 0 as 1, latency information is 
provided */

total: 0 errors, 1 warnings, 462 lines checked

Patch 8/14 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
9/14 Checking commit 7d0bffca6382 (numa: Extend CLI to provide memory side 
cache information)
10/14 Checking commit 39ba308b5612 (hmat acpi: Build Memory Proximity Domain 
Attributes Structure(s))
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#72: 
new file mode 100644

total: 0 errors, 1 warnings, 185 lines checked

Patch 10/14 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
11/14 Checking commit 6d92931a0a40 (hmat acpi: Build System Locality Latency 
and Bandwidth Information Structure(s))
12/14 Checking commit 864da49c0ce4 (hmat acpi: Build Memory Side Cache 
Information Structure(s))
13/14 Checking commit 309fd85d39fc (tests/numa: Add case for QMP build HMAT)
WARNING: line over 80 characters
#124: FILE: tests/numa-test.c:433:
+g_assert(!qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'x-exit-preconfig' 
}")));

WARNING: line over 80 characters
#159: FILE: tests/numa-test.c:468:
+g_assert(!qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'x-exit-preconfig' 
}")));

WARNING: line over 80 characters
#206: FILE: tests/numa-test.c:515:
+g_assert(!qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'x-exit-preconfig' 
}")));

total: 0 errors, 3 warnings, 206 lines checked

Patch 13/14 has style problems, please review.  If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
14/14 Checking commit 9192aa6b273f (tests/bios-tables-test: add test cases for 
ACPI HMAT)
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#106: 
new file mode 100644

total: 0 errors, 1 warnings, 65 lines checked

Patch 14/14 has style problems, 

[PATCH] monitor: Fix slow reading

[Yury Kotov]

The monitor_can_read (as a callback of qemu_chr_fe_set_handlers)
should return size of buffer which monitor_qmp_read or monitor_read
can process.
Currently, monitor_can_read returns 1 as a result of logical not.
Thus, for each QMP command, len(QMD) iterations of the main loop
are required to handle a command.
In fact, these both functions can process any buffer size.
So, return 1024 as a reasonable size which is enough to process
the most QMP commands, but not too big to block the main loop for
a long time.

Signed-off-by: Yury Kotov 
---
 monitor/monitor.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/monitor/monitor.c b/monitor/monitor.c
index 12898b6448..cac3f39727 100644
--- a/monitor/monitor.c
+++ b/monitor/monitor.c
@@ -50,6 +50,13 @@ typedef struct {
 int64_t rate;   /* Minimum time (in ns) between two events */
 } MonitorQAPIEventConf;
 
+/*
+ * The maximum buffer size which the monitor can process in one iteration
+ * of the main loop. We don't want to block the loop for a long time
+ * because of JSON parser, so use a reasonable value.
+ */
+#define MONITOR_READ_LEN_MAX 1024
+
 /* Shared monitor I/O thread */
 IOThread *mon_iothread;
 
@@ -498,7 +505,7 @@ int monitor_can_read(void *opaque)
 {
 Monitor *mon = opaque;
 
-return !atomic_mb_read(&mon->suspend_cnt);
+return atomic_mb_read(&mon->suspend_cnt) ? 0 : MONITOR_READ_LEN_MAX;
 }
 
 void monitor_list_append(Monitor *mon)
-- 
2.24.0

Re: [PATCH] Add minimal Hexagon target - First in a series of patches - linux-user changes + linux-user/hexagon + skeleton of target/hexagon - Files in target/hexagon/imported are from another project

[Aleksandar Markovic]

On Friday, November 22, 2019, Taylor Simpson  wrote:

> Hi Aleksandar,
>
> The complete qemu-hexagon implementation can be found here
> https://github.com/quic/qemu
>
> From the beginning, I knew I would have to divide it up into smaller
> patches for review.  The discussion on how divide it was here
> https://lists.gnu.org/archive/html/qemu-devel/2019-11/msg01971.html
>
I'll summarize the proposal
> 1) linux-user changes + linux-user/hexagon + skeleton of target/hexagon
> 2) Add the code this imported from the Hexagon simulator and the qemu
> helper generator
> 3) Add support for packet semantics
> 4) Add support for wide vector extensions
> 5) Add the helper overrides for performance optimization
>
>
I think you, for some reason, mix and keep mixing two really different
things:

- outline of your changes (as seen as points 1-5 above)

- a patch

None of points 1-5 could be a patch. All of them should be patch series, or
part of patch series.

I am surprised that it seems as if you did not take a look at the previous
cases of platform introductions to QEMU. Or you did, but decided you don't
need to bother creating patch series, you don't need to follow QEMU
submission guidelines - you apparently think you can simply send the
changes as several huge patches.


> My assumption in the proposal was that each phase of the submission should
> compile and execute, and each phase should expand the capabilities of the
> Hexagon target.  I apologize that it wasn't clear how large each of the
> patches would be.
>
> I greatly appreciate all of the feedback on the proposal and the patch,
> and I am making the revisions.  In several cases, the feedback also applies
> to the remainder of the code.  So, I am making the changes there as well.
> From that perspective, I think it will reduce the overall burden on the
> reviewers.
>
> As far as what might change in the imported files goes, the current
> simulator (hexagon-sim) has been used in production as part of the
> toolchain for over a decade and has been used to verify every version of
> the core that we have shipped.  Since it is used in verification, it is
> considered the gold standard - more so than the PDF manual.  Any changes to
> that code, including reformatting, would put qemu at risk of not accurately
> emulating the processor.
>
>
We in MIPS also have ISA verification software that can be viewed as "gold
standard", but we don't burden QEMU with any imported files - and we
certainly could, using the same rationale as you do.

I am opposed to considering the output (or a part) of an internally
developed simulator more important than (or on the same level as)
documentation, and calling it a "gold standard".

A gold-standard-related question arises here:

If something is called a "gold standard", should it be a constant, by its
very definition?

Also, you did not answer my question from my previous resoonse, which was:

What do you expect to be changing in imported-from-another-simulator code?

And I add another one:

What exactly components of QEMU for Hexagon are contained in
imported-from-another-simulator code?

Thanks,
Aleksandar


> Taylor
>
>
> -Original Message-
> From: Aleksandar Markovic 
> Sent: Thursday, November 21, 2019 2:45 PM
> To: Taylor Simpson 
> Cc: Laurent Vivier ; Riku Voipio ;
> QEMU Developers 
> Subject: Re: [PATCH] Add minimal Hexagon target - First in a series of
> patches - linux-user changes + linux-user/hexagon + skeleton of
> target/hexagon - Files in target/hexagon/imported are from another project
> and therefore do not conform to qemu coding standards
>
> On Thu, Nov 21, 2019 at 8:52 PM Taylor Simpson 
> wrote:
> >
> > They are imported from the existing Hexagon simulator.  Please
> understand that this patch is the first in a series.  Later patches will
> contain more elaborate contents in that directory.  The reason I don't want
> to reformat them is to stay in sync with the other simulator in the
> future.  When the other team makes changes to the code (either to fix bugs
> or add features), it will be easier to identify the changes and bring them
> into qemu.
> >
> > Taylor
> >
>
> Taylor,
>
> Please understand that this patch can't remain a single patch. It can't
> remain even a set of 2 or 3 patches as others suggested. A patch is a
> logically connected unit of code whose typical size is less than
> 200 lines. There are lots of such logical units in this single path that
> you sent, and you should not have sent it in its present form, even if you
> wanted just comments to it. You should have submitted a series rather than
> a single patch. And you should have said this is v1 of my series that I
> will expand later on. Guidelines for submissions are here:
>
> https://wiki.qemu.org/Contribute/SubmitAPatch
>
> As far as "imported" files, frankly, I dislike the fact that you are
> willing to sacrifice our coding style guidelines in favor to your
> convenience. But, more than this, I also find ver

Re: [PATCH 0/4] colo: Introduce resource agent and high-level test

[Dr. David Alan Gilbert]

* Lukas Straub (lukasstra...@web.de) wrote:
> Hello Everyone,
> These patches introduce a resource agent for use with the Pacemaker CRM and a
> high-level test utilizing it for testing qemu COLO.
> 
> The resource agent manages qemu COLO including continuous replication.
> 
> Currently the second test case (where the peer qemu is frozen) fails on 
> primary
> failover, because qemu hangs while removing the replication related block 
> nodes.
> Note that this also happens in real world test when cutting power to the peer
> host, so this needs to be fixed.

Do you understand why that happens? Is this it's trying to finish a
read/write to the dead partner?

Dave

> Based-on: 
> ([PATCH v7 0/4] colo: Add support for continuous replication)
> 
> Lukas Straub (4):
>   block/quorum.c: stable children names
>   colo: Introduce resource agent
>   colo: Introduce high-level test
>   MAINTAINERS: Add myself as maintainer for COLO resource agent
> 
>  MAINTAINERS|6 +
>  block/quorum.c |6 +
>  scripts/colo-resource-agent/colo   | 1026 
>  scripts/colo-resource-agent/crm_master |   44 +
>  tests/acceptance/colo.py   |  444 ++
>  5 files changed, 1526 insertions(+)
>  create mode 100755 scripts/colo-resource-agent/colo
>  create mode 100755 scripts/colo-resource-agent/crm_master
>  create mode 100644 tests/acceptance/colo.py
> 
> --
> 2.20.1
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

[Bug 1848556] Re: qemu-img check failing on remote image in Eoan

[Timo Aaltonen]

Hello Rod, or anyone else affected,

Accepted qemu into eoan-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/qemu/1:4.0+dfsg-
0ubuntu9.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package.  See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed.  Your feedback will aid us getting this
update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-eoan to verification-done-eoan. If it does not fix
the bug for you, please add a comment stating that, and change the tag
to verification-failed-eoan. In either case, without details of your
testing we will not be able to proceed.

Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification .  Thank you in
advance for helping!

N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.

** Changed in: qemu (Ubuntu Eoan)
   Status: Triaged => Fix Committed

** Tags added: verification-needed verification-needed-eoan

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1848556

Title:
  qemu-img check failing on remote image in Eoan

Status in QEMU:
  Fix Released
Status in qemu package in Ubuntu:
  Fix Released
Status in qemu source package in Eoan:
  Fix Committed
Status in qemu source package in Focal:
  Fix Released

Bug description:
  Ubuntu SRU Template:

  [Impact]

   * There is fallout due to changes in libcurl that affect qemu and might 
 lead to a hang.

   * Fix by backporting the upstream fix

  [Test Case]

   * If you have network just run
 $ qemu-img check http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img

   * Without network, install apache2, and get a complex qemu file (like a 
 cloud image) onto the system. Then access the file via apache http but 
 not localhost (that would work)

  [Regression Potential]

   * The change is local to the libcurl usage of qemu, so that could be 
 affected. But then this is what has been found to not work here, so I'd 
 expect not too much trouble. But if so then in the curl usage (which 
 means disks on http)

  [Other Info]
   
   * n/a

  ---

  The "qemu-img check" function is failing on remote (HTTP-hosted)
  images, beginning with Ubuntu 19.10 (qemu-utils version 1:4.0+dfsg-
  0ubuntu9). With previous versions, through Ubuntu 19.04/qemu-utils
  version 1:3.1+dfsg-2ubuntu3.5, the following worked:

  $ /usr/bin/qemu-img check  
http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img
  No errors were found on the image.
  19778/36032 = 54.89% allocated, 90.34% fragmented, 89.90% compressed clusters
  Image end offset: 514064384

  The 10.193.37.117 server holds an Apache server that hosts the cloud
  images on a LAN. Beginning with Ubuntu 19.10/qemu-utils 1:4.0+dfsg-
  0ubuntu9, the same command never returns. (I've left it for up to an
  hour with no change.) I'm able to wget the image from the same server
  and installation on which qemu-img check fails. I've tried several
  .img files on the server, ranging from Bionic to Eoan, with the same
  results with all of them.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1848556/+subscriptions

Re: [PATCH 1/4] virtiofsd: Release file locks using F_UNLCK

[Stefan Hajnoczi]

On Fri, Nov 15, 2019 at 03:55:40PM -0500, Vivek Goyal wrote:
> diff --git a/contrib/virtiofsd/passthrough_ll.c 
> b/contrib/virtiofsd/passthrough_ll.c
> index bc214df0c7..028e7da273 100644
> --- a/contrib/virtiofsd/passthrough_ll.c
> +++ b/contrib/virtiofsd/passthrough_ll.c
> @@ -936,6 +936,14 @@ static void put_shared(struct lo_data *lo, struct 
> lo_inode *inode)
>   }
>  }
>  
> +static void release_plock(gpointer data)

The name posix_locks_value_destroy() would be clearer because it matches
g_hash_table_new_full() terminology and the function cannot be confused
with a lock acquire/release operation.

This patch conflicts with the cleanups that are currently being made to
virtiofsd:
https://github.com/stefanha/qemu/commit/1e493175feca58a81a2d0cbdac93b92e5425d850#diff-ca2dea995d1e6cdb95c8a47c7cca51ceR773

Stefan


signature.asc
Description: PGP signature

Re: [PATCH 0/4] s390x: Reset cleanup

[no-reply]

Patchew URL: 
https://patchew.org/QEMU/20191122075218.23935-1-fran...@linux.ibm.com/



Hi,

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

Subject: [PATCH 0/4] s390x: Reset cleanup
Type: series
Message-id: 20191122075218.23935-1-fran...@linux.ibm.com

=== 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
Switched to a new branch 'test'
b557dea s390x: Beautify machine reset
e5244c7 s390x: Beautify diag308 handling
288f436 s390x: Cleanup cpu resets
9f85af6 s390x: Don't do a normal reset on the initial cpu

=== OUTPUT BEGIN ===
1/4 Checking commit 9f85af68844a (s390x: Don't do a normal reset on the initial 
cpu)
2/4 Checking commit 288f436dc8e9 (s390x: Cleanup cpu resets)
3/4 Checking commit e5244c7edde8 (s390x: Beautify diag308 handling)
ERROR: code indent should never use tabs
#25: FILE: target/s390x/diag.c:56:
+#define DIAG308_RESET_MOD_CLR^I^I0$

ERROR: code indent should never use tabs
#26: FILE: target/s390x/diag.c:57:
+#define DIAG308_RESET_LOAD_NORM^I^I1$

ERROR: code indent should never use tabs
#27: FILE: target/s390x/diag.c:58:
+#define DIAG308_LOAD_CLEAR^I^I3$

ERROR: code indent should never use tabs
#28: FILE: target/s390x/diag.c:59:
+#define DIAG308_LOAD_NORMAL_DUMP^I4$

ERROR: code indent should never use tabs
#29: FILE: target/s390x/diag.c:60:
+#define DIAG308_SET^I^I^I5$

ERROR: code indent should never use tabs
#30: FILE: target/s390x/diag.c:61:
+#define DIAG308_STORE^I^I^I6$

total: 6 errors, 0 warnings, 83 lines checked

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

4/4 Checking commit b557dea18bc1 (s390x: Beautify machine reset)
=== OUTPUT END ===

Test command exited with code: 1


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

Re: [PATCH v4 12/37] serial: start making SerialMM a sysbus device

[Peter Maydell]

On Thu, 21 Nov 2019 at 18:51, Marc-André Lureau
 wrote:
>
> Hi
>
> On Thu, Nov 21, 2019 at 10:24 PM Peter Maydell  
> wrote:
> >
> > On Thu, 21 Nov 2019 at 18:15, Marc-André Lureau
> >  wrote:
> > >
> > > On Thu, Nov 21, 2019 at 5:47 PM Peter Maydell  
> > > wrote:
> > > >
> > > > On Wed, 20 Nov 2019 at 15:27, Marc-André Lureau
> > > >  wrote:
> > > > >
> > > > > Memory mapped serial device is in fact a sysbus device. The following
> > > > > patches will make use of sysbus facilities for resource and
> > > > > registration. In particular, "serial-mm: use sysbus facilities" will
> > > > > move internal serial realization to serial_mm_realize callback to
> > > > > follow qdev best practices.
> > > >
> > > > What goes wrong if you just put the realize of smm->serial in
> > > > the right place to start with ?
> > >
> > > You mean squash the following patches?
> >
> > No, I meant just having this patch have
> >
> > static void serial_mm_realize(DeviceState *dev, Error **errp)
> > {
> > SerialMM *smm = SERIAL_MM(dev);
> > SerialState *s = &smm->serial;
> >
> > object_property_set_bool(OBJECT(dev), true, "realized", &err);
> > if (err) {
> > error_propagate(errp, err);
> > return;
> > }
> > }
> >
> > and
> >
> > + dc->realize = serial_mm_realize;
> >
> > rather than manually doing the qdev_init_nofail()
> > in serial_mm_init(). This seems to me like an integral
> > part of the change to doing the init of the subdevice in the
> > init method, so it would be better unless there's a reason
> > why it breaks something. The rest of patch 15 (which is
> > what currently makes the equivalent change to realize) is all
> > about passing through the properties and exposing the
> > sysbus MMIO/irq regions and should stay a separate patch.
> >
> > (setting the 'realized' property is better in a realize method
> > than using qdev_init_nofail() because it means we can propagate
> > any error outward rather than killing qemu.)
>
> Ok, but I implemented realize and moved serial init in "serial: make
> SerialIO a sysbus device".

That patch is for the TYPE_SERIAL_IO device, isn't it? It
changes both serial_io_instance_init and serial_io_realize
to do the instance init and realize of the TYPE_SERIAL device,
so it doesn't have the same "only doing half a change" issue
that this patch has for TYPE_SERIAL_MM.

thanks
-- PMM

Re: [PATCH 0/9] RFC: [for 5.0]: HMP monitor handlers cleanups

[Dr. David Alan Gilbert]

* Maxim Levitsky (mlevi...@redhat.com) wrote:
> This patch series is bunch of cleanups
> to the hmp monitor code.
> 
> This series only touched blockdev related hmp handlers.

Hi Maxim,
  This looks mostly OK to me from the HMP side - with one change;
can you please move the blockdev-hmp-cmds.c into either monitor/ or
block/; with that


Reviewed-by: Dr. David Alan Gilbert 

we also need a corresponding review by a block person.

Dave


> No functional changes expected other that
> light error message changes by the last patch.
> 
> This was inspired by this bugzilla:
> https://bugzilla.redhat.com/show_bug.cgi?id=1719169
> 
> Basically some users still parse hmp error messages,
> and they would like to have them prefixed with 'Error:'
> 
> In commit 66363e9a43f649360a3f74d2805c9f864da027eb we added
> the hmp_handle_error which does exactl that but some hmp handlers
> don't use it.
> 
> In this patch series, I moved all the block related hmp handlers
> into blockdev-hmp-cmds.c, and then made them use this function
> to report the errors.
> 
> I hope I didn't change too much code, I just felt that if
> I touch this code, I can also make it easier to find these
> handlers, that were scattered over 3 different files.
> 
> Best regards,
>   Maxim Levitsky
> 
> Maxim Levitsky (9):
>   monitor: uninline add_init_drive
>   monitor: rename device-hotplug.c to blockdev-hmp-cmds.c
>   monitor: move hmp_drive_del and hmp_commit to blockdev-hmp-cmds.c
>   monitor: move hmp_drive_mirror and hmp_drive_backup to
> blockdev-hmp-cmds.c
>   monitor: move hmp_block_job* to blockdev-hmp-cmd.c
>   monitor: move hmp_snapshot_* to blockdev-hmp-cmds.c
>   monitor: move remaining hmp_block* functions to blockdev-hmp-cmds.c
>   monitor: move hmp_info_block* to blockdev-hmp-cmds.c
>   monitor/hmp: Prefer to use hmp_handle_error for error reporting in
> block hmp commands
> 
>  MAINTAINERS |   1 +
>  Makefile.objs   |   4 +-
>  blockdev-hmp-cmds.c | 656 
>  blockdev.c  |  95 ---
>  device-hotplug.c|  91 --
>  monitor/hmp-cmds.c  | 465 ---
>  6 files changed, 659 insertions(+), 653 deletions(-)
>  create mode 100644 blockdev-hmp-cmds.c
>  delete mode 100644 device-hotplug.c
> 
> -- 
> 2.17.2
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

Re: [PATCH for-5.0 v5 16/23] ppc/xive: Extend the TIMA operation with a XivePresenter parameter

[Greg Kurz]

On Fri, 15 Nov 2019 17:24:29 +0100
Cédric Le Goater  wrote:

> The TIMA operations are performed on behalf of the XIVE IVPE sub-engine
> (Presenter) on the thread interrupt context registers. The current
> operations supported by the model are simple and do not require access
> to the controller but more complex operations will need access to the
> controller NVT table and to its configuration.
> 
> Signed-off-by: Cédric Le Goater 
> ---

Reviewed-by: Greg Kurz 

>  include/hw/ppc/xive.h |  7 +++---
>  hw/intc/pnv_xive.c|  4 +--
>  hw/intc/xive.c| 58 ---
>  3 files changed, 38 insertions(+), 31 deletions(-)
> 
> diff --git a/include/hw/ppc/xive.h b/include/hw/ppc/xive.h
> index b00af988779b..97bbcddb381d 100644
> --- a/include/hw/ppc/xive.h
> +++ b/include/hw/ppc/xive.h
> @@ -463,9 +463,10 @@ typedef struct XiveENDSource {
>  #define XIVE_TM_USER_PAGE   0x3
>  
>  extern const MemoryRegionOps xive_tm_ops;
> -void xive_tctx_tm_write(XiveTCTX *tctx, hwaddr offset, uint64_t value,
> -unsigned size);
> -uint64_t xive_tctx_tm_read(XiveTCTX *tctx, hwaddr offset, unsigned size);
> +void xive_tctx_tm_write(XivePresenter *xptr, XiveTCTX *tctx, hwaddr offset,
> +uint64_t value, unsigned size);
> +uint64_t xive_tctx_tm_read(XivePresenter *xptr, XiveTCTX *tctx, hwaddr 
> offset,
> +   unsigned size);
>  
>  void xive_tctx_pic_print_info(XiveTCTX *tctx, Monitor *mon);
>  Object *xive_tctx_create(Object *cpu, XiveRouter *xrtr, Error **errp);
> diff --git a/hw/intc/pnv_xive.c b/hw/intc/pnv_xive.c
> index 4c8c6e51c20f..3ee28f00694a 100644
> --- a/hw/intc/pnv_xive.c
> +++ b/hw/intc/pnv_xive.c
> @@ -1436,7 +1436,7 @@ static void xive_tm_indirect_write(void *opaque, hwaddr 
> offset,
>  {
>  XiveTCTX *tctx = pnv_xive_get_indirect_tctx(PNV_XIVE(opaque));
>  
> -xive_tctx_tm_write(tctx, offset, value, size);
> +xive_tctx_tm_write(XIVE_PRESENTER(opaque), tctx, offset, value, size);
>  }
>  
>  static uint64_t xive_tm_indirect_read(void *opaque, hwaddr offset,
> @@ -1444,7 +1444,7 @@ static uint64_t xive_tm_indirect_read(void *opaque, 
> hwaddr offset,
>  {
>  XiveTCTX *tctx = pnv_xive_get_indirect_tctx(PNV_XIVE(opaque));
>  
> -return xive_tctx_tm_read(tctx, offset, size);
> +return xive_tctx_tm_read(XIVE_PRESENTER(opaque), tctx, offset, size);
>  }
>  
>  static const MemoryRegionOps xive_tm_indirect_ops = {
> diff --git a/hw/intc/xive.c b/hw/intc/xive.c
> index ab62bda85788..a9298783e7d2 100644
> --- a/hw/intc/xive.c
> +++ b/hw/intc/xive.c
> @@ -144,19 +144,20 @@ static inline uint32_t xive_tctx_word2(uint8_t *ring)
>   * XIVE Thread Interrupt Management Area (TIMA)
>   */
>  
> -static void xive_tm_set_hv_cppr(XiveTCTX *tctx, hwaddr offset,
> -uint64_t value, unsigned size)
> +static void xive_tm_set_hv_cppr(XivePresenter *xptr, XiveTCTX *tctx,
> +hwaddr offset, uint64_t value, unsigned size)
>  {
>  xive_tctx_set_cppr(tctx, TM_QW3_HV_PHYS, value & 0xff);
>  }
>  
> -static uint64_t xive_tm_ack_hv_reg(XiveTCTX *tctx, hwaddr offset, unsigned 
> size)
> +static uint64_t xive_tm_ack_hv_reg(XivePresenter *xptr, XiveTCTX *tctx,
> +   hwaddr offset, unsigned size)
>  {
>  return xive_tctx_accept(tctx, TM_QW3_HV_PHYS);
>  }
>  
> -static uint64_t xive_tm_pull_pool_ctx(XiveTCTX *tctx, hwaddr offset,
> -  unsigned size)
> +static uint64_t xive_tm_pull_pool_ctx(XivePresenter *xptr, XiveTCTX *tctx,
> +  hwaddr offset, unsigned size)
>  {
>  uint32_t qw2w2_prev = xive_tctx_word2(&tctx->regs[TM_QW2_HV_POOL]);
>  uint32_t qw2w2;
> @@ -166,13 +167,14 @@ static uint64_t xive_tm_pull_pool_ctx(XiveTCTX *tctx, 
> hwaddr offset,
>  return qw2w2;
>  }
>  
> -static void xive_tm_vt_push(XiveTCTX *tctx, hwaddr offset,
> +static void xive_tm_vt_push(XivePresenter *xptr, XiveTCTX *tctx, hwaddr 
> offset,
>  uint64_t value, unsigned size)
>  {
>  tctx->regs[TM_QW3_HV_PHYS + TM_WORD2] = value & 0xff;
>  }
>  
> -static uint64_t xive_tm_vt_poll(XiveTCTX *tctx, hwaddr offset, unsigned size)
> +static uint64_t xive_tm_vt_poll(XivePresenter *xptr, XiveTCTX *tctx,
> +hwaddr offset, unsigned size)
>  {
>  return tctx->regs[TM_QW3_HV_PHYS + TM_WORD2] & 0xff;
>  }
> @@ -315,13 +317,14 @@ static uint64_t xive_tm_raw_read(XiveTCTX *tctx, hwaddr 
> offset, unsigned size)
>   * state changes (side effects) in addition to setting/returning the
>   * interrupt management area context of the processor thread.
>   */
> -static uint64_t xive_tm_ack_os_reg(XiveTCTX *tctx, hwaddr offset, unsigned 
> size)
> +static uint64_t xive_tm_ack_os_reg(XivePresenter *xptr, XiveTCTX *tctx,
> +   hwaddr offset, unsigned size)
>  {
>  return xive_

Re: [PATCH 2/4] virtiofd: Create a notification queue

[Stefan Hajnoczi]

On Fri, Nov 15, 2019 at 03:55:41PM -0500, Vivek Goyal wrote:
>  /* Callback from libvhost-user */
>  static void fv_set_features(VuDev *dev, uint64_t features)
>  {
> +struct fv_VuDev *vud = container_of(dev, struct fv_VuDev, dev);
> +struct fuse_session *se = vud->se;
> +
> +if ((1 << VIRTIO_FS_F_NOTIFICATION) & features) {

For consistency 1ull should be used.  That way the reader does not have
to check the bit position to verify that the bitmap isn't truncated at
32 bits.

> +vud->notify_enabled = true;
> +se->notify_enabled = true;

Only one copy of this field is needed.  vud has a pointer to se.

> +}
>  }
>  
>  /*
> @@ -662,6 +671,65 @@ static void fv_queue_worker(gpointer data, gpointer 
> user_data)
>  free(req);
>  }
>  
> +static void *fv_queue_notify_thread(void *opaque)
> +{
> +struct fv_QueueInfo *qi = opaque;
> +
> +fuse_log(FUSE_LOG_INFO, "%s: Start for queue %d kick_fd %d\n", __func__,
> + qi->qidx, qi->kick_fd);
> +
> +while (1) {
> +struct pollfd pf[2];
> +
> +pf[0].fd = qi->kick_fd;
> +pf[0].events = POLLIN;
> +pf[0].revents = 0;
> +pf[1].fd = qi->kill_fd;
> +pf[1].events = POLLIN;
> +pf[1].revents = 0;
> +
> +fuse_log(FUSE_LOG_DEBUG, "%s: Waiting for Queue %d event\n", 
> __func__,
> + qi->qidx);
> +int poll_res = ppoll(pf, 2, NULL, NULL);
> +
> +if (poll_res == -1) {
> +if (errno == EINTR) {
> +fuse_log(FUSE_LOG_INFO, "%s: ppoll interrupted, going 
> around\n",
> + __func__);
> +continue;
> +}
> +fuse_log(FUSE_LOG_ERR, "fv_queue_thread ppoll: %m\n");
> +break;
> +}
> +assert(poll_res >= 1);
> +if (pf[0].revents & (POLLERR | POLLHUP | POLLNVAL)) {
> +fuse_log(FUSE_LOG_ERR, "%s: Unexpected poll revents %x Queue 
> %d\n",
> + __func__, pf[0].revents, qi->qidx);
> + break;
> +}
> +if (pf[1].revents & (POLLERR | POLLHUP | POLLNVAL)) {
> +fuse_log(FUSE_LOG_ERR, "%s: Unexpected poll revents %x Queue %d"
> + "killfd\n", __func__, pf[1].revents, qi->qidx);
> +break;
> +}
> +if (pf[1].revents) {
> +fuse_log(FUSE_LOG_INFO, "%s: kill event on queue %d - 
> quitting\n",
> + __func__, qi->qidx);
> +break;
> +}
> +assert(pf[0].revents & POLLIN);
> +fuse_log(FUSE_LOG_DEBUG, "%s: Got queue event on Queue %d\n", 
> __func__,
> + qi->qidx);
> +
> +eventfd_t evalue;
> +if (eventfd_read(qi->kick_fd, &evalue)) {
> +fuse_log(FUSE_LOG_ERR, "Eventfd_read for queue: %m\n");
> +break;
> +}
> +}
> +return NULL;
> +}

It's difficult to review function without any actual functionality using
the virtqueue.  I'm not sure a thread is even needed since the device
only needs to get a buffer when it has a notification for the driver.
I'll have to wait for the following patches to see what happens here...

> @@ -378,12 +382,23 @@ static void vuf_set_status(VirtIODevice *vdev, uint8_t 
> status)
>  }
>  }
>  
> -static uint64_t vuf_get_features(VirtIODevice *vdev,
> -  uint64_t requested_features,
> -  Error **errp)
> +static uint64_t vuf_get_features(VirtIODevice *vdev, uint64_t features,
> + Error **errp)
>  {
> -/* No feature bits used yet */
> -return requested_features;
> +VHostUserFS *fs = VHOST_USER_FS(vdev);
> +
> +virtio_add_feature(&features, VIRTIO_FS_F_NOTIFICATION);
> +
> +return vhost_get_features(&fs->vhost_dev, user_feature_bits, features);
> +}
> +
> +static void vuf_set_features(VirtIODevice *vdev, uint64_t features)
> +{
> +VHostUserFS *fs = VHOST_USER_FS(vdev);
> +
> +if (virtio_has_feature(features, VIRTIO_FS_F_NOTIFICATION)) {
> +fs->notify_enabled = true;

This field is unused, please remove it.


signature.asc
Description: PGP signature

Re: [PATCH] monitor: Fix slow reading

[Philippe Mathieu-Daudé]

Cc'ing the chardev maintainers.

On 11/22/19 10:23 AM, Yury Kotov wrote:

The monitor_can_read (as a callback of qemu_chr_fe_set_handlers)
should return size of buffer which monitor_qmp_read or monitor_read
can process.
Currently, monitor_can_read returns 1 as a result of logical not.
Thus, for each QMP command, len(QMD) iterations of the main loop
are required to handle a command.
In fact, these both functions can process any buffer size.
So, return 1024 as a reasonable size which is enough to process
the most QMP commands, but not too big to block the main loop for
a long time.

Signed-off-by: Yury Kotov 
---
  monitor/monitor.c | 9 -
  1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/monitor/monitor.c b/monitor/monitor.c
index 12898b6448..cac3f39727 100644
--- a/monitor/monitor.c
+++ b/monitor/monitor.c
@@ -50,6 +50,13 @@ typedef struct {
  int64_t rate;   /* Minimum time (in ns) between two events */
  } MonitorQAPIEventConf;
  
+/*

+ * The maximum buffer size which the monitor can process in one iteration
+ * of the main loop. We don't want to block the loop for a long time
+ * because of JSON parser, so use a reasonable value.
+ */
+#define MONITOR_READ_LEN_MAX 1024


This looks reasonable.
Reviewed-by: Philippe Mathieu-Daudé 


+
  /* Shared monitor I/O thread */
  IOThread *mon_iothread;
  
@@ -498,7 +505,7 @@ int monitor_can_read(void *opaque)

  {
  Monitor *mon = opaque;
  
-return !atomic_mb_read(&mon->suspend_cnt);

+return atomic_mb_read(&mon->suspend_cnt) ? 0 : MONITOR_READ_LEN_MAX;
  }
  
  void monitor_list_append(Monitor *mon)

Re: [Qemu-devel] [PATCH v4 03/14] qapi: Introduce default values for struct members

[Kevin Wolf]

Am 22.11.2019 um 08:29 hat Markus Armbruster geschrieben:
> > At any rate, your counterpoint is taken - whatever we pick, we'll want
> > to make sure that introspection can expose semantics, and whether we
> > can make '*' redundant with some other form of longhand in the qapi
> > language is in part determined by whether we also reflect that through
> > introspection.
> 
> Introspection has the true member name, without the '*' prefix.
> 
> We'll also want to avoid unnecessary compromises on QAPI schema
> expressiveness.  If we use null to mean "schema does not specify
> behavior when member is absent", we can't use it to mean "absent member
> behaves like the value null".  A bit of a blemish, but I think it's a
> tolerable one.

If you want an example for an option that defaults to null, take the
backing option of BlockdevOptionsGenericCOWFormat.

What is the reason for even considering limiting the expressiveness? Do
you think that an additional 'optional' bool, at least for those options
that don't have a default, would be so bad in the longhand form? Or
keeping '*' even in the longhand form, as suggested below.

> > If that means that keeping '*' in the longhand form of
> > optional members (whether or not those members have a default value),
> > then so be it.
> 
> I believe both
> 
> '*KEY': { 'type': ARG': 'default': null }
> 
> and
> 
> 'KEY': { 'type': ARG': 'default': null }
> 
> are viable longhand forms for '*KEY': 'ARG'.
> 
> I prefer the latter, but I'm open to arguments.

If you go for the former, then you certainly want to use absent
'default' to indicate no default, and allow a QNull default with
'default': null.

The only reason to abuse 'default': null for no default is that you
can't distinguish optional and non-optional if you use 'KEY' for both
instead of 'KEY' for mandatory and '*KEY' for optional.

So while I understand and to some degree share your dislike for the '*'
prefix, I think I cast my pragmatic vote for:

mandatory:   'KEY':  { 'type': 'ARG' }
optional without a default:  '*KEY': { 'type': 'ARG' }
optional with QNull default: '*KEY': { 'type': 'ARG', 'default': null }

Kevin

Re: [PATCH 0/9] RFC: [for 5.0]: HMP monitor handlers cleanups

[Kevin Wolf]

Am 22.11.2019 um 11:15 hat Dr. David Alan Gilbert geschrieben:
> * Maxim Levitsky (mlevi...@redhat.com) wrote:
> > This patch series is bunch of cleanups
> > to the hmp monitor code.
> > 
> > This series only touched blockdev related hmp handlers.
> 
> Hi Maxim,
>   This looks mostly OK to me from the HMP side - with one change;
> can you please move the blockdev-hmp-cmds.c into either monitor/ or
> block/; with that

Let's create a block/monitor/hmp.c then. There is more stuff that could
move into that directory later.

Kevin

Re: [PATCH v3 1/2] migration: Fix incorrect integer->float conversion caught by clang

[Philippe Mathieu-Daudé]

On 11/22/19 9:00 AM, Markus Armbruster wrote:

From: Fangrui Song 

Clang does not like qmp_migrate_set_downtime()'s code to clamp double
@value to 0..INT64_MAX:

 qemu/migration/migration.c:2038:24: error: implicit conversion from 'long' 
to 'double' changes value from 9223372036854775807 to 9223372036854775808 
[-Werror,-Wimplicit-int-float-conversion]

The warning will be enabled by default in clang 10. It is not
available for clang <= 9.

The clamp is actually useless; @value is checked to be within
0..MAX_MIGRATE_DOWNTIME_SECONDS immediately before.  Delete it.

While there, make the conversion from double to int64_t explicit.

Signed-off-by: Fangrui Song 
Reviewed-by: Markus Armbruster 
[Patch split, commit message improved]
Signed-off-by: Markus Armbruster 
---
  migration/migration.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/migration/migration.c b/migration/migration.c
index 354ad072fa..09b150663f 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -2035,11 +2035,10 @@ void qmp_migrate_set_downtime(double value, Error 
**errp)
  }
  
  value *= 1000; /* Convert to milliseconds */

-value = MAX(0, MIN(INT64_MAX, value));
  
  MigrateSetParameters p = {

  .has_downtime_limit = true,
-.downtime_limit = value,
+.downtime_limit = (int64_t)value,


I agree with Eric a one line comment about the explicit cast is 
welcomed. We can still use 'git blame', find the last commit sha, then 
look at the commit description. But having it along the code is 
straightforward.


Preferably with a comment (the maintainer queing this can amend it):
Reviewed-by: Philippe Mathieu-Daudé 


  };
  
  qmp_migrate_set_parameters(&p, errp);

Re: [PATCH 3/4] virtiofsd: Specify size of notification buffer using config space

[Stefan Hajnoczi]

On Fri, Nov 15, 2019 at 03:55:42PM -0500, Vivek Goyal wrote:
> diff --git a/contrib/virtiofsd/fuse_virtio.c b/contrib/virtiofsd/fuse_virtio.c
> index 44c9b3..982b6ad0bd 100644
> --- a/contrib/virtiofsd/fuse_virtio.c
> +++ b/contrib/virtiofsd/fuse_virtio.c
> @@ -109,7 +109,8 @@ static uint64_t fv_get_features(VuDev *dev)
>  uint64_t features;
>  
>  features = 1ull << VIRTIO_F_VERSION_1 |
> -   1ull << VIRTIO_FS_F_NOTIFICATION;
> +   1ull << VIRTIO_FS_F_NOTIFICATION |
> +   1ull << VHOST_USER_F_PROTOCOL_FEATURES;

This is not needed since VHOST_USER_F_PROTOCOL_FEATURES is already added
by vu_get_features_exec():

  vu_get_features_exec(VuDev *dev, VhostUserMsg *vmsg)
  {
  vmsg->payload.u64 =
  1ULL << VHOST_F_LOG_ALL |
  1ULL << VHOST_USER_F_PROTOCOL_FEATURES;

  if (dev->iface->get_features) {
  vmsg->payload.u64 |= dev->iface->get_features(dev);
  }

>  
>  return features;
>  }
> @@ -927,6 +928,27 @@ static bool fv_queue_order(VuDev *dev, int qidx)
>  return false;
>  }
>  
> +static uint64_t fv_get_protocol_features(VuDev *dev)
> +{
> + return 1ull << VHOST_USER_PROTOCOL_F_CONFIG;
> +}

Please change vu_get_protocol_features_exec() in a separate patch so
that devices don't need this boilerplate .get_protocol_features() code:

  static bool
  vu_get_protocol_features_exec(VuDev *dev, VhostUserMsg *vmsg)
  {
  ...
 -if (dev->iface->get_config && dev->iface->set_config) {
 +if (dev->iface->get_config || dev->iface->set_config) {
  features |= 1ULL << VHOST_USER_PROTOCOL_F_CONFIG;
  }

> +
> +static int fv_get_config(VuDev *dev, uint8_t *config, uint32_t len)
> +{
> + struct virtio_fs_config fscfg = {};
> +
> + fuse_log(FUSE_LOG_DEBUG, "%s:Setting notify_buf_size=%d\n", __func__,
> + sizeof(struct fuse_notify_lock_out));
> + /*
> +  * As of now only notification related to lock is supported. As more
> +  * notification types are supported, bump up the size accordingly.
> +  */
> + fscfg.notify_buf_size = sizeof(struct fuse_notify_lock_out);

Missing cpu_to_le32().

I'm not sure about specifying the size precisely down to the last byte
because any change to guest-visible aspects of the device (like VIRTIO
Configuration Space) are not compatible across live migration.  It will
be necessary to introduce a device version command-line option for live
migration compatibility so that existing guests can be migrated to a new
virtiofsd without the device changing underneath them.

How about rounding this up to 4 KB?

>  static void vuf_get_config(VirtIODevice *vdev, uint8_t *config)
>  {
>  VHostUserFS *fs = VHOST_USER_FS(vdev);
>  struct virtio_fs_config fscfg = {};
> +int ret;
> +
> +/*
> + * As of now we only get notification buffer size from device. And that's
> + * needed only if notification queue is enabled.
> + */
> +if (fs->notify_enabled) {
> +ret = vhost_dev_get_config(&fs->vhost_dev, (uint8_t *)&fs->fscfg,
> +   sizeof(struct virtio_fs_config));
> + if (ret < 0) {

Indentation.

> +error_report("vhost-user-fs: get device config space failed."
> + " ret=%d\n", ret);
> +return;
> +}

Missing le32_to_cpu() for notify_buf_size.

> +}
>  
>  memcpy((char *)fscfg.tag, fs->conf.tag,
> MIN(strlen(fs->conf.tag) + 1, sizeof(fscfg.tag)));
>  
>  virtio_stl_p(vdev, &fscfg.num_request_queues, 
> fs->conf.num_request_queues);
> +virtio_stl_p(vdev, &fscfg.notify_buf_size, fs->fscfg.notify_buf_size);
>  
>  memcpy(config, &fscfg, sizeof(fscfg));
>  }
> @@ -545,6 +569,8 @@ static void vuf_device_realize(DeviceState *dev, Error 
> **errp)
>  fs->vhost_dev.nvqs = 2 + fs->conf.num_request_queues;
>  
>  fs->vhost_dev.vqs = g_new0(struct vhost_virtqueue, fs->vhost_dev.nvqs);
> +
> +vhost_dev_set_config_notifier(&fs->vhost_dev, &fs_ops);

Is this really needed since vhost_user_fs_handle_config_change() ignores
it?


signature.asc
Description: PGP signature

Re: [RFC v4 PATCH 41/49] multi-process/mig: Enable VMSD save in the Proxy object

[Dr. David Alan Gilbert]

* Jag Raman (jag.ra...@oracle.com) wrote:
> 
> 
> On 11/13/2019 12:11 PM, Daniel P. Berrangé wrote:
> > On Wed, Nov 13, 2019 at 11:32:09AM -0500, Jag Raman wrote:
> > > 
> > > 
> > > On 11/13/2019 10:50 AM, Daniel P. Berrangé wrote:
> > > > On Thu, Oct 24, 2019 at 05:09:22AM -0400, Jagannathan Raman wrote:
> > > > > Collect the VMSD from remote process on the source and save
> > > > > it to the channel leading to the destination
> > > > > 
> > > > > Signed-off-by: Elena Ufimtseva 
> > > > > Signed-off-by: John G Johnson 
> > > > > Signed-off-by: Jagannathan Raman 
> > > > > ---
> > > > >New patch in v4
> > > > > 
> > > > >hw/proxy/qemu-proxy.c | 132 
> > > > > ++
> > > > >include/hw/proxy/qemu-proxy.h |   2 +
> > > > >include/io/mpqemu-link.h  |   1 +
> > > > >3 files changed, 135 insertions(+)
> > > > > 
> > > > > diff --git a/hw/proxy/qemu-proxy.c b/hw/proxy/qemu-proxy.c
> > > > > index 623a6c5..ce72e6a 100644
> > > > > --- a/hw/proxy/qemu-proxy.c
> > > > > +++ b/hw/proxy/qemu-proxy.c
> > > > > @@ -52,6 +52,14 @@
> > > > >#include "util/event_notifier-posix.c"
> > > > >#include "hw/boards.h"
> > > > >#include "include/qemu/log.h"
> > > > > +#include "io/channel.h"
> > > > > +#include "migration/qemu-file-types.h"
> > > > > +#include "qapi/error.h"
> > > > > +#include "io/channel-util.h"
> > > > > +#include "migration/qemu-file-channel.h"
> > > > > +#include "migration/qemu-file.h"
> > > > > +#include "migration/migration.h"
> > > > > +#include "migration/vmstate.h"
> > > > >QEMUTimer *hb_timer;
> > > > >static void pci_proxy_dev_realize(PCIDevice *dev, Error **errp);
> > > > > @@ -62,6 +70,9 @@ static void stop_heartbeat_timer(void);
> > > > >static void childsig_handler(int sig, siginfo_t *siginfo, void 
> > > > > *ctx);
> > > > >static void broadcast_msg(MPQemuMsg *msg, bool need_reply);
> > > > > +#define PAGE_SIZE getpagesize()
> > > > > +uint8_t *mig_data;
> > > > > +
> > > > >static void childsig_handler(int sig, siginfo_t *siginfo, void 
> > > > > *ctx)
> > > > >{
> > > > >/* TODO: Add proper handler. */
> > > > > @@ -357,14 +368,135 @@ static void pci_proxy_dev_inst_init(Object 
> > > > > *obj)
> > > > >dev->mem_init = false;
> > > > >}
> > > > > +typedef struct {
> > > > > +QEMUFile *rem;
> > > > > +PCIProxyDev *dev;
> > > > > +} proxy_mig_data;
> > > > > +
> > > > > +static void *proxy_mig_out(void *opaque)
> > > > > +{
> > > > > +proxy_mig_data *data = opaque;
> > > > > +PCIProxyDev *dev = data->dev;
> > > > > +uint8_t byte;
> > > > > +uint64_t data_size = PAGE_SIZE;
> > > > > +
> > > > > +mig_data = g_malloc(data_size);
> > > > > +
> > > > > +while (true) {
> > > > > +byte = qemu_get_byte(data->rem);
> > > > 
> > > > There is a pretty large set of APIs hiding behind the qemu_get_byte
> > > > call, which does not give me confidence that...
> > > > 
> > > > > +mig_data[dev->migsize++] = byte;
> > > > > +if (dev->migsize == data_size) {
> > > > > +data_size += PAGE_SIZE;
> > > > > +mig_data = g_realloc(mig_data, data_size);
> > > > > +}
> > > > > +}
> > > > > +
> > > > > +return NULL;
> > > > > +}
> > > > > +
> > > > > +static int proxy_pre_save(void *opaque)
> > > > > +{
> > > > > +PCIProxyDev *pdev = opaque;
> > > > > +proxy_mig_data *mig_data;
> > > > > +QEMUFile *f_remote;
> > > > > +MPQemuMsg msg = {0};
> > > > > +QemuThread thread;
> > > > > +Error *err = NULL;
> > > > > +QIOChannel *ioc;
> > > > > +uint64_t size;
> > > > > +int fd[2];
> > > > > +
> > > > > +if (socketpair(AF_UNIX, SOCK_STREAM, 0, fd)) {
> > > > > +return -1;
> > > > > +}
> > > > > +
> > > > > +ioc = qio_channel_new_fd(fd[0], &err);
> > > > > +if (err) {
> > > > > +error_report_err(err);
> > > > > +return -1;
> > > > > +}
> > > > > +
> > > > > +qio_channel_set_name(QIO_CHANNEL(ioc), "PCIProxyDevice-mig");
> > > > > +
> > > > > +f_remote = qemu_fopen_channel_input(ioc);
> > > > > +
> > > > > +pdev->migsize = 0;
> > > > > +
> > > > > +mig_data = g_malloc0(sizeof(proxy_mig_data));
> > > > > +mig_data->rem = f_remote;
> > > > > +mig_data->dev = pdev;
> > > > > +
> > > > > +qemu_thread_create(&thread, "Proxy MIG_OUT", proxy_mig_out, 
> > > > > mig_data,
> > > > > +   QEMU_THREAD_DETACHED);
> > > > > +
> > > > > +msg.cmd = START_MIG_OUT;
> > > > > +msg.bytestream = 0;
> > > > > +msg.num_fds = 2;
> > > > > +msg.fds[0] = fd[1];
> > > > > +msg.fds[1] = GET_REMOTE_WAIT;
> > > > > +
> > > > > +mpqemu_msg_send(pdev->mpqemu_link, &msg, pdev->mpqemu_link->com);
> > > > > +size = wait_for_remote(msg.fds[1]);
> > > > > +PUT_REMOTE_WAIT(msg.fds[1]);
> > > > > +
> > > > > +assert(size != ULLONG_MAX);
> > > > > +
> > > > > +/*
> > > > > + * migsize is b

Re: [PATCH 2/4] s390x: Cleanup cpu resets

[Philippe Mathieu-Daudé]

Hi Janosh,

On 11/22/19 8:52 AM, Janosch Frank wrote:

Let's move the resets into one function and switch by type, so we can
use fallthroughs for shared reset actions.

Signed-off-by: Janosch Frank 
---
  target/s390x/cpu.c | 110 -
  1 file changed, 48 insertions(+), 62 deletions(-)

diff --git a/target/s390x/cpu.c b/target/s390x/cpu.c
index 3abe7e80fd..556afecbc1 100644
--- a/target/s390x/cpu.c
+++ b/target/s390x/cpu.c
@@ -82,67 +82,52 @@ static void s390_cpu_load_normal(CPUState *s)
  }
  #endif
  
-/* S390CPUClass::cpu_reset() */

-static void s390_cpu_reset(CPUState *s)
+typedef enum cpu_reset_type {
+S390_CPU_RESET_NORMAL,
+S390_CPU_RESET_INITIAL,
+S390_CPU_RESET_CLEAR,
+} cpu_reset_type;
+
+static void s390_cpu_reset(CPUState *s, cpu_reset_type type)
  {
  S390CPU *cpu = S390_CPU(s);
  S390CPUClass *scc = S390_CPU_GET_CLASS(cpu);
  CPUS390XState *env = &cpu->env;
  
-env->pfault_token = -1UL;

-env->bpbc = false;
  scc->parent_reset(s);
  cpu->env.sigp_order = 0;
  s390_cpu_set_state(S390_CPU_STATE_STOPPED, cpu);
-}
  
-/* S390CPUClass::initial_reset() */

-static void s390_cpu_initial_reset(CPUState *s)
-{
-S390CPU *cpu = S390_CPU(s);
-CPUS390XState *env = &cpu->env;
+/* Set initial values after clearing */
+switch (type) {
+case S390_CPU_RESET_CLEAR:
+memset(env, 0, offsetof(CPUS390XState, start_initial_reset_fields));
+/* Fallthrough */
+case S390_CPU_RESET_INITIAL:
+memset(&env->start_initial_reset_fields, 0,
+   offsetof(CPUS390XState, end_reset_fields) -
+   offsetof(CPUS390XState, start_initial_reset_fields));
+/* architectured initial values for CR 0 and 14 */
+env->cregs[0] = CR0_RESET;
+env->cregs[14] = CR14_RESET;
  
-s390_cpu_reset(s);

-/* initial reset does not clear everything! */
-memset(&env->start_initial_reset_fields, 0,
-offsetof(CPUS390XState, end_reset_fields) -
-offsetof(CPUS390XState, start_initial_reset_fields));
-
-/* architectured initial values for CR 0 and 14 */
-env->cregs[0] = CR0_RESET;
-env->cregs[14] = CR14_RESET;
-
-/* architectured initial value for Breaking-Event-Address register */
-env->gbea = 1;
-
-env->pfault_token = -1UL;
-
-/* tininess for underflow is detected before rounding */
-set_float_detect_tininess(float_tininess_before_rounding,
-  &env->fpu_status);
+/* architectured initial value for Breaking-Event-Address register */
+env->gbea = 1;
+/* tininess for underflow is detected before rounding */
+set_float_detect_tininess(float_tininess_before_rounding,
+  &env->fpu_status);
+/* Fallthrough */
+case S390_CPU_RESET_NORMAL:
+env->pfault_token = -1UL;
+env->bpbc = false;
+break;
+}
  
  /* Reset state inside the kernel that we cannot access yet from QEMU. */

-if (kvm_enabled()) {
-kvm_s390_reset_vcpu(cpu);
+if (kvm_enabled() && (type == S390_CPU_RESET_CLEAR ||
+  type == S390_CPU_RESET_INITIAL)) {
+kvm_s390_reset_vcpu(cpu);
  }
-}
-
-/* CPUClass:reset() */
-static void s390_cpu_full_reset(CPUState *s)
-{
-S390CPU *cpu = S390_CPU(s);
-S390CPUClass *scc = S390_CPU_GET_CLASS(cpu);
-CPUS390XState *env = &cpu->env;
-
-scc->parent_reset(s);
-cpu->env.sigp_order = 0;
-s390_cpu_set_state(S390_CPU_STATE_STOPPED, cpu);
-
-memset(env, 0, offsetof(CPUS390XState, end_reset_fields));
-
-/* architectured initial values for CR 0 and 14 */
-env->cregs[0] = CR0_RESET;
-env->cregs[14] = CR14_RESET;
  
  #if defined(CONFIG_USER_ONLY)

  /* user mode should always be allowed to use the full FPU */
@@ -151,20 +136,21 @@ static void s390_cpu_full_reset(CPUState *s)
  env->cregs[0] |= CR0_VECTOR;
  }
  #endif
+}
  
-/* architectured initial value for Breaking-Event-Address register */

-env->gbea = 1;
+static void s390_cpu_reset_normal(CPUState *s)
+{
+return s390_cpu_reset(s, S390_CPU_RESET_NORMAL);
+}
  
-env->pfault_token = -1UL;

+static void s390_cpu_reset_initial(CPUState *s)
+{
+return s390_cpu_reset(s, S390_CPU_RESET_INITIAL);
+}
  
-/* tininess for underflow is detected before rounding */

-set_float_detect_tininess(float_tininess_before_rounding,
-  &env->fpu_status);
-
-/* Reset state inside the kernel that we cannot access yet from QEMU. */
-if (kvm_enabled()) {
-kvm_s390_reset_vcpu(cpu);
-}
+static void s390_cpu_reset_clear(CPUState *s)
+{
+return s390_cpu_reset(s, S390_CPU_RESET_CLEAR);
  }
  
  #if !defined(CONFIG_USER_ONLY)

@@ -473,9 +459,9 @@ static void s390_cpu_class_init(ObjectClass *oc, void *data)
  #if !defined(CONFIG_USER_ONLY)
  scc->load_normal = s390_cpu_load_normal;
  #endif
-scc

Re: [PATCH v35 01/13] target/avr: Add outward facing interfaces and core CPU logic

[Philippe Mathieu-Daudé]

On 11/21/19 9:55 PM, Aleksandar Markovic wrote:

Why not implement the dump_ASM code? This is very useful...



... and time-consuming to implement, unless Michael have some
ready off-shelf code.

It is great that you have lots of ideas, Philippe, however I think
that it is counterproductive to suggest Michael to work on this
at this moment.


I am just asking why. I later realized Michael and Sarah should be using 
their port via gdbstub, this having the gdb internal disassembler available.



Disassembler is just a debugging tool,
non-essential to core functionality, and Michael should remain
focused on completing core bits and pieces of AVR emulation.

My 2 cents,
Aleksandar

Re: [PATCH v35 01/13] target/avr: Add outward facing interfaces and core CPU logic

[Philippe Mathieu-Daudé]

Hi Michael,

On 11/22/19 9:43 AM, Aleksandar Markovic wrote:
On Friday, November 22, 2019, Richard Henderson 
mailto:richard.hender...@linaro.org>> wrote:


On 11/21/19 8:53 PM, Michael Rolnik wrote:
 > It seems to be a huge investment. this function should parse the
 > binary data as `decode_insn` does, so I suggest to modify decodetree
 > tool to make decoding information available to the instruction print
 > function.
 > what do you think?

See target/openrisc/disas.c, which makes use of decodetree.
It shouldn't be difficult to do something slimiar for avr.


I support Richard's suggested direction. Since you already implemenred 
core AVR decoder using decodetree, and you have this openrisc QEMU 
disassembler example, could you perhaps give a try to what Richard said, 
Michael?


As Aleksandar commented elsewhere in this thread, the port is useful as 
it, and having the disas output is a feature request.


If you have time to look at it before 5.0 development window opens, I'll 
be pleased to review and test it. Anyway I won't object we merge your 
work because this is missing.


Regards,

Phil.

Re: [PATCH 4/4] virtiofsd: Implement blocking posix locks

[Stefan Hajnoczi]

On Fri, Nov 15, 2019 at 03:55:43PM -0500, Vivek Goyal wrote:
> diff --git a/contrib/virtiofsd/fuse_lowlevel.c 
> b/contrib/virtiofsd/fuse_lowlevel.c
> index d4a42d9804..f706e440bf 100644
> --- a/contrib/virtiofsd/fuse_lowlevel.c
> +++ b/contrib/virtiofsd/fuse_lowlevel.c
> @@ -183,7 +183,8 @@ int fuse_send_reply_iov_nofree(fuse_req_t req, int error, 
> struct iovec *iov,
>  {
>   struct fuse_out_header out;
>  
> - if (error <= -1000 || error > 0) {
> + /* error = 1 has been used to signal client to wait for notificaiton */
> + if (error <= -1000 || error > 1) {
>   fuse_log(FUSE_LOG_ERR, "fuse: bad error value: %i\n",   error);
>   error = -ERANGE;
>   }

What is this?

> +int fuse_lowlevel_notify_lock(struct fuse_session *se, uint64_t req_id,
> +   int32_t error)
> +{
> + struct fuse_notify_lock_out outarg;

Missing = {} initialization to avoid information leaks to the guest.

> @@ -1704,6 +1720,15 @@ int fuse_lowlevel_notify_delete(struct fuse_session 
> *se,
>  int fuse_lowlevel_notify_store(struct fuse_session *se, fuse_ino_t ino,
>  off_t offset, struct fuse_bufvec *bufv,
>  enum fuse_buf_copy_flags flags);
> +/**
> + * Notify event related to previous lock request
> + *
> + * @param se the session object
> + * @param req_id the id of the request which requested setlkw

The rest of the code calls this id "unique":

  + * @param req_unique the unique id of the setlkw request

> +/* Pop an element from queue */
> +req = vu_queue_pop(dev, q, sizeof(FVRequest), &bad_in_num, &bad_out_num);
> +if (!req) {
> +/* TODO: Implement some sort of ring buffer and queue notifications
> +  * on that and send these later when notification queue has space
> +  * available.
> +  */
> +return -ENOSPC;

Ah, I thought the point of the notifications processing thread was
exactly this case.  It could wake any threads waiting for buffers.

This wakeup could be implemented with a condvar - no ring buffer
necessary.


signature.asc
Description: PGP signature

Re: [PATCH v35 01/13] target/avr: Add outward facing interfaces and core CPU logic

[Michael Rolnik]

Hi all.

Once implemented, how to invoke this function?

Sent from my cell phone, please ignore typos

On Fri, Nov 22, 2019, 12:46 PM Philippe Mathieu-Daudé 
wrote:

> Hi Michael,
>
> On 11/22/19 9:43 AM, Aleksandar Markovic wrote:
> > On Friday, November 22, 2019, Richard Henderson
> > mailto:richard.hender...@linaro.org>>
> wrote:
> >
> > On 11/21/19 8:53 PM, Michael Rolnik wrote:
> >  > It seems to be a huge investment. this function should parse the
> >  > binary data as `decode_insn` does, so I suggest to modify
> decodetree
> >  > tool to make decoding information available to the instruction
> print
> >  > function.
> >  > what do you think?
> >
> > See target/openrisc/disas.c, which makes use of decodetree.
> > It shouldn't be difficult to do something slimiar for avr.
> >
> >
> > I support Richard's suggested direction. Since you already implemenred
> > core AVR decoder using decodetree, and you have this openrisc QEMU
> > disassembler example, could you perhaps give a try to what Richard said,
> > Michael?
>
> As Aleksandar commented elsewhere in this thread, the port is useful as
> it, and having the disas output is a feature request.
>
> If you have time to look at it before 5.0 development window opens, I'll
> be pleased to review and test it. Anyway I won't object we merge your
> work because this is missing.
>
> Regards,
>
> Phil.
>
>

Re: [PATCH v3] linux-user/strace: Improve output of various syscalls

[Philippe Mathieu-Daudé]

On 11/21/19 8:33 PM, Helge Deller wrote:

Improve strace output of various syscalls which either have none
or only int-type parameters.

Signed-off-by: Helge Deller 

---
Changes in v3:
 fixed alarm()
 added epoll_create(), epoll_create1(), eventfd(), eventfd2()

Changes in v2:
 fixed ioctl()


diff --git a/linux-user/strace.list b/linux-user/strace.list
index 1de4319dcf..d49a1e92a8 100644
--- a/linux-user/strace.list
+++ b/linux-user/strace.list
@@ -26,7 +26,7 @@
  { TARGET_NR_afs_syscall, "afs_syscall" , NULL, NULL, NULL },
  #endif
  #ifdef TARGET_NR_alarm
-{ TARGET_NR_alarm, "alarm" , NULL, NULL, NULL },
+{ TARGET_NR_alarm, "alarm" , "%s(%u)", NULL, NULL },
  #endif
  #ifdef TARGET_NR_aplib
  { TARGET_NR_aplib, "aplib" , NULL, NULL, NULL },
@@ -116,19 +116,19 @@
  { TARGET_NR_dipc, "dipc" , NULL, NULL, NULL },
  #endif
  #ifdef TARGET_NR_dup
-{ TARGET_NR_dup, "dup" , NULL, NULL, NULL },
+{ TARGET_NR_dup, "dup" , "%s(%d)", NULL, NULL },
  #endif
  #ifdef TARGET_NR_dup2
-{ TARGET_NR_dup2, "dup2" , NULL, NULL, NULL },
+{ TARGET_NR_dup2, "dup2" , "%s(%d,%d)", NULL, NULL },
  #endif
  #ifdef TARGET_NR_dup3
-{ TARGET_NR_dup3, "dup3" , NULL, NULL, NULL },
+{ TARGET_NR_dup3, "dup3" , "%s(%d,%d,%d)", NULL, NULL },
  #endif
  #ifdef TARGET_NR_epoll_create
-{ TARGET_NR_epoll_create, "epoll_create" , NULL, NULL, NULL },
+{ TARGET_NR_epoll_create, "%s(%d)", NULL, NULL, NULL },
  #endif
  #ifdef TARGET_NR_epoll_create1
-{ TARGET_NR_epoll_create1, "epoll_create1" , NULL, NULL, NULL },
+{ TARGET_NR_epoll_create1, "%s(%d)", NULL, NULL, NULL },
  #endif
  #ifdef TARGET_NR_epoll_ctl
  { TARGET_NR_epoll_ctl, "epoll_ctl" , NULL, NULL, NULL },
@@ -146,10 +146,10 @@
  { TARGET_NR_epoll_wait_old, "epoll_wait_old" , NULL, NULL, NULL },
  #endif
  #ifdef TARGET_NR_eventfd
-{ TARGET_NR_eventfd, "eventfd" , NULL, NULL, NULL },
+{ TARGET_NR_eventfd, "eventfd", "%s(%d)", NULL, NULL },
  #endif
  #ifdef TARGET_NR_eventfd2
-{ TARGET_NR_eventfd2, "eventfd2" , NULL, NULL, NULL },
+{ TARGET_NR_eventfd2, "eventfd2" , "%s(%d,%d)", NULL, NULL },
  #endif
  #ifdef TARGET_NR_execv
  { TARGET_NR_execv, "execv" , NULL, print_execv, NULL },
@@ -191,7 +191,7 @@
  { TARGET_NR_fanotify_mark, "fanotify_mark" , NULL, NULL, NULL },
  #endif
  #ifdef TARGET_NR_fchdir
-{ TARGET_NR_fchdir, "fchdir" , NULL, NULL, NULL },
+{ TARGET_NR_fchdir, "fchdir" , "%s(%d)", NULL, NULL },
  #endif
  #ifdef TARGET_NR_fchmod
  { TARGET_NR_fchmod, "fchmod" , "%s(%d,%#o)", NULL, NULL },
@@ -287,7 +287,7 @@
  { TARGET_NR_getdtablesize, "getdtablesize" , NULL, NULL, NULL },
  #endif
  #ifdef TARGET_NR_getegid
-{ TARGET_NR_getegid, "getegid" , NULL, NULL, NULL },
+{ TARGET_NR_getegid, "getegid" , "%s()", NULL, NULL },


Oh I didn't realize using this format improves the output by not 
displaying the value of unused registers.

Few other syscalls can be improved this way too.

Good cleanup.
Reviewed-by: Philippe Mathieu-Daudé 


  #endif
  #ifdef TARGET_NR_getegid32
  { TARGET_NR_getegid32, "getegid32" , NULL, NULL, NULL },
@@ -299,7 +299,7 @@
  { TARGET_NR_geteuid32, "geteuid32" , NULL, NULL, NULL },
  #endif
  #ifdef TARGET_NR_getgid
-{ TARGET_NR_getgid, "getgid" , NULL, NULL, NULL },
+{ TARGET_NR_getgid, "getgid" , "%s()", NULL, NULL },
  #endif
  #ifdef TARGET_NR_getgid32
  { TARGET_NR_getgid32, "getgid32" , NULL, NULL, NULL },
@@ -329,10 +329,10 @@
  { TARGET_NR_getpeername, "getpeername" , NULL, NULL, NULL },
  #endif
  #ifdef TARGET_NR_getpgid
-{ TARGET_NR_getpgid, "getpgid" , NULL, NULL, NULL },
+{ TARGET_NR_getpgid, "getpgid" , "%s(%u)", NULL, NULL },
  #endif
  #ifdef TARGET_NR_getpgrp
-{ TARGET_NR_getpgrp, "getpgrp" , NULL, NULL, NULL },
+{ TARGET_NR_getpgrp, "getpgrp" , "%s()", NULL, NULL },
  #endif
  #ifdef TARGET_NR_getpid
  { TARGET_NR_getpid, "getpid" , "%s()", NULL, NULL },
@@ -432,7 +432,7 @@
  { TARGET_NR_io_cancel, "io_cancel" , NULL, NULL, NULL },
  #endif
  #ifdef TARGET_NR_ioctl
-{ TARGET_NR_ioctl, "ioctl" , NULL, NULL, NULL },
+{ TARGET_NR_ioctl, "ioctl" , "%s(%d,%#x,%#x)", NULL, NULL },
  #endif
  #ifdef TARGET_NR_io_destroy
  { TARGET_NR_io_destroy, "io_destroy" , NULL, NULL, NULL },
@@ -1257,22 +1257,22 @@
  { TARGET_NR_setdomainname, "setdomainname" , NULL, NULL, NULL },
  #endif
  #ifdef TARGET_NR_setfsgid
-{ TARGET_NR_setfsgid, "setfsgid" , NULL, NULL, NULL },
+{ TARGET_NR_setfsgid, "setfsgid" , "%s(%u)", NULL, NULL },
  #endif
  #ifdef TARGET_NR_setfsgid32
-{ TARGET_NR_setfsgid32, "setfsgid32" , NULL, NULL, NULL },
+{ TARGET_NR_setfsgid32, "setfsgid32" , "%s(%u)" , NULL, NULL },
  #endif
  #ifdef TARGET_NR_setfsuid
-{ TARGET_NR_setfsuid, "setfsuid" , NULL, NULL, NULL },
+{ TARGET_NR_setfsuid, "setfsuid" , "%s(%u)" , NULL, NULL },
  #endif
  #ifdef TARGET_NR_setfsuid32
  { TARGET_NR_setfsuid32, "setfsuid32" , NULL, NULL, NULL },
  #endif
  #ifdef TARGET_NR_setgid
-{ TARGET_NR_setgid, "setgid" , NULL, NULL, NULL },
+{ TARGET_NR_setgid, "setgid" , "%s(%u)", NULL, NULL },
  #endif
  #ifdef TARGET_NR_setgid32
-{ TARGET_NR_setgid32, "se

Re: [PATCH 1/4] s390x: Don't do a normal reset on the initial cpu

[David Hildenbrand]

On 22.11.19 08:52, Janosch Frank wrote:

The initiating cpu needs to be reset with an initial reset. While
doing a normal reset followed by a initial reset is not wron per-se,
the Ultravisor will only allow the correct reset to be performed.

Signed-off-by: Janosch Frank 
---
  hw/s390x/s390-virtio-ccw.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index d3edeef0ad..c1d1440272 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -348,6 +348,9 @@ static void s390_machine_reset(MachineState *machine)
  break;
  case S390_RESET_LOAD_NORMAL:
  CPU_FOREACH(t) {
+if (t == cs) {
+continue;
+}
  run_on_cpu(t, s390_do_cpu_reset, RUN_ON_CPU_NULL);
  }
  subsystem_reset();



Right, AFAIKS, s390_cpu_initial_reset() does a s390_cpu_reset() right 
no, so nothing should change.


Reviewed-by: David Hildenbrand 

--

Thanks,

David / dhildenb

Re: [PATCH 3/4] s390x: Beautify diag308 handling

[David Hildenbrand]

On 22.11.19 08:52, Janosch Frank wrote:

Let's improve readability by:
* Using constants for the subcodes
* Moving parameter checking into a function
* Removing subcode > 6 check as the default case catches that

Signed-off-by: Janosch Frank 
Reviewed-by: Cornelia Huck 
Reviewed-by: Thomas Huth 
---
  target/s390x/diag.c | 54 +++--
  1 file changed, 32 insertions(+), 22 deletions(-)

diff --git a/target/s390x/diag.c b/target/s390x/diag.c
index 53c2f81f2a..18d33c8492 100644
--- a/target/s390x/diag.c
+++ b/target/s390x/diag.c
@@ -53,6 +53,29 @@ int handle_diag_288(CPUS390XState *env, uint64_t r1, 
uint64_t r3)
  #define DIAG_308_RC_NO_CONF 0x0102
  #define DIAG_308_RC_INVALID 0x0402
  
+#define DIAG308_RESET_MOD_CLR		0

+#define DIAG308_RESET_LOAD_NORM1
+#define DIAG308_LOAD_CLEAR 3
+#define DIAG308_LOAD_NORMAL_DUMP   4
+#define DIAG308_SET5
+#define DIAG308_STORE  6
+
+static int diag308_parm_check(CPUS390XState *env, uint64_t r1, uint64_t addr,
+  uintptr_t ra, bool write)
+{
+if ((r1 & 1) || (addr & ~TARGET_PAGE_MASK)) {
+s390_program_interrupt(env, PGM_SPECIFICATION, ra);
+return -1;
+}
+if (!address_space_access_valid(&address_space_memory, addr,
+sizeof(IplParameterBlock), write,
+MEMTXATTRS_UNSPECIFIED)) {
+s390_program_interrupt(env, PGM_ADDRESSING, ra);
+return -1;
+}
+return 0;
+}
+
  void handle_diag_308(CPUS390XState *env, uint64_t r1, uint64_t r3, uintptr_t 
ra)
  {
  CPUState *cs = env_cpu(env);
@@ -65,30 +88,24 @@ void handle_diag_308(CPUS390XState *env, uint64_t r1, 
uint64_t r3, uintptr_t ra)
  return;
  }
  
-if ((subcode & ~0x0ULL) || (subcode > 6)) {

+if (subcode & ~0x0ULL) {
  s390_program_interrupt(env, PGM_SPECIFICATION, ra);
  return;
  }
  
  switch (subcode) {

-case 0:
+case DIAG308_RESET_MOD_CLR:
  s390_ipl_reset_request(cs, S390_RESET_MODIFIED_CLEAR);
  break;
-case 1:
+case DIAG308_RESET_LOAD_NORM:
  s390_ipl_reset_request(cs, S390_RESET_LOAD_NORMAL);
  break;
-case 3:
+case DIAG308_LOAD_CLEAR:
+/* Well we still lack the clearing bit... */
  s390_ipl_reset_request(cs, S390_RESET_REIPL);
  break;
-case 5:
-if ((r1 & 1) || (addr & 0x0fffULL)) {
-s390_program_interrupt(env, PGM_SPECIFICATION, ra);
-return;
-}
-if (!address_space_access_valid(&address_space_memory, addr,
-sizeof(IplParameterBlock), false,
-MEMTXATTRS_UNSPECIFIED)) {
-s390_program_interrupt(env, PGM_ADDRESSING, ra);
+case DIAG308_SET:
+if (diag308_parm_check(env, r1, addr, ra, false)) {
  return;
  }
  iplb = g_new0(IplParameterBlock, 1);
@@ -110,15 +127,8 @@ void handle_diag_308(CPUS390XState *env, uint64_t r1, 
uint64_t r3, uintptr_t ra)
  out:
  g_free(iplb);
  return;
-case 6:
-if ((r1 & 1) || (addr & 0x0fffULL)) {
-s390_program_interrupt(env, PGM_SPECIFICATION, ra);
-return;
-}
-if (!address_space_access_valid(&address_space_memory, addr,
-sizeof(IplParameterBlock), true,
-MEMTXATTRS_UNSPECIFIED)) {
-s390_program_interrupt(env, PGM_ADDRESSING, ra);
+case DIAG308_STORE:
+if (diag308_parm_check(env, r1, addr, ra, true)) {
  return;
  }
  iplb = s390_ipl_get_iplb();



Reviewed-by: David Hildenbrand 

--

Thanks,

David / dhildenb

Re: [PATCH 4/4] s390x: Beautify machine reset

[David Hildenbrand]

On 22.11.19 08:52, Janosch Frank wrote:

* Add comments that tell you which diag308 subcode caused the reset
* Sort by diag308 reset subcode

Signed-off-by: Janosch Frank 
---
  hw/s390x/s390-virtio-ccw.c | 20 ++--
  1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index c1d1440272..88f7758721 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -330,15 +330,7 @@ static void s390_machine_reset(MachineState *machine)
  s390_cmma_reset();
  
  switch (reset_type) {

-case S390_RESET_EXTERNAL:
-case S390_RESET_REIPL:
-qemu_devices_reset();
-s390_crypto_reset();
-
-/* configure and start the ipl CPU only */
-run_on_cpu(cs, s390_do_cpu_ipl, RUN_ON_CPU_NULL);
-break;
-case S390_RESET_MODIFIED_CLEAR:
+case S390_RESET_MODIFIED_CLEAR: /* Subcode 0 */


IMHO "Subcode X" isn't of much help here. We're out of diag handling.

I'd suggest to just document the subcodes along with the definitions, if 
really needed, and drop this patch, at least I don't quite see the value 
of moving code around here... or is the code shuffling of any value on 
your prot virt patches?


--

Thanks,

David / dhildenb

Re: [PATCH v35 01/13] target/avr: Add outward facing interfaces and core CPU logic

[Aleksandar Markovic]

On Friday, November 22, 2019, Philippe Mathieu-Daudé 
wrote:

> On 11/21/19 9:55 PM, Aleksandar Markovic wrote:
>
>> Why not implement the dump_ASM code? This is very useful...
>>>
>>>
>> ... and time-consuming to implement, unless Michael have some
>> ready off-shelf code.
>>
>> It is great that you have lots of ideas, Philippe, however I think
>> that it is counterproductive to suggest Michael to work on this
>> at this moment.
>>
>
> I am just asking why. I later realized Michael and Sarah should be using
> their port via gdbstub, this having the gdb internal disassembler available.
>
>
Sure, perhaps I misread your 'why' sentence.

Keep your ideas coming! I don't mean to restrict your style and creativity,
I encourage you keeping and growing them. :)



> Disassembler is just a debugging tool,
>> non-essential to core functionality, and Michael should remain
>> focused on completing core bits and pieces of AVR emulation.
>>
>> My 2 cents,
>> Aleksandar
>>
>
>

Re: [PATCH v4 31/37] smbus-eeprom: remove PROP_PTR

[Philippe Mathieu-Daudé]

On 11/20/19 4:24 PM, Marc-André Lureau wrote:

Instead, set the initial data field directly.

(the initial data is an array of 256 bytes. As I don't know if it may
change over time, I keep the pointer to original buffer as is, but it
might be worth to consider to copy it instead)

Signed-off-by: Marc-André Lureau 
---
  hw/i2c/smbus_eeprom.c | 17 -
  1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/hw/i2c/smbus_eeprom.c b/hw/i2c/smbus_eeprom.c
index 54c86a0112..533c728b3b 100644
--- a/hw/i2c/smbus_eeprom.c
+++ b/hw/i2c/smbus_eeprom.c
@@ -44,7 +44,7 @@
  typedef struct SMBusEEPROMDevice {
  SMBusDevice smbusdev;
  uint8_t data[SMBUS_EEPROM_SIZE];
-void *init_data;
+uint8_t *init_data;
  uint8_t offset;
  bool accessed;
  } SMBusEEPROMDevice;
@@ -129,14 +129,14 @@ static void smbus_eeprom_reset(DeviceState *dev)
  
  static void smbus_eeprom_realize(DeviceState *dev, Error **errp)

  {
+SMBusEEPROMDevice *eeprom = SMBUS_EEPROM(dev);
+
  smbus_eeprom_reset(dev);
+if (eeprom->init_data == NULL) {
+error_setg(errp, "init_data cannot be NULL");
+}
  }
  
-static Property smbus_eeprom_properties[] = {

-DEFINE_PROP_PTR("data", SMBusEEPROMDevice, init_data),
-DEFINE_PROP_END_OF_LIST(),
-};
-
  static void smbus_eeprom_class_initfn(ObjectClass *klass, void *data)
  {
  DeviceClass *dc = DEVICE_CLASS(klass);
@@ -146,9 +146,8 @@ static void smbus_eeprom_class_initfn(ObjectClass *klass, 
void *data)
  dc->reset = smbus_eeprom_reset;
  sc->receive_byte = eeprom_receive_byte;
  sc->write_data = eeprom_write_data;
-dc->props = smbus_eeprom_properties;
  dc->vmsd = &vmstate_smbus_eeprom;
-/* Reason: pointer property "data" */
+/* Reason: init_data */
  dc->user_creatable = false;
  }
  
@@ -172,7 +171,7 @@ void smbus_eeprom_init_one(I2CBus *smbus, uint8_t address, uint8_t *eeprom_buf)
  
  dev = qdev_create((BusState *) smbus, TYPE_SMBUS_EEPROM);

  qdev_prop_set_uint8(dev, "address", address);
-qdev_prop_set_ptr(dev, "data", eeprom_buf);
+SMBUS_EEPROM(dev)->init_data = eeprom_buf;


Isn't this a QOM anti-pattern?


  qdev_init_nofail(dev);
  }
  

Re: [PATCH v4 31/37] smbus-eeprom: remove PROP_PTR

[Marc-André Lureau]

On Fri, Nov 22, 2019 at 3:07 PM Philippe Mathieu-Daudé
 wrote:
>
> On 11/20/19 4:24 PM, Marc-André Lureau wrote:
> > Instead, set the initial data field directly.
> >
> > (the initial data is an array of 256 bytes. As I don't know if it may
> > change over time, I keep the pointer to original buffer as is, but it
> > might be worth to consider to copy it instead)
> >
> > Signed-off-by: Marc-André Lureau 
> > ---
> >   hw/i2c/smbus_eeprom.c | 17 -
> >   1 file changed, 8 insertions(+), 9 deletions(-)
> >
> > diff --git a/hw/i2c/smbus_eeprom.c b/hw/i2c/smbus_eeprom.c
> > index 54c86a0112..533c728b3b 100644
> > --- a/hw/i2c/smbus_eeprom.c
> > +++ b/hw/i2c/smbus_eeprom.c
> > @@ -44,7 +44,7 @@
> >   typedef struct SMBusEEPROMDevice {
> >   SMBusDevice smbusdev;
> >   uint8_t data[SMBUS_EEPROM_SIZE];
> > -void *init_data;
> > +uint8_t *init_data;
> >   uint8_t offset;
> >   bool accessed;
> >   } SMBusEEPROMDevice;
> > @@ -129,14 +129,14 @@ static void smbus_eeprom_reset(DeviceState *dev)
> >
> >   static void smbus_eeprom_realize(DeviceState *dev, Error **errp)
> >   {
> > +SMBusEEPROMDevice *eeprom = SMBUS_EEPROM(dev);
> > +
> >   smbus_eeprom_reset(dev);
> > +if (eeprom->init_data == NULL) {
> > +error_setg(errp, "init_data cannot be NULL");
> > +}
> >   }
> >
> > -static Property smbus_eeprom_properties[] = {
> > -DEFINE_PROP_PTR("data", SMBusEEPROMDevice, init_data),
> > -DEFINE_PROP_END_OF_LIST(),
> > -};
> > -
> >   static void smbus_eeprom_class_initfn(ObjectClass *klass, void *data)
> >   {
> >   DeviceClass *dc = DEVICE_CLASS(klass);
> > @@ -146,9 +146,8 @@ static void smbus_eeprom_class_initfn(ObjectClass 
> > *klass, void *data)
> >   dc->reset = smbus_eeprom_reset;
> >   sc->receive_byte = eeprom_receive_byte;
> >   sc->write_data = eeprom_write_data;
> > -dc->props = smbus_eeprom_properties;
> >   dc->vmsd = &vmstate_smbus_eeprom;
> > -/* Reason: pointer property "data" */
> > +/* Reason: init_data */
> >   dc->user_creatable = false;
> >   }
> >
> > @@ -172,7 +171,7 @@ void smbus_eeprom_init_one(I2CBus *smbus, uint8_t 
> > address, uint8_t *eeprom_buf)
> >
> >   dev = qdev_create((BusState *) smbus, TYPE_SMBUS_EEPROM);
> >   qdev_prop_set_uint8(dev, "address", address);
> > -qdev_prop_set_ptr(dev, "data", eeprom_buf);
> > +SMBUS_EEPROM(dev)->init_data = eeprom_buf;
>
> Isn't this a QOM anti-pattern?

Sort of, but using prop_ptr in the first place is an anti-pattern. So
I am not improving the situation much here, but just getting rid of
prop_ptr usage.

Using an array of bytes instead could be done in a follow-up patch. I
can leave a fixme if that helps.

>
> >   qdev_init_nofail(dev);
> >   }
> >
> >
>

Re: [PATCH v35 01/13] target/avr: Add outward facing interfaces and core CPU logic

[Philippe Mathieu-Daudé]

On 11/22/19 11:54 AM, Michael Rolnik wrote:

Hi all.

Once implemented, how to invoke this function?


I'm testing your series with:

qemu-system-avr -kernel ~/Downloads/ATmegaBOOT.elf -d in_asm,unimp

The '-d in_asm' enable dumping the assembler instructions translated.


Sent from my cell phone, please ignore typos

On Fri, Nov 22, 2019, 12:46 PM Philippe Mathieu-Daudé > wrote:


Hi Michael,

On 11/22/19 9:43 AM, Aleksandar Markovic wrote:
 > On Friday, November 22, 2019, Richard Henderson
 > mailto:richard.hender...@linaro.org>
>> wrote:
 >
 >     On 11/21/19 8:53 PM, Michael Rolnik wrote:
 >      > It seems to be a huge investment. this function should
parse the
 >      > binary data as `decode_insn` does, so I suggest to modify
decodetree
 >      > tool to make decoding information available to the
instruction print
 >      > function.
 >      > what do you think?
 >
 >     See target/openrisc/disas.c, which makes use of decodetree.
 >     It shouldn't be difficult to do something slimiar for avr.
 >
 >
 > I support Richard's suggested direction. Since you already
implemenred
 > core AVR decoder using decodetree, and you have this openrisc QEMU
 > disassembler example, could you perhaps give a try to what
Richard said,
 > Michael?

As Aleksandar commented elsewhere in this thread, the port is useful as
it, and having the disas output is a feature request.

If you have time to look at it before 5.0 development window opens,
I'll
be pleased to review and test it. Anyway I won't object we merge your
work because this is missing.

Regards,

Phil.

Re: [PATCH 2/4] s390x: Cleanup cpu resets

[David Hildenbrand]

[...]

  
  #if !defined(CONFIG_USER_ONLY)

@@ -473,9 +459,9 @@ static void s390_cpu_class_init(ObjectClass *oc, void *data)
  #if !defined(CONFIG_USER_ONLY)
  scc->load_normal = s390_cpu_load_normal;
  #endif
-scc->cpu_reset = s390_cpu_reset;
-scc->initial_cpu_reset = s390_cpu_initial_reset;
-cc->reset = s390_cpu_full_reset;
+scc->cpu_reset = s390_cpu_reset_normal;
+scc->initial_cpu_reset = s390_cpu_reset_initial;


What about having only one function here

scc->cpu_reset(), where you directly pass in the reset type

instead of scc->cpu_reset/scc->initial_cpu_reset?


+cc->reset = s390_cpu_reset_clear;
  cc->class_by_name = s390_cpu_class_by_name,
  cc->has_work = s390_cpu_has_work;
  #ifdef CONFIG_TCG




--

Thanks,

David / dhildenb

Re: [PATCH v4 31/37] smbus-eeprom: remove PROP_PTR

[Philippe Mathieu-Daudé]

On 11/22/19 12:12 PM, Marc-André Lureau wrote:

On Fri, Nov 22, 2019 at 3:07 PM Philippe Mathieu-Daudé
 wrote:


On 11/20/19 4:24 PM, Marc-André Lureau wrote:

Instead, set the initial data field directly.

(the initial data is an array of 256 bytes. As I don't know if it may
change over time, I keep the pointer to original buffer as is, but it
might be worth to consider to copy it instead)

Signed-off-by: Marc-André Lureau 
---
   hw/i2c/smbus_eeprom.c | 17 -
   1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/hw/i2c/smbus_eeprom.c b/hw/i2c/smbus_eeprom.c
index 54c86a0112..533c728b3b 100644
--- a/hw/i2c/smbus_eeprom.c
+++ b/hw/i2c/smbus_eeprom.c
@@ -44,7 +44,7 @@
   typedef struct SMBusEEPROMDevice {
   SMBusDevice smbusdev;
   uint8_t data[SMBUS_EEPROM_SIZE];
-void *init_data;
+uint8_t *init_data;
   uint8_t offset;
   bool accessed;
   } SMBusEEPROMDevice;
@@ -129,14 +129,14 @@ static void smbus_eeprom_reset(DeviceState *dev)

   static void smbus_eeprom_realize(DeviceState *dev, Error **errp)
   {
+SMBusEEPROMDevice *eeprom = SMBUS_EEPROM(dev);
+
   smbus_eeprom_reset(dev);
+if (eeprom->init_data == NULL) {
+error_setg(errp, "init_data cannot be NULL");
+}
   }

-static Property smbus_eeprom_properties[] = {
-DEFINE_PROP_PTR("data", SMBusEEPROMDevice, init_data),
-DEFINE_PROP_END_OF_LIST(),
-};
-
   static void smbus_eeprom_class_initfn(ObjectClass *klass, void *data)
   {
   DeviceClass *dc = DEVICE_CLASS(klass);
@@ -146,9 +146,8 @@ static void smbus_eeprom_class_initfn(ObjectClass *klass, 
void *data)
   dc->reset = smbus_eeprom_reset;
   sc->receive_byte = eeprom_receive_byte;
   sc->write_data = eeprom_write_data;
-dc->props = smbus_eeprom_properties;
   dc->vmsd = &vmstate_smbus_eeprom;
-/* Reason: pointer property "data" */
+/* Reason: init_data */
   dc->user_creatable = false;
   }

@@ -172,7 +171,7 @@ void smbus_eeprom_init_one(I2CBus *smbus, uint8_t address, 
uint8_t *eeprom_buf)

   dev = qdev_create((BusState *) smbus, TYPE_SMBUS_EEPROM);
   qdev_prop_set_uint8(dev, "address", address);
-qdev_prop_set_ptr(dev, "data", eeprom_buf);
+SMBUS_EEPROM(dev)->init_data = eeprom_buf;


Isn't this a QOM anti-pattern?


Sort of, but using prop_ptr in the first place is an anti-pattern. So
I am not improving the situation much here, but just getting rid of
prop_ptr usage.


Alright.


Using an array of bytes instead could be done in a follow-up patch. I
can leave a fixme if that helps.


IIRC there was a discussion earlier this year about using block backend 
for this device.





   qdev_init_nofail(dev);
   }

[PATCH v1 2/3] tests/vm/ubuntu: include language pack to silence locale warnings

[Alex Bennée]

The iotests in particular don't like the output being spammed with
warnings about locales.

Signed-off-by: Alex Bennée 
---
 tests/vm/ubuntu.i386 | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/vm/ubuntu.i386 b/tests/vm/ubuntu.i386
index 38f740eabf7..18b1ea2b72c 100755
--- a/tests/vm/ubuntu.i386
+++ b/tests/vm/ubuntu.i386
@@ -84,7 +84,7 @@ class UbuntuX86VM(basevm.BaseVM):
 self.ssh_root_check("sed -ie s/^#\ deb-src/deb-src/g 
/etc/apt/sources.list")
 self.ssh_root_check("apt-get update")
 self.ssh_root_check("apt-get build-dep -y qemu")
-self.ssh_root_check("apt-get install -y libfdt-dev flex bison")
+self.ssh_root_check("apt-get install -y libfdt-dev flex bison 
language-pack-en")
 self.ssh_root("poweroff")
 self.wait()
 os.rename(img_tmp, img)
-- 
2.20.1

[PATCH for 4.2 v1 0/3] some tests/vm fixes

[Alex Bennée]

Hi,

These fixes are aimed at improving the "vm-build-all" make target. The
first two are fairly non contriversal tweaks to the base
configuration. The final one just elides over the fact that the tests
are broken on 32bit 16.04 - but I think it may be a distro problem as
I've failed to replicate on my other 32 bit OSes. If anyone else wants
to figure out whats going on then be my guest ;-)

Alex Bennée (3):
  tests/vm/centos: fix centos build target
  tests/vm/ubuntu: include language pack to silence locale warnings
  tests/vm/ubuntu: update i386 image to 18.04

 tests/vm/centos  | 2 +-
 tests/vm/ubuntu.i386 | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

-- 
2.20.1

[PATCH v1 3/3] tests/vm/ubuntu: update i386 image to 18.04

[Alex Bennée]

The current image is broken while running qtests but the bug go away
when built with a newer Ubuntu i386 image. I was unable to replicate
the crash on Debian Buster for i386 either so I'm concluding it is a
distro problem. Let's paper over that crack by updating our 32 bir
test image.

Signed-off-by: Alex Bennée 
---
 tests/vm/ubuntu.i386 | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/vm/ubuntu.i386 b/tests/vm/ubuntu.i386
index 18b1ea2b72c..f611bebdc9d 100755
--- a/tests/vm/ubuntu.i386
+++ b/tests/vm/ubuntu.i386
@@ -66,8 +66,8 @@ class UbuntuX86VM(basevm.BaseVM):
 
 def build_image(self, img):
 cimg = self._download_with_cache(
-
"https://cloud-images.ubuntu.com/releases/16.04/release-20190605/ubuntu-16.04-server-cloudimg-i386-disk1.img";,
-
sha256sum="e30091144c73483822b7c27193e9d47346dd1064229da577c3fedcf943f7cfcc")
+
"https://cloud-images.ubuntu.com/releases/bionic/release-20191114/ubuntu-18.04-server-cloudimg-i386.img";,
+
sha256sum="28969840626d1ea80bb249c08eef1a4533e8904aa51a327b40f37ac4b4ff04ef")
 img_tmp = img + ".tmp"
 subprocess.check_call(["cp", "-f", cimg, img_tmp])
 subprocess.check_call(["qemu-img", "resize", img_tmp, "50G"])
-- 
2.20.1

[PATCH v1 1/3] tests/vm/centos: fix centos build target

[Alex Bennée]

To be able to run the docker tests centos has here we have to install
python3 as well as the basic tools.

Signed-off-by: Alex Bennée 
Reviewed-by: Wainer dos Santos Moschetta 
Reviewed-by: Philippe Mathieu-Daudé 
---
 tests/vm/centos | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/vm/centos b/tests/vm/centos
index 53976f1c4c9..b9e851f2d33 100755
--- a/tests/vm/centos
+++ b/tests/vm/centos
@@ -73,7 +73,7 @@ class CentosVM(basevm.BaseVM):
 self.wait_ssh()
 self.ssh_root_check("touch /etc/cloud/cloud-init.disabled")
 self.ssh_root_check("yum update -y")
-self.ssh_root_check("yum install -y docker make git")
+self.ssh_root_check("yum install -y docker make git python3")
 self.ssh_root_check("systemctl enable docker")
 self.ssh_root("poweroff")
 self.wait()
-- 
2.20.1

[PATCH] virtiofsd: fix libfuse information leaks

[Stefan Hajnoczi]

Some FUSE message replies contain padding fields that are not
initialized by libfuse.  This is fine in traditional FUSE applications
because the kernel is trusted.  virtiofsd does not trust the guest and
must not expose uninitialized memory.

Use C struct initializers to automatically zero out memory.  Not all of
these code changes are strictly necessary but they will prevent future
information leaks if the structs are extended.

Signed-off-by: Stefan Hajnoczi 
---
 contrib/virtiofsd/fuse_lowlevel.c | 150 +++---
 1 file changed, 76 insertions(+), 74 deletions(-)

diff --git a/contrib/virtiofsd/fuse_lowlevel.c 
b/contrib/virtiofsd/fuse_lowlevel.c
index 7fa8861f5d..8a4234630d 100644
--- a/contrib/virtiofsd/fuse_lowlevel.c
+++ b/contrib/virtiofsd/fuse_lowlevel.c
@@ -45,21 +45,23 @@ static __attribute__((constructor)) void 
fuse_ll_init_pagesize(void)
 
 static void convert_stat(const struct stat *stbuf, struct fuse_attr *attr)
 {
-   attr->ino   = stbuf->st_ino;
-   attr->mode  = stbuf->st_mode;
-   attr->nlink = stbuf->st_nlink;
-   attr->uid   = stbuf->st_uid;
-   attr->gid   = stbuf->st_gid;
-   attr->rdev  = stbuf->st_rdev;
-   attr->size  = stbuf->st_size;
-   attr->blksize   = stbuf->st_blksize;
-   attr->blocks= stbuf->st_blocks;
-   attr->atime = stbuf->st_atime;
-   attr->mtime = stbuf->st_mtime;
-   attr->ctime = stbuf->st_ctime;
-   attr->atimensec = ST_ATIM_NSEC(stbuf);
-   attr->mtimensec = ST_MTIM_NSEC(stbuf);
-   attr->ctimensec = ST_CTIM_NSEC(stbuf);
+   *attr = (struct fuse_attr) {
+   .ino= stbuf->st_ino,
+   .mode   = stbuf->st_mode,
+   .nlink  = stbuf->st_nlink,
+   .uid= stbuf->st_uid,
+   .gid= stbuf->st_gid,
+   .rdev   = stbuf->st_rdev,
+   .size   = stbuf->st_size,
+   .blksize= stbuf->st_blksize,
+   .blocks = stbuf->st_blocks,
+   .atime  = stbuf->st_atime,
+   .mtime  = stbuf->st_mtime,
+   .ctime  = stbuf->st_ctime,
+   .atimensec  = ST_ATIM_NSEC(stbuf),
+   .mtimensec  = ST_MTIM_NSEC(stbuf),
+   .ctimensec  = ST_CTIM_NSEC(stbuf),
+   };
 }
 
 static void convert_attr(const struct fuse_setattr_in *attr, struct stat 
*stbuf)
@@ -181,16 +183,16 @@ static int fuse_send_msg(struct fuse_session *se, struct 
fuse_chan *ch,
 int fuse_send_reply_iov_nofree(fuse_req_t req, int error, struct iovec *iov,
   int count)
 {
-   struct fuse_out_header out;
+   struct fuse_out_header out = {
+   .unique = req->unique,
+   .error = error,
+   };
 
if (error <= -1000 || error > 0) {
fuse_log(FUSE_LOG_ERR, "fuse: bad error value: %i\n",   error);
error = -ERANGE;
}
 
-   out.unique = req->unique;
-   out.error = error;
-
iov[0].iov_base = &out;
iov[0].iov_len = sizeof(struct fuse_out_header);
 
@@ -271,14 +273,16 @@ size_t fuse_add_direntry(fuse_req_t req, char *buf, 
size_t bufsize,
 static void convert_statfs(const struct statvfs *stbuf,
   struct fuse_kstatfs *kstatfs)
 {
-   kstatfs->bsize   = stbuf->f_bsize;
-   kstatfs->frsize  = stbuf->f_frsize;
-   kstatfs->blocks  = stbuf->f_blocks;
-   kstatfs->bfree   = stbuf->f_bfree;
-   kstatfs->bavail  = stbuf->f_bavail;
-   kstatfs->files   = stbuf->f_files;
-   kstatfs->ffree   = stbuf->f_ffree;
-   kstatfs->namelen = stbuf->f_namemax;
+   *kstatfs = (struct fuse_kstatfs) {
+   .bsize   = stbuf->f_bsize,
+   .frsize  = stbuf->f_frsize,
+   .blocks  = stbuf->f_blocks,
+   .bfree   = stbuf->f_bfree,
+   .bavail  = stbuf->f_bavail,
+   .files   = stbuf->f_files,
+   .ffree   = stbuf->f_ffree,
+   .namelen = stbuf->f_namemax,
+   };
 }
 
 static int send_reply_ok(fuse_req_t req, const void *arg, size_t argsize)
@@ -320,12 +324,14 @@ static unsigned int calc_timeout_nsec(double t)
 static void fill_entry(struct fuse_entry_out *arg,
   const struct fuse_entry_param *e)
 {
-   arg->nodeid = e->ino;
-   arg->generation = e->generation;
-   arg->entry_valid = calc_timeout_sec(e->entry_timeout);
-   arg->entry_valid_nsec = calc_timeout_nsec(e->entry_timeout);
-   arg->attr_valid = calc_timeout_sec(e->attr_timeout);
-   arg->attr_valid_nsec = calc_timeout_nsec(e->attr_timeout);
+   *arg = (struct fuse_entry_out) {
+   .nodeid = e->ino,
+   .generation = e->generation,
+   .entry_valid = calc_timeout_sec(e->entry_timeout),
+   .entry_valid_nsec = c

Re: [Qemu-devel] [libvirt] [PATCH 2/2] qapi: deprecate implicit filters

[Christophe de Dinechin]

> On 22 Nov 2019, at 09:41, Markus Armbruster  wrote:
> 
> Reviving this old thread, because I'd like to connect it to more recent
> discussions.
> 
> Christophe de Dinechin mailto:dinec...@redhat.com>> 
> writes:
> 
>> Markus Armbruster writes:
>> 
>>> Peter Krempa  writes:
>>> 
>> [...]
 From my experience users report non-fatal messages mostly only if it is
 spamming the system log. One of instances are very unlikely to be
 noticed.
 
 In my experience it's better to notify us in libvirt of such change and
 we will try our best to fix it.
>>> 
>>> How to best alert the layers above QEMU was one of the topic of the KVM
>>> Forum 2018 BoF on deprecating stuff.  Minutes:
>>> 
>>>Message-ID: <87mur0ls8o@dusky.pond.sub.org>
>>>https://lists.nongnu.org/archive/html/qemu-devel/2018-10/msg05828.html
>>> 
>>> Relevant part:
>>> 
>>> * We need to communicate "you're using something that is deprecated".
>>>  How?  Right now, we print a deprecation message.  Okay when humans use
>>>  QEMU directly in a shell.  However, when QEMU sits at the bottom of a
>>>  software stack, the message will likely end up in a log file that is
>>>  effectively write-only.
>>> 
>>>  - The one way to get people read log files is crashing their
>>>application.  A command line option --future could make QEMU crash
>>>right after printing a deprecation message.  This could help with
>>>finding use of deprecated features in a testing environment.
>>> 
>>>  - A less destructive way to grab people's attention is to make things
>>>run really, really slow: have QEMU go to sleep for a while after
>>>printing a deprecation message.
>>> 
>>>  - We can also pass the buck to the next layer up: emit a QMP event.
>>> 
>>>Sadly, by the time the next layer connects to QMP, plenty of stuff
>>>already happened.  We'd have to buffer deprecation events somehow.
>>> 
>>>What would libvirt do with such an event?  Log it, taint the domain,
>>>emit a (libvirt) event to pass it on to the next layer up.
>>> 
>>>  - A completely different idea is to have a configuratin linter.  To
>>>support doing this at the libvirt level, QEMU could expose "is
>>>deprecated" in interface introspection.  Feels feasible for QMP,
>>>where we already have sufficiently expressive introspection.  For
>>>CLI, we'd first have to provide that (but we want that anyway).
>>> 
>>>  - We might also want to dispay deprecation messages in QEMU's GUI
>>>somehow, or on serial consoles.
>> 
>> Sorry for catching up late, this mail thread happened during my PTO.
>> 
>> I remember bringing up at the time [1] that the correct solution needs
>> to take into account usage models that vary from
>> 
>> - a workstation case, where displaying an error box is easy and
>>  convenient,
>> 
>> - to local headless VMs where system-level notification would do the job
>>  better, allowing us to leverage things like system-wide email notifications
>> 
>> - to large-scale collections of VMs managed by some layered product,
>>  where the correct reporting would be through something like Insights,
>>  i.e. you don't scan individual logs, you want something like "913 VMs
>>  are using deprecated X"
>> 
>> To me, that implies that we need to have a clear division of roles, with
>> a standard way to
>> 
>> a) produce the errors,
>> b) propagate them,
>> c) consume them (at least up to libvirt)
>> 
>> Notice that this work has already been done for "real" errors,
>> i.e. there is a real QAPI notion of "errors". AFAICT, warn_report does
>> not connect to it, though, it goes through error_vprintf which is really
>> just basic logging.
>> 
>> So would it make sense to:
>> 
>> 1. Add a deprecation_report() alongside warn_report()?
> 
> "Grepability" alone would make that worthwhile, I think.
> 
>> 2. Connect warn_report() and all the error_vprintf output to QAPI,
>>   e.g. using John's suggestion of adding the messages using some
>>   "warning" or "deprecated" tag?
> 
> This is the difficult part.  See my "Exposing feature deprecation to
> machine clients (was: [Qemu-devel] [PATCH 2/2] qapi: deprecate implicit
> filters)" in this thread.  Quote:
> 
>Propagating errors is painful.  It has caused massive churn all over the
>place.
> 
>I don't think we can hitch deprecation info to the existing error
>propagation, since we need to take the success path back to the QMP
>core, not an error path.
> 
>Propagating a second object for warnings... thanks, but no thanks.
> 
>The QMP core could provide a function for recording deprecation info for
>the currently executing QMP command.  This is how we used to record
>errors in QMP commands, until Anthony rammed through what we have now.
>The commit messages (e.g. d5ec4f27c38) provide no justification.  I
>dimly recall adamant (oral?) claims that recording errors in the Monitor
>object cannot work for us.
> 
>I smell a swamp.

This looks swamp

Re: [PATCH v0 1/2] qdev-properties-system: extend set_pionter for unrealized devices

[Denis Plotnikov]

On 18.11.2019 21:54, Eduardo Habkost wrote:
> On Sun, Nov 10, 2019 at 10:03:09PM +0300, Denis Plotnikov wrote:
>> Some device's property can be changed if the device has been already
>> realized. For example, it could be "drive" property of a scsi disk device.
>>
>> So far, set_pointer could operate only on a relized device. The patch
>> extends its interface for operation on an unrealized device.
>>
>> Signed-off-by: Denis Plotnikov 
>> ---
>>   hw/core/qdev-properties-system.c | 32 +---
>>   1 file changed, 21 insertions(+), 11 deletions(-)
>>
>> diff --git a/hw/core/qdev-properties-system.c 
>> b/hw/core/qdev-properties-system.c
>> index ba412dd2ca..c534590dcd 100644
>> --- a/hw/core/qdev-properties-system.c
>> +++ b/hw/core/qdev-properties-system.c
>> @@ -38,9 +38,14 @@ static void get_pointer(Object *obj, Visitor *v, Property 
>> *prop,
>>   }
>>   
>>   static void set_pointer(Object *obj, Visitor *v, Property *prop,
>> -void (*parse)(DeviceState *dev, const char *str,
>> -  void **ptr, const char *propname,
>> -  Error **errp),
>> +void (*parse_realized)(DeviceState *dev,
>> +   const char *str, void **ptr,
>> +   const char *propname,
>> +   Error **errp),
>> +void (*parse_unrealized)(DeviceState *dev,
>> + const char *str, void 
>> **ptr,
>> + const char *propname,
>> + Error **errp),
>>   const char *name, Error **errp)
> Wouldn't it be simpler to just add a PropertyInfo::allow_set_after_realize
> bool field, and call the same setter function?  Then you can
> simply change do_parse_drive() to check if realized is true.
May be, but I thought It would be more clear to have a separate callback 
for all the devices supporting the property setting when realized.
Also the "drive" property setting on realized and non-realized device a 
little bit different: in the realized case the setter function expects 
to get
BlockDriverState only, when in the unrealized case the setter can accept 
both BlockBackend and BlockDriverState. Also, in the unrealized case the 
setter function doesn't expect to have a device with an empty BlockBackend.
I decided that extending do_parse_drive would make it more complex for 
understanding. That's why I made two separate functions for both cases.

I'd like to mention that I have a few concerns about 
do_parse_drive_realized (please see the next patch from the series) and 
I'd like them to be reviewed as well. After that, may be it would be 
better to go the way you suggested.

Thanks for reviewing!
Denis

>
>>   {
>>   DeviceState *dev = DEVICE(obj);
>> @@ -48,11 +53,6 @@ static void set_pointer(Object *obj, Visitor *v, Property 
>> *prop,
>>   void **ptr = qdev_get_prop_ptr(dev, prop);
>>   char *str;
>>   
>> -if (dev->realized) {
>> -qdev_prop_set_after_realize(dev, name, errp);
>> -return;
>> -}
>> -
>>   visit_type_str(v, name, &str, &local_err);
>>   if (local_err) {
>>   error_propagate(errp, local_err);
>> @@ -63,7 +63,17 @@ static void set_pointer(Object *obj, Visitor *v, Property 
>> *prop,
>>   *ptr = NULL;
>>   return;
>>   }
>> -parse(dev, str, ptr, prop->name, errp);
>> +
>> +if (dev->realized) {
>> +if (parse_realized) {
>> +parse_realized(dev, str, ptr, prop->name, errp);
>> +} else {
>> +qdev_prop_set_after_realize(dev, name, errp);
>> +}
>> +} else {
>> +parse_unrealized(dev, str, ptr, prop->name, errp);
>> +}
>> +
>>   g_free(str);
>>   }
>>   
>> @@ -178,13 +188,13 @@ static void get_drive(Object *obj, Visitor *v, const 
>> char *name, void *opaque,
>>   static void set_drive(Object *obj, Visitor *v, const char *name, void 
>> *opaque,
>> Error **errp)
>>   {
>> -set_pointer(obj, v, opaque, parse_drive, name, errp);
>> +set_pointer(obj, v, opaque, NULL, parse_drive, name, errp);
>>   }
>>   
>>   static void set_drive_iothread(Object *obj, Visitor *v, const char *name,
>>  void *opaque, Error **errp)
>>   {
>> -set_pointer(obj, v, opaque, parse_drive_iothread, name, errp);
>> +set_pointer(obj, v, opaque, NULL, parse_drive_iothread, name, errp);
>>   }
>>   
>>   const PropertyInfo qdev_prop_drive = {
>> -- 
>> 2.17.0
>>

Re: [PATCH v1 3/3] tests/vm/ubuntu: update i386 image to 18.04

[Philippe Mathieu-Daudé]

On 11/22/19 12:22 PM, Alex Bennée wrote:

The current image is broken while running qtests but the bug go away
when built with a newer Ubuntu i386 image. I was unable to replicate
the crash on Debian Buster for i386 either so I'm concluding it is a
distro problem. Let's paper over that crack by updating our 32 bir


typo "our 32 bit"


test image.

Signed-off-by: Alex Bennée 
---
  tests/vm/ubuntu.i386 | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/vm/ubuntu.i386 b/tests/vm/ubuntu.i386
index 18b1ea2b72c..f611bebdc9d 100755
--- a/tests/vm/ubuntu.i386
+++ b/tests/vm/ubuntu.i386
@@ -66,8 +66,8 @@ class UbuntuX86VM(basevm.BaseVM):
  
  def build_image(self, img):

  cimg = self._download_with_cache(
-
"https://cloud-images.ubuntu.com/releases/16.04/release-20190605/ubuntu-16.04-server-cloudimg-i386-disk1.img";,
-
sha256sum="e30091144c73483822b7c27193e9d47346dd1064229da577c3fedcf943f7cfcc")


This one is in QCow2 format.


+
"https://cloud-images.ubuntu.com/releases/bionic/release-20191114/ubuntu-18.04-server-cloudimg-i386.img";,
+
sha256sum="28969840626d1ea80bb249c08eef1a4533e8904aa51a327b40f37ac4b4ff04ef")


This one is announced as USB format (ISO) but is in QCow2 format too...

Using '18.04' instead of 'bionic' in the URL is not important because 
the information is also in the filename.


Reviewed-by: Philippe Mathieu-Daudé 


  img_tmp = img + ".tmp"
  subprocess.check_call(["cp", "-f", cimg, img_tmp])
  subprocess.check_call(["qemu-img", "resize", img_tmp, "50G"])

Re: [PATCH v1 2/3] tests/vm/ubuntu: include language pack to silence locale warnings

[Philippe Mathieu-Daudé]

On 11/22/19 12:22 PM, Alex Bennée wrote:

The iotests in particular don't like the output being spammed with
warnings about locales.

Signed-off-by: Alex Bennée 
---
  tests/vm/ubuntu.i386 | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/vm/ubuntu.i386 b/tests/vm/ubuntu.i386
index 38f740eabf7..18b1ea2b72c 100755
--- a/tests/vm/ubuntu.i386
+++ b/tests/vm/ubuntu.i386
@@ -84,7 +84,7 @@ class UbuntuX86VM(basevm.BaseVM):
  self.ssh_root_check("sed -ie s/^#\ deb-src/deb-src/g 
/etc/apt/sources.list")
  self.ssh_root_check("apt-get update")
  self.ssh_root_check("apt-get build-dep -y qemu")
-self.ssh_root_check("apt-get install -y libfdt-dev flex bison")
+self.ssh_root_check("apt-get install -y libfdt-dev flex bison 
language-pack-en")
  self.ssh_root("poweroff")
  self.wait()
  os.rename(img_tmp, img)



Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH v35 02/13] target/avr: Add instruction helpers

[Philippe Mathieu-Daudé]

On 10/29/19 10:24 PM, Michael Rolnik wrote:

Stubs for unimplemented instructions and helpers for instructions that need to 
interact with QEMU.
SPM and WDR are unimplemented because they require emulation of complex 
peripherals.
The implementation of SLEEP is very limited due to the lack of peripherals to 
generate wake interrupts.
Memory access instructions are implemented here because some address ranges 
actually refer to CPU registers.

Signed-off-by: Michael Rolnik 


Tested-by: Philippe Mathieu-Daudé 


---
  target/avr/helper.c | 354 
  target/avr/helper.h |  29 
  2 files changed, 383 insertions(+)
  create mode 100644 target/avr/helper.c
  create mode 100644 target/avr/helper.h

diff --git a/target/avr/helper.c b/target/avr/helper.c
new file mode 100644
index 00..f0f0d4f15a
--- /dev/null
+++ b/target/avr/helper.c
@@ -0,0 +1,354 @@
+/*
+ * QEMU AVR CPU
+ *
+ * Copyright (c) 2019 Michael Rolnik
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
+ * 
+ */
+
+#include "qemu/osdep.h"
+
+#include "cpu.h"
+#include "hw/irq.h"
+#include "hw/sysbus.h"
+#include "sysemu/sysemu.h"
+#include "exec/exec-all.h"
+#include "exec/cpu_ldst.h"
+#include "exec/helper-proto.h"
+#include "exec/ioport.h"
+#include "qemu/host-utils.h"
+#include "qemu/error-report.h"
+
+bool avr_cpu_exec_interrupt(CPUState *cs, int interrupt_request)
+{
+bool ret = false;
+CPUClass *cc = CPU_GET_CLASS(cs);
+AVRCPU *cpu = AVR_CPU(cs);
+CPUAVRState *env = &cpu->env;
+
+if (interrupt_request & CPU_INTERRUPT_RESET) {
+if (cpu_interrupts_enabled(env)) {
+cs->exception_index = EXCP_RESET;
+cc->do_interrupt(cs);
+
+cs->interrupt_request &= ~CPU_INTERRUPT_RESET;
+
+ret = true;
+}
+}
+if (interrupt_request & CPU_INTERRUPT_HARD) {
+if (cpu_interrupts_enabled(env) && env->intsrc != 0) {
+int index = ctz32(env->intsrc);
+cs->exception_index = EXCP_INT(index);
+cc->do_interrupt(cs);
+
+env->intsrc &= env->intsrc - 1; /* clear the interrupt */
+cs->interrupt_request &= ~CPU_INTERRUPT_HARD;
+
+ret = true;
+}
+}
+return ret;
+}
+
+void avr_cpu_do_interrupt(CPUState *cs)
+{
+AVRCPU *cpu = AVR_CPU(cs);
+CPUAVRState *env = &cpu->env;
+
+uint32_t ret = env->pc_w;
+int vector = 0;
+int size = avr_feature(env, AVR_FEATURE_JMP_CALL) ? 2 : 1;
+int base = 0;
+
+if (cs->exception_index == EXCP_RESET) {
+vector = 0;
+} else if (env->intsrc != 0) {
+vector = ctz32(env->intsrc) + 1;
+}
+
+if (avr_feature(env, AVR_FEATURE_3_BYTE_PC)) {
+cpu_stb_data(env, env->sp--, (ret & 0xff));
+cpu_stb_data(env, env->sp--, (ret & 0x00ff00) >> 8);
+cpu_stb_data(env, env->sp--, (ret & 0xff) >> 16);
+} else if (avr_feature(env, AVR_FEATURE_2_BYTE_PC)) {
+cpu_stb_data(env, env->sp--, (ret & 0xff));
+cpu_stb_data(env, env->sp--, (ret & 0x00ff00) >> 8);
+} else {
+cpu_stb_data(env, env->sp--, (ret & 0xff));
+}
+
+env->pc_w = base + vector * size;
+env->sregI = 0; /* clear Global Interrupt Flag */
+
+cs->exception_index = -1;
+}
+
+int avr_cpu_memory_rw_debug(CPUState *cs, vaddr addr, uint8_t *buf,
+int len, bool is_write)
+{
+return cpu_memory_rw_debug(cs, addr, buf, len, is_write);
+}
+
+hwaddr avr_cpu_get_phys_page_debug(CPUState *cs, vaddr addr)
+{
+return addr; /* I assume 1:1 address correspondance */
+}
+
+int avr_cpu_handle_mmu_fault(
+CPUState *cs, vaddr address, int size, int rw, int mmu_idx)
+{
+/* currently it's assumed that this will never happen */
+cs->exception_index = EXCP_DEBUG;
+cpu_dump_state(cs, stderr, 0);
+return 1;
+}
+
+bool avr_cpu_tlb_fill(CPUState *cs, vaddr address, int size,
+MMUAccessType access_type, int mmu_idx,
+bool probe, uintptr_t retaddr)
+{
+int prot = 0;
+MemTxAttrs attrs = {};
+uint32_t paddr;
+
+address &= TARGET_PAGE_MASK;
+
+if (mmu_idx == MMU_CODE_IDX) {
+/* access to code in flash */
+paddr = OFFSET_CODE + address;
+prot = PAGE_READ | PAGE_EXEC;
+if (paddr + TARGET_PAGE_S

Re: [PATCH v35 03/13] target/avr: Add instruction decoding

[Philippe Mathieu-Daudé]

On 10/29/19 10:24 PM, Michael Rolnik wrote:

This includes:
- encoding of all 16 bit instructions
- encoding of all 32 bit instructions

Signed-off-by: Michael Rolnik 


Tested-by: Philippe Mathieu-Daudé 


---
  target/avr/insn.decode | 175 +
  1 file changed, 175 insertions(+)
  create mode 100644 target/avr/insn.decode

diff --git a/target/avr/insn.decode b/target/avr/insn.decode
new file mode 100644
index 00..6b387762c6
--- /dev/null
+++ b/target/avr/insn.decode
@@ -0,0 +1,175 @@
+#
+#   A = [16 .. 31]
+#   B = [16 .. 23]
+#   C = [24, 26, 28, 30]
+#   D = [0, 2, 4, 6, 8, .. 30]
+
+%rd 4:5
+%rr 9:1 0:4
+
+&rd_rr  rd rr
+&rd_imm rd imm
+
+@op_rd_rr    .. . . &rd_rr  rd=%rd rr=%rr
+ADD  11 . . @op_rd_rr
+ADC 0001 11 . . @op_rd_rr
+AND 0010 00 . . @op_rd_rr
+CP  0001 01 . . @op_rd_rr
+CPC  01 . . @op_rd_rr
+CPSE0001 00 . . @op_rd_rr
+EOR 0010 01 . . @op_rd_rr
+MOV 0010 11 . . @op_rd_rr
+MUL 1001 11 . . @op_rd_rr
+OR  0010 10 . . @op_rd_rr
+SBC  10 . . @op_rd_rr
+SUB 0001 10 . . @op_rd_rr
+
+
+%rd_c   4:2 !function=to_C
+%imm6   6:2 0:4
+
+@op_rd_imm6   .. .. &rd_imm rd=%rd_c imm=%imm6
+ADIW1001 0110 .. .. @op_rd_imm6
+SBIW1001 0111 .. .. @op_rd_imm6
+
+
+%rd_a   4:4 !function=to_A
+%rr_a   0:4 !function=to_A
+%rd_d   4:4 !function=to_D
+%rr_d   0:4 !function=to_D
+%imm8   8:4 0:4
+
+@op_rd_imm8     &rd_imm rd=%rd_a imm=%imm8
+ANDI0111    @op_rd_imm8
+CPI 0011    @op_rd_imm8
+LDI 1110    @op_rd_imm8
+ORI 0110    @op_rd_imm8
+SBCI0100    @op_rd_imm8
+SUBI0101    @op_rd_imm8
+
+
+@op_rd   ... rd:5 
+ASR 1001 010 . 0101 @op_rd
+COM 1001 010 .  @op_rd
+DEC 1001 010 . 1010 @op_rd
+ELPM2   1001 000 . 0110 @op_rd
+ELPMX   1001 000 . 0111 @op_rd
+INC 1001 010 . 0011 @op_rd
+LDX11001 000 . 1100 @op_rd
+LDX21001 000 . 1101 @op_rd
+LDX31001 000 . 1110 @op_rd
+LDY21001 000 . 1001 @op_rd
+LDY31001 000 . 1010 @op_rd
+LDZ21001 000 . 0001 @op_rd
+LDZ31001 000 . 0010 @op_rd
+LPM21001 000 . 0100 @op_rd
+LPMX1001 000 . 0101 @op_rd
+LSR 1001 010 . 0110 @op_rd
+NEG 1001 010 . 0001 @op_rd
+POP 1001 000 .  @op_rd
+PUSH1001 001 .  @op_rd
+ROR 1001 010 . 0111 @op_rd
+STY21001 001 . 1001 @op_rd
+STY31001 001 . 1010 @op_rd
+STZ21001 001 . 0001 @op_rd
+STZ31001 001 . 0010 @op_rd
+SWAP1001 010 . 0010 @op_rd
+
+
+@op_bit   . bit:3 
+BCLR1001 0100 1 ... 1000@op_bit
+BSET1001 0100 0 ... 1000@op_bit
+
+
+@op_rd_bit   ... rd:5 . bit:3
+BLD  100 . 0 ...@op_rd_bit
+BST  101 . 0 ...@op_rd_bit
+
+
+@op_bit_imm  .. imm:s7 bit:3
+BRBC 01 ... ... @op_bit_imm
+BRBS 00 ... ... @op_bit_imm
+
+
+BREAK   1001 0101 1001 1000
+EICALL  1001 0101 0001 1001
+EIJMP   1001 0100 0001 1001
+ELPM1   1001 0101 1101 1000
+ICALL   1001 0101  1001
+IJMP1001 0100  1001
+LPM11001 0101 1100 1000
+NOP    
+RET 1001 0101  1000
+RETI1001 0101 0001 1000
+SLEEP   1001 0101 1000 1000
+SPM 1001 0101 1110 1000
+SPMX1001 0101  1000
+WDR 1001 0101 1010 1000
+
+
+@op_reg_bit   reg:5 bit:3
+CBI 1001 1000 . ... @op_reg_bit
+SBI 1001 1010 . ... @op_reg_bit
+SBIC1001 1001 . ... @op_reg_bit
+SBIS1001 1

Re: [PATCH v35 09/13] target/avr: Add instruction translation - CPU main translation function

[Philippe Mathieu-Daudé]

On 10/29/19 10:24 PM, Michael Rolnik wrote:

Co-developed-by: Richard Henderson 


This misses a:
"Signed-off-by: Richard Henderson "


Co-developed-by: Michael Rolnik 

Signed-off-by: Michael Rolnik 


Tested-by: Philippe Mathieu-Daudé 


---
  target/avr/translate.c | 234 +
  1 file changed, 234 insertions(+)

diff --git a/target/avr/translate.c b/target/avr/translate.c
index 30ba13bdd7..fdf4e11f58 100644
--- a/target/avr/translate.c
+++ b/target/avr/translate.c
@@ -2792,3 +2792,237 @@ static bool trans_WDR(DisasContext *ctx, arg_WDR *a)
  
  return true;

  }
+
+
+void avr_cpu_tcg_init(void)
+{
+int i;
+
+#define AVR_REG_OFFS(x) offsetof(CPUAVRState, x)
+cpu_pc = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(pc_w), "pc");
+cpu_Cf = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(sregC), "Cf");
+cpu_Zf = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(sregZ), "Zf");
+cpu_Nf = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(sregN), "Nf");
+cpu_Vf = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(sregV), "Vf");
+cpu_Sf = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(sregS), "Sf");
+cpu_Hf = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(sregH), "Hf");
+cpu_Tf = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(sregT), "Tf");
+cpu_If = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(sregI), "If");
+cpu_rampD = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(rampD), "rampD");
+cpu_rampX = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(rampX), "rampX");
+cpu_rampY = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(rampY), "rampY");
+cpu_rampZ = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(rampZ), "rampZ");
+cpu_eind = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(eind), "eind");
+cpu_sp = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(sp), "sp");
+cpu_skip = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(skip), "skip");
+
+for (i = 0; i < NO_CPU_REGISTERS; i++) {
+cpu_r[i] = tcg_global_mem_new_i32(cpu_env, AVR_REG_OFFS(r[i]),
+  reg_names[i]);
+}
+#undef AVR_REG_OFFS
+}
+
+static void translate(DisasContext *ctx)
+{
+uint32_t opcode = next_word(ctx);
+
+if (!decode_insn(ctx, opcode)) {
+gen_helper_unsupported(cpu_env);
+ctx->bstate = DISAS_NORETURN;
+}
+}
+
+/* Standardize the cpu_skip condition to NE.  */
+static bool canonicalize_skip(DisasContext *ctx)
+{
+switch (ctx->skip_cond) {
+case TCG_COND_NEVER:
+/* Normal case: cpu_skip is known to be false.  */
+return false;
+
+case TCG_COND_ALWAYS:
+/*
+ * Breakpoint case: cpu_skip is known to be true, via TB_FLAGS_SKIP.
+ * The breakpoint is on the instruction being skipped, at the start
+ * of the TranslationBlock.  No need to update.
+ */
+return false;
+
+case TCG_COND_NE:
+if (ctx->skip_var1 == NULL) {
+tcg_gen_mov_tl(cpu_skip, ctx->skip_var0);
+} else {
+tcg_gen_xor_tl(cpu_skip, ctx->skip_var0, ctx->skip_var1);
+ctx->skip_var1 = NULL;
+}
+break;
+
+default:
+/* Convert to a NE condition vs 0. */
+if (ctx->skip_var1 == NULL) {
+tcg_gen_setcondi_tl(ctx->skip_cond, cpu_skip, ctx->skip_var0, 0);
+} else {
+tcg_gen_setcond_tl(ctx->skip_cond, cpu_skip,
+   ctx->skip_var0, ctx->skip_var1);
+ctx->skip_var1 = NULL;
+}
+ctx->skip_cond = TCG_COND_NE;
+break;
+}
+if (ctx->free_skip_var0) {
+tcg_temp_free(ctx->skip_var0);
+ctx->free_skip_var0 = false;
+}
+ctx->skip_var0 = cpu_skip;
+return true;
+}
+
+void gen_intermediate_code(CPUState *cs, TranslationBlock *tb, int max_insns)
+{
+CPUAVRState *env = cs->env_ptr;
+DisasContext ctx = {
+.tb = tb,
+.cs = cs,
+.env = env,
+.memidx = 0,
+.bstate = DISAS_NEXT,
+.skip_cond = TCG_COND_NEVER,
+.singlestep = cs->singlestep_enabled,
+};
+target_ulong pc_start = tb->pc / 2;
+int num_insns = 0;
+
+if (tb->flags & TB_FLAGS_FULL_ACCESS) {
+/*
+ * This flag is set by ST/LD instruction we will regenerate it ONLY
+ * with mem/cpu memory access instead of mem access
+ */
+max_insns = 1;
+}
+if (ctx.singlestep) {
+max_insns = 1;
+}
+
+gen_tb_start(tb);
+
+ctx.npc = pc_start;
+if (tb->flags & TB_FLAGS_SKIP) {
+ctx.skip_cond = TCG_COND_ALWAYS;
+ctx.skip_var0 = cpu_skip;
+}
+
+do {
+TCGLabel *skip_label = NULL;
+
+/* translate current instruction */
+tcg_gen_insn_start(ctx.npc);
+num_insns++;
+
+/*
+ * this is due to some strange GDB behavior
+ * let's assume main has address 0x100
+ * b main   - sets breakpoint at address 0x0100 (code)
+ * b

Re: [PATCH 4/4] s390x: Beautify machine reset

[Janosch Frank]

On 11/22/19 11:59 AM, David Hildenbrand wrote:
> On 22.11.19 08:52, Janosch Frank wrote:
>> * Add comments that tell you which diag308 subcode caused the reset
>> * Sort by diag308 reset subcode
>>
>> Signed-off-by: Janosch Frank 
>> ---
>>   hw/s390x/s390-virtio-ccw.c | 20 ++--
>>   1 file changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
>> index c1d1440272..88f7758721 100644
>> --- a/hw/s390x/s390-virtio-ccw.c
>> +++ b/hw/s390x/s390-virtio-ccw.c
>> @@ -330,15 +330,7 @@ static void s390_machine_reset(MachineState *machine)
>>   s390_cmma_reset();
>>   
>>   switch (reset_type) {
>> -case S390_RESET_EXTERNAL:
>> -case S390_RESET_REIPL:
>> -qemu_devices_reset();
>> -s390_crypto_reset();
>> -
>> -/* configure and start the ipl CPU only */
>> -run_on_cpu(cs, s390_do_cpu_ipl, RUN_ON_CPU_NULL);
>> -break;
>> -case S390_RESET_MODIFIED_CLEAR:
>> +case S390_RESET_MODIFIED_CLEAR: /* Subcode 0 */
> 
> IMHO "Subcode X" isn't of much help here. We're out of diag handling.
> 
> I'd suggest to just document the subcodes along with the definitions, if 
> really needed, and drop this patch, at least I don't quite see the value 
> of moving code around here... or is the code shuffling of any value on 
> your prot virt patches?
> 

It keeps me from consulting the POP every time I need to change things
in the machine resets. This is basically a 1:1 mapping of diag 308
subcodes to machine resets, so why don't we want to make that obvious
and order them by the subcodes?



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 4/4] s390x: Beautify machine reset

[David Hildenbrand]

On 22.11.19 12:46, Janosch Frank wrote:

On 11/22/19 11:59 AM, David Hildenbrand wrote:

On 22.11.19 08:52, Janosch Frank wrote:

* Add comments that tell you which diag308 subcode caused the reset
* Sort by diag308 reset subcode

Signed-off-by: Janosch Frank 
---
   hw/s390x/s390-virtio-ccw.c | 20 ++--
   1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index c1d1440272..88f7758721 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -330,15 +330,7 @@ static void s390_machine_reset(MachineState *machine)
   s390_cmma_reset();
   
   switch (reset_type) {

-case S390_RESET_EXTERNAL:
-case S390_RESET_REIPL:
-qemu_devices_reset();
-s390_crypto_reset();
-
-/* configure and start the ipl CPU only */
-run_on_cpu(cs, s390_do_cpu_ipl, RUN_ON_CPU_NULL);
-break;
-case S390_RESET_MODIFIED_CLEAR:
+case S390_RESET_MODIFIED_CLEAR: /* Subcode 0 */


IMHO "Subcode X" isn't of much help here. We're out of diag handling.

I'd suggest to just document the subcodes along with the definitions, if
really needed, and drop this patch, at least I don't quite see the value
of moving code around here... or is the code shuffling of any value on
your prot virt patches?



It keeps me from consulting the POP every time I need to change things
in the machine resets. This is basically a 1:1 mapping of diag 308
subcodes to machine resets, so why don't we want to make that obvious
and order them by the subcodes?



Because it is not a 1:1 mapping: S390_RESET_EXTERNAL

--

Thanks,

David / dhildenb

Re: [PATCH v4 12/37] serial: start making SerialMM a sysbus device

[Marc-André Lureau]

On Fri, Nov 22, 2019 at 2:11 PM Peter Maydell  wrote:
>
> On Thu, 21 Nov 2019 at 18:51, Marc-André Lureau
>  wrote:
> >
> > Hi
> >
> > On Thu, Nov 21, 2019 at 10:24 PM Peter Maydell  
> > wrote:
> > >
> > > On Thu, 21 Nov 2019 at 18:15, Marc-André Lureau
> > >  wrote:
> > > >
> > > > On Thu, Nov 21, 2019 at 5:47 PM Peter Maydell 
> > > >  wrote:
> > > > >
> > > > > On Wed, 20 Nov 2019 at 15:27, Marc-André Lureau
> > > > >  wrote:
> > > > > >
> > > > > > Memory mapped serial device is in fact a sysbus device. The 
> > > > > > following
> > > > > > patches will make use of sysbus facilities for resource and
> > > > > > registration. In particular, "serial-mm: use sysbus facilities" will
> > > > > > move internal serial realization to serial_mm_realize callback to
> > > > > > follow qdev best practices.
> > > > >
> > > > > What goes wrong if you just put the realize of smm->serial in
> > > > > the right place to start with ?
> > > >
> > > > You mean squash the following patches?
> > >
> > > No, I meant just having this patch have
> > >
> > > static void serial_mm_realize(DeviceState *dev, Error **errp)
> > > {
> > > SerialMM *smm = SERIAL_MM(dev);
> > > SerialState *s = &smm->serial;
> > >
> > > object_property_set_bool(OBJECT(dev), true, "realized", &err);
> > > if (err) {
> > > error_propagate(errp, err);
> > > return;
> > > }
> > > }
> > >
> > > and
> > >
> > > + dc->realize = serial_mm_realize;
> > >
> > > rather than manually doing the qdev_init_nofail()
> > > in serial_mm_init(). This seems to me like an integral
> > > part of the change to doing the init of the subdevice in the
> > > init method, so it would be better unless there's a reason
> > > why it breaks something. The rest of patch 15 (which is
> > > what currently makes the equivalent change to realize) is all
> > > about passing through the properties and exposing the
> > > sysbus MMIO/irq regions and should stay a separate patch.
> > >
> > > (setting the 'realized' property is better in a realize method
> > > than using qdev_init_nofail() because it means we can propagate
> > > any error outward rather than killing qemu.)
> >
> > Ok, but I implemented realize and moved serial init in "serial: make
> > SerialIO a sysbus device".
>
> That patch is for the TYPE_SERIAL_IO device, isn't it? It
> changes both serial_io_instance_init and serial_io_realize
> to do the instance init and realize of the TYPE_SERIAL device,
> so it doesn't have the same "only doing half a change" issue
> that this patch has for TYPE_SERIAL_MM.
>

Ok, I got it, thanks.




-- 
Marc-André Lureau

Re: [PATCH v35 10/13] target/avr: Add limited support for USART and 16 bit timer peripherals

[Philippe Mathieu-Daudé]

Hi Michael,

On 10/29/19 10:24 PM, Michael Rolnik wrote:

From: Sarah Harris 

These were designed to facilitate testing but should provide enough function to 
be useful in other contexts.
Only a subset of the functions of each peripheral is implemented, mainly due to 
the lack of a standard way to handle electrical connections (like GPIO pins).

Signed-off-by: Sarah Harris 
---
  hw/char/Kconfig|   3 +
  hw/char/Makefile.objs  |   1 +
  hw/char/avr_usart.c| 324 ++
  hw/misc/Kconfig|   3 +
  hw/misc/Makefile.objs  |   2 +
  hw/misc/avr_mask.c | 112 ++
  hw/timer/Kconfig   |   3 +
  hw/timer/Makefile.objs |   2 +
  hw/timer/avr_timer16.c | 605 +
  include/hw/char/avr_usart.h|  97 ++
  include/hw/misc/avr_mask.h |  47 +++
  include/hw/timer/avr_timer16.h |  97 ++
  12 files changed, 1296 insertions(+)
  create mode 100644 hw/char/avr_usart.c
  create mode 100644 hw/misc/avr_mask.c
  create mode 100644 hw/timer/avr_timer16.c
  create mode 100644 include/hw/char/avr_usart.h
  create mode 100644 include/hw/misc/avr_mask.h
  create mode 100644 include/hw/timer/avr_timer16.h


I haven't read all the other review comments yet, so I'm not sure you 
need to respin a new version of this series.


In another review I suggested to rename 'avr' -> 'avr8'.

If you have to send another version, can you split this patch in 3?
IRQ/TMR/UART.

[...]

+static void avr_timer16_clksrc_update(AVRTimer16State *t16)
+{
+uint16_t divider = 0;
+switch (CLKSRC(t16)) {
+case T16_CLKSRC_EXT_FALLING:
+case T16_CLKSRC_EXT_RISING:
+ERROR("external clock source unsupported");
+goto end;
+case T16_CLKSRC_STOPPED:
+goto end;
+case T16_CLKSRC_DIV1:
+divider = 1;
+break;
+case T16_CLKSRC_DIV8:
+divider = 8;
+break;
+case T16_CLKSRC_DIV64:
+divider = 64;
+break;
+case T16_CLKSRC_DIV256:
+divider = 256;
+break;
+case T16_CLKSRC_DIV1024:
+divider = 1024;
+break;
+default:
+goto end;
+}
+t16->freq_hz = t16->cpu_freq_hz / divider;
+t16->period_ns = 10ULL / t16->freq_hz;


Please use NANOSECONDS_PER_SECOND here.


+DB_PRINT("Timer frequency %" PRIu64 " hz, period %" PRIu64 " ns (%f s)",
+ t16->freq_hz, t16->period_ns, 1 / (double)t16->freq_hz);
+end:
+return;
+}


While trying this patch it looks the timer fires too fast (or maybe 
doesn't use the correct clock rate).


When looking at the instructions in GDB render the debugging of timing 
issues pointless (which is why I wanted to compare the asm executed with 
the IRQ timed events on stdout).


I should have some time to continue investigating Sunday evening.

Regards,

Phil.

Re: [PATCH v35 12/13] target/avr: Register AVR support with the rest of QEMU, the build system, and the WMAINTAINERS file

[Philippe Mathieu-Daudé]

On 10/29/19 10:24 PM, Michael Rolnik wrote:

Signed-off-by: Michael Rolnik 
---
  MAINTAINERS |  9 +
  arch_init.c |  2 ++
  configure   |  7 +++
  default-configs/avr-softmmu.mak |  5 +
  include/disas/dis-asm.h |  6 ++
  include/sysemu/arch_init.h  |  1 +
  qapi/machine.json   |  3 ++-
  target/avr/Makefile.objs| 33 +
  tests/machine-none-test.c   |  1 +
  9 files changed, 66 insertions(+), 1 deletion(-)
  create mode 100644 default-configs/avr-softmmu.mak
  create mode 100644 target/avr/Makefile.objs

diff --git a/MAINTAINERS b/MAINTAINERS
index 5b27888533..01f951356f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -163,6 +163,15 @@ S: Maintained
  F: hw/arm/smmu*
  F: include/hw/arm/smmu*
  
+AVR TCG CPUs

+M: Michael Rolnik 
+S: Maintained
+F: target/avr/
+F: hw/misc/avr_mask.c
+F: hw/char/avr_usart.c
+F: hw/timer/avr_timer16.c
+F: hw/avr/
+
  CRIS TCG CPUs
  M: Edgar E. Iglesias 
  S: Maintained
diff --git a/arch_init.c b/arch_init.c
index 705d0b94ad..6a741165b2 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -89,6 +89,8 @@ int graphic_depth = 32;
  #define QEMU_ARCH QEMU_ARCH_UNICORE32
  #elif defined(TARGET_XTENSA)
  #define QEMU_ARCH QEMU_ARCH_XTENSA
+#elif defined(TARGET_AVR)
+#define QEMU_ARCH QEMU_ARCH_AVR
  #endif
  
  const uint32_t arch_type = QEMU_ARCH;

diff --git a/configure b/configure
index 3be9e92a24..e5dec62fde 100755
--- a/configure
+++ b/configure
@@ -7516,6 +7516,10 @@ case "$target_name" in
  mttcg="yes"
  gdb_xml_files="aarch64-core.xml aarch64-fpu.xml arm-core.xml arm-vfp.xml 
arm-vfp3.xml arm-neon.xml"
;;
+  avr)
+gdb_xml_files="avr-cpu.xml"
+target_compiler=$cross_cc_avr
+  ;;
cris)
;;
hppa)
@@ -7735,6 +7739,9 @@ for i in $ARCH $TARGET_BASE_ARCH ; do
disas_config "ARM_A64"
  fi
;;
+  avr)
+disas_config "AVR"
+  ;;
cris)
  disas_config "CRIS"
;;
diff --git a/default-configs/avr-softmmu.mak b/default-configs/avr-softmmu.mak
new file mode 100644
index 00..d1e1c28118
--- /dev/null
+++ b/default-configs/avr-softmmu.mak
@@ -0,0 +1,5 @@
+# Default configuration for avr-softmmu
+
+# Boards:
+#
+CONFIG_AVR_SAMPLE=y
diff --git a/include/disas/dis-asm.h b/include/disas/dis-asm.h
index e9c7dd8eb4..8bedce17ac 100644
--- a/include/disas/dis-asm.h
+++ b/include/disas/dis-asm.h
@@ -211,6 +211,12 @@ enum bfd_architecture
  #define bfd_mach_m32r  0  /* backwards compatibility */
bfd_arch_mn10200,/* Matsushita MN10200 */
bfd_arch_mn10300,/* Matsushita MN10300 */
+  bfd_arch_avr,   /* Atmel AVR microcontrollers.  */
+#define bfd_mach_avr1  1
+#define bfd_mach_avr2  2
+#define bfd_mach_avr3  3
+#define bfd_mach_avr4  4
+#define bfd_mach_avr5  5
bfd_arch_cris,   /* Axis CRIS */
  #define bfd_mach_cris_v0_v10   255
  #define bfd_mach_cris_v32  32
diff --git a/include/sysemu/arch_init.h b/include/sysemu/arch_init.h
index 62c6fe4cf1..893df26ce2 100644
--- a/include/sysemu/arch_init.h
+++ b/include/sysemu/arch_init.h
@@ -24,6 +24,7 @@ enum {
  QEMU_ARCH_NIOS2 = (1 << 17),
  QEMU_ARCH_HPPA = (1 << 18),
  QEMU_ARCH_RISCV = (1 << 19),
+QEMU_ARCH_AVR = (1 << 20),
  };
  
  extern const uint32_t arch_type;

diff --git a/qapi/machine.json b/qapi/machine.json
index ca26779f1a..1fa2917ba9 100644
--- a/qapi/machine.json
+++ b/qapi/machine.json
@@ -21,11 +21,12 @@
  #is true even for "qemu-system-x86_64".
  #
  # ppcemb: dropped in 3.1
+# avr: since 4.2
  #
  # Since: 3.0
  ##
  { 'enum' : 'SysEmuTarget',
-  'data' : [ 'aarch64', 'alpha', 'arm', 'cris', 'hppa', 'i386', 'lm32',
+  'data' : [ 'aarch64', 'alpha', 'arm', 'avr', 'cris', 'hppa', 'i386', 'lm32',
   'm68k', 'microblaze', 'microblazeel', 'mips', 'mips64',
   'mips64el', 'mipsel', 'moxie', 'nios2', 'or1k', 'ppc',
   'ppc64', 'riscv32', 'riscv64', 's390x', 'sh4',
diff --git a/target/avr/Makefile.objs b/target/avr/Makefile.objs
new file mode 100644
index 00..2976affd95
--- /dev/null
+++ b/target/avr/Makefile.objs
@@ -0,0 +1,33 @@
+#
+#  QEMU AVR CPU
+#
+#  Copyright (c) 2019 Michael Rolnik
+#
+#  This library is free software; you can redistribute it and/or
+#  modify it under the terms of the GNU Lesser General Public
+#  License as published by the Free Software Foundation; either
+#  version 2.1 of the License, or (at your option) any later version.
+#
+#  This library is distributed in the hope that it will be useful,
+#  but WITHOUT ANY WARRANTY; without even the implied warranty of
+#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+#  Lesser General Public License for more details.
+#
+#  You should have received a copy of the GNU Lesser General Public
+#  License along with this library; if not, see
+#  
+#
+
+DECODETREE = $(SRC_P

Re: [PATCH 4/4] s390x: Beautify machine reset

[Cornelia Huck]

On Fri, 22 Nov 2019 12:47:44 +0100
David Hildenbrand  wrote:

> On 22.11.19 12:46, Janosch Frank wrote:
> > On 11/22/19 11:59 AM, David Hildenbrand wrote:  
> >> On 22.11.19 08:52, Janosch Frank wrote:  
> >>> * Add comments that tell you which diag308 subcode caused the reset
> >>> * Sort by diag308 reset subcode
> >>>
> >>> Signed-off-by: Janosch Frank 
> >>> ---
> >>>hw/s390x/s390-virtio-ccw.c | 20 ++--
> >>>1 file changed, 10 insertions(+), 10 deletions(-)
> >>>
> >>> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
> >>> index c1d1440272..88f7758721 100644
> >>> --- a/hw/s390x/s390-virtio-ccw.c
> >>> +++ b/hw/s390x/s390-virtio-ccw.c
> >>> @@ -330,15 +330,7 @@ static void s390_machine_reset(MachineState *machine)
> >>>s390_cmma_reset();
> >>>
> >>>switch (reset_type) {
> >>> -case S390_RESET_EXTERNAL:
> >>> -case S390_RESET_REIPL:
> >>> -qemu_devices_reset();
> >>> -s390_crypto_reset();
> >>> -
> >>> -/* configure and start the ipl CPU only */
> >>> -run_on_cpu(cs, s390_do_cpu_ipl, RUN_ON_CPU_NULL);
> >>> -break;
> >>> -case S390_RESET_MODIFIED_CLEAR:
> >>> +case S390_RESET_MODIFIED_CLEAR: /* Subcode 0 */  
> >>
> >> IMHO "Subcode X" isn't of much help here. We're out of diag handling.
> >>
> >> I'd suggest to just document the subcodes along with the definitions, if
> >> really needed, and drop this patch, at least I don't quite see the value
> >> of moving code around here... or is the code shuffling of any value on
> >> your prot virt patches?
> >>  
> > 
> > It keeps me from consulting the POP every time I need to change things
> > in the machine resets. This is basically a 1:1 mapping of diag 308
> > subcodes to machine resets, so why don't we want to make that obvious
> > and order them by the subcodes?
> >   
> 
> Because it is not a 1:1 mapping: S390_RESET_EXTERNAL
> 

Tack the explanation onto the definitions of S390_RESET_, then?
Probably still quicker than consulting the POP :)

[PATCH] Remove wrappers

[Janosch Frank]

That's what it would look like.

Signed-off-by: Janosch Frank 
---
 target/s390x/cpu-qom.h | 12 
 target/s390x/cpu.c | 28 +---
 target/s390x/cpu.h |  8 +---
 target/s390x/sigp.c|  4 ++--
 4 files changed, 20 insertions(+), 32 deletions(-)

diff --git a/target/s390x/cpu-qom.h b/target/s390x/cpu-qom.h
index b809ec8418..e8ec999e77 100644
--- a/target/s390x/cpu-qom.h
+++ b/target/s390x/cpu-qom.h
@@ -34,13 +34,18 @@
 typedef struct S390CPUModel S390CPUModel;
 typedef struct S390CPUDef S390CPUDef;
 
+typedef enum cpu_reset_type {
+S390_CPU_RESET_NORMAL,
+S390_CPU_RESET_INITIAL,
+S390_CPU_RESET_CLEAR,
+} cpu_reset_type;
+
 /**
  * S390CPUClass:
  * @parent_realize: The parent class' realize handler.
  * @parent_reset: The parent class' reset handler.
  * @load_normal: Performs a load normal.
- * @cpu_reset: Performs a CPU reset.
- * @initial_cpu_reset: Performs an initial CPU reset.
+ * @reset: Performs a CPU reset of a given type.
  *
  * An S/390 CPU model.
  */
@@ -57,8 +62,7 @@ typedef struct S390CPUClass {
 DeviceRealize parent_realize;
 void (*parent_reset)(CPUState *cpu);
 void (*load_normal)(CPUState *cpu);
-void (*cpu_reset)(CPUState *cpu);
-void (*initial_cpu_reset)(CPUState *cpu);
+void (*reset)(CPUState *cpu, cpu_reset_type type);
 } S390CPUClass;
 
 typedef struct S390CPU S390CPU;
diff --git a/target/s390x/cpu.c b/target/s390x/cpu.c
index 556afecbc1..970495d042 100644
--- a/target/s390x/cpu.c
+++ b/target/s390x/cpu.c
@@ -82,12 +82,6 @@ static void s390_cpu_load_normal(CPUState *s)
 }
 #endif
 
-typedef enum cpu_reset_type {
-S390_CPU_RESET_NORMAL,
-S390_CPU_RESET_INITIAL,
-S390_CPU_RESET_CLEAR,
-} cpu_reset_type;
-
 static void s390_cpu_reset(CPUState *s, cpu_reset_type type)
 {
 S390CPU *cpu = S390_CPU(s);
@@ -138,21 +132,6 @@ static void s390_cpu_reset(CPUState *s, cpu_reset_type 
type)
 #endif
 }
 
-static void s390_cpu_reset_normal(CPUState *s)
-{
-return s390_cpu_reset(s, S390_CPU_RESET_NORMAL);
-}
-
-static void s390_cpu_reset_initial(CPUState *s)
-{
-return s390_cpu_reset(s, S390_CPU_RESET_INITIAL);
-}
-
-static void s390_cpu_reset_clear(CPUState *s)
-{
-return s390_cpu_reset(s, S390_CPU_RESET_CLEAR);
-}
-
 #if !defined(CONFIG_USER_ONLY)
 static void s390_cpu_machine_reset_cb(void *opaque)
 {
@@ -444,6 +423,11 @@ static Property s390x_cpu_properties[] = {
 DEFINE_PROP_END_OF_LIST()
 };
 
+static void s390_cpu_reset_clear(CPUState *s)
+{
+return s390_cpu_reset(s, S390_CPU_RESET_CLEAR);
+}
+
 static void s390_cpu_class_init(ObjectClass *oc, void *data)
 {
 S390CPUClass *scc = S390_CPU_CLASS(oc);
@@ -459,8 +443,6 @@ static void s390_cpu_class_init(ObjectClass *oc, void *data)
 #if !defined(CONFIG_USER_ONLY)
 scc->load_normal = s390_cpu_load_normal;
 #endif
-scc->cpu_reset = s390_cpu_reset_normal;
-scc->initial_cpu_reset = s390_cpu_reset_initial;
 cc->reset = s390_cpu_reset_clear;
 cc->class_by_name = s390_cpu_class_by_name,
 cc->has_work = s390_cpu_has_work;
diff --git a/target/s390x/cpu.h b/target/s390x/cpu.h
index 17460ed7b3..687b31d87e 100644
--- a/target/s390x/cpu.h
+++ b/target/s390x/cpu.h
@@ -734,21 +734,23 @@ static inline uint64_t s390_build_validity_mcic(void)
 
 static inline void s390_do_cpu_full_reset(CPUState *cs, run_on_cpu_data arg)
 {
-cpu_reset(cs);
+S390CPUClass *scc = S390_CPU_GET_CLASS(cs);
+
+scc->reset(cs, S390_CPU_RESET_CLEAR);
 }
 
 static inline void s390_do_cpu_reset(CPUState *cs, run_on_cpu_data arg)
 {
 S390CPUClass *scc = S390_CPU_GET_CLASS(cs);
 
-scc->cpu_reset(cs);
+scc->reset(cs, S390_CPU_RESET_CLEAR);
 }
 
 static inline void s390_do_cpu_initial_reset(CPUState *cs, run_on_cpu_data arg)
 {
 S390CPUClass *scc = S390_CPU_GET_CLASS(cs);
 
-scc->initial_cpu_reset(cs);
+scc->reset(cs, S390_CPU_RESET_INITIAL);
 }
 
 static inline void s390_do_cpu_load_normal(CPUState *cs, run_on_cpu_data arg)
diff --git a/target/s390x/sigp.c b/target/s390x/sigp.c
index 2ce22d4dc1..727875bb4a 100644
--- a/target/s390x/sigp.c
+++ b/target/s390x/sigp.c
@@ -254,7 +254,7 @@ static void sigp_initial_cpu_reset(CPUState *cs, 
run_on_cpu_data arg)
 SigpInfo *si = arg.host_ptr;
 
 cpu_synchronize_state(cs);
-scc->initial_cpu_reset(cs);
+scc->reset(cs, S390_CPU_RESET_INITIAL);
 cpu_synchronize_post_reset(cs);
 si->cc = SIGP_CC_ORDER_CODE_ACCEPTED;
 }
@@ -266,7 +266,7 @@ static void sigp_cpu_reset(CPUState *cs, run_on_cpu_data 
arg)
 SigpInfo *si = arg.host_ptr;
 
 cpu_synchronize_state(cs);
-scc->cpu_reset(cs);
+scc->reset(cs, S390_CPU_RESET_NORMAL);
 cpu_synchronize_post_reset(cs);
 si->cc = SIGP_CC_ORDER_CODE_ACCEPTED;
 }
-- 
2.20.1

Re: [PATCH v17 09/14] numa: Extend CLI to provide memory side cache information

[Igor Mammedov]

On Fri, 22 Nov 2019 15:48:21 +0800
Tao Xu  wrote:

> From: Liu Jingqi 
> 
> Add -numa hmat-cache option to provide Memory Side Cache Information.
> These memory attributes help to build Memory Side Cache Information
> Structure(s) in ACPI Heterogeneous Memory Attribute Table (HMAT).
> 
> Reviewed-by: Daniel Black 
> Signed-off-by: Liu Jingqi 
> Signed-off-by: Tao Xu 

with nit below fixed:
 Reviewed-by: Igor Mammedov 



> ---
> 
> Changes in v17:
> - Use NumaHmatCacheOptions to replace HMAT_Cache_Info (Igor)
> - Add check for unordered cache level input (Igor)
> 
> Changes in v16:
> - Add cross check with hmat_lb data (Igor)
> - Drop total_levels in struct HMAT_Cache_Info (Igor)
> - Correct the error table number (Igor)
> 
> Changes in v15:
> - Change the QAPI version tag to 5.0 (Eric)
> ---
>  hw/core/numa.c| 78 +++
>  include/sysemu/numa.h |  5 +++
>  qapi/machine.json | 78 +--
>  qemu-options.hx   | 16 +++--
>  4 files changed, 173 insertions(+), 4 deletions(-)
> 
> diff --git a/hw/core/numa.c b/hw/core/numa.c
> index 70bc8a1081..7b1a9531d2 100644
> --- a/hw/core/numa.c
> +++ b/hw/core/numa.c
> @@ -363,6 +363,71 @@ void parse_numa_hmat_lb(NumaState *numa_state, 
> NumaHmatLBOptions *node,
>  g_array_append_val(hmat_lb->list, lb_data);
>  }
>  
> +void parse_numa_hmat_cache(MachineState *ms, NumaHmatCacheOptions *node,
> +   Error **errp)
> +{
> +int nb_numa_nodes = ms->numa_state->num_nodes;
> +NodeInfo *numa_info = ms->numa_state->nodes;
> +NumaHmatCacheOptions *hmat_cache = NULL;
> +
> +if (node->node_id >= nb_numa_nodes) {
> +error_setg(errp, "Invalid node-id=%" PRIu32 ", it should be less "
> +   "than %d", node->node_id, nb_numa_nodes);
> +return;
> +}
> +
> +if (numa_info[node->node_id].lb_info_provided != (BIT(0) | BIT(1))) {
> +error_setg(errp, "The latency and bandwidth information of "
> +   "node-id=%" PRIu32 " should be provided before memory 
> side "
> +   "cache attributes", node->node_id);
> +return;
> +}
> +
> +if (node->level >= HMAT_LB_LEVELS) {
> +error_setg(errp, "Invalid level=%" PRIu8 ", it should be less than 
> or "
> +   "equal to %d", node->level, HMAT_LB_LEVELS - 1);
> +return;
> +}
> +assert(node->assoc < HMAT_CACHE_ASSOCIATIVITY__MAX);
> +assert(node->policy < HMAT_CACHE_WRITE_POLICY__MAX);
> +if (ms->numa_state->hmat_cache[node->node_id][node->level]) {
> +error_setg(errp, "Duplicate configuration of the side cache for "
> +   "node-id=%" PRIu32 " and level=%" PRIu8,
> +   node->node_id, node->level);
> +return;
> +}
> +
> +if ((node->level > 1) &&
> +ms->numa_state->hmat_cache[node->node_id][node->level - 1] &&
> +(node->size >=
> +ms->numa_state->hmat_cache[node->node_id][node->level - 
> 1]->size)) {
> +error_setg(errp, "Invalid size=%" PRIu64 ", the size of level=%" 
> PRIu8
> +   " should be small than the size(%" PRIu64 ") of "

s/small/less/

> +   "level=%" PRIu8, node->size, node->level,
> +   ms->numa_state->hmat_cache[node->node_id]
> + [node->level - 1]->size,
> +   node->level - 1);
> +return;
> +}
> +
> +if ((node->level < HMAT_LB_LEVELS - 1) &&
> +ms->numa_state->hmat_cache[node->node_id][node->level + 1] &&
> +(node->size <=
> +ms->numa_state->hmat_cache[node->node_id][node->level + 
> 1]->size)) {
> +error_setg(errp, "Invalid size=%" PRIu64 ", the size of level=%" 
> PRIu8
> +   " should be larger than the size(%" PRIu64 ") of "
> +   "level=%" PRIu8, node->size, node->level,
> +   ms->numa_state->hmat_cache[node->node_id]
> + [node->level + 1]->size,
> +   node->level + 1);
> +return;
> +}
> +
> +hmat_cache = g_malloc0(sizeof(*hmat_cache));
> +memcpy(hmat_cache, node, sizeof(*hmat_cache));
> +ms->numa_state->hmat_cache[node->node_id][node->level] = hmat_cache;
> +}
> +
>  void set_numa_options(MachineState *ms, NumaOptions *object, Error **errp)
>  {
>  Error *err = NULL;
> @@ -414,6 +479,19 @@ void set_numa_options(MachineState *ms, NumaOptions 
> *object, Error **errp)
>  goto end;
>  }
>  break;
> +case NUMA_OPTIONS_TYPE_HMAT_CACHE:
> +if (!ms->numa_state->hmat_enabled) {
> +error_setg(errp, "ACPI Heterogeneous Memory Attribute Table "
> +   "(HMAT) is disabled, enable it with -machine hmat=on "
> +   "before using any of hmat specific options");
> +return;
> +  

Re: [PATCH 4/4] s390x: Beautify machine reset

[Janosch Frank]

On 11/22/19 1:10 PM, Cornelia Huck wrote:
> On Fri, 22 Nov 2019 12:47:44 +0100
> David Hildenbrand  wrote:
> 
>> On 22.11.19 12:46, Janosch Frank wrote:
>>> On 11/22/19 11:59 AM, David Hildenbrand wrote:  
 On 22.11.19 08:52, Janosch Frank wrote:  
> * Add comments that tell you which diag308 subcode caused the reset
> * Sort by diag308 reset subcode
>
> Signed-off-by: Janosch Frank 
> ---
>hw/s390x/s390-virtio-ccw.c | 20 ++--
>1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
> index c1d1440272..88f7758721 100644
> --- a/hw/s390x/s390-virtio-ccw.c
> +++ b/hw/s390x/s390-virtio-ccw.c
> @@ -330,15 +330,7 @@ static void s390_machine_reset(MachineState *machine)
>s390_cmma_reset();
>
>switch (reset_type) {
> -case S390_RESET_EXTERNAL:
> -case S390_RESET_REIPL:
> -qemu_devices_reset();
> -s390_crypto_reset();
> -
> -/* configure and start the ipl CPU only */
> -run_on_cpu(cs, s390_do_cpu_ipl, RUN_ON_CPU_NULL);
> -break;
> -case S390_RESET_MODIFIED_CLEAR:
> +case S390_RESET_MODIFIED_CLEAR: /* Subcode 0 */  

 IMHO "Subcode X" isn't of much help here. We're out of diag handling.

 I'd suggest to just document the subcodes along with the definitions, if
 really needed, and drop this patch, at least I don't quite see the value
 of moving code around here... or is the code shuffling of any value on
 your prot virt patches?
  
>>>
>>> It keeps me from consulting the POP every time I need to change things
>>> in the machine resets. This is basically a 1:1 mapping of diag 308
>>> subcodes to machine resets, so why don't we want to make that obvious
>>> and order them by the subcodes?
>>>   
>>
>> Because it is not a 1:1 mapping: S390_RESET_EXTERNAL
>>
> 
> Tack the explanation onto the definitions of S390_RESET_, then?
> Probably still quicker than consulting the POP :)
> 

Does it really bother you that much, that I add some explanations to the
things we're doing. The external reset also gets a comment so Conni
won't need that much coffee anymore to understand the code :-)



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] Remove wrappers

[David Hildenbrand]

On 22.11.19 13:20, Janosch Frank wrote:

That's what it would look like.

Signed-off-by: Janosch Frank 
---
  target/s390x/cpu-qom.h | 12 
  target/s390x/cpu.c | 28 +---
  target/s390x/cpu.h |  8 +---
  target/s390x/sigp.c|  4 ++--
  4 files changed, 20 insertions(+), 32 deletions(-)

diff --git a/target/s390x/cpu-qom.h b/target/s390x/cpu-qom.h
index b809ec8418..e8ec999e77 100644
--- a/target/s390x/cpu-qom.h
+++ b/target/s390x/cpu-qom.h
@@ -34,13 +34,18 @@
  typedef struct S390CPUModel S390CPUModel;
  typedef struct S390CPUDef S390CPUDef;
  
+typedef enum cpu_reset_type {

+S390_CPU_RESET_NORMAL,
+S390_CPU_RESET_INITIAL,
+S390_CPU_RESET_CLEAR,
+} cpu_reset_type;
+
  /**
   * S390CPUClass:
   * @parent_realize: The parent class' realize handler.
   * @parent_reset: The parent class' reset handler.
   * @load_normal: Performs a load normal.
- * @cpu_reset: Performs a CPU reset.
- * @initial_cpu_reset: Performs an initial CPU reset.
+ * @reset: Performs a CPU reset of a given type.
   *
   * An S/390 CPU model.
   */
@@ -57,8 +62,7 @@ typedef struct S390CPUClass {
  DeviceRealize parent_realize;
  void (*parent_reset)(CPUState *cpu);
  void (*load_normal)(CPUState *cpu);
-void (*cpu_reset)(CPUState *cpu);
-void (*initial_cpu_reset)(CPUState *cpu);
+void (*reset)(CPUState *cpu, cpu_reset_type type);
  } S390CPUClass;
  
  typedef struct S390CPU S390CPU;

diff --git a/target/s390x/cpu.c b/target/s390x/cpu.c
index 556afecbc1..970495d042 100644
--- a/target/s390x/cpu.c
+++ b/target/s390x/cpu.c
@@ -82,12 +82,6 @@ static void s390_cpu_load_normal(CPUState *s)
  }
  #endif
  
-typedef enum cpu_reset_type {

-S390_CPU_RESET_NORMAL,
-S390_CPU_RESET_INITIAL,
-S390_CPU_RESET_CLEAR,
-} cpu_reset_type;
-
  static void s390_cpu_reset(CPUState *s, cpu_reset_type type)
  {
  S390CPU *cpu = S390_CPU(s);
@@ -138,21 +132,6 @@ static void s390_cpu_reset(CPUState *s, cpu_reset_type 
type)
  #endif
  }
  
-static void s390_cpu_reset_normal(CPUState *s)

-{
-return s390_cpu_reset(s, S390_CPU_RESET_NORMAL);
-}
-
-static void s390_cpu_reset_initial(CPUState *s)
-{
-return s390_cpu_reset(s, S390_CPU_RESET_INITIAL);
-}
-
-static void s390_cpu_reset_clear(CPUState *s)
-{
-return s390_cpu_reset(s, S390_CPU_RESET_CLEAR);
-}
-
  #if !defined(CONFIG_USER_ONLY)
  static void s390_cpu_machine_reset_cb(void *opaque)
  {
@@ -444,6 +423,11 @@ static Property s390x_cpu_properties[] = {
  DEFINE_PROP_END_OF_LIST()
  };
  
+static void s390_cpu_reset_clear(CPUState *s)

+{
+return s390_cpu_reset(s, S390_CPU_RESET_CLEAR);
+}
+
  static void s390_cpu_class_init(ObjectClass *oc, void *data)
  {
  S390CPUClass *scc = S390_CPU_CLASS(oc);
@@ -459,8 +443,6 @@ static void s390_cpu_class_init(ObjectClass *oc, void *data)
  #if !defined(CONFIG_USER_ONLY)
  scc->load_normal = s390_cpu_load_normal;
  #endif
-scc->cpu_reset = s390_cpu_reset_normal;
-scc->initial_cpu_reset = s390_cpu_reset_initial;


You have to set

scc->reset = s390_cpu_reset;

if I'm not wrong.


  cc->reset = s390_cpu_reset_clear;
  cc->class_by_name = s390_cpu_class_by_name,
  cc->has_work = s390_cpu_has_work;
diff --git a/target/s390x/cpu.h b/target/s390x/cpu.h
index 17460ed7b3..687b31d87e 100644
--- a/target/s390x/cpu.h
+++ b/target/s390x/cpu.h
@@ -734,21 +734,23 @@ static inline uint64_t s390_build_validity_mcic(void)
  
  static inline void s390_do_cpu_full_reset(CPUState *cs, run_on_cpu_data arg)

  {
-cpu_reset(cs);
+S390CPUClass *scc = S390_CPU_GET_CLASS(cs);
+
+scc->reset(cs, S390_CPU_RESET_CLEAR);
  }
  
  static inline void s390_do_cpu_reset(CPUState *cs, run_on_cpu_data arg)

  {
  S390CPUClass *scc = S390_CPU_GET_CLASS(cs);
  
-scc->cpu_reset(cs);

+scc->reset(cs, S390_CPU_RESET_CLEAR);
  }
  
  static inline void s390_do_cpu_initial_reset(CPUState *cs, run_on_cpu_data arg)

  {
  S390CPUClass *scc = S390_CPU_GET_CLASS(cs);
  
-scc->initial_cpu_reset(cs);

+scc->reset(cs, S390_CPU_RESET_INITIAL);
  }
  
  static inline void s390_do_cpu_load_normal(CPUState *cs, run_on_cpu_data arg)

diff --git a/target/s390x/sigp.c b/target/s390x/sigp.c
index 2ce22d4dc1..727875bb4a 100644
--- a/target/s390x/sigp.c
+++ b/target/s390x/sigp.c
@@ -254,7 +254,7 @@ static void sigp_initial_cpu_reset(CPUState *cs, 
run_on_cpu_data arg)
  SigpInfo *si = arg.host_ptr;
  
  cpu_synchronize_state(cs);

-scc->initial_cpu_reset(cs);
+scc->reset(cs, S390_CPU_RESET_INITIAL);
  cpu_synchronize_post_reset(cs);
  si->cc = SIGP_CC_ORDER_CODE_ACCEPTED;
  }
@@ -266,7 +266,7 @@ static void sigp_cpu_reset(CPUState *cs, run_on_cpu_data 
arg)
  SigpInfo *si = arg.host_ptr;
  
  cpu_synchronize_state(cs);

-scc->cpu_reset(cs);
+scc->reset(cs, S390_CPU_RESET_NORMAL);
  cpu_synchronize_post_reset(cs);
  si->cc = SIGP_CC_ORDER_CODE_ACCEPTED;
  }



Looks good and much cleaner to me :)

--

T

Re: [PATCH 4/4] s390x: Beautify machine reset

[David Hildenbrand]

On 22.11.19 13:22, Janosch Frank wrote:

On 11/22/19 1:10 PM, Cornelia Huck wrote:

On Fri, 22 Nov 2019 12:47:44 +0100
David Hildenbrand  wrote:


On 22.11.19 12:46, Janosch Frank wrote:

On 11/22/19 11:59 AM, David Hildenbrand wrote:

On 22.11.19 08:52, Janosch Frank wrote:

* Add comments that tell you which diag308 subcode caused the reset
* Sort by diag308 reset subcode

Signed-off-by: Janosch Frank 
---
hw/s390x/s390-virtio-ccw.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
index c1d1440272..88f7758721 100644
--- a/hw/s390x/s390-virtio-ccw.c
+++ b/hw/s390x/s390-virtio-ccw.c
@@ -330,15 +330,7 @@ static void s390_machine_reset(MachineState *machine)
s390_cmma_reset();

switch (reset_type) {

-case S390_RESET_EXTERNAL:
-case S390_RESET_REIPL:
-qemu_devices_reset();
-s390_crypto_reset();
-
-/* configure and start the ipl CPU only */
-run_on_cpu(cs, s390_do_cpu_ipl, RUN_ON_CPU_NULL);
-break;
-case S390_RESET_MODIFIED_CLEAR:
+case S390_RESET_MODIFIED_CLEAR: /* Subcode 0 */


IMHO "Subcode X" isn't of much help here. We're out of diag handling.

I'd suggest to just document the subcodes along with the definitions, if
really needed, and drop this patch, at least I don't quite see the value
of moving code around here... or is the code shuffling of any value on
your prot virt patches?
  


It keeps me from consulting the POP every time I need to change things
in the machine resets. This is basically a 1:1 mapping of diag 308
subcodes to machine resets, so why don't we want to make that obvious
and order them by the subcodes?
   


Because it is not a 1:1 mapping: S390_RESET_EXTERNAL



Tack the explanation onto the definitions of S390_RESET_, then?
Probably still quicker than consulting the POP :)



Does it really bother you that much, that I add some explanations to the
things we're doing. The external reset also gets a comment so Conni
won't need that much coffee anymore to understand the code :-)



I'm really sorry, but I fail to see how "Subcode 0" is *any* better than 
S390_RESET_MODIFIED_CLEAR (and avoids consulting the PoP) and why the 
order should matter at all here to make it easier to understand.


I don't NACK this, I just find it *completely* useless :)

--

Thanks,

David / dhildenb

Re: [PATCH] Remove wrappers

[Janosch Frank]

On 11/22/19 1:23 PM, David Hildenbrand wrote:
> On 22.11.19 13:20, Janosch Frank wrote:
>> That's what it would look like.
>>
>> Signed-off-by: Janosch Frank 
>> ---
>>   target/s390x/cpu-qom.h | 12 
>>   target/s390x/cpu.c | 28 +---
>>   target/s390x/cpu.h |  8 +---
>>   target/s390x/sigp.c|  4 ++--
>>   4 files changed, 20 insertions(+), 32 deletions(-)
>>
>> diff --git a/target/s390x/cpu-qom.h b/target/s390x/cpu-qom.h
>> index b809ec8418..e8ec999e77 100644
>> --- a/target/s390x/cpu-qom.h
>> +++ b/target/s390x/cpu-qom.h
>> @@ -34,13 +34,18 @@
>>   typedef struct S390CPUModel S390CPUModel;
>>   typedef struct S390CPUDef S390CPUDef;
>>   
>> +typedef enum cpu_reset_type {
>> +S390_CPU_RESET_NORMAL,
>> +S390_CPU_RESET_INITIAL,
>> +S390_CPU_RESET_CLEAR,
>> +} cpu_reset_type;
>> +
>>   /**
>>* S390CPUClass:
>>* @parent_realize: The parent class' realize handler.
>>* @parent_reset: The parent class' reset handler.
>>* @load_normal: Performs a load normal.
>> - * @cpu_reset: Performs a CPU reset.
>> - * @initial_cpu_reset: Performs an initial CPU reset.
>> + * @reset: Performs a CPU reset of a given type.
>>*
>>* An S/390 CPU model.
>>*/
>> @@ -57,8 +62,7 @@ typedef struct S390CPUClass {
>>   DeviceRealize parent_realize;
>>   void (*parent_reset)(CPUState *cpu);
>>   void (*load_normal)(CPUState *cpu);
>> -void (*cpu_reset)(CPUState *cpu);
>> -void (*initial_cpu_reset)(CPUState *cpu);
>> +void (*reset)(CPUState *cpu, cpu_reset_type type);
>>   } S390CPUClass;
>>   
>>   typedef struct S390CPU S390CPU;
>> diff --git a/target/s390x/cpu.c b/target/s390x/cpu.c
>> index 556afecbc1..970495d042 100644
>> --- a/target/s390x/cpu.c
>> +++ b/target/s390x/cpu.c
>> @@ -82,12 +82,6 @@ static void s390_cpu_load_normal(CPUState *s)
>>   }
>>   #endif
>>   
>> -typedef enum cpu_reset_type {
>> -S390_CPU_RESET_NORMAL,
>> -S390_CPU_RESET_INITIAL,
>> -S390_CPU_RESET_CLEAR,
>> -} cpu_reset_type;
>> -
>>   static void s390_cpu_reset(CPUState *s, cpu_reset_type type)
>>   {
>>   S390CPU *cpu = S390_CPU(s);
>> @@ -138,21 +132,6 @@ static void s390_cpu_reset(CPUState *s, cpu_reset_type 
>> type)
>>   #endif
>>   }
>>   
>> -static void s390_cpu_reset_normal(CPUState *s)
>> -{
>> -return s390_cpu_reset(s, S390_CPU_RESET_NORMAL);
>> -}
>> -
>> -static void s390_cpu_reset_initial(CPUState *s)
>> -{
>> -return s390_cpu_reset(s, S390_CPU_RESET_INITIAL);
>> -}
>> -
>> -static void s390_cpu_reset_clear(CPUState *s)
>> -{
>> -return s390_cpu_reset(s, S390_CPU_RESET_CLEAR);
>> -}
>> -
>>   #if !defined(CONFIG_USER_ONLY)
>>   static void s390_cpu_machine_reset_cb(void *opaque)
>>   {
>> @@ -444,6 +423,11 @@ static Property s390x_cpu_properties[] = {
>>   DEFINE_PROP_END_OF_LIST()
>>   };
>>   
>> +static void s390_cpu_reset_clear(CPUState *s)
>> +{
>> +return s390_cpu_reset(s, S390_CPU_RESET_CLEAR);
>> +}
>> +
>>   static void s390_cpu_class_init(ObjectClass *oc, void *data)
>>   {
>>   S390CPUClass *scc = S390_CPU_CLASS(oc);
>> @@ -459,8 +443,6 @@ static void s390_cpu_class_init(ObjectClass *oc, void 
>> *data)
>>   #if !defined(CONFIG_USER_ONLY)
>>   scc->load_normal = s390_cpu_load_normal;
>>   #endif
>> -scc->cpu_reset = s390_cpu_reset_normal;
>> -scc->initial_cpu_reset = s390_cpu_reset_initial;
> 
> You have to set
> 
> scc->reset = s390_cpu_reset;
> 
> if I'm not wrong.

Yeah, that would make sense :)
I'm also going to tripple check if we are doing the right resets.


> 
>>   cc->reset = s390_cpu_reset_clear;
>>   cc->class_by_name = s390_cpu_class_by_name,
>>   cc->has_work = s390_cpu_has_work;
>> diff --git a/target/s390x/cpu.h b/target/s390x/cpu.h
>> index 17460ed7b3..687b31d87e 100644
>> --- a/target/s390x/cpu.h
>> +++ b/target/s390x/cpu.h
>> @@ -734,21 +734,23 @@ static inline uint64_t s390_build_validity_mcic(void)
>>   
>>   static inline void s390_do_cpu_full_reset(CPUState *cs, run_on_cpu_data 
>> arg)
>>   {
>> -cpu_reset(cs);
>> +S390CPUClass *scc = S390_CPU_GET_CLASS(cs);
>> +
>> +scc->reset(cs, S390_CPU_RESET_CLEAR);
>>   }
>>   
>>   static inline void s390_do_cpu_reset(CPUState *cs, run_on_cpu_data arg)
>>   {
>>   S390CPUClass *scc = S390_CPU_GET_CLASS(cs);
>>   
>> -scc->cpu_reset(cs);
>> +scc->reset(cs, S390_CPU_RESET_CLEAR);
>>   }
>>   
>>   static inline void s390_do_cpu_initial_reset(CPUState *cs, run_on_cpu_data 
>> arg)
>>   {
>>   S390CPUClass *scc = S390_CPU_GET_CLASS(cs);
>>   
>> -scc->initial_cpu_reset(cs);
>> +scc->reset(cs, S390_CPU_RESET_INITIAL);
>>   }
>>   
>>   static inline void s390_do_cpu_load_normal(CPUState *cs, run_on_cpu_data 
>> arg)
>> diff --git a/target/s390x/sigp.c b/target/s390x/sigp.c
>> index 2ce22d4dc1..727875bb4a 100644
>> --- a/target/s390x/sigp.c
>> +++ b/target/s390x/sigp.c
>> @@ -254,7 +254,7 @@ static void sigp_initial_cpu_reset(CPUState *cs, 
>> run_on_cpu_data arg)
>>

Re: [PATCH 4/4] s390x: Beautify machine reset

[Janosch Frank]

On 11/22/19 1:25 PM, David Hildenbrand wrote:
> On 22.11.19 13:22, Janosch Frank wrote:
>> On 11/22/19 1:10 PM, Cornelia Huck wrote:
>>> On Fri, 22 Nov 2019 12:47:44 +0100
>>> David Hildenbrand  wrote:
>>>
 On 22.11.19 12:46, Janosch Frank wrote:
> On 11/22/19 11:59 AM, David Hildenbrand wrote:
>> On 22.11.19 08:52, Janosch Frank wrote:
>>> * Add comments that tell you which diag308 subcode caused the reset
>>> * Sort by diag308 reset subcode
>>>
>>> Signed-off-by: Janosch Frank 
>>> ---
>>> hw/s390x/s390-virtio-ccw.c | 20 ++--
>>> 1 file changed, 10 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
>>> index c1d1440272..88f7758721 100644
>>> --- a/hw/s390x/s390-virtio-ccw.c
>>> +++ b/hw/s390x/s390-virtio-ccw.c
>>> @@ -330,15 +330,7 @@ static void s390_machine_reset(MachineState 
>>> *machine)
>>> s390_cmma_reset();
>>> 
>>> switch (reset_type) {
>>> -case S390_RESET_EXTERNAL:
>>> -case S390_RESET_REIPL:
>>> -qemu_devices_reset();
>>> -s390_crypto_reset();
>>> -
>>> -/* configure and start the ipl CPU only */
>>> -run_on_cpu(cs, s390_do_cpu_ipl, RUN_ON_CPU_NULL);
>>> -break;
>>> -case S390_RESET_MODIFIED_CLEAR:
>>> +case S390_RESET_MODIFIED_CLEAR: /* Subcode 0 */
>>
>> IMHO "Subcode X" isn't of much help here. We're out of diag handling.
>>
>> I'd suggest to just document the subcodes along with the definitions, if
>> really needed, and drop this patch, at least I don't quite see the value
>> of moving code around here... or is the code shuffling of any value on
>> your prot virt patches?
>>   
>
> It keeps me from consulting the POP every time I need to change things
> in the machine resets. This is basically a 1:1 mapping of diag 308
> subcodes to machine resets, so why don't we want to make that obvious
> and order them by the subcodes?
>

 Because it is not a 1:1 mapping: S390_RESET_EXTERNAL

>>>
>>> Tack the explanation onto the definitions of S390_RESET_, then?
>>> Probably still quicker than consulting the POP :)
>>>
>>
>> Does it really bother you that much, that I add some explanations to the
>> things we're doing. The external reset also gets a comment so Conni
>> won't need that much coffee anymore to understand the code :-)
>>
> 
> I'm really sorry, but I fail to see how "Subcode 0" is *any* better than 
> S390_RESET_MODIFIED_CLEAR (and avoids consulting the PoP) and why the 
> order should matter at all here to make it easier to understand.
> 
> I don't NACK this, I just find it *completely* useless :)
> 

Ugh, time for some rebase conflicts...



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v17 12/14] hmat acpi: Build Memory Side Cache Information Structure(s)

[Igor Mammedov]

On Fri, 22 Nov 2019 15:48:24 +0800
Tao Xu  wrote:

> From: Liu Jingqi 
> 
> This structure describes memory side cache information for memory
> proximity domains if the memory side cache is present and the
> physical device forms the memory side cache.
> The software could use this information to effectively place
> the data in memory to maximize the performance of the system
> memory that use the memory side cache.
> 
> Reviewed-by: Daniel Black 
> Reviewed-by: Jonathan Cameron 

for the future reference,
You are not supposed to carry over Reviewed-by tags
if you do non trivial change to the patch.

> Signed-off-by: Liu Jingqi 
> Signed-off-by: Tao Xu 

Reviewed-by: Igor Mammedov 

> ---
> 
> No changes in v17.
> 
> Changes in v16:
> - Use checks and assert to replace masks (Igor)
> - Fields in Cache Attributes are promoted to uint32_t before
>   shifting (Igor)
> - Drop cpu_to_le32() (Igor)
> 
> Changes in v13:
> - rename level as cache_level
> ---
>  hw/acpi/hmat.c | 69 +-
>  1 file changed, 68 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/acpi/hmat.c b/hw/acpi/hmat.c
> index e5ee8b4317..bb6adb0ccf 100644
> --- a/hw/acpi/hmat.c
> +++ b/hw/acpi/hmat.c
> @@ -143,14 +143,62 @@ static void build_hmat_lb(GArray *table_data, 
> HMAT_LB_Info *hmat_lb,
>  g_free(entry_list);
>  }
>  
> +/* ACPI 6.3: 5.2.27.5 Memory Side Cache Information Structure: Table 5-147 */
> +static void build_hmat_cache(GArray *table_data, uint8_t total_levels,
> + NumaHmatCacheOptions *hmat_cache)
> +{
> +/*
> + * Cache Attributes: Bits [3:0] – Total Cache Levels
> + * for this Memory Proximity Domain
> + */
> +uint32_t cache_attr = total_levels;
> +
> +/* Bits [7:4] : Cache Level described in this structure */
> +cache_attr |= (uint32_t) hmat_cache->level << 4;
> +
> +/* Bits [11:8] - Cache Associativity */
> +cache_attr |= (uint32_t) hmat_cache->assoc << 8;
> +
> +/* Bits [15:12] - Write Policy */
> +cache_attr |= (uint32_t) hmat_cache->policy << 12;
> +
> +/* Bits [31:16] - Cache Line size in bytes */
> +cache_attr |= (uint32_t) hmat_cache->line << 16;
> +
> +/* Type */
> +build_append_int_noprefix(table_data, 2, 2);
> +/* Reserved */
> +build_append_int_noprefix(table_data, 0, 2);
> +/* Length */
> +build_append_int_noprefix(table_data, 32, 4);
> +/* Proximity Domain for the Memory */
> +build_append_int_noprefix(table_data, hmat_cache->node_id, 4);
> +/* Reserved */
> +build_append_int_noprefix(table_data, 0, 4);
> +/* Memory Side Cache Size */
> +build_append_int_noprefix(table_data, hmat_cache->size, 8);
> +/* Cache Attributes */
> +build_append_int_noprefix(table_data, cache_attr, 4);
> +/* Reserved */
> +build_append_int_noprefix(table_data, 0, 2);
> +/*
> + * Number of SMBIOS handles (n)
> + * Linux kernel uses Memory Side Cache Information Structure
> + * without SMBIOS entries for now, so set Number of SMBIOS handles
> + * as 0.
> + */
> +build_append_int_noprefix(table_data, 0, 2);
> +}
> +
>  /* Build HMAT sub table structures */
>  static void hmat_build_table_structs(GArray *table_data, NumaState 
> *numa_state)
>  {
>  uint16_t flags;
>  uint32_t num_initiator = 0;
>  uint32_t initiator_list[MAX_NODES];
> -int i, hierarchy, type;
> +int i, hierarchy, type, cache_level, total_levels;
>  HMAT_LB_Info *hmat_lb;
> +NumaHmatCacheOptions *hmat_cache;
>  
>  for (i = 0; i < numa_state->num_nodes; i++) {
>  flags = 0;
> @@ -184,6 +232,25 @@ static void hmat_build_table_structs(GArray *table_data, 
> NumaState *numa_state)
>  }
>  }
>  }
> +
> +/*
> + * ACPI 6.3: 5.2.27.5 Memory Side Cache Information Structure:
> + * Table 5-147
> + */
> +for (i = 0; i < numa_state->num_nodes; i++) {
> +total_levels = 0;
> +for (cache_level = 1; cache_level < HMAT_LB_LEVELS; cache_level++) {
> +if (numa_state->hmat_cache[i][cache_level]) {
> +total_levels++;
> +}
> +}
> +for (cache_level = 0; cache_level <= total_levels; cache_level++) {
> +hmat_cache = numa_state->hmat_cache[i][cache_level];
> +if (hmat_cache) {
> +build_hmat_cache(table_data, total_levels, hmat_cache);
> +}
> +}
> +}
>  }
>  
>  void build_hmat(GArray *table_data, BIOSLinker *linker, NumaState 
> *numa_state)

Re: [PATCH v17 00/14] Build ACPI Heterogeneous Memory Attribute Table (HMAT)

[Igor Mammedov]

On Fri, 22 Nov 2019 01:17:12 -0800 (PST)
no-re...@patchew.org wrote:

> Patchew URL: https://patchew.org/QEMU/20191122074826.1373-1-tao3...@intel.com/
> 
do not ignore warnings "line over 80 characters",
just fix them

> 
> Hi,
> 
> This series seems to have some coding style problems. See output below for
> more information:
> 
> Subject: [PATCH v17 00/14] Build ACPI Heterogeneous Memory Attribute Table 
> (HMAT)
> Type: series
> Message-id: 20191122074826.1373-1-tao3...@intel.com
> 
> === 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
>  - [tag update]  
> patchew/20191121000843.24844-1-beata.michal...@linaro.org -> 
> patchew/20191121000843.24844-1-beata.michal...@linaro.org
>  - [tag update]  patchew/20191122080039.12771-1-arm...@redhat.com -> 
> patchew/20191122080039.12771-1-arm...@redhat.com
> Switched to a new branch 'test'
> 9192aa6 tests/bios-tables-test: add test cases for ACPI HMAT
> 309fd85 tests/numa: Add case for QMP build HMAT
> 864da49 hmat acpi: Build Memory Side Cache Information Structure(s)
> 6d92931 hmat acpi: Build System Locality Latency and Bandwidth Information 
> Structure(s)
> 39ba308 hmat acpi: Build Memory Proximity Domain Attributes Structure(s)
> 7d0bffc numa: Extend CLI to provide memory side cache information
> 3fc8a54 numa: Extend CLI to provide memory latency and bandwidth information
> 592a96a numa: Extend CLI to provide initiator information for numa nodes
> 7032fc4 tests: Add test for QAPI builtin type time
> 2d89c93 qapi: Add builtin type time
> dbe82f5 util/cutils: Add qemu_strtotime_ns()
> 2fef66f util/cutils: refactor do_strtosz() to support suffixes list
> 2cae457 util/cutils: Use qemu_strtold_finite to parse size
> a691b5f util/cutils: Add Add qemu_strtold and qemu_strtold_finite
> 
> === OUTPUT BEGIN ===
> 1/14 Checking commit a691b5f92191 (util/cutils: Add Add qemu_strtold and 
> qemu_strtold_finite)
> ERROR: consider using qemu_strtold in preference to strtold
> #61: FILE: util/cutils.c:636:
> +*result = strtold(nptr, &ep);
> 
> total: 1 errors, 0 warnings, 69 lines checked
> 
> Patch 1/14 has style problems, please review.  If any of these errors
> are false positives report them to the maintainer, see
> CHECKPATCH in MAINTAINERS.
> 
> 2/14 Checking commit 2cae457669b9 (util/cutils: Use qemu_strtold_finite to 
> parse size)
> 3/14 Checking commit 2fef66fd2a82 (util/cutils: refactor do_strtosz() to 
> support suffixes list)
> 4/14 Checking commit dbe82f50cf86 (util/cutils: Add qemu_strtotime_ns())
> 5/14 Checking commit 2d89c9350115 (qapi: Add builtin type time)
> 6/14 Checking commit 7032fc4756a0 (tests: Add test for QAPI builtin type time)
> 7/14 Checking commit 592a96a0ff21 (numa: Extend CLI to provide initiator 
> information for numa nodes)
> 8/14 Checking commit 3fc8a542a4b7 (numa: Extend CLI to provide memory latency 
> and bandwidth information)
> WARNING: line over 80 characters
> #130: FILE: hw/core/numa.c:299:
> +/* Set lb_info_provided bit 0 as 1, latency information is 
> provided */
> 
> total: 0 errors, 1 warnings, 462 lines checked
> 
> Patch 8/14 has style problems, please review.  If any of these errors
> are false positives report them to the maintainer, see
> CHECKPATCH in MAINTAINERS.
> 9/14 Checking commit 7d0bffca6382 (numa: Extend CLI to provide memory side 
> cache information)
> 10/14 Checking commit 39ba308b5612 (hmat acpi: Build Memory Proximity Domain 
> Attributes Structure(s))
> WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
> #72: 
> new file mode 100644
> 
> total: 0 errors, 1 warnings, 185 lines checked
> 
> Patch 10/14 has style problems, please review.  If any of these errors
> are false positives report them to the maintainer, see
> CHECKPATCH in MAINTAINERS.
> 11/14 Checking commit 6d92931a0a40 (hmat acpi: Build System Locality Latency 
> and Bandwidth Information Structure(s))
> 12/14 Checking commit 864da49c0ce4 (hmat acpi: Build Memory Side Cache 
> Information Structure(s))
> 13/14 Checking commit 309fd85d39fc (tests/numa: Add case for QMP build HMAT)
> WARNING: line over 80 characters
> #124: FILE: tests/numa-test.c:433:
> +g_assert(!qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'x-exit-preconfig' 
> }")));
> 
> WARNING: line over 80 characters
> #159: FILE: tests/numa-test.c:468:
> +g_assert(!qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'x-exit-preconfig' 
> }")));
> 
> WARNING: line over 80 characters
> #206: FILE: tests/numa-test.c:515:
> +g_assert(!qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'x-exit-preconfig' 
> }")));
> 
> total: 0 errors, 3 warnings, 206 lines checked
> 
> Patch 13/14 has style problems, please review.  If any of t

Re: [PATCH 4/4] s390x: Beautify machine reset

[David Hildenbrand]

On 22.11.19 08:52, Janosch Frank wrote:
> * Add comments that tell you which diag308 subcode caused the reset
> * Sort by diag308 reset subcode
> 
> Signed-off-by: Janosch Frank 
> ---
>  hw/s390x/s390-virtio-ccw.c | 20 ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
> index c1d1440272..88f7758721 100644
> --- a/hw/s390x/s390-virtio-ccw.c
> +++ b/hw/s390x/s390-virtio-ccw.c
> @@ -330,15 +330,7 @@ static void s390_machine_reset(MachineState *machine)
>  s390_cmma_reset();
>  
>  switch (reset_type) {
> -case S390_RESET_EXTERNAL:
> -case S390_RESET_REIPL:
> -qemu_devices_reset();
> -s390_crypto_reset();
> -
> -/* configure and start the ipl CPU only */
> -run_on_cpu(cs, s390_do_cpu_ipl, RUN_ON_CPU_NULL);
> -break;
> -case S390_RESET_MODIFIED_CLEAR:
> +case S390_RESET_MODIFIED_CLEAR: /* Subcode 0 */
>  CPU_FOREACH(t) {
>  run_on_cpu(t, s390_do_cpu_full_reset, RUN_ON_CPU_NULL);
>  }
> @@ -346,7 +338,7 @@ static void s390_machine_reset(MachineState *machine)
>  s390_crypto_reset();
>  run_on_cpu(cs, s390_do_cpu_load_normal, RUN_ON_CPU_NULL);
>  break;
> -case S390_RESET_LOAD_NORMAL:
> +case S390_RESET_LOAD_NORMAL: /* Subcode 1 */
>  CPU_FOREACH(t) {
>  if (t == cs) {
>  continue;
> @@ -357,6 +349,14 @@ static void s390_machine_reset(MachineState *machine)
>  run_on_cpu(cs, s390_do_cpu_initial_reset, RUN_ON_CPU_NULL);
>  run_on_cpu(cs, s390_do_cpu_load_normal, RUN_ON_CPU_NULL);
>  break;
> +case S390_RESET_EXTERNAL: /* Externally triggered reboot */

BTW, if we decide to document this *somehow*, S390_RESET_EXTERNAL is
also used via the diag288 watchdog.

-- 

Thanks,

David / dhildenb

Re: [PATCH v17 13/14] tests/numa: Add case for QMP build HMAT

[Igor Mammedov]

On Fri, 22 Nov 2019 15:48:25 +0800
Tao Xu  wrote:

> Check configuring HMAT usecase
> 
> Suggested-by: Igor Mammedov 
> Signed-off-by: Tao Xu 

Reviewed-by: Igor Mammedov 

> ---
> 
> Chenges in v17:
> - Add some fail test cases (Igor)
> ---
>  tests/numa-test.c | 194 ++
>  1 file changed, 194 insertions(+)
> 
> diff --git a/tests/numa-test.c b/tests/numa-test.c
> index 8de8581231..9c69da973c 100644
> --- a/tests/numa-test.c
> +++ b/tests/numa-test.c
> @@ -327,6 +327,197 @@ static void pc_dynamic_cpu_cfg(const void *data)
>  qtest_quit(qs);
>  }
>  
> +static void pc_hmat_build_cfg(const void *data)
> +{
> +QTestState *qs = qtest_initf("%s -nodefaults --preconfig -machine 
> hmat=on "
> + "-smp 2,sockets=2 "
> + "-m 128M,slots=2,maxmem=1G "
> + "-object memory-backend-ram,size=64M,id=m0 "
> + "-object memory-backend-ram,size=64M,id=m1 "
> + "-numa node,nodeid=0,memdev=m0 "
> + "-numa node,nodeid=1,memdev=m1,initiator=0 "
> + "-numa cpu,node-id=0,socket-id=0 "
> + "-numa cpu,node-id=0,socket-id=1",
> + data ? (char *)data : "");
> +
> +/* Fail: Initiator should be less than the number of nodes */
> +g_assert(qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
> +" 'arguments': { 'type': 'hmat-lb', 'initiator': 2, 'target': 0,"
> +" 'hierarchy': \"memory\", 'data-type': \"access-latency\" } }")));
> +
> +/* Fail: Target should be less than the number of nodes */
> +g_assert(qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
> +" 'arguments': { 'type': 'hmat-lb', 'initiator': 0, 'target': 2,"
> +" 'hierarchy': \"memory\", 'data-type': \"access-latency\" } }")));
> +
> +/* Fail: Initiator should contain cpu */
> +g_assert(qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
> +" 'arguments': { 'type': 'hmat-lb', 'initiator': 1, 'target': 0,"
> +" 'hierarchy': \"memory\", 'data-type': \"access-latency\" } }")));
> +
> +/* Fail: Data-type mismatch */
> +g_assert(qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
> +" 'arguments': { 'type': 'hmat-lb', 'initiator': 0, 'target': 0,"
> +" 'hierarchy': \"memory\", 'data-type': \"write-latency\","
> +" 'bandwidth': 524288000 } }")));
> +g_assert(qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
> +" 'arguments': { 'type': 'hmat-lb', 'initiator': 0, 'target': 0,"
> +" 'hierarchy': \"memory\", 'data-type': \"read-bandwidth\","
> +" 'latency': 5 } }")));
> +
> +/* Fail: Bandwidth should be 1MB (1048576) aligned */
> +g_assert(qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
> +" 'arguments': { 'type': 'hmat-lb', 'initiator': 0, 'target': 0,"
> +" 'hierarchy': \"memory\", 'data-type': \"access-bandwidth\","
> +" 'bandwidth': 1048575 } }")));
> +
> +/* Configuring HMAT bandwidth and latency details */
> +g_assert(!qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
> +" 'arguments': { 'type': 'hmat-lb', 'initiator': 0, 'target': 0,"
> +" 'hierarchy': \"memory\", 'data-type': \"access-latency\","
> +" 'latency': 1 } }")));/* 1 ns */
> +g_assert(qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
> +" 'arguments': { 'type': 'hmat-lb', 'initiator': 0, 'target': 0,"
> +" 'hierarchy': \"memory\", 'data-type': \"access-latency\","
> +" 'latency': 5 } }")));/* Fail: Duplicate configuration */
> +g_assert(!qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
> +" 'arguments': { 'type': 'hmat-lb', 'initiator': 0, 'target': 0,"
> +" 'hierarchy': \"memory\", 'data-type': \"access-bandwidth\","
> +" 'bandwidth': 68717379584 } }")));/* 65534 MB/s */
> +g_assert(!qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
> +" 'arguments': { 'type': 'hmat-lb', 'initiator': 0, 'target': 1,"
> +" 'hierarchy': \"memory\", 'data-type': \"access-latency\","
> +" 'latency': 65534 } }")));/* 65534 ns */
> +g_assert(!qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
> +" 'arguments': { 'type': 'hmat-lb', 'initiator': 0, 'target': 1,"
> +" 'hierarchy': \"memory\", 'data-type': \"access-bandwidth\","
> +" 'bandwidth': 34358689792 } }")));/* 32767 MB/s */
> +
> +/* Fail: node_id should be less than the number of nodes */
> +g_assert(qmp_rsp_is_err(qtest_qmp(qs, "{ 'execute': 'set-numa-node',"
> +" 'arguments': { 'type': 'hmat-cache', 'node-id': 2, 'size': 10240,"
> +" 'level': 1, 'assoc': \"direct\", 'policy': \"write-back\","
> +" 'line': 8 } }")));
> +
> +/* Fail: level should be less than HMAT_LB_LEVELS (4) */

Re: [PATCH 1/6] iotests: Skip test 060 if it is not possible to create large files

[Alex Bennée]

Thomas Huth  writes:

> Test 060 fails in the arm64, s390x and ppc64le LXD containers, which
> apparently do not allow large files to be created. The repair process
> in test 060 creates a file of 64 GiB, so test first whether such large
> files are possible and skip the test if that's not the case.
>
> Signed-off-by: Thomas Huth 

Reviewed-by: Alex Bennée 

> ---
>  tests/qemu-iotests/060 | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/tests/qemu-iotests/060 b/tests/qemu-iotests/060
> index b91d8321bb..e7ee865c55 100755
> --- a/tests/qemu-iotests/060
> +++ b/tests/qemu-iotests/060
> @@ -49,6 +49,12 @@ _supported_fmt qcow2
>  _supported_proto file
>  _supported_os Linux
>  
> +# The repair process will create a large file - so check for availability 
> first
> +if ! truncate --size=64G "$TEST_IMG"; then
> +_notrun "file system on $TEST_DIR does not support large enough files"
> +fi
> +rm "$TEST_IMG"
> +
>  rt_offset=65536  # 0x1 (XXX: just an assumption)
>  rb_offset=131072 # 0x2 (XXX: just an assumption)
>  l1_offset=196608 # 0x3 (XXX: just an assumption)


-- 
Alex Bennée

Re: [PATCH 2/6] iotests: Skip test 079 if it is not possible to create large files

[Alex Bennée]

Thomas Huth  writes:

> Test 079 fails in the arm64, s390x and ppc64le LXD containers, which
> apparently do not allow large files to be created. Test 079 tries to
> create a 4G sparse file, so check first whether we can really create
> such files before executing the test.
>
> Signed-off-by: Thomas Huth 
> ---
>  tests/qemu-iotests/079 | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/tests/qemu-iotests/079 b/tests/qemu-iotests/079
> index 81f0c21f53..e9b81419b7 100755
> --- a/tests/qemu-iotests/079
> +++ b/tests/qemu-iotests/079
> @@ -39,6 +39,12 @@ trap "_cleanup; exit \$status" 0 1 2 3 15
>  _supported_fmt qcow2
>  _supported_proto file nfs
>  
> +# Some containers (e.g. non-x86 on Travis) do not allow large files
> +if ! truncate --size=4G "$TEST_IMG"; then
> +_notrun "file system on $TEST_DIR does not support large enough files"
> +fi
> +rm "$TEST_IMG"
> +

Hmm we are repeating ourselves here. Maybe the test should be wrapped up
as __supported_filesize and the test can just do:

  __supported_filesize 4G

along with the other tests above.

-- 
Alex Bennée

Re: [PATCH] virtiofsd: fix libfuse information leaks

[Philippe Mathieu-Daudé]

On 11/22/19 12:31 PM, Stefan Hajnoczi wrote:

Some FUSE message replies contain padding fields that are not
initialized by libfuse.  This is fine in traditional FUSE applications
because the kernel is trusted.  virtiofsd does not trust the guest and
must not expose uninitialized memory.

Use C struct initializers to automatically zero out memory.  Not all of
these code changes are strictly necessary but they will prevent future
information leaks if the structs are extended.

Signed-off-by: Stefan Hajnoczi 


Nice cleanup.
Reviewed-by: Philippe Mathieu-Daudé 

Re: [PATCH v1 3/3] tests/vm/ubuntu: update i386 image to 18.04

[Alex Bennée]

Philippe Mathieu-Daudé  writes:

> On 11/22/19 12:22 PM, Alex Bennée wrote:
>> The current image is broken while running qtests but the bug go away
>> when built with a newer Ubuntu i386 image. I was unable to replicate
>> the crash on Debian Buster for i386 either so I'm concluding it is a
>> distro problem. Let's paper over that crack by updating our 32 bir
>
> typo "our 32 bit"
>
>> test image.
>> Signed-off-by: Alex Bennée 
>> ---
>>   tests/vm/ubuntu.i386 | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>> diff --git a/tests/vm/ubuntu.i386 b/tests/vm/ubuntu.i386
>> index 18b1ea2b72c..f611bebdc9d 100755
>> --- a/tests/vm/ubuntu.i386
>> +++ b/tests/vm/ubuntu.i386
>> @@ -66,8 +66,8 @@ class UbuntuX86VM(basevm.BaseVM):
>> def build_image(self, img):
>>   cimg = self._download_with_cache(
>> -
>> "https://cloud-images.ubuntu.com/releases/16.04/release-20190605/ubuntu-16.04-server-cloudimg-i386-disk1.img";,
>> -
>> sha256sum="e30091144c73483822b7c27193e9d47346dd1064229da577c3fedcf943f7cfcc")
>
> This one is in QCow2 format.
>
>> +
>> "https://cloud-images.ubuntu.com/releases/bionic/release-20191114/ubuntu-18.04-server-cloudimg-i386.img";,
>> +
>> sha256sum="28969840626d1ea80bb249c08eef1a4533e8904aa51a327b40f37ac4b4ff04ef")
>
> This one is announced as USB format (ISO) but is in QCow2 format too...
>

heh I never noticed. It worked though ;-)

> Using '18.04' instead of 'bionic' in the URL is not important because
> the information is also in the filename.
>
> Reviewed-by: Philippe Mathieu-Daudé 

Thanks.

>
>>   img_tmp = img + ".tmp"
>>   subprocess.check_call(["cp", "-f", cimg, img_tmp])
>>   subprocess.check_call(["qemu-img", "resize", img_tmp, "50G"])
>> 


-- 
Alex Bennée

Re: [PATCH 2/4] s390x: Cleanup cpu resets

[Janosch Frank]

On 11/22/19 11:35 AM, Philippe Mathieu-Daudé wrote:
> Hi Janosh,
> 
> On 11/22/19 8:52 AM, Janosch Frank wrote:
>> Let's move the resets into one function and switch by type, so we can
>> use fallthroughs for shared reset actions.
>>
>> Signed-off-by: Janosch Frank 
>> ---
>>   target/s390x/cpu.c | 110 -
>>   1 file changed, 48 insertions(+), 62 deletions(-)
>>
>> diff --git a/target/s390x/cpu.c b/target/s390x/cpu.c
>> index 3abe7e80fd..556afecbc1 100644
>> --- a/target/s390x/cpu.c
>> +++ b/target/s390x/cpu.c
>> @@ -82,67 +82,52 @@ static void s390_cpu_load_normal(CPUState *s)
>>   }
>>   #endif
>>   
>> -/* S390CPUClass::cpu_reset() */
>> -static void s390_cpu_reset(CPUState *s)
>> +typedef enum cpu_reset_type {
>> +S390_CPU_RESET_NORMAL,
>> +S390_CPU_RESET_INITIAL,
>> +S390_CPU_RESET_CLEAR,
>> +} cpu_reset_type;
>> +
>> +static void s390_cpu_reset(CPUState *s, cpu_reset_type type)
>>   {
>>   S390CPU *cpu = S390_CPU(s);
>>   S390CPUClass *scc = S390_CPU_GET_CLASS(cpu);
>>   CPUS390XState *env = &cpu->env;
>>   
>> -env->pfault_token = -1UL;
>> -env->bpbc = false;
>>   scc->parent_reset(s);
>>   cpu->env.sigp_order = 0;
>>   s390_cpu_set_state(S390_CPU_STATE_STOPPED, cpu);
>> -}
>>   
>> -/* S390CPUClass::initial_reset() */
>> -static void s390_cpu_initial_reset(CPUState *s)
>> -{
>> -S390CPU *cpu = S390_CPU(s);
>> -CPUS390XState *env = &cpu->env;
>> +/* Set initial values after clearing */
>> +switch (type) {
>> +case S390_CPU_RESET_CLEAR:
>> +memset(env, 0, offsetof(CPUS390XState, start_initial_reset_fields));
>> +/* Fallthrough */
>> +case S390_CPU_RESET_INITIAL:
>> +memset(&env->start_initial_reset_fields, 0,
>> +   offsetof(CPUS390XState, end_reset_fields) -
>> +   offsetof(CPUS390XState, start_initial_reset_fields));
>> +/* architectured initial values for CR 0 and 14 */
>> +env->cregs[0] = CR0_RESET;
>> +env->cregs[14] = CR14_RESET;
>>   
>> -s390_cpu_reset(s);
>> -/* initial reset does not clear everything! */
>> -memset(&env->start_initial_reset_fields, 0,
>> -offsetof(CPUS390XState, end_reset_fields) -
>> -offsetof(CPUS390XState, start_initial_reset_fields));
>> -
>> -/* architectured initial values for CR 0 and 14 */
>> -env->cregs[0] = CR0_RESET;
>> -env->cregs[14] = CR14_RESET;
>> -
>> -/* architectured initial value for Breaking-Event-Address register */
>> -env->gbea = 1;
>> -
>> -env->pfault_token = -1UL;
>> -
>> -/* tininess for underflow is detected before rounding */
>> -set_float_detect_tininess(float_tininess_before_rounding,
>> -  &env->fpu_status);
>> +/* architectured initial value for Breaking-Event-Address register 
>> */
>> +env->gbea = 1;
>> +/* tininess for underflow is detected before rounding */
>> +set_float_detect_tininess(float_tininess_before_rounding,
>> +  &env->fpu_status);
>> +/* Fallthrough */
>> +case S390_CPU_RESET_NORMAL:
>> +env->pfault_token = -1UL;
>> +env->bpbc = false;
>> +break;
>> +}
>>   
>>   /* Reset state inside the kernel that we cannot access yet from QEMU. 
>> */
>> -if (kvm_enabled()) {
>> -kvm_s390_reset_vcpu(cpu);
>> +if (kvm_enabled() && (type == S390_CPU_RESET_CLEAR ||
>> +  type == S390_CPU_RESET_INITIAL)) {
>> +kvm_s390_reset_vcpu(cpu);
>>   }
>> -}
>> -
>> -/* CPUClass:reset() */
>> -static void s390_cpu_full_reset(CPUState *s)
>> -{
>> -S390CPU *cpu = S390_CPU(s);
>> -S390CPUClass *scc = S390_CPU_GET_CLASS(cpu);
>> -CPUS390XState *env = &cpu->env;
>> -
>> -scc->parent_reset(s);
>> -cpu->env.sigp_order = 0;
>> -s390_cpu_set_state(S390_CPU_STATE_STOPPED, cpu);
>> -
>> -memset(env, 0, offsetof(CPUS390XState, end_reset_fields));
>> -
>> -/* architectured initial values for CR 0 and 14 */
>> -env->cregs[0] = CR0_RESET;
>> -env->cregs[14] = CR14_RESET;
>>   
>>   #if defined(CONFIG_USER_ONLY)
>>   /* user mode should always be allowed to use the full FPU */
>> @@ -151,20 +136,21 @@ static void s390_cpu_full_reset(CPUState *s)
>>   env->cregs[0] |= CR0_VECTOR;
>>   }
>>   #endif
>> +}
>>   
>> -/* architectured initial value for Breaking-Event-Address register */
>> -env->gbea = 1;
>> +static void s390_cpu_reset_normal(CPUState *s)
>> +{
>> +return s390_cpu_reset(s, S390_CPU_RESET_NORMAL);
>> +}
>>   
>> -env->pfault_token = -1UL;
>> +static void s390_cpu_reset_initial(CPUState *s)
>> +{
>> +return s390_cpu_reset(s, S390_CPU_RESET_INITIAL);
>> +}
>>   
>> -/* tininess for underflow is detected before rounding */
>> -set_float_detect_tininess(float_tininess_before_rounding,
>> -  &env->fpu_status);
>> -
>> -   

[PATCH-for-5.0] hw/display/sm501: Always map the UART0

[Philippe Mathieu-Daudé]

The SM501 is a Mobile Multimedia Companion Chip with 2 UARTs.
This model only implements the first UART. Being part of the
chipset, the UART block is always mapped in memory, regardless
we provide a chardev backend.

Since commit 12051d82f, qemu_chr_fe_init() accepts a NULL chardev.
Let's remove the chardev check and always map the UART in the
chipset memory.

Signed-off-by: Philippe Mathieu-Daudé 
---
 hw/display/sm501.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/hw/display/sm501.c b/hw/display/sm501.c
index 1f33c87e65..79bd7bc2d1 100644
--- a/hw/display/sm501.c
+++ b/hw/display/sm501.c
@@ -1958,11 +1958,9 @@ static void sm501_realize_sysbus(DeviceState *dev, Error 
**errp)
 sysbus_pass_irq(sbd, SYS_BUS_DEVICE(usb_dev));
 
 /* bridge to serial emulation module */
-if (s->chr_state) {
-serial_mm_init(&s->state.mmio_region, SM501_UART0, 2,
-   NULL, /* TODO : chain irq to IRL */
-   115200, s->chr_state, DEVICE_LITTLE_ENDIAN);
-}
+serial_mm_init(&s->state.mmio_region, SM501_UART0, 2,
+   NULL, /* TODO : chain irq to IRL */
+   115200, s->chr_state, DEVICE_LITTLE_ENDIAN);
 }
 
 static Property sm501_sysbus_properties[] = {
-- 
2.21.0

Re: [PATCH 06/15] s390x: protvirt: Support unpack facility

[Cornelia Huck]

On Wed, 20 Nov 2019 06:43:25 -0500
Janosch Frank  wrote:

> When a guest has saved a ipib of type 5 and call diagnose308 with
> subcode 10, we have to setup the protected processing environment via
> Ultravisor calls. The calls are done by KVM and are exposed via an API.
> 
> The following steps are necessary:
> 1. Create a VM (register it with the Ultravisor)
> 2. Create secure CPUs for all of our current cpus
> 3. Forward the secure header to the Ultravisor (has all information on
> how to decrypt the image and VM information)
> 4. Protect image pages from the host and decrypt them
> 5. Verify the image integrity
> 
> Only after step 5 a protected VM is allowed to run.
> 
> Signed-off-by: Janosch Frank 
> ---
>  hw/s390x/Makefile.objs  |   1 +
>  hw/s390x/ipl.c  |  33 
>  hw/s390x/ipl.h  |   2 +
>  hw/s390x/pv.c   | 118 
>  hw/s390x/pv.h   |  26 ++
>  hw/s390x/s390-virtio-ccw.c  |  45 ---
>  target/s390x/cpu_features_def.inc.h |   1 +
>  7 files changed, 216 insertions(+), 10 deletions(-)
>  create mode 100644 hw/s390x/pv.c
>  create mode 100644 hw/s390x/pv.h
> 

> +static int s390_pv_cmd(uint32_t cmd, void *data)
> +{
> +int rc;
> +struct kvm_pv_cmd pv_cmd = {
> +.cmd = cmd,
> +.data = (uint64_t)data,
> +};
> +
> +rc = kvm_vm_ioctl(kvm_state, KVM_S390_PV_COMMAND, &pv_cmd);
> +if (rc) {
> +error_report("KVM PV command failed cmd: %d rc: %d", cmd, rc);
> +exit(1);
> +}
> +return rc;
> +}
> +
> +static int s390_pv_cmd_vcpu(CPUState *cs, uint32_t cmd, void *data)
> +{
> +int rc;
> +struct kvm_pv_cmd pv_cmd = {
> +.cmd = cmd,
> +.data = (uint64_t)data,
> +};
> +
> +rc = kvm_vcpu_ioctl(cs, KVM_S390_PV_COMMAND_VCPU, &pv_cmd);
> +if (rc) {
> +error_report("KVM PV VCPU command failed cmd: %d rc: %d", cmd, rc);
> +exit(1);
> +}
> +return rc;
> +}

If you do a hard exit for any rc != 0 anyway, returning rc does not
sound very useful :)

Re: [PATCH-for-5.0] hw/display/sm501: Always map the UART0

[Peter Maydell]

On Fri, 22 Nov 2019 at 13:36, Philippe Mathieu-Daudé  wrote:
>
> The SM501 is a Mobile Multimedia Companion Chip with 2 UARTs.
> This model only implements the first UART. Being part of the
> chipset, the UART block is always mapped in memory, regardless

"regardless of whether we provide"

> we provide a chardev backend.
>
> Since commit 12051d82f, qemu_chr_fe_init() accepts a NULL chardev.
> Let's remove the chardev check and always map the UART in the
> chipset memory.
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---
>  hw/display/sm501.c | 8 +++-
>  1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/hw/display/sm501.c b/hw/display/sm501.c
> index 1f33c87e65..79bd7bc2d1 100644
> --- a/hw/display/sm501.c
> +++ b/hw/display/sm501.c
> @@ -1958,11 +1958,9 @@ static void sm501_realize_sysbus(DeviceState *dev, 
> Error **errp)
>  sysbus_pass_irq(sbd, SYS_BUS_DEVICE(usb_dev));
>
>  /* bridge to serial emulation module */
> -if (s->chr_state) {
> -serial_mm_init(&s->state.mmio_region, SM501_UART0, 2,
> -   NULL, /* TODO : chain irq to IRL */
> -   115200, s->chr_state, DEVICE_LITTLE_ENDIAN);
> -}
> +serial_mm_init(&s->state.mmio_region, SM501_UART0, 2,
> +   NULL, /* TODO : chain irq to IRL */
> +   115200, s->chr_state, DEVICE_LITTLE_ENDIAN);
>  }
>
>  static Property sm501_sysbus_properties[] = {

Reviewed-by: Peter Maydell 

This would be one way of resolving a comment I had on
a patch to this device in Marc-André's series...

thanks
-- PMM

QEMU Licensing query

[karina filer]

Hi All,


QEMU  is used in Android Emulator and
is licensed under GPLv2
.

For one of our customer support we may have to modify QEMU.


 I have below queries,

   - *Case 1: No modification in QEMU *(QEMU delivered by Google)

Is there any implications if we are not modifying and releasing QEMU
externally, but we are sharing an Android image externally that runs on QEMU



   - *Case 2: Modification in QEMU *(QEMU delivered by Google)

What are the implications if we need to modify and release QEMU,
considering that we will also have to release an Android image that will
run on this QEMU.



Regards

Karina

Re: [PATCH 1/4] virtiofsd: Release file locks using F_UNLCK

[Vivek Goyal]

On Fri, Nov 22, 2019 at 10:07:13AM +, Stefan Hajnoczi wrote:
> On Fri, Nov 15, 2019 at 03:55:40PM -0500, Vivek Goyal wrote:
> > diff --git a/contrib/virtiofsd/passthrough_ll.c 
> > b/contrib/virtiofsd/passthrough_ll.c
> > index bc214df0c7..028e7da273 100644
> > --- a/contrib/virtiofsd/passthrough_ll.c
> > +++ b/contrib/virtiofsd/passthrough_ll.c
> > @@ -936,6 +936,14 @@ static void put_shared(struct lo_data *lo, struct 
> > lo_inode *inode)
> > }
> >  }
> >  
> > +static void release_plock(gpointer data)
> 
> The name posix_locks_value_destroy() would be clearer because it matches
> g_hash_table_new_full() terminology and the function cannot be confused
> with a lock acquire/release operation.

Ok, will use this name.

> 
> This patch conflicts with the cleanups that are currently being made to
> virtiofsd:
> https://github.com/stefanha/qemu/commit/1e493175feca58a81a2d0cbdac93b92e5425d850#diff-ca2dea995d1e6cdb95c8a47c7cca51ceR773

Yes it will. I see you are removing element from hash table on lo_flush().
This works fine today but with waiting locks, we drop the
inode->plock_mutex lock and then wait for the lock and expect
"lo_inode_plock" to not go away.

So I don't think you can remove the element from hash table upon
lo_flush(). May be we can refcount lo_inode_plock structure and first
release all the locks using setlk(UNLCK) and then drop the reference. If
this is last refernce, it will be freed.

And waiting lock code, will obtain a refernce under inode->posix_locks
and then wait for lock outside the lock.

IOW, I will say don't do this optimization of lookup + remove because
it will not work with blocking locks.

Thanks
Vivek

RE: [PATCH v2 1/2] intel_iommu: split the resevred fields arrays into two ones

[Qi, Yadong]

> -Original Message-
> From: Peter Xu 
> Sent: Wednesday, November 20, 2019 12:06 AM
> To: Zhang, Qi1 
> Cc: qemu-devel@nongnu.org; ehabk...@redhat.com; m...@redhat.com;
> pbonz...@redhat.com; Qi, Yadong ; r...@twiddle.net
> Subject: Re: [PATCH v2 1/2] intel_iommu: split the resevred fields arrays into
> two ones
> 
> On Tue, Nov 19, 2019 at 08:28:13PM +0800, qi1.zh...@intel.com wrote:
> > @@ -3547,15 +3548,17 @@ static void vtd_init(IntelIOMMUState *s)
> >  /*
> >   * Rsvd field masks for spte
> >   */
> > -vtd_paging_entry_rsvd_field[0] = ~0ULL;
> > -vtd_paging_entry_rsvd_field[1] = VTD_SPTE_PAGE_L1_RSVD_MASK(s-
> >aw_bits);
> > -vtd_paging_entry_rsvd_field[2] = VTD_SPTE_PAGE_L2_RSVD_MASK(s-
> >aw_bits);
> > -vtd_paging_entry_rsvd_field[3] = VTD_SPTE_PAGE_L3_RSVD_MASK(s-
> >aw_bits);
> > -vtd_paging_entry_rsvd_field[4] = VTD_SPTE_PAGE_L4_RSVD_MASK(s-
> >aw_bits);
> > -vtd_paging_entry_rsvd_field[5] = VTD_SPTE_LPAGE_L1_RSVD_MASK(s-
> >aw_bits);
> > -vtd_paging_entry_rsvd_field[6] = VTD_SPTE_LPAGE_L2_RSVD_MASK(s-
> >aw_bits);
> > -vtd_paging_entry_rsvd_field[7] = VTD_SPTE_LPAGE_L3_RSVD_MASK(s-
> >aw_bits);
> > -vtd_paging_entry_rsvd_field[8] = VTD_SPTE_LPAGE_L4_RSVD_MASK(s-
> >aw_bits);
> > +vtd_spte_rsvd[0] = ~0ULL;
> > +vtd_spte_rsvd[1] = VTD_SPTE_PAGE_L1_RSVD_MASK(s->aw_bits);
> > +vtd_spte_rsvd[2] = VTD_SPTE_PAGE_L2_RSVD_MASK(s->aw_bits);
> > +vtd_spte_rsvd[3] = VTD_SPTE_PAGE_L3_RSVD_MASK(s->aw_bits);
> > +vtd_spte_rsvd[4] = VTD_SPTE_PAGE_L4_RSVD_MASK(s->aw_bits);
> > +
> > +vtd_spte_rsvd_large[0] = ~0ULL;
> > +vtd_spte_rsvd_large[1] = VTD_SPTE_LPAGE_L1_RSVD_MASK(s->aw_bits);
> > +vtd_spte_rsvd_large[2] = VTD_SPTE_LPAGE_L2_RSVD_MASK(s->aw_bits);
> > +vtd_spte_rsvd_large[3] = VTD_SPTE_LPAGE_L3_RSVD_MASK(s->aw_bits);
> > +vtd_spte_rsvd_large[4] = VTD_SPTE_LPAGE_L4_RSVD_MASK(s->aw_bits);
> 
> This looks good to me in general, but... Since we're at it, do you think we 
> can
> directly drop VTD_SPTE_LPAGE_L1_RSVD_MASK and
> VTD_SPTE_LPAGE_L4_RSVD_MASK?  Are they really useful?

Yes, the LPAGE_L1 and LPAGE_L4 are useless.  I will try to make the change.


Best Regard
Yadong

Re: [PATCH 09/15] s390x: protvirt: SCLP interpretation

[Pierre Morel]

On 2019-11-21 15:24, Janosch Frank wrote:

On 11/21/19 3:11 PM, Cornelia Huck wrote:

On Wed, 20 Nov 2019 06:43:28 -0500
Janosch Frank  wrote:


SCLP for a protected guest is done over the SIDAD, so we need to use
the s390_cpu_virt_mem_* functions to access the SIDAD instead of guest
memory when reading/writing SCBs.

To not confuse the sclp emulation, we set 0x42000 as the address, but
ignore it for reading/writing the SCCB.

Signed-off-by: Janosch Frank 
---
  hw/s390x/sclp.c | 16 
  include/hw/s390x/sclp.h |  2 ++
  target/s390x/kvm.c  |  8 +++-
  3 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/hw/s390x/sclp.c b/hw/s390x/sclp.c
index f57ce7b739..00d08adc7f 100644
--- a/hw/s390x/sclp.c
+++ b/hw/s390x/sclp.c
@@ -193,6 +193,22 @@ static void sclp_execute(SCLPDevice *sclp, SCCB *sccb, 
uint32_t code)
  }
  }
  
+int sclp_service_call_protected(CPUS390XState *env, uint64_t sccb,

+uint32_t code)
+{
+SCLPDevice *sclp = get_sclp_device();
+SCLPDeviceClass *sclp_c = SCLP_GET_CLASS(sclp);
+SCCB work_sccb;
+hwaddr sccb_len = sizeof(SCCB);
+
+s390_cpu_virt_mem_read(env_archcpu(env), 0, 0, &work_sccb, sccb_len);
+sclp_c->execute(sclp, &work_sccb, code);
+s390_cpu_virt_mem_write(env_archcpu(env), 0, 0, &work_sccb,
+be16_to_cpu(work_sccb.h.length));
+sclp_c->service_interrupt(sclp, sccb);
+return 0;
+}
+
  int sclp_service_call(CPUS390XState *env, uint64_t sccb, uint32_t code)
  {
  SCLPDevice *sclp = get_sclp_device();
diff --git a/include/hw/s390x/sclp.h b/include/hw/s390x/sclp.h
index c54413b78c..c0a3faa37d 100644
--- a/include/hw/s390x/sclp.h
+++ b/include/hw/s390x/sclp.h
@@ -217,5 +217,7 @@ void s390_sclp_init(void);
  void sclp_service_interrupt(uint32_t sccb);
  void raise_irq_cpu_hotplug(void);
  int sclp_service_call(CPUS390XState *env, uint64_t sccb, uint32_t code);
+int sclp_service_call_protected(CPUS390XState *env, uint64_t sccb,
+uint32_t code);
  
  #endif

diff --git a/target/s390x/kvm.c b/target/s390x/kvm.c
index 58251c0229..0f2458b553 100644
--- a/target/s390x/kvm.c
+++ b/target/s390x/kvm.c
@@ -1172,7 +1172,13 @@ static int kvm_sclp_service_call(S390CPU *cpu, struct 
kvm_run *run,
  sccb = env->regs[ipbh0 & 0xf];
  code = env->regs[(ipbh0 & 0xf0) >> 4];
  
-r = sclp_service_call(env, sccb, code);

+if (run->s390_sieic.icptcode == ICPT_PV_INSTR ||
+run->s390_sieic.icptcode == ICPT_PV_INSTR_NOT) {
+r = sclp_service_call_protected(env, 0x42000, code);

I fear that confuses the reader instead of the emulation :)

Especially as you end up passing that value to
sclp_c->service_interrupt()...

Pierre has some more opinions on that, so I'll let him present his
planned changes to this patch :)



Hum, sorry but I can not present any thing at the moment.
I will study the problem, it will take some time.





+} else {
+r = sclp_service_call(env, sccb, code);
+}
+
  if (r < 0) {
  kvm_s390_program_interrupt(cpu, -r);
  } else {



--
Pierre Morel
IBM Lab Boeblingen

Re: [PATCH 06/15] s390x: protvirt: Support unpack facility

[Janosch Frank]

On 11/22/19 2:39 PM, Cornelia Huck wrote:
> On Wed, 20 Nov 2019 06:43:25 -0500
> Janosch Frank  wrote:
> 
>> When a guest has saved a ipib of type 5 and call diagnose308 with
>> subcode 10, we have to setup the protected processing environment via
>> Ultravisor calls. The calls are done by KVM and are exposed via an API.
>>
>> The following steps are necessary:
>> 1. Create a VM (register it with the Ultravisor)
>> 2. Create secure CPUs for all of our current cpus
>> 3. Forward the secure header to the Ultravisor (has all information on
>> how to decrypt the image and VM information)
>> 4. Protect image pages from the host and decrypt them
>> 5. Verify the image integrity
>>
>> Only after step 5 a protected VM is allowed to run.
>>
>> Signed-off-by: Janosch Frank 
>> ---
>>  hw/s390x/Makefile.objs  |   1 +
>>  hw/s390x/ipl.c  |  33 
>>  hw/s390x/ipl.h  |   2 +
>>  hw/s390x/pv.c   | 118 
>>  hw/s390x/pv.h   |  26 ++
>>  hw/s390x/s390-virtio-ccw.c  |  45 ---
>>  target/s390x/cpu_features_def.inc.h |   1 +
>>  7 files changed, 216 insertions(+), 10 deletions(-)
>>  create mode 100644 hw/s390x/pv.c
>>  create mode 100644 hw/s390x/pv.h
>>
> 
>> +static int s390_pv_cmd(uint32_t cmd, void *data)
>> +{
>> +int rc;
>> +struct kvm_pv_cmd pv_cmd = {
>> +.cmd = cmd,
>> +.data = (uint64_t)data,
>> +};
>> +
>> +rc = kvm_vm_ioctl(kvm_state, KVM_S390_PV_COMMAND, &pv_cmd);
>> +if (rc) {
>> +error_report("KVM PV command failed cmd: %d rc: %d", cmd, rc);
>> +exit(1);
>> +}
>> +return rc;
>> +}
>> +
>> +static int s390_pv_cmd_vcpu(CPUState *cs, uint32_t cmd, void *data)
>> +{
>> +int rc;
>> +struct kvm_pv_cmd pv_cmd = {
>> +.cmd = cmd,
>> +.data = (uint64_t)data,
>> +};
>> +
>> +rc = kvm_vcpu_ioctl(cs, KVM_S390_PV_COMMAND_VCPU, &pv_cmd);
>> +if (rc) {
>> +error_report("KVM PV VCPU command failed cmd: %d rc: %d", cmd, rc);
>> +exit(1);
>> +}
>> +return rc;
>> +}
> 
> If you do a hard exit for any rc != 0 anyway, returning rc does not
> sound very useful :)
> 

Yeah, that's also what Pierre said.
I'll need to rethink if there's actually a call where we could recover
from an error and if not make everything void.




signature.asc
Description: OpenPGP digital signature

Re: [PATCH v35 12/13] target/avr: Register AVR support with the rest of QEMU, the build system, and the WMAINTAINERS file

[Eric Blake]

On 10/29/19 4:24 PM, Michael Rolnik wrote:

Signed-off-by: Michael Rolnik 
---



+++ b/qapi/machine.json
@@ -21,11 +21,12 @@
  #is true even for "qemu-system-x86_64".
  #
  # ppcemb: dropped in 3.1
+# avr: since 4.2


At this point, we've missed the cutoff for new features in 4.2, so this 
should be 5.0



  #
  # Since: 3.0
  ##
  { 'enum' : 'SysEmuTarget',
-  'data' : [ 'aarch64', 'alpha', 'arm', 'cris', 'hppa', 'i386', 'lm32',
+  'data' : [ 'aarch64', 'alpha', 'arm', 'avr', 'cris', 'hppa', 'i386', 'lm32',
   'm68k', 'microblaze', 'microblazeel', 'mips', 'mips64',
   'mips64el', 'mipsel', 'moxie', 'nios2', 'or1k', 'ppc',
   'ppc64', 'riscv32', 'riscv64', 's390x', 'sh4',



--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Re: [PATCH for-5.0 v5 17/23] ppc/pnv: Clarify how the TIMA is accessed on a multichip system

[Greg Kurz]

On Fri, 15 Nov 2019 17:24:30 +0100
Cédric Le Goater  wrote:

> The TIMA region gives access to the thread interrupt context registers
> of a CPU. It is mapped at the same address on all chips and can be
> accessed by any CPU of the system. To identify the chip from which the
> access is being done, the PowerBUS uses a 'chip' field in the
> load/store messages. QEMU does not model these messages, instead, we
> extract the chip id from the CPU PIR and do a lookup at the machine
> level to fetch the targeted interrupt controller.
> 
> Introduce pnv_get_chip() and pnv_xive_tm_get_xive() helpers to clarify
> this process in pnv_xive_get_tctx(). The latter will be removed in the
> subsequent patches but the same principle will be kept.
> 
> Signed-off-by: Cédric Le Goater 
> ---
>  include/hw/ppc/pnv.h | 13 +
>  hw/intc/pnv_xive.c   | 46 
>  2 files changed, 42 insertions(+), 17 deletions(-)
> 
> diff --git a/include/hw/ppc/pnv.h b/include/hw/ppc/pnv.h
> index 58f4dcc0b71d..9b98b6afa31b 100644
> --- a/include/hw/ppc/pnv.h
> +++ b/include/hw/ppc/pnv.h
> @@ -192,6 +192,19 @@ static inline bool pnv_is_power9(PnvMachineState *pnv)
>  return pnv_chip_is_power9(pnv->chips[0]);
>  }
>  
> +static inline PnvChip *pnv_get_chip(PnvMachineState *pnv, uint32_t chip_id)

I understand this has global scope because it may be used by
some other code, eg. PHB4 in your private branch, but I'm not
sure it is small enough to deserve the inline qualifier.

> +{
> +int i;
> +
> +for (i = 0; i < pnv->num_chips; i++) {
> +PnvChip *chip = pnv->chips[i];
> +if (chip->chip_id == chip_id) {
> +return chip;
> +}
> +}
> +return NULL;
> +}
> +
>  #define PNV_FDT_ADDR  0x0100
>  #define PNV_TIMEBASE_FREQ 51200ULL
>  
> diff --git a/hw/intc/pnv_xive.c b/hw/intc/pnv_xive.c
> index 3ee28f00694a..d75053d0baad 100644
> --- a/hw/intc/pnv_xive.c
> +++ b/hw/intc/pnv_xive.c
> @@ -378,6 +378,12 @@ static int cpu_pir(PowerPCCPU *cpu)
>  return env->spr_cb[SPR_PIR].default_value;
>  }
>  
> +static int cpu_chip_id(PowerPCCPU *cpu)
> +{
> +int pir = cpu_pir(cpu);
> +return (pir >> 8) & 0x7f;
> +}

Just a thought: it would be nice to have all pir<->ids conversion
functions grouped by CPU type in pnv.h (inline makes sense in this
case) along with the layout comment.

Anyway,

Reviewed-by: Greg Kurz 

> +
>  static bool pnv_xive_is_cpu_enabled(PnvXive *xive, PowerPCCPU *cpu)
>  {
>  int pir = cpu_pir(cpu);
> @@ -440,31 +446,37 @@ static int pnv_xive_match_nvt(XivePresenter *xptr, 
> uint8_t format,
>  return count;
>  }
>  
> +/*
> + * The TIMA MMIO space is shared among the chips and to identify the
> + * chip from which the access is being done, we extract the chip id
> + * from the PIR.
> + */
> +static PnvXive *pnv_xive_tm_get_xive(PowerPCCPU *cpu)
> +{
> +PnvMachineState *pnv = PNV_MACHINE(qdev_get_machine());
> +PnvChip *chip;
> +PnvXive *xive;
> +
> +chip = pnv_get_chip(pnv, cpu_chip_id(cpu));
> +assert(chip);
> +xive = &PNV9_CHIP(chip)->xive;
> +
> +if (!pnv_xive_is_cpu_enabled(xive, cpu)) {
> +xive_error(xive, "IC: CPU %x is not enabled", cpu_pir(cpu));
> +}
> +return xive;
> +}
> +
>  static XiveTCTX *pnv_xive_get_tctx(XiveRouter *xrtr, CPUState *cs)
>  {
>  PowerPCCPU *cpu = POWERPC_CPU(cs);
> -XiveTCTX *tctx = XIVE_TCTX(pnv_cpu_state(cpu)->intc);
> -PnvXive *xive = NULL;
> -CPUPPCState *env = &cpu->env;
> -int pir = env->spr_cb[SPR_PIR].default_value;
> +PnvXive *xive = pnv_xive_tm_get_xive(cpu);
>  
> -/*
> - * Perform an extra check on the HW thread enablement.
> - *
> - * The TIMA is shared among the chips and to identify the chip
> - * from which the access is being done, we extract the chip id
> - * from the PIR.
> - */
> -xive = pnv_xive_get_ic((pir >> 8) & 0xf);
>  if (!xive) {
>  return NULL;
>  }
>  
> -if (!(xive->regs[PC_THREAD_EN_REG0 >> 3] & PPC_BIT(pir & 0x3f))) {
> -xive_error(PNV_XIVE(xrtr), "IC: CPU %x is not enabled", pir);
> -}
> -
> -return tctx;
> +return XIVE_TCTX(pnv_cpu_state(cpu)->intc);
>  }
>  
>  /*

Re: [PATCH v2 4/5] MAINTAINERS: Adjust maintainership for R4000 systems

[Philippe Mathieu-Daudé]

Hi Aleksandar,

On 11/13/19 2:47 PM, Aleksandar Markovic wrote:

From: Aleksandar Markovic 

Change the maintainership for R4000 systems to improve its quality.

Acked-by: Aurelien Jarno 
Signed-off-by: Aleksandar Markovic 
---
  MAINTAINERS | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6afec32..ba9ca98 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -971,8 +971,9 @@ F: hw/mips/mips_mipssim.c
  F: hw/net/mipsnet.c
  
  R4000

-M: Aurelien Jarno 
-R: Aleksandar Rikalo 
+M: Hervé Poussineau 


Commit 0c10962a033 from Hervé was part of a bigger refactor series, so I 
don't think he is interested.



+R: Aurelien Jarno 
+R: Philippe Mathieu-Daudé 
  S: Maintained
  F: hw/mips/mips_r4k.c


Now back to this board, I am having hard time to understand what it 
models. IIUC it predates the Malta board, and was trying to model a 
board able to run the first MIPS cpu when the port was added in 2005 
(see commit 6af0bf9c7c3a).
The Malta board was added 1 year later (commit 5856de800df) and models a 
real hardware.


As Aurelien acked to step down maintaining it, it seems the perfect 
timing to start its deprecation process. I'll prepare a patch for 5.0 
(unless someone is really using it and willing to maintain it).


Regards,

Phil.

[PATCH] target/arm: Fix ISR_EL1 tracking when executing at EL2

[Marc Zyngier]

The ARMv8 ARM states when executing at EL2, EL3 or Secure EL1,
ISR_EL1 shows the pending status of the physical IRQ, FIQ, or
SError interrupts.

Unfortunately, QEMU's implementation only considers the HCR_EL2
bits, and ignores the current exception level. This means a hypervisor
trying to look at its own interrupt state actually sees the guest
state, which is unexpected and breaks KVM as of Linux 5.3.

Instead, check for the running EL and return the physical bits
if not running in a virtualized context.

Fixes: 636540e9c40b
Reported-by: Quentin Perret 
Signed-off-by: Marc Zyngier 
---
 target/arm/helper.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/target/arm/helper.c b/target/arm/helper.c
index a089fb5a69..027fffbff6 100644
--- a/target/arm/helper.c
+++ b/target/arm/helper.c
@@ -1934,8 +1934,11 @@ static uint64_t isr_read(CPUARMState *env, const 
ARMCPRegInfo *ri)
 CPUState *cs = env_cpu(env);
 uint64_t hcr_el2 = arm_hcr_el2_eff(env);
 uint64_t ret = 0;
+bool allow_virt = (arm_current_el(env) == 1 &&
+   (!arm_is_secure_below_el3(env) ||
+(env->cp15.scr_el3 & SCR_EEL2)));
 
-if (hcr_el2 & HCR_IMO) {
+if (allow_virt && (hcr_el2 & HCR_IMO)) {
 if (cs->interrupt_request & CPU_INTERRUPT_VIRQ) {
 ret |= CPSR_I;
 }
@@ -1945,7 +1948,7 @@ static uint64_t isr_read(CPUARMState *env, const 
ARMCPRegInfo *ri)
 }
 }
 
-if (hcr_el2 & HCR_FMO) {
+if (allow_virt && (hcr_el2 & HCR_FMO)) {
 if (cs->interrupt_request & CPU_INTERRUPT_VFIQ) {
 ret |= CPSR_F;
 }
-- 
2.17.1

[PATCH v2 0/5] s390x: Reset cleanup

[Janosch Frank]

Adding comments and reordering code for better readability in the
diag308 and machine reset functions.

Janosch Frank (5):
  s390x: Don't do a normal reset on the initial cpu
  s390x: Move reset normal to shared reset handler
  s390x: Move initial reset
  s390x: Move clear reset
  s390x: Beautify diag308 handling

 hw/s390x/s390-virtio-ccw.c |  3 ++
 target/s390x/cpu-qom.h |  9 +++-
 target/s390x/cpu.c | 99 --
 target/s390x/cpu.h |  4 +-
 target/s390x/diag.c| 54 -
 target/s390x/sigp.c|  4 +-
 6 files changed, 76 insertions(+), 97 deletions(-)

-- 
2.20.1

[PATCH v2 3/5] s390x: Move initial reset

[Janosch Frank]

Let's move the intial reset into the reset handler and cleanup
afterwards.

Signed-off-by: Janosch Frank 
---
 target/s390x/cpu-qom.h |  2 +-
 target/s390x/cpu.c | 44 +++---
 target/s390x/cpu.h |  2 +-
 target/s390x/sigp.c|  2 +-
 4 files changed, 19 insertions(+), 31 deletions(-)

diff --git a/target/s390x/cpu-qom.h b/target/s390x/cpu-qom.h
index f3b71bac67..6f0a12042e 100644
--- a/target/s390x/cpu-qom.h
+++ b/target/s390x/cpu-qom.h
@@ -36,6 +36,7 @@ typedef struct S390CPUDef S390CPUDef;
 
 typedef enum cpu_reset_type {
 S390_CPU_RESET_NORMAL,
+S390_CPU_RESET_INITIAL,
 } cpu_reset_type;
 
 /**
@@ -62,7 +63,6 @@ typedef struct S390CPUClass {
 void (*parent_reset)(CPUState *cpu);
 void (*load_normal)(CPUState *cpu);
 void (*reset)(CPUState *cpu, cpu_reset_type type);
-void (*initial_cpu_reset)(CPUState *cpu);
 } S390CPUClass;
 
 typedef struct S390CPU S390CPU;
diff --git a/target/s390x/cpu.c b/target/s390x/cpu.c
index cf13472472..1f423fb676 100644
--- a/target/s390x/cpu.c
+++ b/target/s390x/cpu.c
@@ -94,37 +94,26 @@ static void s390_cpu_reset(CPUState *s, cpu_reset_type type)
 s390_cpu_set_state(S390_CPU_STATE_STOPPED, cpu);
 
 switch (type) {
+case S390_CPU_RESET_INITIAL:
+/* initial reset does not clear everything! */
+memset(&env->start_initial_reset_fields, 0,
+   offsetof(CPUS390XState, end_reset_fields) -
+   offsetof(CPUS390XState, start_initial_reset_fields));
+
+/* architectured initial value for Breaking-Event-Address register */
+env->gbea = 1;
+
+/* architectured initial values for CR 0 and 14 */
+env->cregs[0] = CR0_RESET;
+env->cregs[14] = CR14_RESET;
+
+/* tininess for underflow is detected before rounding */
+set_float_detect_tininess(float_tininess_before_rounding,
+  &env->fpu_status);
 case S390_CPU_RESET_NORMAL:
 env->pfault_token = -1UL;
 env->bpbc = false;
-break;
 }
-}
-
-/* S390CPUClass::initial_reset() */
-static void s390_cpu_initial_reset(CPUState *s)
-{
-S390CPU *cpu = S390_CPU(s);
-CPUS390XState *env = &cpu->env;
-
-s390_cpu_reset(s, S390_CPU_RESET_NORMAL);
-/* initial reset does not clear everything! */
-memset(&env->start_initial_reset_fields, 0,
-offsetof(CPUS390XState, end_reset_fields) -
-offsetof(CPUS390XState, start_initial_reset_fields));
-
-/* architectured initial values for CR 0 and 14 */
-env->cregs[0] = CR0_RESET;
-env->cregs[14] = CR14_RESET;
-
-/* architectured initial value for Breaking-Event-Address register */
-env->gbea = 1;
-
-env->pfault_token = -1UL;
-
-/* tininess for underflow is detected before rounding */
-set_float_detect_tininess(float_tininess_before_rounding,
-  &env->fpu_status);
 
 /* Reset state inside the kernel that we cannot access yet from QEMU. */
 if (kvm_enabled()) {
@@ -479,7 +468,6 @@ static void s390_cpu_class_init(ObjectClass *oc, void *data)
 scc->load_normal = s390_cpu_load_normal;
 #endif
 scc->reset = s390_cpu_reset;
-scc->initial_cpu_reset = s390_cpu_initial_reset;
 cc->reset = s390_cpu_full_reset;
 cc->class_by_name = s390_cpu_class_by_name,
 cc->has_work = s390_cpu_has_work;
diff --git a/target/s390x/cpu.h b/target/s390x/cpu.h
index 18123dfd5b..d2af13b345 100644
--- a/target/s390x/cpu.h
+++ b/target/s390x/cpu.h
@@ -748,7 +748,7 @@ static inline void s390_do_cpu_initial_reset(CPUState *cs, 
run_on_cpu_data arg)
 {
 S390CPUClass *scc = S390_CPU_GET_CLASS(cs);
 
-scc->initial_cpu_reset(cs);
+scc->reset(cs, S390_CPU_RESET_INITIAL);
 }
 
 static inline void s390_do_cpu_load_normal(CPUState *cs, run_on_cpu_data arg)
diff --git a/target/s390x/sigp.c b/target/s390x/sigp.c
index 850139b9cd..727875bb4a 100644
--- a/target/s390x/sigp.c
+++ b/target/s390x/sigp.c
@@ -254,7 +254,7 @@ static void sigp_initial_cpu_reset(CPUState *cs, 
run_on_cpu_data arg)
 SigpInfo *si = arg.host_ptr;
 
 cpu_synchronize_state(cs);
-scc->initial_cpu_reset(cs);
+scc->reset(cs, S390_CPU_RESET_INITIAL);
 cpu_synchronize_post_reset(cs);
 si->cc = SIGP_CC_ORDER_CODE_ACCEPTED;
 }
-- 
2.20.1

[PATCH v2 2/5] s390x: Move reset normal to shared reset handler

[Janosch Frank]

Let's start moving the cpu reset functions into a single function with
a switch/case, so we can use fallthroughs and share more code between
resets.

This patch introduces the reset function by renaming cpu_reset() and
cleaning up leftovers.

Signed-off-by: Janosch Frank 
---
 target/s390x/cpu-qom.h |  6 +-
 target/s390x/cpu.c | 17 +++--
 target/s390x/cpu.h |  2 +-
 target/s390x/sigp.c|  2 +-
 4 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/target/s390x/cpu-qom.h b/target/s390x/cpu-qom.h
index b809ec8418..f3b71bac67 100644
--- a/target/s390x/cpu-qom.h
+++ b/target/s390x/cpu-qom.h
@@ -34,6 +34,10 @@
 typedef struct S390CPUModel S390CPUModel;
 typedef struct S390CPUDef S390CPUDef;
 
+typedef enum cpu_reset_type {
+S390_CPU_RESET_NORMAL,
+} cpu_reset_type;
+
 /**
  * S390CPUClass:
  * @parent_realize: The parent class' realize handler.
@@ -57,7 +61,7 @@ typedef struct S390CPUClass {
 DeviceRealize parent_realize;
 void (*parent_reset)(CPUState *cpu);
 void (*load_normal)(CPUState *cpu);
-void (*cpu_reset)(CPUState *cpu);
+void (*reset)(CPUState *cpu, cpu_reset_type type);
 void (*initial_cpu_reset)(CPUState *cpu);
 } S390CPUClass;
 
diff --git a/target/s390x/cpu.c b/target/s390x/cpu.c
index 3abe7e80fd..cf13472472 100644
--- a/target/s390x/cpu.c
+++ b/target/s390x/cpu.c
@@ -82,18 +82,23 @@ static void s390_cpu_load_normal(CPUState *s)
 }
 #endif
 
-/* S390CPUClass::cpu_reset() */
-static void s390_cpu_reset(CPUState *s)
+/* S390CPUClass::reset() */
+static void s390_cpu_reset(CPUState *s, cpu_reset_type type)
 {
 S390CPU *cpu = S390_CPU(s);
 S390CPUClass *scc = S390_CPU_GET_CLASS(cpu);
 CPUS390XState *env = &cpu->env;
 
-env->pfault_token = -1UL;
-env->bpbc = false;
 scc->parent_reset(s);
 cpu->env.sigp_order = 0;
 s390_cpu_set_state(S390_CPU_STATE_STOPPED, cpu);
+
+switch (type) {
+case S390_CPU_RESET_NORMAL:
+env->pfault_token = -1UL;
+env->bpbc = false;
+break;
+}
 }
 
 /* S390CPUClass::initial_reset() */
@@ -102,7 +107,7 @@ static void s390_cpu_initial_reset(CPUState *s)
 S390CPU *cpu = S390_CPU(s);
 CPUS390XState *env = &cpu->env;
 
-s390_cpu_reset(s);
+s390_cpu_reset(s, S390_CPU_RESET_NORMAL);
 /* initial reset does not clear everything! */
 memset(&env->start_initial_reset_fields, 0,
 offsetof(CPUS390XState, end_reset_fields) -
@@ -473,7 +478,7 @@ static void s390_cpu_class_init(ObjectClass *oc, void *data)
 #if !defined(CONFIG_USER_ONLY)
 scc->load_normal = s390_cpu_load_normal;
 #endif
-scc->cpu_reset = s390_cpu_reset;
+scc->reset = s390_cpu_reset;
 scc->initial_cpu_reset = s390_cpu_initial_reset;
 cc->reset = s390_cpu_full_reset;
 cc->class_by_name = s390_cpu_class_by_name,
diff --git a/target/s390x/cpu.h b/target/s390x/cpu.h
index 17460ed7b3..18123dfd5b 100644
--- a/target/s390x/cpu.h
+++ b/target/s390x/cpu.h
@@ -741,7 +741,7 @@ static inline void s390_do_cpu_reset(CPUState *cs, 
run_on_cpu_data arg)
 {
 S390CPUClass *scc = S390_CPU_GET_CLASS(cs);
 
-scc->cpu_reset(cs);
+scc->reset(cs, S390_CPU_RESET_NORMAL);
 }
 
 static inline void s390_do_cpu_initial_reset(CPUState *cs, run_on_cpu_data arg)
diff --git a/target/s390x/sigp.c b/target/s390x/sigp.c
index 2ce22d4dc1..850139b9cd 100644
--- a/target/s390x/sigp.c
+++ b/target/s390x/sigp.c
@@ -266,7 +266,7 @@ static void sigp_cpu_reset(CPUState *cs, run_on_cpu_data 
arg)
 SigpInfo *si = arg.host_ptr;
 
 cpu_synchronize_state(cs);
-scc->cpu_reset(cs);
+scc->reset(cs, S390_CPU_RESET_NORMAL);
 cpu_synchronize_post_reset(cs);
 si->cc = SIGP_CC_ORDER_CODE_ACCEPTED;
 }
-- 
2.20.1