Re: [PATCH] travis.yml: Run tcg tests with tci

[Thomas Huth]

On 27/11/2019 19.38, Alex Bennée wrote:


Thomas Huth  writes:


So far we only have compile coverage for tci. But since commit
2f160e0f9797c7522bfd0d09218d0c9340a5137c ("tci: Add implementation
for INDEX_op_ld16u_i64") has been included, we can also run the
x86 TCG tests with tci, so let's enable them in Travis now.

Signed-off-by: Thomas Huth 
---
  .travis.yml | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.travis.yml b/.travis.yml
index c09b6a0014..b0b634d484 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -218,7 +218,7 @@ matrix:
  # We manually include builds which we disable "make check" for


this comment is out of date now (or rather has been for a while)


  - env:
  - CONFIG="--enable-debug --enable-tcg-interpreter"


Perhaps as linux-user doesn't add much to testing the TCG we could limit
by MAIN_SOFTMMU_TARGETS here?


Limiting is a good idea, but I think we should use the architectures 
that are supported by tests/boot-serial-test.c instead.



-- TEST_CMD=""
+- TEST_CMD="make run-tcg-tests-x86_64-softmmu V=1"


How about "make check-qtest check-tcg"
> Which will exercise the moderate boot code tests of various
architectures as well as x86_64 (if we include the --disable-docker
configure stanza)


I tried "check-tcg" before switching to "run-tcg-tests-x86_64-softmmu", 
but "check-tcg" then resulted in a docker error:


 https://travis-ci.com/huth/qemu/jobs/260949876#L11974

... so looks like we indeed have to use --disable-docker in that case.

I'll have a try and send a v2 if that works out fine.

 Thomas

[PATCH v19 3/8] numa: Extend CLI to provide memory side cache information

[Tao Xu]

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).
Before using hmat-cache option, enable HMAT with -machine hmat=on.

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

Changes in v19:
- Add description about the machine property 'hmat' in commit
  message (Markus)
- Update the QAPI comments
- Add a check for no memory side cache

Changes in v18:
- Update the error message (Igor)

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| 86 +++
 include/sysemu/numa.h |  5 +++
 qapi/machine.json | 81 +++-
 qemu-options.hx   | 16 +++-
 4 files changed, 184 insertions(+), 4 deletions(-)

diff --git a/hw/core/numa.c b/hw/core/numa.c
index 2183c8df1f..664b44ad68 100644
--- a/hw/core/numa.c
+++ b/hw/core/numa.c
@@ -366,6 +366,79 @@ 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;
+}
+
+if (!node->level && (node->assoc || node->policy || node->line)) {
+error_setg(errp, "Assoc and policy options should be 'none', line "
+   "should be 0. If cache level is 0, which means no memory "
+   "side cache in node-id=%" PRIu32, node->node_id);
+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 less 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;
+}
+
+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;
@@ -417,6 +490,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(er

[PATCH v19 1/8] numa: Extend CLI to provide initiator information for numa nodes

[Tao Xu]

In ACPI 6.3 chapter 5.2.27 Heterogeneous Memory Attribute Table (HMAT),
The initiator represents processor which access to memory. And in 5.2.27.3
Memory Proximity Domain Attributes Structure, the attached initiator is
defined as where the memory controller responsible for a memory proximity
domain. With attached initiator information, the topology of heterogeneous
memory can be described. Add new machine property 'hmat' to enable all
HMAT specific options.

Extend CLI of "-numa node" option to indicate the initiator numa node-id.
In the linux kernel, the codes in drivers/acpi/hmat/hmat.c parse and report
the platform's HMAT tables. Before using initiator option, enable HMAT with
-machine hmat=on.

Reviewed-by: Igor Mammedov 
Reviewed-by: Jingqi Liu 
Suggested-by: Dan Williams 
Signed-off-by: Tao Xu 
---

Changes in v19:
- Add description about the machine property 'hmat' in commit
  message (Markus)

Changes in v15:
- Change the QAPI version tag to 5.0 (Eric)
---
 hw/core/machine.c | 64 +++
 hw/core/numa.c| 23 
 include/sysemu/numa.h |  5 
 qapi/machine.json | 10 ++-
 qemu-options.hx   | 35 +++
 5 files changed, 131 insertions(+), 6 deletions(-)

diff --git a/hw/core/machine.c b/hw/core/machine.c
index 1689ad3bf8..d7d2cfa66d 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -518,6 +518,20 @@ static void machine_set_nvdimm(Object *obj, bool value, 
Error **errp)
 ms->nvdimms_state->is_enabled = value;
 }
 
+static bool machine_get_hmat(Object *obj, Error **errp)
+{
+MachineState *ms = MACHINE(obj);
+
+return ms->numa_state->hmat_enabled;
+}
+
+static void machine_set_hmat(Object *obj, bool value, Error **errp)
+{
+MachineState *ms = MACHINE(obj);
+
+ms->numa_state->hmat_enabled = value;
+}
+
 static char *machine_get_nvdimm_persistence(Object *obj, Error **errp)
 {
 MachineState *ms = MACHINE(obj);
@@ -645,6 +659,7 @@ void machine_set_cpu_numa_node(MachineState *machine,
const CpuInstanceProperties *props, Error 
**errp)
 {
 MachineClass *mc = MACHINE_GET_CLASS(machine);
+NodeInfo *numa_info = machine->numa_state->nodes;
 bool match = false;
 int i;
 
@@ -714,6 +729,17 @@ void machine_set_cpu_numa_node(MachineState *machine,
 match = true;
 slot->props.node_id = props->node_id;
 slot->props.has_node_id = props->has_node_id;
+
+if (machine->numa_state->hmat_enabled) {
+if ((numa_info[props->node_id].initiator < MAX_NODES) &&
+(props->node_id != numa_info[props->node_id].initiator)) {
+error_setg(errp, "The initiator of CPU NUMA node %" PRId64
+" should be itself", props->node_id);
+return;
+}
+numa_info[props->node_id].has_cpu = true;
+numa_info[props->node_id].initiator = props->node_id;
+}
 }
 
 if (!match) {
@@ -960,6 +986,13 @@ static void machine_initfn(Object *obj)
 
 if (mc->numa_mem_supported) {
 ms->numa_state = g_new0(NumaState, 1);
+object_property_add_bool(obj, "hmat",
+ machine_get_hmat, machine_set_hmat,
+ &error_abort);
+object_property_set_description(obj, "hmat",
+"Set on/off to enable/disable "
+"ACPI Heterogeneous Memory Attribute "
+"Table (HMAT)", NULL);
 }
 
 /* Register notifier when init is done for sysbus sanity checks */
@@ -1048,6 +1081,32 @@ static char *cpu_slot_to_string(const CPUArchId *cpu)
 return g_string_free(s, false);
 }
 
+static void numa_validate_initiator(NumaState *numa_state)
+{
+int i;
+NodeInfo *numa_info = numa_state->nodes;
+
+for (i = 0; i < numa_state->num_nodes; i++) {
+if (numa_info[i].initiator == MAX_NODES) {
+error_report("The initiator of NUMA node %d is missing, use "
+ "'-numa node,initiator' option to declare it", i);
+exit(1);
+}
+
+if (!numa_info[numa_info[i].initiator].present) {
+error_report("NUMA node %" PRIu16 " is missing, use "
+ "'-numa node' option to declare it first",
+ numa_info[i].initiator);
+exit(1);
+}
+
+if (!numa_info[numa_info[i].initiator].has_cpu) {
+error_report("The initiator of NUMA node %d is invalid", i);
+exit(1);
+}
+}
+}
+
 static void machine_numa_finish_cpu_init(MachineState *machine)
 {
 int i;
@@ -1088,6 +1147,11 @@ static void machine_numa_finish_cpu_init(MachineState 
*machine)
 machine_set_cpu_numa_node(machine, &props, &error_fatal);
 }
 }
+
+if (machine->numa_state->hmat_enabled) {
+numa_val

[PATCH v19 7/8] tests/numa: Add case for QMP build HMAT

[Tao Xu]

Check configuring HMAT usecase

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

Changes in v19:
- Add some fail cases for hmat-cache when level=0

Changes in v18:
- Rewrite the lines over 80 characters

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

diff --git a/tests/numa-test.c b/tests/numa-test.c
index 8de8581231..aed7b2f31b 100644
--- a/tests/numa-test.c
+++ b/tests/numa-test.c
@@ -327,6 +327,216 @@ 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': '

[PATCH v19 0/8] Build ACPI Heterogeneous Memory Attribute Table (HMAT)

[Tao Xu]

This series of patches will build Heterogeneous Memory Attribute Table (HMAT)
according to the command line. The ACPI HMAT describes the memory attributes,
such as memory side cache attributes and bandwidth and latency details,
related to the Memory Proximity Domain.
The software is expected to use HMAT information as hint for optimization.

In the linux kernel, the codes in drivers/acpi/hmat/hmat.c parse and report
the platform's HMAT tables.

The V18 patches link:
https://patchwork.kernel.org/cover/11263551/

Changelog:
v19:
- Add description about the machine property 'hmat' in commit
  message (Markus)
- Update the QAPI comments
- Add a check for no memory side cache
- Add some fail cases for hmat-cache when level=0
v18:
- Defer patches 01/14~06/14 of V17, use qapi type uint64 and
  only nanosecond for latency (Markus)
- Rewrite the lines over 80 characters(Igor)
v17:
- Add check when user input latency or bandwidth 0, the
  lb_info_provided should also be 0. Because in ACPI 6.3 5.2.27.4,
  0 means the corresponding latency or bandwidth information is
  not provided.
- Fix the infinite loop when node->latency is 0.
- Use NumaHmatCacheOptions to replace HMAT_Cache_Info (Igor)
- Add check for unordered cache level input (Igor)
- Add some fail test cases (Igor)
v16:
- Add and use qemu_strtold_finite to parse size, support full
  64bit precision, modify related test cases (Eduardo and Markus)
- Simplify struct HMAT_LB_Info and related code, unify latency
  and bandwidth (Igor)
- Add cross check with hmat_lb data (Igor)
- Fields in Cache Attributes are promoted to uint32_t before
  shifting (Igor)
- Add case for QMP build HMAT (Igor)
v15:
- Add a new patch to refactor do_strtosz() (Eduardo)
- Make tests without breaking CI (Michael)
v14:
- Reuse the codes of do_strtosz to build qemu_strtotime_ns
  (Eduardo)
- Squash patch v13 01/12 and 02/12 together (Daniel and Eduardo)
- Drop time unit picosecond (Eric)
- Use qemu ctz64 and clz64 instead of builtin function
v13:
- Modify some text description
- Drop "initiator_valid" field in struct NodeInfo
- Reuse Garray to store the raw bandwidth and bandwidth data
- Calculate common base unit using range bitmap
- Add a patch to alculate hmat latency and bandwidth entry list
- Drop the total_levels option and use readable cache size
- Remove the unnecessary head file
- Use decimal notation with appropriate suffix for cache size
v12:
- Fix a bug that a memory-only node without initiator setting
  doesn't report error. (reported by Danmei Wei)
- Fix a bug that if HMAT is enabled and without hmat-lb setting,
  QEMU will crash. (reported by Danmei Wei)

Liu Jingqi (5):
  numa: Extend CLI to provide memory latency and bandwidth information
  numa: Extend CLI to provide memory side cache information
  hmat acpi: Build Memory Proximity Domain Attributes Structure(s)
  hmat acpi: Build System Locality Latency and Bandwidth Information
Structure(s)
  hmat acpi: Build Memory Side Cache Information Structure(s)

Tao Xu (3):
  numa: Extend CLI to provide initiator information for numa nodes
  tests/numa: Add case for QMP build HMAT
  tests/bios-tables-test: add test cases for ACPI HMAT

 hw/acpi/Kconfig   |   7 +-
 hw/acpi/Makefile.objs |   1 +
 hw/acpi/hmat.c| 268 
 hw/acpi/hmat.h|  42 
 hw/core/machine.c |  64 ++
 hw/core/numa.c| 290 ++
 hw/i386/acpi-build.c  |   5 +
 include/sysemu/numa.h |  63 ++
 qapi/machine.json | 180 +++-
 qemu-options.hx   |  95 -
 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
 tests/numa-test.c | 213 +++
 21 files changed, 1269 insertions(+), 11 deletions(-)
 create mode 100644 hw/acpi/hmat.c
 create mode 100644 hw/acpi/hmat.h
 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

-- 
2.20.1

[PATCH v19 6/8] 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: Igor Mammedov 
Reviewed-by: Daniel Black 
Reviewed-by: Jonathan Cameron 
Signed-off-by: Liu Jingqi 
Signed-off-by: Tao Xu 
---

No changes in v19.

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 v19 2/8] numa: Extend CLI to provide memory latency and bandwidth information

[Tao Xu]

From: Liu Jingqi 

Add -numa hmat-lb option to provide System Locality Latency and
Bandwidth Information. These memory attributes help to build
System Locality Latency and Bandwidth Information Structure(s)
in ACPI Heterogeneous Memory Attribute Table (HMAT). Before using
hmat-lb option, enable HMAT with -machine hmat=on.

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

Changes in v19:
- Add description about the machine property 'hmat' in commit
  message (Markus)

Changes in v18:
- Use qapi type uint64 and only nanosecond for latency (Markus)

Changes in v17:
- Add check when user input latency or bandwidth 0, the
  lb_info_provided should also be 0. Because in ACPI 6.3 5.2.27.4,
  0 means the corresponding latency or bandwidth information is
  not provided.
- Fix the infinite loop when node->latency is 0.

Changes in v16:
- Initialize HMAT_LB_Data lb_data (Igor)
- Remove punctuation from error_setg (Igor)
- Correct some description (Igor)
- Drop statement about max value (Igor)
- Simplify struct HMAT_LB_Info and related code, unify latency
  and bandwidth (Igor)
---
 hw/core/numa.c| 181 ++
 include/sysemu/numa.h |  53 +
 qapi/machine.json |  93 +-
 qemu-options.hx   |  48 ++-
 4 files changed, 372 insertions(+), 3 deletions(-)

diff --git a/hw/core/numa.c b/hw/core/numa.c
index e60da99293..2183c8df1f 100644
--- a/hw/core/numa.c
+++ b/hw/core/numa.c
@@ -23,6 +23,7 @@
  */
 
 #include "qemu/osdep.h"
+#include "qemu/units.h"
 #include "sysemu/hostmem.h"
 #include "sysemu/numa.h"
 #include "sysemu/sysemu.h"
@@ -198,6 +199,173 @@ void parse_numa_distance(MachineState *ms, 
NumaDistOptions *dist, Error **errp)
 ms->numa_state->have_numa_distance = true;
 }
 
+void parse_numa_hmat_lb(NumaState *numa_state, NumaHmatLBOptions *node,
+Error **errp)
+{
+int i, first_bit, last_bit;
+uint64_t max_entry, temp_base_la;
+NodeInfo *numa_info = numa_state->nodes;
+HMAT_LB_Info *hmat_lb =
+numa_state->hmat_lb[node->hierarchy][node->data_type];
+HMAT_LB_Data lb_data = {};
+HMAT_LB_Data *lb_temp;
+
+/* Error checking */
+if (node->initiator > numa_state->num_nodes) {
+error_setg(errp, "Invalid initiator=%d, it should be less than %d",
+   node->initiator, numa_state->num_nodes);
+return;
+}
+if (node->target > numa_state->num_nodes) {
+error_setg(errp, "Invalid target=%d, it should be less than %d",
+   node->target, numa_state->num_nodes);
+return;
+}
+if (!numa_info[node->initiator].has_cpu) {
+error_setg(errp, "Invalid initiator=%d, it isn't an "
+   "initiator proximity domain", node->initiator);
+return;
+}
+if (!numa_info[node->target].present) {
+error_setg(errp, "The target=%d should point to an existing node",
+   node->target);
+return;
+}
+
+if (!hmat_lb) {
+hmat_lb = g_malloc0(sizeof(*hmat_lb));
+numa_state->hmat_lb[node->hierarchy][node->data_type] = hmat_lb;
+hmat_lb->list = g_array_new(false, true, sizeof(HMAT_LB_Data));
+}
+hmat_lb->hierarchy = node->hierarchy;
+hmat_lb->data_type = node->data_type;
+lb_data.initiator = node->initiator;
+lb_data.target = node->target;
+
+if (node->data_type <= HMATLB_DATA_TYPE_WRITE_LATENCY) {
+/* Input latency data */
+
+if (!node->has_latency) {
+error_setg(errp, "Missing 'latency' option");
+return;
+}
+if (node->has_bandwidth) {
+error_setg(errp, "Invalid option 'bandwidth' since "
+   "the data type is latency");
+return;
+}
+
+/* Detect duplicate configuration */
+for (i = 0; i < hmat_lb->list->len; i++) {
+lb_temp = &g_array_index(hmat_lb->list, HMAT_LB_Data, i);
+
+if (node->initiator == lb_temp->initiator &&
+node->target == lb_temp->target) {
+error_setg(errp, "Duplicate configuration of the latency for "
+"initiator=%d and target=%d", node->initiator,
+node->target);
+return;
+}
+}
+
+hmat_lb->base = hmat_lb->base ? hmat_lb->base : UINT64_MAX;
+
+if (node->latency) {
+/* Calculate the temporary base and compressed latency */
+max_entry = node->latency;
+temp_base_la = 1;
+while (QEMU_IS_ALIGNED(max_entry, 10)) {
+max_entry /= 10;
+temp_base_la *= 10;
+}
+
+/* Calculate the max compressed latency */
+hmat_lb->base = MIN(hmat_lb->base, temp_base_la);
+max_entry = node->latency / hmat_lb->base;
+hmat_lb->range_bitmap = MAX(hmat_lb->rang

[PATCH v19 8/8] 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 
---

No changes in v19.

Changes in v18:
- Remove unit "ns".

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..cb1de58053 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=1"
+  " -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=65534"
+  " -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, "aarch

[PATCH v19 4/8] hmat acpi: Build Memory Proximity Domain Attributes Structure(s)

[Tao Xu]

From: Liu Jingqi 

HMAT is defined in ACPI 6.3: 5.2.27 Heterogeneous Memory Attribute Table
(HMAT). The specification references below link:
http://www.uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf

It describes the memory attributes, such as memory side cache
attributes and bandwidth and latency details, related to the
Memory Proximity Domain. The software is
expected to use this information as hint for optimization.

This structure describes Memory Proximity Domain Attributes by memory
subsystem and its associativity with processor proximity domain as well as
hint for memory usage.

In the linux kernel, the codes in drivers/acpi/hmat/hmat.c parse and report
the platform's HMAT tables.

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

No changes in v19.

Changes in v16:
- Use uint32_t for initiator and mem_node

Changes in v13:
- Remove the unnecessary head file.
---
 hw/acpi/Kconfig   |  7 ++-
 hw/acpi/Makefile.objs |  1 +
 hw/acpi/hmat.c| 99 +++
 hw/acpi/hmat.h| 42 ++
 hw/i386/acpi-build.c  |  5 +++
 5 files changed, 152 insertions(+), 2 deletions(-)
 create mode 100644 hw/acpi/hmat.c
 create mode 100644 hw/acpi/hmat.h

diff --git a/hw/acpi/Kconfig b/hw/acpi/Kconfig
index 12e3f1e86e..54209c6f2f 100644
--- a/hw/acpi/Kconfig
+++ b/hw/acpi/Kconfig
@@ -7,6 +7,7 @@ config ACPI_X86
 select ACPI_NVDIMM
 select ACPI_CPU_HOTPLUG
 select ACPI_MEMORY_HOTPLUG
+select ACPI_HMAT
 
 config ACPI_X86_ICH
 bool
@@ -23,6 +24,10 @@ config ACPI_NVDIMM
 bool
 depends on ACPI
 
+config ACPI_HMAT
+bool
+depends on ACPI
+
 config ACPI_PCI
 bool
 depends on ACPI && PCI
@@ -33,5 +38,3 @@ config ACPI_VMGENID
 depends on PC
 
 config ACPI_HW_REDUCED
-bool
-depends on ACPI
diff --git a/hw/acpi/Makefile.objs b/hw/acpi/Makefile.objs
index 655a9c1973..517bd88704 100644
--- a/hw/acpi/Makefile.objs
+++ b/hw/acpi/Makefile.objs
@@ -7,6 +7,7 @@ common-obj-$(CONFIG_ACPI_CPU_HOTPLUG) += cpu.o
 common-obj-$(CONFIG_ACPI_NVDIMM) += nvdimm.o
 common-obj-$(CONFIG_ACPI_VMGENID) += vmgenid.o
 common-obj-$(CONFIG_ACPI_HW_REDUCED) += generic_event_device.o
+common-obj-$(CONFIG_ACPI_HMAT) += hmat.o
 common-obj-$(call lnot,$(CONFIG_ACPI_X86)) += acpi-stub.o
 
 common-obj-y += acpi_interface.o
diff --git a/hw/acpi/hmat.c b/hw/acpi/hmat.c
new file mode 100644
index 00..9ff79308a4
--- /dev/null
+++ b/hw/acpi/hmat.c
@@ -0,0 +1,99 @@
+/*
+ * HMAT ACPI Implementation
+ *
+ * Copyright(C) 2019 Intel Corporation.
+ *
+ * Author:
+ *  Liu jingqi 
+ *  Tao Xu 
+ *
+ * HMAT is defined in ACPI 6.3: 5.2.27 Heterogeneous Memory Attribute Table
+ * (HMAT)
+ *
+ * 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 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 "sysemu/numa.h"
+#include "hw/acpi/hmat.h"
+
+/*
+ * ACPI 6.3:
+ * 5.2.27.3 Memory Proximity Domain Attributes Structure: Table 5-145
+ */
+static void build_hmat_mpda(GArray *table_data, uint16_t flags,
+uint32_t initiator, uint32_t mem_node)
+{
+
+/* Memory Proximity Domain Attributes Structure */
+/* Type */
+build_append_int_noprefix(table_data, 0, 2);
+/* Reserved */
+build_append_int_noprefix(table_data, 0, 2);
+/* Length */
+build_append_int_noprefix(table_data, 40, 4);
+/* Flags */
+build_append_int_noprefix(table_data, flags, 2);
+/* Reserved */
+build_append_int_noprefix(table_data, 0, 2);
+/* Proximity Domain for the Attached Initiator */
+build_append_int_noprefix(table_data, initiator, 4);
+/* Proximity Domain for the Memory */
+build_append_int_noprefix(table_data, mem_node, 4);
+/* Reserved */
+build_append_int_noprefix(table_data, 0, 4);
+/*
+ * Reserved:
+ * Previously defined as the Start Address of the System Physical
+ * Address Range. Deprecated since ACPI Spec 6.3.
+ */
+build_append_int_noprefix(table_data, 0, 8);
+/*
+ * Reserved:
+ * Previously defined as the Range Length of the region in bytes.
+ * Deprecated since ACPI Spec 6.3.
+ */
+build_append_int_noprefix(table_data, 0, 8);
+}
+
+/* Build HMAT sub table structures */
+static void hmat_build_table_structs(GArray *table_data, NumaStat

[PATCH v19 5/8] hmat acpi: Build System Locality Latency and Bandwidth Information Structure(s)

[Tao Xu]

From: Liu Jingqi 

This structure describes the memory access latency and bandwidth
information from various memory access initiator proximity domains.
The latency and bandwidth numbers represented in this structure
correspond to rated latency and bandwidth for the platform.
The software could use this information as hint for optimization.

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

No changes in 19.

Changes in v17:
- Remove unnecessary header file (Igor)

Changes in v16:
- Add more description for lb_length (Igor)
- Drop entry_list and calculate entries in this patch (Igor)

Changes in v13:
- Calculate the entries in a new patch.
---
 hw/acpi/hmat.c | 104 -
 1 file changed, 103 insertions(+), 1 deletion(-)

diff --git a/hw/acpi/hmat.c b/hw/acpi/hmat.c
index 9ff79308a4..e5ee8b4317 100644
--- a/hw/acpi/hmat.c
+++ b/hw/acpi/hmat.c
@@ -25,6 +25,7 @@
  */
 
 #include "qemu/osdep.h"
+#include "qemu/units.h"
 #include "sysemu/numa.h"
 #include "hw/acpi/hmat.h"
 
@@ -67,11 +68,89 @@ static void build_hmat_mpda(GArray *table_data, uint16_t 
flags,
 build_append_int_noprefix(table_data, 0, 8);
 }
 
+/*
+ * ACPI 6.3: 5.2.27.4 System Locality Latency and Bandwidth Information
+ * Structure: Table 5-146
+ */
+static void build_hmat_lb(GArray *table_data, HMAT_LB_Info *hmat_lb,
+  uint32_t num_initiator, uint32_t num_target,
+  uint32_t *initiator_list)
+{
+int i, index;
+HMAT_LB_Data *lb_data;
+uint16_t *entry_list;
+uint32_t base;
+/* Length in bytes for entire structure */
+uint32_t lb_length
+= 32 /* Table length upto and including Entry Base Unit */
++ 4 * num_initiator /* Initiator Proximity Domain List */
++ 4 * num_target /* Target Proximity Domain List */
++ 2 * num_initiator * num_target; /* Latency or Bandwidth Entries */
+
+/* Type */
+build_append_int_noprefix(table_data, 1, 2);
+/* Reserved */
+build_append_int_noprefix(table_data, 0, 2);
+/* Length */
+build_append_int_noprefix(table_data, lb_length, 4);
+/* Flags: Bits [3:0] Memory Hierarchy, Bits[7:4] Reserved */
+assert(!(hmat_lb->hierarchy >> 4));
+build_append_int_noprefix(table_data, hmat_lb->hierarchy, 1);
+/* Data Type */
+build_append_int_noprefix(table_data, hmat_lb->data_type, 1);
+/* Reserved */
+build_append_int_noprefix(table_data, 0, 2);
+/* Number of Initiator Proximity Domains (s) */
+build_append_int_noprefix(table_data, num_initiator, 4);
+/* Number of Target Proximity Domains (t) */
+build_append_int_noprefix(table_data, num_target, 4);
+/* Reserved */
+build_append_int_noprefix(table_data, 0, 4);
+
+/* Entry Base Unit */
+if (hmat_lb->data_type <= HMAT_LB_DATA_WRITE_LATENCY) {
+/* Convert latency base from nanoseconds to picosecond */
+base = hmat_lb->base * 1000;
+} else {
+/* Convert bandwidth base from Byte to Megabyte */
+base = hmat_lb->base / MiB;
+}
+build_append_int_noprefix(table_data, base, 8);
+
+/* Initiator Proximity Domain List */
+for (i = 0; i < num_initiator; i++) {
+build_append_int_noprefix(table_data, initiator_list[i], 4);
+}
+
+/* Target Proximity Domain List */
+for (i = 0; i < num_target; i++) {
+build_append_int_noprefix(table_data, i, 4);
+}
+
+/* Latency or Bandwidth Entries */
+entry_list = g_malloc0(hmat_lb->list->len * sizeof(uint16_t));
+for (i = 0; i < hmat_lb->list->len; i++) {
+lb_data = &g_array_index(hmat_lb->list, HMAT_LB_Data, i);
+index = lb_data->initiator * num_target + lb_data->target;
+
+entry_list[index] = (uint16_t)(lb_data->data / hmat_lb->base);
+}
+
+for (i = 0; i < num_initiator * num_target; i++) {
+build_append_int_noprefix(table_data, entry_list[i], 2);
+}
+
+g_free(entry_list);
+}
+
 /* Build HMAT sub table structures */
 static void hmat_build_table_structs(GArray *table_data, NumaState *numa_state)
 {
 uint16_t flags;
-int i;
+uint32_t num_initiator = 0;
+uint32_t initiator_list[MAX_NODES];
+int i, hierarchy, type;
+HMAT_LB_Info *hmat_lb;
 
 for (i = 0; i < numa_state->num_nodes; i++) {
 flags = 0;
@@ -82,6 +161,29 @@ static void hmat_build_table_structs(GArray *table_data, 
NumaState *numa_state)
 
 build_hmat_mpda(table_data, flags, numa_state->nodes[i].initiator, i);
 }
+
+for (i = 0; i < numa_state->num_nodes; i++) {
+if (numa_state->nodes[i].has_cpu) {
+initiator_list[num_initiator++] = i;
+}
+}
+
+/*
+ * ACPI 6.3: 5.2.27.4 System Locality Latency and Bandwidth Information
+ * Structure: Table 5-146
+ */
+for (hierarchy = HMAT_LB_MEM_MEMORY;
+ hierarchy <= HMAT_LB_MEM_CACHE_3RD_LEVEL; hierarchy++) {
+for (type = HMAT_LB_DATA

Re: [PATCH v6] block/snapshot: rename Error ** parameter to more common errp

[Max Reitz]

On 27.11.19 20:25, Vladimir Sementsov-Ogievskiy wrote:
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> Reviewed-by: Eric Blake 
> ---
> 
> v6: merge corresponding header change here, so, v6 is merge of
>   [RFC v5 011/126] block/snapshot: rename Error ** parameter to more common 
> errp
>   and
>   [RFC v5 019/126] include/block/snapshot.h: rename Error ** parameter to 
> more common errp
>   both has Eric's r-b, so I keep Eric's r-b for the merge
> 
>  include/block/snapshot.h | 2 +-
>  block/snapshot.c | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)

Thanks, applied to my block-next branch:

https://git.xanclic.moe/XanClic/qemu/commits/branch/block-next

Max



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v4 4/6] s390x: Move clear reset

[Janosch Frank]

On 11/28/19 8:09 AM, Thomas Huth wrote:
> On 27/11/2019 18.50, Janosch Frank wrote:
>> Let's also move the clear reset function into the reset handler.
>>
>> Signed-off-by: Janosch Frank 
>> ---
>>   target/s390x/cpu-qom.h |  1 +
>>   target/s390x/cpu.c | 58 +-
>>   2 files changed, 18 insertions(+), 41 deletions(-)
> 
> I really wonder why we had so much duplicated code here before and 
> nobody dared to clean it up in all those years... Thanks for doing that now!

Looking back at my old patch series, I most often start with a cleanup
before I change or add anything...

I'd guess that QEMU hasn't seen some love for a longer time.

> 
> Reviewed-by: Thomas Huth 
> 

Thanks!




signature.asc
Description: OpenPGP digital signature

[PATCH v5] s390x: Move initial reset

[Janosch Frank]

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

Signed-off-by: Janosch Frank 
Reviewed-by: David Hildenbrand 
---

Fixed the kvm vcpu reset.

---
 target/s390x/cpu-qom.h |  2 +-
 target/s390x/cpu.c | 46 +-
 target/s390x/cpu.h |  2 +-
 target/s390x/sigp.c|  2 +-
 4 files changed, 21 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 67d6fbfa44..ca62fe7685 100644
--- a/target/s390x/cpu.c
+++ b/target/s390x/cpu.c
@@ -94,6 +94,23 @@ 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);
+   /* fall through */
 case S390_CPU_RESET_NORMAL:
 env->pfault_token = -1UL;
 env->bpbc = false;
@@ -101,35 +118,9 @@ static void s390_cpu_reset(CPUState *s, cpu_reset_type 
type)
 default:
 g_assert_not_reached();
 }
-}
-
-/* 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()) {
+if (kvm_enabled() && type != S390_CPU_RESET_NORMAL) {
 kvm_s390_reset_vcpu(cpu);
 }
 }
@@ -481,7 +472,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

Re: [PATCH v4 4/6] s390x: Move clear reset

[David Hildenbrand]

On 28.11.19 09:35, Janosch Frank wrote:
> On 11/28/19 8:09 AM, Thomas Huth wrote:
>> On 27/11/2019 18.50, Janosch Frank wrote:
>>> Let's also move the clear reset function into the reset handler.
>>>
>>> Signed-off-by: Janosch Frank 
>>> ---
>>>   target/s390x/cpu-qom.h |  1 +
>>>   target/s390x/cpu.c | 58 +-
>>>   2 files changed, 18 insertions(+), 41 deletions(-)
>>
>> I really wonder why we had so much duplicated code here before and 
>> nobody dared to clean it up in all those years... Thanks for doing that now!
> 
> Looking back at my old patch series, I most often start with a cleanup
> before I change or add anything...
> 
> I'd guess that QEMU hasn't seen some love for a longer time.

Oh, I give QEMU some love quite often ... I just can't love every part
of it equally well ;)

I'd like to second the "thanks" for doing this cleanup :)

-- 
Thanks,

David / dhildenb

[PATCH] block/nbd: fix memory leak in nbd_open()

[pannengyuan]

From: PanNengyuan 

In currently implementation there will be a memory leak when
nbd_client_connect() returns error status. Here is an easy way to reproduce:

1. run qemu-iotests as follow and check the result with asan:
./check -raw 143

Following is the asan output backtrack:
Direct leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7f629688a560 in calloc (/usr/lib64/libasan.so.3+0xc7560)
#1 0x7f6295e7e015 in g_malloc0  (/usr/lib64/libglib-2.0.so.0+0x50015)
#2 0x56281dab4642 in qobject_input_start_struct  
/mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:295
#3 0x56281dab1a04 in visit_start_struct  
/mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:49
#4 0x56281dad1827 in visit_type_SocketAddress  qapi/qapi-visit-sockets.c:386
#5 0x56281da8062f in nbd_config  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
#6 0x56281da8062f in nbd_process_options  
/mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
#7 0x56281da8062f in nbd_open  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873

Direct leak of 15 byte(s) in 1 object(s) allocated from:
#0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
#1 0x7f6295e7dfbd in g_malloc  (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
#2 0x7f6295e96ace in g_strdup  (/usr/lib64/libglib-2.0.so.0+0x68ace)
#3 0x56281da804ac in nbd_process_options 
/mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1834
#4 0x56281da804ac in nbd_open  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873

Indirect leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
#1 0x7f6295e7dfbd in g_malloc (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
#2 0x7f6295e96ace in g_strdup (/usr/lib64/libglib-2.0.so.0+0x68ace)
#3 0x56281dab41a3 in qobject_input_type_str_keyval   
/mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:536
#4 0x56281dab2ee9 in visit_type_str   
/mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:297
#5 0x56281dad0fa1 in visit_type_UnixSocketAddress_members  
qapi/qapi-visit-sockets.c:141
#6 0x56281dad17b6 in visit_type_SocketAddress_members  
qapi/qapi-visit-sockets.c:366
#7 0x56281dad186a in visit_type_SocketAddress 
qapi/qapi-visit-sockets.c:393
#8 0x56281da8062f in nbd_config   /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
#9 0x56281da8062f in nbd_process_options   
/mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
#10 0x56281da8062f in nbd_open  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873

Reported-by: Euler Robot 
Signed-off-by: PanNengyuan 
---
 block/nbd.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/block/nbd.c b/block/nbd.c
index 1239761..bc40a25 100644
--- a/block/nbd.c
+++ b/block/nbd.c
@@ -1881,6 +1881,11 @@ static int nbd_open(BlockDriverState *bs, QDict 
*options, int flags,
 
 ret = nbd_client_connect(bs, errp);
 if (ret < 0) {
+object_unref(OBJECT(s->tlscreds));
+qapi_free_SocketAddress(s->saddr);
+g_free(s->export);
+g_free(s->tlscredsid);
+g_free(s->x_dirty_bitmap);
 return ret;
 }
 /* successfully connected */
-- 
2.7.2.windows.1

Re: [PATCH 2/4] target/arm: Abstract the generic timer frequency

[Cédric Le Goater]

On 28/11/2019 06:45, Andrew Jeffery wrote:
> Prepare for SoCs such as the ASPEED AST2600 whose firmware configures
> CNTFRQ to values significantly larger than the static 62.5MHz value
> currently derived from GTIMER_SCALE. As the OS potentially derives its
> timer periods from the CNTFRQ value the lack of support for running
> QEMUTimers at the appropriate rate leads to sticky behaviour in the
> guest.
> 
> Substitute the GTIMER_SCALE constant with use of a helper to derive the
> period from gt_cntfrq stored in struct ARMCPU. Initially set gt_cntfrq
> to the frequency associated with GTIMER_SCALE so current behaviour is
> maintained.
> 
> Signed-off-by: Andrew Jeffery 
> ---
>  target/arm/cpu.c|  2 ++
>  target/arm/cpu.h| 10 ++
>  target/arm/helper.c | 10 +++---
>  3 files changed, 19 insertions(+), 3 deletions(-)
> 
> diff --git a/target/arm/cpu.c b/target/arm/cpu.c
> index 7a4ac9339bf9..5698a74061bb 100644
> --- a/target/arm/cpu.c
> +++ b/target/arm/cpu.c
> @@ -974,6 +974,8 @@ static void arm_cpu_initfn(Object *obj)
>  if (tcg_enabled()) {
>  cpu->psci_version = 2; /* TCG implements PSCI 0.2 */
>  }
> +
> +cpu->gt_cntfrq = NANOSECONDS_PER_SECOND / GTIMER_SCALE;
>  }
>  
>  static Property arm_cpu_reset_cbar_property =
> diff --git a/target/arm/cpu.h b/target/arm/cpu.h
> index 83a809d4bac4..666c03871fdf 100644
> --- a/target/arm/cpu.h
> +++ b/target/arm/cpu.h
> @@ -932,8 +932,18 @@ struct ARMCPU {
>   */
>  DECLARE_BITMAP(sve_vq_map, ARM_MAX_VQ);
>  DECLARE_BITMAP(sve_vq_init, ARM_MAX_VQ);
> +
> +/* Generic timer counter frequency, in Hz */
> +uint64_t gt_cntfrq;
>  };
>  
> +static inline unsigned int gt_cntfrq_period_ns(ARMCPU *cpu)
> +{
> +/* XXX: Could include qemu/timer.h to get NANOSECONDS_PER_SECOND? */
> +const unsigned int ns_per_s = 1000 * 1000 * 1000;
> +return ns_per_s > cpu->gt_cntfrq ? ns_per_s / cpu->gt_cntfrq : 1;
> +}

Are you inlining this helper for performance reasons ? 

C. 


>  void arm_cpu_post_init(Object *obj);
>  
>  uint64_t arm_cpu_mp_affinity(int idx, uint8_t clustersz);
> diff --git a/target/arm/helper.c b/target/arm/helper.c
> index 65c4441a3896..1cc0551081a0 100644
> --- a/target/arm/helper.c
> +++ b/target/arm/helper.c
> @@ -2409,7 +2409,9 @@ static CPAccessResult gt_stimer_access(CPUARMState *env,
>  
>  static uint64_t gt_get_countervalue(CPUARMState *env)
>  {
> -return qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) / GTIMER_SCALE;
> +ARMCPU *cpu = env_archcpu(env);
> +
> +return qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) / gt_cntfrq_period_ns(cpu);
>  }
>  
>  static void gt_recalc_timer(ARMCPU *cpu, int timeridx)
> @@ -2445,7 +2447,7 @@ static void gt_recalc_timer(ARMCPU *cpu, int timeridx)
>   * set the timer for as far in the future as possible. When the
>   * timer expires we will reset the timer for any remaining period.
>   */
> -if (nexttick > INT64_MAX / GTIMER_SCALE) {
> +if (nexttick > INT64_MAX / gt_cntfrq_period_ns(cpu)) {
>  timer_mod_ns(cpu->gt_timer[timeridx], INT64_MAX);
>  } else {
>  timer_mod(cpu->gt_timer[timeridx], nexttick);
> @@ -2874,11 +2876,13 @@ static const ARMCPRegInfo generic_timer_cp_reginfo[] 
> = {
>  
>  static uint64_t gt_virt_cnt_read(CPUARMState *env, const ARMCPRegInfo *ri)
>  {
> +ARMCPU *cpu = env_archcpu(env);
> +
>  /* Currently we have no support for QEMUTimer in linux-user so we
>   * can't call gt_get_countervalue(env), instead we directly
>   * call the lower level functions.
>   */
> -return cpu_get_clock() / GTIMER_SCALE;
> +return cpu_get_clock() / gt_cntfrq_period(cpu);
>  }
>  
>  static const ARMCPRegInfo generic_timer_cp_reginfo[] = {
> 

Re: [PATCH 4/4] ast2600: Configure CNTFRQ at 1125MHz

[Cédric Le Goater]

On 28/11/2019 06:45, Andrew Jeffery wrote:
> This matches the configuration set by u-boot on the AST2600.
> 
> Signed-off-by: Andrew Jeffery 

Reviewed-by: Cédric Le Goater 

> ---
>  hw/arm/aspeed_ast2600.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/hw/arm/aspeed_ast2600.c b/hw/arm/aspeed_ast2600.c
> index 931887ac681f..5aecc3b3caec 100644
> --- a/hw/arm/aspeed_ast2600.c
> +++ b/hw/arm/aspeed_ast2600.c
> @@ -259,6 +259,9 @@ static void aspeed_soc_ast2600_realize(DeviceState *dev, 
> Error **errp)
>  object_property_set_int(OBJECT(&s->cpu[i]), aspeed_calc_affinity(i),
>  "mp-affinity", &error_abort);
>  
> +object_property_set_int(OBJECT(&s->cpu[i]), 112500, "cntfrq",
> +&error_abort);
> +
>  /*
>   * TODO: the secondary CPUs are started and a boot helper
>   * is needed when using -kernel
> 

Re: [PATCH 1/4] target/arm: Remove redundant scaling of nexttick

[Cédric Le Goater]

On 28/11/2019 06:45, Andrew Jeffery wrote:
> The corner-case codepath was adjusting nexttick such that overflow
> wouldn't occur when timer_mod() scaled the value back up. Remove a use
> of GTIMER_SCALE and avoid unnecessary operations by calling
> timer_mod_ns() directly.
> 
> Signed-off-by: Andrew Jeffery 

Reviewed-by: Cédric Le Goater 


> ---
>  target/arm/helper.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/target/arm/helper.c b/target/arm/helper.c
> index a089fb5a6909..65c4441a3896 100644
> --- a/target/arm/helper.c
> +++ b/target/arm/helper.c
> @@ -2446,9 +2446,10 @@ static void gt_recalc_timer(ARMCPU *cpu, int timeridx)
>   * timer expires we will reset the timer for any remaining period.
>   */
>  if (nexttick > INT64_MAX / GTIMER_SCALE) {
> -nexttick = INT64_MAX / GTIMER_SCALE;
> +timer_mod_ns(cpu->gt_timer[timeridx], INT64_MAX);
> +} else {
> +timer_mod(cpu->gt_timer[timeridx], nexttick);
>  }
> -timer_mod(cpu->gt_timer[timeridx], nexttick);
>  trace_arm_gt_recalc(timeridx, irqstate, nexttick);
>  } else {
>  /* Timer disabled: ISTATUS and timer output always clear */
> 

Re: [RFC v5 000/126] error: auto propagated local_err

[Markus Armbruster]

Please accept my sincere apologies for taking so long to reply.  A few
thoughts before I dig deeper.

Vladimir Sementsov-Ogievskiy  writes:

> Hi all!
>
> At the request of Markus: full version of errp propagation. Let's look
> at it. Cover as much as possible, except inserting macro invocation
> where it's not necessary.
>
> It's huge, and so it's an RFC.

It's a monster.  Best to get it into full view before we commit to
fighting it.

> In v5 I've added a lot more preparation cleanups:
> 01-23 are preparation cleanups
>   01: not changed, keep Eric's r-b
>   02: improve commit msg [Markus], keep Eric's r-b
>   03: changed, only error API here, drop r-b
> 24 is core macro
>   - improve cover letter, wording and macro code style
>   - keep Eric's r-b
> 25-26: automation scripts
>- commit-per-subsystem changed a lot. it's a draft, don't bother too
>  much with it
>- coccinelle: add support of error_propagate_prepend
>
> 27-126: generated patches

Splitting up the monster can make fighting it easier.

Your description suggests three high-level parts:

Part 1: Preparation (makes sense by itself)
Part 2: Error interface update (with rules what code should do now)
Part 3: Make the code obey the new rules everywhere

I hope we can get part 1 out of the way quickly.  Diffstat:

 backends/cryptodev.c   |  11 +---
 block/nbd.c|  10 +--
 block/snapshot.c   |   4 +-
 dump/dump-hmp-cmds.c   |   4 +-
 hw/9pfs/9p-local.c |   4 +-
 hw/9pfs/9p-proxy.c |   5 +-
 hw/core/loader-fit.c   |   5 +-
 hw/core/machine-hmp-cmds.c |   6 +-
 hw/core/qdev.c |  28 
 hw/i386/amd_iommu.c|  14 ++--
 hw/ppc/spapr.c |   2 +-
 hw/s390x/event-facility.c  |   2 +-
 hw/s390x/s390-stattrib.c   |   3 +-
 hw/sd/sdhci.c  |   2 +-
 hw/tpm/tpm_emulator.c  |   8 +--
 hw/usb/dev-network.c   |   2 +-
 hw/vfio/ap.c   |  16 +
 include/block/snapshot.h   |   2 +-
 include/monitor/hmp.h  |   2 +-
 include/qapi/error.h   |  69 ++--
 include/qom/object.h   |   4 +-
 monitor/hmp-cmds.c | 155 ++---
 monitor/qmp-cmds.c |   2 +-
 net/net.c  |  17 ++---
 qdev-monitor.c |  28 
 qga/commands-posix.c   |   2 +-
 qga/commands-win32.c   |   2 +-
 qga/commands.c |  12 ++--
 qom/qom-hmp-cmds.c |   4 +-
 target/ppc/kvm.c   |   6 +-
 target/ppc/kvm_ppc.h   |   4 +-
 ui/vnc.c   |  20 ++
 ui/vnc.h   |   2 +-
 util/error.c   |  30 -
 34 files changed, 261 insertions(+), 226 deletions(-)

At first glance, I can see bug fixes, non-mechanical cleanups, and
mechanical cleanups.

Within each of these three groups, we have related sub-groups.  For
instance, several patches clean up funny names for the common Error **
parameters.  Several more rename "uncommon" Error ** parameters, to
signal their uncommon role.  I doubt splitting up these subgroups of
related mechanical changes along subsystem lines is worthwhile.

Part 2 needs careful interface review.  Having part 3 ready helps there,
because we can see rather than guess how the interface changes play out.
We really want to get this part right from the start, because if we
don't, we get to do part 3 again.

Part 3 is what makes this a monster.  I understand it's mechanical.  We
can merge it incrementally, but we do want to merge it all, and sooner
rather than later, to avoid a mix of old and new error handling code.
Such mixes inevitably confuse developers, and lead to new instances of
the old patterns creeping in.

I do have doubts about your automated split.

I acknowledge maintainers of active subsystems may want to merge this on
their own terms, to minimize disruption.  Splitting off sub-monsters for
them makes sense.  Splitting off the long tail of less busy subsystems
not so much; it'll only drag out the merging.  Your list below shows 100
parts, and chasing their maintainers is not going to be a fun
experience.

Moreover, using MAINTAINERS to guide an automatic split is a cute idea,
but it falls apart when MAINTAINERS attributes the same file to several
subsystems, which is fairly common.  A sane split requires human touch.

Instead, I'd start with big subsystems with maintainers known to be
sympathetic to this effort.  Split off their sub-monsters, get them
merged.  Iterate until the remainder can be merged in one final push.

> 
>
> Here is a proposal of auto propagation for local_err, to not call
> error_propagate on every exit point, when we deal with local_err.

More cleverness, less code, avoids one kind of error (forgetting manual
propagate when we should), risks another kind of error (automatic
propagate when we shouldn't).  Tradeoffs, but the general feeling among
reviewers appears to be positive.

> There are also two issues with errp:
>
> 1. error_fatal & err

Re: [PATCH] block/nbd: fix memory leak in nbd_open()

[Stefano Garzarella]

On Thu, Nov 28, 2019 at 04:40:10PM +0800, pannengy...@huawei.com wrote:

Hi,
I don't know nbd code very well, the patch LGTM, but just a comment
below:

> From: PanNengyuan 
> 
> In currently implementation there will be a memory leak when
> nbd_client_connect() returns error status. Here is an easy way to reproduce:
> 
> 1. run qemu-iotests as follow and check the result with asan:
> ./check -raw 143
> 
> Following is the asan output backtrack:
> Direct leak of 40 byte(s) in 1 object(s) allocated from:
> #0 0x7f629688a560 in calloc (/usr/lib64/libasan.so.3+0xc7560)
> #1 0x7f6295e7e015 in g_malloc0  (/usr/lib64/libglib-2.0.so.0+0x50015)
> #2 0x56281dab4642 in qobject_input_start_struct  
> /mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:295
> #3 0x56281dab1a04 in visit_start_struct  
> /mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:49
> #4 0x56281dad1827 in visit_type_SocketAddress  
> qapi/qapi-visit-sockets.c:386
> #5 0x56281da8062f in nbd_config  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
> #6 0x56281da8062f in nbd_process_options  
> /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
> #7 0x56281da8062f in nbd_open  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
> 
> Direct leak of 15 byte(s) in 1 object(s) allocated from:
> #0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
> #1 0x7f6295e7dfbd in g_malloc  (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
> #2 0x7f6295e96ace in g_strdup  (/usr/lib64/libglib-2.0.so.0+0x68ace)
> #3 0x56281da804ac in nbd_process_options 
> /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1834
> #4 0x56281da804ac in nbd_open  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
> 
> Indirect leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
> #1 0x7f6295e7dfbd in g_malloc (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
> #2 0x7f6295e96ace in g_strdup (/usr/lib64/libglib-2.0.so.0+0x68ace)
> #3 0x56281dab41a3 in qobject_input_type_str_keyval   
> /mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:536
> #4 0x56281dab2ee9 in visit_type_str   
> /mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:297
> #5 0x56281dad0fa1 in visit_type_UnixSocketAddress_members  
> qapi/qapi-visit-sockets.c:141
> #6 0x56281dad17b6 in visit_type_SocketAddress_members  
> qapi/qapi-visit-sockets.c:366
> #7 0x56281dad186a in visit_type_SocketAddress 
> qapi/qapi-visit-sockets.c:393
> #8 0x56281da8062f in nbd_config   /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
> #9 0x56281da8062f in nbd_process_options   
> /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
> #10 0x56281da8062f in nbd_open  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
> 
> Reported-by: Euler Robot 
> Signed-off-by: PanNengyuan 
> ---
>  block/nbd.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/block/nbd.c b/block/nbd.c
> index 1239761..bc40a25 100644
> --- a/block/nbd.c
> +++ b/block/nbd.c
> @@ -1881,6 +1881,11 @@ static int nbd_open(BlockDriverState *bs, QDict 
> *options, int flags,
>  
>  ret = nbd_client_connect(bs, errp);
>  if (ret < 0) {
> +object_unref(OBJECT(s->tlscreds));
> +qapi_free_SocketAddress(s->saddr);
> +g_free(s->export);
> +g_free(s->tlscredsid);
> +g_free(s->x_dirty_bitmap);

Since with this patch we are doing these cleanups in 3 places (here,
nbd_close(), and nbd_process_options()), should be better to add a new
function to do these cleanups?

Maybe I'd create a series adding a patch before this one, implementing this
new function, and change this patch calling it.

Thanks,
Stefano

[Bug 1846427] Re: 4.1.0: qcow2 corruption on savevm/quit/loadvm cycle

[Michael Weiser]

All my images are still fine after some heavy use with qemu-4.1.0 and
fix patches applied. Just upgraded to 4.1.1 and will report back. But
it's certainly looks like this bug is fixed for good.

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

Title:
  4.1.0: qcow2 corruption on savevm/quit/loadvm cycle

Status in QEMU:
  Fix Committed

Bug description:
  I'm seeing massive corruption of qcow2 images with qemu 4.1.0 and git
  master as of 7f21573c822805a8e6be379d9bcf3ad9effef3dc after a few
  savevm/quit/loadvm cycles. I've narrowed it down to the following
  reproducer (further notes below):

  # qemu-img check debian.qcow2
  No errors were found on the image.
  251601/327680 = 76.78% allocated, 1.63% fragmented, 0.00% compressed clusters
  Image end offset: 18340446208
  # bin/qemu/bin/qemu-system-x86_64 -machine pc-q35-4.0.1,accel=kvm -m 4096 
-chardev stdio,id=charmonitor -mon chardev=charmonitor -drive 
file=debian.qcow2,id=d -S
  qemu-system-x86_64: warning: dbind: Couldn't register with accessibility bus: 
Did not receive a reply. Possible causes include: the remote application did 
not send a reply, the message bus security policy blocked the reply, the reply 
timeout expired, or the network connection was broken.
  QEMU 4.1.50 monitor - type 'help' for more information
  (qemu) loadvm foo
  (qemu) c
  (qemu) qcow2_free_clusters failed: Invalid argument
  qcow2_free_clusters failed: Invalid argument
  qcow2_free_clusters failed: Invalid argument
  qcow2_free_clusters failed: Invalid argument
  quit
  [m@nargothrond:~] qemu-img check debian.qcow2
  Leaked cluster 85179 refcount=2 reference=1
  Leaked cluster 85180 refcount=2 reference=1
  ERROR cluster 266150 refcount=0 reference=2
  [...]
  ERROR OFLAG_COPIED data cluster: l2_entry=42284 refcount=1

  9493 errors were found on the image.
  Data may be corrupted, or further writes to the image may corrupt it.

  2 leaked clusters were found on the image.
  This means waste of disk space, but no harm to data.
  259266/327680 = 79.12% allocated, 1.67% fragmented, 0.00% compressed clusters
  Image end offset: 18340446208

  This is on a x86_64 Linux 5.3.1 Gentoo host with qemu-system-x86_64
  and accel=kvm. The compiler is gcc-9.2.0 with the rest of the system
  similarly current.

  Reproduced with qemu-4.1.0 from distribution package as well as
  vanilla git checkout of tag v4.1.0 and commit
  7f21573c822805a8e6be379d9bcf3ad9effef3dc (today's master). Does not
  happen with qemu compiled from vanilla checkout of tag v4.0.0. Build
  sequence:

  ./configure --prefix=$HOME/bin/qemu-bisect --target-list=x86_64-softmmu 
--disable-werror --disable-docs
  [...]
  CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -g
  [...] (can provide full configure output if helpful)
  make -j8 install

  The kind of guest OS does not matter: seen with Debian testing 64bit,
  Windows 7 x86/x64 BIOS and Windows 7 x64 EFI.

  The virtual storage controller does not seem to matter: seen with
  VirtIO SCSI, emulated SCSI and emulated SATA AHCI.

  Caching modes (none, directsync, writeback), aio mode (threads,
  native) or discard (ignore, unmap) or detect-zeroes (off, unmap) does
  not influence occurence either.

  Having more RAM in the guest seems to increase odds of corruption:
  With 512MB to the Debian guest problem hardly occurs at all, with 4GB
  RAM it happens almost instantly.

  An automated reproducer works as follows:

  - the guest *does* mount its root fs and swap with option discard and
  my testing leaves me with the impression that file deletion rather
  than reading is causing the issue

  - foo is a snapshot of the running Debian VM which is already running
  command

  # while true ; do dd if=/dev/zero of=foo bs=10240k count=400 ; done

  to produce some I/O to the disk (4GB file with 4GB of RAM).

  - on the host a loop continuously resumes and saves the guest state
  and quits qemu inbetween:

  # while true ; do (echo loadvm foo ; echo c ; sleep 10 ; echo stop ;
  echo savevm foo ; echo quit ) | bin/qemu-bisect/bin/qemu-system-x86_64
  -machine pc-q35-3.1,accel=kvm -m 4096 -chardev stdio,id=charmonitor
  -mon chardev=charmonitor -drive file=debian.qcow2,id=d -S -display
  none ; done

  - quitting qemu inbetween saves and loads seems to be necessary for
  the problem to occur. Just continusouly in one session saving and
  loading guest state does not trigger it.

  - For me, after about 2 to 6 iterations of above loop the image is
  corrupted.

  - corruption manifests with other messages from qemu as well, e.g.:

  (qemu) loadvm foo
  Error: Device 'd' does not have the requested snapshot 'foo'

  Using above reproducer I have to the be best of my ability bisected
  the introduction of the problem to commit
  69f47505ee66afaa513305de0c1895a224e52c45 (block: avoid recursive
  block_status call if possible). qemu compiled from the comm

Re: [PATCH v5] s390x: Move initial reset

[Thomas Huth]

On 28/11/2019 09.37, Janosch Frank wrote:

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

Signed-off-by: Janosch Frank 
Reviewed-by: David Hildenbrand 
---

Fixed the kvm vcpu reset.

---
  target/s390x/cpu-qom.h |  2 +-
  target/s390x/cpu.c | 46 +-
  target/s390x/cpu.h |  2 +-
  target/s390x/sigp.c|  2 +-
  4 files changed, 21 insertions(+), 31 deletions(-)


Reviewed-by: Thomas Huth 

Re: [RFC v5 000/126] error: auto propagated local_err

[Vladimir Sementsov-Ogievskiy]

28.11.2019 11:54, Markus Armbruster wrote:
> Please accept my sincere apologies for taking so long to reply.  A few
> thoughts before I dig deeper.
> 
> Vladimir Sementsov-Ogievskiy  writes:
> 
>> Hi all!
>>
>> At the request of Markus: full version of errp propagation. Let's look
>> at it. Cover as much as possible, except inserting macro invocation
>> where it's not necessary.
>>
>> It's huge, and so it's an RFC.
> 
> It's a monster.  Best to get it into full view before we commit to
> fighting it.
> 
>> In v5 I've added a lot more preparation cleanups:
>> 01-23 are preparation cleanups
>>01: not changed, keep Eric's r-b
>>02: improve commit msg [Markus], keep Eric's r-b
>>03: changed, only error API here, drop r-b
>> 24 is core macro
>>- improve cover letter, wording and macro code style
>>- keep Eric's r-b
>> 25-26: automation scripts
>> - commit-per-subsystem changed a lot. it's a draft, don't bother too
>>   much with it
>> - coccinelle: add support of error_propagate_prepend
>>
>> 27-126: generated patches
> 
> Splitting up the monster can make fighting it easier.
> 
> Your description suggests three high-level parts:
> 
> Part 1: Preparation (makes sense by itself)

I already resent part 1 all patches (handling review comments) in separate as 
v6.
If it is convenient, I can resend them in one series as v7.

> Part 2: Error interface update (with rules what code should do now)

Note, that patch 21 is actually from part2, not part1.
So Part 2 is 21, 24, 25.
So I wait for your comments and resend (if needed) as separate small series.

And 26 is auto-patch-splitter, but we don't need it now, if we are going
to start from several big subsystems.

> Part 3: Make the code obey the new rules everywhere
> 
> I hope we can get part 1 out of the way quickly.  Diffstat:
> 
>   backends/cryptodev.c   |  11 +---
>   block/nbd.c|  10 +--
>   block/snapshot.c   |   4 +-
>   dump/dump-hmp-cmds.c   |   4 +-
>   hw/9pfs/9p-local.c |   4 +-
>   hw/9pfs/9p-proxy.c |   5 +-
>   hw/core/loader-fit.c   |   5 +-
>   hw/core/machine-hmp-cmds.c |   6 +-
>   hw/core/qdev.c |  28 
>   hw/i386/amd_iommu.c|  14 ++--
>   hw/ppc/spapr.c |   2 +-
>   hw/s390x/event-facility.c  |   2 +-
>   hw/s390x/s390-stattrib.c   |   3 +-
>   hw/sd/sdhci.c  |   2 +-
>   hw/tpm/tpm_emulator.c  |   8 +--
>   hw/usb/dev-network.c   |   2 +-
>   hw/vfio/ap.c   |  16 +
>   include/block/snapshot.h   |   2 +-
>   include/monitor/hmp.h  |   2 +-
>   include/qapi/error.h   |  69 ++--
>   include/qom/object.h   |   4 +-
>   monitor/hmp-cmds.c | 155 
> ++---
>   monitor/qmp-cmds.c |   2 +-
>   net/net.c  |  17 ++---
>   qdev-monitor.c |  28 
>   qga/commands-posix.c   |   2 +-
>   qga/commands-win32.c   |   2 +-
>   qga/commands.c |  12 ++--
>   qom/qom-hmp-cmds.c |   4 +-
>   target/ppc/kvm.c   |   6 +-
>   target/ppc/kvm_ppc.h   |   4 +-
>   ui/vnc.c   |  20 ++
>   ui/vnc.h   |   2 +-
>   util/error.c   |  30 -
>   34 files changed, 261 insertions(+), 226 deletions(-)
> 
> At first glance, I can see bug fixes, non-mechanical cleanups, and
> mechanical cleanups.
> 
> Within each of these three groups, we have related sub-groups.  For
> instance, several patches clean up funny names for the common Error **
> parameters.  Several more rename "uncommon" Error ** parameters, to
> signal their uncommon role.  I doubt splitting up these subgroups of
> related mechanical changes along subsystem lines is worthwhile.
> 
> Part 2 needs careful interface review.  Having part 3 ready helps there,
> because we can see rather than guess how the interface changes play out.
> We really want to get this part right from the start, because if we
> don't, we get to do part 3 again.
> 
> Part 3 is what makes this a monster.  I understand it's mechanical.  We
> can merge it incrementally, but we do want to merge it all, and sooner
> rather than later, to avoid a mix of old and new error handling code.
> Such mixes inevitably confuse developers, and lead to new instances of
> the old patterns creeping in.
> 
> I do have doubts about your automated split.
> 
> I acknowledge maintainers of active subsystems may want to merge this on
> their own terms, to minimize disruption.  Splitting off sub-monsters for
> them makes sense.  Splitting off the long tail of less busy subsystems
> not so much; it'll only drag out the merging.  Your list below shows 100
> parts, and chasing their maintainers is not going to be a fun
> experience.
> 
> Moreover, using MAINTAINERS to guide an automatic split is a cute idea,
> but it falls apart when MAINTAINERS attributes the same file to several
> subsystems, which is fairly comm

[PATCH v10 1/3] block: introduce compress filter driver

[Andrey Shinkevich]

Allow writing all the data compressed through the filter driver.
The written data will be aligned by the cluster size.
Based on the QEMU current implementation, that data can be written to
unallocated clusters only. May be used for a backup job.

Suggested-by: Max Reitz 
Signed-off-by: Andrey Shinkevich 
---
 block/Makefile.objs |   1 +
 block/filter-compress.c | 166 
 qapi/block-core.json|  10 +--
 3 files changed, 173 insertions(+), 4 deletions(-)
 create mode 100644 block/filter-compress.c

diff --git a/block/Makefile.objs b/block/Makefile.objs
index e394fe0..330529b 100644
--- a/block/Makefile.objs
+++ b/block/Makefile.objs
@@ -43,6 +43,7 @@ block-obj-y += crypto.o
 
 block-obj-y += aio_task.o
 block-obj-y += backup-top.o
+block-obj-y += filter-compress.o
 
 common-obj-y += stream.o
 
diff --git a/block/filter-compress.c b/block/filter-compress.c
new file mode 100644
index 000..4aa189b
--- /dev/null
+++ b/block/filter-compress.c
@@ -0,0 +1,166 @@
+/*
+ * Compress filter block driver
+ *
+ * Copyright (c) 2019 Virtuozzo International GmbH
+ *
+ * Author:
+ *   Andrey Shinkevich 
+ *   (based on block/copy-on-read.c by Max Reitz)
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 or
+ * (at your option) any later version of the License.
+ *
+ * This program 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 General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see .
+ */
+
+#include "qemu/osdep.h"
+#include "block/block_int.h"
+#include "qemu/module.h"
+#include "qapi/error.h"
+
+
+static int compress_open(BlockDriverState *bs, QDict *options, int flags,
+ Error **errp)
+{
+bs->file = bdrv_open_child(NULL, options, "file", bs, &child_file, false,
+   errp);
+if (!bs->file) {
+return -EINVAL;
+}
+
+if (!bs->file->bs->drv || !block_driver_can_compress(bs->file->bs->drv)) {
+error_setg(errp, "Compression is not supported with this drive %s",
+   bdrv_get_device_name(bs->file->bs));
+return -ENOTSUP;
+}
+
+bs->supported_write_flags = BDRV_REQ_WRITE_UNCHANGED |
+(BDRV_REQ_FUA & bs->file->bs->supported_write_flags);
+
+bs->supported_zero_flags = BDRV_REQ_WRITE_UNCHANGED |
+((BDRV_REQ_FUA | BDRV_REQ_MAY_UNMAP | BDRV_REQ_NO_FALLBACK) &
+bs->file->bs->supported_zero_flags);
+
+return 0;
+}
+
+
+static int64_t compress_getlength(BlockDriverState *bs)
+{
+return bdrv_getlength(bs->file->bs);
+}
+
+
+static int coroutine_fn compress_co_preadv_part(BlockDriverState *bs,
+uint64_t offset, uint64_t 
bytes,
+QEMUIOVector *qiov,
+size_t qiov_offset,
+int flags)
+{
+return bdrv_co_preadv_part(bs->file, offset, bytes, qiov, qiov_offset,
+   flags);
+}
+
+
+static int coroutine_fn compress_co_pwritev_part(BlockDriverState *bs,
+ uint64_t offset,
+ uint64_t bytes,
+ QEMUIOVector *qiov,
+ size_t qiov_offset, int flags)
+{
+return bdrv_co_pwritev_part(bs->file, offset, bytes, qiov, qiov_offset,
+flags | BDRV_REQ_WRITE_COMPRESSED);
+}
+
+
+static int coroutine_fn compress_co_pwrite_zeroes(BlockDriverState *bs,
+  int64_t offset, int bytes,
+  BdrvRequestFlags flags)
+{
+return bdrv_co_pwrite_zeroes(bs->file, offset, bytes, flags);
+}
+
+
+static int coroutine_fn compress_co_pdiscard(BlockDriverState *bs,
+ int64_t offset, int bytes)
+{
+return bdrv_co_pdiscard(bs->file, offset, bytes);
+}
+
+
+static void compress_refresh_limits(BlockDriverState *bs, Error **errp)
+{
+BlockDriverInfo bdi;
+int ret;
+
+if (!bs->file) {
+return;
+}
+
+ret = bdrv_get_info(bs->file->bs, &bdi);
+if (ret < 0 || bdi.cluster_size == 0) {
+return;
+}
+
+bs->bl.request_alignment = bdi.cluster_size;
+}
+
+
+static void compress_eject(BlockDriverState *bs, bool eject_flag)
+{
+bdrv_eject(bs->file->bs, eject_flag);
+}
+
+
+static void compress_lock_medium(BlockDriverState *bs, bool locked)
+{
+ 

[PATCH v10 3/3] tests/qemu-iotests: add case to write compressed data of multiple clusters

[Andrey Shinkevich]

Add the case to the iotest #214 that checks possibility of writing
compressed data of more than one cluster size. The test case involves
the compress filter driver showing a sample usage of that.

Signed-off-by: Andrey Shinkevich 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Max Reitz 
---
 tests/qemu-iotests/214 | 43 +++
 tests/qemu-iotests/214.out | 14 ++
 2 files changed, 57 insertions(+)

diff --git a/tests/qemu-iotests/214 b/tests/qemu-iotests/214
index 21ec8a2..0b6ea0b 100755
--- a/tests/qemu-iotests/214
+++ b/tests/qemu-iotests/214
@@ -89,6 +89,49 @@ _check_test_img -r all
 $QEMU_IO -c "read  -P 0x11  0 4M" "$TEST_IMG" 2>&1 | _filter_qemu_io | 
_filter_testdir
 $QEMU_IO -c "read  -P 0x22 4M 4M" "$TEST_IMG" 2>&1 | _filter_qemu_io | 
_filter_testdir
 
+echo
+echo "=== Write compressed data of multiple clusters ==="
+echo
+cluster_size=0x1
+_make_test_img 2M -o cluster_size=$cluster_size
+
+echo "Write uncompressed data:"
+let data_size="8 * $cluster_size"
+$QEMU_IO -c "write -P 0xaa 0 $data_size" "$TEST_IMG" \
+ 2>&1 | _filter_qemu_io | _filter_testdir
+sizeA=$($QEMU_IMG info --output=json "$TEST_IMG" |
+sed -n '/"actual-size":/ s/[^0-9]//gp')
+
+_make_test_img 2M -o cluster_size=$cluster_size
+echo "Write compressed data:"
+let data_size="3 * $cluster_size + $cluster_size / 2"
+# Set compress on. That will align the written data
+# by the cluster size and will write them compressed.
+QEMU_IO_OPTIONS=$QEMU_IO_OPTIONS_NO_FMT \
+$QEMU_IO -c "write -P 0xbb 0 $data_size" --image-opts \
+ 
"driver=compress,file.driver=$IMGFMT,file.file.driver=file,file.file.filename=$TEST_IMG"
 \
+ 2>&1 | _filter_qemu_io | _filter_testdir
+
+let offset="4 * $cluster_size + $cluster_size / 4"
+QEMU_IO_OPTIONS=$QEMU_IO_OPTIONS_NO_FMT \
+$QEMU_IO -c "write -P 0xcc $offset $data_size" "json:{\
+'driver': 'compress',
+'file': {'driver': '$IMGFMT',
+ 'file': {'driver': 'file',
+  'filename': '$TEST_IMG'}}}" | \
+  _filter_qemu_io | _filter_testdir
+
+sizeB=$($QEMU_IMG info --output=json "$TEST_IMG" |
+sed -n '/"actual-size":/ s/[^0-9]//gp')
+
+if [ $sizeA -le $sizeB ]
+then
+echo "Compression ERROR"
+fi
+
+$QEMU_IMG check --output=json "$TEST_IMG" |
+  sed -n 's/,$//; /"compressed-clusters":/ s/^ *//p'
+
 # success, all done
 echo '*** done'
 rm -f $seq.full
diff --git a/tests/qemu-iotests/214.out b/tests/qemu-iotests/214.out
index 0fcd8dc..9fc6728 100644
--- a/tests/qemu-iotests/214.out
+++ b/tests/qemu-iotests/214.out
@@ -32,4 +32,18 @@ read 4194304/4194304 bytes at offset 0
 4 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
 read 4194304/4194304 bytes at offset 4194304
 4 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+
+=== Write compressed data of multiple clusters ===
+
+Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=2097152
+Write uncompressed data:
+wrote 524288/524288 bytes at offset 0
+512 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=2097152
+Write compressed data:
+wrote 229376/229376 bytes at offset 0
+224 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+wrote 229376/229376 bytes at offset 278528
+224 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+"compressed-clusters": 8
 *** done
-- 
1.8.3.1

[PATCH v10 0/3] qcow2: advanced compression options

[Andrey Shinkevich]

The compression filter driver is introduced as suggested by Max.
A sample usage of the filter can be found in the test #214.
Now, multiple clusters can be written compressed.
It is useful for the backup job.

v10:
  01: The option 'compress' moved up in the QAPI BlockdevDriver list
  to fit its alphabetic order (noticed by Eric).
  02: bdrv_filter_default_perms assigned to .bdrv_child_perm in the
  compression filter driver interface (suggested by Max, noticed
  by Vladimir).

  Discussed in the email thread with the message ID:
  <1574779398-88772-1-git-send-email-andrey.shinkev...@virtuozzo.com>

Andrey Shinkevich (3):
  block: introduce compress filter driver
  qcow2: Allow writing compressed data of multiple clusters
  tests/qemu-iotests: add case to write compressed data of multiple
clusters

 block/Makefile.objs|   1 +
 block/filter-compress.c| 166 +
 block/qcow2.c  | 102 
 qapi/block-core.json   |  10 +--
 tests/qemu-iotests/214 |  43 
 tests/qemu-iotests/214.out |  14 
 6 files changed, 305 insertions(+), 31 deletions(-)
 create mode 100644 block/filter-compress.c

-- 
1.8.3.1

[PATCH v10 2/3] qcow2: Allow writing compressed data of multiple clusters

[Andrey Shinkevich]

QEMU currently supports writing compressed data of the size equal to
one cluster. This patch allows writing QCOW2 compressed data that
exceed one cluster. Now, we split buffered data into separate clusters
and write them compressed using the block/aio_task API.

Suggested-by: Pavel Butsykin 
Suggested-by: Vladimir Sementsov-Ogievskiy 
Signed-off-by: Andrey Shinkevich 
Reviewed-by: Vladimir Sementsov-Ogievskiy 
Reviewed-by: Max Reitz 
---
 block/qcow2.c | 102 ++
 1 file changed, 75 insertions(+), 27 deletions(-)

diff --git a/block/qcow2.c b/block/qcow2.c
index 7c18721..0e03a1a 100644
--- a/block/qcow2.c
+++ b/block/qcow2.c
@@ -4222,10 +4222,8 @@ fail:
 return ret;
 }
 
-/* XXX: put compressed sectors first, then all the cluster aligned
-   tables to avoid losing bytes in alignment */
 static coroutine_fn int
-qcow2_co_pwritev_compressed_part(BlockDriverState *bs,
+qcow2_co_pwritev_compressed_task(BlockDriverState *bs,
  uint64_t offset, uint64_t bytes,
  QEMUIOVector *qiov, size_t qiov_offset)
 {
@@ -4235,32 +4233,11 @@ qcow2_co_pwritev_compressed_part(BlockDriverState *bs,
 uint8_t *buf, *out_buf;
 uint64_t cluster_offset;
 
-if (has_data_file(bs)) {
-return -ENOTSUP;
-}
-
-if (bytes == 0) {
-/* align end of file to a sector boundary to ease reading with
-   sector based I/Os */
-int64_t len = bdrv_getlength(bs->file->bs);
-if (len < 0) {
-return len;
-}
-return bdrv_co_truncate(bs->file, len, false, PREALLOC_MODE_OFF, NULL);
-}
-
-if (offset_into_cluster(s, offset)) {
-return -EINVAL;
-}
+assert(bytes == s->cluster_size || (bytes < s->cluster_size &&
+   (offset + bytes == bs->total_sectors << BDRV_SECTOR_BITS)));
 
 buf = qemu_blockalign(bs, s->cluster_size);
-if (bytes != s->cluster_size) {
-if (bytes > s->cluster_size ||
-offset + bytes != bs->total_sectors << BDRV_SECTOR_BITS)
-{
-qemu_vfree(buf);
-return -EINVAL;
-}
+if (bytes < s->cluster_size) {
 /* Zero-pad last write if image size is not cluster aligned */
 memset(buf + bytes, 0, s->cluster_size - bytes);
 }
@@ -4309,6 +4286,77 @@ fail:
 return ret;
 }
 
+static coroutine_fn int qcow2_co_pwritev_compressed_task_entry(AioTask *task)
+{
+Qcow2AioTask *t = container_of(task, Qcow2AioTask, task);
+
+assert(!t->cluster_type && !t->l2meta);
+
+return qcow2_co_pwritev_compressed_task(t->bs, t->offset, t->bytes, 
t->qiov,
+t->qiov_offset);
+}
+
+/*
+ * XXX: put compressed sectors first, then all the cluster aligned
+ * tables to avoid losing bytes in alignment
+ */
+static coroutine_fn int
+qcow2_co_pwritev_compressed_part(BlockDriverState *bs,
+ uint64_t offset, uint64_t bytes,
+ QEMUIOVector *qiov, size_t qiov_offset)
+{
+BDRVQcow2State *s = bs->opaque;
+AioTaskPool *aio = NULL;
+int ret = 0;
+
+if (has_data_file(bs)) {
+return -ENOTSUP;
+}
+
+if (bytes == 0) {
+/*
+ * align end of file to a sector boundary to ease reading with
+ * sector based I/Os
+ */
+int64_t len = bdrv_getlength(bs->file->bs);
+if (len < 0) {
+return len;
+}
+return bdrv_co_truncate(bs->file, len, false, PREALLOC_MODE_OFF, NULL);
+}
+
+if (offset_into_cluster(s, offset)) {
+return -EINVAL;
+}
+
+while (bytes && aio_task_pool_status(aio) == 0) {
+uint64_t chunk_size = MIN(bytes, s->cluster_size);
+
+if (!aio && chunk_size != bytes) {
+aio = aio_task_pool_new(QCOW2_MAX_WORKERS);
+}
+
+ret = qcow2_add_task(bs, aio, qcow2_co_pwritev_compressed_task_entry,
+ 0, 0, offset, chunk_size, qiov, qiov_offset, 
NULL);
+if (ret < 0) {
+break;
+}
+qiov_offset += chunk_size;
+offset += chunk_size;
+bytes -= chunk_size;
+}
+
+if (aio) {
+aio_task_pool_wait_all(aio);
+if (ret == 0) {
+ret = aio_task_pool_status(aio);
+}
+g_free(aio);
+}
+
+return ret;
+}
+
 static int coroutine_fn
 qcow2_co_preadv_compressed(BlockDriverState *bs,
uint64_t file_cluster_offset,
-- 
1.8.3.1

Re: [PATCH for-5.0 02/31] block: Add BdrvChildRole

[Vladimir Sementsov-Ogievskiy]

27.11.2019 16:15, Max Reitz wrote:
> This enum will supplement BdrvChildClass when it comes to what role (or
> combination of roles) a child takes for its parent.
> 
> Because empty enums are not allowed, let us just start with it filled.
> 
> Signed-off-by: Max Reitz 
> ---
>   include/block/block.h | 38 ++
>   1 file changed, 38 insertions(+)
> 
> diff --git a/include/block/block.h b/include/block/block.h
> index 38963ef203..36817d5689 100644
> --- a/include/block/block.h
> +++ b/include/block/block.h
> @@ -279,6 +279,44 @@ enum {
>   DEFAULT_PERM_UNCHANGED  = BLK_PERM_ALL & ~DEFAULT_PERM_PASSTHROUGH,
>   };
>   
> +typedef enum BdrvChildRole {

Don't you want to call it just BdrvChildFlags ?
Benefits:

1. Do not intersect with old BdrvChildRole.
2. I think, BDRV_CHILD_STAY_AT_NODE is not a role, but just a property or flag..

> +/*
> + * If present, bdrv_replace_node() will not change the node this
> + * BdrvChild points to.
> + */
> +BDRV_CHILD_STAY_AT_NODE = (1 << 0),
> +
> +/* Child stores data */
> +BDRV_CHILD_DATA = (1 << 1),
> +
> +/* Child stores metadata */
> +BDRV_CHILD_METADATA = (1 << 2),
> +
> +/* Filtered child */
> +BDRV_CHILD_FILTERED = (1 << 3),
> +
> +/* Child to COW from (backing child) */
> +BDRV_CHILD_COW  = (1 << 4),
> +
> +/* Child is expected to be a protocol node */
> +BDRV_CHILD_PROTOCOL = (1 << 5),
> +
> +/* Child is expected to be a format node */
> +BDRV_CHILD_FORMAT   = (1 << 6),
> +
> +/*
> + * The primary child.  For most drivers, this is the child whose
> + * filename applies best to the parent node.
> + */
> +BDRV_CHILD_PRIMARY  = (1 << 7),
> +
> +/* Useful combination of flags */
> +BDRV_CHILD_IMAGE= BDRV_CHILD_DATA
> +  | BDRV_CHILD_METADATA
> +  | BDRV_CHILD_PROTOCOL
> +  | BDRV_CHILD_PRIMARY,
> +} BdrvChildRole;
> +
>   char *bdrv_perm_names(uint64_t perm);
>   uint64_t bdrv_qapi_perm_to_blk_perm(BlockPermission qapi_perm);
>   
> 


-- 
Best regards,
Vladimir

Re: [RFC PATCH 06/10] hw/avr: Add ATmega microcontrollers

[Aleksandar Markovic]

On Thursday, November 28, 2019, Philippe Mathieu-Daudé 
wrote:

> Add famous ATmega MCUs:
>
> - middle range: ATmega168 and ATmega328
> - high range: ATmega1280 and ATmega2560
>
> Signed-off-by: Philippe Mathieu-Daudé 
> ---


Philippe, hi.

Thank you for the impetus you give us all.

However, is this the right direction?

Let's analyse some bits and pieces.

Starting from the commit message, the word "famous" is used, but I really
don't see enumerated CPUs/MCUs are any special in Atmel lineup. Other than
we often used the doc describing them (cited several times in our
discussions) as our reference, but that doesn't make them "famous".
Ofcourse, there other docs for other Atmel CPUs/MCUs, of at lest equivalent
significance. For example, "tiny" ones are at least as famous as "mega"
ones.

Then, you introduce the term MCU, without proper discussion with others on
terminology. In parlance of QEMU, ATmega168 at al. are CPUs (we all know
and assume that that are some peripherals in it). I am not against using
the term MCU, but let's first sync up on that.

The added terminology trouble is that MCUs, as you defined them, have in
array atmega_mcu[] a field called "cpu_type" - why is that field not called
"mcu_type"? *Very* confusing for any future reader. And then, similar
terminology conundrum continues with macro AVR_CPU_TYPE_NAME().

All of the above is far less important than this question: What are we
achieving with proposed CPU/MCU definitions? I certainly see the value of
fitting the complex variety of AVR CPUs/MCUs into QEMU object model. No
question about that. However, is this the right moment to do it? There are
still some unresolved architectural problems with peripheral definitions,
as I noted in yhe comment to Michael's last cover letter. This patch does
not solve them. It just assumes everything is ready with peripherals, let's
build CPUs/MCUs. The machines based on proposed CPUs/MCUs are not more real
that machine based on Michael's "sample" machine. At least Michal says
"this is not a real machine". If we used proposed CPUs/MCUs from this
patch, the resulting machine is as "paper" machine as yhe "sample" machine.
We would just live in a la-la lend of thinking: "wow, we model real
hardware now".

I would rather accept into QEMU a series admitting we are still far from
modelling real machine or CPU/MCU, than a series that gives an illusion
that we are modelling real machine or CPU/MCU.

As far as utility of this patch for Michael's series, it looks to me they
add more headake than help (not saying that the help is not present) to
Michael. He would have anotter abstraction layer to think of, at the moment
he desperately needs (in my opinion) to focus on providing the as solid as
possible, and as complete as possinle foundations. This patch looks like
building castles in the air. Again, I am not claiming that the patch is not
helpful at all.

In summary, I think that this patch is premature.

Sincerely,
Aleksansar



>  hw/avr/atmega.h  |  58 +++
>  hw/avr/atmega.c  | 379 +++
>  hw/avr/Makefile.objs |   1 +
>  3 files changed, 438 insertions(+)
>  create mode 100644 hw/avr/atmega.h
>  create mode 100644 hw/avr/atmega.c
>
> diff --git a/hw/avr/atmega.h b/hw/avr/atmega.h
> new file mode 100644
> index 00..d22d90a962
> --- /dev/null
> +++ b/hw/avr/atmega.h
> @@ -0,0 +1,58 @@
> +/*
> + * QEMU ATmega MCU
> + *
> + * Copyright (c) 2019 Philippe Mathieu-Daudé
> + *
> + * This work is licensed under the terms of the GNU GPLv2 or later.
> + * See the COPYING file in the top-level directory.
> + * SPDX-License-Identifier: GPL-2.0-or-later
> + */
> +
> +#ifndef HW_AVR_ATMEGA_H
> +#define HW_AVR_ATMEGA_H
> +
> +#include "hw/char/avr_usart.h"
> +#include "hw/char/avr_usart.h"
> +#include "hw/timer/avr_timer16.h"
> +#include "hw/misc/avr_mask.h"
> +#include "target/avr/cpu.h"
> +
> +#define TYPE_ATMEGA "ATmega"
> +#define TYPE_ATMEGA168  "ATmega168"
> +#define TYPE_ATMEGA328  "ATmega328"
> +#define TYPE_ATMEGA1280 "ATmega1280"
> +#define TYPE_ATMEGA2560 "ATmega2560"
> +#define ATMEGA(obj) OBJECT_CHECK(AtmegaState, (obj), TYPE_ATMEGA)
> +
> +#define USART_MAX 4
> +#define TIMER_MAX 6
> +
> +typedef struct AtmegaState {
> +/*< private >*/
> +SysBusDevice parent_obj;
> +/*< public >*/
> +
> +AVRCPU cpu;
> +MemoryRegion flash;
> +MemoryRegion eeprom;
> +MemoryRegion sram;
> +DeviceState *io;
> +AVRMaskState pwr[2];
> +AVRUsartState usart[USART_MAX];
> +AVRTimer16State timer[TIMER_MAX];
> +uint64_t xtal_freq_hz;
> +} AtmegaState;
> +
> +typedef struct AtmegaInfo AtmegaInfo;
> +
> +typedef struct AtmegaClass {
> +SysBusDeviceClass parent_class;
> +const AtmegaInfo *info;
> +} AtmegaClass;
> +
> +#define ATMEGA_CLASS(klass) \
> +OBJECT_CLASS_CHECK(AtmegaClass, (klass), TYPE_ATMEGA)
> +#define ATMEGA_GET_CLASS(obj) \
> +OBJECT_GET_CLASS(AtmegaClass, (obj), TYPE_ATMEGA)
> +
> +#endif /* HW_AV

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

[Sarah Harris]

Hi Aleksandar,

> Sarah, thanks for taking your tome to respond!
No problem! :)

> do we fully support what is said in:
> * 22.6.2 Sending Frames with 9 Data Bit
> * 22.7.2 Receiving Frames with 9 Data Bits
No, QEMU's character device system only supports 8 bit characters.
Shorter characters can be padded easily, but longer is a problem.
At the moment we just emit a warning and ignore the extra bit in UCSRnB (i.e. 
behave as if 8 bits was selected).

> And the same question for section:
> * 22.9 Multi-processor Communication Mode
No, this was out of scope for testing use.
This case is checked when writing to the UCSRnA register, `if (value & 
USART_CSRA_MPCM)`, and causes a warning.
I don't know if we should crash instead, but at the moment we just log the 
warning and continue.
(USART emulation will be incorrect from when this happens and until MPCM is 
disabled)

Kind regards,
Sarah Harris


On Mon, 25 Nov 2019 19:57:48 +0100
Aleksandar Markovic  wrote:

> On Mon, Nov 25, 2019 at 4:57 PM Sarah Harris  wrote:
> >
> > Hi Aleksandar,
> >
> > > - Is there a place in docs that explain its implementation in general?
> > This implementation was based on the datasheet for the ATmega2560 
> > ("ATmega640/1280/1281/2560/2561 datasheet" available from Microchip's 
> > website).
> > (I'm not sure if posting a URL will trigger any spam filters, so I'll leave 
> > it for now)
> > See section 22.10, "USART - Register Description".
> >
> 
> OK.
> 
> > > - Why do cases 4, 5, 6 issue relatively unclear error message
> > > ""update_char_mask(): Reserved character size "? Is there a
> > > better wording perhaps? Where is justification in the doc for these
> > > cases?
> > The hardware can send/receive characters of various lengths, specified by 
> > settings in these configuration registers.
> > The cases are defined in table 22-7, "UCSZn Bits Settings", which specifies 
> > that modes 4, 5, and 6 are reserved and should not be used.
> > I'm not sure how better to explain this fault to the user; this is an edge 
> > case that I'd expect only an AVR developer testing their own program to 
> > see, so describing it in the same way as the datasheet seems a good idea.
> >
> 
> OK. I somehow missed table 22-7 while comparing the code and specs - my bad.
> 
> > > - What would be the docs justification for case 7? Why is an error
> > > message issued, but still "char_mask" is set, and I guess, further
> > > processing will go on? Why the error message says "Nine bit character
> > > requested"? Who said that (that *nine* bit characters were requested?
> > > :-)
> > Case 7 also comes from table 22-7, and specifies that the USART should 
> > send/receive 9 bits per character.
> > For characters <= 8 bits it's easy to pad them to the 8 bit bytes that the 
> > character device subsystem operates on.
> > For characters of 9 bits we'd have to throw away one bit, which seems like 
> > a bad thing to do.
> > I decided it wasn't enough to justify crashing, but the user should be made 
> > aware that data is being lost and the output might not be what they would 
> > otherwise expect.
> >
> 
> Sarah, thanks for taking your tome to respond! Could you just explain
> to me do we fully support what is said in:
> 
> * 22.6.2 Sending Frames with 9 Data Bit
> * 22.7.2 Receiving Frames with 9 Data Bits
> 
> or perhaps there are some limitations?
> 
> And the same question for section:
> 
> * 22.9 Multi-processor Communication Mode
> 
> Please note that I don't suggest amending or extending your
> implementation, I just want to understand it better.
> 
> Best regards,
> Aleksandar
> 
> 
> > Kind regards,
> > Sarah Harris
> >
> >
> > On Fri, 22 Nov 2019 16:10:02 +0100
> > Aleksandar Markovic  wrote:
> >
> > > On Tue, Oct 29, 2019 at 10:25 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 

Re: [PATCH v36 17/17] target/avr: Update MAINTAINERS file

[Sarah Harris]

Yes, I don't have time to do maintenance, but I can manage reviewing.

Kind regards,
Sarah Harris


On Tue, 26 Nov 2019 22:41:32 +0200
Michael Rolnik  wrote:

> Ah. I think Sarah was ok with reviewer role.
> 
> On Tue, Nov 26, 2019 at 9:39 PM Aleksandar Markovic <
> aleksandar.m.m...@gmail.com> wrote:
> 
> > On Tue, Nov 26, 2019 at 8:06 PM Michael Rolnik  wrote:
> > >
> > > Aleksandar,
> > >
> > > there was an email from Sarah, stating that she does not want to be a
> > maintainer.
> > >
> >
> > But this is for "reviewer" role, not "maintainer".
> >
> > Sarah?
> >
> > > On Tue, Nov 26, 2019 at 5:17 AM Aleksandar Markovic <
> > aleksandar.m.m...@gmail.com> wrote:
> > >>
> > >>
> > >>
> > >> On Sunday, November 24, 2019, Michael Rolnik  wrote:
> > >>>
> > >>> Include AVR maintaners in MAINTAINERS file
> > >>>
> > >>> Signed-off-by: Michael Rolnik 
> > >>> ---
> > >>>  MAINTAINERS | 9 +
> > >>>  1 file changed, 9 insertions(+)
> > >>>
> > >>> diff --git a/MAINTAINERS b/MAINTAINERS
> > >>> index 5e5e3e52d6..ad2d9dd04a 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/
> > >>> +
> > >>
> > >>
> > >> I had a strange feeling that something is missing here, and I finally
> > realized what that was:
> > >>
> > >> R: Sarah Harris 
> > >>
> > >> https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg04225.html
> > >>
> > >>
> > >>
> > >>>  CRIS TCG CPUs
> > >>>  M: Edgar E. Iglesias 
> > >>>  S: Maintained
> > >>> --
> > >>> 2.17.2 (Apple Git-113)
> > >>>
> > >
> > >
> > > --
> > > Best Regards,
> > > Michael Rolnik
> >
> 
> 
> -- 
> Best Regards,
> Michael Rolnik

Re: [RFC PATCH 06/10] hw/avr: Add ATmega microcontrollers

[dovgaluk]

Aleksandar Markovic писал 2019-11-28 12:28:

On Thursday, November 28, 2019, Philippe Mathieu-Daudé
 wrote:


Add famous ATmega MCUs:

- middle range: ATmega168 and ATmega328
- high range: ATmega1280 and ATmega2560

Signed-off-by: Philippe Mathieu-Daudé 
---


Philippe, hi.

Thank you for the impetus you give us all.

However, is this the right direction?

Let's analyse some bits and pieces.

Starting from the commit message, the word "famous" is used, but I
really don't see enumerated CPUs/MCUs are any special in Atmel lineup.
Other than we often used the doc describing them (cited several times
in our discussions) as our reference, but that doesn't make them
"famous". Ofcourse, there other docs for other Atmel CPUs/MCUs, of at
lest equivalent significance. For example, "tiny" ones are at least as
famous as "mega" ones.

Then, you introduce the term MCU, without proper discussion with
others on terminology. In parlance of QEMU, ATmega168 at al. are CPUs
(we all know and assume that that are some peripherals in it). I am
not against using the term MCU, but let's first sync up on that.

The added terminology trouble is that MCUs, as you defined them, have
in array atmega_mcu[] a field called "cpu_type" - why is that field
not called "mcu_type"? *Very* confusing for any future reader. And
then, similar terminology conundrum continues with macro
AVR_CPU_TYPE_NAME().


MCU is a system-on-chip which includes CPU core and peripheral devices.
Separating this is better that including everything into the machine.

E.g., different MCUs may have different IO addresses for USART.


All of the above is far less important than this question: What are we
achieving with proposed CPU/MCU definitions? I certainly see the value
of fitting the complex variety of AVR CPUs/MCUs into QEMU object
model. No question about that. However, is this the right moment to do
it? There are still some unresolved architectural problems with
peripheral definitions, as I noted in yhe comment to Michael's last
cover letter. This patch does not solve them. It just assumes
everything is ready with peripherals, let's build CPUs/MCUs. The
machines based on proposed CPUs/MCUs are not more real that machine
based on Michael's "sample" machine. At least Michal says "this is not
a real machine". If we used proposed CPUs/MCUs from this patch, the
resulting machine is as "paper" machine as yhe "sample" machine. We
would just live in a la-la lend of thinking: "wow, we model real
hardware now".

I would rather accept into QEMU a series admitting we are still far
from modelling real machine or CPU/MCU, than a series that gives an
illusion that we are modelling real machine or CPU/MCU.

As far as utility of this patch for Michael's series, it looks to me
they add more headake than help (not saying that the help is not
present) to Michael. He would have anotter abstraction layer to think
of, at the moment he desperately needs (in my opinion) to focus on
providing the as solid as possible, and as complete as possinle
foundations. This patch looks like building castles in the air. Again,
I am not claiming that the patch is not helpful at all.

In summary, I think that this patch is premature.




Pavel Dovgalyuk

[PATCH v1 0/1] s390x: protvirt: SCLP interpretation

[Pierre Morel]

A new proposition:
I think it would be wise to fork directly from handle_instruction
instead to accept per default all instructions with with secure
instruction interception code.
Just in case future firmware with older QEMU.

How ever I let three dors open.

1) This patch accepts the all B2 instructions, mostly I/O.
Some of the instructions will not work correctly for PV until patched.
This should be fixed, and will be, in a separate patch.

2) The same is true for DIAG instructions.

3) Secure notifications are separated from secure instructions and
normal instructions interception because this case is completely new.
For B2 instructions we do not have to do anything this just informative.
However, one information is of interrest, a notification that
SIGP(STOP) is sent to stop the CPUs and terminate QEMU.



Pierre Morel (1):
  s390x: protvirt: SCLP interpretation

 hw/s390x/sclp.c | 18 +
 include/hw/s390x/sclp.h |  2 ++
 target/s390x/kvm.c  | 56 -
 3 files changed, 75 insertions(+), 1 deletion(-)

-- 
2.17.0

[PATCH v1 1/1] s390x: protvirt: SCLP interpretation

[Pierre Morel]

The SCLP protection handle some of the exceptions due to
mis-constructions of the SCLP Control Block (SCCB) by the guest and
provides notifications to the host when something gets wrong.
We currently do not handle these exceptions, letting all the work to the
firmware therefor, we only need to inject an external interrupt to the
guest.

When the SCCB is correct, the S390x virtualisation protection copies
the SCLP Control Block (SCCB) from the guest inside the kernel to avoid
opening a direct access to the guest memory.
When accessing the kernel memory with standard s390_cpu_virt_mem_*
functions the host opens access to the SCCB shadow at address 0.

Signed-off-by: Pierre Morel 
---
 hw/s390x/sclp.c | 18 +
 include/hw/s390x/sclp.h |  2 ++
 target/s390x/kvm.c  | 56 -
 3 files changed, 75 insertions(+), 1 deletion(-)

diff --git a/hw/s390x/sclp.c b/hw/s390x/sclp.c
index f57ce7b739..02e4e0146f 100644
--- a/hw/s390x/sclp.c
+++ b/hw/s390x/sclp.c
@@ -193,6 +193,24 @@ 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);
+
+/* Protected guest SCCB is always seen at address 0 */
+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, (uint64_t)&work_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 0c9d14b4b1..559f470f51 100644
--- a/target/s390x/kvm.c
+++ b/target/s390x/kvm.c
@@ -1170,7 +1170,14 @@ 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);
+switch (run->s390_sieic.icptcode) {
+case ICPT_PV_INSTR:
+r = sclp_service_call_protected(env, sccb, code);
+break;
+default:
+r = sclp_service_call(env, sccb, code);
+break;
+}
 if (r < 0) {
 kvm_s390_program_interrupt(cpu, -r);
 } else {
@@ -1575,6 +1582,47 @@ static int kvm_s390_handle_sigp(S390CPU *cpu, uint8_t 
ipa1, uint32_t ipb)
 return 0;
 }
 
+static int handle_secure_notification(S390CPU *cpu, struct kvm_run *run)
+{
+unsigned int ipa0 = (run->s390_sieic.ipa & 0xff00);
+uint8_t ipa1 = run->s390_sieic.ipa & 0x00ff;
+
+switch (ipa0) {
+case IPA0_SIGP: /* We get the notification that the guest stop */
+kvm_s390_handle_sigp(cpu, ipa1, run->s390_sieic.ipb);
+break;
+case IPA0_B2: /* We accept but do nothing for B2 notifications */
+break;
+default: /* We do not expect other instruction's notification */
+kvm_s390_program_interrupt(cpu, PGM_OPERATION);
+break;
+}
+return 0;
+}
+
+static int handle_secure_instruction(S390CPU *cpu, struct kvm_run *run)
+{
+unsigned int ipa0 = (run->s390_sieic.ipa & 0xff00);
+uint8_t ipa1 = run->s390_sieic.ipa & 0x00ff;
+int r = -1;
+
+switch (ipa0) {
+case IPA0_B2:
+r = handle_b2(cpu, run, ipa1);
+break;
+case IPA0_DIAG:
+r = handle_diag(cpu, run, run->s390_sieic.ipb);
+break;
+}
+
+if (r < 0) {
+r = 0;
+kvm_s390_program_interrupt(cpu, PGM_OPERATION);
+}
+
+return r;
+}
+
 static int handle_instruction(S390CPU *cpu, struct kvm_run *run)
 {
 unsigned int ipa0 = (run->s390_sieic.ipa & 0xff00);
@@ -1665,6 +1713,12 @@ static int handle_intercept(S390CPU *cpu)
 DPRINTF("intercept: 0x%x (at 0x%lx)\n", icpt_code,
 (long)cs->kvm_run->psw_addr);
 switch (icpt_code) {
+ case ICPT_PV_INSTR_NOT:
+r = handle_secure_notification(cpu, run);
+break;
+case ICPT_PV_INSTR:
+r = handle_secure_instruction(cpu, run);
+break;
 case ICPT_INSTRUCTION:
 r = handle_instruction(cpu, run);
 break;
-- 
2.17.0

Re: [PATCH] travis.yml: Run tcg tests with tci

[Alex Bennée]

Thomas Huth  writes:

> On 27/11/2019 19.38, Alex Bennée wrote:
>> Thomas Huth  writes:
>> 
>>> So far we only have compile coverage for tci. But since commit
>>> 2f160e0f9797c7522bfd0d09218d0c9340a5137c ("tci: Add implementation
>>> for INDEX_op_ld16u_i64") has been included, we can also run the
>>> x86 TCG tests with tci, so let's enable them in Travis now.
>>>
>>> Signed-off-by: Thomas Huth 
>>> ---
>>>   .travis.yml | 2 +-
>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/.travis.yml b/.travis.yml
>>> index c09b6a0014..b0b634d484 100644
>>> --- a/.travis.yml
>>> +++ b/.travis.yml
>>> @@ -218,7 +218,7 @@ matrix:
>>>   # We manually include builds which we disable "make check" for
>> this comment is out of date now (or rather has been for a while)
>> 
>>>   - env:
>>>   - CONFIG="--enable-debug --enable-tcg-interpreter"
>> Perhaps as linux-user doesn't add much to testing the TCG we could
>> limit
>> by MAIN_SOFTMMU_TARGETS here?
>
> Limiting is a good idea, but I think we should use the architectures
> that are supported by tests/boot-serial-test.c instead.

Maybe a new env - TESTBOOT_SOFTMMU_TARGETS?

>
>>> -- TEST_CMD=""
>>> +- TEST_CMD="make run-tcg-tests-x86_64-softmmu V=1"
>> How about "make check-qtest check-tcg"
>> > Which will exercise the moderate boot code tests of various
>> architectures as well as x86_64 (if we include the --disable-docker
>> configure stanza)
>
> I tried "check-tcg" before switching to
> "run-tcg-tests-x86_64-softmmu", but "check-tcg" then resulted in a
> docker error:
>
>  https://travis-ci.com/huth/qemu/jobs/260949876#L11974
>
> ... so looks like we indeed have to use --disable-docker in that case.
>
> I'll have a try and send a v2 if that works out fine.
>
>  Thomas


-- 
Alex Bennée

Re: [RFC PATCH 06/10] hw/avr: Add ATmega microcontrollers

[Aleksandar Markovic]

On Thursday, November 28, 2019, dovgaluk  wrote:

> Aleksandar Markovic писал 2019-11-28 12:28:
>
>> On Thursday, November 28, 2019, Philippe Mathieu-Daudé
>>  wrote:
>>
>> Add famous ATmega MCUs:
>>>
>>> - middle range: ATmega168 and ATmega328
>>> - high range: ATmega1280 and ATmega2560
>>>
>>> Signed-off-by: Philippe Mathieu-Daudé 
>>> ---
>>>
>>
>> Philippe, hi.
>>
>> Thank you for the impetus you give us all.
>>
>> However, is this the right direction?
>>
>> Let's analyse some bits and pieces.
>>
>> Starting from the commit message, the word "famous" is used, but I
>> really don't see enumerated CPUs/MCUs are any special in Atmel lineup.
>> Other than we often used the doc describing them (cited several times
>> in our discussions) as our reference, but that doesn't make them
>> "famous". Ofcourse, there other docs for other Atmel CPUs/MCUs, of at
>> lest equivalent significance. For example, "tiny" ones are at least as
>> famous as "mega" ones.
>>
>> Then, you introduce the term MCU, without proper discussion with
>> others on terminology. In parlance of QEMU, ATmega168 at al. are CPUs
>> (we all know and assume that that are some peripherals in it). I am
>> not against using the term MCU, but let's first sync up on that.
>>
>> The added terminology trouble is that MCUs, as you defined them, have
>> in array atmega_mcu[] a field called "cpu_type" - why is that field
>> not called "mcu_type"? *Very* confusing for any future reader. And
>> then, similar terminology conundrum continues with macro
>> AVR_CPU_TYPE_NAME().
>>
>
> MCU is a system-on-chip which includes CPU core and peripheral devices.
> Separating this is better that including everything into the machine.
>
> E.g., different MCUs may have different IO addresses for USART.
>
>
Pavel,

Do you know how is this resolved for other platforms?

How other platfirms organize and use terms "soc", "mcu", "cpu",  "core",
"cpu core"? And what is the relation between each of them and QEMU command
line options "-cpu" and "-machine"? Is thar organization the same accross
all platforms?

(I am asking you as you most likely have much wider experience in the
topic, sincr mine i limited to mips emulation)

Yours, Aleksandar





> All of the above is far less important than this question: What are we
>> achieving with proposed CPU/MCU definitions? I certainly see the value
>> of fitting the complex variety of AVR CPUs/MCUs into QEMU object
>> model. No question about that. However, is this the right moment to do
>> it? There are still some unresolved architectural problems with
>> peripheral definitions, as I noted in yhe comment to Michael's last
>> cover letter. This patch does not solve them. It just assumes
>> everything is ready with peripherals, let's build CPUs/MCUs. The
>> machines based on proposed CPUs/MCUs are not more real that machine
>> based on Michael's "sample" machine. At least Michal says "this is not
>> a real machine". If we used proposed CPUs/MCUs from this patch, the
>> resulting machine is as "paper" machine as yhe "sample" machine. We
>> would just live in a la-la lend of thinking: "wow, we model real
>> hardware now".
>>
>> I would rather accept into QEMU a series admitting we are still far
>> from modelling real machine or CPU/MCU, than a series that gives an
>> illusion that we are modelling real machine or CPU/MCU.
>>
>> As far as utility of this patch for Michael's series, it looks to me
>> they add more headake than help (not saying that the help is not
>> present) to Michael. He would have anotter abstraction layer to think
>> of, at the moment he desperately needs (in my opinion) to focus on
>> providing the as solid as possible, and as complete as possinle
>> foundations. This patch looks like building castles in the air. Again,
>> I am not claiming that the patch is not helpful at all.
>>
>> In summary, I think that this patch is premature.
>>
>>
>
> Pavel Dovgalyuk
>

Re: [RFC PATCH 00/10] hw/avr: Introduce the Arduino board

[Michael Rolnik]

Hi Philippe.

This is really good news.

Should I do anything or this will be merged after my stuff goes through?

On Thu, Nov 28, 2019 at 3:50 AM Philippe Mathieu-Daudé 
wrote:

> Hi Michael,
>
> I complained I'd rather have QEMU model real hardware, with
> documentation (schematics).
> Since your series is almost ready to get merged, I prefered to
> spend some time now to write down what I wanted. This is mostly
> a rewrite of your board, but matching the Arduino boards.
>
> Some bug slipped in (uart interrupt not raised) but I'm too tired
> to find it, and since I won't have time to look at it the next
> days, I prefer to send this now.
>
> The first part of the series are quick review notes, which you
> should squash in your previous patches.
>
> I still have in my TODO before merge:
> - Fix the USART IRQ bug
> - Split "Add limited support for USART and 16 bit timer peripherals"
>   in 3 patches: USART/Timer16/INTC
>
> And TODO after merge is:
> - Extract Timer8 common parts from Timer16
> - Add GPIOs
> - Connect LED to GPIO on Arduino
>
> Thank you for having insisted with this during so long!
>
> Regards,
>
> Phil.
>
> Based-on: <20191127175257.23480-1-mrol...@gmail.com>
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg661553.html
>
> Philippe Mathieu-Daudé (10):
>   hw/avr: Kludge to fix build failure
>   target/avr: Remove unused include
>   target/avr: Add missing definitions
>   target/avr: Fix IRQ count
>   hw/char/avr: Reduce USART I/O size
>   hw/avr: Add ATmega microcontrollers
>   hw/avr: Add few Arduino boards
>   tests/acceptance: Keep multilines comment consistent with other tests
>   tests/acceptance: Use the ATmega2560 board
>   hw/avr: Remove the 'sample' board
>
>  hw/avr/atmega.h  |  58 +
>  include/hw/char/avr_usart.h  |   2 +
>  target/avr/cpu.h |   2 +
>  hw/avr/arduino.c | 173 ++
>  hw/avr/atmega.c  | 379 +++
>  hw/avr/sample.c  | 282 ---
>  hw/char/avr_usart.c  |   2 +-
>  target/avr/cpu.c |   2 +-
>  target/avr/helper.c  |   1 -
>  hw/avr/Makefile.objs |   3 +-
>  tests/acceptance/machine_avr6.py |  10 +-
>  11 files changed, 623 insertions(+), 291 deletions(-)
>  create mode 100644 hw/avr/atmega.h
>  create mode 100644 hw/avr/arduino.c
>  create mode 100644 hw/avr/atmega.c
>  delete mode 100644 hw/avr/sample.c
>
> --
> 2.21.0
>
>

-- 
Best Regards,
Michael Rolnik

Re: [PATCH] block/nbd: fix memory leak in nbd_open()

[pannengyuan]

Hi,
I think it's a better way, you can implement this new function before
this patch.

Thanks.

On 2019/11/28 17:01, Stefano Garzarella wrote:
> On Thu, Nov 28, 2019 at 04:40:10PM +0800, pannengy...@huawei.com wrote:
> 
> Hi,
> I don't know nbd code very well, the patch LGTM, but just a comment
> below:
> 
>> From: PanNengyuan 
>>
>> In currently implementation there will be a memory leak when
>> nbd_client_connect() returns error status. Here is an easy way to reproduce:
>>
>> 1. run qemu-iotests as follow and check the result with asan:
>> ./check -raw 143
>>
>> Following is the asan output backtrack:
>> Direct leak of 40 byte(s) in 1 object(s) allocated from:
>> #0 0x7f629688a560 in calloc (/usr/lib64/libasan.so.3+0xc7560)
>> #1 0x7f6295e7e015 in g_malloc0  (/usr/lib64/libglib-2.0.so.0+0x50015)
>> #2 0x56281dab4642 in qobject_input_start_struct  
>> /mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:295
>> #3 0x56281dab1a04 in visit_start_struct  
>> /mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:49
>> #4 0x56281dad1827 in visit_type_SocketAddress  
>> qapi/qapi-visit-sockets.c:386
>> #5 0x56281da8062f in nbd_config  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
>> #6 0x56281da8062f in nbd_process_options  
>> /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
>> #7 0x56281da8062f in nbd_open  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
>>
>> Direct leak of 15 byte(s) in 1 object(s) allocated from:
>> #0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
>> #1 0x7f6295e7dfbd in g_malloc  (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
>> #2 0x7f6295e96ace in g_strdup  (/usr/lib64/libglib-2.0.so.0+0x68ace)
>> #3 0x56281da804ac in nbd_process_options 
>> /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1834
>> #4 0x56281da804ac in nbd_open  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
>>
>> Indirect leak of 24 byte(s) in 1 object(s) allocated from:
>> #0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
>> #1 0x7f6295e7dfbd in g_malloc (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
>> #2 0x7f6295e96ace in g_strdup (/usr/lib64/libglib-2.0.so.0+0x68ace)
>> #3 0x56281dab41a3 in qobject_input_type_str_keyval   
>> /mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:536
>> #4 0x56281dab2ee9 in visit_type_str   
>> /mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:297
>> #5 0x56281dad0fa1 in visit_type_UnixSocketAddress_members  
>> qapi/qapi-visit-sockets.c:141
>> #6 0x56281dad17b6 in visit_type_SocketAddress_members  
>> qapi/qapi-visit-sockets.c:366
>> #7 0x56281dad186a in visit_type_SocketAddress 
>> qapi/qapi-visit-sockets.c:393
>> #8 0x56281da8062f in nbd_config   
>> /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
>> #9 0x56281da8062f in nbd_process_options   
>> /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
>> #10 0x56281da8062f in nbd_open  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
>>
>> Reported-by: Euler Robot 
>> Signed-off-by: PanNengyuan 
>> ---
>>  block/nbd.c | 5 +
>>  1 file changed, 5 insertions(+)
>>
>> diff --git a/block/nbd.c b/block/nbd.c
>> index 1239761..bc40a25 100644
>> --- a/block/nbd.c
>> +++ b/block/nbd.c
>> @@ -1881,6 +1881,11 @@ static int nbd_open(BlockDriverState *bs, QDict 
>> *options, int flags,
>>  
>>  ret = nbd_client_connect(bs, errp);
>>  if (ret < 0) {
>> +object_unref(OBJECT(s->tlscreds));
>> +qapi_free_SocketAddress(s->saddr);
>> +g_free(s->export);
>> +g_free(s->tlscredsid);
>> +g_free(s->x_dirty_bitmap);
> 
> Since with this patch we are doing these cleanups in 3 places (here,
> nbd_close(), and nbd_process_options()), should be better to add a new
> function to do these cleanups?
> 
> Maybe I'd create a series adding a patch before this one, implementing this
> new function, and change this patch calling it.
> 
> Thanks,
> Stefano
> 
> 
> .
> 

[PATCH v5 0/4] blockdev: avoid acquiring AioContext lock twice at do_drive_backup and do_blockdev_backup

[Sergio Lopez]

do_drive_backup() acquires the AioContext lock of the corresponding
BlockDriverState. This is not a problem when it's called from
qmp_drive_backup(), but drive_backup_prepare() also acquires the lock
before calling it. The same things happens with do_blockdev_backup()
and blockdev_backup_prepare().

This patch series merges do_drive_backup() with drive_backup_prepare()
and do_blockdev_backup() with blockdev_backup_prepare(), and ensures
they're only getting called from a transaction context. This way,
there's a single code path for both transaction requests and qmp
commands, as suggested by Kevin Wolf.

We also take this opportunity to ensure we're honoring the context
acquisition semantics required by bdrv_try_set_aio_context, as
suggested by Max Reitz.

---
Changelog:

v5:
 - Include fix for iotest 141 in patch 2. (thanks Max Reitz)
 - Also fix iotest 185 and 219 in patch 2. (thanks Max Reitz)
 - Move error block after context acquisition/release, to we can use
   goto to bail out and release resources. (thanks Max Reitz)
 - Properly release old_context in qmp_blockdev_mirror. (thanks Max
   Reitz)

v4:
 - Unify patches 1-4 and 5-7 to avoid producing broken interim
   states. (thanks Max Reitz)
 - Include a fix for iotest 141. (thanks Kevin Wolf)

v3:
 - Rework the whole patch series to fix the issue by consolidating all
   operations in the transaction model. (thanks Kevin Wolf)

v2:
 - Honor bdrv_try_set_aio_context() context acquisition requirements
   (thanks Max Reitz).
 - Release the context at drive_backup_prepare() instead of avoiding
   re-acquiring it at do_drive_baclup(). (thanks Max Reitz)
 - Convert a single patch into a two-patch series.
---

Sergio Lopez (4):
  blockdev: fix coding style issues in drive_backup_prepare
  blockdev: unify qmp_drive_backup and drive-backup transaction paths
  blockdev: unify qmp_blockdev_backup and blockdev-backup transaction
paths
  blockdev: honor bdrv_try_set_aio_context() context requirements

 blockdev.c | 354 ++---
 tests/qemu-iotests/141.out |   2 +
 tests/qemu-iotests/185.out |   2 +
 tests/qemu-iotests/219 |   7 +-
 tests/qemu-iotests/219.out |   8 +
 5 files changed, 192 insertions(+), 181 deletions(-)

-- 
2.23.0

[PATCH v5 4/4] blockdev: honor bdrv_try_set_aio_context() context requirements

[Sergio Lopez]

bdrv_try_set_aio_context() requires that the old context is held, and
the new context is not held. Fix all the occurrences where it's not
done this way.

Suggested-by: Max Reitz 
Signed-off-by: Sergio Lopez 
---
 blockdev.c | 72 ++
 1 file changed, 62 insertions(+), 10 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index 152a0f7454..e33abd7fd2 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -1535,6 +1535,7 @@ static void external_snapshot_prepare(BlkActionState 
*common,
  DO_UPCAST(ExternalSnapshotState, common, common);
 TransactionAction *action = common->action;
 AioContext *aio_context;
+AioContext *old_context;
 int ret;
 
 /* 'blockdev-snapshot' and 'blockdev-snapshot-sync' have similar
@@ -1675,7 +1676,16 @@ static void external_snapshot_prepare(BlkActionState 
*common,
 goto out;
 }
 
+/* Honor bdrv_try_set_aio_context() context acquisition requirements. */
+old_context = bdrv_get_aio_context(state->new_bs);
+aio_context_release(aio_context);
+aio_context_acquire(old_context);
+
 ret = bdrv_try_set_aio_context(state->new_bs, aio_context, errp);
+
+aio_context_release(old_context);
+aio_context_acquire(aio_context);
+
 if (ret < 0) {
 goto out;
 }
@@ -1775,11 +1785,13 @@ static void drive_backup_prepare(BlkActionState 
*common, Error **errp)
 BlockDriverState *target_bs;
 BlockDriverState *source = NULL;
 AioContext *aio_context;
+AioContext *old_context;
 QDict *options;
 Error *local_err = NULL;
 int flags;
 int64_t size;
 bool set_backing_hd = false;
+int ret;
 
 assert(common->action->type == TRANSACTION_ACTION_KIND_DRIVE_BACKUP);
 backup = common->action->u.drive_backup.data;
@@ -1868,6 +1880,20 @@ static void drive_backup_prepare(BlkActionState *common, 
Error **errp)
 goto out;
 }
 
+/* Honor bdrv_try_set_aio_context() context acquisition requirements. */
+old_context = bdrv_get_aio_context(target_bs);
+aio_context_release(aio_context);
+aio_context_acquire(old_context);
+
+ret = bdrv_try_set_aio_context(target_bs, aio_context, errp);
+
+aio_context_release(old_context);
+aio_context_acquire(aio_context);
+
+if (ret < 0) {
+goto out;
+}
+
 if (set_backing_hd) {
 bdrv_set_backing_hd(target_bs, source, &local_err);
 if (local_err) {
@@ -1947,6 +1973,8 @@ static void blockdev_backup_prepare(BlkActionState 
*common, Error **errp)
 BlockDriverState *bs;
 BlockDriverState *target_bs;
 AioContext *aio_context;
+AioContext *old_context;
+int ret;
 
 assert(common->action->type == TRANSACTION_ACTION_KIND_BLOCKDEV_BACKUP);
 backup = common->action->u.blockdev_backup.data;
@@ -1961,7 +1989,18 @@ static void blockdev_backup_prepare(BlkActionState 
*common, Error **errp)
 return;
 }
 
+/* Honor bdrv_try_set_aio_context() context acquisition requirements. */
 aio_context = bdrv_get_aio_context(bs);
+old_context = bdrv_get_aio_context(target_bs);
+aio_context_acquire(old_context);
+
+ret = bdrv_try_set_aio_context(target_bs, aio_context, errp);
+if (ret < 0) {
+aio_context_release(old_context);
+return;
+}
+
+aio_context_release(old_context);
 aio_context_acquire(aio_context);
 state->bs = bs;
 
@@ -3562,7 +3601,6 @@ static BlockJob *do_backup_common(BackupCommon *backup,
 BlockJob *job = NULL;
 BdrvDirtyBitmap *bmap = NULL;
 int job_flags = JOB_DEFAULT;
-int ret;
 
 if (!backup->has_speed) {
 backup->speed = 0;
@@ -3586,11 +3624,6 @@ static BlockJob *do_backup_common(BackupCommon *backup,
 backup->compress = false;
 }
 
-ret = bdrv_try_set_aio_context(target_bs, aio_context, errp);
-if (ret < 0) {
-return NULL;
-}
-
 if ((backup->sync == MIRROR_SYNC_MODE_BITMAP) ||
 (backup->sync == MIRROR_SYNC_MODE_INCREMENTAL)) {
 /* done before desugaring 'incremental' to print the right message */
@@ -3825,6 +3858,7 @@ void qmp_drive_mirror(DriveMirror *arg, Error **errp)
 BlockDriverState *bs;
 BlockDriverState *source, *target_bs;
 AioContext *aio_context;
+AioContext *old_context;
 BlockMirrorBackingMode backing_mode;
 Error *local_err = NULL;
 QDict *options = NULL;
@@ -3937,10 +3971,19 @@ void qmp_drive_mirror(DriveMirror *arg, Error **errp)
(arg->mode == NEW_IMAGE_MODE_EXISTING ||
 !bdrv_has_zero_init(target_bs)));
 
+
+/* Honor bdrv_try_set_aio_context() context acquisition requirements. */
+old_context = bdrv_get_aio_context(target_bs);
+aio_context_release(aio_context);
+aio_context_acquire(old_context);
+
 ret = bdrv_try_set_aio_context(target_bs, aio_context, errp);
+
+aio_context_release(old_context);
+aio_context_acquire(aio_context);
+
 if (ret < 0) {
-  

[PATCH v5 2/4] blockdev: unify qmp_drive_backup and drive-backup transaction paths

[Sergio Lopez]

Issuing a drive-backup from qmp_drive_backup takes a slightly
different path than when it's issued from a transaction. In the code,
this is manifested as some redundancy between do_drive_backup() and
drive_backup_prepare().

This change unifies both paths, merging do_drive_backup() and
drive_backup_prepare(), and changing qmp_drive_backup() to create a
transaction instead of calling do_backup_common() direcly.

As a side-effect, now qmp_drive_backup() is executed inside a drained
section, as it happens when creating a drive-backup transaction. This
change is visible from the user's perspective, as the job gets paused
and immediately resumed before starting the actual work.

Also fix tests 141, 185 and 219 to cope with the extra
JOB_STATUS_CHANGE lines.

Signed-off-by: Sergio Lopez 
---
 blockdev.c | 224 +
 tests/qemu-iotests/141.out |   2 +
 tests/qemu-iotests/185.out |   2 +
 tests/qemu-iotests/219 |   7 +-
 tests/qemu-iotests/219.out |   8 ++
 5 files changed, 117 insertions(+), 126 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index 553e315972..5e85fc042e 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -1761,39 +1761,128 @@ typedef struct DriveBackupState {
 BlockJob *job;
 } DriveBackupState;
 
-static BlockJob *do_drive_backup(DriveBackup *backup, JobTxn *txn,
-Error **errp);
+static BlockJob *do_backup_common(BackupCommon *backup,
+  BlockDriverState *bs,
+  BlockDriverState *target_bs,
+  AioContext *aio_context,
+  JobTxn *txn, Error **errp);
 
 static void drive_backup_prepare(BlkActionState *common, Error **errp)
 {
 DriveBackupState *state = DO_UPCAST(DriveBackupState, common, common);
-BlockDriverState *bs;
 DriveBackup *backup;
+BlockDriverState *bs;
+BlockDriverState *target_bs;
+BlockDriverState *source = NULL;
 AioContext *aio_context;
+QDict *options;
 Error *local_err = NULL;
+int flags;
+int64_t size;
+bool set_backing_hd = false;
 
 assert(common->action->type == TRANSACTION_ACTION_KIND_DRIVE_BACKUP);
 backup = common->action->u.drive_backup.data;
 
+if (!backup->has_mode) {
+backup->mode = NEW_IMAGE_MODE_ABSOLUTE_PATHS;
+}
+
 bs = bdrv_lookup_bs(backup->device, backup->device, errp);
 if (!bs) {
 return;
 }
 
+if (!bs->drv) {
+error_setg(errp, "Device has no medium");
+return;
+}
+
 aio_context = bdrv_get_aio_context(bs);
 aio_context_acquire(aio_context);
 
 /* Paired with .clean() */
 bdrv_drained_begin(bs);
 
-state->bs = bs;
+if (!backup->has_format) {
+backup->format = backup->mode == NEW_IMAGE_MODE_EXISTING ?
+ NULL : (char *) bs->drv->format_name;
+}
+
+/* Early check to avoid creating target */
+if (bdrv_op_is_blocked(bs, BLOCK_OP_TYPE_BACKUP_SOURCE, errp)) {
+goto out;
+}
+
+flags = bs->open_flags | BDRV_O_RDWR;
+
+/*
+ * See if we have a backing HD we can use to create our new image
+ * on top of.
+ */
+if (backup->sync == MIRROR_SYNC_MODE_TOP) {
+source = backing_bs(bs);
+if (!source) {
+backup->sync = MIRROR_SYNC_MODE_FULL;
+}
+}
+if (backup->sync == MIRROR_SYNC_MODE_NONE) {
+source = bs;
+flags |= BDRV_O_NO_BACKING;
+set_backing_hd = true;
+}
+
+size = bdrv_getlength(bs);
+if (size < 0) {
+error_setg_errno(errp, -size, "bdrv_getlength failed");
+goto out;
+}
+
+if (backup->mode != NEW_IMAGE_MODE_EXISTING) {
+assert(backup->format);
+if (source) {
+bdrv_refresh_filename(source);
+bdrv_img_create(backup->target, backup->format, source->filename,
+source->drv->format_name, NULL,
+size, flags, false, &local_err);
+} else {
+bdrv_img_create(backup->target, backup->format, NULL, NULL, NULL,
+size, flags, false, &local_err);
+}
+}
 
-state->job = do_drive_backup(backup, common->block_job_txn, &local_err);
 if (local_err) {
 error_propagate(errp, local_err);
 goto out;
 }
 
+options = qdict_new();
+qdict_put_str(options, "discard", "unmap");
+qdict_put_str(options, "detect-zeroes", "unmap");
+if (backup->format) {
+qdict_put_str(options, "driver", backup->format);
+}
+
+target_bs = bdrv_open(backup->target, NULL, options, flags, errp);
+if (!target_bs) {
+goto out;
+}
+
+if (set_backing_hd) {
+bdrv_set_backing_hd(target_bs, source, &local_err);
+if (local_err) {
+goto unref;
+}
+}
+
+state->bs = bs;
+
+state->job = do_backup_common(qapi_DriveBackup_base(backup),
+

[PATCH v5 1/4] blockdev: fix coding style issues in drive_backup_prepare

[Sergio Lopez]

Fix a couple of minor coding style issues in drive_backup_prepare.

Signed-off-by: Sergio Lopez 
Reviewed-by: Max Reitz 
---
 blockdev.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index 8e029e9c01..553e315972 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -3620,7 +3620,7 @@ static BlockJob *do_drive_backup(DriveBackup *backup, 
JobTxn *txn,
 
 if (!backup->has_format) {
 backup->format = backup->mode == NEW_IMAGE_MODE_EXISTING ?
- NULL : (char*) bs->drv->format_name;
+ NULL : (char *) bs->drv->format_name;
 }
 
 /* Early check to avoid creating target */
@@ -3630,8 +3630,10 @@ static BlockJob *do_drive_backup(DriveBackup *backup, 
JobTxn *txn,
 
 flags = bs->open_flags | BDRV_O_RDWR;
 
-/* See if we have a backing HD we can use to create our new image
- * on top of. */
+/*
+ * See if we have a backing HD we can use to create our new image
+ * on top of.
+ */
 if (backup->sync == MIRROR_SYNC_MODE_TOP) {
 source = backing_bs(bs);
 if (!source) {
-- 
2.23.0

Re: [PATCH] block/nbd: fix memory leak in nbd_open()

[Stefano Garzarella]

On Thu, Nov 28, 2019 at 06:32:49PM +0800, pannengyuan wrote:
> Hi,
> I think it's a better way, you can implement this new function before
> this patch.

If you want to do it, so you can send everything together, for me there's
no problem, it was just a suggestion.

If you don't have time, I can do it.

Cheers,
Stefano

> 
> Thanks.
> 
> On 2019/11/28 17:01, Stefano Garzarella wrote:
> > On Thu, Nov 28, 2019 at 04:40:10PM +0800, pannengy...@huawei.com wrote:
> > 
> > Hi,
> > I don't know nbd code very well, the patch LGTM, but just a comment
> > below:
> > 
> >> From: PanNengyuan 
> >>
> >> In currently implementation there will be a memory leak when
> >> nbd_client_connect() returns error status. Here is an easy way to 
> >> reproduce:
> >>
> >> 1. run qemu-iotests as follow and check the result with asan:
> >> ./check -raw 143
> >>
> >> Following is the asan output backtrack:
> >> Direct leak of 40 byte(s) in 1 object(s) allocated from:
> >> #0 0x7f629688a560 in calloc (/usr/lib64/libasan.so.3+0xc7560)
> >> #1 0x7f6295e7e015 in g_malloc0  (/usr/lib64/libglib-2.0.so.0+0x50015)
> >> #2 0x56281dab4642 in qobject_input_start_struct  
> >> /mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:295
> >> #3 0x56281dab1a04 in visit_start_struct  
> >> /mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:49
> >> #4 0x56281dad1827 in visit_type_SocketAddress  
> >> qapi/qapi-visit-sockets.c:386
> >> #5 0x56281da8062f in nbd_config  
> >> /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
> >> #6 0x56281da8062f in nbd_process_options  
> >> /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
> >> #7 0x56281da8062f in nbd_open  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
> >>
> >> Direct leak of 15 byte(s) in 1 object(s) allocated from:
> >> #0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
> >> #1 0x7f6295e7dfbd in g_malloc  (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
> >> #2 0x7f6295e96ace in g_strdup  (/usr/lib64/libglib-2.0.so.0+0x68ace)
> >> #3 0x56281da804ac in nbd_process_options 
> >> /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1834
> >> #4 0x56281da804ac in nbd_open  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
> >>
> >> Indirect leak of 24 byte(s) in 1 object(s) allocated from:
> >> #0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
> >> #1 0x7f6295e7dfbd in g_malloc (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
> >> #2 0x7f6295e96ace in g_strdup (/usr/lib64/libglib-2.0.so.0+0x68ace)
> >> #3 0x56281dab41a3 in qobject_input_type_str_keyval   
> >> /mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:536
> >> #4 0x56281dab2ee9 in visit_type_str   
> >> /mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:297
> >> #5 0x56281dad0fa1 in visit_type_UnixSocketAddress_members  
> >> qapi/qapi-visit-sockets.c:141
> >> #6 0x56281dad17b6 in visit_type_SocketAddress_members  
> >> qapi/qapi-visit-sockets.c:366
> >> #7 0x56281dad186a in visit_type_SocketAddress 
> >> qapi/qapi-visit-sockets.c:393
> >> #8 0x56281da8062f in nbd_config   
> >> /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
> >> #9 0x56281da8062f in nbd_process_options   
> >> /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
> >> #10 0x56281da8062f in nbd_open  
> >> /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
> >>
> >> Reported-by: Euler Robot 
> >> Signed-off-by: PanNengyuan 
> >> ---
> >>  block/nbd.c | 5 +
> >>  1 file changed, 5 insertions(+)
> >>
> >> diff --git a/block/nbd.c b/block/nbd.c
> >> index 1239761..bc40a25 100644
> >> --- a/block/nbd.c
> >> +++ b/block/nbd.c
> >> @@ -1881,6 +1881,11 @@ static int nbd_open(BlockDriverState *bs, QDict 
> >> *options, int flags,
> >>  
> >>  ret = nbd_client_connect(bs, errp);
> >>  if (ret < 0) {
> >> +object_unref(OBJECT(s->tlscreds));
> >> +qapi_free_SocketAddress(s->saddr);
> >> +g_free(s->export);
> >> +g_free(s->tlscredsid);
> >> +g_free(s->x_dirty_bitmap);
> > 
> > Since with this patch we are doing these cleanups in 3 places (here,
> > nbd_close(), and nbd_process_options()), should be better to add a new
> > function to do these cleanups?
> > 
> > Maybe I'd create a series adding a patch before this one, implementing this
> > new function, and change this patch calling it.
> > 
> > Thanks,
> > Stefano
> > 
> > 
> > .
> > 
> 

-- 

[PATCH v5 3/4] blockdev: unify qmp_blockdev_backup and blockdev-backup transaction paths

[Sergio Lopez]

Issuing a blockdev-backup from qmp_blockdev_backup takes a slightly
different path than when it's issued from a transaction. In the code,
this is manifested as some redundancy between do_blockdev_backup() and
blockdev_backup_prepare().

This change unifies both paths, merging do_blockdev_backup() and
blockdev_backup_prepare(), and changing qmp_blockdev_backup() to
create a transaction instead of calling do_backup_common() direcly.

As a side-effect, now qmp_blockdev_backup() is executed inside a
drained section, as it happens when creating a blockdev-backup
transaction. This change is visible from the user's perspective, as
the job gets paused and immediately resumed before starting the actual
work.

Signed-off-by: Sergio Lopez 
Reviewed-by: Max Reitz 
---
 blockdev.c | 60 --
 1 file changed, 13 insertions(+), 47 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index 5e85fc042e..152a0f7454 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -1940,16 +1940,13 @@ typedef struct BlockdevBackupState {
 BlockJob *job;
 } BlockdevBackupState;
 
-static BlockJob *do_blockdev_backup(BlockdevBackup *backup, JobTxn *txn,
-Error **errp);
-
 static void blockdev_backup_prepare(BlkActionState *common, Error **errp)
 {
 BlockdevBackupState *state = DO_UPCAST(BlockdevBackupState, common, 
common);
 BlockdevBackup *backup;
-BlockDriverState *bs, *target;
+BlockDriverState *bs;
+BlockDriverState *target_bs;
 AioContext *aio_context;
-Error *local_err = NULL;
 
 assert(common->action->type == TRANSACTION_ACTION_KIND_BLOCKDEV_BACKUP);
 backup = common->action->u.blockdev_backup.data;
@@ -1959,8 +1956,8 @@ static void blockdev_backup_prepare(BlkActionState 
*common, Error **errp)
 return;
 }
 
-target = bdrv_lookup_bs(backup->target, backup->target, errp);
-if (!target) {
+target_bs = bdrv_lookup_bs(backup->target, backup->target, errp);
+if (!target_bs) {
 return;
 }
 
@@ -1971,13 +1968,10 @@ static void blockdev_backup_prepare(BlkActionState 
*common, Error **errp)
 /* Paired with .clean() */
 bdrv_drained_begin(state->bs);
 
-state->job = do_blockdev_backup(backup, common->block_job_txn, &local_err);
-if (local_err) {
-error_propagate(errp, local_err);
-goto out;
-}
+state->job = do_backup_common(qapi_BlockdevBackup_base(backup),
+  bs, target_bs, aio_context,
+  common->block_job_txn, errp);
 
-out:
 aio_context_release(aio_context);
 }
 
@@ -3695,41 +3689,13 @@ XDbgBlockGraph *qmp_x_debug_query_block_graph(Error 
**errp)
 return bdrv_get_xdbg_block_graph(errp);
 }
 
-BlockJob *do_blockdev_backup(BlockdevBackup *backup, JobTxn *txn,
- Error **errp)
+void qmp_blockdev_backup(BlockdevBackup *backup, Error **errp)
 {
-BlockDriverState *bs;
-BlockDriverState *target_bs;
-AioContext *aio_context;
-BlockJob *job;
-
-bs = bdrv_lookup_bs(backup->device, backup->device, errp);
-if (!bs) {
-return NULL;
-}
-
-target_bs = bdrv_lookup_bs(backup->target, backup->target, errp);
-if (!target_bs) {
-return NULL;
-}
-
-aio_context = bdrv_get_aio_context(bs);
-aio_context_acquire(aio_context);
-
-job = do_backup_common(qapi_BlockdevBackup_base(backup),
-   bs, target_bs, aio_context, txn, errp);
-
-aio_context_release(aio_context);
-return job;
-}
-
-void qmp_blockdev_backup(BlockdevBackup *arg, Error **errp)
-{
-BlockJob *job;
-job = do_blockdev_backup(arg, NULL, errp);
-if (job) {
-job_start(&job->job);
-}
+TransactionAction action = {
+.type = TRANSACTION_ACTION_KIND_BLOCKDEV_BACKUP,
+.u.blockdev_backup.data = backup,
+};
+blockdev_do_action(&action, errp);
 }
 
 /* Parameter check and block job starting for drive mirroring.
-- 
2.23.0

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

[Aleksandar Markovic]

On Thursday, November 28, 2019, Sarah Harris  wrote:

> Hi Aleksandar,
>
> > Sarah, thanks for taking your tome to respond!
> No problem! :)
>
> > do we fully support what is said in:
> > * 22.6.2 Sending Frames with 9 Data Bit
> > * 22.7.2 Receiving Frames with 9 Data Bits
> No, QEMU's character device system only supports 8 bit characters.
> Shorter characters can be padded easily, but longer is a problem.
> At the moment we just emit a warning and ignore the extra bit in UCSRnB
> (i.e. behave as if 8 bits was selected).
>
> > And the same question for section:
> > * 22.9 Multi-processor Communication Mode
> No, this was out of scope for testing use.
> This case is checked when writing to the UCSRnA register, `if (value &
> USART_CSRA_MPCM)`, and causes a warning.
> I don't know if we should crash instead, but at the moment we just log the
> warning and continue.
> (USART emulation will be incorrect from when this happens and until MPCM
> is disabled)
>
>
OK. Thanks. All this sounds reasonable to me. Do you agree that we insert:

/*
 * Limitation of this emulation:
 *
 *   * Sending and receiving frames with 9 data bits sre not supported
 *   * Multi-processor communication mode is not supported
 */

or a similar comment, close to the top of the file?

Yours,
Aleksandar


Kind regards,
> Sarah Harris
>
>
> On Mon, 25 Nov 2019 19:57:48 +0100
> Aleksandar Markovic  wrote:
>
> > On Mon, Nov 25, 2019 at 4:57 PM Sarah Harris  wrote:
> > >
> > > Hi Aleksandar,
> > >
> > > > - Is there a place in docs that explain its implementation in
> general?
> > > This implementation was based on the datasheet for the ATmega2560
> ("ATmega640/1280/1281/2560/2561 datasheet" available from Microchip's
> website).
> > > (I'm not sure if posting a URL will trigger any spam filters, so I'll
> leave it for now)
> > > See section 22.10, "USART - Register Description".
> > >
> >
> > OK.
> >
> > > > - Why do cases 4, 5, 6 issue relatively unclear error message
> > > > ""update_char_mask(): Reserved character size "? Is there a
> > > > better wording perhaps? Where is justification in the doc for these
> > > > cases?
> > > The hardware can send/receive characters of various lengths, specified
> by settings in these configuration registers.
> > > The cases are defined in table 22-7, "UCSZn Bits Settings", which
> specifies that modes 4, 5, and 6 are reserved and should not be used.
> > > I'm not sure how better to explain this fault to the user; this is an
> edge case that I'd expect only an AVR developer testing their own program
> to see, so describing it in the same way as the datasheet seems a good idea.
> > >
> >
> > OK. I somehow missed table 22-7 while comparing the code and specs - my
> bad.
> >
> > > > - What would be the docs justification for case 7? Why is an error
> > > > message issued, but still "char_mask" is set, and I guess, further
> > > > processing will go on? Why the error message says "Nine bit character
> > > > requested"? Who said that (that *nine* bit characters were requested?
> > > > :-)
> > > Case 7 also comes from table 22-7, and specifies that the USART should
> send/receive 9 bits per character.
> > > For characters <= 8 bits it's easy to pad them to the 8 bit bytes that
> the character device subsystem operates on.
> > > For characters of 9 bits we'd have to throw away one bit, which seems
> like a bad thing to do.
> > > I decided it wasn't enough to justify crashing, but the user should be
> made aware that data is being lost and the output might not be what they
> would otherwise expect.
> > >
> >
> > Sarah, thanks for taking your tome to respond! Could you just explain
> > to me do we fully support what is said in:
> >
> > * 22.6.2 Sending Frames with 9 Data Bit
> > * 22.7.2 Receiving Frames with 9 Data Bits
> >
> > or perhaps there are some limitations?
> >
> > And the same question for section:
> >
> > * 22.9 Multi-processor Communication Mode
> >
> > Please note that I don't suggest amending or extending your
> > implementation, I just want to understand it better.
> >
> > Best regards,
> > Aleksandar
> >
> >
> > > Kind regards,
> > > Sarah Harris
> > >
> > >
> > > On Fri, 22 Nov 2019 16:10:02 +0100
> > > Aleksandar Markovic  wrote:
> > >
> > > > On Tue, Oct 29, 2019 at 10:25 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   

Re: [PATCH] block/nbd: fix memory leak in nbd_open()

[pannengyuan]

Thanks for you suggestion, I'd be glad to do it, I will send a new
version later.

Cheers.

On 2019/11/28 18:41, Stefano Garzarella wrote:
> On Thu, Nov 28, 2019 at 06:32:49PM +0800, pannengyuan wrote:
>> Hi,
>> I think it's a better way, you can implement this new function before
>> this patch.
> 
> If you want to do it, so you can send everything together, for me there's
> no problem, it was just a suggestion.
> 
> If you don't have time, I can do it.
> 
> Cheers,
> Stefano
> 
>>
>> Thanks.
>>
>> On 2019/11/28 17:01, Stefano Garzarella wrote:
>>> On Thu, Nov 28, 2019 at 04:40:10PM +0800, pannengy...@huawei.com wrote:
>>>
>>> Hi,
>>> I don't know nbd code very well, the patch LGTM, but just a comment
>>> below:
>>>
 From: PanNengyuan 

 In currently implementation there will be a memory leak when
 nbd_client_connect() returns error status. Here is an easy way to 
 reproduce:

 1. run qemu-iotests as follow and check the result with asan:
 ./check -raw 143

 Following is the asan output backtrack:
 Direct leak of 40 byte(s) in 1 object(s) allocated from:
 #0 0x7f629688a560 in calloc (/usr/lib64/libasan.so.3+0xc7560)
 #1 0x7f6295e7e015 in g_malloc0  (/usr/lib64/libglib-2.0.so.0+0x50015)
 #2 0x56281dab4642 in qobject_input_start_struct  
 /mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:295
 #3 0x56281dab1a04 in visit_start_struct  
 /mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:49
 #4 0x56281dad1827 in visit_type_SocketAddress  
 qapi/qapi-visit-sockets.c:386
 #5 0x56281da8062f in nbd_config  
 /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
 #6 0x56281da8062f in nbd_process_options  
 /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
 #7 0x56281da8062f in nbd_open  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873

 Direct leak of 15 byte(s) in 1 object(s) allocated from:
 #0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
 #1 0x7f6295e7dfbd in g_malloc  (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
 #2 0x7f6295e96ace in g_strdup  (/usr/lib64/libglib-2.0.so.0+0x68ace)
 #3 0x56281da804ac in nbd_process_options 
 /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1834
 #4 0x56281da804ac in nbd_open  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873

 Indirect leak of 24 byte(s) in 1 object(s) allocated from:
 #0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
 #1 0x7f6295e7dfbd in g_malloc (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
 #2 0x7f6295e96ace in g_strdup (/usr/lib64/libglib-2.0.so.0+0x68ace)
 #3 0x56281dab41a3 in qobject_input_type_str_keyval   
 /mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:536
 #4 0x56281dab2ee9 in visit_type_str   
 /mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:297
 #5 0x56281dad0fa1 in visit_type_UnixSocketAddress_members  
 qapi/qapi-visit-sockets.c:141
 #6 0x56281dad17b6 in visit_type_SocketAddress_members  
 qapi/qapi-visit-sockets.c:366
 #7 0x56281dad186a in visit_type_SocketAddress 
 qapi/qapi-visit-sockets.c:393
 #8 0x56281da8062f in nbd_config   
 /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
 #9 0x56281da8062f in nbd_process_options   
 /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
 #10 0x56281da8062f in nbd_open  
 /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873

 Reported-by: Euler Robot 
 Signed-off-by: PanNengyuan 
 ---
  block/nbd.c | 5 +
  1 file changed, 5 insertions(+)

 diff --git a/block/nbd.c b/block/nbd.c
 index 1239761..bc40a25 100644
 --- a/block/nbd.c
 +++ b/block/nbd.c
 @@ -1881,6 +1881,11 @@ static int nbd_open(BlockDriverState *bs, QDict 
 *options, int flags,
  
  ret = nbd_client_connect(bs, errp);
  if (ret < 0) {
 +object_unref(OBJECT(s->tlscreds));
 +qapi_free_SocketAddress(s->saddr);
 +g_free(s->export);
 +g_free(s->tlscredsid);
 +g_free(s->x_dirty_bitmap);
>>>
>>> Since with this patch we are doing these cleanups in 3 places (here,
>>> nbd_close(), and nbd_process_options()), should be better to add a new
>>> function to do these cleanups?
>>>
>>> Maybe I'd create a series adding a patch before this one, implementing this
>>> new function, and change this patch calling it.
>>>
>>> Thanks,
>>> Stefano
>>>
>>>
>>> .
>>>
>>
> 

Re: [PATCH for-5.0 02/31] block: Add BdrvChildRole

[Max Reitz]

On 28.11.19 10:31, Vladimir Sementsov-Ogievskiy wrote:
> 27.11.2019 16:15, Max Reitz wrote:
>> This enum will supplement BdrvChildClass when it comes to what role (or
>> combination of roles) a child takes for its parent.
>>
>> Because empty enums are not allowed, let us just start with it filled.
>>
>> Signed-off-by: Max Reitz 
>> ---
>>   include/block/block.h | 38 ++
>>   1 file changed, 38 insertions(+)
>>
>> diff --git a/include/block/block.h b/include/block/block.h
>> index 38963ef203..36817d5689 100644
>> --- a/include/block/block.h
>> +++ b/include/block/block.h
>> @@ -279,6 +279,44 @@ enum {
>>   DEFAULT_PERM_UNCHANGED  = BLK_PERM_ALL & ~DEFAULT_PERM_PASSTHROUGH,
>>   };
>>   
>> +typedef enum BdrvChildRole {
> 
> Don't you want to call it just BdrvChildFlags ?
> Benefits:
> 
> 1. Do not intersect with old BdrvChildRole.

Well, that doesn’t change the fact that the old BdrvChildRole just
doesn’t describe a role.

> 2. I think, BDRV_CHILD_STAY_AT_NODE is not a role, but just a property or 
> flag..

I can be convinced to let STAY_AT_NODE stay a property of
BdrvChildClass. :-)

What I don’t like about “BdrvChildFlags” is that “flags” doesn’t express
anything.  The permissions are flags, too.

Max



signature.asc
Description: OpenPGP digital signature

Re: [RFC PATCH 06/10] hw/avr: Add ATmega microcontrollers

[dovgaluk]

Aleksandar Markovic писал 2019-11-28 13:20:

On Thursday, November 28, 2019, dovgaluk  wrote:


Aleksandar Markovic писал 2019-11-28 12:28:
On Thursday, November 28, 2019, Philippe Mathieu-Daudé
 wrote:

Add famous ATmega MCUs:

- middle range: ATmega168 and ATmega328
- high range: ATmega1280 and ATmega2560

Signed-off-by: Philippe Mathieu-Daudé 
---

Philippe, hi.

Thank you for the impetus you give us all.

However, is this the right direction?

Let's analyse some bits and pieces.

Starting from the commit message, the word "famous" is used, but I
really don't see enumerated CPUs/MCUs are any special in Atmel
lineup.
Other than we often used the doc describing them (cited several
times
in our discussions) as our reference, but that doesn't make them
"famous". Ofcourse, there other docs for other Atmel CPUs/MCUs, of
at
lest equivalent significance. For example, "tiny" ones are at least
as
famous as "mega" ones.

Then, you introduce the term MCU, without proper discussion with
others on terminology. In parlance of QEMU, ATmega168 at al. are
CPUs
(we all know and assume that that are some peripherals in it). I am
not against using the term MCU, but let's first sync up on that.

The added terminology trouble is that MCUs, as you defined them,
have
in array atmega_mcu[] a field called "cpu_type" - why is that field
not called "mcu_type"? *Very* confusing for any future reader. And
then, similar terminology conundrum continues with macro
AVR_CPU_TYPE_NAME().


MCU is a system-on-chip which includes CPU core and peripheral
devices.
Separating this is better that including everything into the machine.

E.g., different MCUs may have different IO addresses for USART.

Pavel,

Do you know how is this resolved for other platforms?

How other platfirms organize and use terms "soc", "mcu", "cpu",
"core", "cpu core"? And what is the relation between each of them and
QEMU command line options "-cpu" and "-machine"? Is thar organization
the same accross all platforms?


Here is an ARM example:
 SoCs: hw/arm/aspeed_soc.c include/hw/arm/aspeed_soc.h
 Boards: hw/arm/aspeed.c


(I am asking you as you most likely have much wider experience in the
topic, sincr mine i limited to mips emulation)


As far as I know, there are MIPS SoCs too.
Doesn't QEMU emulate any of them?


All of the above is far less important than this question: What
are we
achieving with proposed CPU/MCU definitions? I certainly see the
value
of fitting the complex variety of AVR CPUs/MCUs into QEMU object
model. No question about that. However, is this the right moment
to do
it? There are still some unresolved architectural problems with
peripheral definitions, as I noted in yhe comment to Michael's
last
cover letter. This patch does not solve them. It just assumes
everything is ready with peripherals, let's build CPUs/MCUs. The
machines based on proposed CPUs/MCUs are not more real that
machine
based on Michael's "sample" machine. At least Michal says "this is
not
a real machine". If we used proposed CPUs/MCUs from this patch,
the
resulting machine is as "paper" machine as yhe "sample" machine.
We
would just live in a la-la lend of thinking: "wow, we model real
hardware now".

I would rather accept into QEMU a series admitting we are still
far
from modelling real machine or CPU/MCU, than a series that gives
an
illusion that we are modelling real machine or CPU/MCU.

As far as utility of this patch for Michael's series, it looks to
me
they add more headake than help (not saying that the help is not
present) to Michael. He would have anotter abstraction layer to
think
of, at the moment he desperately needs (in my opinion) to focus on
providing the as solid as possible, and as complete as possinle
foundations. This patch looks like building castles in the air.
Again,
I am not claiming that the patch is not helpful at all.

In summary, I think that this patch is premature.




Pavel Dovgalyuk

[PATCH v2 0/1] s390x: css: pong, channel subsystem test device

[Pierre Morel]

This patch series presents a device to test the channel subsystem.

Currently it only does the following:
- answer to WRITE requests by incrementing an integer stored as
  string in the data of a PONG_WRITE CCW command.
- send back the same buffer, with the incremented integer when
  receiving a PONG_READ CCW command.
- defines a Control Unit property.


Pierre Morel (1):
  s390x: css: pong, channel subsystem test device

 default-configs/s390x-softmmu.mak |   1 +
 hw/s390x/Kconfig  |   3 +
 hw/s390x/Makefile.objs|   1 +
 hw/s390x/ccw-pong.c   | 134 ++
 include/hw/s390x/pong.h   |  48 +++
 5 files changed, 187 insertions(+)
 create mode 100644 hw/s390x/ccw-pong.c
 create mode 100644 include/hw/s390x/pong.h

-- 
2.17.0

Changelog:
- use ccw_dstream_xxx_buf (Connie)
- adding a cu_type property
- testing the ccw.count
- conditional compiling for TEST_DEVICES (Connie, Thomas)
- suppress the device categorie (Connie ?)
- adding write callback and some funny protocol

Re: [RFC PATCH 06/10] hw/avr: Add ATmega microcontrollers

[Philippe Mathieu-Daudé]

On 11/28/19 11:20 AM, Aleksandar Markovic wrote:
On Thursday, November 28, 2019, dovgaluk > wrote:


Aleksandar Markovic писал 2019-11-28 12:28:

On Thursday, November 28, 2019, Philippe Mathieu-Daudé
mailto:f4...@amsat.org>> wrote:

Add famous ATmega MCUs:

- middle range: ATmega168 and ATmega328
- high range: ATmega1280 and ATmega2560

Signed-off-by: Philippe Mathieu-Daudé mailto:f4...@amsat.org>>
---


Philippe, hi.

Thank you for the impetus you give us all.

However, is this the right direction?

Let's analyse some bits and pieces.

Starting from the commit message, the word "famous" is used, but I
really don't see enumerated CPUs/MCUs are any special in Atmel
lineup.
Other than we often used the doc describing them (cited several
times
in our discussions) as our reference, but that doesn't make them
"famous". Ofcourse, there other docs for other Atmel CPUs/MCUs,
of at
lest equivalent significance. For example, "tiny" ones are at
least as
famous as "mega" ones.

Then, you introduce the term MCU, without proper discussion with
others on terminology. In parlance of QEMU, ATmega168 at al. are
CPUs
(we all know and assume that that are some peripherals in it). I am
not against using the term MCU, but let's first sync up on that.

The added terminology trouble is that MCUs, as you defined them,
have
in array atmega_mcu[] a field called "cpu_type" - why is that field
not called "mcu_type"? *Very* confusing for any future reader. And
then, similar terminology conundrum continues with macro
AVR_CPU_TYPE_NAME().


MCU is a system-on-chip which includes CPU core and peripheral devices.
Separating this is better that including everything into the machine.

E.g., different MCUs may have different IO addresses for USART.


Pavel,

Do you know how is this resolved for other platforms?

How other platfirms organize and use terms "soc", "mcu", "cpu",  "core", 
"cpu core"? And what is the relation between each of them and QEMU 
command line options "-cpu" and "-machine"? Is thar organization the 
same accross all platforms?


The market/industry evolves quicker than the QEMU codebase, so some 
technical namings that were fine 14 years ago might be not sufficient 
nowadays.


QEMU started with dies/chipsets being really only a 
CentralProcessingUnit, cache managed off-die, external RAM, external 
peripherals.


For example the R4000 is a CPU with internal cache but QEMU doesn't 
model caches.


Now compare that with the I6500. Is it a CPU? Yes and no...
It has 4-6 cores (each having its own ScratchPad RAM), each core having 
various threads (now 'thread' == QEMU MIPS CPU), there are peripherals 
dedicated to inter-core communication; then there is also some I/O 
coherence units to use external peripherals. Add to that you can 
clusterize the cores :)
All that in the same die. The industry calls this 'System-on-Chip', 
abbreviated SoC.

Actually the 'SoC' abbreviation is used as it by MIPS marketing:
https://www.mips.com/products/warrior/i-class-i6500-multiprocessor-core/

  "As such, in conjunction with popular third party SoC coherent
  interconnect/fabric alternatives, the I6500 family can be used
  in “many core” implementations of up to 64 clusters, or >1500
  processing elements (up to four threads/core, up to six
  cores/cluster, up to 64 clusters)."


MCU and SoC are similar in that they contains CPU and peripherals in the 
same die.



Now the QEMU codebase has various 'subsystems' of interests. Group of 
developers are custom to work in the same subsystems. When I'm writing 
code/comments targeting a specific group, I try to use the technical 
vocabulary used by the group, often based on the subsystem technical 
documentation available (specs, datasheets). This is why here I used the 
MCU terminology.


(I am asking you as you most likely have much wider experience in the 
topic, sincr mine i limited to mips emulation)


Yours, Aleksandar

[...]

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

[Aleksandar Markovic]

On Thursday, November 28, 2019, Aleksandar Markovic <
aleksandar.m.m...@gmail.com> wrote:

>
>
> On Thursday, November 28, 2019, Sarah Harris  wrote:
>
>> Hi Aleksandar,
>>
>> > Sarah, thanks for taking your tome to respond!
>> No problem! :)
>>
>> > do we fully support what is said in:
>> > * 22.6.2 Sending Frames with 9 Data Bit
>> > * 22.7.2 Receiving Frames with 9 Data Bits
>> No, QEMU's character device system only supports 8 bit characters.
>> Shorter characters can be padded easily, but longer is a problem.
>> At the moment we just emit a warning and ignore the extra bit in UCSRnB
>> (i.e. behave as if 8 bits was selected).
>>
>> > And the same question for section:
>> > * 22.9 Multi-processor Communication Mode
>> No, this was out of scope for testing use.
>> This case is checked when writing to the UCSRnA register, `if (value &
>> USART_CSRA_MPCM)`, and causes a warning.
>> I don't know if we should crash instead, but at the moment we just log
>> the warning and continue.
>> (USART emulation will be incorrect from when this happens and until MPCM
>> is disabled)
>>
>>
> OK. Thanks. All this sounds reasonable to me. Do you agree that we insert:
>
> /*
>  * Limitation of this emulation:
>  *
>  *   * Sending and receiving frames with 9 data bits sre not supported
>  *   * Multi-processor communication mode is not supported
>  */
>
> or a similar comment, close to the top of the file?
>
>
One more question, Sarah, Michael left the license preambles the same as
originals, however this is not a good license (there are some legal
nuances) for QEMU, do you agree that the license preambles for your
implementations are changed to LGPL 2.1 (with wording "or later (at your
option)") that Michael used elsewhere?

Best regards,

 Aleksandar


> Yours,
> Aleksandar
>
>
> Kind regards,
>> Sarah Harris
>>
>>
>> On Mon, 25 Nov 2019 19:57:48 +0100
>> Aleksandar Markovic  wrote:
>>
>> > On Mon, Nov 25, 2019 at 4:57 PM Sarah Harris  wrote:
>> > >
>> > > Hi Aleksandar,
>> > >
>> > > > - Is there a place in docs that explain its implementation in
>> general?
>> > > This implementation was based on the datasheet for the ATmega2560
>> ("ATmega640/1280/1281/2560/2561 datasheet" available from Microchip's
>> website).
>> > > (I'm not sure if posting a URL will trigger any spam filters, so I'll
>> leave it for now)
>> > > See section 22.10, "USART - Register Description".
>> > >
>> >
>> > OK.
>> >
>> > > > - Why do cases 4, 5, 6 issue relatively unclear error message
>> > > > ""update_char_mask(): Reserved character size "? Is there a
>> > > > better wording perhaps? Where is justification in the doc for these
>> > > > cases?
>> > > The hardware can send/receive characters of various lengths,
>> specified by settings in these configuration registers.
>> > > The cases are defined in table 22-7, "UCSZn Bits Settings", which
>> specifies that modes 4, 5, and 6 are reserved and should not be used.
>> > > I'm not sure how better to explain this fault to the user; this is an
>> edge case that I'd expect only an AVR developer testing their own program
>> to see, so describing it in the same way as the datasheet seems a good idea.
>> > >
>> >
>> > OK. I somehow missed table 22-7 while comparing the code and specs - my
>> bad.
>> >
>> > > > - What would be the docs justification for case 7? Why is an error
>> > > > message issued, but still "char_mask" is set, and I guess, further
>> > > > processing will go on? Why the error message says "Nine bit
>> character
>> > > > requested"? Who said that (that *nine* bit characters were
>> requested?
>> > > > :-)
>> > > Case 7 also comes from table 22-7, and specifies that the USART
>> should send/receive 9 bits per character.
>> > > For characters <= 8 bits it's easy to pad them to the 8 bit bytes
>> that the character device subsystem operates on.
>> > > For characters of 9 bits we'd have to throw away one bit, which seems
>> like a bad thing to do.
>> > > I decided it wasn't enough to justify crashing, but the user should
>> be made aware that data is being lost and the output might not be what they
>> would otherwise expect.
>> > >
>> >
>> > Sarah, thanks for taking your tome to respond! Could you just explain
>> > to me do we fully support what is said in:
>> >
>> > * 22.6.2 Sending Frames with 9 Data Bit
>> > * 22.7.2 Receiving Frames with 9 Data Bits
>> >
>> > or perhaps there are some limitations?
>> >
>> > And the same question for section:
>> >
>> > * 22.9 Multi-processor Communication Mode
>> >
>> > Please note that I don't suggest amending or extending your
>> > implementation, I just want to understand it better.
>> >
>> > Best regards,
>> > Aleksandar
>> >
>> >
>> > > Kind regards,
>> > > Sarah Harris
>> > >
>> > >
>> > > On Fri, 22 Nov 2019 16:10:02 +0100
>> > > Aleksandar Markovic  wrote:
>> > >
>> > > > On Tue, Oct 29, 2019 at 10:25 PM Michael Rolnik 
>> wrote:
>> > > > >
>> > > > > From: Sarah Harris 
>> > > > >
>> > > > > These were designed to facilitate testing but shoul

Re: [PATCH for-5.0 02/31] block: Add BdrvChildRole

[Vladimir Sementsov-Ogievskiy]

28.11.2019 13:52, Max Reitz wrote:
> On 28.11.19 10:31, Vladimir Sementsov-Ogievskiy wrote:
>> 27.11.2019 16:15, Max Reitz wrote:
>>> This enum will supplement BdrvChildClass when it comes to what role (or
>>> combination of roles) a child takes for its parent.
>>>
>>> Because empty enums are not allowed, let us just start with it filled.
>>>
>>> Signed-off-by: Max Reitz 
>>> ---
>>>include/block/block.h | 38 ++
>>>1 file changed, 38 insertions(+)
>>>
>>> diff --git a/include/block/block.h b/include/block/block.h
>>> index 38963ef203..36817d5689 100644
>>> --- a/include/block/block.h
>>> +++ b/include/block/block.h
>>> @@ -279,6 +279,44 @@ enum {
>>>DEFAULT_PERM_UNCHANGED  = BLK_PERM_ALL & 
>>> ~DEFAULT_PERM_PASSTHROUGH,
>>>};
>>>
>>> +typedef enum BdrvChildRole {
>>
>> Don't you want to call it just BdrvChildFlags ?
>> Benefits:
>>
>> 1. Do not intersect with old BdrvChildRole.
> 
> Well, that doesn’t change the fact that the old BdrvChildRole just
> doesn’t describe a role.
> 
>> 2. I think, BDRV_CHILD_STAY_AT_NODE is not a role, but just a property or 
>> flag..
> 
> I can be convinced to let STAY_AT_NODE stay a property of
> BdrvChildClass. :-)

or BdrvChild if we want it to be property of object, not class.

> 
> What I don’t like about “BdrvChildFlags” is that “flags” doesn’t express
> anything.  The permissions are flags, too.
> 
> Max
> 


-- 
Best regards,
Vladimir

[Bug 1853826] Re: ELF loader fails to load shared object on ThunderX2 running RHEL7

[Alex Bennée]

This was on Aarch64 Ubuntu 18.04 - I don't have any RHEL machines around
but if you send the ld.so along with the other libraries that won't
matter in replicating the fault on my x86 host.

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

Title:
  ELF loader fails to load shared object on ThunderX2 running RHEL7

Status in QEMU:
  Incomplete

Bug description:
  Simple test:
  hello.c

  include 

  int main(int argc, char* argv[])
  {
{
  printf("Hello World... \n");
}
return 0;
  }

  when compiled with :
  *Compiler 
  
https://developer.arm.com/tools-and-software/server-and-hpc/arm-architecture-tools/arm-allinea-studio/download
  Arm-Compiler-for-HPC_19.3_RHEL_7_aarch64.tar   

  *Running:
  1) with -armpl
   armclang -armpl hello.c
   ./qemu/build/aarch64-linux-user/qemu-aarch64 a.out
  2) without flag
  armclang hello.c
   ./qemu/build/aarch64-linux-user/qemu-aarch64 a.out

  •With Docker image:
 CentOS Linux release 7.7.1908 (AltArch)

  *Two different machines:
 AArch64, Taishan. tsv110, Kunpeng 920, ARMv8.2-A
 AArch64, Taishan 2280, Cortex-A72, ARMv8-A

  *QEMU 4.0
   qemu-aarch64 version 4.1.91 (v4.2.0-rc1)

  
  Results:

  
   Taishan 2280 Cortex-A72 
Running 
  1)with -armpl flag with and without the docker
WORKS-> Hello World...
 -> ldd a.out
  ldd a.out 
  linux-vdso.so.1 =>  (0xbc6a2000) 
  libamath_generic.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libamath_generic.so
 (0xbc544000) 
  libm.so.6 => /lib64/libm.so.6 (0xbc493000) 
  libastring_generic.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libastring_generic.so
 (0xbc472000) libarmflang.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/libarmflang.so
 (0xbbfd3000) 
  libomp.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/libomp.so
 (0xbbef5000) 
  librt.so.1 => /lib64/librt.so.1 (0xbbed4000) 
  libpthread.so.0 => /lib64/libpthread.so.0 (0xbbe9f000) 
  libarmpl_lp64_generic.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libarmpl_lp64_generic.so
 (0xb3306000) 
  libc.so.6 => /lib64/libc.so.6 (0xb318) 
  libstdc++.so.6 => 
/scratch/gcc-9.2.0_Generic-AArch64_RHEL-8_aarch64-linux/lib64/libstdc++.so.6 
(0xb2f3) 
  libgcc_s.so.1 => 
/scratch/gcc-9.2.0_Generic-AArch64_RHEL-8_aarch64-linux/lib64/libgcc_s.so.1 
(0xb2eff000) 
  libdl.so.2 => /lib64/libdl.so.2 (0xb2ede000) 
  /lib/ld-linux-aarch64.so.1 (0xbc674000)
 

  Running 
  2) without -armpl flag with and without the docker
 WORKS -> Hello World...
   -> ldd a.out
  ldd a.out
   linux-vdso.so.1 =>  (0xa6895000) 
  libastring_generic.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libastring_generic.so
 (0xa6846000) 
  libc.so.6 => /lib64/libc.so.6 (0xa66c) 
  /lib/ld-linux-aarch64.so.1 (0xa6867000)
  

  Taishan - tsv110  Kunpeng 920
 For Running 

  1)with -armpl flag with and without the docker
 DOES NOT WORK -> with and without Docker
   -> It shows : qemu:handle_cpu_signal received signal 
outside vCPU
   context @ pc=0xaaa8844a
   -> ldd a.out 
  ldd a.out 
  linux-vdso.so.1 =>  (0xad4b)
  libamath_generic.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libamath_generic.so
 (0xad37) 
  libm.so.6 => /lib64/libm.so.6 (0xad2a) 
  libastring_generic.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libastring_generic.so
 (0xad27) libarmflang.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/libarmflang.so
 (0xacdd) 
  libomp.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/libomp.so
 (0xaccf) 
  librt.so.1 => /lib64/librt.so.1 (0xaccc) 
  libpthread.so.0 => /lib64/libpthread.so.0 (0xacc8) 
  libarmpl_lp64_generic.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libarmpl_lp64_generic.so
 (0xa40e) 
  libc.so.6 => /lib64/libc.so.6 (0xa3f5) 
  libstdc++.so.6 => 
/scratch/gcc-9.2.0_Generic-AArch64_RHEL-8_aarch64-linux/lib64/libstdc++.so.6 
(0xa3d0) 
  libgcc_s.so.1 => 
/scratch/gcc-9.2.0_Generic-AArch64_RHEL-8_aarch64-linux/lib64/libgcc_s.

[PATCH v2 1/1] s390x: css: pong, channel subsystem test device

[Pierre Morel]

This is a test device for channel subsystem.
Most of the CSS instructions are handled by the common code.

The PONG_READ and PONG_WRITE CCW commands allow to test the
SSCH instruction with both read and write commands.

It is also possible to define the Control Unit type
with the cu_type property.
Currently only the kvm-unit-test css test uses the PONG device.

Signed-off-by: Pierre Morel 
---
 default-configs/s390x-softmmu.mak |   1 +
 hw/s390x/Kconfig  |   3 +
 hw/s390x/Makefile.objs|   1 +
 hw/s390x/ccw-pong.c   | 134 ++
 include/hw/s390x/pong.h   |  48 +++
 5 files changed, 187 insertions(+)
 create mode 100644 hw/s390x/ccw-pong.c
 create mode 100644 include/hw/s390x/pong.h

diff --git a/default-configs/s390x-softmmu.mak 
b/default-configs/s390x-softmmu.mak
index f2287a133f..72711912cd 100644
--- a/default-configs/s390x-softmmu.mak
+++ b/default-configs/s390x-softmmu.mak
@@ -7,6 +7,7 @@
 #CONFIG_VFIO_CCW=n
 #CONFIG_VIRTIO_PCI=n
 #CONFIG_WDT_DIAG288=n
+#CONFIG_CCW_TESTDEV=n
 
 # Boards:
 #
diff --git a/hw/s390x/Kconfig b/hw/s390x/Kconfig
index 5e7d8a2bae..041ede333e 100644
--- a/hw/s390x/Kconfig
+++ b/hw/s390x/Kconfig
@@ -10,3 +10,6 @@ config S390_CCW_VIRTIO
 select SCLPCONSOLE
 select VIRTIO_CCW
 select MSI_NONBROKEN
+
+config CCW_TESTDEV
+default y if TEST_DEVICES
diff --git a/hw/s390x/Makefile.objs b/hw/s390x/Makefile.objs
index e02ed80b68..e74d0efd9d 100644
--- a/hw/s390x/Makefile.objs
+++ b/hw/s390x/Makefile.objs
@@ -34,3 +34,4 @@ obj-$(CONFIG_KVM) += s390-stattrib-kvm.o
 obj-y += s390-ccw.o
 obj-y += ap-device.o
 obj-y += ap-bridge.o
+obj-y += ccw-pong.o
diff --git a/hw/s390x/ccw-pong.c b/hw/s390x/ccw-pong.c
new file mode 100644
index 00..ae09357f72
--- /dev/null
+++ b/hw/s390x/ccw-pong.c
@@ -0,0 +1,134 @@
+/*
+ * CCW PING-PONG
+ *
+ * Copyright 2019 IBM Corp.
+ * Author(s): Pierre Morel 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or (at
+ * your option) any later version. See the COPYING file in the top-level
+ * directory.
+ */
+
+#include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "qemu/module.h"
+#include "cpu.h"
+#include "exec/address-spaces.h"
+#include "hw/s390x/css.h"
+#include "hw/s390x/css-bridge.h"
+#include "hw/qdev-properties.h"
+#include "hw/s390x/pong.h"
+
+#define PONG_BUF_SIZE 0x1000
+static char buf[PONG_BUF_SIZE];
+
+static int pong_ccw_cb(SubchDev *sch, CCW1 ccw)
+{
+int rc = 0;
+static int value;
+int len;
+
+len = (ccw.count > PONG_BUF_SIZE) ? PONG_BUF_SIZE : ccw.count;
+switch (ccw.cmd_code) {
+case PONG_WRITE:
+rc = ccw_dstream_read_buf(&sch->cds, buf, len);
+value = atol(buf);
+break;
+case PONG_READ:
+sprintf(buf, "%08x", value + 1);
+rc = ccw_dstream_write_buf(&sch->cds, buf, len);
+break;
+default:
+rc = -ENOSYS;
+break;
+}
+
+sch->curr_status.scsw.count = ccw_dstream_residual_count(&sch->cds);
+
+if (rc == -EIO) {
+/* I/O error, specific devices generate specific conditions */
+SCHIB *schib = &sch->curr_status;
+
+sch->curr_status.scsw.dstat = SCSW_DSTAT_UNIT_CHECK;
+sch->sense_data[0] = 0x40;/* intervention-req */
+schib->scsw.ctrl &= ~SCSW_ACTL_START_PEND;
+schib->scsw.ctrl &= ~SCSW_CTRL_MASK_STCTL;
+schib->scsw.ctrl |= SCSW_STCTL_PRIMARY | SCSW_STCTL_SECONDARY |
+   SCSW_STCTL_ALERT | SCSW_STCTL_STATUS_PEND;
+}
+return rc;
+}
+
+static void pong_ccw_realize(DeviceState *ds, Error **errp)
+{
+uint16_t chpid;
+CcwPONGDevice *dev = CCW_PONG(ds);
+CcwDevice *cdev = CCW_DEVICE(ds);
+CCWDeviceClass *cdk = CCW_DEVICE_GET_CLASS(cdev);
+SubchDev *sch;
+Error *err = NULL;
+
+sch = css_create_sch(cdev->devno, errp);
+if (!sch) {
+return;
+}
+
+sch->driver_data = dev;
+cdev->sch = sch;
+chpid = css_find_free_chpid(sch->cssid);
+
+if (chpid > MAX_CHPID) {
+error_setg(&err, "No available chpid to use.");
+goto out_err;
+}
+
+sch->id.reserved = 0xff;
+sch->id.cu_type = dev->cu_type;
+css_sch_build_virtual_schib(sch, (uint8_t)chpid, CCW_PONG_CHPID_TYPE);
+sch->do_subchannel_work = do_subchannel_work_virtual;
+sch->ccw_cb = pong_ccw_cb;
+
+cdk->realize(cdev, &err);
+if (err) {
+goto out_err;
+}
+
+css_reset_sch(sch);
+return;
+
+out_err:
+error_propagate(errp, err);
+css_subch_assign(sch->cssid, sch->ssid, sch->schid, sch->devno, NULL);
+cdev->sch = NULL;
+g_free(sch);
+}
+
+static Property pong_ccw_properties[] = {
+DEFINE_PROP_UINT16("cu_type", CcwPONGDevice, cu_type, CCW_PONG_CU_TYPE),
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static void pong_ccw_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+
+dc->props = pong_ccw_properties;
+dc->bus_type = TYPE_VIRTUAL

Re:[Qemu-devel] [PATCH v2] vhost-vsock: report QMP event when setrunning

[ning.bo9]

Let me describe the issue with an example via `nc-vsock`:

Let's assume the Guest cid is 3.
execute 'rmmod vmw_vsock_virtio_transport' in Guest,
then execute 'while true; do nc-vsock 3 1234' in Host.

Host Guest
 # rmmod vmw_vsock_virtio_transport

# while true; do ./nc-vsock 3 1234; done
(after 2 second)
connect: Connection timed out
(after 2 second)
connect: Connection timed out
...

 # modprobe vmw_vsock_virtio_transport

connect: Connection reset by peer
connect: Connection reset by peer
connect: Connection reset by peer
...

 # nc-vsock -l 1234
 Connetion from cid 2 port ***...
(stop printing)


The above process simulates the communication process between
the `kata-runtime` and `kata-agent` after starting the Guest.
In order to connect to `kata-agent` as soon as possible, 
`kata-runtime` will continuously try to connect to `kata-agent` in a loop.
see 
https://github.com/kata-containers/runtime/blob/d054556f60f092335a22a288011fa29539ad4ccc/vendor/github.com/kata-containers/agent/protocols/client/client.go#L327
But when the vsock device in the Guest is not ready, the connection
will block for 2 seconds. This situation actually slows down
the entire startup time of `kata-runtime`.


> I think that adding a QMP event is working around the issue rather than
> fixing the root cause.  This is probably a vhost_vsock.ko problem and
> should be fixed there.

After looking at the source code of vhost_vsock.ko, 
I think it is possible to optimize the logic here too.
The simple patch is as follows. Do you think the modification is appropriate?

diff --git a/drivers/vhost/vsock.c b/drivers/vhost/vsock.c
index 9f57736f..8fad67be 100644
--- a/drivers/vhost/vsock.c
+++ b/drivers/vhost/vsock.c
@@ -51,6 +51,7 @@ struct vhost_vsock {
atomic_t queued_replies;

u32 guest_cid;
+   u32 state;
 };

 static u32 vhost_transport_get_local_cid(void)
@@ -497,6 +541,7 @@ static int vhost_vsock_start(struct vhost_vsock *vsock)

mutex_unlock(&vq->mutex);
}
+   vsock->state = 1;

mutex_unlock(&vsock->dev.mutex);
return 0;
@@ -535,6 +580,7 @@ static int vhost_vsock_stop(struct vhost_vsock *vsock)
vq->private_data = NULL;
mutex_unlock(&vq->mutex);
}
+   vsock->state = 0;

 err:
mutex_unlock(&vsock->dev.mutex);
@@ -786,6 +832,27 @@ static struct miscdevice vhost_vsock_misc = {
.fops = &vhost_vsock_fops,
 };

+int vhost_transport_connect(struct vsock_sock *vsk) {
+   struct vhost_vsock *vsock;
+
+   rcu_read_lock();
+
+   /* Find the vhost_vsock according to guest context id  */
+   vsock = vhost_vsock_get(vsk->remote_addr.svm_cid);
+   if (!vsock) {
+   rcu_read_unlock();
+   return -ENODEV;
+   }
+
+   rcu_read_unlock();
+
+   if (vsock->state == 1) {
+   return virtio_transport_connect(vsk);
+   } else {
+   return -ECONNRESET;
+   }
+}
+
 static struct virtio_transport vhost_transport = {
.transport = {
.get_local_cid= vhost_transport_get_local_cid,
@@ -793,7 +860,7 @@ static struct virtio_transport vhost_transport = {
.init = virtio_transport_do_socket_init,
.destruct = virtio_transport_destruct,
.release  = virtio_transport_release,
-   .connect  = virtio_transport_connect,
+   .connect  = vhost_transport_connect,
.shutdown = virtio_transport_shutdown,
.cancel_pkt   = vhost_transport_cancel_pkt,

[Bug 1853826] Re: ELF loader fails to load shared object on ThunderX2 running RHEL7

[Peter Maydell]

IIRC RHEL uses 64k pages but Ubuntu does not -- maybe that is relevant ?
Is the guest binary built for 4K or 64K pages?

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

Title:
  ELF loader fails to load shared object on ThunderX2 running RHEL7

Status in QEMU:
  Incomplete

Bug description:
  Simple test:
  hello.c

  include 

  int main(int argc, char* argv[])
  {
{
  printf("Hello World... \n");
}
return 0;
  }

  when compiled with :
  *Compiler 
  
https://developer.arm.com/tools-and-software/server-and-hpc/arm-architecture-tools/arm-allinea-studio/download
  Arm-Compiler-for-HPC_19.3_RHEL_7_aarch64.tar   

  *Running:
  1) with -armpl
   armclang -armpl hello.c
   ./qemu/build/aarch64-linux-user/qemu-aarch64 a.out
  2) without flag
  armclang hello.c
   ./qemu/build/aarch64-linux-user/qemu-aarch64 a.out

  •With Docker image:
 CentOS Linux release 7.7.1908 (AltArch)

  *Two different machines:
 AArch64, Taishan. tsv110, Kunpeng 920, ARMv8.2-A
 AArch64, Taishan 2280, Cortex-A72, ARMv8-A

  *QEMU 4.0
   qemu-aarch64 version 4.1.91 (v4.2.0-rc1)

  
  Results:

  
   Taishan 2280 Cortex-A72 
Running 
  1)with -armpl flag with and without the docker
WORKS-> Hello World...
 -> ldd a.out
  ldd a.out 
  linux-vdso.so.1 =>  (0xbc6a2000) 
  libamath_generic.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libamath_generic.so
 (0xbc544000) 
  libm.so.6 => /lib64/libm.so.6 (0xbc493000) 
  libastring_generic.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libastring_generic.so
 (0xbc472000) libarmflang.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/libarmflang.so
 (0xbbfd3000) 
  libomp.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/libomp.so
 (0xbbef5000) 
  librt.so.1 => /lib64/librt.so.1 (0xbbed4000) 
  libpthread.so.0 => /lib64/libpthread.so.0 (0xbbe9f000) 
  libarmpl_lp64_generic.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libarmpl_lp64_generic.so
 (0xb3306000) 
  libc.so.6 => /lib64/libc.so.6 (0xb318) 
  libstdc++.so.6 => 
/scratch/gcc-9.2.0_Generic-AArch64_RHEL-8_aarch64-linux/lib64/libstdc++.so.6 
(0xb2f3) 
  libgcc_s.so.1 => 
/scratch/gcc-9.2.0_Generic-AArch64_RHEL-8_aarch64-linux/lib64/libgcc_s.so.1 
(0xb2eff000) 
  libdl.so.2 => /lib64/libdl.so.2 (0xb2ede000) 
  /lib/ld-linux-aarch64.so.1 (0xbc674000)
 

  Running 
  2) without -armpl flag with and without the docker
 WORKS -> Hello World...
   -> ldd a.out
  ldd a.out
   linux-vdso.so.1 =>  (0xa6895000) 
  libastring_generic.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libastring_generic.so
 (0xa6846000) 
  libc.so.6 => /lib64/libc.so.6 (0xa66c) 
  /lib/ld-linux-aarch64.so.1 (0xa6867000)
  

  Taishan - tsv110  Kunpeng 920
 For Running 

  1)with -armpl flag with and without the docker
 DOES NOT WORK -> with and without Docker
   -> It shows : qemu:handle_cpu_signal received signal 
outside vCPU
   context @ pc=0xaaa8844a
   -> ldd a.out 
  ldd a.out 
  linux-vdso.so.1 =>  (0xad4b)
  libamath_generic.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libamath_generic.so
 (0xad37) 
  libm.so.6 => /lib64/libm.so.6 (0xad2a) 
  libastring_generic.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libastring_generic.so
 (0xad27) libarmflang.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/libarmflang.so
 (0xacdd) 
  libomp.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/libomp.so
 (0xaccf) 
  librt.so.1 => /lib64/librt.so.1 (0xaccc) 
  libpthread.so.0 => /lib64/libpthread.so.0 (0xacc8) 
  libarmpl_lp64_generic.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libarmpl_lp64_generic.so
 (0xa40e) 
  libc.so.6 => /lib64/libc.so.6 (0xa3f5) 
  libstdc++.so.6 => 
/scratch/gcc-9.2.0_Generic-AArch64_RHEL-8_aarch64-linux/lib64/libstdc++.so.6 
(0xa3d0) 
  libgcc_s.so.1 => 
/scratch/gcc-9.2.0_Generic-AArch64_RHEL-8_aarch64-linux/lib64/libgcc_s.so.1 
(0xa3cc)
  libdl.so.2 => /lib64/libdl.so.2 (0xf

Re: [RFC PATCH 06/10] hw/avr: Add ATmega microcontrollers

[Aleksandar Markovic]

On Thursday, November 28, 2019, dovgaluk  wrote:

> Aleksandar Markovic писал 2019-11-28 13:20:
>
>> On Thursday, November 28, 2019, dovgaluk  wrote:
>>
>> Aleksandar Markovic писал 2019-11-28 12:28:
>>> On Thursday, November 28, 2019, Philippe Mathieu-Daudé
>>>  wrote:
>>>
>>> Add famous ATmega MCUs:
>>>
>>> - middle range: ATmega168 and ATmega328
>>> - high range: ATmega1280 and ATmega2560
>>>
>>> Signed-off-by: Philippe Mathieu-Daudé 
>>> ---
>>>
>>> Philippe, hi.
>>>
>>> Thank you for the impetus you give us all.
>>>
>>> However, is this the right direction?
>>>
>>> Let's analyse some bits and pieces.
>>>
>>> Starting from the commit message, the word "famous" is used, but I
>>> really don't see enumerated CPUs/MCUs are any special in Atmel
>>> lineup.
>>> Other than we often used the doc describing them (cited several
>>> times
>>> in our discussions) as our reference, but that doesn't make them
>>> "famous". Ofcourse, there other docs for other Atmel CPUs/MCUs, of
>>> at
>>> lest equivalent significance. For example, "tiny" ones are at least
>>> as
>>> famous as "mega" ones.
>>>
>>> Then, you introduce the term MCU, without proper discussion with
>>> others on terminology. In parlance of QEMU, ATmega168 at al. are
>>> CPUs
>>> (we all know and assume that that are some peripherals in it). I am
>>> not against using the term MCU, but let's first sync up on that.
>>>
>>> The added terminology trouble is that MCUs, as you defined them,
>>> have
>>> in array atmega_mcu[] a field called "cpu_type" - why is that field
>>> not called "mcu_type"? *Very* confusing for any future reader. And
>>> then, similar terminology conundrum continues with macro
>>> AVR_CPU_TYPE_NAME().
>>>
>>
>> MCU is a system-on-chip which includes CPU core and peripheral
>> devices.
>> Separating this is better that including everything into the machine.
>>
>> E.g., different MCUs may have different IO addresses for USART.
>>
>> Pavel,
>>
>> Do you know how is this resolved for other platforms?
>>
>> How other platfirms organize and use terms "soc", "mcu", "cpu",
>> "core", "cpu core"? And what is the relation between each of them and
>> QEMU command line options "-cpu" and "-machine"? Is thar organization
>> the same accross all platforms?
>>
>
> Here is an ARM example:
>  SoCs: hw/arm/aspeed_soc.c include/hw/arm/aspeed_soc.h
>  Boards: hw/arm/aspeed.c
>
> (I am asking you as you most likely have much wider experience in the
>> topic, sincr mine i limited to mips emulation)
>>
>
> As far as I know, there are MIPS SoCs too.
> Doesn't QEMU emulate any of them?


It does, but, admitedly, we could do a much better job in that area, and we
are certainly not good as a reference platform in that area. Some features
of MIPS SoCs are extremely difficult to implement in QEMU though (for
example, so called hardware miltithreading).

Thanks,
Aleksandar


>
> All of the above is far less important than this question: What
 are we
 achieving with proposed CPU/MCU definitions? I certainly see the
 value
 of fitting the complex variety of AVR CPUs/MCUs into QEMU object
 model. No question about that. However, is this the right moment
 to do
 it? There are still some unresolved architectural problems with
 peripheral definitions, as I noted in yhe comment to Michael's
 last
 cover letter. This patch does not solve them. It just assumes
 everything is ready with peripherals, let's build CPUs/MCUs. The
 machines based on proposed CPUs/MCUs are not more real that
 machine
 based on Michael's "sample" machine. At least Michal says "this is
 not
 a real machine". If we used proposed CPUs/MCUs from this patch,
 the
 resulting machine is as "paper" machine as yhe "sample" machine.
 We
 would just live in a la-la lend of thinking: "wow, we model real
 hardware now".

 I would rather accept into QEMU a series admitting we are still
 far
 from modelling real machine or CPU/MCU, than a series that gives
 an
 illusion that we are modelling real machine or CPU/MCU.

 As far as utility of this patch for Michael's series, it looks to
 me
 they add more headake than help (not saying that the help is not
 present) to Michael. He would have anotter abstraction layer to
 think
 of, at the moment he desperately needs (in my opinion) to focus on
 providing the as solid as possible, and as complete as possinle
 foundations. This patch looks like building castles in the air.
 Again,
 I am not claiming that the patch is not helpful at all.

 In summary, I think that this patch is premature.

>>>
>
>
> Pavel Dovgalyuk
>
>

Re: [PATCH v19 7/8] tests/numa: Add case for QMP build HMAT

[Markus Armbruster]

Tao Xu  writes:

> Check configuring HMAT usecase
>
> Reviewed-by: Igor Mammedov 
> Suggested-by: Igor Mammedov 
> Signed-off-by: Tao Xu 
> ---
>
> Changes in v19:
> - Add some fail cases for hmat-cache when level=0
>
> Changes in v18:
> - Rewrite the lines over 80 characters
>
> Chenges in v17:
> - Add some fail test cases (Igor)
> ---
>  tests/numa-test.c | 213 ++
>  1 file changed, 213 insertions(+)
>
> diff --git a/tests/numa-test.c b/tests/numa-test.c
> index 8de8581231..aed7b2f31b 100644
> --- a/tests/numa-test.c
> +++ b/tests/numa-test.c
> @@ -327,6 +327,216 @@ 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\" } }")));

Code smell: side effect within assert().

Harmless here, because compiling tests with NDEBUG is pointless.  Still,
it sets a bad example.  Not your idea, the pattern seems to go back to
commit c35665e1ee3 and fb1e58f72ba.

The non-smelly pattern would be

resp = qtest_qmp(...);
g_assert(resp);
g_assert(qdict_haskey(rsp, "error"));
qobject_unref(resp);

It's a bit longwinded.  We could create a suitable function, but then
the assertion points to the function, which is less useful than pointing
to the test.  A macro could avoid that.

Can be cleaned up on top.

[...]

Re: [PATCH v19 2/8] numa: Extend CLI to provide memory latency and bandwidth information

[Markus Armbruster]

Tao Xu  writes:

> From: Liu Jingqi 
>
> Add -numa hmat-lb option to provide System Locality Latency and
> Bandwidth Information. These memory attributes help to build
> System Locality Latency and Bandwidth Information Structure(s)
> in ACPI Heterogeneous Memory Attribute Table (HMAT). Before using
> hmat-lb option, enable HMAT with -machine hmat=on.
>
> Signed-off-by: Liu Jingqi 
> Signed-off-by: Tao Xu 
> ---
[...]
> diff --git a/qapi/machine.json b/qapi/machine.json
> index 27d0e37534..cf9851fcd1 100644
> --- a/qapi/machine.json
> +++ b/qapi/machine.json
> @@ -426,10 +426,12 @@
>  #
>  # @cpu: property based CPU(s) to node mapping (Since: 2.10)
>  #
> +# @hmat-lb: memory latency and bandwidth information (Since: 5.0)
> +#
>  # Since: 2.1
>  ##
>  { 'enum': 'NumaOptionsType',
> -  'data': [ 'node', 'dist', 'cpu' ] }
> +  'data': [ 'node', 'dist', 'cpu', 'hmat-lb' ] }
>  
>  ##
>  # @NumaOptions:
> @@ -444,7 +446,8 @@
>'data': {
>  'node': 'NumaNodeOptions',
>  'dist': 'NumaDistOptions',
> -'cpu': 'NumaCpuOptions' }}
> +'cpu': 'NumaCpuOptions',
> +'hmat-lb': 'NumaHmatLBOptions' }}
>  
>  ##
>  # @NumaNodeOptions:
> @@ -557,6 +560,92 @@
> 'base': 'CpuInstanceProperties',
> 'data' : {} }
>  
> +##
> +# @HmatLBMemoryHierarchy:
> +#
> +# The memory hierarchy in the System Locality Latency and Bandwidth
> +# Information Structure of HMAT (Heterogeneous Memory Attribute Table)
> +#
> +# For more information about @HmatLBMemoryHierarchy see chapter

@HmatLBMemoryHierarchy, see

> +# 5.2.27.4: Table 5-146: Field "Flags" of ACPI 6.3 spec.
> +#
> +# @memory: the structure represents the memory performance
> +#
> +# @first-level: first level of memory side cache
> +#
> +# @second-level: second level of memory side cache
> +#
> +# @third-level: third level of memory side cache
> +#
> +# Since: 5.0
> +##
> +{ 'enum': 'HmatLBMemoryHierarchy',
> +  'data': [ 'memory', 'first-level', 'second-level', 'third-level' ] }
> +
> +##
> +# @HmatLBDataType:
> +#
> +# Data type in the System Locality Latency and Bandwidth
> +# Information Structure of HMAT (Heterogeneous Memory Attribute Table)
> +#
> +# For more information about @HmatLBDataType see chapter

@HmatLBDataType, see

> +# 5.2.27.4: Table 5-146:  Field "Data Type" of ACPI 6.3 spec.
> +#
> +# @access-latency: access latency (nanoseconds)
> +#
> +# @read-latency: read latency (nanoseconds)
> +#
> +# @write-latency: write latency (nanoseconds)
> +#
> +# @access-bandwidth: access bandwidth (Bytes per second)
> +#
> +# @read-bandwidth: read bandwidth (Bytes per second)
> +#
> +# @write-bandwidth: write bandwidth (Bytes per second)
> +#
> +# Since: 5.0
> +##
> +{ 'enum': 'HmatLBDataType',
> +  'data': [ 'access-latency', 'read-latency', 'write-latency',
> +'access-bandwidth', 'read-bandwidth', 'write-bandwidth' ] }
> +
> +##
> +# @NumaHmatLBOptions:
> +#
> +# Set the system locality latency and bandwidth information
> +# between Initiator and Target proximity Domains.
> +#
> +# For more information about @NumaHmatLBOptions see chapter

@NumaHmatLBOptions, see

> +# 5.2.27.4: Table 5-146 of ACPI 6.3 spec.
> +#
> +# @initiator: the Initiator Proximity Domain.
> +#
> +# @target: the Target Proximity Domain.
> +#
> +# @hierarchy: the Memory Hierarchy. Indicates the performance
> +# of memory or side cache.
> +#
> +# @data-type: presents the type of data, access/read/write
> +# latency or hit latency.
> +#
> +# @latency: the value of latency from @initiator to @target
> +#   proximity domain, the latency unit is "ns(nanosecond)".
> +#
> +# @bandwidth: the value of bandwidth between @initiator and @target
> +# proximity domain, the bandwidth unit is
> +# "Bytes per second".
> +#
> +# Since: 5.0
> +##
> +{ 'struct': 'NumaHmatLBOptions',
> +'data': {
> +'initiator': 'uint16',
> +'target': 'uint16',
> +'hierarchy': 'HmatLBMemoryHierarchy',
> +'data-type': 'HmatLBDataType',
> +'*latency': 'uint64',
> +'*bandwidth': 'size' }}
> +
>  ##
>  # @HostMemPolicy:
>  #
> diff --git a/qemu-options.hx b/qemu-options.hx
> index 63f6b33322..23303fc7d7 100644
> --- a/qemu-options.hx
> +++ b/qemu-options.hx
> @@ -168,16 +168,19 @@ DEF("numa", HAS_ARG, QEMU_OPTION_numa,
>  "-numa 
> node[,mem=size][,cpus=firstcpu[-lastcpu]][,nodeid=node][,initiator=node]\n"
>  "-numa 
> node[,memdev=id][,cpus=firstcpu[-lastcpu]][,nodeid=node][,initiator=node]\n"
>  "-numa dist,src=source,dst=destination,val=distance\n"
> -"-numa cpu,node-id=node[,socket-id=x][,core-id=y][,thread-id=z]\n",
> +"-numa cpu,node-id=node[,socket-id=x][,core-id=y][,thread-id=z]\n"
> +"-numa 
> hmat-lb,initiator=node,target=node,hierarchy=memory|first-level|second-level|third-level,data-type=access-latency|read-latency|write-latency[,latency=lat][,bandwidth=bw]\n",
>  QEMU_ARCH_ALL)
>  STEXI
>  @item -numa 
> node[,mem=@var{size}][,cpus=@var{firstcpu}[-@var{lastcpu}]][,nodeid=@var{node}

Re: [RFC 0/1] ATI R300 emulated grpahics card V2

[Gerd Hoffmann]

On Thu, Nov 28, 2019 at 12:13:49PM +0530, aaron.zakh...@gmail.com wrote:
> From: Aaron Dominick 
> 
> This is the cleaned up patchset to my previous RFC patch set.
> I could not reliably clean up my previous commits so I deleted my fork and 
> started from scratch.
> The patch looks like a lot of changes but most of it is just register 
> definitions copied from the kernel radeon DRM tree.

Adding headers should be a separate patch.

Qemu has some infrastructure to sync files with the linux kernel tree
(see scripts/update-linux-headers.sh).  It's intended for uapi include
files though, so it might not work for you.  Also the register specs are
not going to change, so future updates are unlikely, so doing a one-time
manual copy wouldn't be too bad maintenance-wise.

The code should probably be integrated with the existing ati-vga instead
of just copying the code, i.e. it'll be "-device ati-vga,model=r300".
As far I know crtc programming doesn't change much across models, so
there should be a good chunk of shareable code.

The infrastructure to branch into model-specific code is pretty rough
right now, we might refine that, for example with some helper functions
(ati_get_model() returning an enum, or ati_is_$model() functions
returning bool, or both).

Patches usually should pass scripts/checkpatch.pl codestyle checking.
We can make exceptions when reasonable (headers copied from elsewhere
for example).

> What I have implemented so far seems to get a Linux guest to load the
> DRM and KMS drivers but it cannot find any CRTCs.

Might be the vgabios tables are lacking information,
see https://git.seabios.org/cgit/seabios.git/tree/vgasrc/ati-tables.S

Might be i2c emulation needs tweaks (so EDID fetch works).

Trouble-shooting linux guests shouldn't be too hard, you have the source
code so you can check what the driver tries to do and you can add debug
printk's to trace where exactly things are failing ;)

HTH,
  Gerd

Re: [PATCH v19 7/8] tests/numa: Add case for QMP build HMAT

[Thomas Huth]

On 28/11/2019 12.49, Markus Armbruster wrote:

Tao Xu  writes:


Check configuring HMAT usecase

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

Changes in v19:
 - Add some fail cases for hmat-cache when level=0

Changes in v18:
 - Rewrite the lines over 80 characters

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

diff --git a/tests/numa-test.c b/tests/numa-test.c
index 8de8581231..aed7b2f31b 100644
--- a/tests/numa-test.c
+++ b/tests/numa-test.c
@@ -327,6 +327,216 @@ 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\" } }")));


Code smell: side effect within assert().

Harmless here, because compiling tests with NDEBUG is pointless.  Still,
it sets a bad example.  Not your idea, the pattern seems to go back to
commit c35665e1ee3 and fb1e58f72ba.


... maybe best to use g_assert_true() which can't be disabled and thus 
should be used in tests. See:


 https://developer.gnome.org/glib/unstable/glib-Testing.html#g-assert-true

 Thomas

Re: [PATCH v19 0/8] Build ACPI Heterogeneous Memory Attribute Table (HMAT)

[Markus Armbruster]

Tao Xu  writes:

> This series of patches will build Heterogeneous Memory Attribute Table (HMAT)
> according to the command line. The ACPI HMAT describes the memory attributes,
> such as memory side cache attributes and bandwidth and latency details,
> related to the Memory Proximity Domain.
> The software is expected to use HMAT information as hint for optimization.
>
> In the linux kernel, the codes in drivers/acpi/hmat/hmat.c parse and report
> the platform's HMAT tables.
>
> The V18 patches link:
> https://patchwork.kernel.org/cover/11263551/

With at least the error message in PATCH 3 fixed:
Acked-by: Markus Armbruster 

Re: [RFC PATCH 06/10] hw/avr: Add ATmega microcontrollers

[Philippe Mathieu-Daudé]

Hi Aleksandar, Richard.

On 11/28/19 10:28 AM, Aleksandar Markovic wrote:
On Thursday, November 28, 2019, Philippe Mathieu-Daudé > wrote:


Add famous ATmega MCUs:

- middle range: ATmega168 and ATmega328
- high range: ATmega1280 and ATmega2560

Signed-off-by: Philippe Mathieu-Daudé mailto:f4...@amsat.org>>
---


Philippe, hi.

Thank you for the impetus you give us all.

However, is this the right direction?


I am not the maintainer who will merge the AVR port, so I'm not an 
authoritative figure. I simply wanted to help Michael and Joaquin, so 
spent 6h of my personal time here.



Let's analyse some bits and pieces.

Starting from the commit message, the word "famous" is used, but I 
really don't see enumerated CPUs/MCUs are any special in Atmel lineup. 
Other than we often used the doc describing them (cited several times in 
our discussions) as our reference, but that doesn't make them "famous". 
Ofcourse, there other docs for other Atmel CPUs/MCUs, of at lest 
equivalent significance. For example, "tiny" ones are at least as famous 
as "mega" ones.


As noted in the cover, this is sent as RFC and I was quite tired when 
posting so the documentation is rather scarce, but the patches were 
targeted at Michael/Joaquin as example how they could properly add AVR 
machines.


Then, you introduce the term MCU, without proper discussion with others 
on terminology. In parlance of QEMU, ATmega168 at al. are CPUs (we all 
know and assume that that are some peripherals in it). I am not against 
using the term MCU, but let's first sync up on that.


The added terminology trouble is that MCUs, as you defined them, have in 
array atmega_mcu[] a field called "cpu_type" - why is that field not 
called "mcu_type"? *Very* confusing for any future reader. And then, 
similar terminology conundrum continues with macro AVR_CPU_TYPE_NAME().


All of the above is far less important than this question: What are we 
achieving with proposed CPU/MCU definitions? I certainly see the value 
of fitting the complex variety of AVR CPUs/MCUs into QEMU object model. 
No question about that. However, is this the right moment to do it? 
There are still some unresolved architectural problems with peripheral 
definitions, as I noted in yhe comment to Michael's last cover letter. 
This patch does not solve them. It just assumes everything is ready with 
peripherals, let's build CPUs/MCUs. The machines based on proposed 
CPUs/MCUs are not more real that machine based on Michael's "sample" 
machine. At least Michal says "this is not a real machine". If we used 
proposed CPUs/MCUs from this patch, the resulting machine is as "paper" 
machine as yhe "sample" machine. We would just live in a la-la lend of 
thinking: "wow, we model real hardware now".


I would rather accept into QEMU a series admitting we are still far from 
modelling real machine or CPU/MCU, than a series that gives an illusion 
that we are modelling real machine or CPU/MCU.


These patches try to do the same as the 'sample' machine modeled by 
Michael, but reordered in a different way.
The only documentation was "The CPU is an approximation of an 
ATmega2560" so I assumed he could be using the Arduino MEGA2560 board 
which matches. I used the same peripherals that Michael used, simply 
presented a more QEMU-up-to-date way.


As far as utility of this patch for Michael's series, it looks to me 
they add more headake than help (not saying that the help is not 
present) to Michael. He would have anotter abstraction layer to think 
of, at the moment he desperately needs (in my opinion) to focus on 
providing the as solid as possible, and as complete as possinle 
foundations. This patch looks like building castles in the air. Again, I 
am not claiming that the patch is not helpful at all.


In summary, I think that this patch is premature.


If we merge the 'sample' board, the deprecation process will take at 
least 8 months, hoping no-one start to hack it.


So to save time, we can merge the architectural part (target/avr) of 
Michael work, without the hardware part (hw/avr).


Michael/Sarah can still test their 'instruction-tests' [*] suite using 
the 'none' machine.


See this example which creates a testing machine with a AVR3 core and 
1MB of RAM mapped at 0x:


$ avr-softmmu/qemu-system-avr -M none -cpu avr3-avr-cpu -m 1 -S -monitor 
stdio

QEMU 4.1.93 monitor - type 'help' for more information
(qemu) info mtree
address-space: cpu-memory-0
  - (prio 0, i/o): system
-000f (prio 0, ram): ram

(qemu) info qom-tree
/machine (none-machine)
  /unattached (container)
/ram[0] (qemu:memory-region)
/sysbus (System)
/system[0] (qemu:memory-region)
/io[0] (qemu:memory-region)
/device[0] (avr3-avr-cpu)
[...]

They won't be able to run the FreeRTOS test suite [*] until we find a 
consensus with the AVR hardware/boards.


This seems the clever outcome, so

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

[Michael Rolnik]

On Thu, Nov 28, 2019 at 12:26 AM Philippe Mathieu-Daudé 
wrote:

> Hi Michael,
>
> On 11/27/19 6:52 PM, Michael Rolnik wrote:
> > This includes:
> > - CPU data structures
> > - object model classes and functions
> > - migration functions
> > - GDB hooks
> >
> > Co-developed-by: Michael Rolnik 
> > Co-developed-by: Sarah Harris 
> > Signed-off-by: Michael Rolnik 
> > Signed-off-by: Sarah Harris 
> > Signed-off-by: Michael Rolnik 
> > Acked-by: Igor Mammedov 
> > Tested-by: Philippe Mathieu-Daudé 
> > ---
> >   target/avr/cpu-param.h |  37 +++
> >   target/avr/cpu-qom.h   |  54 
> >   target/avr/cpu.h   | 253 ++
> >   target/avr/cpu.c   | 576 +
> >   target/avr/gdbstub.c   |  85 ++
> >   target/avr/machine.c   | 121 +
> >   gdb-xml/avr-cpu.xml|  49 
> >   7 files changed, 1175 insertions(+)
> >   create mode 100644 target/avr/cpu-param.h
> >   create mode 100644 target/avr/cpu-qom.h
> >   create mode 100644 target/avr/cpu.h
> >   create mode 100644 target/avr/cpu.c
> >   create mode 100644 target/avr/gdbstub.c
> >   create mode 100644 target/avr/machine.c
> >   create mode 100644 gdb-xml/avr-cpu.xml
> >
> > diff --git a/target/avr/cpu-param.h b/target/avr/cpu-param.h
> > new file mode 100644
> > index 00..ccd1ea3429
> > --- /dev/null
> > +++ b/target/avr/cpu-param.h
> > @@ -0,0 +1,37 @@
> > +/*
> > + * 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
> > + * 
> > + */
> > +
> > +#ifndef AVR_CPU_PARAM_H
> > +#define AVR_CPU_PARAM_H 1
> > +
> > +#define TARGET_LONG_BITS 32
> > +/*
> > + * TARGET_PAGE_BITS cannot be more than 8 bits because
> > + * 1.  all IO registers occupy [0x .. 0x00ff] address range, and
> they
> > + * should be implemented as a device and not memory
> > + * 2.  SRAM starts at the address 0x0100
> > + */
> > +#define TARGET_PAGE_BITS 8
> > +#define TARGET_PHYS_ADDR_SPACE_BITS 24
> > +#define TARGET_VIRT_ADDR_SPACE_BITS 24
> > +#define NB_MMU_MODES 2
> > +
> > +
> > +#endif
> > diff --git a/target/avr/cpu-qom.h b/target/avr/cpu-qom.h
> > new file mode 100644
> > index 00..e28b58c897
> > --- /dev/null
> > +++ b/target/avr/cpu-qom.h
> > @@ -0,0 +1,54 @@
> > +/*
> > + * 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
> > + * 
> > + */
> > +
> > +#ifndef QEMU_AVR_QOM_H
> > +#define QEMU_AVR_QOM_H
> > +
> > +#include "hw/core/cpu.h"
> > +
> > +#define TYPE_AVR_CPU "avr-cpu"
> > +
> > +#define AVR_CPU_CLASS(klass) \
> > +OBJECT_CLASS_CHECK(AVRCPUClass, (klass), TYPE_AVR_CPU)
> > +#define AVR_CPU(obj) \
> > +OBJECT_CHECK(AVRCPU, (obj), TYPE_AVR_CPU)
> > +#define AVR_CPU_GET_CLASS(obj) \
> > +OBJECT_GET_CLASS(AVRCPUClass, (obj), TYPE_AVR_CPU)
> > +
> > +/**
> > + *  AVRCPUClass:
> > + *  @parent_realize: The parent class' realize handler.
> > + *  @parent_reset: The parent class' reset handler.
> > + *  @vr: Version Register value.
> > + *
> > + *  A AVR CPU model.
> > + */
> > +typedef struct AVRCPUClass {
> > +/*< private >*/
> > +CPUClass parent_class;
> > +/*< public >*/
> > +DeviceRealize parent_realize;
> > +void (*parent_reset)(CPUState *cpu);
> > +} AVRCPUClass;
> > +
> > +typedef struct AVRCPU AVRCPU;
> > +
> > +
> > +#endif /* !defined (QEMU_AVR_CPU_QOM_H) */
> > diff --git a/target/avr/cpu.h b/target/avr/cpu.h
> > new file mode 100644
> > index 00..9ea5260165
> > --- /dev/null
> > +++ b/target/avr/cpu.h
> > @@ -0,0 +1,253 @@
> > +/*
> > + * QEMU

[Bug 1853826] Re: ELF loader fails to load shared object on ThunderX2 running RHEL7

[Caroline Concatto]

Alex,

Do you have the licence to run the compiler library?

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

Title:
  ELF loader fails to load shared object on ThunderX2 running RHEL7

Status in QEMU:
  Incomplete

Bug description:
  Simple test:
  hello.c

  include 

  int main(int argc, char* argv[])
  {
{
  printf("Hello World... \n");
}
return 0;
  }

  when compiled with :
  *Compiler 
  
https://developer.arm.com/tools-and-software/server-and-hpc/arm-architecture-tools/arm-allinea-studio/download
  Arm-Compiler-for-HPC_19.3_RHEL_7_aarch64.tar   

  *Running:
  1) with -armpl
   armclang -armpl hello.c
   ./qemu/build/aarch64-linux-user/qemu-aarch64 a.out
  2) without flag
  armclang hello.c
   ./qemu/build/aarch64-linux-user/qemu-aarch64 a.out

  •With Docker image:
 CentOS Linux release 7.7.1908 (AltArch)

  *Two different machines:
 AArch64, Taishan. tsv110, Kunpeng 920, ARMv8.2-A
 AArch64, Taishan 2280, Cortex-A72, ARMv8-A

  *QEMU 4.0
   qemu-aarch64 version 4.1.91 (v4.2.0-rc1)

  
  Results:

  
   Taishan 2280 Cortex-A72 
Running 
  1)with -armpl flag with and without the docker
WORKS-> Hello World...
 -> ldd a.out
  ldd a.out 
  linux-vdso.so.1 =>  (0xbc6a2000) 
  libamath_generic.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libamath_generic.so
 (0xbc544000) 
  libm.so.6 => /lib64/libm.so.6 (0xbc493000) 
  libastring_generic.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libastring_generic.so
 (0xbc472000) libarmflang.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/libarmflang.so
 (0xbbfd3000) 
  libomp.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/libomp.so
 (0xbbef5000) 
  librt.so.1 => /lib64/librt.so.1 (0xbbed4000) 
  libpthread.so.0 => /lib64/libpthread.so.0 (0xbbe9f000) 
  libarmpl_lp64_generic.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libarmpl_lp64_generic.so
 (0xb3306000) 
  libc.so.6 => /lib64/libc.so.6 (0xb318) 
  libstdc++.so.6 => 
/scratch/gcc-9.2.0_Generic-AArch64_RHEL-8_aarch64-linux/lib64/libstdc++.so.6 
(0xb2f3) 
  libgcc_s.so.1 => 
/scratch/gcc-9.2.0_Generic-AArch64_RHEL-8_aarch64-linux/lib64/libgcc_s.so.1 
(0xb2eff000) 
  libdl.so.2 => /lib64/libdl.so.2 (0xb2ede000) 
  /lib/ld-linux-aarch64.so.1 (0xbc674000)
 

  Running 
  2) without -armpl flag with and without the docker
 WORKS -> Hello World...
   -> ldd a.out
  ldd a.out
   linux-vdso.so.1 =>  (0xa6895000) 
  libastring_generic.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libastring_generic.so
 (0xa6846000) 
  libc.so.6 => /lib64/libc.so.6 (0xa66c) 
  /lib/ld-linux-aarch64.so.1 (0xa6867000)
  

  Taishan - tsv110  Kunpeng 920
 For Running 

  1)with -armpl flag with and without the docker
 DOES NOT WORK -> with and without Docker
   -> It shows : qemu:handle_cpu_signal received signal 
outside vCPU
   context @ pc=0xaaa8844a
   -> ldd a.out 
  ldd a.out 
  linux-vdso.so.1 =>  (0xad4b)
  libamath_generic.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libamath_generic.so
 (0xad37) 
  libm.so.6 => /lib64/libm.so.6 (0xad2a) 
  libastring_generic.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libastring_generic.so
 (0xad27) libarmflang.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/libarmflang.so
 (0xacdd) 
  libomp.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/libomp.so
 (0xaccf) 
  librt.so.1 => /lib64/librt.so.1 (0xaccc) 
  libpthread.so.0 => /lib64/libpthread.so.0 (0xacc8) 
  libarmpl_lp64_generic.so => 
/scratch/arm-linux-compiler-19.3_Generic-AArch64_RHEL-8_aarch64-linux/lib/clang/9.0.1/armpl_links/lib/libarmpl_lp64_generic.so
 (0xa40e) 
  libc.so.6 => /lib64/libc.so.6 (0xa3f5) 
  libstdc++.so.6 => 
/scratch/gcc-9.2.0_Generic-AArch64_RHEL-8_aarch64-linux/lib64/libstdc++.so.6 
(0xa3d0) 
  libgcc_s.so.1 => 
/scratch/gcc-9.2.0_Generic-AArch64_RHEL-8_aarch64-linux/lib64/libgcc_s.so.1 
(0xa3cc)
  libdl.so.2 => /lib64/libdl.so.2 (0xa3c9) 
  /lib/ld-linux-aarch64.so.1 (0xad4c00

Re: [PATCH v1 1/1] s390x: protvirt: SCLP interpretation

[Thomas Huth]

On 28/11/2019 11.13, Pierre Morel wrote:

The SCLP protection handle some of the exceptions due to
mis-constructions of the SCLP Control Block (SCCB) by the guest and
provides notifications to the host when something gets wrong.
We currently do not handle these exceptions, letting all the work to the
firmware therefor, we only need to inject an external interrupt to the
guest.

When the SCCB is correct, the S390x virtualisation protection copies
the SCLP Control Block (SCCB) from the guest inside the kernel to avoid
opening a direct access to the guest memory.
When accessing the kernel memory with standard s390_cpu_virt_mem_*
functions the host opens access to the SCCB shadow at address 0.

Signed-off-by: Pierre Morel 
---
  hw/s390x/sclp.c | 18 +
  include/hw/s390x/sclp.h |  2 ++
  target/s390x/kvm.c  | 56 -
  3 files changed, 75 insertions(+), 1 deletion(-)

diff --git a/hw/s390x/sclp.c b/hw/s390x/sclp.c
index f57ce7b739..02e4e0146f 100644
--- a/hw/s390x/sclp.c
+++ b/hw/s390x/sclp.c
@@ -193,6 +193,24 @@ 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);
+
+/* Protected guest SCCB is always seen at address 0 */


Well, as far as I've understood it, the address is rather ignored (and 
you can only specify an offset into the 4k page)?



+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, (uint64_t)&work_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 0c9d14b4b1..559f470f51 100644
--- a/target/s390x/kvm.c
+++ b/target/s390x/kvm.c
@@ -1170,7 +1170,14 @@ 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);

+switch (run->s390_sieic.icptcode) {
+case ICPT_PV_INSTR:
+r = sclp_service_call_protected(env, sccb, code);
+break;
+default:
+r = sclp_service_call(env, sccb, code);
+break;
+}


Why not simply

if (run->s390_sieic.icptcode == ICPT_PV_INSTR) {
r = sclp_service_call_protected(env, sccb, code);
} else {
r = sclp_service_call(env, sccb, code);
}

... that's way short and easier to read. Or do you expect other 
icptcodes in the near future?



  if (r < 0) {
  kvm_s390_program_interrupt(cpu, -r);
  } else {
@@ -1575,6 +1582,47 @@ static int kvm_s390_handle_sigp(S390CPU *cpu, uint8_t 
ipa1, uint32_t ipb)
  return 0;
  }
  
+static int handle_secure_notification(S390CPU *cpu, struct kvm_run *run)

+{
+unsigned int ipa0 = (run->s390_sieic.ipa & 0xff00);
+uint8_t ipa1 = run->s390_sieic.ipa & 0x00ff;
+
+switch (ipa0) {
+case IPA0_SIGP: /* We get the notification that the guest stop */
+kvm_s390_handle_sigp(cpu, ipa1, run->s390_sieic.ipb);
+break;
+case IPA0_B2: /* We accept but do nothing for B2 notifications */
+break;
+default: /* We do not expect other instruction's notification */
+kvm_s390_program_interrupt(cpu, PGM_OPERATION);


Maybe add a tracepoint or qemu_log_mask(LOG_UNIMP, ...) or CPU_LOG_INT 
here, so we can spot this condition more easily?



+break;
+}
+return 0;
+}
+
+static int handle_secure_instruction(S390CPU *cpu, struct kvm_run *run)
+{
+unsigned int ipa0 = (run->s390_sieic.ipa & 0xff00);
+uint8_t ipa1 = run->s390_sieic.ipa & 0x00ff;
+int r = -1;
+
+switch (ipa0) {
+case IPA0_B2:
+r = handle_b2(cpu, run, ipa1);
+break;
+case IPA0_DIAG:
+r = handle_diag(cpu, run, run->s390_sieic.ipb);
+break;
+}
+
+if (r < 0) {
+r = 0;
+kvm_s390_program_interrupt(cpu, PGM_OPERATION);
+}
+
+return r;
+}
+
  static int handle_instruction(S390CPU *cpu, struct kvm_run *run)
  {

Re: [PATCH v19 3/8] numa: Extend CLI to provide memory side cache information

[Markus Armbruster]

Tao Xu  writes:

> 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).
> Before using hmat-cache option, enable HMAT with -machine hmat=on.
>
> Signed-off-by: Liu Jingqi 
> Signed-off-by: Tao Xu 
> ---
>
> Changes in v19:
> - Add description about the machine property 'hmat' in commit
>   message (Markus)
> - Update the QAPI comments
> - Add a check for no memory side cache
>
> Changes in v18:
> - Update the error message (Igor)
>
> 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| 86 +++
>  include/sysemu/numa.h |  5 +++
>  qapi/machine.json | 81 +++-
>  qemu-options.hx   | 16 +++-
>  4 files changed, 184 insertions(+), 4 deletions(-)
>
> diff --git a/hw/core/numa.c b/hw/core/numa.c
> index 2183c8df1f..664b44ad68 100644
> --- a/hw/core/numa.c
> +++ b/hw/core/numa.c
> @@ -366,6 +366,79 @@ 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;
> +}
> +
> +if (!node->level && (node->assoc || node->policy || node->line)) {
> +error_setg(errp, "Assoc and policy options should be 'none', line "
> +   "should be 0. If cache level is 0, which means no memory "
> +   "side cache in node-id=%" PRIu32, node->node_id);

Error messages should be a phrase, not a paragraph; see error_setg()'s
function comment.  I think you want something like "be 0 when cache
level is 0".

I'm not sure the error message should explain what level 0 means, but
I'm happy to defer to the NUMA maintainers there.

> +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 less 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;
> +}
> +
> +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_c

[PATCH V2] block/nbd: fix memory leak in nbd_open()

[pannengyuan]

From: PanNengyuan 

In currently implementation there will be a memory leak when
nbd_client_connect() returns error status. Here is an easy way to
reproduce:

1. run qemu-iotests as follow and check the result with asan:
./check -raw 143

Following is the asan output backtrack:
Direct leak of 40 byte(s) in 1 object(s) allocated from:
#0 0x7f629688a560 in calloc (/usr/lib64/libasan.so.3+0xc7560)
#1 0x7f6295e7e015 in g_malloc0  (/usr/lib64/libglib-2.0.so.0+0x50015)
#2 0x56281dab4642 in qobject_input_start_struct  
/mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:295
#3 0x56281dab1a04 in visit_start_struct  
/mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:49
#4 0x56281dad1827 in visit_type_SocketAddress  qapi/qapi-visit-sockets.c:386
#5 0x56281da8062f in nbd_config   /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
#6 0x56281da8062f in nbd_process_options  
/mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
#7 0x56281da8062f in nbd_open  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873

Direct leak of 15 byte(s) in 1 object(s) allocated from:
#0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
#1 0x7f6295e7dfbd in g_malloc (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
#2 0x7f6295e96ace in g_strdup (/usr/lib64/libglib-2.0.so.0+0x68ace)
#3 0x56281da804ac in nbd_process_options 
/mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1834
#4 0x56281da804ac in nbd_open /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873

Indirect leak of 24 byte(s) in 1 object(s) allocated from:
#0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
#1 0x7f6295e7dfbd in g_malloc (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
#2 0x7f6295e96ace in g_strdup (/usr/lib64/libglib-2.0.so.0+0x68ace)
#3 0x56281dab41a3 in qobject_input_type_str_keyval  
/mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:536
#4 0x56281dab2ee9 in visit_type_str  
/mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:297
#5 0x56281dad0fa1 in visit_type_UnixSocketAddress_members 
qapi/qapi-visit-sockets.c:141
#6 0x56281dad17b6 in visit_type_SocketAddress_members  
qapi/qapi-visit-sockets.c:366
#7 0x56281dad186a in visit_type_SocketAddress qapi/qapi-visit-sockets.c:393
#8 0x56281da8062f in nbd_config /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
#9 0x56281da8062f in nbd_process_options 
/mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
#10 0x56281da8062f in nbd_open /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873

Reported-by: Euler Robot 
Signed-off-by: PanNengyuan 
---
Changes v2 to v1:
- add a new function to do the common cleanups (suggested by Stefano 
Garzarella).
---
 block/nbd.c | 26 --
 1 file changed, 16 insertions(+), 10 deletions(-)

diff --git a/block/nbd.c b/block/nbd.c
index 1239761..f8aa2a8 100644
--- a/block/nbd.c
+++ b/block/nbd.c
@@ -94,6 +94,8 @@ typedef struct BDRVNBDState {
 
 static int nbd_client_connect(BlockDriverState *bs, Error **errp);
 
+static void nbd_free_bdrvstate_prop(BDRVNBDState *s);
+
 static void nbd_channel_error(BDRVNBDState *s, int ret)
 {
 if (ret == -EIO) {
@@ -1486,6 +1488,17 @@ static int nbd_client_connect(BlockDriverState *bs, 
Error **errp)
 }
 }
 
+static void nbd_free_bdrvstate_prop(BDRVNBDState *s)
+{
+object_unref(OBJECT(s->tlscreds));
+qapi_free_SocketAddress(s->saddr);
+g_free(s->export);
+g_free(s->tlscredsid);
+if (s->x_dirty_bitmap) {
+g_free(s->x_dirty_bitmap);
+}
+}
+
 /*
  * Parse nbd_open options
  */
@@ -1855,10 +1868,7 @@ static int nbd_process_options(BlockDriverState *bs, 
QDict *options,
 
  error:
 if (ret < 0) {
-object_unref(OBJECT(s->tlscreds));
-qapi_free_SocketAddress(s->saddr);
-g_free(s->export);
-g_free(s->tlscredsid);
+nbd_free_bdrvstate_prop(s);
 }
 qemu_opts_del(opts);
 return ret;
@@ -1881,6 +1891,7 @@ static int nbd_open(BlockDriverState *bs, QDict *options, 
int flags,
 
 ret = nbd_client_connect(bs, errp);
 if (ret < 0) {
+nbd_free_bdrvstate_prop(s);
 return ret;
 }
 /* successfully connected */
@@ -1937,12 +1948,7 @@ static void nbd_close(BlockDriverState *bs)
 BDRVNBDState *s = bs->opaque;
 
 nbd_client_close(bs);
-
-object_unref(OBJECT(s->tlscreds));
-qapi_free_SocketAddress(s->saddr);
-g_free(s->export);
-g_free(s->tlscredsid);
-g_free(s->x_dirty_bitmap);
+nbd_free_bdrvstate_prop(s);
 }
 
 static int64_t nbd_getlength(BlockDriverState *bs)
-- 
2.7.2.windows.1

Re: [RFC v5 000/126] error: auto propagated local_err

[Markus Armbruster]

Vladimir Sementsov-Ogievskiy  writes:

> 28.11.2019 11:54, Markus Armbruster wrote:
>> Please accept my sincere apologies for taking so long to reply.  A few
>> thoughts before I dig deeper.
>> 
>> Vladimir Sementsov-Ogievskiy  writes:
>> 
>>> Hi all!
>>>
>>> At the request of Markus: full version of errp propagation. Let's look
>>> at it. Cover as much as possible, except inserting macro invocation
>>> where it's not necessary.
>>>
>>> It's huge, and so it's an RFC.
>> 
>> It's a monster.  Best to get it into full view before we commit to
>> fighting it.
>> 
>>> In v5 I've added a lot more preparation cleanups:
>>> 01-23 are preparation cleanups
>>>01: not changed, keep Eric's r-b
>>>02: improve commit msg [Markus], keep Eric's r-b
>>>03: changed, only error API here, drop r-b
>>> 24 is core macro
>>>- improve cover letter, wording and macro code style
>>>- keep Eric's r-b
>>> 25-26: automation scripts
>>> - commit-per-subsystem changed a lot. it's a draft, don't bother too
>>>   much with it
>>> - coccinelle: add support of error_propagate_prepend
>>>
>>> 27-126: generated patches
>> 
>> Splitting up the monster can make fighting it easier.
>> 
>> Your description suggests three high-level parts:
>> 
>> Part 1: Preparation (makes sense by itself)
>
> I already resent part 1 all patches (handling review comments) in separate as 
> v6.
> If it is convenient, I can resend them in one series as v7.

Recommend to await review.  The more we can merge without another
respin, the better.

>> Part 2: Error interface update (with rules what code should do now)
>
> Note, that patch 21 is actually from part2, not part1.
> So Part 2 is 21, 24, 25.

Thanks for the heads-up.

> So I wait for your comments and resend (if needed) as separate small series.
>
> And 26 is auto-patch-splitter, but we don't need it now, if we are going
> to start from several big subsystems.
>
>> Part 3: Make the code obey the new rules everywhere
>> 
>> I hope we can get part 1 out of the way quickly.  Diffstat:
>> 
>>   backends/cryptodev.c   |  11 +---
>>   block/nbd.c|  10 +--
>>   block/snapshot.c   |   4 +-
>>   dump/dump-hmp-cmds.c   |   4 +-
>>   hw/9pfs/9p-local.c |   4 +-
>>   hw/9pfs/9p-proxy.c |   5 +-
>>   hw/core/loader-fit.c   |   5 +-
>>   hw/core/machine-hmp-cmds.c |   6 +-
>>   hw/core/qdev.c |  28 
>>   hw/i386/amd_iommu.c|  14 ++--
>>   hw/ppc/spapr.c |   2 +-
>>   hw/s390x/event-facility.c  |   2 +-
>>   hw/s390x/s390-stattrib.c   |   3 +-
>>   hw/sd/sdhci.c  |   2 +-
>>   hw/tpm/tpm_emulator.c  |   8 +--
>>   hw/usb/dev-network.c   |   2 +-
>>   hw/vfio/ap.c   |  16 +
>>   include/block/snapshot.h   |   2 +-
>>   include/monitor/hmp.h  |   2 +-
>>   include/qapi/error.h   |  69 ++--
>>   include/qom/object.h   |   4 +-
>>   monitor/hmp-cmds.c | 155 
>> ++---
>>   monitor/qmp-cmds.c |   2 +-
>>   net/net.c  |  17 ++---
>>   qdev-monitor.c |  28 
>>   qga/commands-posix.c   |   2 +-
>>   qga/commands-win32.c   |   2 +-
>>   qga/commands.c |  12 ++--
>>   qom/qom-hmp-cmds.c |   4 +-
>>   target/ppc/kvm.c   |   6 +-
>>   target/ppc/kvm_ppc.h   |   4 +-
>>   ui/vnc.c   |  20 ++
>>   ui/vnc.h   |   2 +-
>>   util/error.c   |  30 -
>>   34 files changed, 261 insertions(+), 226 deletions(-)
>> 
>> At first glance, I can see bug fixes, non-mechanical cleanups, and
>> mechanical cleanups.
>> 
>> Within each of these three groups, we have related sub-groups.  For
>> instance, several patches clean up funny names for the common Error **
>> parameters.  Several more rename "uncommon" Error ** parameters, to
>> signal their uncommon role.  I doubt splitting up these subgroups of
>> related mechanical changes along subsystem lines is worthwhile.
>> 
>> Part 2 needs careful interface review.  Having part 3 ready helps there,
>> because we can see rather than guess how the interface changes play out.
>> We really want to get this part right from the start, because if we
>> don't, we get to do part 3 again.
>> 
>> Part 3 is what makes this a monster.  I understand it's mechanical.  We
>> can merge it incrementally, but we do want to merge it all, and sooner
>> rather than later, to avoid a mix of old and new error handling code.
>> Such mixes inevitably confuse developers, and lead to new instances of
>> the old patterns creeping in.
>> 
>> I do have doubts about your automated split.
>> 
>> I acknowledge maintainers of active subsystems may want to merge this on
>> their own terms, to minimize disruption.  Splitting off sub-monsters for
>> them makes sense.  Splitting off the long tail of less busy subsystems
>> not so much; it'll only drag out the merging.  Your list 

Re: [PATCH v1 0/1] s390x: protvirt: SCLP interpretation

[Janosch Frank]

On 11/28/19 11:13 AM, Pierre Morel wrote:
> A new proposition:
> I think it would be wise to fork directly from handle_instruction
> instead to accept per default all instructions with with secure
> instruction interception code.
> Just in case future firmware with older QEMU.
> 
> How ever I let three dors open.
> 
> 1) This patch accepts the all B2 instructions, mostly I/O.
> Some of the instructions will not work correctly for PV until patched.
> This should be fixed, and will be, in a separate patch.
> 
> 2) The same is true for DIAG instructions.
> 
> 3) Secure notifications are separated from secure instructions and
> normal instructions interception because this case is completely new.
> For B2 instructions we do not have to do anything this just informative.
> However, one information is of interrest, a notification that
> SIGP(STOP) is sent to stop the CPUs and terminate QEMU.

Pierre, I told you this morning that I don't want this and that you
should leave this untouched until I can explain my thoughts behind the
initial patch in a f2f.
Thomas' review of your change only confirmed my concerns about this patch.

This is the wrong patch at the wrong time, which creates noise and work
for other people. Please stop and work on something else.



> 
> 
> 
> Pierre Morel (1):
>   s390x: protvirt: SCLP interpretation
> 
>  hw/s390x/sclp.c | 18 +
>  include/hw/s390x/sclp.h |  2 ++
>  target/s390x/kvm.c  | 56 -
>  3 files changed, 75 insertions(+), 1 deletion(-)
> 




signature.asc
Description: OpenPGP digital signature

[PATCH v1 1/1] pc-bios/s390-ccw: fix sclp_get_loadparm_ascii

[Claudio Imbrenda]

The existing s390 bios gets the LOADPARM information from the system using
an SCLP call that specifies a buffer length too small to contain all the
output.

The recent fixes in the SCLP code have exposed this bug, since now the
SCLP call will return an error (as per architecture) instead of
writing partially and completing successfully.

The solution is simply to specify the full page length as the SCCB
length instead of a smaller size.

Fixes: 832be0d8a3bb ("s390x: sclp: Report insufficient SCCB length")
Fixes: 9a22473c70f3 ("pc-bios/s390-ccw: get LOADPARM stored in SCP Read Info")

Signed-off-by: Claudio Imbrenda 
---
 pc-bios/s390-ccw/sclp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pc-bios/s390-ccw/sclp.c b/pc-bios/s390-ccw/sclp.c
index c0223fa..7251f9a 100644
--- a/pc-bios/s390-ccw/sclp.c
+++ b/pc-bios/s390-ccw/sclp.c
@@ -112,7 +112,7 @@ void sclp_get_loadparm_ascii(char *loadparm)
 ReadInfo *sccb = (void *)_sccb;
 
 memset((char *)_sccb, 0, sizeof(ReadInfo));
-sccb->h.length = sizeof(ReadInfo);
+sccb->h.length = SCCB_SIZE;
 if (!sclp_service_call(SCLP_CMDW_READ_SCP_INFO, sccb)) {
 ebcdic_to_ascii((char *) sccb->loadparm, loadparm, LOADPARM_LEN);
 }
-- 
2.7.4

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Michael Rolnik]

On Wed, Nov 27, 2019 at 11:06 PM Aleksandar Markovic <
aleksandar.m.m...@gmail.com> wrote:

> On Wed, Nov 27, 2019 at 6:53 PM Michael Rolnik  wrote:
> >
> > This series of patches adds 8bit AVR cores to QEMU.
> > All instruction, except BREAK/DES/SPM/SPMX, are implemented. Not fully
> tested yet.
> > However I was able to execute simple code with functions. e.g fibonacci
> calculation.
> > This series of patches include a non real, sample board.
> > No fuses support yet. PC is set to 0 at reset.
> >
>
> I have a couple of general remarks, so I am responding to the cover
> letter, not individual patches.
>
> 1) The licenses for Sarah devices differ than the rest - shouldn't all
> licenses be harmonized?

Sarah,
do you mind if use the same license I use for my code?


>


> 2) There is an architectural problem with peripherals. It is possible
> that they evolve over time, so, for example, USART could not be the
> same for older and newer CPUs (in principle, newer peripheral is
> expected to be o sort of "superset" of the older). How do you solve
> that problem? Right now, it may not looks serious to you, but if you
> don;t think about that right now, from the outset, soon the code will
> become so entangled, ti woudl be almost very difficult to fix it.
> Please think about that, how would you solve it, is there a way to
> pass the information on the currently emulated CPU to the code
> covering a peripheral, and provide a different behaviour?
>
Hi Aleksandar,

Please explain. I don't see any problem from CPU's perspective.
as for the sample board is just a sample, I hope other people will create
real models or real hw.
there was no way I could provide a CPU alone, that's why there is sample.



>
> > Following are examples of possible usages, assuming program.elf is
> compiled for AVR cpu
> > 1.  Continious non interrupted execution
> > run `qemu-system-avr -kernel program.elf`
> > 2.  Continious non interrupted execution with serial output into telnet
> window
> > run `qemu-system-avr -kernel program.elf -serial
> tcp::5678,server,nowait -nographic `
> > run `telent localhost 5678`
> > 3.  Continious non interrupted execution with serial output into stdout
> > run `qemu-system-avr -kernel program.elf -serial stdio`
> > 4.  Debugging wit GDB debugger
> > run `qemu-system-avr -kernel program.elf -s -S`
> > run `avr-gdb program.elf` and then within GDB shell `target remote
> :1234`
> > 5.  Print out executed instructions
> > run `qemu-system-avr -kernel program.elf -d in_asm`
> >
>
> Thank you so much for these examples!
>
> Aleksandar
>
>
> >
> > the patches include the following
> > 1. just a basic 8bit AVR CPU, without instruction decoding or translation
> > 2. CPU features which allow define the following 8bit AVR cores
> >  avr1
> >  avr2 avr25
> >  avr3 avr31 avr35
> >  avr4
> >  avr5 avr51
> >  avr6
> >  xmega2 xmega4 xmega5 xmega6 xmega7
> > 3. a definition of sample machine with SRAM, FLASH and CPU which allows
> to execute simple code
> > 4. encoding for all AVR instructions
> > 5. interrupt handling
> > 6. helpers for IN, OUT, SLEEP, WBR & unsupported instructions
> > 7. a decoder which given an opcode decides what istruction it is
> > 8. translation of AVR instruction into TCG
> > 9. all features together
> >
> > changes since v3
> > 1. rampD/X/Y/Z registers are encoded as 0x00ff (instead of
> 0x00ff) for faster address manipulaton
> > 2. ffs changed to ctz32
> > 3. duplicate code removed at avr_cpu_do_interrupt
> > 4. using andc instead of not + and
> > 5. fixing V flag calculation in varios instructions
> > 6. freeing local variables in PUSH
> > 7. tcg_const_local_i32 -> tcg_const_i32
> > 8. using sextract32 instead of my implementation
> > 9. fixing BLD instruction
> > 10.xor(r) instead of 0xff - r at COM
> > 11.fixing MULS/MULSU not to modify inputs' content
> > 12.using SUB for NEG
> > 13.fixing tcg_gen_qemu_ld/st call in XCH
> >
> > changes since v4
> > 1. target is now defined as big endian in order to optimize
> push_ret/pop_ret
> > 2. all style warnings are fixed
> > 3. adding cpu_set/get_sreg functions
> > 4. simplifying gen_goto_tb as there is no real paging
> > 5. env->pc -> env->pc_w
> > 6. making flag dump more compact
> > 7. more spacing
> > 8. renaming CODE/DATA_INDEX -> MMU_CODE/DATA_IDX
> > 9. removing avr_set_feature
> > 10. SPL/SPH set bug fix
> > 11. switching stb_phys to cpu_stb_data
> > 12. cleaning up avr_decode
> > 13. saving sreg, rampD/X/Y/Z, eind in HW format (savevm)
> > 14. saving CPU features (savevm)
> >
> > changes since v5
> > 1. BLD bug fix
> > 2. decoder generator is added
> >
> > chages since v6
> > 1. using cpu_get_sreg/cpu_set_sreg in
> avr_cpu_gdb_read_register/avr_cpu_gdb_write_register
> > 2. configure the target as little endian because otherwise GDB does not
> work
> > 3. fixing and testing gen_push_ret/gen_pop_ret
> >
> > changes since v7
> > 1. folding back v6
> > 2. logging at helper_outb 

[PATCH RFC] qga: fence guest-set-time if hwclock not available

[Cornelia Huck]

The Posix implementation of guest-set-time invokes hwclock to
set/retrieve the time to/from the hardware clock. If hwclock
is not available, the user is currently informed that "hwclock
failed to set hardware clock to system time", which is quite
misleading. This may happen e.g. on s390x, which has a different
timekeeping concept anyway.

Let's check for the availability of the hwclock command and
return QERR_UNSUPPORTED for guest-set-time if it is not available.

Signed-off-by: Cornelia Huck 
---

Not sure if that is the correct approach, but the current error
message is really quite confusing.

Gave it a quick test with an s390x and an x86_64 guest; invoking
'virsh domtime ' now fails with 'not currently supported'
on s390x and continues to work as before on x86_64.

---
 qga/commands-posix.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/qga/commands-posix.c b/qga/commands-posix.c
index 1c1a165daed8..bd298a38b716 100644
--- a/qga/commands-posix.c
+++ b/qga/commands-posix.c
@@ -149,6 +149,13 @@ int64_t qmp_guest_get_time(Error **errp)
return tq.tv_sec * 10LL + tq.tv_usec * 1000;
 }
 
+static int check_hwclock_available(const char *path)
+{
+struct stat st;
+
+return (stat(path, &st) < 0) ? 0 : 1;
+}
+
 void qmp_guest_set_time(bool has_time, int64_t time_ns, Error **errp)
 {
 int ret;
@@ -156,6 +163,17 @@ void qmp_guest_set_time(bool has_time, int64_t time_ns, 
Error **errp)
 pid_t pid;
 Error *local_err = NULL;
 struct timeval tv;
+const char *hwclock_path = "/sbin/hwclock";
+static int hwclock_available = -1;
+
+if (hwclock_available < 0) {
+hwclock_available = check_hwclock_available(hwclock_path);
+}
+
+if (!hwclock_available) {
+error_setg(errp, QERR_UNSUPPORTED);
+return;
+}
 
 /* If user has passed a time, validate and set it. */
 if (has_time) {
@@ -195,7 +213,7 @@ void qmp_guest_set_time(bool has_time, int64_t time_ns, 
Error **errp)
 
 /* Use '/sbin/hwclock -w' to set RTC from the system time,
  * or '/sbin/hwclock -s' to set the system time from RTC. */
-execle("/sbin/hwclock", "hwclock", has_time ? "-w" : "-s",
+execle(hwclock_path, "hwclock", has_time ? "-w" : "-s",
NULL, environ);
 _exit(EXIT_FAILURE);
 } else if (pid < 0) {
-- 
2.21.0

Re: [PATCH v1 1/1] pc-bios/s390-ccw: fix sclp_get_loadparm_ascii

[Christian Borntraeger]

Ack.

Conny, I think this would be really nice to have for 4.2 (together with a bios 
rebuild)
as this fixes a regression. Opinions?



On 28.11.19 13:33, Claudio Imbrenda wrote:
> The existing s390 bios gets the LOADPARM information from the system using
> an SCLP call that specifies a buffer length too small to contain all the
> output.
> 
> The recent fixes in the SCLP code have exposed this bug, since now the
> SCLP call will return an error (as per architecture) instead of
> writing partially and completing successfully.
> 
> The solution is simply to specify the full page length as the SCCB
> length instead of a smaller size.
> 
> Fixes: 832be0d8a3bb ("s390x: sclp: Report insufficient SCCB length")
> Fixes: 9a22473c70f3 ("pc-bios/s390-ccw: get LOADPARM stored in SCP Read Info")
> 
> Signed-off-by: Claudio Imbrenda 
> ---
>  pc-bios/s390-ccw/sclp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/pc-bios/s390-ccw/sclp.c b/pc-bios/s390-ccw/sclp.c
> index c0223fa..7251f9a 100644
> --- a/pc-bios/s390-ccw/sclp.c
> +++ b/pc-bios/s390-ccw/sclp.c
> @@ -112,7 +112,7 @@ void sclp_get_loadparm_ascii(char *loadparm)
>  ReadInfo *sccb = (void *)_sccb;
>  
>  memset((char *)_sccb, 0, sizeof(ReadInfo));
> -sccb->h.length = sizeof(ReadInfo);
> +sccb->h.length = SCCB_SIZE;
>  if (!sclp_service_call(SCLP_CMDW_READ_SCP_INFO, sccb)) {
>  ebcdic_to_ascii((char *) sccb->loadparm, loadparm, LOADPARM_LEN);
>  }
> 

RE: [PATCH 0/5] ARM virt: Add NVDIMM support

[Shameerali Kolothum Thodi]

> -Original Message-
> From: Qemu-devel
> [mailto:qemu-devel-bounces+shameerali.kolothum.thodi=huawei.com@nongn
> u.org] On Behalf Of Igor Mammedov
> Sent: 26 November 2019 08:57
> To: Shameerali Kolothum Thodi 
> Cc: peter.mayd...@linaro.org; drjo...@redhat.com;
> xiaoguangrong.e...@gmail.com; shannon.zha...@gmail.com;
> qemu-devel@nongnu.org; Linuxarm ; Auger Eric
> ; qemu-...@nongnu.org; xuwei (O)
> ; ler...@redhat.com
> Subject: Re: [PATCH 0/5] ARM virt: Add NVDIMM support

[..]

> > > 0xb8 Dirty No.  -->Another read is attempted
> > > > [Qemu]NVDIMM:nvdimm_dsm_func_read_fit: read_fit_out buf size 0x8
> > > func_ret_status 3  --> Error status returned
> > >
> > > status 3 means that QEMU didn't like content of NRAM, and there is only
> > > 1 place like this in nvdimm_dsm_func_read_fit()
> > > if (read_fit->offset > fit->len) {
> > > func_ret_status = NVDIMM_DSM_RET_STATUS_INVALID;
> > > goto exit;
> > > }
> > >
> > > so I'd start looking from here and check that QEMU gets expected data
> > > in nvdimm_dsm_write(). In other words I'd try to trace/compare
> > > content of DSM buffer (from qemu side).
> >
> > I had printed the DSM buffer previously and it looked same, I will double 
> > check
> > that.

Tried printing the buffer in both Qemu/AML code.

On Amr64,
-
(1st iteration with offset 0)
[QEMU]NVDIMM:nvdimm_dsm_func_read_fit: Read FIT: offset 0 FIT size 0xb8 Dirty 
Yes.
[QEMU]NVDIMM:nvdimm_dsm_func_read_fit: read_fit_out buff: 
[QEMU]NVDIMM BUF[0x0] = 0xC0
[QEMU]NVDIMM BUF[0x1] = 0x0
[QEMU]NVDIMM BUF[0x2] = 0x0
[QEMU]NVDIMM BUF[0x3] = 0x0
[QEMU]NVDIMM BUF[0x4] = 0x0
[QEMU]NVDIMM BUF[0x5] = 0x0
[QEMU]NVDIMM BUF[0x6] = 0x0
[QEMU]NVDIMM BUF[0x7] = 0x0
[QEMU]NVDIMM BUF[0x8] = 0x0
[QEMU]NVDIMM BUF[0x9] = 0x0
[QEMU]NVDIMM BUF[0xA] = 0x38
[QEMU]NVDIMM BUF[0xB] = 0x0
[QEMU]NVDIMM BUF[0xC] = 0x2
[QEMU]NVDIMM BUF[0xD] = 0x0
[QEMU]NVDIMM BUF[0xE] = 0x3
[QEMU]NVDIMM BUF[0xF] = 0x0
.
[QEMU]NVDIMM BUF[0xBC] = 0x0
[QEMU]NVDIMM BUF[0xBD] = 0x0
[QEMU]NVDIMM BUF[0xBE] = 0x0
[QEMU]NVDIMM BUF[0xBF] = 0x0
[QEMU]NVDIMM:nvdimm_dsm_func_read_fit: read_fit_out buf size 0xc0 
func_ret_status 0 

"AML:NVDIMM-NCAL: Rcvd RLEN 00C0"
"AML:NVDIMM-NCAL TBUF[] = 0x00C0"
"AML:NVDIMM-NCAL TBUF[0001] = 0x"
"AML:NVDIMM-NCAL TBUF[0002] = 0x"
"AML:NVDIMM-NCAL TBUF[0003] = 0x"
"AML:NVDIMM-NCAL TBUF[0004] = 0x"
"AML:NVDIMM-NCAL TBUF[0005] = 0x"
"AML:NVDIMM-NCAL TBUF[0006] = 0x"
"AML:NVDIMM-NCAL TBUF[0007] = 0x"
"AML:NVDIMM-NCAL TBUF[0008] = 0x"
"AML:NVDIMM-NCAL TBUF[0009] = 0x"
"AML:NVDIMM-NCAL TBUF[000A] = 0x0038"
"AML:NVDIMM-NCAL TBUF[000B] = 0x"
"AML:NVDIMM-NCAL TBUF[000C] = 0x0002"
"AML:NVDIMM-NCAL TBUF[000D] = 0x"
"AML:NVDIMM-NCAL TBUF[000E] = 0x0003"
"AML:NVDIMM-NCAL TBUF[000F] = 0x"
...
"AML:NVDIMM-NCAL TBUF[00BC] = 0x"
"AML:NVDIMM-NCAL TBUF[00BD] = 0x"
"AML:NVDIMM-NCAL TBUF[00BE] = 0x"
"AML:NVDIMM-NCAL TBUF[00BF] = 0x"
"AML:NVDIMM-NCAL: Creating OBUF with bytes 00BC"
"AML:NVDIMM-NCAL: Created  BUF(Local7) size 00BC"
"AML:NVDIMM-RFIT Rcvd buf size 00BC"
"AML:NVDIMM-RFIT Created NVDR.RFIT.BUFF size 00B8"
"AML:NVDIMM-FIT: Rcvd buf size 00B8" -->All looks fine in first 
iteration.

(2nd iteration with offset 0xb8)
[QEMU]NVDIMM:nvdimm_dsm_func_read_fit: Read FIT: offset 0xb8 FIT size 0xb8 
Dirty No.
[QEMU]NVDIMM:nvdimm_dsm_func_read_fit: read_fit_out buff: 
[QEMU]NVDIMM BUF[0x0] = 0x8
[QEMU]NVDIMM BUF[0x1] = 0x0
[QEMU]NVDIMM BUF[0x2] = 0x0
[QEMU]NVDIMM BUF[0x3] = 0x0
[QEMU]NVDIMM BUF[0x4] = 0x0
[QEMU]NVDIMM BUF[0x5] = 0x0
[QEMU]NVDIMM BUF[0x6] = 0x0
[QEMU]NVDIMM BUF[0x7] = 0x0
[QEMU]NVDIMM:nvdimm_dsm_func_read_fit: read_fit_out buf size 0x8 
func_ret_status 0 

"AML:NVDIMM-NCAL: Rcvd RLEN 0008"
"AML:NVDIMM-NCAL TBUF[] = 0x0008"
"AML:NVDIMM-NCAL TBUF[0001] = 0x"
"AML:NVDIMM-NCAL TBUF[0002] = 0x"
"AML:NVDIMM-NCAL TBUF[0003] = 0x"
"AML:NVDIMM-NCAL TBUF[0004] = 0x"
"AML:NVDIMM-NCAL TBUF[0005] = 0x"
"AML:NVDIMM-NCAL TBUF[0006] = 0x"
"AML:NVDIMM-NCAL TBUF[0007] = 0x"
"AML:NVDIMM-NCAL: Creating OBUF with bytes 0004"   -->Requested 
size is 4
"AML:NVDIMM-NCAL: Created  BUF(Local7) size 0008" --> Created size 
is 8 !.

Re: [PATCH RFC] qga: fence guest-set-time if hwclock not available

[Daniel P . Berrangé]

On Thu, Nov 28, 2019 at 01:36:58PM +0100, Cornelia Huck wrote:
> The Posix implementation of guest-set-time invokes hwclock to
> set/retrieve the time to/from the hardware clock. If hwclock
> is not available, the user is currently informed that "hwclock
> failed to set hardware clock to system time", which is quite
> misleading. This may happen e.g. on s390x, which has a different
> timekeeping concept anyway.
> 
> Let's check for the availability of the hwclock command and
> return QERR_UNSUPPORTED for guest-set-time if it is not available.
> 
> Signed-off-by: Cornelia Huck 
> ---
> 
> Not sure if that is the correct approach, but the current error
> message is really quite confusing.

I guess the alternative is to just #ifndef __s390x__ the whole
impl of the qmp_guest_set_time  method, but I don't have a
strong opinion on which is best.

> 
> Gave it a quick test with an s390x and an x86_64 guest; invoking
> 'virsh domtime ' now fails with 'not currently supported'
> on s390x and continues to work as before on x86_64.
> 
> ---
>  qga/commands-posix.c | 20 +++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/qga/commands-posix.c b/qga/commands-posix.c
> index 1c1a165daed8..bd298a38b716 100644
> --- a/qga/commands-posix.c
> +++ b/qga/commands-posix.c
> @@ -149,6 +149,13 @@ int64_t qmp_guest_get_time(Error **errp)
> return tq.tv_sec * 10LL + tq.tv_usec * 1000;
>  }
>  
> +static int check_hwclock_available(const char *path)
> +{
> +struct stat st;
> +
> +return (stat(path, &st) < 0) ? 0 : 1;
> +}
> +
>  void qmp_guest_set_time(bool has_time, int64_t time_ns, Error **errp)
>  {
>  int ret;
> @@ -156,6 +163,17 @@ void qmp_guest_set_time(bool has_time, int64_t time_ns, 
> Error **errp)
>  pid_t pid;
>  Error *local_err = NULL;
>  struct timeval tv;
> +const char *hwclock_path = "/sbin/hwclock";
> +static int hwclock_available = -1;
> +
> +if (hwclock_available < 0) {
> +hwclock_available = check_hwclock_available(hwclock_path);

Could do this inline with:

hwclock_available = (access(hwclock_available, X_OK) == 0);

getting a slightly better result as this check for it being
executable as well as existing.

> +}
> +
> +if (!hwclock_available) {
> +error_setg(errp, QERR_UNSUPPORTED);
> +return;
> +}
>  
>  /* If user has passed a time, validate and set it. */
>  if (has_time) {
> @@ -195,7 +213,7 @@ void qmp_guest_set_time(bool has_time, int64_t time_ns, 
> Error **errp)
>  
>  /* Use '/sbin/hwclock -w' to set RTC from the system time,
>   * or '/sbin/hwclock -s' to set the system time from RTC. */
> -execle("/sbin/hwclock", "hwclock", has_time ? "-w" : "-s",
> +execle(hwclock_path, "hwclock", has_time ? "-w" : "-s",
> NULL, environ);
>  _exit(EXIT_FAILURE);
>  } else if (pid < 0) {
> -- 
> 2.21.0
> 
> 

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

[PATCH v5] qga: add command guest-get-devices for reporting VirtIO devices

[Tomáš Golembiovský]

Add command for reporting devices on Windows guest. The intent is not so
much to report the devices but more importantly the driver (and its
version) that is assigned to the device. This gives caller the
information whether VirtIO drivers are installed and/or whether
inadequate driver is used on a device (e.g. QXL device with base VGA
driver).

Signed-off-by: Tomáš Golembiovský 
---

changes in v5:
- updated version in schema

changes in v4:
- making check-patch happy

 qga/commands-posix.c |   9 ++
 qga/commands-win32.c | 204 ++-
 qga/qapi-schema.json |  32 +++
 3 files changed, 244 insertions(+), 1 deletion(-)

diff --git a/qga/commands-posix.c b/qga/commands-posix.c
index 1c1a165dae..efcd9174a8 100644
--- a/qga/commands-posix.c
+++ b/qga/commands-posix.c
@@ -2758,6 +2758,8 @@ GList *ga_command_blacklist_init(GList *blacklist)
 blacklist = g_list_append(blacklist, g_strdup("guest-fstrim"));
 #endif
 
+blacklist = g_list_append(blacklist, g_strdup("guest-get-devices"));
+
 return blacklist;
 }
 
@@ -2978,3 +2980,10 @@ GuestOSInfo *qmp_guest_get_osinfo(Error **errp)
 
 return info;
 }
+
+GuestDeviceInfoList *qmp_guest_get_devices(Error **errp)
+{
+error_setg(errp, QERR_UNSUPPORTED);
+
+return NULL;
+}
diff --git a/qga/commands-win32.c b/qga/commands-win32.c
index 55ba5b263a..cd942b3fb3 100644
--- a/qga/commands-win32.c
+++ b/qga/commands-win32.c
@@ -21,10 +21,11 @@
 #ifdef CONFIG_QGA_NTDDSCSI
 #include 
 #include 
+#endif
 #include 
 #include 
 #include 
-#endif
+#include 
 #include 
 #include 
 #include 
@@ -38,6 +39,36 @@
 #include "qemu/host-utils.h"
 #include "qemu/base64.h"
 
+/*
+ * The following should be in devpkey.h, but it isn't. The key names were
+ * prefixed to avoid (future) name clashes. Once the definitions get into
+ * mingw the following lines can be removed.
+ */
+DEFINE_DEVPROPKEY(qga_DEVPKEY_NAME, 0xb725f130, 0x47ef, 0x101a, 0xa5,
+0xf1, 0x02, 0x60, 0x8c, 0x9e, 0xeb, 0xac, 10);
+/* DEVPROP_TYPE_STRING */
+DEFINE_DEVPROPKEY(qga_DEVPKEY_Device_HardwareIds, 0xa45c254e, 0xdf1c,
+0x4efd, 0x80, 0x20, 0x67, 0xd1, 0x46, 0xa8, 0x50, 0xe0, 3);
+/* DEVPROP_TYPE_STRING_LIST */
+DEFINE_DEVPROPKEY(qga_DEVPKEY_Device_DriverDate, 0xa8b865dd, 0x2e3d,
+0x4094, 0xad, 0x97, 0xe5, 0x93, 0xa7, 0xc, 0x75, 0xd6, 2);
+/* DEVPROP_TYPE_FILETIME */
+DEFINE_DEVPROPKEY(qga_DEVPKEY_Device_DriverVersion, 0xa8b865dd, 0x2e3d,
+0x4094, 0xad, 0x97, 0xe5, 0x93, 0xa7, 0xc, 0x75, 0xd6, 3);
+/* DEVPROP_TYPE_STRING */
+/* The following shoud be in cfgmgr32.h, but it isn't */
+#ifndef CM_Get_DevNode_Property
+CMAPI CONFIGRET WINAPI CM_Get_DevNode_PropertyW(
+DEVINST  dnDevInst,
+CONST DEVPROPKEY * PropertyKey,
+DEVPROPTYPE  * PropertyType,
+PBYTEPropertyBuffer,
+PULONG   PropertyBufferSize,
+ULONGulFlags
+);
+#define CM_Get_DevNode_Property CM_Get_DevNode_PropertyW
+#endif
+
 #ifndef SHTDN_REASON_FLAG_PLANNED
 #define SHTDN_REASON_FLAG_PLANNED 0x8000
 #endif
@@ -92,6 +123,8 @@ static OpenFlags guest_file_open_modes[] = {
 g_free(suffix); \
 } while (0)
 
+G_DEFINE_AUTOPTR_CLEANUP_FUNC(GuestDeviceInfo, qapi_free_GuestDeviceInfo)
+
 static OpenFlags *find_open_flag(const char *mode_str)
 {
 int mode;
@@ -2234,3 +2267,172 @@ GuestOSInfo *qmp_guest_get_osinfo(Error **errp)
 
 return info;
 }
+
+/*
+ * Safely get device property. Returned strings are using wide characters.
+ * Caller is responsible for freeing the buffer.
+ */
+static LPBYTE cm_get_property(DEVINST devInst, const DEVPROPKEY *propName,
+PDEVPROPTYPE propType)
+{
+CONFIGRET cr;
+g_autofree LPBYTE buffer = NULL;
+ULONG buffer_len = 0;
+
+/* First query for needed space */
+cr = CM_Get_DevNode_PropertyW(devInst, propName, propType,
+buffer, &buffer_len, 0);
+if (cr != CR_SUCCESS && cr != CR_BUFFER_SMALL) {
+
+slog("failed to get property size, error=0x%lx", cr);
+return NULL;
+}
+buffer = g_new0(BYTE, buffer_len + 1);
+cr = CM_Get_DevNode_PropertyW(devInst, propName, propType,
+buffer, &buffer_len, 0);
+if (cr != CR_SUCCESS) {
+slog("failed to get device property, error=0x%lx", cr);
+return NULL;
+}
+return g_steal_pointer(&buffer);
+}
+
+static GStrv ga_get_hardware_ids(DEVINST devInstance)
+{
+GStrv hw_ids = NULL;
+GArray *values = NULL;
+DEVPROPTYPE cm_type;
+LPWSTR id;
+g_autofree LPWSTR property = (LPWSTR)cm_get_property(devInstance,
+&qga_DEVPKEY_Device_HardwareIds, &cm_type);
+if (property == NULL) {
+slog("failed to get hardware IDs");
+return NULL;
+}
+if (*property == '\0') {
+/* empty list */
+return NULL;
+}
+values = g_array_new(TRUE, TRUE, sizeof(gchar *));
+for (id = property; '\0' != *id; id += lstrlenW(id) + 1) {
+gchar *id8 = g_utf16_to_utf8(id, -1, NULL, NULL, NULL);
+g_arr

Re: [PATCH v1 1/1] pc-bios/s390-ccw: fix sclp_get_loadparm_ascii

[Janosch Frank]

On 11/28/19 1:33 PM, Claudio Imbrenda wrote:
> The existing s390 bios gets the LOADPARM information from the system using
> an SCLP call that specifies a buffer length too small to contain all the
> output.
> 
> The recent fixes in the SCLP code have exposed this bug, since now the
> SCLP call will return an error (as per architecture) instead of
> writing partially and completing successfully.
> 
> The solution is simply to specify the full page length as the SCCB
> length instead of a smaller size.
> 
> Fixes: 832be0d8a3bb ("s390x: sclp: Report insufficient SCCB length")
> Fixes: 9a22473c70f3 ("pc-bios/s390-ccw: get LOADPARM stored in SCP Read Info")


"pc-bios/s390-ccw: fix sclp readinfo buffer length indication"?

Reviewed-by: Janosch Frank 

> 
> Signed-off-by: Claudio Imbrenda 
> ---
>  pc-bios/s390-ccw/sclp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/pc-bios/s390-ccw/sclp.c b/pc-bios/s390-ccw/sclp.c
> index c0223fa..7251f9a 100644
> --- a/pc-bios/s390-ccw/sclp.c
> +++ b/pc-bios/s390-ccw/sclp.c
> @@ -112,7 +112,7 @@ void sclp_get_loadparm_ascii(char *loadparm)
>  ReadInfo *sccb = (void *)_sccb;
>  
>  memset((char *)_sccb, 0, sizeof(ReadInfo));
> -sccb->h.length = sizeof(ReadInfo);
> +sccb->h.length = SCCB_SIZE;
>  if (!sclp_service_call(SCLP_CMDW_READ_SCP_INFO, sccb)) {
>  ebcdic_to_ascii((char *) sccb->loadparm, loadparm, LOADPARM_LEN);
>  }
> 




signature.asc
Description: OpenPGP digital signature

Re: [PATCH v1 1/1] pc-bios/s390-ccw: fix sclp_get_loadparm_ascii

[Claudio Imbrenda]

On Thu, 28 Nov 2019 13:33:57 +0100
Claudio Imbrenda  wrote:

[...]

> Signed-off-by: Claudio Imbrenda 

I forgot this:

Reported-by: Marc Hartmayer 

[...]

please add the reported-by when merging :)

[PATCH] Adding support for MAC filtering in the FEC IP implementation

[Wasim, Bilal]

 Adding support for MAC filtering in the FEC IP
 implementation. This addition ensures that the IP does NOT boot up in
 promiscuous mode by default, and so the software only receives the desired
 packets(Unicast, Broadcast, Unicast / Multicast hashed) by default. The
 software running on-top of QEMU can also modify these settings and disable
 reception of broadcast frames or make the IP receive all packets (PROM mode).
 This patch greatly reduces the number of packets received by the software
 running on-top of the QEMU model. Tested with the armv7-a SABRE_LITE machine.
 Testing included running a custom OS with IPv4 / IPv6 support. Hashing and
 filtering of packets is tested to work well. Skeleton taken from the
 CADENCE_GEM IP and hash generation algorithm from the Linux Kernel.

Signed-off-by: Bilal Wasim 
---
 hw/net/imx_fec.c | 92 +++-
 include/hw/net/imx_fec.h | 12 +++
 2 files changed, 103 insertions(+), 1 deletion(-)

diff --git a/hw/net/imx_fec.c b/hw/net/imx_fec.c
index bd99236..96c52dd 100644
--- a/hw/net/imx_fec.c
+++ b/hw/net/imx_fec.c
@@ -419,6 +419,80 @@ static void imx_enet_write_bd(IMXENETBufDesc *bd, 
dma_addr_t addr)
 dma_memory_write(&address_space_memory, addr, bd, sizeof(*bd));
 }

+/*
+ * Calculate a FEC MAC Address hash index
+ */
+static unsigned calc_mac_hash(const uint8_t *mac, uint8_t mac_length)
+{
+uint32_t crc = -1;
+int i;
+
+while (mac_length --) {
+crc ^= *mac++;
+for (i = 0; i < 8; i++) {
+crc = (crc >> 1) ^ ((crc & 1) ? CRCPOLY_LE : 0);
+}
+}
+
+/* only upper 6 bits (FEC_HASH_BITS) are used
+ * which point to specific bit in the hash registers
+ */
+return ((crc >> (32 - FEC_HASH_BITS)) & 0x3f);
+}
+
+/*
+ * fec_mac_address_filter:
+ * Accept or reject this destination address?
+ */
+static int fec_mac_address_filter(IMXFECState *s, const uint8_t *packet)
+{
+const uint8_t broadcast_addr[] = { 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF };
+uint32_t addr1, addr2;
+uint8_t  hash;
+
+/* Promiscuous mode? */
+if (s->regs[ENET_RCR] & ENET_RCR_PROM) {
+return (FEC_RX_PROMISCUOUS_ACCEPT); /* Accept all packets in 
promiscuous mode (even if bc_rej is set). */
+}
+
+/* Broadcast packet? */
+if (!memcmp(packet, broadcast_addr, 6)) {
+/* Reject broadcast packets? */
+if (s->regs[ENET_RCR] & ENET_RCR_BC_REJ) {
+return (FEC_RX_REJECT);
+}
+return (FEC_RX_BROADCAST_ACCEPT); /* Accept packets from broadcast 
address. */
+}
+
+/* Accept packets -w- hash match? */
+hash = calc_mac_hash(packet, 6);
+
+/* Accept packets -w- multicast hash match? */
+if ((packet[0] & 0x01) == 0x01) {
+/* See if the computed hash matches a set bit in either GAUR / GALR 
register. */
+if (((hash < 32) && (s->regs[ENET_GALR] & (1 << hash)))
+|| ((hash > 31) && (s->regs[ENET_GAUR] & (1 << (hash-32) {
+return (FEC_RX_MULTICAST_HASH_ACCEPT); /* Accept multicast hash 
enabled address. */
+}
+} else {
+/* See if the computed hash matches a set bit in either IAUR / IALR 
register. */
+if (((hash < 32) && (s->regs[ENET_IALR] & (1 << hash)))
+|| ((hash > 31) && (s->regs[ENET_IAUR] & (1 << (hash-32) {
+return (FEC_RX_UNICAST_HASH_ACCEPT); /* Accept multicast hash 
enabled address. */
+}
+}
+
+/* Match Unicast address. */
+addr1  = g_htonl(s->regs[ENET_PALR]);
+addr2  = g_htonl(s->regs[ENET_PAUR]);
+if (!(memcmp(packet, (uint8_t *) &addr1, 4) || memcmp(packet+4, (uint8_t 
*) &addr2, 2))) {
+return (FEC_RX_UNICAST_ACCEPT); /* Accept packet because it matches my 
unicast address. */
+}
+
+/* Return -1 because we do NOT support MAC address filtering.. */
+return (FEC_RX_REJECT);
+}
+
 static void imx_eth_update(IMXFECState *s)
 {
 /*
@@ -984,7 +1058,7 @@ static void imx_eth_write(void *opaque, hwaddr offset, 
uint64_t value,
 case ENET_IALR:
 case ENET_GAUR:
 case ENET_GALR:
-/* TODO: implement MAC hash filtering.  */
+s->regs[index] |= value;
 break;
 case ENET_TFWR:
 if (s->is_fec) {
@@ -1066,8 +1140,16 @@ static ssize_t imx_fec_receive(NetClientState *nc, const 
uint8_t *buf,
 uint32_t buf_addr;
 uint8_t *crc_ptr;
 unsigned int buf_len;
+int maf;
 size_t size = len;

+/* Is this destination MAC address "for us" ? */
+maf = fec_mac_address_filter(s, buf);
+if (maf == FEC_RX_REJECT)
+{
+return (FEC_RX_REJECT);
+}
+
 FEC_PRINTF("len %d\n", (int)size);

 if (!s->regs[ENET_RDAR]) {
@@ -1133,6 +1215,14 @@ static ssize_t imx_fec_receive(NetClientState *nc, const 
uint8_t *buf,
 } else {
 s->regs[ENET_EIR] |= ENET_INT_RXB;
 }
+
+/* Update descriptor based on the "maf" flag. */
+if (maf == FEC_RX_BROADCAST_

Re: [PATCH v1 1/1] pc-bios/s390-ccw: fix sclp_get_loadparm_ascii

[Christian Borntraeger]

On 28.11.19 13:45, Cornelia Huck wrote:
> On Thu, 28 Nov 2019 13:35:29 +0100
> Christian Borntraeger  wrote:
> 
>> Ack.
>>
>> Conny, I think this would be really nice to have for 4.2 (together with a 
>> bios rebuild)
>> as this fixes a regression. Opinions?
> 
> I fear that this is a bit late for 4.2... but this should get a
> cc:stable.

So we would rather ship a qemu regression instead of pushing a 1 line fixup?
Peter, what is the current state of 4.2? does it look like we will have an rc4
or is everything else silent.

> 
>>
>>
>>
>> On 28.11.19 13:33, Claudio Imbrenda wrote:
>>> The existing s390 bios gets the LOADPARM information from the system using
>>> an SCLP call that specifies a buffer length too small to contain all the
>>> output.
>>>
>>> The recent fixes in the SCLP code have exposed this bug, since now the
>>> SCLP call will return an error (as per architecture) instead of
>>> writing partially and completing successfully.
>>>
>>> The solution is simply to specify the full page length as the SCCB
>>> length instead of a smaller size.
>>>
>>> Fixes: 832be0d8a3bb ("s390x: sclp: Report insufficient SCCB length")
>>> Fixes: 9a22473c70f3 ("pc-bios/s390-ccw: get LOADPARM stored in SCP Read 
>>> Info")
>>>
>>> Signed-off-by: Claudio Imbrenda 
>>> ---
>>>  pc-bios/s390-ccw/sclp.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/pc-bios/s390-ccw/sclp.c b/pc-bios/s390-ccw/sclp.c
>>> index c0223fa..7251f9a 100644
>>> --- a/pc-bios/s390-ccw/sclp.c
>>> +++ b/pc-bios/s390-ccw/sclp.c
>>> @@ -112,7 +112,7 @@ void sclp_get_loadparm_ascii(char *loadparm)
>>>  ReadInfo *sccb = (void *)_sccb;
>>>  
>>>  memset((char *)_sccb, 0, sizeof(ReadInfo));
>>> -sccb->h.length = sizeof(ReadInfo);
>>> +sccb->h.length = SCCB_SIZE;
>>>  if (!sclp_service_call(SCLP_CMDW_READ_SCP_INFO, sccb)) {
>>>  ebcdic_to_ascii((char *) sccb->loadparm, loadparm, LOADPARM_LEN);
>>>  }
>>>   
> 
> The change seems sane.
> 

Re: [PATCH v1 1/1] pc-bios/s390-ccw: fix sclp_get_loadparm_ascii

[Cornelia Huck]

On Thu, 28 Nov 2019 13:35:29 +0100
Christian Borntraeger  wrote:

> Ack.
> 
> Conny, I think this would be really nice to have for 4.2 (together with a 
> bios rebuild)
> as this fixes a regression. Opinions?

I fear that this is a bit late for 4.2... but this should get a
cc:stable.

> 
> 
> 
> On 28.11.19 13:33, Claudio Imbrenda wrote:
> > The existing s390 bios gets the LOADPARM information from the system using
> > an SCLP call that specifies a buffer length too small to contain all the
> > output.
> > 
> > The recent fixes in the SCLP code have exposed this bug, since now the
> > SCLP call will return an error (as per architecture) instead of
> > writing partially and completing successfully.
> > 
> > The solution is simply to specify the full page length as the SCCB
> > length instead of a smaller size.
> > 
> > Fixes: 832be0d8a3bb ("s390x: sclp: Report insufficient SCCB length")
> > Fixes: 9a22473c70f3 ("pc-bios/s390-ccw: get LOADPARM stored in SCP Read 
> > Info")
> > 
> > Signed-off-by: Claudio Imbrenda 
> > ---
> >  pc-bios/s390-ccw/sclp.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/pc-bios/s390-ccw/sclp.c b/pc-bios/s390-ccw/sclp.c
> > index c0223fa..7251f9a 100644
> > --- a/pc-bios/s390-ccw/sclp.c
> > +++ b/pc-bios/s390-ccw/sclp.c
> > @@ -112,7 +112,7 @@ void sclp_get_loadparm_ascii(char *loadparm)
> >  ReadInfo *sccb = (void *)_sccb;
> >  
> >  memset((char *)_sccb, 0, sizeof(ReadInfo));
> > -sccb->h.length = sizeof(ReadInfo);
> > +sccb->h.length = SCCB_SIZE;
> >  if (!sclp_service_call(SCLP_CMDW_READ_SCP_INFO, sccb)) {
> >  ebcdic_to_ascii((char *) sccb->loadparm, loadparm, LOADPARM_LEN);
> >  }
> >   

The change seems sane.

Re: [PATCH RFC] qga: fence guest-set-time if hwclock not available

[Cornelia Huck]

On Thu, 28 Nov 2019 12:45:32 +
Daniel P. Berrangé  wrote:

> On Thu, Nov 28, 2019 at 01:36:58PM +0100, Cornelia Huck wrote:
> > The Posix implementation of guest-set-time invokes hwclock to
> > set/retrieve the time to/from the hardware clock. If hwclock
> > is not available, the user is currently informed that "hwclock
> > failed to set hardware clock to system time", which is quite
> > misleading. This may happen e.g. on s390x, which has a different
> > timekeeping concept anyway.
> > 
> > Let's check for the availability of the hwclock command and
> > return QERR_UNSUPPORTED for guest-set-time if it is not available.
> > 
> > Signed-off-by: Cornelia Huck 
> > ---
> > 
> > Not sure if that is the correct approach, but the current error
> > message is really quite confusing.  
> 
> I guess the alternative is to just #ifndef __s390x__ the whole
> impl of the qmp_guest_set_time  method, but I don't have a
> strong opinion on which is best.

This hardcodes this as a s390x specialty, though, and I'm not sure that
assumption is and will stay correct.

> 
> > 
> > Gave it a quick test with an s390x and an x86_64 guest; invoking
> > 'virsh domtime ' now fails with 'not currently supported'
> > on s390x and continues to work as before on x86_64.
> > 
> > ---
> >  qga/commands-posix.c | 20 +++-
> >  1 file changed, 19 insertions(+), 1 deletion(-)
> > 
> > diff --git a/qga/commands-posix.c b/qga/commands-posix.c
> > index 1c1a165daed8..bd298a38b716 100644
> > --- a/qga/commands-posix.c
> > +++ b/qga/commands-posix.c
> > @@ -149,6 +149,13 @@ int64_t qmp_guest_get_time(Error **errp)
> > return tq.tv_sec * 10LL + tq.tv_usec * 1000;
> >  }
> >  
> > +static int check_hwclock_available(const char *path)
> > +{
> > +struct stat st;
> > +
> > +return (stat(path, &st) < 0) ? 0 : 1;
> > +}
> > +
> >  void qmp_guest_set_time(bool has_time, int64_t time_ns, Error **errp)
> >  {
> >  int ret;
> > @@ -156,6 +163,17 @@ void qmp_guest_set_time(bool has_time, int64_t 
> > time_ns, Error **errp)
> >  pid_t pid;
> >  Error *local_err = NULL;
> >  struct timeval tv;
> > +const char *hwclock_path = "/sbin/hwclock";
> > +static int hwclock_available = -1;
> > +
> > +if (hwclock_available < 0) {
> > +hwclock_available = check_hwclock_available(hwclock_path);  
> 
> Could do this inline with:
> 
> hwclock_available = (access(hwclock_available, X_OK) == 0);
> 
> getting a slightly better result as this check for it being
> executable as well as existing.

Yes, that looks better. Can do if we agree on this approach.

> 
> > +}
> > +
> > +if (!hwclock_available) {
> > +error_setg(errp, QERR_UNSUPPORTED);
> > +return;
> > +}
> >  
> >  /* If user has passed a time, validate and set it. */
> >  if (has_time) {
> > @@ -195,7 +213,7 @@ void qmp_guest_set_time(bool has_time, int64_t time_ns, 
> > Error **errp)
> >  
> >  /* Use '/sbin/hwclock -w' to set RTC from the system time,
> >   * or '/sbin/hwclock -s' to set the system time from RTC. */
> > -execle("/sbin/hwclock", "hwclock", has_time ? "-w" : "-s",
> > +execle(hwclock_path, "hwclock", has_time ? "-w" : "-s",
> > NULL, environ);
> >  _exit(EXIT_FAILURE);
> >  } else if (pid < 0) {
> > -- 
> > 2.21.0
> > 
> >   
> 
> Regards,
> Daniel

Re: [PATCH v1 1/1] s390x: protvirt: SCLP interpretation

[Pierre Morel]

On 2019-11-28 13:10, Thomas Huth wrote:

On 28/11/2019 11.13, Pierre Morel wrote:

The SCLP protection handle some of the exceptions due to
mis-constructions of the SCLP Control Block (SCCB) by the guest and
provides notifications to the host when something gets wrong.
We currently do not handle these exceptions, letting all the work to the
firmware therefor, we only need to inject an external interrupt to the
guest.

When the SCCB is correct, the S390x virtualisation protection copies
the SCLP Control Block (SCCB) from the guest inside the kernel to avoid
opening a direct access to the guest memory.
When accessing the kernel memory with standard s390_cpu_virt_mem_*
functions the host opens access to the SCCB shadow at address 0.

Signed-off-by: Pierre Morel 
---
  hw/s390x/sclp.c | 18 +
  include/hw/s390x/sclp.h |  2 ++
  target/s390x/kvm.c  | 56 -
  3 files changed, 75 insertions(+), 1 deletion(-)

diff --git a/hw/s390x/sclp.c b/hw/s390x/sclp.c
index f57ce7b739..02e4e0146f 100644
--- a/hw/s390x/sclp.c
+++ b/hw/s390x/sclp.c
@@ -193,6 +193,24 @@ 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);
+
+    /* Protected guest SCCB is always seen at address 0 */


Well, as far as I've understood it, the address is rather ignored (and 
you can only specify an offset into the 4k page)?



You can see it like this, then the offset is 0. However we give here an 
address as argument.






+ 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, (uint64_t)&work_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 0c9d14b4b1..559f470f51 100644
--- a/target/s390x/kvm.c
+++ b/target/s390x/kvm.c
@@ -1170,7 +1170,14 @@ 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);
+    switch (run->s390_sieic.icptcode) {
+    case ICPT_PV_INSTR:
+    r = sclp_service_call_protected(env, sccb, code);
+    break;
+    default:
+    r = sclp_service_call(env, sccb, code);
+    break;
+    }


Why not simply

    if (run->s390_sieic.icptcode == ICPT_PV_INSTR) {
    r = sclp_service_call_protected(env, sccb, code);
    } else {
    r = sclp_service_call(env, sccb, code);
    }

... that's way short and easier to read. Or do you expect other 
icptcodes in the near future?



No you are right, it is better, I just like switches :)





  if (r < 0) {
  kvm_s390_program_interrupt(cpu, -r);
  } else {
@@ -1575,6 +1582,47 @@ static int kvm_s390_handle_sigp(S390CPU *cpu, 
uint8_t ipa1, uint32_t ipb)

  return 0;
  }
  +static int handle_secure_notification(S390CPU *cpu, struct kvm_run 
*run)

+{
+    unsigned int ipa0 = (run->s390_sieic.ipa & 0xff00);
+    uint8_t ipa1 = run->s390_sieic.ipa & 0x00ff;
+
+    switch (ipa0) {
+    case IPA0_SIGP: /* We get the notification that the guest stop */
+    kvm_s390_handle_sigp(cpu, ipa1, run->s390_sieic.ipb);
+    break;
+    case IPA0_B2: /* We accept but do nothing for B2 notifications */
+    break;
+    default: /* We do not expect other instruction's notification */
+    kvm_s390_program_interrupt(cpu, PGM_OPERATION);


Maybe add a tracepoint or qemu_log_mask(LOG_UNIMP, ...) or CPU_LOG_INT 
here, so we can spot this condition more easily?



+    break;
+    }
+    return 0;
+}
+
+static int handle_secure_instruction(S390CPU *cpu, struct kvm_run *run)
+{
+    unsigned int ipa0 = (run->s390_sieic.ipa & 0xff00);
+    uint8_t ipa1 = run->s390_sieic.ipa & 0x00ff;
+    int r = -1;
+
+    switch (ipa0) {
+    case IPA0_B2:
+    r = handle_b2(cpu, run, ipa1);
+    break;
+    case IPA0_DIAG:
+    r = handle_diag(cpu, run, run->s390_sieic.ipb);
+    break

Re: [PATCH v5] qga: add command guest-get-devices for reporting VirtIO devices

[Marc-André Lureau]

Hi

On Thu, Nov 28, 2019 at 4:49 PM Tomáš Golembiovský  wrote:
>
> Add command for reporting devices on Windows guest. The intent is not so
> much to report the devices but more importantly the driver (and its
> version) that is assigned to the device. This gives caller the
> information whether VirtIO drivers are installed and/or whether
> inadequate driver is used on a device (e.g. QXL device with base VGA
> driver).
>
> Signed-off-by: Tomáš Golembiovský 
> ---
>
> changes in v5:
> - updated version in schema
>

But that will be 5.0 (aka 2020, ..)

Reviewed-by: Marc-André Lureau 

> changes in v4:
> - making check-patch happy
>
>  qga/commands-posix.c |   9 ++
>  qga/commands-win32.c | 204 ++-
>  qga/qapi-schema.json |  32 +++
>  3 files changed, 244 insertions(+), 1 deletion(-)
>
> diff --git a/qga/commands-posix.c b/qga/commands-posix.c
> index 1c1a165dae..efcd9174a8 100644
> --- a/qga/commands-posix.c
> +++ b/qga/commands-posix.c
> @@ -2758,6 +2758,8 @@ GList *ga_command_blacklist_init(GList *blacklist)
>  blacklist = g_list_append(blacklist, g_strdup("guest-fstrim"));
>  #endif
>
> +blacklist = g_list_append(blacklist, g_strdup("guest-get-devices"));
> +
>  return blacklist;
>  }
>
> @@ -2978,3 +2980,10 @@ GuestOSInfo *qmp_guest_get_osinfo(Error **errp)
>
>  return info;
>  }
> +
> +GuestDeviceInfoList *qmp_guest_get_devices(Error **errp)
> +{
> +error_setg(errp, QERR_UNSUPPORTED);
> +
> +return NULL;
> +}
> diff --git a/qga/commands-win32.c b/qga/commands-win32.c
> index 55ba5b263a..cd942b3fb3 100644
> --- a/qga/commands-win32.c
> +++ b/qga/commands-win32.c
> @@ -21,10 +21,11 @@
>  #ifdef CONFIG_QGA_NTDDSCSI
>  #include 
>  #include 
> +#endif
>  #include 
>  #include 
>  #include 
> -#endif
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -38,6 +39,36 @@
>  #include "qemu/host-utils.h"
>  #include "qemu/base64.h"
>
> +/*
> + * The following should be in devpkey.h, but it isn't. The key names were
> + * prefixed to avoid (future) name clashes. Once the definitions get into
> + * mingw the following lines can be removed.
> + */
> +DEFINE_DEVPROPKEY(qga_DEVPKEY_NAME, 0xb725f130, 0x47ef, 0x101a, 0xa5,
> +0xf1, 0x02, 0x60, 0x8c, 0x9e, 0xeb, 0xac, 10);
> +/* DEVPROP_TYPE_STRING */
> +DEFINE_DEVPROPKEY(qga_DEVPKEY_Device_HardwareIds, 0xa45c254e, 0xdf1c,
> +0x4efd, 0x80, 0x20, 0x67, 0xd1, 0x46, 0xa8, 0x50, 0xe0, 3);
> +/* DEVPROP_TYPE_STRING_LIST */
> +DEFINE_DEVPROPKEY(qga_DEVPKEY_Device_DriverDate, 0xa8b865dd, 0x2e3d,
> +0x4094, 0xad, 0x97, 0xe5, 0x93, 0xa7, 0xc, 0x75, 0xd6, 2);
> +/* DEVPROP_TYPE_FILETIME */
> +DEFINE_DEVPROPKEY(qga_DEVPKEY_Device_DriverVersion, 0xa8b865dd, 0x2e3d,
> +0x4094, 0xad, 0x97, 0xe5, 0x93, 0xa7, 0xc, 0x75, 0xd6, 3);
> +/* DEVPROP_TYPE_STRING */
> +/* The following shoud be in cfgmgr32.h, but it isn't */
> +#ifndef CM_Get_DevNode_Property
> +CMAPI CONFIGRET WINAPI CM_Get_DevNode_PropertyW(
> +DEVINST  dnDevInst,
> +CONST DEVPROPKEY * PropertyKey,
> +DEVPROPTYPE  * PropertyType,
> +PBYTEPropertyBuffer,
> +PULONG   PropertyBufferSize,
> +ULONGulFlags
> +);
> +#define CM_Get_DevNode_Property CM_Get_DevNode_PropertyW
> +#endif
> +
>  #ifndef SHTDN_REASON_FLAG_PLANNED
>  #define SHTDN_REASON_FLAG_PLANNED 0x8000
>  #endif
> @@ -92,6 +123,8 @@ static OpenFlags guest_file_open_modes[] = {
>  g_free(suffix); \
>  } while (0)
>
> +G_DEFINE_AUTOPTR_CLEANUP_FUNC(GuestDeviceInfo, qapi_free_GuestDeviceInfo)
> +
>  static OpenFlags *find_open_flag(const char *mode_str)
>  {
>  int mode;
> @@ -2234,3 +2267,172 @@ GuestOSInfo *qmp_guest_get_osinfo(Error **errp)
>
>  return info;
>  }
> +
> +/*
> + * Safely get device property. Returned strings are using wide characters.
> + * Caller is responsible for freeing the buffer.
> + */
> +static LPBYTE cm_get_property(DEVINST devInst, const DEVPROPKEY *propName,
> +PDEVPROPTYPE propType)
> +{
> +CONFIGRET cr;
> +g_autofree LPBYTE buffer = NULL;
> +ULONG buffer_len = 0;
> +
> +/* First query for needed space */
> +cr = CM_Get_DevNode_PropertyW(devInst, propName, propType,
> +buffer, &buffer_len, 0);
> +if (cr != CR_SUCCESS && cr != CR_BUFFER_SMALL) {
> +
> +slog("failed to get property size, error=0x%lx", cr);
> +return NULL;
> +}
> +buffer = g_new0(BYTE, buffer_len + 1);
> +cr = CM_Get_DevNode_PropertyW(devInst, propName, propType,
> +buffer, &buffer_len, 0);
> +if (cr != CR_SUCCESS) {
> +slog("failed to get device property, error=0x%lx", cr);
> +return NULL;
> +}
> +return g_steal_pointer(&buffer);
> +}
> +
> +static GStrv ga_get_hardware_ids(DEVINST devInstance)
> +{
> +GStrv hw_ids = NULL;
> +GArray *values = NULL;
> +DEVPROPTYPE cm_type;
> +LPWSTR id;
> +g_autofree LPWSTR property = (LPWSTR)cm_get_property(devInstance,
> +&qga_DEVPKEY

Re: [PATCH v5] qga: add command guest-get-devices for reporting VirtIO devices

[Daniel P . Berrangé]

On Thu, Nov 28, 2019 at 01:45:13PM +0100, Tomáš Golembiovský wrote:
> Add command for reporting devices on Windows guest. The intent is not so
> much to report the devices but more importantly the driver (and its
> version) that is assigned to the device. This gives caller the
> information whether VirtIO drivers are installed and/or whether
> inadequate driver is used on a device (e.g. QXL device with base VGA
> driver).
> 
> Signed-off-by: Tomáš Golembiovský 
> ---
> 
> changes in v5:
> - updated version in schema
> 
> changes in v4:
> - making check-patch happy
> 
>  qga/commands-posix.c |   9 ++
>  qga/commands-win32.c | 204 ++-
>  qga/qapi-schema.json |  32 +++
>  3 files changed, 244 insertions(+), 1 deletion(-)

> +##
> +# @GuestDeviceInfo:
> +#
> +# @vendor-id: vendor ID
> +# @device-id: device ID

Presumably these are PCI device IDs ?  If so, this schema is not
portable to all architectures, because they don't all use PCI
and on s390x PCI there's some extra device IDs.

> +# @driver-name: name of the associated driver
> +# @driver-date: driver release date in format -MM-DD
> +# @driver-version: driver version
> +#
> +# Since: 4.3
> +##
> +{ 'struct': 'GuestDeviceInfo',
> +  'data': {
> +  'vendor-id': 'uint16',
> +  'device-id': 'uint16',
> +  'driver-name': 'str',
> +  'driver-date': 'str',

Should be optional as not all OS will have dates for
individual drivers

> +  'driver-version': 'str'

Should be optional again.

> +  } }

I think this ought to be a structured differently
though. GuestDeviceInfo should just contain the
driver name, date + version, then it should point
to an GuestDeviceAddress which is a union, initially
only holding a "GuestDevicePCI" struct, but which we
can extend to other types of device address later.

> +
> +##
> +# @guest-get-devices:
> +#
> +# Retrieve information about device drivers in Windows guest
> +#
> +# Returns: @GuestDeviceInfo
> +#
> +# Since: 4.3

The next version is 5.0

> +##
> +{ 'command': 'guest-get-devices',
> +  'returns': ['GuestDeviceInfo'] }
> -- 
> 2.24.0
> 
> 

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

Re: [PATCH v1 1/1] pc-bios/s390-ccw: fix sclp_get_loadparm_ascii

[Thomas Huth]

On 28/11/2019 13.35, Christian Borntraeger wrote:

Ack.

Conny, I think this would be really nice to have for 4.2 (together with a bios 
rebuild)
as this fixes a regression. Opinions?


If we do another rc of 4.2, I think we definitely want this to be 
included, otherwise quite a bunch of things don't work anymore as 
expected, e.g. "-boot menu=on"...



diff --git a/pc-bios/s390-ccw/sclp.c b/pc-bios/s390-ccw/sclp.c
index c0223fa..7251f9a 100644
--- a/pc-bios/s390-ccw/sclp.c
+++ b/pc-bios/s390-ccw/sclp.c
@@ -112,7 +112,7 @@ void sclp_get_loadparm_ascii(char *loadparm)
  ReadInfo *sccb = (void *)_sccb;
  
  memset((char *)_sccb, 0, sizeof(ReadInfo));

-sccb->h.length = sizeof(ReadInfo);
+sccb->h.length = SCCB_SIZE;
  if (!sclp_service_call(SCLP_CMDW_READ_SCP_INFO, sccb)) {
  ebcdic_to_ascii((char *) sccb->loadparm, loadparm, LOADPARM_LEN);
  }


I gave it a quick try, and this fixes "-boot menu=on" for me, so:

Tested-by: Thomas Huth 

Re: [PATCH v1 1/1] pc-bios/s390-ccw: fix sclp_get_loadparm_ascii

[Cornelia Huck]

On Thu, 28 Nov 2019 14:11:38 +0100
Thomas Huth  wrote:

> On 28/11/2019 13.35, Christian Borntraeger wrote:
> > Ack.
> > 
> > Conny, I think this would be really nice to have for 4.2 (together with a 
> > bios rebuild)
> > as this fixes a regression. Opinions?  
> 
> If we do another rc of 4.2, I think we definitely want this to be 
> included, otherwise quite a bunch of things don't work anymore as 
> expected, e.g. "-boot menu=on"...

I do agree we want this if possible; the question is really the
"possible" part...

> 
> >> diff --git a/pc-bios/s390-ccw/sclp.c b/pc-bios/s390-ccw/sclp.c
> >> index c0223fa..7251f9a 100644
> >> --- a/pc-bios/s390-ccw/sclp.c
> >> +++ b/pc-bios/s390-ccw/sclp.c
> >> @@ -112,7 +112,7 @@ void sclp_get_loadparm_ascii(char *loadparm)
> >>   ReadInfo *sccb = (void *)_sccb;
> >>   
> >>   memset((char *)_sccb, 0, sizeof(ReadInfo));
> >> -sccb->h.length = sizeof(ReadInfo);
> >> +sccb->h.length = SCCB_SIZE;
> >>   if (!sclp_service_call(SCLP_CMDW_READ_SCP_INFO, sccb)) {
> >>   ebcdic_to_ascii((char *) sccb->loadparm, loadparm, LOADPARM_LEN);
> >>   }  
> 
> I gave it a quick try, and this fixes "-boot menu=on" for me, so:
> 
> Tested-by: Thomas Huth 

Thanks.

FWIW, I'm currently working to put this + the rebuild on my s390-fixes
branch.

Re: [PATCH v1 0/1] s390x: protvirt: SCLP interpretation

[Pierre Morel]

On 2019-11-28 13:28, Janosch Frank wrote:

On 11/28/19 11:13 AM, Pierre Morel wrote:

A new proposition:
I think it would be wise to fork directly from handle_instruction
instead to accept per default all instructions with with secure
instruction interception code.
Just in case future firmware with older QEMU.

How ever I let three dors open.

1) This patch accepts the all B2 instructions, mostly I/O.
Some of the instructions will not work correctly for PV until patched.
This should be fixed, and will be, in a separate patch.

2) The same is true for DIAG instructions.

3) Secure notifications are separated from secure instructions and
normal instructions interception because this case is completely new.
For B2 instructions we do not have to do anything this just informative.
However, one information is of interrest, a notification that
SIGP(STOP) is sent to stop the CPUs and terminate QEMU.

Pierre, I told you this morning that I don't want this and that you
should leave this untouched until I can explain my thoughts behind the
initial patch in a f2f.
Thomas' review of your change only confirmed my concerns about this patch.

This is the wrong patch at the wrong time, which creates noise and work
for other people. Please stop and work on something else.


!?

- you sent to me info on slack that I did not see until now, next time 
be sure I have acknowledged if it is important.


- You told me to dive into this patch quite abruptly, and it invested 
time to understand how the I/O works with PV, so sorry for the wrong time


- I see no problem with the questions from Thomas, may be you can 
explain this to me


- I have a lot of other things to do so I just close this thread after 
having answered to Thomas.










Pierre Morel (1):
   s390x: protvirt: SCLP interpretation

  hw/s390x/sclp.c | 18 +
  include/hw/s390x/sclp.h |  2 ++
  target/s390x/kvm.c  | 56 -
  3 files changed, 75 insertions(+), 1 deletion(-)




--
Pierre Morel
IBM Lab Boeblingen

Re: [PATCH] travis.yml: Run tcg tests with tci

[Thomas Huth]

On 28/11/2019 11.16, Alex Bennée wrote:


Thomas Huth  writes:


On 27/11/2019 19.38, Alex Bennée wrote:

Thomas Huth  writes:


So far we only have compile coverage for tci. But since commit
2f160e0f9797c7522bfd0d09218d0c9340a5137c ("tci: Add implementation
for INDEX_op_ld16u_i64") has been included, we can also run the
x86 TCG tests with tci, so let's enable them in Travis now.

Signed-off-by: Thomas Huth 
---
   .travis.yml | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.travis.yml b/.travis.yml
index c09b6a0014..b0b634d484 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -218,7 +218,7 @@ matrix:
   # We manually include builds which we disable "make check" for

this comment is out of date now (or rather has been for a while)


   - env:
   - CONFIG="--enable-debug --enable-tcg-interpreter"

Perhaps as linux-user doesn't add much to testing the TCG we could
limit
by MAIN_SOFTMMU_TARGETS here?


Limiting is a good idea, but I think we should use the architectures
that are supported by tests/boot-serial-test.c instead.


Maybe a new env - TESTBOOT_SOFTMMU_TARGETS?


I tried something like that - but with all possible targets that are 
supported by boot-serial-tests, I hit the 50 minutes timeout from 
Travis. Looks like I've got to skip some, TCI is really slow. So I'll 
rather specify the target subset in the matrix entry directly.


 Thomas

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Michael Rolnik]

I don't see why you say that the peripherals are inside the chip, there is
CPU within target/avr directory and then there are some peripherals in hw
directory, CPU does not depend on them. what am I missing?

On Thu, Nov 28, 2019 at 3:22 PM Aleksandar Markovic <
aleksandar.m.m...@gmail.com> wrote:

>
>
> On Thursday, November 28, 2019, Michael Rolnik  wrote:
>
>>
>>
>> On Wed, Nov 27, 2019 at 11:06 PM Aleksandar Markovic <
>> aleksandar.m.m...@gmail.com> wrote:
>>
>>> On Wed, Nov 27, 2019 at 6:53 PM Michael Rolnik 
>>> wrote:
>>> >
>>> > This series of patches adds 8bit AVR cores to QEMU.
>>> > All instruction, except BREAK/DES/SPM/SPMX, are implemented. Not fully
>>> tested yet.
>>> > However I was able to execute simple code with functions. e.g
>>> fibonacci calculation.
>>> > This series of patches include a non real, sample board.
>>> > No fuses support yet. PC is set to 0 at reset.
>>> >
>>>
>>> I have a couple of general remarks, so I am responding to the cover
>>> letter, not individual patches.
>>>
>>> 1) The licenses for Sarah devices differ than the rest - shouldn't all
>>> licenses be harmonized?
>>
>> Sarah,
>> do you mind if use the same license I use for my code?
>>
>>
>>>
>>
>>
>>> 2) There is an architectural problem with peripherals. It is possible
>>> that they evolve over time, so, for example, USART could not be the
>>> same for older and newer CPUs (in principle, newer peripheral is
>>> expected to be o sort of "superset" of the older). How do you solve
>>> that problem? Right now, it may not looks serious to you, but if you
>>> don;t think about that right now, from the outset, soon the code will
>>> become so entangled, ti woudl be almost very difficult to fix it.
>>> Please think about that, how would you solve it, is there a way to
>>> pass the information on the currently emulated CPU to the code
>>> covering a peripheral, and provide a different behaviour?
>>>
>> Hi Aleksandar,
>>
>> Please explain.
>>
>>
> My concern is about peripherals inside the chip, together with the core.
>
> If one models, let's say an external (in the sense, it is a separate chip)
> ADC (analog-to-digital converter), one looks at specs, implement what is
> resonable possible in QEMU, plug it in in one of machines thst contains it,
> and that's it. That ADC remains the same, of course, whatever the
> surrounding system is.
>
> In AVR case, I think we have a phenomenon likes of which we didn't see
> before (at least I don't know about). Number of AVR microcontrollers is
> very large, and both cores and peripherals evolved.
>
> For cores, you handle differences with all these AVR_FEATURE macros, and
> this seems to be working, no significant objection from my side, and btw
> that was not an easy task to execute, all admiration from me.
>
> But what about peripherals inside the chip? A peripheral with the same
> name and the same general area of functionality may be differently
> specified for microcontrollers from 2010 and 2018. By the difference I
> don't mean starting address, but the difference in behavior. I don't have
> time right now to spell many examples, but I read three different specs,
> and there are differences in USART specifications.
>
> I am not clear what is your envisioned solution for these cases. Would you
> such close, but not the same, flabors of a peripheral treat as if they are
> two completely separate cases of a peripheral? Or would you have a single
> peripheral that would somehow configure itself depending on the core it is
> attached to?
>
> I hope I was clearer this time.
>
> Aleksandar
>
>
>
>>
>>
>>
>> I don't see any problem from CPU's perspective.
>> as for the sample board is just a sample, I hope other people will create
>> real models or real hw.
>> there was no way I could provide a CPU alone, that's why there is sample.
>>
>>
>>
>>>
>>> > Following are examples of possible usages, assuming program.elf is
>>> compiled for AVR cpu
>>> > 1.  Continious non interrupted execution
>>> > run `qemu-system-avr -kernel program.elf`
>>> > 2.  Continious non interrupted execution with serial output into
>>> telnet window
>>> > run `qemu-system-avr -kernel program.elf -serial
>>> tcp::5678,server,nowait -nographic `
>>> > run `telent localhost 5678`
>>> > 3.  Continious non interrupted execution with serial output into stdout
>>> > run `qemu-system-avr -kernel program.elf -serial stdio`
>>> > 4.  Debugging wit GDB debugger
>>> > run `qemu-system-avr -kernel program.elf -s -S`
>>> > run `avr-gdb program.elf` and then within GDB shell `target remote
>>> :1234`
>>> > 5.  Print out executed instructions
>>> > run `qemu-system-avr -kernel program.elf -d in_asm`
>>> >
>>>
>>> Thank you so much for these examples!
>>>
>>> Aleksandar
>>>
>>>
>>> >
>>> > the patches include the following
>>> > 1. just a basic 8bit AVR CPU, without instruction decoding or
>>> translation
>>> > 2. CPU features which allow define the following 8bit AVR cores
>>> >  avr1
>>> >   

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Philippe Mathieu-Daudé]

On 11/28/19 2:25 PM, Michael Rolnik wrote:
I don't see why you say that the peripherals are inside the chip, there 
is CPU within target/avr directory and then there are some 
peripherals in hw directory, CPU does not depend on them. what am I missing?


On Thu, Nov 28, 2019 at 3:22 PM Aleksandar Markovic 
mailto:aleksandar.m.m...@gmail.com>> wrote:




On Thursday, November 28, 2019, Michael Rolnik mailto:mrol...@gmail.com>> wrote:



On Wed, Nov 27, 2019 at 11:06 PM Aleksandar Markovic
mailto:aleksandar.m.m...@gmail.com>> wrote:

On Wed, Nov 27, 2019 at 6:53 PM Michael Rolnik
mailto:mrol...@gmail.com>> wrote:
 >
 > This series of patches adds 8bit AVR cores to QEMU.
 > All instruction, except BREAK/DES/SPM/SPMX, are
implemented. Not fully tested yet.
 > However I was able to execute simple code with functions.
e.g fibonacci calculation.
 > This series of patches include a non real, sample board.
 > No fuses support yet. PC is set to 0 at reset.
 >

I have a couple of general remarks, so I am responding to
the cover
letter, not individual patches.

1) The licenses for Sarah devices differ than the rest -
shouldn't all
licenses be harmonized?

Sarah,
do you mind if use the same license I use for my code?


2) There is an architectural problem with peripherals. It is
possible
that they evolve over time, so, for example, USART could not
be the
same for older and newer CPUs (in principle, newer peripheral is
expected to be o sort of "superset" of the older). How do
you solve
that problem? Right now, it may not looks serious to you,
but if you
don;t think about that right now, from the outset, soon the
code will
become so entangled, ti woudl be almost very difficult to
fix it.
Please think about that, how would you solve it, is there a
way to
pass the information on the currently emulated CPU to the code
covering a peripheral, and provide a different behaviour?

Hi Aleksandar,

Please explain.


My concern is about peripherals inside the chip, together with the core.

If one models, let's say an external (in the sense, it is a separate
chip) ADC (analog-to-digital converter), one looks at specs,
implement what is resonable possible in QEMU, plug it in in one of
machines thst contains it, and that's it. That ADC remains the same,
of course, whatever the surrounding system is.

In AVR case, I think we have a phenomenon likes of which we didn't
see before (at least I don't know about). Number of AVR
microcontrollers is very large, and both cores and peripherals evolved.

For cores, you handle differences with all these AVR_FEATURE macros,
and this seems to be working, no significant objection from my side,
and btw that was not an easy task to execute, all admiration from me.

But what about peripherals inside the chip? A peripheral with the
same name and the same general area of functionality may be
differently specified for microcontrollers from 2010 and 2018. By
the difference I don't mean starting address, but the difference in
behavior. I don't have time right now to spell many examples, but I
read three different specs, and there are differences in USART
specifications.

I am not clear what is your envisioned solution for these cases.
Would you such close, but not the same, flabors of a peripheral
treat as if they are two completely separate cases of a peripheral?
Or would you have a single peripheral that would somehow configure
itself depending on the core it is attached to?

I hope I was clearer this time.

Aleksandar




I don't see any problem from CPU's perspective.
as for the sample board is just a sample, I hope other people
will create real models or real hw.
there was no way I could provide a CPU alone, that's why there
is sample.


If I understand Aleksandar correctly, the naming is incorrect because 
too generic to AVR family, why Sarah only modeled the Atmel implementation.


Renaming devices such hw/char/avr_usart.c -> hw/char/atmel_usart.c 
(similarly with the macros) would be enough Aleksandar?

Re: [PATCH v1 1/1] pc-bios/s390-ccw: fix sclp_get_loadparm_ascii

[Cornelia Huck]

On Thu, 28 Nov 2019 13:33:57 +0100
Claudio Imbrenda  wrote:

> The existing s390 bios gets the LOADPARM information from the system using
> an SCLP call that specifies a buffer length too small to contain all the
> output.
> 
> The recent fixes in the SCLP code have exposed this bug, since now the
> SCLP call will return an error (as per architecture) instead of
> writing partially and completing successfully.
> 
> The solution is simply to specify the full page length as the SCCB
> length instead of a smaller size.
> 
> Fixes: 832be0d8a3bb ("s390x: sclp: Report insufficient SCCB length")
> Fixes: 9a22473c70f3 ("pc-bios/s390-ccw: get LOADPARM stored in SCP Read Info")
> 
> Signed-off-by: Claudio Imbrenda 
> ---
>  pc-bios/s390-ccw/sclp.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/pc-bios/s390-ccw/sclp.c b/pc-bios/s390-ccw/sclp.c
> index c0223fa..7251f9a 100644
> --- a/pc-bios/s390-ccw/sclp.c
> +++ b/pc-bios/s390-ccw/sclp.c
> @@ -112,7 +112,7 @@ void sclp_get_loadparm_ascii(char *loadparm)
>  ReadInfo *sccb = (void *)_sccb;
>  
>  memset((char *)_sccb, 0, sizeof(ReadInfo));
> -sccb->h.length = sizeof(ReadInfo);
> +sccb->h.length = SCCB_SIZE;
>  if (!sclp_service_call(SCLP_CMDW_READ_SCP_INFO, sccb)) {
>  ebcdic_to_ascii((char *) sccb->loadparm, loadparm, LOADPARM_LEN);
>  }

Acked-by: Cornelia Huck 

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Aleksandar Markovic]

On Thursday, November 28, 2019, Michael Rolnik  wrote:

> I don't see why you say that the peripherals are inside the chip, there is
> CPU within target/avr directory and then there are some peripherals in hw
> directory, CPU does not depend on them. what am I missing?
>
>>
>>
I meant these peripherals are physically inside the chip together with the
core.

And USART in a micricontroler from 2010 is different than USART from one
from 2018.


> On Thu, Nov 28, 2019 at 3:22 PM Aleksandar Markovic <
> aleksandar.m.m...@gmail.com> wrote:
>
>>
>>
>> On Thursday, November 28, 2019, Michael Rolnik  wrote:
>>
>>>
>>>
>>> On Wed, Nov 27, 2019 at 11:06 PM Aleksandar Markovic <
>>> aleksandar.m.m...@gmail.com> wrote:
>>>
 On Wed, Nov 27, 2019 at 6:53 PM Michael Rolnik 
 wrote:
 >
 > This series of patches adds 8bit AVR cores to QEMU.
 > All instruction, except BREAK/DES/SPM/SPMX, are implemented. Not
 fully tested yet.
 > However I was able to execute simple code with functions. e.g
 fibonacci calculation.
 > This series of patches include a non real, sample board.
 > No fuses support yet. PC is set to 0 at reset.
 >

 I have a couple of general remarks, so I am responding to the cover
 letter, not individual patches.

 1) The licenses for Sarah devices differ than the rest - shouldn't all
 licenses be harmonized?
>>>
>>> Sarah,
>>> do you mind if use the same license I use for my code?
>>>
>>>

>>>
>>>
 2) There is an architectural problem with peripherals. It is possible
 that they evolve over time, so, for example, USART could not be the
 same for older and newer CPUs (in principle, newer peripheral is
 expected to be o sort of "superset" of the older). How do you solve
 that problem? Right now, it may not looks serious to you, but if you
 don;t think about that right now, from the outset, soon the code will
 become so entangled, ti woudl be almost very difficult to fix it.
 Please think about that, how would you solve it, is there a way to
 pass the information on the currently emulated CPU to the code
 covering a peripheral, and provide a different behaviour?

>>> Hi Aleksandar,
>>>
>>> Please explain.
>>>
>>>
>> My concern is about peripherals inside the chip, together with the core.
>>
>> If one models, let's say an external (in the sense, it is a separate
>> chip) ADC (analog-to-digital converter), one looks at specs, implement what
>> is resonable possible in QEMU, plug it in in one of machines thst contains
>> it, and that's it. That ADC remains the same, of course, whatever the
>> surrounding system is.
>>
>> In AVR case, I think we have a phenomenon likes of which we didn't see
>> before (at least I don't know about). Number of AVR microcontrollers is
>> very large, and both cores and peripherals evolved.
>>
>> For cores, you handle differences with all these AVR_FEATURE macros, and
>> this seems to be working, no significant objection from my side, and btw
>> that was not an easy task to execute, all admiration from me.
>>
>> But what about peripherals inside the chip? A peripheral with the same
>> name and the same general area of functionality may be differently
>> specified for microcontrollers from 2010 and 2018. By the difference I
>> don't mean starting address, but the difference in behavior. I don't have
>> time right now to spell many examples, but I read three different specs,
>> and there are differences in USART specifications.
>>
>> I am not clear what is your envisioned solution for these cases. Would
>> you such close, but not the same, flabors of a peripheral treat as if they
>> are two completely separate cases of a peripheral? Or would you have a
>> single peripheral that would somehow configure itself depending on the core
>> it is attached to?
>>
>> I hope I was clearer this time.
>>
>> Aleksandar
>>
>>
>>
>>>
>>>
>>>
>>> I don't see any problem from CPU's perspective.
>>> as for the sample board is just a sample, I hope other people will
>>> create real models or real hw.
>>> there was no way I could provide a CPU alone, that's why there is sample.
>>>
>>>
>>>

 > Following are examples of possible usages, assuming program.elf is
 compiled for AVR cpu
 > 1.  Continious non interrupted execution
 > run `qemu-system-avr -kernel program.elf`
 > 2.  Continious non interrupted execution with serial output into
 telnet window
 > run `qemu-system-avr -kernel program.elf -serial
 tcp::5678,server,nowait -nographic `
 > run `telent localhost 5678`
 > 3.  Continious non interrupted execution with serial output into
 stdout
 > run `qemu-system-avr -kernel program.elf -serial stdio`
 > 4.  Debugging wit GDB debugger
 > run `qemu-system-avr -kernel program.elf -s -S`
 > run `avr-gdb program.elf` and then within GDB shell `target
 remote :1234`
 > 5.  Print out executed instructions
 >

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Aleksandar Markovic]

On Thursday, November 28, 2019, Michael Rolnik  wrote:

>
>
> On Wed, Nov 27, 2019 at 11:06 PM Aleksandar Markovic <
> aleksandar.m.m...@gmail.com> wrote:
>
>> On Wed, Nov 27, 2019 at 6:53 PM Michael Rolnik  wrote:
>> >
>> > This series of patches adds 8bit AVR cores to QEMU.
>> > All instruction, except BREAK/DES/SPM/SPMX, are implemented. Not fully
>> tested yet.
>> > However I was able to execute simple code with functions. e.g fibonacci
>> calculation.
>> > This series of patches include a non real, sample board.
>> > No fuses support yet. PC is set to 0 at reset.
>> >
>>
>> I have a couple of general remarks, so I am responding to the cover
>> letter, not individual patches.
>>
>> 1) The licenses for Sarah devices differ than the rest - shouldn't all
>> licenses be harmonized?
>
> Sarah,
> do you mind if use the same license I use for my code?
>
>
>>
>
>
>> 2) There is an architectural problem with peripherals. It is possible
>> that they evolve over time, so, for example, USART could not be the
>> same for older and newer CPUs (in principle, newer peripheral is
>> expected to be o sort of "superset" of the older). How do you solve
>> that problem? Right now, it may not looks serious to you, but if you
>> don;t think about that right now, from the outset, soon the code will
>> become so entangled, ti woudl be almost very difficult to fix it.
>> Please think about that, how would you solve it, is there a way to
>> pass the information on the currently emulated CPU to the code
>> covering a peripheral, and provide a different behaviour?
>>
> Hi Aleksandar,
>
> Please explain.
>
>
My concern is about peripherals inside the chip, together with the core.

If one models, let's say an external (in the sense, it is a separate chip)
ADC (analog-to-digital converter), one looks at specs, implement what is
resonable possible in QEMU, plug it in in one of machines thst contains it,
and that's it. That ADC remains the same, of course, whatever the
surrounding system is.

In AVR case, I think we have a phenomenon likes of which we didn't see
before (at least I don't know about). Number of AVR microcontrollers is
very large, and both cores and peripherals evolved.

For cores, you handle differences with all these AVR_FEATURE macros, and
this seems to be working, no significant objection from my side, and btw
that was not an easy task to execute, all admiration from me.

But what about peripherals inside the chip? A peripheral with the same name
and the same general area of functionality may be differently specified for
microcontrollers from 2010 and 2018. By the difference I don't mean
starting address, but the difference in behavior. I don't have time right
now to spell many examples, but I read three different specs, and there are
differences in USART specifications.

I am not clear what is your envisioned solution for these cases. Would you
such close, but not the same, flabors of a peripheral treat as if they are
two completely separate cases of a peripheral? Or would you have a single
peripheral that would somehow configure itself depending on the core it is
attached to?

I hope I was clearer this time.

Aleksandar



>
>
>
> I don't see any problem from CPU's perspective.
> as for the sample board is just a sample, I hope other people will create
> real models or real hw.
> there was no way I could provide a CPU alone, that's why there is sample.
>
>
>
>>
>> > Following are examples of possible usages, assuming program.elf is
>> compiled for AVR cpu
>> > 1.  Continious non interrupted execution
>> > run `qemu-system-avr -kernel program.elf`
>> > 2.  Continious non interrupted execution with serial output into telnet
>> window
>> > run `qemu-system-avr -kernel program.elf -serial
>> tcp::5678,server,nowait -nographic `
>> > run `telent localhost 5678`
>> > 3.  Continious non interrupted execution with serial output into stdout
>> > run `qemu-system-avr -kernel program.elf -serial stdio`
>> > 4.  Debugging wit GDB debugger
>> > run `qemu-system-avr -kernel program.elf -s -S`
>> > run `avr-gdb program.elf` and then within GDB shell `target remote
>> :1234`
>> > 5.  Print out executed instructions
>> > run `qemu-system-avr -kernel program.elf -d in_asm`
>> >
>>
>> Thank you so much for these examples!
>>
>> Aleksandar
>>
>>
>> >
>> > the patches include the following
>> > 1. just a basic 8bit AVR CPU, without instruction decoding or
>> translation
>> > 2. CPU features which allow define the following 8bit AVR cores
>> >  avr1
>> >  avr2 avr25
>> >  avr3 avr31 avr35
>> >  avr4
>> >  avr5 avr51
>> >  avr6
>> >  xmega2 xmega4 xmega5 xmega6 xmega7
>> > 3. a definition of sample machine with SRAM, FLASH and CPU which allows
>> to execute simple code
>> > 4. encoding for all AVR instructions
>> > 5. interrupt handling
>> > 6. helpers for IN, OUT, SLEEP, WBR & unsupported instructions
>> > 7. a decoder which given an opcode decides what istruction it is
>> > 8. tran

[PATCH 1/7] target/ppc: Implement the VTB for HV access

[Cédric Le Goater]

From: Suraj Jitindar Singh 

The virtual timebase register (VTB) is a 64-bit register which
increments at the same rate as the timebase register, present on POWER8
and later processors.

The register is able to be read/written by the hypervisor and read by
the supervisor. All other accesses are illegal.

Currently the VTB is just an alias for the timebase (TB) register.

Implement the VTB so that is can be read/written independent of the TB.
Make use of the existing method for accessing timebase facilities where
by the compensation is stored and used to compute the value on reads/is
updated on writes.

Signed-off-by: Suraj Jitindar Singh 
[ clg: rebased on current ppc tree ]
Signed-off-by: Cédric Le Goater 
---
 include/hw/ppc/ppc.h|  1 +
 target/ppc/cpu.h|  2 ++
 target/ppc/helper.h |  2 ++
 hw/ppc/ppc.c| 16 
 linux-user/ppc/cpu_loop.c   |  5 +
 target/ppc/timebase_helper.c| 10 ++
 target/ppc/translate_init.inc.c | 19 +++
 7 files changed, 51 insertions(+), 4 deletions(-)

diff --git a/include/hw/ppc/ppc.h b/include/hw/ppc/ppc.h
index 585be6ab98c5..02481cd27c36 100644
--- a/include/hw/ppc/ppc.h
+++ b/include/hw/ppc/ppc.h
@@ -24,6 +24,7 @@ struct ppc_tb_t {
 /* Time base management */
 int64_t  tb_offset;/* Compensation*/
 int64_t  atb_offset;   /* Compensation*/
+int64_t  vtb_offset;
 uint32_t tb_freq;  /* TB frequency*/
 /* Decrementer management */
 uint64_t decr_next;/* Tick for next decr interrupt*/
diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
index e3e82327b723..19d6e724bb5a 100644
--- a/target/ppc/cpu.h
+++ b/target/ppc/cpu.h
@@ -1305,6 +1305,8 @@ uint64_t cpu_ppc_load_atbl(CPUPPCState *env);
 uint32_t cpu_ppc_load_atbu(CPUPPCState *env);
 void cpu_ppc_store_atbl(CPUPPCState *env, uint32_t value);
 void cpu_ppc_store_atbu(CPUPPCState *env, uint32_t value);
+uint64_t cpu_ppc_load_vtb(CPUPPCState *env);
+void cpu_ppc_store_vtb(CPUPPCState *env, uint64_t value);
 bool ppc_decr_clear_on_delivery(CPUPPCState *env);
 target_ulong cpu_ppc_load_decr(CPUPPCState *env);
 void cpu_ppc_store_decr(CPUPPCState *env, target_ulong value);
diff --git a/target/ppc/helper.h b/target/ppc/helper.h
index f843814b8aa8..a5f53bb421a7 100644
--- a/target/ppc/helper.h
+++ b/target/ppc/helper.h
@@ -649,6 +649,7 @@ DEF_HELPER_FLAGS_1(load_tbl, TCG_CALL_NO_RWG, tl, env)
 DEF_HELPER_FLAGS_1(load_tbu, TCG_CALL_NO_RWG, tl, env)
 DEF_HELPER_FLAGS_1(load_atbl, TCG_CALL_NO_RWG, tl, env)
 DEF_HELPER_FLAGS_1(load_atbu, TCG_CALL_NO_RWG, tl, env)
+DEF_HELPER_FLAGS_1(load_vtb, TCG_CALL_NO_RWG, tl, env)
 DEF_HELPER_FLAGS_1(load_601_rtcl, TCG_CALL_NO_RWG, tl, env)
 DEF_HELPER_FLAGS_1(load_601_rtcu, TCG_CALL_NO_RWG, tl, env)
 #if !defined(CONFIG_USER_ONLY)
@@ -669,6 +670,7 @@ DEF_HELPER_FLAGS_1(load_decr, TCG_CALL_NO_RWG, tl, env)
 DEF_HELPER_FLAGS_2(store_decr, TCG_CALL_NO_RWG, void, env, tl)
 DEF_HELPER_FLAGS_1(load_hdecr, TCG_CALL_NO_RWG, tl, env)
 DEF_HELPER_FLAGS_2(store_hdecr, TCG_CALL_NO_RWG, void, env, tl)
+DEF_HELPER_FLAGS_2(store_vtb, TCG_CALL_NO_RWG, void, env, tl)
 DEF_HELPER_2(store_hid0_601, void, env, tl)
 DEF_HELPER_3(store_403_pbr, void, env, i32, tl)
 DEF_HELPER_FLAGS_1(load_40x_pit, TCG_CALL_NO_RWG, tl, env)
diff --git a/hw/ppc/ppc.c b/hw/ppc/ppc.c
index 8dd982fc1e40..263922052536 100644
--- a/hw/ppc/ppc.c
+++ b/hw/ppc/ppc.c
@@ -694,6 +694,22 @@ void cpu_ppc_store_atbu (CPUPPCState *env, uint32_t value)
  &tb_env->atb_offset, ((uint64_t)value << 32) | tb);
 }
 
+uint64_t cpu_ppc_load_vtb(CPUPPCState *env)
+{
+ppc_tb_t *tb_env = env->tb_env;
+
+return cpu_ppc_get_tb(tb_env, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL),
+  tb_env->vtb_offset);
+}
+
+void cpu_ppc_store_vtb(CPUPPCState *env, uint64_t value)
+{
+ppc_tb_t *tb_env = env->tb_env;
+
+cpu_ppc_store_tb(tb_env, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL),
+ &tb_env->vtb_offset, value);
+}
+
 static void cpu_ppc_tb_stop (CPUPPCState *env)
 {
 ppc_tb_t *tb_env = env->tb_env;
diff --git a/linux-user/ppc/cpu_loop.c b/linux-user/ppc/cpu_loop.c
index d5704def2902..5b27f8603e33 100644
--- a/linux-user/ppc/cpu_loop.c
+++ b/linux-user/ppc/cpu_loop.c
@@ -47,6 +47,11 @@ uint32_t cpu_ppc_load_atbu(CPUPPCState *env)
 return cpu_ppc_get_tb(env) >> 32;
 }
 
+uint64_t cpu_ppc_load_vtb(CPUPPCState *env)
+{
+return cpu_ppc_get_tb(env);
+}
+
 uint32_t cpu_ppc601_load_rtcu(CPUPPCState *env)
 __attribute__ (( alias ("cpu_ppc_load_tbu") ));
 
diff --git a/target/ppc/timebase_helper.c b/target/ppc/timebase_helper.c
index 73363e08ae71..8c3c2fe67c2c 100644
--- a/target/ppc/timebase_helper.c
+++ b/target/ppc/timebase_helper.c
@@ -45,6 +45,11 @@ target_ulong helper_load_atbu(CPUPPCState *env)
 return cpu_ppc_load_atbu(env);
 }
 
+target_ulong helper_load_vtb(CPUPPCState *env)
+{
+return cpu_ppc

Re: [PATCH V2] block/nbd: fix memory leak in nbd_open()

[Stefano Garzarella]

On Thu, Nov 28, 2019 at 08:09:31PM +0800, pannengy...@huawei.com wrote:
> From: PanNengyuan 
> 
> In currently implementation there will be a memory leak when
> nbd_client_connect() returns error status. Here is an easy way to
> reproduce:
> 
> 1. run qemu-iotests as follow and check the result with asan:
> ./check -raw 143
> 
> Following is the asan output backtrack:
> Direct leak of 40 byte(s) in 1 object(s) allocated from:
> #0 0x7f629688a560 in calloc (/usr/lib64/libasan.so.3+0xc7560)
> #1 0x7f6295e7e015 in g_malloc0  (/usr/lib64/libglib-2.0.so.0+0x50015)
> #2 0x56281dab4642 in qobject_input_start_struct  
> /mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:295
> #3 0x56281dab1a04 in visit_start_struct  
> /mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:49
> #4 0x56281dad1827 in visit_type_SocketAddress  
> qapi/qapi-visit-sockets.c:386
> #5 0x56281da8062f in nbd_config   /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
> #6 0x56281da8062f in nbd_process_options  
> /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
> #7 0x56281da8062f in nbd_open  /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
> 
> Direct leak of 15 byte(s) in 1 object(s) allocated from:
> #0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
> #1 0x7f6295e7dfbd in g_malloc (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
> #2 0x7f6295e96ace in g_strdup (/usr/lib64/libglib-2.0.so.0+0x68ace)
> #3 0x56281da804ac in nbd_process_options 
> /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1834
> #4 0x56281da804ac in nbd_open /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
> 
> Indirect leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f629688a3a0 in malloc (/usr/lib64/libasan.so.3+0xc73a0)
> #1 0x7f6295e7dfbd in g_malloc (/usr/lib64/libglib-2.0.so.0+0x4ffbd)
> #2 0x7f6295e96ace in g_strdup (/usr/lib64/libglib-2.0.so.0+0x68ace)
> #3 0x56281dab41a3 in qobject_input_type_str_keyval  
> /mnt/sdb/qemu-4.2.0-rc0/qapi/qobject-input-visitor.c:536
> #4 0x56281dab2ee9 in visit_type_str  
> /mnt/sdb/qemu-4.2.0-rc0/qapi/qapi-visit-core.c:297
> #5 0x56281dad0fa1 in visit_type_UnixSocketAddress_members 
> qapi/qapi-visit-sockets.c:141
> #6 0x56281dad17b6 in visit_type_SocketAddress_members  
> qapi/qapi-visit-sockets.c:366
> #7 0x56281dad186a in visit_type_SocketAddress 
> qapi/qapi-visit-sockets.c:393
> #8 0x56281da8062f in nbd_config /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1716
> #9 0x56281da8062f in nbd_process_options 
> /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1829
> #10 0x56281da8062f in nbd_open /mnt/sdb/qemu-4.2.0-rc0/block/nbd.c:1873
> 
> Reported-by: Euler Robot 
> Signed-off-by: PanNengyuan 
> ---
> Changes v2 to v1:
> - add a new function to do the common cleanups (suggested by Stefano 
> Garzarella).
> ---
>  block/nbd.c | 26 --
>  1 file changed, 16 insertions(+), 10 deletions(-)
> 
> diff --git a/block/nbd.c b/block/nbd.c
> index 1239761..f8aa2a8 100644
> --- a/block/nbd.c
> +++ b/block/nbd.c
> @@ -94,6 +94,8 @@ typedef struct BDRVNBDState {
>  
>  static int nbd_client_connect(BlockDriverState *bs, Error **errp);
>  
> +static void nbd_free_bdrvstate_prop(BDRVNBDState *s);
> +
>  static void nbd_channel_error(BDRVNBDState *s, int ret)
>  {
>  if (ret == -EIO) {
> @@ -1486,6 +1488,17 @@ static int nbd_client_connect(BlockDriverState *bs, 
> Error **errp)
>  }
>  }
>  
> +static void nbd_free_bdrvstate_prop(BDRVNBDState *s)
> +{
> +object_unref(OBJECT(s->tlscreds));
> +qapi_free_SocketAddress(s->saddr);
> +g_free(s->export);
> +g_free(s->tlscredsid);
> +if (s->x_dirty_bitmap) {
   ^ it is not needed, g_free() handles NULL pointers.
> +g_free(s->x_dirty_bitmap);
> +}
> +}
> +

Please, split this patch in two patches:
- the first patch where you add this function and use it in
  nbd_process_options() and nbd_close()
- the second patch where you fix the leak in nbd_open()

Thanks,
Stefano

>  /*
>   * Parse nbd_open options
>   */
> @@ -1855,10 +1868,7 @@ static int nbd_process_options(BlockDriverState *bs, 
> QDict *options,
>  
>   error:
>  if (ret < 0) {
> -object_unref(OBJECT(s->tlscreds));
> -qapi_free_SocketAddress(s->saddr);
> -g_free(s->export);
> -g_free(s->tlscredsid);
> +nbd_free_bdrvstate_prop(s);
>  }
>  qemu_opts_del(opts);
>  return ret;
> @@ -1881,6 +1891,7 @@ static int nbd_open(BlockDriverState *bs, QDict 
> *options, int flags,
>  
>  ret = nbd_client_connect(bs, errp);
>  if (ret < 0) {
> +nbd_free_bdrvstate_prop(s);
>  return ret;
>  }
>  /* successfully connected */
> @@ -1937,12 +1948,7 @@ static void nbd_close(BlockDriverState *bs)
>  BDRVNBDState *s = bs->opaque;
>  
>  nbd_client_close(bs);
> -
> -object_unref(OBJECT(s->tlscreds));
> -qapi_free_SocketAddress(s->saddr);
> -g_free(s->export);
> -g_free(s->tlscredsid);
> -g_free(s->x_dirty_bitmap);
> +nbd_free_bdrvstate_prop(s);
> 

[PATCH 3/7] target/ppc: Add SPR ASDR

[Cédric Le Goater]

From: Suraj Jitindar Singh 

The Access Segment Descriptor Register (ASDR) provides information about
the storage element when taking a hypervisor storage interrupt. When
performing nested radix address translation, this is normally the guest
real address. This register is present on POWER9 processors and later.

Implement the ADSR, note read and write access is limited to the
hypervisor.

Signed-off-by: Suraj Jitindar Singh 
Reviewed-by: David Gibson 
Signed-off-by: Cédric Le Goater 
---
 target/ppc/cpu.h| 1 +
 target/ppc/translate_init.inc.c | 6 ++
 2 files changed, 7 insertions(+)

diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
index 9128dbefbdb0..646a94370dba 100644
--- a/target/ppc/cpu.h
+++ b/target/ppc/cpu.h
@@ -1780,6 +1780,7 @@ typedef PowerPCCPU ArchCPU;
 #define SPR_MPC_MD_DBRAM1 (0x32A)
 #define SPR_RCPU_L2U_RA3  (0x32B)
 #define SPR_TAR   (0x32F)
+#define SPR_ASDR  (0x330)
 #define SPR_IC(0x350)
 #define SPR_VTB   (0x351)
 #define SPR_MMCRC (0x353)
diff --git a/target/ppc/translate_init.inc.c b/target/ppc/translate_init.inc.c
index 6105e74e9dc6..a3cf1d8a450c 100644
--- a/target/ppc/translate_init.inc.c
+++ b/target/ppc/translate_init.inc.c
@@ -8290,6 +8290,12 @@ static void gen_spr_power9_mmu(CPUPPCState *env)
 SPR_NOACCESS, SPR_NOACCESS,
 &spr_read_generic, &spr_write_ptcr,
 KVM_REG_PPC_PTCR, 0x);
+/* Address Segment Descriptor Register */
+spr_register_hv(env, SPR_ASDR, "ASDR",
+SPR_NOACCESS, SPR_NOACCESS,
+SPR_NOACCESS, SPR_NOACCESS,
+&spr_read_generic, &spr_write_generic,
+0x);
 #endif
 }
 
-- 
2.21.0

Re: [PATCH v37 00/17] QEMU AVR 8 bit cores

[Aleksandar Markovic]

On Thursday, November 28, 2019, Philippe Mathieu-Daudé 
wrote:

> On 11/28/19 2:25 PM, Michael Rolnik wrote:
>
>> I don't see why you say that the peripherals are inside the chip, there
>> is CPU within target/avr directory and then there are some peripherals in
>> hw directory, CPU does not depend on them. what am I missing?
>>
>> On Thu, Nov 28, 2019 at 3:22 PM Aleksandar Markovic <
>> aleksandar.m.m...@gmail.com > wrote:
>>
>>
>>
>> On Thursday, November 28, 2019, Michael Rolnik > > wrote:
>>
>>
>>
>> On Wed, Nov 27, 2019 at 11:06 PM Aleksandar Markovic
>> > > wrote:
>>
>> On Wed, Nov 27, 2019 at 6:53 PM Michael Rolnik
>> mailto:mrol...@gmail.com>> wrote:
>>  >
>>  > This series of patches adds 8bit AVR cores to QEMU.
>>  > All instruction, except BREAK/DES/SPM/SPMX, are
>> implemented. Not fully tested yet.
>>  > However I was able to execute simple code with functions.
>> e.g fibonacci calculation.
>>  > This series of patches include a non real, sample board.
>>  > No fuses support yet. PC is set to 0 at reset.
>>  >
>>
>> I have a couple of general remarks, so I am responding to
>> the cover
>> letter, not individual patches.
>>
>> 1) The licenses for Sarah devices differ than the rest -
>> shouldn't all
>> licenses be harmonized?
>>
>> Sarah,
>> do you mind if use the same license I use for my code?
>>
>>
>> 2) There is an architectural problem with peripherals. It is
>> possible
>> that they evolve over time, so, for example, USART could not
>> be the
>> same for older and newer CPUs (in principle, newer peripheral
>> is
>> expected to be o sort of "superset" of the older). How do
>> you solve
>> that problem? Right now, it may not looks serious to you,
>> but if you
>> don;t think about that right now, from the outset, soon the
>> code will
>> become so entangled, ti woudl be almost very difficult to
>> fix it.
>> Please think about that, how would you solve it, is there a
>> way to
>> pass the information on the currently emulated CPU to the code
>> covering a peripheral, and provide a different behaviour?
>>
>> Hi Aleksandar,
>>
>> Please explain.
>>
>>
>> My concern is about peripherals inside the chip, together with the
>> core.
>>
>> If one models, let's say an external (in the sense, it is a separate
>> chip) ADC (analog-to-digital converter), one looks at specs,
>> implement what is resonable possible in QEMU, plug it in in one of
>> machines thst contains it, and that's it. That ADC remains the same,
>> of course, whatever the surrounding system is.
>>
>> In AVR case, I think we have a phenomenon likes of which we didn't
>> see before (at least I don't know about). Number of AVR
>> microcontrollers is very large, and both cores and peripherals
>> evolved.
>>
>> For cores, you handle differences with all these AVR_FEATURE macros,
>> and this seems to be working, no significant objection from my side,
>> and btw that was not an easy task to execute, all admiration from me.
>>
>> But what about peripherals inside the chip? A peripheral with the
>> same name and the same general area of functionality may be
>> differently specified for microcontrollers from 2010 and 2018. By
>> the difference I don't mean starting address, but the difference in
>> behavior. I don't have time right now to spell many examples, but I
>> read three different specs, and there are differences in USART
>> specifications.
>>
>> I am not clear what is your envisioned solution for these cases.
>> Would you such close, but not the same, flabors of a peripheral
>> treat as if they are two completely separate cases of a peripheral?
>> Or would you have a single peripheral that would somehow configure
>> itself depending on the core it is attached to?
>>
>> I hope I was clearer this time.
>>
>> Aleksandar
>>
>>
>>
>>
>> I don't see any problem from CPU's perspective.
>> as for the sample board is just a sample, I hope other people
>> will create real models or real hw.
>> there was no way I could provide a CPU alone, that's why there
>> is sample.
>>
>
> If I understand Aleksandar correctly, the naming is incorrect because too
> generic to AVR family, why Sarah only modeled the Atmel implementation.
>
> Renaming devices such hw/char/avr_usart.c -> hw/char/atmel_usart.c
> (similarly with the macros) would be enough Aleksand

[PATCH 2/7] target/ppc: Work [S]PURR implementation and add HV support

[Cédric Le Goater]

From: Suraj Jitindar Singh 

The Processor Utilisation of Resources Register (PURR) and Scaled
Processor Utilisation of Resources Register (SPURR) provide an estimate
of the resources used by the thread, present on POWER7 and later
processors.

Currently the [S]PURR registers simply count at the rate of the
timebase.

Preserve this behaviour but rework the implementation to store an offset
like the timebase rather than doing the calculation manually. Also allow
hypervisor write access to the register along with the currently
available read access.

Signed-off-by: Suraj Jitindar Singh 
Reviewed-by: David Gibson 
[ clg: rebased on current ppc tree ]
Signed-off-by: Cédric Le Goater 
---

 David,

 In the initial discussion, PURR and VTB still needed to be added to
 the migration stream. The patch is changing the representation indeed
 but that seems OK. AFAICT, all the SPRs are migrated. I didn't quite
 understand that part. See http://patchwork.ozlabs.org/patch/1094662
 for more info.

 Nevertheless, you added your Reviewed-by.

 include/hw/ppc/ppc.h|  3 +--
 target/ppc/cpu.h|  1 +
 target/ppc/helper.h |  1 +
 hw/ppc/ppc.c| 17 +++--
 target/ppc/timebase_helper.c|  5 +
 target/ppc/translate_init.inc.c | 23 +++
 6 files changed, 30 insertions(+), 20 deletions(-)

diff --git a/include/hw/ppc/ppc.h b/include/hw/ppc/ppc.h
index 02481cd27c36..27bef85ca869 100644
--- a/include/hw/ppc/ppc.h
+++ b/include/hw/ppc/ppc.h
@@ -33,8 +33,7 @@ struct ppc_tb_t {
 /* Hypervisor decrementer management */
 uint64_t hdecr_next;/* Tick for next hdecr interrupt  */
 QEMUTimer *hdecr_timer;
-uint64_t purr_load;
-uint64_t purr_start;
+int64_t purr_offset;
 void *opaque;
 uint32_t flags;
 };
diff --git a/target/ppc/cpu.h b/target/ppc/cpu.h
index 19d6e724bb5a..9128dbefbdb0 100644
--- a/target/ppc/cpu.h
+++ b/target/ppc/cpu.h
@@ -1313,6 +1313,7 @@ void cpu_ppc_store_decr(CPUPPCState *env, target_ulong 
value);
 target_ulong cpu_ppc_load_hdecr(CPUPPCState *env);
 void cpu_ppc_store_hdecr(CPUPPCState *env, target_ulong value);
 uint64_t cpu_ppc_load_purr(CPUPPCState *env);
+void cpu_ppc_store_purr(CPUPPCState *env, uint64_t value);
 uint32_t cpu_ppc601_load_rtcl(CPUPPCState *env);
 uint32_t cpu_ppc601_load_rtcu(CPUPPCState *env);
 #if !defined(CONFIG_USER_ONLY)
diff --git a/target/ppc/helper.h b/target/ppc/helper.h
index a5f53bb421a7..356a14d8a639 100644
--- a/target/ppc/helper.h
+++ b/target/ppc/helper.h
@@ -655,6 +655,7 @@ DEF_HELPER_FLAGS_1(load_601_rtcu, TCG_CALL_NO_RWG, tl, env)
 #if !defined(CONFIG_USER_ONLY)
 #if defined(TARGET_PPC64)
 DEF_HELPER_FLAGS_1(load_purr, TCG_CALL_NO_RWG, tl, env)
+DEF_HELPER_FLAGS_2(store_purr, TCG_CALL_NO_RWG, void, env, tl)
 DEF_HELPER_2(store_ptcr, void, env, tl)
 #endif
 DEF_HELPER_2(store_sdr1, void, env, tl)
diff --git a/hw/ppc/ppc.c b/hw/ppc/ppc.c
index 263922052536..353f11b91d40 100644
--- a/hw/ppc/ppc.c
+++ b/hw/ppc/ppc.c
@@ -821,12 +821,9 @@ target_ulong cpu_ppc_load_hdecr(CPUPPCState *env)
 uint64_t cpu_ppc_load_purr (CPUPPCState *env)
 {
 ppc_tb_t *tb_env = env->tb_env;
-uint64_t diff;
 
-diff = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL) - tb_env->purr_start;
-
-return tb_env->purr_load +
-muldiv64(diff, tb_env->tb_freq, NANOSECONDS_PER_SECOND);
+return cpu_ppc_get_tb(tb_env, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL),
+  tb_env->purr_offset);
 }
 
 /* When decrementer expires,
@@ -985,12 +982,12 @@ static void cpu_ppc_hdecr_cb(void *opaque)
 cpu_ppc_hdecr_excp(cpu);
 }
 
-static void cpu_ppc_store_purr(PowerPCCPU *cpu, uint64_t value)
+void cpu_ppc_store_purr(CPUPPCState *env, uint64_t value)
 {
-ppc_tb_t *tb_env = cpu->env.tb_env;
+ppc_tb_t *tb_env = env->tb_env;
 
-tb_env->purr_load = value;
-tb_env->purr_start = qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL);
+cpu_ppc_store_tb(tb_env, qemu_clock_get_ns(QEMU_CLOCK_VIRTUAL),
+ &tb_env->purr_offset, value);
 }
 
 static void cpu_ppc_set_tb_clk (void *opaque, uint32_t freq)
@@ -1007,7 +1004,7 @@ static void cpu_ppc_set_tb_clk (void *opaque, uint32_t 
freq)
  */
 _cpu_ppc_store_decr(cpu, 0x, 0x, 32);
 _cpu_ppc_store_hdecr(cpu, 0x, 0x, 32);
-cpu_ppc_store_purr(cpu, 0xULL);
+cpu_ppc_store_purr(env, 0xULL);
 }
 
 static void timebase_save(PPCTimebase *tb)
diff --git a/target/ppc/timebase_helper.c b/target/ppc/timebase_helper.c
index 8c3c2fe67c2c..2395295b778c 100644
--- a/target/ppc/timebase_helper.c
+++ b/target/ppc/timebase_helper.c
@@ -55,6 +55,11 @@ target_ulong helper_load_purr(CPUPPCState *env)
 {
 return (target_ulong)cpu_ppc_load_purr(env);
 }
+
+void helper_store_purr(CPUPPCState *env, target_ulong val)
+{
+cpu_ppc_store_purr(env, val);
+}
 #endif
 
 target_ulong helper_load_601_rtcl(CPUPPCState *env)
diff --git a/target/ppc/translate_ini