[PATCH v15 10/12] hmat acpi: Build System Locality Latency and Bandwidth Information Structure(s)

2019-11-06 Thread 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.

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

No changes in v15.

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

diff --git a/hw/acpi/hmat.c b/hw/acpi/hmat.c
index c595098ba7..6ec1310e62 100644
--- a/hw/acpi/hmat.c
+++ b/hw/acpi/hmat.c
@@ -27,6 +27,7 @@
 #include "qemu/osdep.h"
 #include "sysemu/numa.h"
 #include "hw/acpi/hmat.h"
+#include "qemu/error-report.h"
 
 /*
  * ACPI 6.3:
@@ -67,11 +68,81 @@ 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;
+uint16_t *lb_data;
+uint32_t base;
+/*
+ * Length in bytes for entire structure, including 32 bytes of
+ * fixed length, length of initiator proximity domain list,
+ * length of target proximity domain list and length of entries
+ * provides latency/bandwidth values.
+ */
+uint32_t lb_length = 32 + 4 * num_initiator + 4 * num_target +
+  2 * num_initiator * num_target;
+
+/* 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);
+
+if (hmat_lb->data_type <= HMAT_LB_DATA_WRITE_LATENCY) {
+base = hmat_lb->base_latency;
+lb_data = hmat_lb->entry_latency;
+} else {
+base = hmat_lb->base_bandwidth;
+lb_data = hmat_lb->entry_bandwidth;
+}
+
+/* Entry Base Unit */
+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 */
+for (i = 0; i < num_initiator * num_target; i++) {
+build_append_int_noprefix(table_data, lb_data[i], 2);
+}
+}
+
 /* 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 +153,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_ACCESS_LATENCY;
+ type <= HMAT_LB_DATA_WRITE_BANDWIDTH; type++) {
+hmat_lb = numa_state->hmat_lb[hierarchy][type];
+
+if (hmat_lb) {
+build_hmat_lb(table_data, hmat_lb, num_initiator,
+  numa_state->num_nodes, initiator_list);
+}
+}
+}
 }
 
 void build_hmat(GArray *table_data, BIOSLinker *linker, NumaState *numa_state)
-- 
2.20.1




[PATCH v15 08/12] numa: Extend CLI to provide memory side cache information

2019-11-06 Thread 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).

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

Changes in v15:
- Change the QAPI version tag to 5.0 (Eric)

No changes in v14.

Changes in v13:
- Drop the total_levels option.
- Use readable cache size (Igor)
---
 hw/core/numa.c| 66 
 include/sysemu/numa.h | 31 +
 qapi/machine.json | 78 +--
 qemu-options.hx   | 16 +++--
 4 files changed, 187 insertions(+), 4 deletions(-)

diff --git a/hw/core/numa.c b/hw/core/numa.c
index 523dd80822..165b38d74b 100644
--- a/hw/core/numa.c
+++ b/hw/core/numa.c
@@ -321,6 +321,59 @@ void parse_numa_hmat_lb(NumaState *numa_state, 
NumaHmatLBOptions *node,
 }
 }
 
+void parse_numa_hmat_cache(MachineState *ms, NumaHmatCacheOptions *node,
+   Error **errp)
+{
+int nb_numa_nodes = ms->numa_state->num_nodes;
+HMAT_Cache_Info *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 (node->level > MAX_HMAT_CACHE_LEVEL) {
+error_setg(errp, "Invalid level=%" PRIu8
+   ", it should be less than or equal to %d.",
+   node->level, MAX_HMAT_CACHE_LEVEL);
+return;
+}
+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=0x%" PRIx64
+   ", the size of level=%" PRIu8
+   " should be less than the size(0x%" PRIx64
+   ") 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));
+
+hmat_cache->proximity = node->node_id;
+hmat_cache->size = node->size;
+hmat_cache->level = node->level;
+hmat_cache->associativity = node->assoc;
+hmat_cache->write_policy = node->policy;
+hmat_cache->line_size = node->line;
+
+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;
@@ -372,6 +425,19 @@ void set_numa_options(MachineState *ms, NumaOptions 
*object, Error **errp)
 goto end;
 }
 break;
+case NUMA_OPTIONS_TYPE_HMAT_CACHE:
+if (!ms->numa_state->hmat_enabled) {
+error_setg(errp, "ACPI Heterogeneous Memory Attribute Table "
+   "(HMAT) is disabled, enable it with -machine hmat=on "
+   "before using any of hmat specific options.");
+return;
+}
+
+parse_numa_hmat_cache(ms, >u.hmat_cache, );
+if (err) {
+goto end;
+}
+break;
 default:
 abort();
 }
diff --git a/include/sysemu/numa.h b/include/sysemu/numa.h
index 36e1b4dece..50554709e7 100644
--- a/include/sysemu/numa.h
+++ b/include/sysemu/numa.h
@@ -37,6 +37,8 @@ enum {
 #define HMAT_LB_LEVELS(HMAT_LB_MEM_CACHE_3RD_LEVEL + 1)
 #define HMAT_LB_TYPES (HMAT_LB_DATA_WRITE_BANDWIDTH + 1)
 
+#define MAX_HMAT_CACHE_LEVELHMAT_LB_MEM_CACHE_3RD_LEVEL
+
 struct NodeInfo {
 uint64_t node_mem;
 struct HostMemoryBackend *node_memdev;
@@ -91,6 +93,30 @@ struct HMAT_LB_Info {
 };
 typedef struct HMAT_LB_Info HMAT_LB_Info;
 
+struct HMAT_Cache_Info {
+/* The memory proximity domain to which the memory belongs. */
+uint32_tproximity;
+
+/* Size of memory side cache in bytes. */
+uint64_tsize;
+
+/* Total cache levels for this memory proximity domain. */
+uint8_t total_levels;
+
+/* Cache level described in this structure. */
+uint8_t level;
+
+/* Cache Associativity: None/Direct Mapped/Comple Cache Indexing */
+uint8_t associativity;
+
+/* Write Policy: None/Write Back(WB)/Write Through(WT) */
+uint8_t write_policy;
+
+/* Cache Line size in bytes. */
+uint16_tline_size;
+};
+typedef struct HMAT_Cache_Info HMAT_Cache_Info;
+
 struct 

[PATCH v15 06/12] numa: Extend CLI to provide memory latency and bandwidth information

2019-11-06 Thread 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).

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

Changes in v15:
- Change the QAPI version tag to 5.0 (Eric)

Changes in v14:
- Use qemu ctz64 and clz64 instead of builtin function
- Improve help message in qemu-options.hx

Changes in v13:
- Reuse Garray to store the raw bandwidth and bandwidth data
- Calculate common base unit using range bitmap (Igor)
---
 hw/core/numa.c| 136 ++
 include/sysemu/numa.h |  68 +
 qapi/machine.json |  94 -
 qemu-options.hx   |  49 ++-
 4 files changed, 344 insertions(+), 3 deletions(-)

diff --git a/hw/core/numa.c b/hw/core/numa.c
index eba66ab768..f391760c20 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,128 @@ 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 first_bit, last_bit;
+uint64_t max_latency, 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;
+
+/* 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, "Invalid target=%d, it hasn't a valid NUMA 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->latency = g_array_new(false, true, sizeof(HMAT_LB_Data));
+hmat_lb->bandwidth = 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;
+
+/* Input latency data */
+if (node->data_type <= HMATLB_DATA_TYPE_WRITE_LATENCY) {
+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;
+}
+
+if (hmat_lb->base_latency == 0) {
+hmat_lb->base_latency = UINT64_MAX;
+}
+
+/* Calculate the temporary base and compressed latency */
+max_latency = node->latency;
+temp_base_la = 1;
+while (QEMU_IS_ALIGNED(max_latency, 10)) {
+max_latency /= 10;
+temp_base_la *= 10;
+}
+
+/* Calculate the max compressed latency */
+hmat_lb->base_latency = MIN(hmat_lb->base_latency, temp_base_la);
+max_latency = node->latency / hmat_lb->base_latency;
+hmat_lb->max_entry_la = MAX(hmat_lb->max_entry_la, max_latency);
+
+if (hmat_lb->max_entry_la >= UINT16_MAX) {
+error_setg(errp, "Latency %" PRIu64 " between initiator=%d and "
+   "target=%d should not differ from previously entered "
+   "values on more than %d.", node->latency,
+   node->initiator, node->target, UINT16_MAX - 1);
+return;
+}
+
+lb_data.rawdata = node->latency;
+g_array_append_val(hmat_lb->latency, lb_data);
+}
+
+/* Input bandwidth data */
+if (node->data_type >= HMATLB_DATA_TYPE_ACCESS_BANDWIDTH) {
+if (!node->has_bandwidth) {
+error_setg(errp, "Missing 'bandwidth' option.");
+return;
+}
+if (node->has_latency) {
+error_setg(errp, "Invalid option 'latency' since "
+   "the data type is bandwidth.");
+return;
+}
+if 

[PATCH v15 09/12] hmat acpi: Build Memory Proximity Domain Attributes Structure(s)

2019-11-06 Thread 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: Daniel Black 
Reviewed-by: Jonathan Cameron 
Signed-off-by: Liu Jingqi 
Signed-off-by: Tao Xu 
---

No changes in v15.

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..c595098ba7
--- /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,
+uint16_t initiator, uint16_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, NumaState *numa_state)
+{
+uint16_t flags;
+int i;
+
+for (i = 0; i < 

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

2019-11-06 Thread Tao Xu
From: Liu Jingqi 

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

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

No changes in v15.

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

diff --git a/hw/acpi/hmat.c b/hw/acpi/hmat.c
index 6ec1310e62..931aa60678 100644
--- a/hw/acpi/hmat.c
+++ b/hw/acpi/hmat.c
@@ -135,14 +135,63 @@ static void build_hmat_lb(GArray *table_data, 
HMAT_LB_Info *hmat_lb,
 }
 }
 
+/* ACPI 6.3: 5.2.27.5 Memory Side Cache Information Structure: Table 5-147 */
+static void build_hmat_cache(GArray *table_data, HMAT_Cache_Info *hmat_cache)
+{
+/*
+ * Cache Attributes: Bits [3:0] – Total Cache Levels
+ * for this Memory Proximity Domain
+ */
+uint32_t cache_attr = hmat_cache->total_levels & 0xF;
+
+/* Bits [7:4] : Cache Level described in this structure */
+cache_attr |= (hmat_cache->level & 0xF) << 4;
+
+/* Bits [11:8] - Cache Associativity */
+cache_attr |= (hmat_cache->associativity & 0x7) << 8;
+
+/* Bits [15:12] - Write Policy */
+cache_attr |= (hmat_cache->write_policy & 0x7) << 12;
+
+/* Bits [31:16] - Cache Line size in bytes */
+cache_attr |= (hmat_cache->line_size & 0x) << 16;
+
+cache_attr = cpu_to_le32(cache_attr);
+
+/* 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->proximity, 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;
+HMAT_Cache_Info *hmat_cache;
 
 for (i = 0; i < numa_state->num_nodes; i++) {
 flags = 0;
@@ -176,6 +225,27 @@ 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 <= MAX_HMAT_CACHE_LEVEL;
+ 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) {
+hmat_cache->total_levels = total_levels;
+build_hmat_cache(table_data, hmat_cache);
+}
+}
+}
 }
 
 void build_hmat(GArray *table_data, BIOSLinker *linker, NumaState *numa_state)
-- 
2.20.1




[PATCH v15 02/12] util/cutils: Add qemu_strtotime_ns()

2019-11-06 Thread Tao Xu
To convert strings with time suffixes to numbers, support time unit are
"ns" for nanosecond, "us" for microsecond, "ms" for millisecond or "s"
for second. Add test for qemu_strtotime_ns, test the input of basic,
time suffixes, float, invaild, trailing and overflow.

Signed-off-by: Tao Xu 
---

Changes in v15:
- Add a new patch to refactor do_strtosz() (Eduardo)
- use ARRAY_SIZE(suffixes) instead of hardcoding the
  suffixes number (Eduardo)

Changes in 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)
---
 include/qemu/cutils.h |   1 +
 tests/test-cutils.c   | 204 ++
 util/cutils.c |  14 +++
 3 files changed, 219 insertions(+)

diff --git a/include/qemu/cutils.h b/include/qemu/cutils.h
index b54c847e0f..ff2b3f4614 100644
--- a/include/qemu/cutils.h
+++ b/include/qemu/cutils.h
@@ -182,5 +182,6 @@ int uleb128_decode_small(const uint8_t *in, uint32_t *n);
  * *str1 is <, == or > than *str2.
  */
 int qemu_pstrcmp0(const char **str1, const char **str2);
+int qemu_strtotime_ns(const char *nptr, const char **end, uint64_t *result);
 
 #endif
diff --git a/tests/test-cutils.c b/tests/test-cutils.c
index 1aa8351520..d6a0824efd 100644
--- a/tests/test-cutils.c
+++ b/tests/test-cutils.c
@@ -2179,6 +2179,198 @@ static void test_qemu_strtosz_metric(void)
 g_assert(endptr == str + 6);
 }
 
+static void test_qemu_strtotime_ns_simple(void)
+{
+const char *str;
+const char *endptr;
+int err;
+uint64_t res = 0xbaadf00d;
+
+str = "0";
+err = qemu_strtotime_ns(str, , );
+g_assert_cmpint(err, ==, 0);
+g_assert_cmpint(res, ==, 0);
+g_assert(endptr == str + 1);
+
+str = "56789";
+err = qemu_strtotime_ns(str, , );
+g_assert_cmpint(err, ==, 0);
+g_assert_cmpint(res, ==, 56789);
+g_assert(endptr == str + 5);
+
+err = qemu_strtotime_ns(str, NULL, );
+g_assert_cmpint(err, ==, 0);
+g_assert_cmpint(res, ==, 56789);
+
+/* Note: precision is 53 bits since we're parsing with strtod() */
+
+str = "9007199254740991"; /* 2^53-1 */
+err = qemu_strtotime_ns(str, , );
+g_assert_cmpint(err, ==, 0);
+g_assert_cmpint(res, ==, 0x1f);
+g_assert(endptr == str + 16);
+
+str = "9007199254740992"; /* 2^53 */
+err = qemu_strtotime_ns(str, , );
+g_assert_cmpint(err, ==, 0);
+g_assert_cmpint(res, ==, 0x20);
+g_assert(endptr == str + 16);
+
+str = "9007199254740993"; /* 2^53+1 */
+err = qemu_strtotime_ns(str, , );
+g_assert_cmpint(err, ==, 0);
+g_assert_cmpint(res, ==, 0x20); /* rounded to 53 bits */
+g_assert(endptr == str + 16);
+
+str = "18446744073709549568"; /* 0xf800 (53 msbs set) */
+err = qemu_strtotime_ns(str, , );
+g_assert_cmpint(err, ==, 0);
+g_assert_cmpint(res, ==, 0xf800);
+g_assert(endptr == str + 20);
+
+str = "18446744073709550591"; /* 0xfbff */
+err = qemu_strtotime_ns(str, , );
+g_assert_cmpint(err, ==, 0);
+g_assert_cmpint(res, ==, 0xf800); /* rounded to 53 bits */
+g_assert(endptr == str + 20);
+
+/* 0x7e00..0x7fff get rounded to
+ * 0x8000, thus -ERANGE; see test_qemu_strtosz_erange() */
+}
+
+static void test_qemu_strtotime_ns_units(void)
+{
+const char *ns = "1ns";
+const char *us = "1us";
+const char *ms = "1ms";
+const char *s = "1s";
+int err;
+const char *endptr;
+uint64_t res = 0xbaadf00d;
+
+/* default time unit is ns */
+err = qemu_strtotime_ns(ns, , );
+g_assert_cmpint(err, ==, 0);
+g_assert_cmpint(res, ==, 1);
+g_assert(endptr == ns + 3);
+
+err = qemu_strtotime_ns(us, , );
+g_assert_cmpint(err, ==, 0);
+g_assert_cmpint(res, ==, 1000);
+g_assert(endptr == us + 3);
+
+err = qemu_strtotime_ns(ms, , );
+g_assert_cmpint(err, ==, 0);
+g_assert_cmpint(res, ==, 100);
+g_assert(endptr == ms + 3);
+
+err = qemu_strtotime_ns(s, , );
+g_assert_cmpint(err, ==, 0);
+g_assert_cmpint(res, ==, 10LL);
+g_assert(endptr == s + 2);
+}
+
+static void test_qemu_strtotime_ns_float(void)
+{
+const char *str = "56.789us";
+int err;
+const char *endptr;
+uint64_t res = 0xbaadf00d;
+
+err = qemu_strtotime_ns(str, , );
+g_assert_cmpint(err, ==, 0);
+g_assert_cmpint(res, ==, 56.789 * 1000);
+g_assert(endptr == str + 8);
+}
+
+static void test_qemu_strtotime_ns_invalid(void)
+{
+const char *str;
+const char *endptr;
+int err;
+uint64_t res = 0xbaadf00d;
+
+str = "";
+err = qemu_strtotime_ns(str, , );
+g_assert_cmpint(err, ==, -EINVAL);
+g_assert(endptr == str);
+
+str = " \t ";
+err = qemu_strtotime_ns(str, , );
+g_assert_cmpint(err, ==, -EINVAL);
+g_assert(endptr == 

[PATCH v15 03/12] qapi: Add builtin type time

2019-11-06 Thread Tao Xu
Add optional builtin type time, fallback is uint64. This type use
qemu_strtotime_ns() for pre-converting time suffix to numbers.

Signed-off-by: Tao Xu 
---

No changes in v15.

Changes in v14:
- Drop time unit picosecond (Eric)
---
 include/qapi/visitor-impl.h  |  4 
 include/qapi/visitor.h   |  8 
 qapi/opts-visitor.c  | 22 ++
 qapi/qapi-visit-core.c   | 12 
 qapi/qobject-input-visitor.c | 18 ++
 qapi/trace-events|  1 +
 scripts/qapi/schema.py   |  1 +
 7 files changed, 66 insertions(+)

diff --git a/include/qapi/visitor-impl.h b/include/qapi/visitor-impl.h
index 8ccb3b6c20..e0979563c7 100644
--- a/include/qapi/visitor-impl.h
+++ b/include/qapi/visitor-impl.h
@@ -88,6 +88,10 @@ struct Visitor
 void (*type_size)(Visitor *v, const char *name, uint64_t *obj,
   Error **errp);
 
+/* Optional; fallback is type_uint64() */
+void (*type_time)(Visitor *v, const char *name, uint64_t *obj,
+  Error **errp);
+
 /* Must be set */
 void (*type_bool)(Visitor *v, const char *name, bool *obj, Error **errp);
 
diff --git a/include/qapi/visitor.h b/include/qapi/visitor.h
index c5b23851a1..22242e706f 100644
--- a/include/qapi/visitor.h
+++ b/include/qapi/visitor.h
@@ -554,6 +554,14 @@ void visit_type_int64(Visitor *v, const char *name, 
int64_t *obj,
 void visit_type_size(Visitor *v, const char *name, uint64_t *obj,
  Error **errp);
 
+/*
+ * Visit a uint64_t value.
+ * Like visit_type_uint64(), except that some visitors may choose to
+ * recognize numbers with timeunit suffix, such as "ns", "us" "ms" and "s".
+ */
+void visit_type_time(Visitor *v, const char *name, uint64_t *obj,
+ Error **errp);
+
 /*
  * Visit a boolean value.
  *
diff --git a/qapi/opts-visitor.c b/qapi/opts-visitor.c
index 5fe0276c1c..59b575f0fc 100644
--- a/qapi/opts-visitor.c
+++ b/qapi/opts-visitor.c
@@ -526,6 +526,27 @@ opts_type_size(Visitor *v, const char *name, uint64_t 
*obj, Error **errp)
 processed(ov, name);
 }
 
+static void
+opts_type_time(Visitor *v, const char *name, uint64_t *obj, Error **errp)
+{
+OptsVisitor *ov = to_ov(v);
+const QemuOpt *opt;
+int err;
+
+opt = lookup_scalar(ov, name, errp);
+if (!opt) {
+return;
+}
+
+err = qemu_strtotime_ns(opt->str ? opt->str : "", NULL, obj);
+if (err < 0) {
+error_setg(errp, QERR_INVALID_PARAMETER_VALUE, opt->name,
+   "a time value");
+return;
+}
+
+processed(ov, name);
+}
 
 static void
 opts_optional(Visitor *v, const char *name, bool *present)
@@ -573,6 +594,7 @@ opts_visitor_new(const QemuOpts *opts)
 ov->visitor.type_int64  = _type_int64;
 ov->visitor.type_uint64 = _type_uint64;
 ov->visitor.type_size   = _type_size;
+ov->visitor.type_time   = _type_time;
 ov->visitor.type_bool   = _type_bool;
 ov->visitor.type_str= _type_str;
 
diff --git a/qapi/qapi-visit-core.c b/qapi/qapi-visit-core.c
index 5365561b07..ac8896455c 100644
--- a/qapi/qapi-visit-core.c
+++ b/qapi/qapi-visit-core.c
@@ -277,6 +277,18 @@ void visit_type_size(Visitor *v, const char *name, 
uint64_t *obj,
 }
 }
 
+void visit_type_time(Visitor *v, const char *name, uint64_t *obj,
+ Error **errp)
+{
+assert(obj);
+trace_visit_type_time(v, name, obj);
+if (v->type_time) {
+v->type_time(v, name, obj, errp);
+} else {
+v->type_uint64(v, name, obj, errp);
+}
+}
+
 void visit_type_bool(Visitor *v, const char *name, bool *obj, Error **errp)
 {
 assert(obj);
diff --git a/qapi/qobject-input-visitor.c b/qapi/qobject-input-visitor.c
index 32236cbcb1..e476fe0d16 100644
--- a/qapi/qobject-input-visitor.c
+++ b/qapi/qobject-input-visitor.c
@@ -627,6 +627,23 @@ static void qobject_input_type_size_keyval(Visitor *v, 
const char *name,
 }
 }
 
+static void qobject_input_type_time_keyval(Visitor *v, const char *name,
+   uint64_t *obj, Error **errp)
+{
+QObjectInputVisitor *qiv = to_qiv(v);
+const char *str = qobject_input_get_keyval(qiv, name, errp);
+
+if (!str) {
+return;
+}
+
+if (qemu_strtotime_ns(str, NULL, obj) < 0) {
+/* TODO report -ERANGE more nicely */
+error_setg(errp, QERR_INVALID_PARAMETER_VALUE,
+   full_name(qiv, name), "time");
+}
+}
+
 static void qobject_input_optional(Visitor *v, const char *name, bool *present)
 {
 QObjectInputVisitor *qiv = to_qiv(v);
@@ -708,6 +725,7 @@ Visitor *qobject_input_visitor_new_keyval(QObject *obj)
 v->visitor.type_any = qobject_input_type_any;
 v->visitor.type_null = qobject_input_type_null;
 v->visitor.type_size = qobject_input_type_size_keyval;
+v->visitor.type_time = qobject_input_type_time_keyval;
 v->keyval = true;
 
 return >visitor;
diff --git a/qapi/trace-events b/qapi/trace-events
index 

[PATCH v15 07/12] numa: Calculate hmat latency and bandwidth entry list

2019-11-06 Thread Tao Xu
Compress HMAT latency and bandwidth raw data into uint16_t data,
which can be stored in HMAT table.

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

No changes in v15.

Changes in v14:
- Convert latency from ns to ps, because ACPI 6.3 HMAT table use
  ps as minimum unit
---
 hw/core/numa.c | 59 +-
 1 file changed, 58 insertions(+), 1 deletion(-)

diff --git a/hw/core/numa.c b/hw/core/numa.c
index f391760c20..523dd80822 100644
--- a/hw/core/numa.c
+++ b/hw/core/numa.c
@@ -483,6 +483,47 @@ static void complete_init_numa_distance(MachineState *ms)
 }
 }
 
+static void calculate_hmat_entry_list(HMAT_LB_Info *hmat_lb, int num_nodes)
+{
+int i, index;
+uint16_t *entry_list;
+uint64_t base;
+GArray *lb_data_list;
+HMAT_LB_Data *lb_data;
+
+if (hmat_lb->data_type <= HMAT_LB_DATA_WRITE_LATENCY) {
+base = hmat_lb->base_latency;
+lb_data_list = hmat_lb->latency;
+} else {
+base = hmat_lb->base_bandwidth;
+lb_data_list = hmat_lb->bandwidth;
+}
+
+entry_list = g_malloc0(lb_data_list->len * sizeof(uint16_t));
+for (i = 0; i < lb_data_list->len; i++) {
+lb_data = _array_index(lb_data_list, HMAT_LB_Data, i);
+index = lb_data->initiator * num_nodes + lb_data->target;
+if (entry_list[index]) {
+error_report("Duplicate configuration of the latency for "
+"initiator=%d and target=%d.", lb_data->initiator,
+lb_data->target);
+exit(1);
+}
+
+entry_list[index] = (uint16_t)(lb_data->rawdata / base);
+}
+
+if (hmat_lb->data_type <= HMAT_LB_DATA_WRITE_LATENCY) {
+/* Convert latency base from nanoseconds to picosecond */
+hmat_lb->base_latency = base * 1000;
+hmat_lb->entry_latency = entry_list;
+} else {
+/* Convert bandwidth base from Byte to Megabyte */
+hmat_lb->base_bandwidth = base / MiB;
+hmat_lb->entry_bandwidth = entry_list;
+}
+}
+
 void numa_legacy_auto_assign_ram(MachineClass *mc, NodeInfo *nodes,
  int nb_nodes, ram_addr_t size)
 {
@@ -521,9 +562,10 @@ void numa_default_auto_assign_ram(MachineClass *mc, 
NodeInfo *nodes,
 
 void numa_complete_configuration(MachineState *ms)
 {
-int i;
+int i, hierarchy, type;
 MachineClass *mc = MACHINE_GET_CLASS(ms);
 NodeInfo *numa_info = ms->numa_state->nodes;
+HMAT_LB_Info *numa_hmat_lb;
 
 /*
  * If memory hotplug is enabled (slots > 0) but without '-numa'
@@ -620,6 +662,21 @@ void numa_complete_configuration(MachineState *ms)
 /* Validation succeeded, now fill in any missing distances. */
 complete_init_numa_distance(ms);
 }
+
+if (ms->numa_state->hmat_enabled) {
+for (hierarchy = HMAT_LB_MEM_MEMORY;
+ hierarchy <= HMAT_LB_MEM_CACHE_3RD_LEVEL; hierarchy++) {
+for (type = HMAT_LB_DATA_ACCESS_LATENCY;
+type <= HMAT_LB_DATA_WRITE_BANDWIDTH; type++) {
+numa_hmat_lb = ms->numa_state->hmat_lb[hierarchy][type];
+
+if (numa_hmat_lb) {
+calculate_hmat_entry_list(numa_hmat_lb,
+  ms->numa_state->num_nodes);
+}
+}
+}
+}
 }
 }
 
-- 
2.20.1




[PATCH v15 04/12] tests: Add test for QAPI builtin type time

2019-11-06 Thread Tao Xu
Add tests for time input such as zero, around limit of precision,
signed upper limit, actual upper limit, beyond limits, time suffixes,
and etc.

Signed-off-by: Tao Xu 
---

No changes in v15.

Changes in v14:
- Drop time unit picosecond (Eric)
---
 tests/test-keyval.c| 122 +
 tests/test-qobject-input-visitor.c |  29 +++
 2 files changed, 151 insertions(+)

diff --git a/tests/test-keyval.c b/tests/test-keyval.c
index 09b0ae3c68..28e2e34084 100644
--- a/tests/test-keyval.c
+++ b/tests/test-keyval.c
@@ -490,6 +490,127 @@ static void test_keyval_visit_size(void)
 visit_free(v);
 }
 
+static void test_keyval_visit_time(void)
+{
+Error *err = NULL;
+Visitor *v;
+QDict *qdict;
+uint64_t time;
+
+/* Lower limit zero */
+qdict = keyval_parse("time1=0", NULL, _abort);
+v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
+qobject_unref(qdict);
+visit_start_struct(v, NULL, NULL, 0, _abort);
+visit_type_time(v, "time1", , _abort);
+g_assert_cmpuint(time, ==, 0);
+visit_check_struct(v, _abort);
+visit_end_struct(v, NULL);
+visit_free(v);
+
+/* Around limit of precision: 2^53-1, 2^53, 2^53+1 */
+qdict = keyval_parse("time1=9007199254740991,"
+ "time2=9007199254740992,"
+ "time3=9007199254740993",
+ NULL, _abort);
+v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
+qobject_unref(qdict);
+visit_start_struct(v, NULL, NULL, 0, _abort);
+visit_type_time(v, "time1", , _abort);
+g_assert_cmphex(time, ==, 0x1f);
+visit_type_time(v, "time2", , _abort);
+g_assert_cmphex(time, ==, 0x20);
+visit_type_time(v, "time3", , _abort);
+g_assert_cmphex(time, ==, 0x20);
+visit_check_struct(v, _abort);
+visit_end_struct(v, NULL);
+visit_free(v);
+
+/* Close to signed upper limit 0x7c00 (53 msbs set) */
+qdict = keyval_parse("time1=9223372036854774784," /* 7c00 */
+ "time2=9223372036854775295", /* 7dff */
+ NULL, _abort);
+v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
+qobject_unref(qdict);
+visit_start_struct(v, NULL, NULL, 0, _abort);
+visit_type_time(v, "time1", , _abort);
+g_assert_cmphex(time, ==, 0x7c00);
+visit_type_time(v, "time2", , _abort);
+g_assert_cmphex(time, ==, 0x7c00);
+visit_check_struct(v, _abort);
+visit_end_struct(v, NULL);
+visit_free(v);
+
+/* Close to actual upper limit 0xf800 (53 msbs set) */
+qdict = keyval_parse("time1=18446744073709549568," /* f800 */
+ "time2=18446744073709550591", /* fbff */
+ NULL, _abort);
+v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
+qobject_unref(qdict);
+visit_start_struct(v, NULL, NULL, 0, _abort);
+visit_type_time(v, "time1", , _abort);
+g_assert_cmphex(time, ==, 0xf800);
+visit_type_time(v, "time2", , _abort);
+g_assert_cmphex(time, ==, 0xf800);
+visit_check_struct(v, _abort);
+visit_end_struct(v, NULL);
+visit_free(v);
+
+/* Beyond limits */
+qdict = keyval_parse("time1=-1,"
+ "time2=18446744073709550592", /* fc00 */
+ NULL, _abort);
+v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
+qobject_unref(qdict);
+visit_start_struct(v, NULL, NULL, 0, _abort);
+visit_type_time(v, "time1", , );
+error_free_or_abort();
+visit_type_time(v, "time2", , );
+error_free_or_abort();
+visit_end_struct(v, NULL);
+visit_free(v);
+
+/* Suffixes */
+qdict = keyval_parse("time1=2ns,time2=3.4us,time3=5ms,time4=600s",
+ NULL, _abort);
+v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
+qobject_unref(qdict);
+visit_start_struct(v, NULL, NULL, 0, _abort);
+visit_type_time(v, "time1", , _abort);
+g_assert_cmpuint(time, ==, 2);
+visit_type_time(v, "time2", , _abort);
+g_assert_cmpuint(time, ==, 3400);
+visit_type_time(v, "time3", , _abort);
+g_assert_cmphex(time, ==, 5 * 1000 * 1000);
+visit_type_time(v, "time4", , _abort);
+g_assert_cmphex(time, ==, 600 * 10LL);
+visit_check_struct(v, _abort);
+visit_end_struct(v, NULL);
+visit_free(v);
+
+/* Beyond limit with suffix */
+qdict = keyval_parse("time1=1844674407370955s", NULL, _abort);
+v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
+qobject_unref(qdict);
+visit_start_struct(v, NULL, NULL, 0, _abort);
+visit_type_time(v, "time1", , );
+error_free_or_abort();
+visit_end_struct(v, NULL);
+visit_free(v);
+
+/* Trailing crap */
+qdict = keyval_parse("time1=89ks,time2=ns", NULL, _abort);
+v = 

[PATCH v15 00/12] Build ACPI Heterogeneous Memory Attribute Table (HMAT)

2019-11-06 Thread 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 V14 patches link:
https://patchwork.kernel.org/cover/11214887/

Changelog:
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)
v11:
- Move numa option patches forward.
- Add num_initiator in Numa_state to record the number of
initiators.
- Simplify struct HMAT_LB_Info, use uint64_t array to store data.
- Drop hmat_get_base().
- Calculate base in build_hmat_lb().
v10:
- Add qemu_strtotime_ps() to convert strings with time suffixes
to numbers, and add some tests for it.
- Add qapi buildin type time, and add some tests for it.
- Add machine oprion properties "-machine hmat=on|off" for enabling
or disabling HMAT in QEMU.

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 (7):
  util/cutils: refactor do_strtosz() to support suffixes list
  util/cutils: Add qemu_strtotime_ns()
  qapi: Add builtin type time
  tests: Add test for QAPI builtin type time
  numa: Extend CLI to provide initiator information for numa nodes
  numa: Calculate hmat latency and bandwidth entry list
  tests/bios-tables-test: add test cases for ACPI HMAT

 hw/acpi/Kconfig   |   7 +-
 hw/acpi/Makefile.objs |   1 +
 hw/acpi/hmat.c| 263 
 hw/acpi/hmat.h|  42 
 hw/core/machine.c |  64 ++
 hw/core/numa.c| 284 +-
 hw/i386/acpi-build.c  |   5 +
 include/qapi/visitor-impl.h   |   4 +
 include/qapi/visitor.h|   8 +
 include/qemu/cutils.h |   1 +
 include/sysemu/numa.h | 104 ++
 qapi/machine.json | 178 +++-
 qapi/opts-visitor.c   |  22 ++
 qapi/qapi-visit-core.c|  12 ++
 qapi/qobject-input-visitor.c  |  18 ++
 qapi/trace-events |   1 +
 qemu-options.hx   |  96 -
 scripts/qapi/schema.py|   1 +
 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/test-cutils.c   | 204 ++
 tests/test-keyval.c   | 122 +++
 tests/test-qobject-input-visitor.c|  29 +++
 util/cutils.c |  86 +---
 32 files changed, 1562 insertions(+), 42 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 

[PATCH v15 05/12] numa: Extend CLI to provide initiator information for numa nodes

2019-11-06 Thread 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.

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.

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

Changes in v15:
- Change the QAPI version tag to 5.0 (Eric)

Changes in v14:
- Drop the error_printf("\n"); (Igor)

Changes in v13:
- Modify some text description
- Drop "initiator_valid" field in struct NodeInfo (Igor)
---
 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..e60d0b4552 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,
+ _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, , _fatal);
 }
 }
+
+if (machine->numa_state->hmat_enabled) {
+numa_validate_initiator(machine->numa_state);
+}
+
 if (s->len && 

[PATCH v15 01/12] util/cutils: refactor do_strtosz() to support suffixes list

2019-11-06 Thread Tao Xu
Add do_strtomul() to convert string according to different suffixes.

Signed-off-by: Tao Xu 
---

Changes in v15:
- Add a new patch to refactor do_strtosz() (Eduardo)
---
 util/cutils.c | 72 ++-
 1 file changed, 42 insertions(+), 30 deletions(-)

diff --git a/util/cutils.c b/util/cutils.c
index fd591cadf0..86d6e271fa 100644
--- a/util/cutils.c
+++ b/util/cutils.c
@@ -181,41 +181,37 @@ int fcntl_setfl(int fd, int flag)
 }
 #endif
 
-static int64_t suffix_mul(char suffix, int64_t unit)
+static int64_t suffix_mul(const char *suffixes[], int num_suffix,
+  const char *endptr, int *offset, int64_t unit)
 {
-switch (qemu_toupper(suffix)) {
-case 'B':
-return 1;
-case 'K':
-return unit;
-case 'M':
-return unit * unit;
-case 'G':
-return unit * unit * unit;
-case 'T':
-return unit * unit * unit * unit;
-case 'P':
-return unit * unit * unit * unit * unit;
-case 'E':
-return unit * unit * unit * unit * unit * unit;
+int i, suffix_len;
+int64_t mul = 1;
+
+for (i = 0; i < num_suffix; i++) {
+suffix_len = strlen(suffixes[i]);
+if (g_ascii_strncasecmp(suffixes[i], endptr, suffix_len) == 0) {
+*offset = suffix_len;
+return mul;
+}
+mul *= unit;
 }
+
 return -1;
 }
 
 /*
- * Convert string to bytes, allowing either B/b for bytes, K/k for KB,
- * M/m for MB, G/g for GB or T/t for TB. End pointer will be returned
- * in *end, if not NULL. Return -ERANGE on overflow, and -EINVAL on
- * other error.
+ * Convert string according to different suffixes. End pointer will be returned
+ * in *end, if not NULL. Return -ERANGE on overflow, and -EINVAL on other 
error.
  */
-static int do_strtosz(const char *nptr, const char **end,
-  const char default_suffix, int64_t unit,
+static int do_strtomul(const char *nptr, const char **end,
+   const char *suffixes[], int num_suffix,
+   const char *default_suffix, int64_t unit,
   uint64_t *result)
 {
 int retval;
 const char *endptr;
-unsigned char c;
 int mul_required = 0;
+int offset = 0;
 double val, mul, integral, fraction;
 
 retval = qemu_strtod_finite(nptr, , );
@@ -226,12 +222,12 @@ static int do_strtosz(const char *nptr, const char **end,
 if (fraction != 0) {
 mul_required = 1;
 }
-c = *endptr;
-mul = suffix_mul(c, unit);
+
+mul = suffix_mul(suffixes, num_suffix, endptr, , unit);
 if (mul >= 0) {
-endptr++;
+endptr += offset;
 } else {
-mul = suffix_mul(default_suffix, unit);
+mul = suffix_mul(suffixes, num_suffix, default_suffix, , unit);
 assert(mul >= 0);
 }
 if (mul == 1 && mul_required) {
@@ -259,19 +255,35 @@ out:
 return retval;
 }
 
+/*
+ * Convert string to bytes, allowing either B/b for bytes, K/k for KB,
+ * M/m for MB, G/g for GB or T/t for TB. End pointer will be returned
+ * in *end, if not NULL. Return -ERANGE on overflow, and -EINVAL on
+ * other error.
+ */
+static int do_strtosz(const char *nptr, const char **end,
+  const char *default_suffix, int64_t unit,
+  uint64_t *result)
+{
+static const char *suffixes[] = { "B", "K", "M", "G", "T", "P", "E" };
+
+return do_strtomul(nptr, end, suffixes, ARRAY_SIZE(suffixes),
+   default_suffix, unit, result);
+}
+
 int qemu_strtosz(const char *nptr, const char **end, uint64_t *result)
 {
-return do_strtosz(nptr, end, 'B', 1024, result);
+return do_strtosz(nptr, end, "B", 1024, result);
 }
 
 int qemu_strtosz_MiB(const char *nptr, const char **end, uint64_t *result)
 {
-return do_strtosz(nptr, end, 'M', 1024, result);
+return do_strtosz(nptr, end, "M", 1024, result);
 }
 
 int qemu_strtosz_metric(const char *nptr, const char **end, uint64_t *result)
 {
-return do_strtosz(nptr, end, 'B', 1000, result);
+return do_strtosz(nptr, end, "B", 1000, result);
 }
 
 /**
-- 
2.20.1




Re: guest / host buffer sharing ...

2019-11-06 Thread Gerd Hoffmann
> On 2019-11-06 23:41, Gerd Hoffmann wrote:
> > On Wed, Nov 06, 2019 at 05:36:22PM +0900, David Stevens wrote:
> > > > (1) The virtio device
> > > > =
> > > >
> > > > Has a single virtio queue, so the guest can send commands to register
> > > > and unregister buffers.  Buffers are allocated in guest ram.  Each 
> > > > buffer
> > > > has a list of memory ranges for the data. Each buffer also has some
> > > 
> > > Allocating from guest ram would work most of the time, but I think
> > > it's insufficient for many use cases. It doesn't really support things
> > > such as contiguous allocations, allocations from carveouts or <4GB,
> > > protected buffers, etc.
> > 
> > If there are additional constrains (due to gpu hardware I guess)
> > I think it is better to leave the buffer allocation to virtio-gpu.
> 
> The entire point of this for our purposes is due to the fact that we can
> not allocate the buffer, it's either provided by the GPU driver or
> DirectX. If virtio-gpu were to allocate the buffer we might as well forget
> all this and continue using the ivshmem device.

Well, virtio-gpu resources are in guest ram, like the buffers of a
virtio-buffers device would be.  So it isn't much of a difference.  If
the buffer provided by the (nvidia/amd/intel) gpu driver lives in ram
you can create a virtio-gpu resource for it.

On the linux side that is typically handled with dma-buf, one driver
exports the dma-buf and the other imports it.  virtio-gpu doesn't
support that fully yet though (import is being worked on, export is done
and will land upstream in the next merge window).

No clue how this looks like for windows guests ...

> Currently IVSHMEM is used by two projects that I am aware of, Looking
> Glass and SCREAM. While Looking Glass is solving a problem that is out of
> scope for QEMU, SCREAM is working around the audio problems in QEMU that
> have been present for years now.

Side note: sound in qemu 3.1+ should be alot better than in 2.x
versions.

cheers,
  Gerd




Re: [PATCH v14 03/11] tests: Add test for QAPI builtin type time

2019-11-06 Thread Tao Xu

On 11/7/2019 4:53 AM, Eduardo Habkost wrote:

On Mon, Oct 28, 2019 at 03:52:12PM +0800, Tao Xu wrote:

Add tests for time input such as zero, around limit of precision,
signed upper limit, actual upper limit, beyond limits, time suffixes,
and etc.

Signed-off-by: Tao Xu 
---

[...]

+/* Close to signed upper limit 0x7c00 (53 msbs set) */
+qdict = keyval_parse("time1=9223372036854774784," /* 7c00 */
+ "time2=9223372036854775295", /* 7dff */
+ NULL, _abort);
+v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
+qobject_unref(qdict);
+visit_start_struct(v, NULL, NULL, 0, _abort);
+visit_type_time(v, "time1", , _abort);
+g_assert_cmphex(time, ==, 0x7c00);
+visit_type_time(v, "time2", , _abort);
+g_assert_cmphex(time, ==, 0x7c00);


I'm confused by this test case and the one below[1].  Are these
known bugs?  Shouldn't we document them as known bugs?


Because do_strtosz() or do_strtomul() actually parse with strtod(), so 
the precision is 53 bits, so in these cases, 7dff and 
fbff are rounded.



+visit_check_struct(v, _abort);
+visit_end_struct(v, NULL);
+visit_free(v);
+
+/* Close to actual upper limit 0xf800 (53 msbs set) */
+qdict = keyval_parse("time1=18446744073709549568," /* f800 */
+ "time2=18446744073709550591", /* fbff */
+ NULL, _abort);
+v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
+qobject_unref(qdict);
+visit_start_struct(v, NULL, NULL, 0, _abort);
+visit_type_time(v, "time1", , _abort);
+g_assert_cmphex(time, ==, 0xf800);
+visit_type_time(v, "time2", , _abort);
+g_assert_cmphex(time, ==, 0xf800);


[1]


+visit_check_struct(v, _abort);
+visit_end_struct(v, NULL);
+visit_free(v);

[...]






Re: [PATCH 0/6] migration/postcopy: enable compress during postcopy

2019-11-06 Thread Wei Yang
On Wed, Nov 06, 2019 at 08:11:44PM +, Dr. David Alan Gilbert wrote:
>* Wei Yang (richardw.y...@linux.intel.com) wrote:
>> This patch set tries enable compress during postcopy.
>> 
>> postcopy requires to place a whole host page, while migration thread migrate
>> memory in target page size. This makes postcopy need to collect all target
>> pages in one host page before placing via userfaultfd.
>> 
>> To enable compress during postcopy, there are two problems to solve:
>> 
>> 1. Random order for target page arrival
>> 2. Target pages in one host page arrives without interrupt by target
>>page from other host page
>> 
>> The first one is handled by counting the number of target pages arrived
>> instead of the last target page arrived.
>> 
>> The second one is handled by:
>> 
>> 1. Flush compress thread for each host page
>> 2. Wait for decompress thread for before placing host page
>> 
>> With the combination of these two changes, compress is enabled during
>> postcopy.
>
>What have you tested this with? 2MB huge pages I guess?
>

I tried with this qemu option:

   -object memory-backend-file,id=mem1,mem-path=/dev/hugepages/guest2,size=4G \
   -device pc-dimm,id=dimm1,memdev=mem1

/dev/hugepages/guest2 is a file under hugetlbfs

   hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)

>Dave
>
>> Wei Yang (6):
>>   migration/postcopy: reduce memset when it is zero page and
>> matches_target_page_size
>>   migration/postcopy: wait for decompress thread in precopy
>>   migration/postcopy: count target page number to decide the
>> place_needed
>>   migration/postcopy: set all_zero to true on the first target page
>>   migration/postcopy: enable random order target page arrival
>>   migration/postcopy: enable compress during postcopy
>> 
>>  migration/migration.c | 11 
>>  migration/ram.c   | 65 ++-
>>  2 files changed, 45 insertions(+), 31 deletions(-)
>> 
>> -- 
>> 2.17.1
>> 
>--
>Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

-- 
Wei Yang
Help you, Help me



Re: [PATCH 5/6] migration/postcopy: enable random order target page arrival

2019-11-06 Thread Wei Yang
On Wed, Nov 06, 2019 at 08:08:28PM +, Dr. David Alan Gilbert wrote:
>* Wei Yang (richardw.y...@linux.intel.com) wrote:
>> After using number of target page received to track one host page, we
>> could have the capability to handle random order target page arrival in
>> one host page.
>> 
>> This is a preparation for enabling compress during postcopy.
>> 
>> Signed-off-by: Wei Yang 
>> ---
>>  migration/ram.c | 16 +++-
>>  1 file changed, 3 insertions(+), 13 deletions(-)
>> 
>> diff --git a/migration/ram.c b/migration/ram.c
>> index b5759793a9..da0596411c 100644
>> --- a/migration/ram.c
>> +++ b/migration/ram.c
>> @@ -4015,7 +4015,6 @@ static int ram_load_postcopy(QEMUFile *f)
>>  MigrationIncomingState *mis = migration_incoming_get_current();
>>  /* Temporary page that is later 'placed' */
>>  void *postcopy_host_page = mis->postcopy_tmp_page;
>> -void *last_host = NULL;
>>  bool all_zero = false;
>>  int target_pages = 0;
>>  
>> @@ -4062,24 +4061,15 @@ static int ram_load_postcopy(QEMUFile *f)
>>   * that's moved into place later.
>>   * The migration protocol uses,  possibly smaller, target-pages
>>   * however the source ensures it always sends all the components
>> - * of a host page in order.
>> + * of a host page in one chunk.
>>   */
>>  page_buffer = postcopy_host_page +
>>((uintptr_t)host & (block->page_size - 1));
>>  /* If all TP are zero then we can optimise the place */
>>  if (target_pages == 1) {
>>  all_zero = true;
>> -} else {
>> -/* not the 1st TP within the HP */
>> -if (host != (last_host + TARGET_PAGE_SIZE)) {
>> -error_report("Non-sequential target page %p/%p",
>> -  host, last_host);
>> -ret = -EINVAL;
>> -break;
>> -}
>
>I think this is losing more protection than needed.
>I think you can still protect against a page from a different host-page
>arriving until we've placed the current host-page.
>So something like:
>
>if (((uintptr_t)host & ~(block->page_size - 1)) !=
>last_host)
>

OK, looks reasonable.

>and then set last_host to the start of the host page.
>

I think it is not necessary to update the last_host on each target page. We
can just set it at the first target page.

>Then you'll check if that flush is really working.
>
>Dave
>
>>  }
>>  
>> -
>>  /*
>>   * If it's the last part of a host page then we place the host
>>   * page
>> @@ -4090,7 +4080,6 @@ static int ram_load_postcopy(QEMUFile *f)
>>  }
>>  place_source = postcopy_host_page;
>>  }
>> -last_host = host;
>>  
>>  switch (flags & ~RAM_SAVE_FLAG_CONTINUE) {
>>  case RAM_SAVE_FLAG_ZERO:
>> @@ -4143,7 +4132,8 @@ static int ram_load_postcopy(QEMUFile *f)
>>  
>>  if (!ret && place_needed) {
>>  /* This gets called at the last target page in the host page */
>> -void *place_dest = host + TARGET_PAGE_SIZE - block->page_size;
>> +void *place_dest = (void *)QEMU_ALIGN_DOWN((unsigned long)host,
>> +   block->page_size);
>>  
>>  if (all_zero) {
>>  ret = postcopy_place_page_zero(mis, place_dest,
>> -- 
>> 2.17.1
>> 
>--
>Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK

-- 
Wei Yang
Help you, Help me



Re: [Qemu-devel] [PATCH v2 1/2] net: assert that tx packets have nonzero size

2019-11-06 Thread Jason Wang



On 2019/7/22 下午9:24, Oleinik, Alexander wrote:

Virtual devices should not try to send zero-sized packets. The caller
should check the size prior to calling qemu_sendv_packet_async.

Signed-off-by: Alexander Oleinik 
---
v2:
   * Improve the comment to explain the rationale for adding the assert.
  net/net.c | 9 +
  1 file changed, 9 insertions(+)

diff --git a/net/net.c b/net/net.c
index 7d4098254f..4ad21df36f 100644
--- a/net/net.c
+++ b/net/net.c
@@ -741,6 +741,15 @@ ssize_t qemu_sendv_packet_async(NetClientState *sender,
  size_t size = iov_size(iov, iovcnt);
  int ret;
  
+/*

+ * Since this function returns the size of the sent packets, and a return
+ * value of zero indicates that the packet will be sent asynchronously,
+ * there is currently no way to report that a 0-sized packet has been sent
+ * successfully. Forbid it for now, and if someone needs this functionality
+ * later, the API will require a change.
+ */
+assert(size);



This probably will make the assertion triggerable from guest. Is this 
better to warn and return NET_BUFSIZE + 1 here?


Thanks



+
  if (size > NET_BUFSIZE) {
  return size;
  }





Re: [PATCH] WHPX: support for xcr0

2019-11-06 Thread no-reply
Patchew URL: 
https://patchew.org/QEMU/mw2pr2101mb1116e938a5be3174ef5ec9b9c0...@mw2pr2101mb1116.namprd21.prod.outlook.com/



Hi,

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

Subject: [PATCH] WHPX: support for xcr0
Type: series
Message-id: 
mw2pr2101mb1116e938a5be3174ef5ec9b9c0...@mw2pr2101mb1116.namprd21.prod.outlook.com

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

Switched to a new branch 'test'
f1b4c7a WHPX: support for xcr0

=== OUTPUT BEGIN ===
ERROR: Missing Signed-off-by: line(s)

total: 1 errors, 0 warnings, 137 lines checked

Commit f1b4c7ae9c53 (WHPX: support for xcr0) has style problems, please review. 
 If any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
=== OUTPUT END ===

Test command exited with code: 1


The full log is available at
http://patchew.org/logs/mw2pr2101mb1116e938a5be3174ef5ec9b9c0...@mw2pr2101mb1116.namprd21.prod.outlook.com/testing.checkpatch/?type=message.
---
Email generated automatically by Patchew [https://patchew.org/].
Please send your feedback to patchew-de...@redhat.com

Looking for issues/features for my first contribution

2019-11-06 Thread Rajath Shashidhara

Hi all,

I am a Computer Science graduate student at The University of Texas at 
Austin (UT, Austin). I am looking forward to contributing to qemu !


This semester, I am taking a class in Virtualization 
(https://github.com/vijay03/cs378-f19) and contributing to a 
virtualization related open-source project is a significant part of the 
course.
I would be interested in contributing a patchset to qemu - possibly a 
self-contained feature or a reasonably complex bug fix that can be 
completed in under a month's time. I did look at both the bugtracker and 
the QEMU Google Summer of Code 2019 page 
[https://wiki.qemu.org/Google_Summer_of_Code_2019] for ideas. However, I 
would be interested in hearing from the community and I would be 
delighted if somebody can be suggest a suitable project !


I am an advanced C programmer with both professional and academic 
background in systems design & implementation - especially OS & 
Networks. Given my background, I feel fairly confident that I can pickup 
the QEMU codebase quickly.


Eagerly looking forward to hearing from the community !

Thanks,
Rajath Shashidhara




Re: [PATCH v14 04/11] numa: Extend CLI to provide initiator information for numa nodes

2019-11-06 Thread Tao Xu

On 11/7/2019 4:29 AM, Eric Blake wrote:

On 10/28/19 2:52 AM, Tao Xu wrote:

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.

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.

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




+++ b/qapi/machine.json
@@ -463,6 +463,13 @@
   # @memdev: memory backend object.  If specified for one node,
   #  it must be specified for all nodes.
   #
+# @initiator: defined in ACPI 6.3 Chapter 5.2.27.3 Table 5-145,
+# points to the nodeid which has the memory controller
+# responsible for this NUMA node. This field provides
+# additional information as to the initiator node that
+# is closest (as in directly attached) to this node, and
+# therefore has the best performance (since 4.2)
+#


I'm sad to say, but we've now missed soft freeze for 4.2.  This feels
like enough of a feature that we'll probably have to defer the series to
the 5.0 release, which will have ripple effects to your patches.


OK, I will change the version flag.



Re: [RFC v2 11/14] linux-headers/kvm.h: add capability to forward hypercall

2019-11-06 Thread Guoheyi




On 2019/11/7 1:55, Cornelia Huck wrote:

On Tue, 5 Nov 2019 17:10:53 +0800
Heyi Guo  wrote:


To keep backward compatibility, we add new KVM capability
"KVM_CAP_FORWARD_HYPERCALL" to probe whether KVM supports forwarding
hypercall to userspace.

The capability should be enabled explicitly, for we don't want user
space application to deal with unexpected hypercall exits. After
enabling this cap, all HVC calls unhandled by kvm will be forwarded to
user space.

Signed-off-by: Heyi Guo 
Cc: Peter Maydell 
Cc: "Michael S. Tsirkin" 
Cc: Cornelia Huck 
Cc: Paolo Bonzini 
Cc: Dave Martin 
Cc: Marc Zyngier 
Cc: Mark Rutland 
Cc: James Morse 
---
  linux-headers/linux/kvm.h |  1 +
  target/arm/sdei.c | 16 
  target/arm/sdei.h |  2 ++
  3 files changed, 19 insertions(+)

diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index 3d9b18f7f8..36c9b3859f 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -1000,6 +1000,7 @@ struct kvm_ppc_resize_hpt {
  #define KVM_CAP_PMU_EVENT_FILTER 173
  #define KVM_CAP_ARM_IRQ_LINE_LAYOUT_2 174
  #define KVM_CAP_HYPERV_DIRECT_TLBFLUSH 175
+#define KVM_CAP_FORWARD_HYPERCALL 176
  
  #ifdef KVM_CAP_IRQ_ROUTING

Is this cap upstream already? I would have thought your header sync
would have brought it in, then. (Saying this, that header sync looks
awfully small.)

If it is not upstream yet, please split off this hunk into a separate
patch -- it's a bit annoying, but makes life easier for merging.
No, it is not upstream yet. The whole framework and interfaces between 
KVM and qemu are still under discussion. I'll keep in mind of this when 
moving forward to next steps...


Thanks,
HG



.







Re: [RFC v2 02/14] standard-headers: import arm_sdei.h

2019-11-06 Thread Guoheyi




On 2019/11/7 1:52, Cornelia Huck wrote:

On Tue, 5 Nov 2019 17:10:44 +0800
Heyi Guo  wrote:


Import Linux header file include/uapi/linux/arm_sdei.h from kernel v5.4-rc5.

This is to prepare for qemu SDEI emulation.

Signed-off-by: Heyi Guo 
Cc: Peter Maydell 
Cc: Dave Martin 
Cc: Marc Zyngier 
Cc: Mark Rutland 
Cc: James Morse 
Cc: "Michael S. Tsirkin" 
Cc: Cornelia Huck 
Cc: Paolo Bonzini 
---

Notes:
 v2:
 - Import arm_sdei.h by running update-linux-headers.sh

  include/standard-headers/linux/arm_sdei.h | 73 +++
  1 file changed, 73 insertions(+)
  create mode 100644 include/standard-headers/linux/arm_sdei.h

Just a remark that I find it a bit odd that that a header that looks
arm-specific is in the generic linux/ directory (already in the kernel,
I know.) Is this for sharing between arm and arm64, maybe?
I don't think arm platforms will use this header. In section 4.1 of SDEI 
spec, it says " Both the client and dispatcher of SDEI must execute in 
AArch64 state."

So shall we move it to include/standard-headers/asm-arm64/?

Thanks,
HG




.







Re: [PATCH v14 01/11] util/cutils: Add qemu_strtotime_ns()

2019-11-06 Thread Tao Xu

On 11/7/2019 3:56 AM, Eduardo Habkost wrote:

On Mon, Oct 28, 2019 at 03:52:10PM +0800, Tao Xu wrote:

To convert strings with time suffixes to numbers, support time unit are
"ns" for nanosecond, "us" for microsecond, "ms" for millisecond or "s"
for second. Add test for qemu_strtotime_ns, test the input of basic,
time suffixes, float, invaild, trailing and overflow.

Signed-off-by: Tao Xu 
---

Changes in 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)


Suggestion for the next version: if you are refactoring existing
do_strtosz() code, please refactor it in one patch, and add new
functionality in another patch.

Thank you for your suggestions and comments blew. I will improve in next 
version.



---
  include/qemu/cutils.h |   1 +
  tests/test-cutils.c   | 204 ++
  util/cutils.c |  89 +++---
  3 files changed, 262 insertions(+), 32 deletions(-)

diff --git a/include/qemu/cutils.h b/include/qemu/cutils.h
index b54c847e0f..ff2b3f4614 100644
--- a/include/qemu/cutils.h
+++ b/include/qemu/cutils.h
@@ -182,5 +182,6 @@ int uleb128_decode_small(const uint8_t *in, uint32_t *n);
   * *str1 is <, == or > than *str2.
   */
  int qemu_pstrcmp0(const char **str1, const char **str2);
+int qemu_strtotime_ns(const char *nptr, const char **end, uint64_t *result);
  
  #endif

diff --git a/tests/test-cutils.c b/tests/test-cutils.c
index 1aa8351520..d6a0824efd 100644
--- a/tests/test-cutils.c
+++ b/tests/test-cutils.c

[...]

+static void test_qemu_strtotime_ns_trailing(void)
+{
+const char *str;
+const char *endptr;
+int err;
+uint64_t res = 0xbaadf00d;
+
+str = "123xxx";
+
+err = qemu_strtotime_ns(str, NULL, );
+g_assert_cmpint(err, ==, -EINVAL);
+
+str = "1msxxx";
+err = qemu_strtotime_ns(str, , );
+g_assert_cmpint(err, ==, 0);
+g_assert_cmpint(res, ==, 100);
+g_assert(endptr == str + 3);
+
+err = qemu_strtotime_ns(str, NULL, );
+g_assert_cmpint(err, ==, -EINVAL);
+}


This is better than the test case in v13, where trailing strings
were not handled consistently.  Good.

[...]

diff --git a/util/cutils.c b/util/cutils.c
index fd591cadf0..d83825f8b4 100644
--- a/util/cutils.c
+++ b/util/cutils.c
@@ -181,41 +181,38 @@ int fcntl_setfl(int fd, int flag)
  }
  #endif
  
-static int64_t suffix_mul(char suffix, int64_t unit)

-{
-switch (qemu_toupper(suffix)) {
-case 'B':
-return 1;
-case 'K':
-return unit;
-case 'M':
-return unit * unit;
-case 'G':
-return unit * unit * unit;
-case 'T':
-return unit * unit * unit * unit;
-case 'P':
-return unit * unit * unit * unit * unit;
-case 'E':
-return unit * unit * unit * unit * unit * unit;
+static int64_t suffix_mul(const char *suffixes[], int num_suffix,
+  const char *endptr, int *offset, int64_t unit)
+{
+int i, suffix_len;
+int64_t mul = 1;
+
+for (i = 0; i < num_suffix; i++) {
+suffix_len = strlen(suffixes[i]);
+if (strlen(endptr) >= suffix_len &&


Is the strlen(endptr) check here really necessary?



+g_ascii_strncasecmp(suffixes[i], endptr, suffix_len) == 0) {
+*offset = suffix_len;
+return mul;
+}
+mul *= unit;
  }
+
  return -1;
  }
  
  /*

- * Convert string to bytes, allowing either B/b for bytes, K/k for KB,
- * M/m for MB, G/g for GB or T/t for TB. End pointer will be returned
- * in *end, if not NULL. Return -ERANGE on overflow, and -EINVAL on
- * other error.
+ * Convert string according to different suffixes. End pointer will be returned
+ * in *end, if not NULL. Return -ERANGE on overflow, and -EINVAL on other 
error.
   */
-static int do_strtosz(const char *nptr, const char **end,
-  const char default_suffix, int64_t unit,
-  uint64_t *result)
+static int do_strtomul(const char *nptr, const char **end,
+   const char *suffixes[], int num_suffix,
+   const char *default_suffix, int64_t unit,
+   uint64_t *result)
  {
  int retval;
  const char *endptr;
-unsigned char c;
  int mul_required = 0;
+int offset = 0;
  double val, mul, integral, fraction;
  
  retval = qemu_strtod_finite(nptr, , );

@@ -226,12 +223,12 @@ static int do_strtosz(const char *nptr, const char **end,
  if (fraction != 0) {
  mul_required = 1;
  }
-c = *endptr;
-mul = suffix_mul(c, unit);
+
+mul = suffix_mul(suffixes, num_suffix, endptr, , unit);
  if (mul >= 0) {
-endptr++;
+endptr += offset;
  } else {
-mul = suffix_mul(default_suffix, unit);
+mul = suffix_mul(suffixes, num_suffix, default_suffix, , unit);
  assert(mul >= 0);
  

Re: [PATCH] qmp: Reset mon->commands on CHR_EVENT_CLOSED

2019-11-06 Thread no-reply
Patchew URL: https://patchew.org/QEMU/20191106130309.6737-1-jandr...@gmail.com/



Hi,

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

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

  TESTiotest-qcow2: 268
Failures: 060 071 176 184
Failed 4 of 108 iotests
make: *** [check-tests/check-block.sh] Error 1
Traceback (most recent call last):
  File "./tests/docker/docker.py", line 662, in 
sys.exit(main())
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', 
'--label', 'com.qemu.instance.uuid=cb707bce0c3c456d8ecec70aeb08fddc', '-u', 
'1003', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=', 
'-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 
'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', 
'/home/patchew2/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', 
'/var/tmp/patchew-tester-tmp-mxl5_jec/src/docker-src.2019-11-06-19.55.47.20736:/var/tmp/qemu:z,ro',
 'qemu:centos7', '/var/tmp/qemu/run', 'test-quick']' returned non-zero exit 
status 2.
filter=--filter=label=com.qemu.instance.uuid=cb707bce0c3c456d8ecec70aeb08fddc
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-mxl5_jec/src'
make: *** [docker-run-test-quick@centos7] Error 2

real13m1.810s
user0m8.371s


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

[PATCH for 4.2 v1 1/1] riscv/virt: Increase flash size

2019-11-06 Thread Alistair Francis
Coreboot developers have requested that they have at least 32MB of flash
to load binaries. We currently have 32MB of flash, but it is split in
two to allow loading two flash binaries. Let's increase the flash size
from 32MB to 64MB to ensure we have a single region that is 32MB.

No QEMU release has include flash in the RISC-V virt machine, so this
isn't a breaking change.

Signed-off-by: Alistair Francis 
---
 hw/riscv/virt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/riscv/virt.c b/hw/riscv/virt.c
index cc8f311e6b..23f340df19 100644
--- a/hw/riscv/virt.c
+++ b/hw/riscv/virt.c
@@ -62,7 +62,7 @@ static const struct MemmapEntry {
 [VIRT_PLIC] ={  0xc00, 0x400 },
 [VIRT_UART0] =   { 0x1000, 0x100 },
 [VIRT_VIRTIO] =  { 0x10001000,0x1000 },
-[VIRT_FLASH] =   { 0x2000, 0x200 },
+[VIRT_FLASH] =   { 0x2000, 0x400 },
 [VIRT_DRAM] ={ 0x8000,   0x0 },
 [VIRT_PCIE_MMIO] =   { 0x4000,0x4000 },
 [VIRT_PCIE_PIO] ={ 0x0300,0x0001 },
-- 
2.23.0




Re: guest / host buffer sharing ...

2019-11-06 Thread Geoffrey McRae




On 2019-11-06 23:41, Gerd Hoffmann wrote:

On Wed, Nov 06, 2019 at 05:36:22PM +0900, David Stevens wrote:

> (1) The virtio device
> =
>
> Has a single virtio queue, so the guest can send commands to register
> and unregister buffers.  Buffers are allocated in guest ram.  Each buffer
> has a list of memory ranges for the data. Each buffer also has some

Allocating from guest ram would work most of the time, but I think
it's insufficient for many use cases. It doesn't really support things
such as contiguous allocations, allocations from carveouts or <4GB,
protected buffers, etc.


If there are additional constrains (due to gpu hardware I guess)
I think it is better to leave the buffer allocation to virtio-gpu.


The entire point of this for our purposes is due to the fact that we can
not allocate the buffer, it's either provided by the GPU driver or
DirectX. If virtio-gpu were to allocate the buffer we might as well 
forget

all this and continue using the ivshmem device.

Our use case is niche, and the state of things may change if vendors 
like

AMD follow through with their promises and give us SR-IOV on consumer
GPUs, but even then we would still need their support to achieve the 
same

results as the same issue would still be present.

Also don't forget that QEMU already has a non virtio generic device
(IVSHMEM). The only difference is, this device doesn't allow us to 
attain

zero-copy transfers.

Currently IVSHMEM is used by two projects that I am aware of, Looking
Glass and SCREAM. While Looking Glass is solving a problem that is out 
of

scope for QEMU, SCREAM is working around the audio problems in QEMU that
have been present for years now.

While I don't agree with SCREAM being used this way (we really need a
virtio-sound device, and/or intel-hda needs to be fixed), it again is an
example of working around bugs/faults/limitations in QEMU by those of us
that are unable to fix them ourselves and seem to have low priority to 
the

QEMU project.

What we are trying to attain is freedom from dual boot Linux/Windows
systems, not migrate-able enterprise VPS configurations. The Looking
Glass project has brought attention to several other bugs/problems in
QEMU, some of which were fixed as a direct result of this project (i8042
race, AMD NPT).

Unless there is another solution to getting the guest GPUs frame-buffer
back to the host, a device like this will always be required. Since the
landscape could change at any moment, this device should not be a LG
specific device, but rather a generic device to allow for other
workarounds like LG to be developed in the future should they be 
required.


Is it optimal? no
Is there a better solution? not that I am aware of



virtio-gpu can't do that right now, but we have to improve virtio-gpu
memory management for vulkan support anyway.


> properties to carry metadata, some fixed (id, size, application), but

What exactly do you mean by application?


Basically some way to group buffers.  A wayland proxy for example would
add a "application=wayland-proxy" tag to the buffers it creates in the
guest, and the host side part of the proxy could ask qemu (or another
vmm) to notify about all buffers with that tag.  So in case multiple
applications are using the device in parallel they don't interfere with
each other.


> also allow free form (name = value, framebuffers would have
> width/height/stride/format for example).

Is this approach expected to handle allocating buffers with
hardware-specific constraints such as stride/height alignment or
tiling? Or would there need to be some alternative channel for
determining those values and then calculating the appropriate buffer
size?


No parameter negotiation.

cheers,
  Gerd




Re: [QEMU-SECURITY] ide: fix assertion in ide_dma_cb() to prevent qemu DoS from quest

2019-11-06 Thread Alexander Popov
On 06.11.2019 15:05, Michael S. Tsirkin wrote:
> On Thu, Jul 25, 2019 at 08:25:03PM -0400, John Snow wrote:
>>
>>
>> On 7/5/19 10:07 AM, Alexander Popov wrote:
>>> This assertion was introduced in the commit a718978ed58a in July 2015.
>>> It implies that the size of successful DMA transfers handled in
>>> ide_dma_cb() should be multiple of 512 (the size of a sector).
>>>
>>> But guest systems can initiate DMA transfers that don't fit this
>>> requirement. Let's improve the assertion to prevent qemu DoS from quests.
>>>
>>> PoC for Linux that uses SCSI_IOCTL_SEND_COMMAND to perform such an ATA
>>> command and crash qemu:
>>>
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>>
>>> #define CMD_SIZE 2048
>>>
>>> struct scsi_ioctl_cmd_6 {
>>> unsigned int inlen;
>>> unsigned int outlen;
>>> unsigned char cmd[6];
>>> unsigned char data[];
>>> };
>>>
>>> int main(void)
>>> {
>>> intptr_t fd = 0;
>>> struct scsi_ioctl_cmd_6 *cmd = NULL;
>>>
>>> cmd = malloc(CMD_SIZE);
>>> if (!cmd) {
>>> perror("[-] malloc");
>>> return 1;
>>> }
>>>
>>> memset(cmd, 0, CMD_SIZE);
>>> cmd->inlen = 1337;
>>> cmd->cmd[0] = READ_6;
>>>
>>> fd = open("/dev/sg0", O_RDONLY);
>>> if (fd == -1) {
>>> perror("[-] opening sg");
>>> return 1;
>>> }
>>>
>>> printf("[+] sg0 is opened\n");
>>>
>>> printf("[.] qemu should break here:\n");
>>> fflush(stdout);
>>> ioctl(fd, SCSI_IOCTL_SEND_COMMAND, cmd);
>>> printf("[-] qemu didn't break\n");
>>>
>>> free(cmd);
>>>
>>> return 1;
>>> }
>>>
>>> Signed-off-by: Alexander Popov 
>>> ---
>>>  hw/ide/core.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/hw/ide/core.c b/hw/ide/core.c
>>> index 6afadf8..304fe69 100644
>>> --- a/hw/ide/core.c
>>> +++ b/hw/ide/core.c
>>> @@ -868,7 +868,7 @@ static void ide_dma_cb(void *opaque, int ret)
>>>  
>>>  sector_num = ide_get_sector(s);
>>>  if (n > 0) {
>>> -assert(n * 512 == s->sg.size);
>>> +assert(n == s->sg.size / 512);
>>>  dma_buf_commit(s, s->sg.size);
>>>  sector_num += n;
>>>  ide_set_sector(s, sector_num);
>>>
>>
>> Oh, this is fun.
>>
>> So you're actually requesting 131072 bytes (256 sectors) but you're
>> giving it far too short of a PRDT.
>>
>> But ... the prepare_buf callback got anything at all, so it was happy to
>> proceed, but the callback chokes over the idea that the SGlist wasn't
>> formatted correctly -- it can't deal with partial tails.
>>
>> I think it might be the case that the sglist needs to be allowed to have
>> an unaligned tail, and then the second trip to the dma_cb when there
>> isn't any more regions in the PRDT to add to the SGList to transfer at
>> least a single sector -- but the IDE state machine still has sectors to
>> transfer -- we need to trigger the short PRD clause.
>>
>> Papering over it by truncating the tail I think isn't sufficient; there
>> are other problems this exposes.
>>
>> As an emergency patch, it might be better to just do this whenever we
>> see partial tails:
>>
>> prepared = ...prepare_buf(s->bus->dma, s->io_buffer_size);
>> if (prepared % 512) {
>> ide_dma_error(s);
>> return;
>> }
> 
> Do you want to cook up a patch like this then?

Yes, I will take this task and return with a patch.

Thanks!

Best regards,
Alexander


>> I think that prepare_buf does not give unaligned results if you provided
>> *too many* bytes, so the unaligned return only happens when you starve it.
>>
>> I can worry about a proper fix for 4.2+.
>>
>> --js




Re: [PATCH v1 3/3] target/microblaze: Plug temp leak around eval_cond_jmp()

2019-11-06 Thread Alistair Francis
On Wed, Nov 6, 2019 at 6:17 AM Edgar E. Iglesias
 wrote:
>
> From: "Edgar E. Iglesias" 
>
> Plug temp leak around eval_cond_jmp().
>
> Signed-off-by: Edgar E. Iglesias 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  target/microblaze/translate.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/target/microblaze/translate.c b/target/microblaze/translate.c
> index e9ff9e650d..93e22a89ac 100644
> --- a/target/microblaze/translate.c
> +++ b/target/microblaze/translate.c
> @@ -1705,7 +1705,10 @@ void gen_intermediate_code(CPUState *cs, 
> TranslationBlock *tb, int max_insns)
>  dc->tb_flags &= ~D_FLAG;
>  /* If it is a direct jump, try direct chaining.  */
>  if (dc->jmp == JMP_INDIRECT) {
> -eval_cond_jmp(dc, env_btarget, tcg_const_i64(dc->pc));
> +TCGv_i64 tmp_pc = tcg_const_i64(dc->pc);
> +eval_cond_jmp(dc, env_btarget, tmp_pc);
> +tcg_temp_free_i64(tmp_pc);
> +
>  dc->is_jmp = DISAS_JUMP;
>  } else if (dc->jmp == JMP_DIRECT) {
>  t_sync_flags(dc);
> --
> 2.20.1
>
>



Re: [PULL v2 00/13] Linux user for 4.2 patches

2019-11-06 Thread Peter Maydell
On Wed, 6 Nov 2019 at 13:09, Laurent Vivier  wrote:
>
> The following changes since commit 36609b4fa36f0ac934874371874416f7533a5408:
>
>   Merge remote-tracking branch 
> 'remotes/palmer/tags/palmer-for-master-4.2-sf1' into staging (2019-11-02 
> 17:59:03 +)
>
> are available in the Git repository at:
>
>   git://github.com/vivier/qemu.git tags/linux-user-for-4.2-pull-request
>
> for you to fetch changes up to 5849dfe410b3fefec7d54a536cda7ccbf809ebea:
>
>   linux-user/alpha: Set r20 secondary return value (2019-11-06 13:45:05 +0100)
>
> 
> sparc/sparc64 fixes: this doesn't fix debian chroot for me
> but they are a step in the good direction.
> Fix Netlink support.
> Trivial fix for alpha
>
> PULL v2: fix checkpatch warnings
>
> 
>


Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/4.2
for any user-visible changes.

-- PMM



Re: [PATCH v1 2/3] target/microblaze: Plug temp leaks with delay slot setup

2019-11-06 Thread Alistair Francis
On Wed, Nov 6, 2019 at 6:17 AM Edgar E. Iglesias
 wrote:
>
> From: "Edgar E. Iglesias" 
>
> Plug temp leaks with delay slot setup.
>
> Signed-off-by: Edgar E. Iglesias 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  target/microblaze/translate.c | 26 ++
>  1 file changed, 14 insertions(+), 12 deletions(-)
>
> diff --git a/target/microblaze/translate.c b/target/microblaze/translate.c
> index ba143ede5f..e9ff9e650d 100644
> --- a/target/microblaze/translate.c
> +++ b/target/microblaze/translate.c
> @@ -1201,6 +1201,17 @@ static void eval_cond_jmp(DisasContext *dc, TCGv_i64 
> pc_true, TCGv_i64 pc_false)
>  tcg_temp_free_i64(tmp_zero);
>  }
>
> +static void dec_setup_dslot(DisasContext *dc)
> +{
> +TCGv_i32 tmp = tcg_const_i32(dc->type_b && (dc->tb_flags & 
> IMM_FLAG));
> +
> +dc->delayed_branch = 2;
> +dc->tb_flags |= D_FLAG;
> +
> +tcg_gen_st_i32(tmp, cpu_env, offsetof(CPUMBState, bimm));
> +tcg_temp_free_i32(tmp);
> +}
> +
>  static void dec_bcc(DisasContext *dc)
>  {
>  unsigned int cc;
> @@ -1212,10 +1223,7 @@ static void dec_bcc(DisasContext *dc)
>
>  dc->delayed_branch = 1;
>  if (dslot) {
> -dc->delayed_branch = 2;
> -dc->tb_flags |= D_FLAG;
> -tcg_gen_st_i32(tcg_const_i32(dc->type_b && (dc->tb_flags & 
> IMM_FLAG)),
> -  cpu_env, offsetof(CPUMBState, bimm));
> +dec_setup_dslot(dc);
>  }
>
>  if (dec_alu_op_b_is_small_imm(dc)) {
> @@ -1274,10 +1282,7 @@ static void dec_br(DisasContext *dc)
>
>  dc->delayed_branch = 1;
>  if (dslot) {
> -dc->delayed_branch = 2;
> -dc->tb_flags |= D_FLAG;
> -tcg_gen_st_i32(tcg_const_i32(dc->type_b && (dc->tb_flags & 
> IMM_FLAG)),
> -  cpu_env, offsetof(CPUMBState, bimm));
> +dec_setup_dslot(dc);
>  }
>  if (link && dc->rd)
>  tcg_gen_movi_i32(cpu_R[dc->rd], dc->pc);
> @@ -1379,10 +1384,7 @@ static void dec_rts(DisasContext *dc)
>  return;
>  }
>
> -dc->delayed_branch = 2;
> -dc->tb_flags |= D_FLAG;
> -tcg_gen_st_i32(tcg_const_i32(dc->type_b && (dc->tb_flags & IMM_FLAG)),
> -  cpu_env, offsetof(CPUMBState, bimm));
> +dec_setup_dslot(dc);
>
>  if (i_bit) {
>  LOG_DIS("rtid ir=%x\n", dc->ir);
> --
> 2.20.1
>
>



Re: [QEMU-SECURITY] ide: fix assertion in ide_dma_cb() to prevent qemu DoS from quest

2019-11-06 Thread Alexander Popov
On 06.11.2019 15:08, Michael S. Tsirkin wrote:
> On Wed, Nov 06, 2019 at 01:17:51PM +0300, Alexander Popov wrote:
>> On 27.07.2019 00:09, Alexander Popov wrote:
>>> On 26.07.2019 2:25:03 GMT+02:00, John Snow  wrote:
 Oh, this is fun.
>>> ...
 I can worry about a proper fix for 4.2+.
>>>
>>> Hello John,
>>>
>>> Thanks for your letter.
>>>
>>> I double-checked the git history and mailing list, I'm still sure
>>> that my fix for this assertion is correct.
>>
>> Hello!
>>
>> I'm pointing politely to this issue again.
>>
>> It crashes qemu during syzkaller fuzzing.
>>
>> It's really annoying to manually apply the fix against it to qemu.
> 
> I understand. Maybe the fuzzer can be taught to skip the
> specific issue for now?

Michael, thanks for your reply.

Yes, of course. You just forbid the fuzzer to use /dev/sg in the guest.
But I would rather fix the issue.

--
Best regards,
Alexander




[Bug 1851547] Re: qemu 4 crashes with this parameter attached -usb -device usb-host, hostbus=1, hostaddr=7 \

2019-11-06 Thread Marietto
problem resolved changing this line :

-usb -device usb-host,hostbus=1,hostaddr=7 \

with this :

-usb -device usb-host,hostbus=1,hostaddr=8 \

it works with qemu 4.

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

Title:
  qemu 4 crashes with this parameter attached -usb -device usb-
  host,hostbus=1,hostaddr=7 \

Status in QEMU:
  New

Bug description:
  Hello.

  qemu / kvm does not start anymore after upgrading ubuntu from 19.04 to
  19.10 and qemu from 3 to 4,as you can see below. what can I do ?

  root@ziomario-Z390-AORUS-PRO:/home/ziomario/Scrivania/OS-KVM# ./boot-
  OS-HSP2.sh

  > qemu-system-x86_64: /build/qemu-
  UryNDZ/qemu-4.0+dfsg/hw/usb/core.c:720: usb_ep_get: asserzione "dev !=
  NULL" non riuscita.

  ./boot-OS-HSP2.sh: riga 40: 26312 Annullato (core dump creato) qemu-
  system-x86_64 -enable-kvm -m 16000 -cpu
  Penryn,kvm=on,vendor=GenuineIntel,+invtsc,vmware-cpuid-
  freq=on,$MY_OPTIONS -machine pc-q35-2.9 -smp 4,cores=2 -vga none
  -device vfio-pci,host=01:00.0,bus=pcie.0,multifunction=on -device
  vfio-pci,host=01:00.1,bus=pcie.0 -device vfio-
  pci,host=01:00.2,bus=pcie.0 -device vfio-pci,host=01:00.3,bus=pcie.0
  -usb -device usb-host,hostbus=1,hostaddr=7 -drive
  if=pflash,format=raw,readonly,file=$OVMF/OVMF_CODE.fd -drive
  if=pflash,format=raw,file=$OVMF/OVMF_VARS-1024x768.fd -smbios type=2
  -device ich9-ahci,id=sata -drive
  id=Clover,if=none,snapshot=on,format=qcow2,file=./'Mo/CloverNG.qcow2'
  -device ide-hd,bus=sata.2,drive=Clover -device ide-
  hd,bus=sata.3,drive=InstallMedia -drive
  id=InstallMedia,if=none,file=BaseSystemHS.img,format=raw -drive
  id=BsdHDD,if=none,file=/dev/sdg,format=raw -device ide-
  hd,bus=sata.4,drive=BsdHDD -netdev
  tap,id=net0,ifname=tap0,script=no,downscript=no -device
  e1000-82545em,netdev=net0,id=net0,mac=52:54:00:c9:18:27 -monitor stdio

  It seems that this line is not good anymore (it worked with qemu 3.x)
  :

  -usb -device usb-host,hostbus=1,hostaddr=7 \

  when I removed it,it works. But I need that. With what can I change it
  ? You can reproduce that upgrading ubuntu 19.04 to 19.10 because in
  that way also qemu will be upgraded from 3 to 4. These are the
  packages that I'm using :

  root@ziomario-Z390-AORUS-PRO:/home/ziomario# qemu-system-x86_64 --version
  QEMU emulator version 4.0.0 (Debian 1:4.0+dfsg-0ubuntu9)

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



Re: [PATCH v1 1/3] target/microblaze: Plug temp leaks for loads/stores

2019-11-06 Thread Alistair Francis
On Wed, Nov 6, 2019 at 6:14 AM Edgar E. Iglesias
 wrote:
>
> From: "Edgar E. Iglesias" 
>
> Plug TCG temp leaks for loads/stores.
>
> Signed-off-by: Edgar E. Iglesias 

Reviewed-by: Alistair Francis 

Alistair

> ---
>  target/microblaze/translate.c | 30 --
>  1 file changed, 24 insertions(+), 6 deletions(-)
>
> diff --git a/target/microblaze/translate.c b/target/microblaze/translate.c
> index 761f535357..ba143ede5f 100644
> --- a/target/microblaze/translate.c
> +++ b/target/microblaze/translate.c
> @@ -967,12 +967,14 @@ static void dec_load(DisasContext *dc)
> 10 -> 10
> 11 -> 00 */
>  TCGv low = tcg_temp_new();
> +TCGv t3 = tcg_const_tl(3);
>
>  tcg_gen_andi_tl(low, addr, 3);
> -tcg_gen_sub_tl(low, tcg_const_tl(3), low);
> +tcg_gen_sub_tl(low, t3, low);
>  tcg_gen_andi_tl(addr, addr, ~3);
>  tcg_gen_or_tl(addr, addr, low);
>  tcg_temp_free(low);
> +tcg_temp_free(t3);
>  break;
>  }
>
> @@ -1006,9 +1008,16 @@ static void dec_load(DisasContext *dc)
>  tcg_gen_qemu_ld_i32(v, addr, mem_index, mop);
>
>  if ((dc->cpu->env.pvr.regs[2] & PVR2_UNALIGNED_EXC_MASK) && size > 1) {
> +TCGv_i32 t0 = tcg_const_i32(0);
> +TCGv_i32 treg = tcg_const_i32(dc->rd);
> +TCGv_i32 tsize = tcg_const_i32(size - 1);
> +
>  tcg_gen_movi_i64(cpu_SR[SR_PC], dc->pc);
> -gen_helper_memalign(cpu_env, addr, tcg_const_i32(dc->rd),
> -tcg_const_i32(0), tcg_const_i32(size - 1));
> +gen_helper_memalign(cpu_env, addr, treg, t0, tsize);
> +
> +tcg_temp_free_i32(t0);
> +tcg_temp_free_i32(treg);
> +tcg_temp_free_i32(tsize);
>  }
>
>  if (ex) {
> @@ -1100,12 +1109,14 @@ static void dec_store(DisasContext *dc)
> 10 -> 10
> 11 -> 00 */
>  TCGv low = tcg_temp_new();
> +TCGv t3 = tcg_const_tl(3);
>
>  tcg_gen_andi_tl(low, addr, 3);
> -tcg_gen_sub_tl(low, tcg_const_tl(3), low);
> +tcg_gen_sub_tl(low, t3, low);
>  tcg_gen_andi_tl(addr, addr, ~3);
>  tcg_gen_or_tl(addr, addr, low);
>  tcg_temp_free(low);
> +tcg_temp_free(t3);
>  break;
>  }
>
> @@ -1124,6 +1135,10 @@ static void dec_store(DisasContext *dc)
>
>  /* Verify alignment if needed.  */
>  if ((dc->cpu->env.pvr.regs[2] & PVR2_UNALIGNED_EXC_MASK) && size > 1) {
> +TCGv_i32 t1 = tcg_const_i32(1);
> +TCGv_i32 treg = tcg_const_i32(dc->rd);
> +TCGv_i32 tsize = tcg_const_i32(size - 1);
> +
>  tcg_gen_movi_i64(cpu_SR[SR_PC], dc->pc);
>  /* FIXME: if the alignment is wrong, we should restore the value
>   *in memory. One possible way to achieve this is to probe
> @@ -1131,8 +1146,11 @@ static void dec_store(DisasContext *dc)
>   *the alignment checks in between the probe and the mem
>   *access.
>   */
> -gen_helper_memalign(cpu_env, addr, tcg_const_i32(dc->rd),
> -tcg_const_i32(1), tcg_const_i32(size - 1));
> +gen_helper_memalign(cpu_env, addr, treg, t1, tsize);
> +
> +tcg_temp_free_i32(t1);
> +tcg_temp_free_i32(treg);
> +tcg_temp_free_i32(tsize);
>  }
>
>  if (ex) {
> --
> 2.20.1
>
>



[PATCH] WHPX: support for xcr0

2019-11-06 Thread Sunil Muthuswamy
Support for xcr0 to be able to enable xsave/xrstor. This by itself
is not sufficient to enable xsave/xrstor. WHPX XSAVE API's also
needs to be hooked up.
---
 target/i386/whp-dispatch.h |  3 ++
 target/i386/whpx-all.c | 88 ++
 2 files changed, 91 insertions(+)

diff --git a/target/i386/whp-dispatch.h b/target/i386/whp-dispatch.h
index 23791fbb47..b5d56b22a3 100644
--- a/target/i386/whp-dispatch.h
+++ b/target/i386/whp-dispatch.h
@@ -6,6 +6,9 @@
 #include 
 #include 
 
+/* This should eventually come from the Windows SDK */
+#define WHV_E_UNKNOWN_PROPERTY 0x80370302
+
 #define LIST_WINHVPLATFORM_FUNCTIONS(X) \
   X(HRESULT, WHvGetCapability, (WHV_CAPABILITY_CODE CapabilityCode, VOID* 
CapabilityBuffer, UINT32 CapabilityBufferSizeInBytes, UINT32* 
WrittenSizeInBytes)) \
   X(HRESULT, WHvCreatePartition, (WHV_PARTITION_HANDLE* Partition)) \
diff --git a/target/i386/whpx-all.c b/target/i386/whpx-all.c
index ed95105eae..1abaac70db 100644
--- a/target/i386/whpx-all.c
+++ b/target/i386/whpx-all.c
@@ -161,10 +161,15 @@ struct whpx_vcpu {
 static bool whpx_allowed;
 static bool whp_dispatch_initialized;
 static HMODULE hWinHvPlatform, hWinHvEmulation;
+static WHV_PROCESSOR_XSAVE_FEATURES whpx_xsave_cap;
 
 struct whpx_state whpx_global;
 struct WHPDispatch whp_dispatch;
 
+static bool whpx_has_xsave(void)
+{
+return whpx_xsave_cap.XsaveSupport;
+}
 
 /*
  * VP support
@@ -216,6 +221,28 @@ static SegmentCache whpx_seg_h2q(const 
WHV_X64_SEGMENT_REGISTER *hs)
 return qs;
 }
 
+/* X64 Extended Control Registers */
+static void whpx_set_xcrs(CPUState *cpu)
+{
+struct CPUX86State *env = (CPUArchState *)(cpu->env_ptr);
+HRESULT hr;
+struct whpx_state *whpx = _global;
+WHV_REGISTER_VALUE xcr0;
+WHV_REGISTER_NAME xcr0_name = WHvX64RegisterXCr0;
+
+if (!whpx_has_xsave()) {
+return;
+}
+
+/* Only xcr0 is supported by the hypervisor currently */
+xcr0.Reg64 = env->xcr0;
+hr = whp_dispatch.WHvSetVirtualProcessorRegisters(
+whpx->partition, cpu->cpu_index, _name, 1, );
+if (FAILED(hr)) {
+error_report("WHPX: Failed to set register xcr0, hr=%08lx", hr);
+}
+}
+
 static void whpx_set_registers(CPUState *cpu)
 {
 struct whpx_state *whpx = _global;
@@ -291,6 +318,12 @@ static void whpx_set_registers(CPUState *cpu)
 
 /* 8 Debug Registers - Skipped */
 
+/*
+ * Extended control registers needs to be handled separately depending
+ * on whether xsave is supported/enabled or not.
+ */
+whpx_set_xcrs(cpu);
+
 /* 16 XMM registers */
 assert(whpx_register_names[idx] == WHvX64RegisterXmm0);
 idx_next = idx + 16;
@@ -380,6 +413,30 @@ static void whpx_set_registers(CPUState *cpu)
 return;
 }
 
+/* X64 Extended Control Registers */
+static void whpx_get_xcrs(CPUState *cpu)
+{
+struct CPUX86State *env = (CPUArchState *)(cpu->env_ptr);
+HRESULT hr;
+struct whpx_state *whpx = _global;
+WHV_REGISTER_VALUE xcr0;
+WHV_REGISTER_NAME xcr0_name = WHvX64RegisterXCr0;
+
+if (!whpx_has_xsave()) {
+return;
+}
+
+/* Only xcr0 is supported by the hypervisor currently */
+hr = whp_dispatch.WHvGetVirtualProcessorRegisters(
+whpx->partition, cpu->cpu_index, _name, 1, );
+if (FAILED(hr)) {
+error_report("WHPX: Failed to get register xcr0, hr=%08lx", hr);
+return;
+}
+
+env->xcr0 = xcr0.Reg64;
+}
+
 static void whpx_get_registers(CPUState *cpu)
 {
 struct whpx_state *whpx = _global;
@@ -457,6 +514,12 @@ static void whpx_get_registers(CPUState *cpu)
 
 /* 8 Debug Registers - Skipped */
 
+/*
+ * Extended control registers needs to be handled separately depending
+ * on whether xsave is supported/enabled or not.
+ */
+whpx_get_xcrs(cpu);
+
 /* 16 XMM registers */
 assert(whpx_register_names[idx] == WHvX64RegisterXmm0);
 idx_next = idx + 16;
@@ -1395,6 +1458,31 @@ static int whpx_accel_init(MachineState *ms)
 goto error;
 }
 
+/*
+ * Query the XSAVE capability of the partition. Any error here is not
+ * considered fatal.
+ */
+hr = whp_dispatch.WHvGetPartitionProperty(
+whpx->partition,
+WHvPartitionPropertyCodeProcessorXsaveFeatures,
+_xsave_cap,
+sizeof(whpx_xsave_cap),
+_cap_size);
+
+/*
+ * Windows version which don't support this property will return with the
+ * specific error code.
+ */
+if (FAILED(hr) && hr != WHV_E_UNKNOWN_PROPERTY) {
+error_report("WHPX: Failed to query XSAVE capability, hr=%08lx", hr);
+}
+
+if (whpx_has_xsave()) {
+printf("WHPX: Partition XSAVE capable\n");
+} else {
+printf("WHPX: Partition is not XSAVE capable\n");
+}
+
 memset(, 0, sizeof(WHV_PARTITION_PROPERTY));
 prop.ProcessorCount = ms->smp.cpus;
 hr = whp_dispatch.WHvSetPartitionProperty(
-- 
2.16.4




Re: [PULL v2 00/21] hw/i386/pc: Split PIIX3 southbridge from i440FX northbridge

2019-11-06 Thread Peter Maydell
On Tue, 5 Nov 2019 at 22:55, Philippe Mathieu-Daudé  wrote:
>
> Hi Peter,
>
> This is a X86/MIPS pull, Paolo and Aleksandar are OK I send it:
>
>   https://lists.gnu.org/archive/html/qemu-devel/2019-10/msg04959.html
>
> Since v1: Fixed the Kconfig bug you reported here:
>
>   https://lists.gnu.org/archive/html/qemu-devel/2019-11/msg00125.html
>
> This is not a new feature, and the series was already posted before
> soft freeze.
>
> Regards,
>
> Phil.
>
> The following changes since commit 412fbef3d076c43e56451bacb28c4544858c66a3:
>
>   Merge remote-tracking branch 
> 'remotes/philmd-gitlab/tags/fw_cfg-next-pull-request' into staging 
> (2019-11-05 20:17:11 +)
>
> are available in the Git repository at:
>
>   https://gitlab.com/philmd/qemu.git tags/mips-next-20191105
>
> for you to fetch changes up to 48bc99a09cb160a3a2612c4bd5a8a225ed7bf6fb:
>
>   hw/pci-host/i440fx: Remove the last PIIX3 traces (2019-11-05 23:33:12 +0100)
>
> 
> The i440FX northbridge is only used by the PC machine, while the
> PIIX southbridge is also used by the Malta MIPS machine.
>
> Split the PIIX3 southbridge from i440FX northbridge.
>
> 


Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/4.2
for any user-visible changes.

-- PMM



Re: [PATCH] global: Squash 'the the'

2019-11-06 Thread David Gibson
On Mon, Nov 04, 2019 at 06:52:02PM +, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert" 
> 
> 'the' has a tendency to double up; squash them back down.
> 
> Signed-off-by: Dr. David Alan Gilbert 
> ---
>  disas/libvixl/vixl/invalset.h   | 2 +-
>  docs/interop/pr-helper.rst  | 2 +-


>  docs/specs/ppc-spapr-hotplug.txt| 2 +-
>  docs/specs/ppc-xive.rst | 2 +-

These two,
Acked-by: David Gibson 


>  docs/specs/tpm.txt  | 2 +-
>  include/hw/xen/interface/io/blkif.h | 2 +-
>  scripts/dump-guest-memory.py| 2 +-
>  7 files changed, 7 insertions(+), 7 deletions(-)

> 
> diff --git a/disas/libvixl/vixl/invalset.h b/disas/libvixl/vixl/invalset.h
> index ffdc0237b4..ef5e49d6fe 100644
> --- a/disas/libvixl/vixl/invalset.h
> +++ b/disas/libvixl/vixl/invalset.h
> @@ -102,7 +102,7 @@ template class InvalSet {
>size_t size() const;
>  
>// Returns true if no elements are stored in the set.
> -  // Note that this does not mean the the backing storage is empty: it can 
> still
> +  // Note that this does not mean the backing storage is empty: it can still
>// contain invalid elements.
>bool empty() const;
>  
> diff --git a/docs/interop/pr-helper.rst b/docs/interop/pr-helper.rst
> index 9f76d5bcf9..e926f0a6c9 100644
> --- a/docs/interop/pr-helper.rst
> +++ b/docs/interop/pr-helper.rst
> @@ -10,7 +10,7 @@ can delegate implementation of persistent reservations to 
> an external
>  restricting access to block devices to specific initiators in a shared
>  storage setup.
>  
> -For a more detailed reference please refer the the SCSI Primary
> +For a more detailed reference please refer to the SCSI Primary
>  Commands standard, specifically the section on Reservations and the
>  "PERSISTENT RESERVE IN" and "PERSISTENT RESERVE OUT" commands.
>  
> diff --git a/docs/specs/ppc-spapr-hotplug.txt 
> b/docs/specs/ppc-spapr-hotplug.txt
> index cc7833108e..859d52cce6 100644
> --- a/docs/specs/ppc-spapr-hotplug.txt
> +++ b/docs/specs/ppc-spapr-hotplug.txt
> @@ -385,7 +385,7 @@ Each LMB list entry consists of the following elements:
>is used to retrieve the right associativity list to be used for this
>LMB.
>  - A 32bit flags word. The bit at bit position 0x0008 defines whether
> -  the LMB is assigned to the the partition as of boot time.
> +  the LMB is assigned to the partition as of boot time.
>  
>  ibm,dynamic-memory-v2
>  
> diff --git a/docs/specs/ppc-xive.rst b/docs/specs/ppc-xive.rst
> index 148d57eb6a..83d43f658b 100644
> --- a/docs/specs/ppc-xive.rst
> +++ b/docs/specs/ppc-xive.rst
> @@ -163,7 +163,7 @@ Interrupt Priority Register (PIPR) is also updated using 
> the IPB. This
>  register represent the priority of the most favored pending
>  notification.
>  
> -The PIPR is then compared to the the Current Processor Priority
> +The PIPR is then compared to the Current Processor Priority
>  Register (CPPR). If it is more favored (numerically less than), the
>  CPU interrupt line is raised and the EO bit of the Notification Source
>  Register (NSR) is updated to notify the presence of an exception for
> diff --git a/docs/specs/tpm.txt b/docs/specs/tpm.txt
> index 5d8c26b1ad..9c8cca042d 100644
> --- a/docs/specs/tpm.txt
> +++ b/docs/specs/tpm.txt
> @@ -89,7 +89,7 @@ TPM upon reboot. The PPI specification defines the 
> operation requests and the
>  actions the firmware has to take. The system administrator passes the 
> operation
>  request number to the firmware through an ACPI interface which writes this
>  number to a memory location that the firmware knows. Upon reboot, the 
> firmware
> -finds the number and sends commands to the the TPM. The firmware writes the 
> TPM
> +finds the number and sends commands to the TPM. The firmware writes the TPM
>  result code and the operation request number to a memory location that ACPI 
> can
>  read from and pass the result on to the administrator.
>  
> diff --git a/include/hw/xen/interface/io/blkif.h 
> b/include/hw/xen/interface/io/blkif.h
> index 8b1be50ce8..d07fa1e078 100644
> --- a/include/hw/xen/interface/io/blkif.h
> +++ b/include/hw/xen/interface/io/blkif.h
> @@ -341,7 +341,7 @@
>   *  access (even when it should be read-only). If the frontend hits the
>   *  maximum number of allowed persistently mapped grants, it can fallback
>   *  to non persistent mode. This will cause a performance degradation,
> - *  since the the backend driver will still try to map those grants
> + *  since the backend driver will still try to map those grants
>   *  persistently. Since the persistent grants protocol is compatible with
>   *  the previous protocol, a frontend driver can choose to work in
>   *  persistent mode even when the backend doesn't support it.
> diff --git a/scripts/dump-guest-memory.py b/scripts/dump-guest-memory.py
> index 2c587cbefc..9371e45813 100644
> --- a/scripts/dump-guest-memory.py
> +++ b/scripts/dump-guest-memory.py
> @@ -170,7 

Re: [PATCH v14 03/11] tests: Add test for QAPI builtin type time

2019-11-06 Thread Eduardo Habkost
On Mon, Oct 28, 2019 at 03:52:12PM +0800, Tao Xu wrote:
> Add tests for time input such as zero, around limit of precision,
> signed upper limit, actual upper limit, beyond limits, time suffixes,
> and etc.
> 
> Signed-off-by: Tao Xu 
> ---
[...]
> +/* Close to signed upper limit 0x7c00 (53 msbs set) */
> +qdict = keyval_parse("time1=9223372036854774784," /* 7c00 */
> + "time2=9223372036854775295", /* 7dff */
> + NULL, _abort);
> +v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
> +qobject_unref(qdict);
> +visit_start_struct(v, NULL, NULL, 0, _abort);
> +visit_type_time(v, "time1", , _abort);
> +g_assert_cmphex(time, ==, 0x7c00);
> +visit_type_time(v, "time2", , _abort);
> +g_assert_cmphex(time, ==, 0x7c00);

I'm confused by this test case and the one below[1].  Are these
known bugs?  Shouldn't we document them as known bugs?

> +visit_check_struct(v, _abort);
> +visit_end_struct(v, NULL);
> +visit_free(v);
> +
> +/* Close to actual upper limit 0xf800 (53 msbs set) */
> +qdict = keyval_parse("time1=18446744073709549568," /* f800 */
> + "time2=18446744073709550591", /* fbff */
> + NULL, _abort);
> +v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
> +qobject_unref(qdict);
> +visit_start_struct(v, NULL, NULL, 0, _abort);
> +visit_type_time(v, "time1", , _abort);
> +g_assert_cmphex(time, ==, 0xf800);
> +visit_type_time(v, "time2", , _abort);
> +g_assert_cmphex(time, ==, 0xf800);

[1]

> +visit_check_struct(v, _abort);
> +visit_end_struct(v, NULL);
> +visit_free(v);
[...]

-- 
Eduardo




Re: [PATCH v14 04/11] numa: Extend CLI to provide initiator information for numa nodes

2019-11-06 Thread Eric Blake

On 10/28/19 2:52 AM, Tao Xu wrote:

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.

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.

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




+++ b/qapi/machine.json
@@ -463,6 +463,13 @@
  # @memdev: memory backend object.  If specified for one node,
  #  it must be specified for all nodes.
  #
+# @initiator: defined in ACPI 6.3 Chapter 5.2.27.3 Table 5-145,
+# points to the nodeid which has the memory controller
+# responsible for this NUMA node. This field provides
+# additional information as to the initiator node that
+# is closest (as in directly attached) to this node, and
+# therefore has the best performance (since 4.2)
+#


I'm sad to say, but we've now missed soft freeze for 4.2.  This feels 
like enough of a feature that we'll probably have to defer the series to 
the 5.0 release, which will have ripple effects to your patches.


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




Re: [PATCH 0/6] migration/postcopy: enable compress during postcopy

2019-11-06 Thread Dr. David Alan Gilbert
* Wei Yang (richardw.y...@linux.intel.com) wrote:
> This patch set tries enable compress during postcopy.
> 
> postcopy requires to place a whole host page, while migration thread migrate
> memory in target page size. This makes postcopy need to collect all target
> pages in one host page before placing via userfaultfd.
> 
> To enable compress during postcopy, there are two problems to solve:
> 
> 1. Random order for target page arrival
> 2. Target pages in one host page arrives without interrupt by target
>page from other host page
> 
> The first one is handled by counting the number of target pages arrived
> instead of the last target page arrived.
> 
> The second one is handled by:
> 
> 1. Flush compress thread for each host page
> 2. Wait for decompress thread for before placing host page
> 
> With the combination of these two changes, compress is enabled during
> postcopy.

What have you tested this with? 2MB huge pages I guess?

Dave

> Wei Yang (6):
>   migration/postcopy: reduce memset when it is zero page and
> matches_target_page_size
>   migration/postcopy: wait for decompress thread in precopy
>   migration/postcopy: count target page number to decide the
> place_needed
>   migration/postcopy: set all_zero to true on the first target page
>   migration/postcopy: enable random order target page arrival
>   migration/postcopy: enable compress during postcopy
> 
>  migration/migration.c | 11 
>  migration/ram.c   | 65 ++-
>  2 files changed, 45 insertions(+), 31 deletions(-)
> 
> -- 
> 2.17.1
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK




Re: [PATCH 5/6] migration/postcopy: enable random order target page arrival

2019-11-06 Thread Dr. David Alan Gilbert
* Wei Yang (richardw.y...@linux.intel.com) wrote:
> After using number of target page received to track one host page, we
> could have the capability to handle random order target page arrival in
> one host page.
> 
> This is a preparation for enabling compress during postcopy.
> 
> Signed-off-by: Wei Yang 
> ---
>  migration/ram.c | 16 +++-
>  1 file changed, 3 insertions(+), 13 deletions(-)
> 
> diff --git a/migration/ram.c b/migration/ram.c
> index b5759793a9..da0596411c 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -4015,7 +4015,6 @@ static int ram_load_postcopy(QEMUFile *f)
>  MigrationIncomingState *mis = migration_incoming_get_current();
>  /* Temporary page that is later 'placed' */
>  void *postcopy_host_page = mis->postcopy_tmp_page;
> -void *last_host = NULL;
>  bool all_zero = false;
>  int target_pages = 0;
>  
> @@ -4062,24 +4061,15 @@ static int ram_load_postcopy(QEMUFile *f)
>   * that's moved into place later.
>   * The migration protocol uses,  possibly smaller, target-pages
>   * however the source ensures it always sends all the components
> - * of a host page in order.
> + * of a host page in one chunk.
>   */
>  page_buffer = postcopy_host_page +
>((uintptr_t)host & (block->page_size - 1));
>  /* If all TP are zero then we can optimise the place */
>  if (target_pages == 1) {
>  all_zero = true;
> -} else {
> -/* not the 1st TP within the HP */
> -if (host != (last_host + TARGET_PAGE_SIZE)) {
> -error_report("Non-sequential target page %p/%p",
> -  host, last_host);
> -ret = -EINVAL;
> -break;
> -}

I think this is losing more protection than needed.
I think you can still protect against a page from a different host-page
arriving until we've placed the current host-page.
So something like:

if (((uintptr_t)host & ~(block->page_size - 1)) !=
last_host)

and then set last_host to the start of the host page.

Then you'll check if that flush is really working.

Dave

>  }
>  
> -
>  /*
>   * If it's the last part of a host page then we place the host
>   * page
> @@ -4090,7 +4080,6 @@ static int ram_load_postcopy(QEMUFile *f)
>  }
>  place_source = postcopy_host_page;
>  }
> -last_host = host;
>  
>  switch (flags & ~RAM_SAVE_FLAG_CONTINUE) {
>  case RAM_SAVE_FLAG_ZERO:
> @@ -4143,7 +4132,8 @@ static int ram_load_postcopy(QEMUFile *f)
>  
>  if (!ret && place_needed) {
>  /* This gets called at the last target page in the host page */
> -void *place_dest = host + TARGET_PAGE_SIZE - block->page_size;
> +void *place_dest = (void *)QEMU_ALIGN_DOWN((unsigned long)host,
> +   block->page_size);
>  
>  if (all_zero) {
>  ret = postcopy_place_page_zero(mis, place_dest,
> -- 
> 2.17.1
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK




Re: [PATCH 4/6] migration/postcopy: set all_zero to true on the first target page

2019-11-06 Thread Dr. David Alan Gilbert
* Wei Yang (richardw.y...@linux.intel.com) wrote:
> For the first target page, all_zero is set to true for this round check.
> 
> After target_pages introduced, we could leverage this variable instead
> of checking the address offset.
> 
> Signed-off-by: Wei Yang 

Yes, OK - I find target_pages being incremented before
this point a bit confusing, I think of '0' as the first one.

Still, it's OK:


Reviewed-by: Dr. David Alan Gilbert 

> ---
>  migration/ram.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/migration/ram.c b/migration/ram.c
> index 5c05376d8d..b5759793a9 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -4067,7 +4067,7 @@ static int ram_load_postcopy(QEMUFile *f)
>  page_buffer = postcopy_host_page +
>((uintptr_t)host & (block->page_size - 1));
>  /* If all TP are zero then we can optimise the place */
> -if (!((uintptr_t)host & (block->page_size - 1))) {
> +if (target_pages == 1) {
>  all_zero = true;
>  } else {
>  /* not the 1st TP within the HP */
> -- 
> 2.17.1
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK




Re: [RHEL-8.1 virt 2/2] target/i386: sev: Do not pin the ram device memory region

2019-11-06 Thread Gary R Hook



- Original Message -
> From: "Gary R Hook" 
> To: rhvirt-patc...@redhat.com
> Cc: qemu-devel@nongnu.org, "Paolo Bonzini" , 
> gh...@redhat.com, "Eduardo Habkost"
> , "Richard Henderson" 
> Sent: Tuesday, April 9, 2019 7:08:03 PM
> Subject: [RHEL-8.1 virt 2/2] target/i386: sev: Do not pin the ram device  
> memory region
> 
> BZ: 1667249
> Branch: rhel-8.1.0
> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1667249
> Upstream Status: 4.0.0-rc1
> Build Info:
> https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=20980582
> Conflicts: None
> 
> commit cedc0ad539afbbb669dba9e73dfad2915bc1c25b
> Author: Singh, Brijesh 
> Date:   Mon Feb 4 22:23:40 2019 +
> 
> target/i386: sev: Do not pin the ram device memory region
> 
> The RAM device presents a memory region that should be handled
> as an IO region and should not be pinned.
> 
> In the case of the vfio-pci, RAM device represents a MMIO BAR
> and the memory region is not backed by pages hence
> KVM_MEMORY_ENCRYPT_REG_REGION fails to lock the memory range.
> 
> Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1667249
> Cc: Alex Williamson 
> Cc: Paolo Bonzini 
> Signed-off-by: Brijesh Singh 
> Message-Id: <20190204222322.26766-3-brijesh.si...@amd.com>
> Signed-off-by: Paolo Bonzini 
> 
> Cc: Paolo Bonzini 
> Cc: Richard Henderson 
> Cc: Eduardo Habkost 
> Cc: qemu-devel@nongnu.org

NACKed-by: Gary R Hook 

> ---
>  target/i386/sev.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/target/i386/sev.c b/target/i386/sev.c
> index 2395171acf..b8009b001a 100644
> --- a/target/i386/sev.c
> +++ b/target/i386/sev.c
> @@ -130,6 +130,17 @@ sev_ram_block_added(RAMBlockNotifier *n, void *host,
> size_t size)
>  {
>  int r;
>  struct kvm_enc_region range;
> +ram_addr_t offset;
> +MemoryRegion *mr;
> +
> +/*
> + * The RAM device presents a memory region that should be treated
> + * as IO region and should not be pinned.
> + */
> +mr = memory_region_from_host(host, );
> +if (mr && memory_region_is_ram_device(mr)) {
> + return;
> +}
>  
>  range.addr = (__u64)(unsigned long)host;
>  range.size = size;
> --
> 2.18.1
> 
> 




Re: [PATCH 3/6] migration/postcopy: count target page number to decide the place_needed

2019-11-06 Thread Dr. David Alan Gilbert
* Wei Yang (richardw.y...@linux.intel.com) wrote:
> In postcopy, it requires to place whole host page instead of target
> page.
> 
> Currently, it relies on the page offset to decide whether this is the
> last target page. We also can count the target page number during the
> iteration. When the number of target page equals
> (host page size / target page size), this means it is the last target
> page in the host page.
> 
> This is a preparation for non-ordered target page transmission.
> 
> Signed-off-by: Wei Yang 

Reviewed-by: Dr. David Alan Gilbert 

> ---
>  migration/ram.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/migration/ram.c b/migration/ram.c
> index f59e3fe197..5c05376d8d 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -4017,6 +4017,7 @@ static int ram_load_postcopy(QEMUFile *f)
>  void *postcopy_host_page = mis->postcopy_tmp_page;
>  void *last_host = NULL;
>  bool all_zero = false;
> +int target_pages = 0;
>  
>  while (!ret && !(flags & RAM_SAVE_FLAG_EOS)) {
>  ram_addr_t addr;
> @@ -4051,6 +4052,7 @@ static int ram_load_postcopy(QEMUFile *f)
>  ret = -EINVAL;
>  break;
>  }
> +target_pages++;
>  matches_target_page_size = block->page_size == TARGET_PAGE_SIZE;
>  /*
>   * Postcopy requires that we place whole host pages atomically;
> @@ -4082,8 +4084,10 @@ static int ram_load_postcopy(QEMUFile *f)
>   * If it's the last part of a host page then we place the host
>   * page
>   */
> -place_needed = (((uintptr_t)host + TARGET_PAGE_SIZE) &
> - (block->page_size - 1)) == 0;
> +if (target_pages == (block->page_size / TARGET_PAGE_SIZE)) {
> +place_needed = true;
> +target_pages = 0;
> +}
>  place_source = postcopy_host_page;
>  }
>  last_host = host;
> -- 
> 2.17.1
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK




Re: [PATCH 2/6] migration/postcopy: wait for decompress thread in precopy

2019-11-06 Thread Dr. David Alan Gilbert
* Wei Yang (richardw.y...@linux.intel.com) wrote:
> Compress is not supported with postcopy, it is safe to wait for
> decompress thread just in precopy.
> 
> This is a preparation for later patch.
> 
> Signed-off-by: Wei Yang 

OK, since your last patch does this for postcopy.


Reviewed-by: Dr. David Alan Gilbert 

> ---
>  migration/ram.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/migration/ram.c b/migration/ram.c
> index 7938a643d9..f59e3fe197 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -4375,6 +4375,7 @@ static int ram_load_precopy(QEMUFile *f)
>  }
>  }
>  
> +ret |= wait_for_decompress_done();
>  return ret;
>  }
>  
> @@ -4406,8 +4407,6 @@ static int ram_load(QEMUFile *f, void *opaque, int 
> version_id)
>  } else {
>  ret = ram_load_precopy(f);
>  }
> -
> -ret |= wait_for_decompress_done();
>  }
>  trace_ram_load_complete(ret, seq_iter);
>  
> -- 
> 2.17.1
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK




Re: [PATCH v14 01/11] util/cutils: Add qemu_strtotime_ns()

2019-11-06 Thread Eduardo Habkost
On Mon, Oct 28, 2019 at 03:52:10PM +0800, Tao Xu wrote:
> To convert strings with time suffixes to numbers, support time unit are
> "ns" for nanosecond, "us" for microsecond, "ms" for millisecond or "s"
> for second. Add test for qemu_strtotime_ns, test the input of basic,
> time suffixes, float, invaild, trailing and overflow.
> 
> Signed-off-by: Tao Xu 
> ---
> 
> Changes in 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)

Suggestion for the next version: if you are refactoring existing
do_strtosz() code, please refactor it in one patch, and add new
functionality in another patch.

> ---
>  include/qemu/cutils.h |   1 +
>  tests/test-cutils.c   | 204 ++
>  util/cutils.c |  89 +++---
>  3 files changed, 262 insertions(+), 32 deletions(-)
> 
> diff --git a/include/qemu/cutils.h b/include/qemu/cutils.h
> index b54c847e0f..ff2b3f4614 100644
> --- a/include/qemu/cutils.h
> +++ b/include/qemu/cutils.h
> @@ -182,5 +182,6 @@ int uleb128_decode_small(const uint8_t *in, uint32_t *n);
>   * *str1 is <, == or > than *str2.
>   */
>  int qemu_pstrcmp0(const char **str1, const char **str2);
> +int qemu_strtotime_ns(const char *nptr, const char **end, uint64_t *result);
>  
>  #endif
> diff --git a/tests/test-cutils.c b/tests/test-cutils.c
> index 1aa8351520..d6a0824efd 100644
> --- a/tests/test-cutils.c
> +++ b/tests/test-cutils.c
[...]
> +static void test_qemu_strtotime_ns_trailing(void)
> +{
> +const char *str;
> +const char *endptr;
> +int err;
> +uint64_t res = 0xbaadf00d;
> +
> +str = "123xxx";
> +
> +err = qemu_strtotime_ns(str, NULL, );
> +g_assert_cmpint(err, ==, -EINVAL);
> +
> +str = "1msxxx";
> +err = qemu_strtotime_ns(str, , );
> +g_assert_cmpint(err, ==, 0);
> +g_assert_cmpint(res, ==, 100);
> +g_assert(endptr == str + 3);
> +
> +err = qemu_strtotime_ns(str, NULL, );
> +g_assert_cmpint(err, ==, -EINVAL);
> +}

This is better than the test case in v13, where trailing strings
were not handled consistently.  Good.

[...]
> diff --git a/util/cutils.c b/util/cutils.c
> index fd591cadf0..d83825f8b4 100644
> --- a/util/cutils.c
> +++ b/util/cutils.c
> @@ -181,41 +181,38 @@ int fcntl_setfl(int fd, int flag)
>  }
>  #endif
>  
> -static int64_t suffix_mul(char suffix, int64_t unit)
> -{
> -switch (qemu_toupper(suffix)) {
> -case 'B':
> -return 1;
> -case 'K':
> -return unit;
> -case 'M':
> -return unit * unit;
> -case 'G':
> -return unit * unit * unit;
> -case 'T':
> -return unit * unit * unit * unit;
> -case 'P':
> -return unit * unit * unit * unit * unit;
> -case 'E':
> -return unit * unit * unit * unit * unit * unit;
> +static int64_t suffix_mul(const char *suffixes[], int num_suffix,
> +  const char *endptr, int *offset, int64_t unit)
> +{
> +int i, suffix_len;
> +int64_t mul = 1;
> +
> +for (i = 0; i < num_suffix; i++) {
> +suffix_len = strlen(suffixes[i]);
> +if (strlen(endptr) >= suffix_len &&

Is the strlen(endptr) check here really necessary?


> +g_ascii_strncasecmp(suffixes[i], endptr, suffix_len) == 0) {
> +*offset = suffix_len;
> +return mul;
> +}
> +mul *= unit;
>  }
> +
>  return -1;
>  }
>  
>  /*
> - * Convert string to bytes, allowing either B/b for bytes, K/k for KB,
> - * M/m for MB, G/g for GB or T/t for TB. End pointer will be returned
> - * in *end, if not NULL. Return -ERANGE on overflow, and -EINVAL on
> - * other error.
> + * Convert string according to different suffixes. End pointer will be 
> returned
> + * in *end, if not NULL. Return -ERANGE on overflow, and -EINVAL on other 
> error.
>   */
> -static int do_strtosz(const char *nptr, const char **end,
> -  const char default_suffix, int64_t unit,
> -  uint64_t *result)
> +static int do_strtomul(const char *nptr, const char **end,
> +   const char *suffixes[], int num_suffix,
> +   const char *default_suffix, int64_t unit,
> +   uint64_t *result)
>  {
>  int retval;
>  const char *endptr;
> -unsigned char c;
>  int mul_required = 0;
> +int offset = 0;
>  double val, mul, integral, fraction;
>  
>  retval = qemu_strtod_finite(nptr, , );
> @@ -226,12 +223,12 @@ static int do_strtosz(const char *nptr, const char 
> **end,
>  if (fraction != 0) {
>  mul_required = 1;
>  }
> -c = *endptr;
> -mul = suffix_mul(c, unit);
> +
> +mul = suffix_mul(suffixes, num_suffix, endptr, , unit);
>  if (mul >= 0) {
> -endptr++;
> +endptr += offset;
>  } else {
> -mul = suffix_mul(default_suffix, unit);
> +   

Re: [PATCH 6/6] migration/postcopy: enable compress during postcopy

2019-11-06 Thread Dr. David Alan Gilbert
* Wei Yang (richardw.y...@linux.intel.com) wrote:
> postcopy requires to place a whole host page, while migration thread
> migrate memory in target page size. This makes postcopy need to collect
> all target pages in one host page before placing via userfaultfd.
> 
> To enable compress during postcopy, there are two problems to solve:
> 
> 1. Random order for target page arrival
> 2. Target pages in one host page arrives without interrupt by target
>page from other host page
> 
> The first one is handled by previous cleanup patch.
> 
> This patch handles the second one by:
> 
> 1. Flush compress thread for each host page
> 2. Wait for decompress thread for before placing host page
> 
> Signed-off-by: Wei Yang 
> ---
>  migration/migration.c | 11 ---
>  migration/ram.c   | 28 +++-
>  2 files changed, 27 insertions(+), 12 deletions(-)
> 
> diff --git a/migration/migration.c b/migration/migration.c
> index 3febd0f8f3..72e53e2249 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -1000,17 +1000,6 @@ static bool migrate_caps_check(bool *cap_list,
>  #endif
>  
>  if (cap_list[MIGRATION_CAPABILITY_POSTCOPY_RAM]) {
> -if (cap_list[MIGRATION_CAPABILITY_COMPRESS]) {
> -/* The decompression threads asynchronously write into RAM
> - * rather than use the atomic copies needed to avoid
> - * userfaulting.  It should be possible to fix the decompression
> - * threads for compatibility in future.
> - */
> -error_setg(errp, "Postcopy is not currently compatible "
> -   "with compression");
> -return false;
> -}
> -

Yes, I think that's safe - as long as the 'compress' gets set on both
sides you should never get a combination of one side trying it and the
other not being capable.


Reviewed-by: Dr. David Alan Gilbert 

>  /* This check is reasonably expensive, so only when it's being
>   * set the first time, also it's only the destination that needs
>   * special support.
> diff --git a/migration/ram.c b/migration/ram.c
> index da0596411c..1403978d75 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -3449,6 +3449,14 @@ static int ram_save_iterate(QEMUFile *f, void *opaque)
>  
>  rs->target_page_count += pages;
>  
> +/*
> + * During postcopy, it is necessary to make sure one whole host
> + * page is sent in one chunk.
> + */
> +if (migrate_postcopy_ram()) {
> +flush_compressed_data(rs);
> +}
> +
>  /*
>   * we want to check in the 1st loop, just in case it was the 1st
>   * time and we had to sync the dirty bitmap.
> @@ -4025,6 +4033,7 @@ static int ram_load_postcopy(QEMUFile *f)
>  void *place_source = NULL;
>  RAMBlock *block = NULL;
>  uint8_t ch;
> +int len;
>  
>  addr = qemu_get_be64(f);
>  
> @@ -4042,7 +4051,8 @@ static int ram_load_postcopy(QEMUFile *f)
>  
>  trace_ram_load_postcopy_loop((uint64_t)addr, flags);
>  place_needed = false;
> -if (flags & (RAM_SAVE_FLAG_ZERO | RAM_SAVE_FLAG_PAGE)) {
> +if (flags & (RAM_SAVE_FLAG_ZERO | RAM_SAVE_FLAG_PAGE |
> + RAM_SAVE_FLAG_COMPRESS_PAGE)) {
>  block = ram_block_from_stream(f, flags);
>  
>  host = host_from_ram_block_offset(block, addr);
> @@ -4114,6 +4124,17 @@ static int ram_load_postcopy(QEMUFile *f)
>   TARGET_PAGE_SIZE);
>  }
>  break;
> +case RAM_SAVE_FLAG_COMPRESS_PAGE:
> +all_zero = false;
> +len = qemu_get_be32(f);
> +if (len < 0 || len > compressBound(TARGET_PAGE_SIZE)) {
> +error_report("Invalid compressed data length: %d", len);
> +ret = -EINVAL;
> +break;
> +}
> +decompress_data_with_multi_threads(f, page_buffer, len);
> +break;
> +
>  case RAM_SAVE_FLAG_EOS:
>  /* normal exit */
>  multifd_recv_sync_main();
> @@ -4125,6 +4146,11 @@ static int ram_load_postcopy(QEMUFile *f)
>  break;
>  }
>  
> +/* Got the whole host page, wait for decompress before placing. */
> +if (place_needed) {
> +ret |= wait_for_decompress_done();
> +}
> +
>  /* Detect for any possible file errors */
>  if (!ret && qemu_file_get_error(f)) {
>  ret = qemu_file_get_error(f);
> -- 
> 2.17.1
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK




Re: [PULL 0/1] Seabios 20191106 patches

2019-11-06 Thread no-reply
Patchew URL: https://patchew.org/QEMU/20191106122524.5537-1-kra...@redhat.com/



Hi,

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

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

Passed all 108 iotests
  TESTcheck-qtest-aarch64: tests/qos-test
**
ERROR:/tmp/qemu-test/src/tests/boot-sector.c:161:boot_sector_test: assertion 
failed (signature == SIGNATURE): (0x == 0xdead)
ERROR - Bail out! 
ERROR:/tmp/qemu-test/src/tests/boot-sector.c:161:boot_sector_test: assertion 
failed (signature == SIGNATURE): (0x == 0xdead)
make: *** [check-qtest-x86_64] Error 1
Traceback (most recent call last):
  File "./tests/docker/docker.py", line 662, in 
sys.exit(main())
---
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['sudo', '-n', 'docker', 'run', 
'--label', 'com.qemu.instance.uuid=94fa7e2078d84908a9f9a7f2f442c434', '-u', 
'1003', '--security-opt', 'seccomp=unconfined', '--rm', '-e', 'TARGET_LIST=', 
'-e', 'EXTRA_CONFIGURE_OPTS=', '-e', 'V=', '-e', 'J=14', '-e', 'DEBUG=', '-e', 
'SHOW_ENV=1', '-e', 'CCACHE_DIR=/var/tmp/ccache', '-v', 
'/home/patchew2/.cache/qemu-docker-ccache:/var/tmp/ccache:z', '-v', 
'/var/tmp/patchew-tester-tmp-qy60v805/src/docker-src.2019-11-06-14.28.30.29417:/var/tmp/qemu:z,ro',
 'qemu:centos7', '/var/tmp/qemu/run', 'test-quick']' returned non-zero exit 
status 2.
filter=--filter=label=com.qemu.instance.uuid=94fa7e2078d84908a9f9a7f2f442c434
make[1]: *** [docker-run] Error 1
make[1]: Leaving directory `/var/tmp/patchew-tester-tmp-qy60v805/src'
make: *** [docker-run-test-quick@centos7] Error 2

real14m4.054s
user0m8.513s


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

Re: [PATCH v1 4/4] iotests: add test for virtio-scsi and virtio-blk machine type settings

2019-11-06 Thread Eduardo Habkost
On Wed, Nov 06, 2019 at 11:04:16AM +0100, Max Reitz wrote:
> On 06.11.19 10:24, Stefan Hajnoczi wrote:
> > On Tue, Nov 05, 2019 at 07:11:05PM +0300, Denis Plotnikov wrote:
> >> It tests proper queue size settings for all available machine types.
> >>
> >> Signed-off-by: Denis Plotnikov 
> >> ---
> >>  tests/qemu-iotests/267 | 154 +
> >>  tests/qemu-iotests/267.out |   1 +
> >>  tests/qemu-iotests/group   |   1 +
> >>  3 files changed, 156 insertions(+)
> >>  create mode 100755 tests/qemu-iotests/267
> >>  create mode 100644 tests/qemu-iotests/267.out
> > 
> > The qemu-iotests maintainers might prefer for this to be at the
> > top-level in tests/ since it's not really an iotest, but the code itself
> > looks fine to me:
> > 
> > Reviewed-by: Stefan Hajnoczi 
> 
> Good question.  I don’t really mind, but it would be weird if started
> adding all kinds of “external” qemu tests (i.e. that use QMP) in the
> iotests directory.
> 
> What is the alternative?  Just putting it in a different directory
> doesn’t sound that appealing to me either, because it would still depend
> on the iotests infrastructure, right?  (i.e., iotests.py and check)

We do have tests/acceptance for simple test cases written in
Python.  What's the reason for this test case to depend on the
iotests infrastructure?

-- 
Eduardo




Re: [RFC PATCH 06/18] qemu-storage-daemon: Add --nbd-server option

2019-11-06 Thread Eric Blake

On 11/6/19 6:51 AM, Max Reitz wrote:

On 17.10.19 15:01, Kevin Wolf wrote:

Add a --nbd-server option to qemu-storage-daemon to start the built-in
NBD server right away. It maps the arguments for nbd-server-start to the
command line.


Well, it doesn’t quite, because nbd-server-start takes a
SocketAddressLegacy, and this takes a SocketAddress.

On one hand I can understand why you would do it differently (especially
for command-line options), but on the other I find it a bit problematic
to have --nbd-server be slightly different from nbd-server-start when
both are intended to be the same.

My biggest problem though lies in the duplication in the QAPI schema.
If NbdServerOptions.addr were a SocketAddressLegacy, we could let
nbd-server-start’s options just be of type NbdServerOptions and thus get
rid of the duplication.


I would love to somehow deprecate the use of SocketAddressLegacy and get 
QMP nbd-server-start to accept SocketAddress instead.  Maybe it could be 
done by adding a new nbd-server-begin command in 5.0 with a saner wire 
layout, and deprecating nbd-server-start at that time; by the 5.2 
release, we could then drop nbd-server-start.  But we're too late for 4.2.




I suspect in practice it’s all not that big of a problem.  I can’t call
it bad if --nbd-server is just nicer to use.  And the biggest problem
with duplication in the QAPI schema is that nbd-server-start and
--nbd-server might get out of sync.  But realistically, I don’t see that
happen, because if nbd-server-start changes, nbd_server_start() will
change, too, so we’ll get compile errors in nbd_server_start_options().

*shrug*

But I do think the commit message should explain why we can’t just use
NbdServerOptions for nbd-server-start.

Max


Example (only with required options):

 --nbd-server addr.type=inet,addr.host=localhost,addr.port=10809

Signed-off-by: Kevin Wolf 
---
  qapi/block.json   | 18 ++
  include/block/nbd.h   |  1 +
  blockdev-nbd.c|  5 +
  qemu-storage-daemon.c | 26 +-
  Makefile.objs |  2 +-
  5 files changed, 50 insertions(+), 2 deletions(-)

diff --git a/qapi/block.json b/qapi/block.json
index 145c268bb6..7fe0cf6538 100644
--- a/qapi/block.json
+++ b/qapi/block.json
@@ -215,6 +215,24 @@
  '*id': 'str',
  '*force': 'bool' } }
  
+##

+# @NbdServerOptions:
+#
+# @addr: Address on which to listen.
+# @tls-creds: ID of the TLS credentials object (since 2.6).
+# @tls-authz: ID of the QAuthZ authorization object used to validate
+# the client's x509 distinguished name. This object is
+# is only resolved at time of use, so can be deleted and
+# recreated on the fly while the NBD server is active.
+# If missing, it will default to denying access (since 4.0).
+#
+# Since: 4.2
+##
+{ 'struct': 'NbdServerOptions',
+  'data': { 'addr': 'SocketAddress',
+'*tls-creds': 'str',
+'*tls-authz': 'str'} }
+
  ##
  # @nbd-server-start:
  #
diff --git a/include/block/nbd.h b/include/block/nbd.h
index 316fd705a9..2a7441491a 100644
--- a/include/block/nbd.h
+++ b/include/block/nbd.h
@@ -353,6 +353,7 @@ void nbd_client_put(NBDClient *client);
  
  void nbd_server_start(SocketAddress *addr, const char *tls_creds,

const char *tls_authz, Error **errp);
+void nbd_server_start_options(NbdServerOptions *arg, Error **errp);
  
  /* nbd_read

   * Reads @size bytes from @ioc. Returns 0 on success.
diff --git a/blockdev-nbd.c b/blockdev-nbd.c
index 6a8b206e1d..d4c1fd4166 100644
--- a/blockdev-nbd.c
+++ b/blockdev-nbd.c
@@ -132,6 +132,11 @@ void nbd_server_start(SocketAddress *addr, const char 
*tls_creds,
  nbd_server = NULL;
  }
  
+void nbd_server_start_options(NbdServerOptions *arg, Error **errp)

+{
+nbd_server_start(arg->addr, arg->tls_creds, arg->tls_authz, errp);
+}
+
  void qmp_nbd_server_start(SocketAddressLegacy *addr,
bool has_tls_creds, const char *tls_creds,
bool has_tls_authz, const char *tls_authz,
diff --git a/qemu-storage-daemon.c b/qemu-storage-daemon.c
index 904e3c3a46..51882452f3 100644
--- a/qemu-storage-daemon.c
+++ b/qemu-storage-daemon.c
@@ -25,11 +25,14 @@
  #include "qemu/osdep.h"
  
  #include "block/block.h"

+#include "block/nbd.h"
  #include "crypto/init.h"
  
  #include "qapi/error.h"

-#include "qapi/qapi-visit-block-core.h"
+#include "qapi/qapi-commands-block.h"
  #include "qapi/qapi-commands-block-core.h"
+#include "qapi/qapi-visit-block.h"
+#include "qapi/qapi-visit-block-core.h"
  #include "qapi/qobject-input-visitor.h"
  
  #include "qemu-common.h"

@@ -64,6 +67,12 @@ static void help(void)
  " [,driver specific parameters...]\n"
  " configure a block backend\n"
  "\n"
+"  --nbd-server addr.type=inet,addr.host=,addr.port=\n"
+"   [,tls-creds=][,tls-authz=]\n"
+"  --nbd-server addr.type=unix,addr.path=\n"
+" 

Re: [PATCH v8 1/3] docs: improve qcow2 spec about extending image header

2019-11-06 Thread Eric Blake

On 10/18/19 9:36 AM, Vladimir Sementsov-Ogievskiy wrote:


Maybe:

if software doesn't know how to interpret the field, it may be safely ignored 
unless a corresponding incompatible feature flag bit is set; however, the field 
should be preserved unchanged when rewriting the image header.


+
+For all additional fields zero value equals to absence of field (absence is
+when field.offset + field.size > @header_length). This implies
+that if software want's to set fields up to some field not aligned to multiply
+of 8 it must align header up by zeroes. And on the other hand, if software
+need some optional field which is absent it should assume that it's value is
+zero.


Maybe:

Each optional field that does not have a corresponding incompatible feature bit 
must support the value 0 that gives the same default behavior as when the 
optional field is omitted.


Hmmm. That doesn't work, as "corresponding" is something not actually defined. 
Consider our zstd extension.

It has corresponding incompatible bit, therefore, this sentence doesn't apply 
to it. But still, if incompatible bit is unset we can have this field. And it's 
zero value must correspond
to the absence of the field.

So, additional field may use incomaptible bit only for subset of its values.

But, I see, that you want to allow 0 value to not match field-absence if 
incompatible bit is set?


Not necessarily.  Rather, if the value of an unknown field can be safely 
ignored, then it should default to 0.  If it cannot be safely ignored, 
then that field will not be set to a non-zero value without also setting 
an incompatible feature flag, so that software that does not know how to 
interpret the field will fail to load the image because it also fails to 
recognize the associated new incompatible feature bit.


But I'd really like Kevin's opinion on how much wording is worth adding.



So, may be

Additional fields has the following compatible behavior by default:


s/has/have/



1. If software doesn't know how to interpret the field, it may be safely 
ignored, other than preserving the field unchanged when rewriting the image 
header.
2. Zeroed additional field gives the same behavior as when this field is 
omitted.


Both good.



This default behavior may be altered with help of incompatible feature bits. 
So, if, for example, additional field has corresponding incompatible feature 
bit, and it is set, we are sure that software which opens the image knows how 
to interpret the field, so,
1. The field definitely will not be ignored when corresponding incompatible bit 
is set.
2. The field may define any meaning it wants for zero value for the case when 
corresponding incompatible bit is set.


Rather wordy but seems accurate.  Perhaps compress it to:

3. Any additional field whose value must not be ignored for correct 
handling of the file will be accompanied by a corresponding incompatible 
feature bit.


and maybe even reorder it to list the points as:

Additional fields have the following compatibility rules:
1. Any additional field whose value must not be ignored for correct 
handling of the file will be accompanied by a corresponding incompatible 
feature bit.
2. If there are no unrecognized incompatible feature bits set, an 
additional field may be safely ignored other than preserving its value 
when rewriting the image header.
3. An explicit value of 0 will have the same behavior as when the field 
is not present.




+It's allowed for the header end to cut some field in the middle (in this case
+the field is considered as absent), but in this case the part of the field
+which is covered by @header_length must be zeroed.
+
+    < ... No additional fields in the header currently ... >


Do we even still need this if we require 8-byte alignment?  We'd never be able 
to cut a single field in the middle


hmm, for example:
105: compression byte
106-113: some other 8-bytes field, unalinged
113-119: padding to multiply of 8

- bad example, for sure. But to prevent it, we should also define some field 
alignment requirements..



, but I suppose you are worried about cutting a 2-field 16-byte addition tied 
to a single feature in the middle.


and this too.


   But that's not going to happen in practice.


why not?

4 bytes: feature 1

4 bytes: feature 2
8 bytes: feature 2

so, last 12 bytes may be considered as one field.. And software which don't 
know about feature2, will pad header to the middle of feature2


The only time the header will be longer than 104 bytes is if at least one 
documented optional feature has been implemented/backported, and that feature 
will be implemented in its entirety.  If you backport a later feature but not 
the earlier, you're still going to set header_length to the boundary of the 
feature that you ARE backporting.


That's true, of course.


   Thus, I argue that blindly setting header_length to 120 prior to the 
standard ever defining optional field(s) at 112-120 is premature, and that if 
we ever 

Re: [PULL v2 00/13] Linux user for 4.2 patches

2019-11-06 Thread no-reply
Patchew URL: https://patchew.org/QEMU/20191106130456.6176-1-laur...@vivier.eu/



Hi,

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

Subject: [PULL v2 00/13] Linux user for 4.2 patches
Type: series
Message-id: 20191106130456.6176-1-laur...@vivier.eu

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

Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
From https://github.com/patchew-project/qemu
   2dd8fd6..4570c2e  master -> master
 - [tag update]  
patchew/20191018004850.9888-1-richardw.y...@linux.intel.com -> 
patchew/20191018004850.9888-1-richardw.y...@linux.intel.com
Switched to a new branch 'test'
66eeef8 linux-user/alpha: Set r20 secondary return value
752ee6e linux-user/sparc: Fix cpu_clone_regs_*
205ab4e linux-user: Introduce cpu_clone_regs_parent
e116815 linux-user: Rename cpu_clone_regs to cpu_clone_regs_child
e331e5c linux-user/sparc64: Fix target_signal_frame
0a9f44c linux-user/sparc: Fix WREG usage in setup_frame
39220db linux-user/sparc: Use WREG_SP constant in sparc/signal.c
54f43cd linux-user/sparc: Begin using WREG constants in sparc/signal.c
41f1345 linux-user/sparc: Use WREG constants in sparc/target_cpu.h
084e4ce target/sparc: Define an enumeration for accessing env->regwptr
8da1545 tests/tcg/multiarch/linux-test: Fix error check for shmat
29f529a scripts/qemu-binfmt-conf: Update for sparc64
ccdaa08 linux-user: Support for NETLINK socket options

=== OUTPUT BEGIN ===
1/13 Checking commit ccdaa088dec3 (linux-user: Support for NETLINK socket 
options)
2/13 Checking commit 29f529a599f1 (scripts/qemu-binfmt-conf: Update for sparc64)
WARNING: line over 80 characters
#36: FILE: scripts/qemu-binfmt-conf.sh:41:
+sparc64_magic='\x7fELF\x02\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x2b'

ERROR: line over 90 characters
#37: FILE: scripts/qemu-binfmt-conf.sh:42:
+sparc64_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff'

total: 1 errors, 1 warnings, 20 lines checked

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

3/13 Checking commit 8da15455f6f6 (tests/tcg/multiarch/linux-test: Fix error 
check for shmat)
4/13 Checking commit 084e4ce785d7 (target/sparc: Define an enumeration for 
accessing env->regwptr)
5/13 Checking commit 41f1345f4116 (linux-user/sparc: Use WREG constants in 
sparc/target_cpu.h)
6/13 Checking commit 54f43cd1635a (linux-user/sparc: Begin using WREG constants 
in sparc/signal.c)
7/13 Checking commit 39220db616ca (linux-user/sparc: Use WREG_SP constant in 
sparc/signal.c)
8/13 Checking commit 0a9f44c7244a (linux-user/sparc: Fix WREG usage in 
setup_frame)
9/13 Checking commit e331e5c5689d (linux-user/sparc64: Fix target_signal_frame)
10/13 Checking commit e1168157fac4 (linux-user: Rename cpu_clone_regs to 
cpu_clone_regs_child)
11/13 Checking commit 205ab4e6001d (linux-user: Introduce cpu_clone_regs_parent)
12/13 Checking commit 752ee6ec2302 (linux-user/sparc: Fix cpu_clone_regs_*)
13/13 Checking commit 66eeef8f89f7 (linux-user/alpha: Set r20 secondary return 
value)
=== OUTPUT END ===

Test command exited with code: 1


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

[Bug 1851547] [NEW] qemu 4 crashes with this parameter attached -usb -device usb-host, hostbus=1, hostaddr=7 \

2019-11-06 Thread Marietto
Public bug reported:

Hello.

qemu / kvm does not start anymore after upgrading ubuntu from 19.04 to
19.10 and qemu from 3 to 4,as you can see below. what can I do ?

root@ziomario-Z390-AORUS-PRO:/home/ziomario/Scrivania/OS-KVM# ./boot-OS-
HSP2.sh

> qemu-system-x86_64: /build/qemu-
UryNDZ/qemu-4.0+dfsg/hw/usb/core.c:720: usb_ep_get: asserzione "dev !=
NULL" non riuscita.

./boot-OS-HSP2.sh: riga 40: 26312 Annullato (core dump creato) qemu-
system-x86_64 -enable-kvm -m 16000 -cpu
Penryn,kvm=on,vendor=GenuineIntel,+invtsc,vmware-cpuid-
freq=on,$MY_OPTIONS -machine pc-q35-2.9 -smp 4,cores=2 -vga none -device
vfio-pci,host=01:00.0,bus=pcie.0,multifunction=on -device vfio-
pci,host=01:00.1,bus=pcie.0 -device vfio-pci,host=01:00.2,bus=pcie.0
-device vfio-pci,host=01:00.3,bus=pcie.0 -usb -device usb-
host,hostbus=1,hostaddr=7 -drive
if=pflash,format=raw,readonly,file=$OVMF/OVMF_CODE.fd -drive
if=pflash,format=raw,file=$OVMF/OVMF_VARS-1024x768.fd -smbios type=2
-device ich9-ahci,id=sata -drive
id=Clover,if=none,snapshot=on,format=qcow2,file=./'Mo/CloverNG.qcow2'
-device ide-hd,bus=sata.2,drive=Clover -device ide-
hd,bus=sata.3,drive=InstallMedia -drive
id=InstallMedia,if=none,file=BaseSystemHS.img,format=raw -drive
id=BsdHDD,if=none,file=/dev/sdg,format=raw -device ide-
hd,bus=sata.4,drive=BsdHDD -netdev
tap,id=net0,ifname=tap0,script=no,downscript=no -device
e1000-82545em,netdev=net0,id=net0,mac=52:54:00:c9:18:27 -monitor stdio

It seems that this line is not good anymore (it worked with qemu 3.x) :

-usb -device usb-host,hostbus=1,hostaddr=7 \

when I removed it,it works. But I need that. With what can I change it ?
You can reproduce that upgrading ubuntu 19.04 to 19.10 because in that
way also qemu will be upgraded from 3 to 4. These are the packages that
I'm using :

root@ziomario-Z390-AORUS-PRO:/home/ziomario# qemu-system-x86_64 --version
QEMU emulator version 4.0.0 (Debian 1:4.0+dfsg-0ubuntu9)

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  qemu 4 crashes with this parameter attached -usb -device usb-
  host,hostbus=1,hostaddr=7 \

Status in QEMU:
  New

Bug description:
  Hello.

  qemu / kvm does not start anymore after upgrading ubuntu from 19.04 to
  19.10 and qemu from 3 to 4,as you can see below. what can I do ?

  root@ziomario-Z390-AORUS-PRO:/home/ziomario/Scrivania/OS-KVM# ./boot-
  OS-HSP2.sh

  > qemu-system-x86_64: /build/qemu-
  UryNDZ/qemu-4.0+dfsg/hw/usb/core.c:720: usb_ep_get: asserzione "dev !=
  NULL" non riuscita.

  ./boot-OS-HSP2.sh: riga 40: 26312 Annullato (core dump creato) qemu-
  system-x86_64 -enable-kvm -m 16000 -cpu
  Penryn,kvm=on,vendor=GenuineIntel,+invtsc,vmware-cpuid-
  freq=on,$MY_OPTIONS -machine pc-q35-2.9 -smp 4,cores=2 -vga none
  -device vfio-pci,host=01:00.0,bus=pcie.0,multifunction=on -device
  vfio-pci,host=01:00.1,bus=pcie.0 -device vfio-
  pci,host=01:00.2,bus=pcie.0 -device vfio-pci,host=01:00.3,bus=pcie.0
  -usb -device usb-host,hostbus=1,hostaddr=7 -drive
  if=pflash,format=raw,readonly,file=$OVMF/OVMF_CODE.fd -drive
  if=pflash,format=raw,file=$OVMF/OVMF_VARS-1024x768.fd -smbios type=2
  -device ich9-ahci,id=sata -drive
  id=Clover,if=none,snapshot=on,format=qcow2,file=./'Mo/CloverNG.qcow2'
  -device ide-hd,bus=sata.2,drive=Clover -device ide-
  hd,bus=sata.3,drive=InstallMedia -drive
  id=InstallMedia,if=none,file=BaseSystemHS.img,format=raw -drive
  id=BsdHDD,if=none,file=/dev/sdg,format=raw -device ide-
  hd,bus=sata.4,drive=BsdHDD -netdev
  tap,id=net0,ifname=tap0,script=no,downscript=no -device
  e1000-82545em,netdev=net0,id=net0,mac=52:54:00:c9:18:27 -monitor stdio

  It seems that this line is not good anymore (it worked with qemu 3.x)
  :

  -usb -device usb-host,hostbus=1,hostaddr=7 \

  when I removed it,it works. But I need that. With what can I change it
  ? You can reproduce that upgrading ubuntu 19.04 to 19.10 because in
  that way also qemu will be upgraded from 3 to 4. These are the
  packages that I'm using :

  root@ziomario-Z390-AORUS-PRO:/home/ziomario# qemu-system-x86_64 --version
  QEMU emulator version 4.0.0 (Debian 1:4.0+dfsg-0ubuntu9)

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



Re: [PATCH 1/6] migration/postcopy: reduce memset when it is zero page and matches_target_page_size

2019-11-06 Thread Dr. David Alan Gilbert
* Wei Yang (richardw.y...@linux.intel.com) wrote:
> In this case, page_buffer content would not be used.
> 
> Skip this to save some time.
> 
> Signed-off-by: Wei Yang 
> ---
>  migration/ram.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/migration/ram.c b/migration/ram.c
> index 99a98b2da4..7938a643d9 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -4091,7 +4091,13 @@ static int ram_load_postcopy(QEMUFile *f)
>  switch (flags & ~RAM_SAVE_FLAG_CONTINUE) {
>  case RAM_SAVE_FLAG_ZERO:
>  ch = qemu_get_byte(f);
> -memset(page_buffer, ch, TARGET_PAGE_SIZE);
> +/*
> + * Can skip to set page_buffer when
> + * this is a zero page and (block->page_size == 
> TARGET_PAGE_SIZE).
> + */

When it's zero we will use place_page_zero which doesn't need
to page_buffer; so yes that's OK; and you're right, the gotcha is with 
mismatched page sizes where one subpage might be zero but not all of
them; so yes it's right that we need that check.

SO yes,


Reviewed-by: Dr. David Alan Gilbert 

> +if (ch || !matches_target_page_size) {
> +memset(page_buffer, ch, TARGET_PAGE_SIZE);
> +}
>  if (ch) {
>  all_zero = false;
>  }
> -- 
> 2.17.1
> 
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK




Re: Feature Recommendations?

2019-11-06 Thread Peter Maydell
On Wed, 6 Nov 2019 at 17:42, Eric Blake  wrote:
>
> On 11/3/19 4:59 AM, Dinah A Baum wrote:
> > Hello all,
> >
> > I am a university student whose Virtualization course has tasked me with
> > contributing to an open source, virtualization related project. I have a
> > little more than a month to complete this. I was wondering if you could
> > recommend a feature you'd like added that could be done in this time frame.
>
> https://wiki.qemu.org/Contribute/BiteSizedTasks might be an interesting
> place to start looking for an idea you are comfortable with.

...but do come back and talk to us before putting any coding
work in on items on that page, because there are some old
stale things and some landmine "not as simple as it sounds"
items too. I keep thinking we should try to put some cleanup
effort into that page (maybe convert it into a list of links to
launchpad bugs tagged as 'easy-task' ?)

thanks
-- PMM



Re: [RFC v2 11/14] linux-headers/kvm.h: add capability to forward hypercall

2019-11-06 Thread Cornelia Huck
On Tue, 5 Nov 2019 17:10:53 +0800
Heyi Guo  wrote:

> To keep backward compatibility, we add new KVM capability
> "KVM_CAP_FORWARD_HYPERCALL" to probe whether KVM supports forwarding
> hypercall to userspace.
> 
> The capability should be enabled explicitly, for we don't want user
> space application to deal with unexpected hypercall exits. After
> enabling this cap, all HVC calls unhandled by kvm will be forwarded to
> user space.
> 
> Signed-off-by: Heyi Guo 
> Cc: Peter Maydell 
> Cc: "Michael S. Tsirkin" 
> Cc: Cornelia Huck 
> Cc: Paolo Bonzini 
> Cc: Dave Martin 
> Cc: Marc Zyngier 
> Cc: Mark Rutland 
> Cc: James Morse 
> ---
>  linux-headers/linux/kvm.h |  1 +
>  target/arm/sdei.c | 16 
>  target/arm/sdei.h |  2 ++
>  3 files changed, 19 insertions(+)
> 
> diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
> index 3d9b18f7f8..36c9b3859f 100644
> --- a/linux-headers/linux/kvm.h
> +++ b/linux-headers/linux/kvm.h
> @@ -1000,6 +1000,7 @@ struct kvm_ppc_resize_hpt {
>  #define KVM_CAP_PMU_EVENT_FILTER 173
>  #define KVM_CAP_ARM_IRQ_LINE_LAYOUT_2 174
>  #define KVM_CAP_HYPERV_DIRECT_TLBFLUSH 175
> +#define KVM_CAP_FORWARD_HYPERCALL 176
>  
>  #ifdef KVM_CAP_IRQ_ROUTING

Is this cap upstream already? I would have thought your header sync
would have brought it in, then. (Saying this, that header sync looks
awfully small.)

If it is not upstream yet, please split off this hunk into a separate
patch -- it's a bit annoying, but makes life easier for merging.




Re: [RFC v2 02/14] standard-headers: import arm_sdei.h

2019-11-06 Thread Cornelia Huck
On Tue, 5 Nov 2019 17:10:44 +0800
Heyi Guo  wrote:

> Import Linux header file include/uapi/linux/arm_sdei.h from kernel v5.4-rc5.
> 
> This is to prepare for qemu SDEI emulation.
> 
> Signed-off-by: Heyi Guo 
> Cc: Peter Maydell 
> Cc: Dave Martin 
> Cc: Marc Zyngier 
> Cc: Mark Rutland 
> Cc: James Morse 
> Cc: "Michael S. Tsirkin" 
> Cc: Cornelia Huck 
> Cc: Paolo Bonzini 
> ---
> 
> Notes:
> v2:
> - Import arm_sdei.h by running update-linux-headers.sh
> 
>  include/standard-headers/linux/arm_sdei.h | 73 +++
>  1 file changed, 73 insertions(+)
>  create mode 100644 include/standard-headers/linux/arm_sdei.h

Just a remark that I find it a bit odd that that a header that looks
arm-specific is in the generic linux/ directory (already in the kernel,
I know.) Is this for sharing between arm and arm64, maybe?




Re: [PULL 0/1] Q800 branch patches

2019-11-06 Thread Peter Maydell
On Tue, 5 Nov 2019 at 18:07, Laurent Vivier  wrote:
>
> The following changes since commit b7c9a7f353c0e260519bf735ff0d4aa01e72784b:
>
>   Merge remote-tracking branch 'remotes/jnsnow/tags/ide-pull-request' into 
> staging (2019-10-31 15:57:30 +)
>
> are available in the Git repository at:
>
>   git://github.com/vivier/qemu-m68k.git tags/q800-branch-pull-request
>
> for you to fetch changes up to 653901ca2be30299a224677a8203ff3361dbd5c5:
>
>   q800: fix I/O memory map (2019-11-05 18:52:29 +0100)
>
> 
> Fix q800 memory map
>
> 
>


Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/4.2
for any user-visible changes.

-- PMM



Re: Feature Recommendations?

2019-11-06 Thread Eric Blake

On 11/3/19 4:59 AM, Dinah A Baum wrote:

Hello all,

I am a university student whose Virtualization course has tasked me with
contributing to an open source, virtualization related project. I have a
little more than a month to complete this. I was wondering if you could
recommend a feature you'd like added that could be done in this time frame.


https://wiki.qemu.org/Contribute/BiteSizedTasks might be an interesting 
place to start looking for an idea you are comfortable with.


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




Re: [PATCH v4 06/20] module: check module wasn't already initialized

2019-11-06 Thread Darren Kenny

On Wed, Oct 30, 2019 at 02:49:52PM +, Oleinik, Alexander wrote:

From: Alexander Oleinik 

The virtual-device fuzzer must initialize QOM, prior to running
vl:qemu_init, so that it can use the qos_graph to identify the arguments
required to initialize a guest for libqos-assisted fuzzing. This change
prevents errors when vl:qemu_init tries to (re)initialize the previously
initialized QOM module.

Signed-off-by: Alexander Oleinik 


My only question here really is whether there is any possibility of
the list of any given module type being modified later, if so this
might break things if attempts are made to re-init modules.

In that case, this test might be more correctly belong in the
module's own init() function instead.

Assuming for now that it is the correct place to do it, unless
someone can say otherwise:

Reviewed-by: Darren Kenny 


---
util/module.c | 7 +++
1 file changed, 7 insertions(+)

diff --git a/util/module.c b/util/module.c
index e9fe3e5422..841e490e06 100644
--- a/util/module.c
+++ b/util/module.c
@@ -30,6 +30,7 @@ typedef struct ModuleEntry
typedef QTAILQ_HEAD(, ModuleEntry) ModuleTypeList;

static ModuleTypeList init_type_list[MODULE_INIT_MAX];
+static bool modules_init_done[MODULE_INIT_MAX];

static ModuleTypeList dso_init_list;

@@ -91,11 +92,17 @@ void module_call_init(module_init_type type)
ModuleTypeList *l;
ModuleEntry *e;

+if (modules_init_done[type]) {
+return;
+}
+
l = find_type(type);

QTAILQ_FOREACH(e, l, node) {
e->init();
}
+
+modules_init_done[type] = true;
}

#ifdef CONFIG_MODULES
--
2.23.0






Re: [RFC PATCH 00/18] Add qemu-storage-daemon

2019-11-06 Thread Eric Blake

On 11/6/19 8:58 AM, Kevin Wolf wrote:


Well, but anyway.  Just as I didn’t have anything against adding QMP to
qemu-nbd, I don’t have anything against adding a new application that
kind of fulfills the same purpose.  And I think introducing a new
application instead of reusing qemu-nbd that focuses on all-around QAPI
compatibility (which qemu-nbd decidedly does not have) makes sense.


Yes, QAPI is one big reason for creating a new tool that doesn't need to
support the old qemu-nbd command line. Another is that we can add other
types of exports that are not NBD.


If we could make qemu-nbd a thin wrapper around the new tool (even if 
the two are not necessarily command-line compatible), that might be 
worthwhile.





The only thing I don’t like is the name, but that’s what  is for.
:-)


I'm open for suggestions, but I thought 'qsd' was a bit too terse. :-)

(Actually, maybe we could even pick something that doesn't mention
storage or block? After all, it can do all kinds of QEMU backends in
theory. Not sure if there's any standalone use for them, but who
knows...)


Maybe 'qback', for qemu-backend?

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




Re: [PATCH] numa: Add missing \n to error message

2019-11-06 Thread Laurent Vivier
Le 06/11/2019 à 17:55, Markus Armbruster a écrit :
> Greg Kurz  writes:
> 
>> On Wed, 6 Nov 2019 14:01:01 +0100
>> Laurent Vivier  wrote:
>>
>>> Le 06/11/2019 à 13:46, Greg Kurz a écrit :
 If memory allocation fails when using -mem-path, QEMU is supposed to print
 out a message to indicate that fallback to anonymous RAM is deprecated. 
 This
 is done with error_printf() which does output buffering. As a consequence,
 the message is only printed at the next flush, eg. when quiting QEMU, and
 it also lacks a trailing newline:

 qemu-system-ppc64: unable to map backing store for guest RAM: Cannot 
 allocate memory
 qemu-system-ppc64: warning: falling back to regular RAM allocation
 QEMU 4.1.50 monitor - type 'help' for more information
 (qemu) q
 This is deprecated. Make sure that -mem-path  specified path has 
 sufficient resources to allocate -m specified RAM 
 amountgreg@boss02:~/Work/qemu/qemu-spapr$

 Add the missing \n to fix both issues.

 Fixes: cb79224b7e4b "deprecate -mem-path fallback to anonymous RAM"
 Signed-off-by: Greg Kurz 
 ---
  hw/core/numa.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/hw/core/numa.c b/hw/core/numa.c
 index 038c96d4abc6..e3332a984f7c 100644
 --- a/hw/core/numa.c
 +++ b/hw/core/numa.c
 @@ -503,7 +503,7 @@ static void 
 allocate_system_memory_nonnuma(MemoryRegion *mr, Object *owner,
  warn_report("falling back to regular RAM allocation");
  error_printf("This is deprecated. Make sure that -mem-path "
   " specified path has sufficient resources to 
 allocate"
 - " -m specified RAM amount");
 + " -m specified RAM amount\n");
  /* Legacy behavior: if allocation failed, fall back to
   * regular RAM allocation.
   */


>>>
>>> Why is this an error_printf() and not an error_report()?
>>>
>>
>> Because CODING_STYLE suggests to do so I guess:
>>
>> Reporting errors to the human user
>> --
>>
>> Do not use printf(), fprintf() or monitor_printf().  Instead, use
>> error_report() or error_vreport() from error-report.h.  This ensures the
>> error is reported in the right place (current monitor or stderr), and in
>> a uniform format.
>>
>> Use error_printf() & friends to print additional information. <===
> 
> You're right.
> 
> Since I have nothing queued up right now, I'd prefer to have this go via
> qemu-trivial.

Ok, I will take it in my next qemu-trivial pull request (with the other
Greg's patch).

Thanks,
Laurent




Re: [PATCH v4 13/20] fuzz: add configure flag --enable-fuzzing

2019-11-06 Thread Stefan Hajnoczi
On Wed, Oct 30, 2019 at 02:49:59PM +, Oleinik, Alexander wrote:
> From: Alexander Oleinik 
> 
> Signed-off-by: Alexander Oleinik 
> ---
>  configure | 39 +++
>  1 file changed, 39 insertions(+)

Reviewed-by: Stefan Hajnoczi 


signature.asc
Description: PGP signature


Re: [PATCH v4 12/20] libqtest: add in-process qtest.c tx/rx handlers

2019-11-06 Thread Stefan Hajnoczi
On Wed, Oct 30, 2019 at 02:49:58PM +, Oleinik, Alexander wrote:
> From: Alexander Oleinik 
> 
> Signed-off-by: Alexander Oleinik 
> ---
> There's a particularily ugly line here:
> qtest_client_set_tx_handler(qts,
> (void (*)(QTestState *s, const char*, size_t)) send);

Please typedef the function pointer to avoid repetition:

  typedef void (*QTestSendFn)(QTestState *s, const char *buf, size_t len);

And then introduce a wrapper function for type-safety:

  /* A type-safe wrapper for s->send() */
  static void send_wrapper(QTestState *s, const char *buf, size_t len)
  {
  s->send(s, buf, len);
  }

  ...

  qts->send = send;
  qtest_client_set_tx_handler(qts, send_wrapper);

Does this solve the issue?

By the way, I also wonder whether the size_t len arguments are necessary
since const char *buf is a NUL-terminated C string.  The string should
be enough since the length can be calculated from it.

> diff --git a/qtest.c b/qtest.c
> index 9fbfa0f08f..f817a5d789 100644
> --- a/qtest.c
> +++ b/qtest.c
> @@ -812,6 +812,6 @@ void qtest_server_inproc_recv(void *dummy, const char 
> *buf, size_t size)
>  g_string_append(gstr, buf);
>  if (gstr->str[gstr->len - 1] == '\n') {
>  qtest_process_inbuf(NULL, gstr);
> -g_string_free(gstr, true);
> +g_string_truncate(gstr, 0);

Ah, a fix for the bug in an earlier commit.  Please squash it.

> diff --git a/tests/libqtest.c b/tests/libqtest.c
> index ff3153daf2..6143af33da 100644
> --- a/tests/libqtest.c
> +++ b/tests/libqtest.c
> @@ -71,6 +71,7 @@ static void qtest_client_set_tx_handler(QTestState *s,
>  static void qtest_client_set_rx_handler(QTestState *s,
>  GString * (*recv)(QTestState *));
>  
> +static GString *recv_str;

Can this be a QTestState field?


signature.asc
Description: PGP signature


Re: [PATCH] numa: Add missing \n to error message

2019-11-06 Thread Markus Armbruster
Greg Kurz  writes:

> On Wed, 6 Nov 2019 14:01:01 +0100
> Laurent Vivier  wrote:
>
>> Le 06/11/2019 à 13:46, Greg Kurz a écrit :
>> > If memory allocation fails when using -mem-path, QEMU is supposed to print
>> > out a message to indicate that fallback to anonymous RAM is deprecated. 
>> > This
>> > is done with error_printf() which does output buffering. As a consequence,
>> > the message is only printed at the next flush, eg. when quiting QEMU, and
>> > it also lacks a trailing newline:
>> > 
>> > qemu-system-ppc64: unable to map backing store for guest RAM: Cannot 
>> > allocate memory
>> > qemu-system-ppc64: warning: falling back to regular RAM allocation
>> > QEMU 4.1.50 monitor - type 'help' for more information
>> > (qemu) q
>> > This is deprecated. Make sure that -mem-path  specified path has 
>> > sufficient resources to allocate -m specified RAM 
>> > amountgreg@boss02:~/Work/qemu/qemu-spapr$
>> > 
>> > Add the missing \n to fix both issues.
>> > 
>> > Fixes: cb79224b7e4b "deprecate -mem-path fallback to anonymous RAM"
>> > Signed-off-by: Greg Kurz 
>> > ---
>> >  hw/core/numa.c |2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> > 
>> > diff --git a/hw/core/numa.c b/hw/core/numa.c
>> > index 038c96d4abc6..e3332a984f7c 100644
>> > --- a/hw/core/numa.c
>> > +++ b/hw/core/numa.c
>> > @@ -503,7 +503,7 @@ static void 
>> > allocate_system_memory_nonnuma(MemoryRegion *mr, Object *owner,
>> >  warn_report("falling back to regular RAM allocation");
>> >  error_printf("This is deprecated. Make sure that -mem-path "
>> >   " specified path has sufficient resources to 
>> > allocate"
>> > - " -m specified RAM amount");
>> > + " -m specified RAM amount\n");
>> >  /* Legacy behavior: if allocation failed, fall back to
>> >   * regular RAM allocation.
>> >   */
>> > 
>> > 
>> 
>> Why is this an error_printf() and not an error_report()?
>> 
>
> Because CODING_STYLE suggests to do so I guess:
>
> Reporting errors to the human user
> --
>
> Do not use printf(), fprintf() or monitor_printf().  Instead, use
> error_report() or error_vreport() from error-report.h.  This ensures the
> error is reported in the right place (current monitor or stderr), and in
> a uniform format.
>
> Use error_printf() & friends to print additional information. <===

You're right.

Since I have nothing queued up right now, I'd prefer to have this go via
qemu-trivial.

> error_report() prints the current location.  In certain common cases
> like command line parsing, the current location is tracked
> automatically.  To manipulate it manually, use the loc_``*``() from
> error-report.h.




Re: [PATCH v4 11/20] libqtest: make qtest_bufwrite send "atomic"

2019-11-06 Thread Stefan Hajnoczi
On Wed, Oct 30, 2019 at 02:49:57PM +, Oleinik, Alexander wrote:
> From: Alexander Oleinik 
> 
> When using qtest "in-process" communication, qtest_sendf directly calls
> a function in the server (qtest.c). Combining the contents of the
> subsequent socket_sends into the qtest_sendf, makes it so the server can
> immediately handle the command, without building a local buffer and
> waiting for a newline.
> 
> Signed-off-by: Alexander Oleinik 
> ---
>  tests/libqtest.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/libqtest.c b/tests/libqtest.c
> index 822bfe208b..ff3153daf2 100644
> --- a/tests/libqtest.c
> +++ b/tests/libqtest.c
> @@ -1083,8 +1083,8 @@ void qtest_bufwrite(QTestState *s, uint64_t addr, const 
> void *data, size_t size)
>  
>  bdata = g_base64_encode(data, size);
>  qtest_sendf(s, "b64write 0x%" PRIx64 " 0x%zx ", addr, size);
> -socket_send(s->fd, bdata, strlen(bdata));
> -socket_send(s->fd, "\n", 1);
> +s->ops.send(s, bdata, strlen(bdata));
> +s->ops.send(s, "\n", 1);
>  qtest_rsp(s, 0);
>  g_free(bdata);
>  }

Please update the commit message and description - they no longer seem
to match what the patch is doing.  The qtest_sendf() is not atomic, it
is still split into 3 send operations.

Stefan


signature.asc
Description: PGP signature


Re: [Qemu-devel] [PATCH v2 00/11] RFC crypto/luks: encryption key managment using amend interface

2019-11-06 Thread Maxim Levitsky
On Mon, 2019-10-07 at 10:05 +0200, Markus Armbruster wrote:
> Maxim Levitsky  writes:
> 
> > On Fri, 2019-09-20 at 17:14 -0400, John Snow wrote:
> > > 
> > > On 9/12/19 6:30 PM, Maxim Levitsky wrote:
> > > > This patch series is continuation of my work to add encryption
> > > > key managment to luks/qcow2 with luks.
> > > > 
> > > > This is second version of this patch set.
> > > > The changes are mostly addressing the review feedback,
> > > > plus I tested (and fixed sadly) the somewhat ugly code
> > > > that allows to still write share a raw luks device,
> > > > while preveting the key managment from happening in this case,
> > > > as it is unsafe.
> > > > I added a new iotest dedicated to that as well.
> > > > 
> > > > Best regards,
> > > > Maxim Levitsky
> > > > 
> > > 
> > > What branch is this based on?
> > > It doesn't seem to apply to origin/master.
> > > 
> > > --js
> > 
> > It is based on refactoring patch series I send before,
> > which is also under review:
> > "[PATCH v2 00/13] RFC crypto/luks: preparation for encryption key managment"
> 
> Recommend to note such dependencies in the cover letter as
> 
> Based-on: 
I'll take a note!
Note that now all these patches are merged thus,
this patch series should more or less apply on
top of master branch.
I'll probably resend a V3 after I finish going
over the review of this series.


Best regards,
Maxim Levitsky




Re: [PATCH v4 10/20] libqos: move useful qos-test funcs to qos_external

2019-11-06 Thread Stefan Hajnoczi
On Wed, Oct 30, 2019 at 02:49:56PM +, Oleinik, Alexander wrote:
> From: Alexander Oleinik 
> 
> The moved functions are not specific to qos-test and might be useful
> elsewhere. For example the virtual-device fuzzer makes use of them for
> qos-assisted fuzz-targets.
> 
> Signed-off-by: Alexander Oleinik 
> ---
>  tests/Makefile.include  |   1 +
>  tests/libqos/qos_external.c | 168 
>  tests/libqos/qos_external.h |  28 ++
>  tests/qos-test.c| 140 ++
>  4 files changed, 202 insertions(+), 135 deletions(-)
>  create mode 100644 tests/libqos/qos_external.c
>  create mode 100644 tests/libqos/qos_external.h

Reviewed-by: Stefan Hajnoczi 


signature.asc
Description: PGP signature


Re: [PATCH v4 07/20] qtest: add in-process incoming command handler

2019-11-06 Thread Stefan Hajnoczi
On Wed, Oct 30, 2019 at 02:49:53PM +, Oleinik, Alexander wrote:
> diff --git a/qtest.c b/qtest.c
> index ae7e6d779d..9fbfa0f08f 100644
> --- a/qtest.c
> +++ b/qtest.c
> @@ -802,3 +802,16 @@ bool qtest_driver(void)
>  {
>  return qtest_chr.chr != NULL;
>  }
> +
> +void qtest_server_inproc_recv(void *dummy, const char *buf, size_t size)
> +{
> +static GString *gstr;
> +if (!gstr) {
> +gstr = g_string_new(NULL);
> +}
> +g_string_append(gstr, buf);
> +if (gstr->str[gstr->len - 1] == '\n') {
> +qtest_process_inbuf(NULL, gstr);
> +g_string_free(gstr, true);

This double-frees gstr.  Please add:

  gstr = NULL;


signature.asc
Description: PGP signature


Re: [SeaBIOS] Re: 1.13 release?

2019-11-06 Thread Kevin O'Connor
On Wed, Nov 06, 2019 at 12:12:55PM +0100, Gerd Hoffmann wrote:
> On Wed, Oct 16, 2019 at 12:44:12PM +0200, Gerd Hoffmann wrote:
> >   Hi,
> > 
> > Almost a year since 1.12.0 was tagged (Nov 17th to be exact),
> > time to plan the 1.13 release I think ...
> > 
> > How about freeze in a week or two, release by mid-november?
> > 
> > Pending stuff I'm aware of is the disk geometry patch series.
> > The corresponding qemu series is still waiting to be merged.
> 
> It's finally merged in qemu now.  Going to push the seabios
> series and prepare a seabios update for qemu, so upcoming
> seabios release gets some more test coverage.

Okay, thanks.

If we're going to update that in SeaBIOS, then we may wish to push
back the SeaBIOS release by a few weeks.

-Kevin



[PULL v3 1/3] hw/misc/grlib_ahb_apb_pnp: Avoid crash when writing to PnP registers

2019-11-06 Thread Laurent Vivier
From: Philippe Mathieu-Daudé 

Guests can crash QEMU when writting to PnP registers:

  $ echo 'writeb 0x800ff042 69' | qemu-system-sparc -M leon3_generic -S -bios 
/etc/magic -qtest stdio
  [I 1571938309.932255] OPENED
  [R +0.063474] writeb 0x800ff042 69
  Segmentation fault (core dumped)

  (gdb) bt
  #0  0x in  ()
  #1  0x555f4bcdf0bc in memory_region_write_with_attrs_accessor 
(mr=0x555f4d7be8c0, addr=66, value=0x7fff07d00f08, size=1, shift=0, mask=255, 
attrs=...) at memory.c:503
  #2  0x555f4bcdf185 in access_with_adjusted_size (addr=66, 
value=0x7fff07d00f08, size=1, access_size_min=1, access_size_max=4, 
access_fn=0x555f4bcdeff4 , 
mr=0x555f4d7be8c0, attrs=...) at memory.c:539
  #3  0x555f4bce2243 in memory_region_dispatch_write (mr=0x555f4d7be8c0, 
addr=66, data=69, op=MO_8, attrs=...) at memory.c:1489
  #4  0x555f4bc80b20 in flatview_write_continue (fv=0x555f4d92c400, 
addr=2148528194, attrs=..., buf=0x7fff07d01120 "E", len=1, addr1=66, l=1, 
mr=0x555f4d7be8c0) at exec.c:3161
  #5  0x555f4bc80c65 in flatview_write (fv=0x555f4d92c400, addr=2148528194, 
attrs=..., buf=0x7fff07d01120 "E", len=1) at exec.c:3201
  #6  0x555f4bc80fb0 in address_space_write (as=0x555f4d7aa460, 
addr=2148528194, attrs=..., buf=0x7fff07d01120 "E", len=1) at exec.c:3291
  #7  0x555f4bc8101d in address_space_rw (as=0x555f4d7aa460, 
addr=2148528194, attrs=..., buf=0x7fff07d01120 "E", len=1, is_write=true) at 
exec.c:3301
  #8  0x555f4bcdb388 in qtest_process_command (chr=0x555f4c2ed7e0 
, words=0x555f4db0c5d0) at qtest.c:432

Instead of crashing, log the access as unimplemented.

Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: KONRAD Frederic 
Message-Id: <20191025110114.27091-2-phi...@redhat.com>
Signed-off-by: Laurent Vivier 
---
 hw/misc/grlib_ahb_apb_pnp.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/hw/misc/grlib_ahb_apb_pnp.c b/hw/misc/grlib_ahb_apb_pnp.c
index 7338461694c9..f3c015d2c35f 100644
--- a/hw/misc/grlib_ahb_apb_pnp.c
+++ b/hw/misc/grlib_ahb_apb_pnp.c
@@ -22,6 +22,7 @@
  */
 
 #include "qemu/osdep.h"
+#include "qemu/log.h"
 #include "hw/sysbus.h"
 #include "hw/misc/grlib_ahb_apb_pnp.h"
 
@@ -231,8 +232,15 @@ static uint64_t grlib_apb_pnp_read(void *opaque, hwaddr 
offset, unsigned size)
 return apb_pnp->regs[offset >> 2];
 }
 
+static void grlib_apb_pnp_write(void *opaque, hwaddr addr,
+uint64_t val, unsigned size)
+{
+qemu_log_mask(LOG_UNIMP, "%s not implemented\n", __func__);
+}
+
 static const MemoryRegionOps grlib_apb_pnp_ops = {
 .read   = grlib_apb_pnp_read,
+.write  = grlib_apb_pnp_write,
 .endianness = DEVICE_BIG_ENDIAN,
 };
 
-- 
2.21.0




[PULL v3 2/3] hw/misc/grlib_ahb_apb_pnp: Fix 8-bit accesses

2019-11-06 Thread Laurent Vivier
From: Philippe Mathieu-Daudé 

The Plug & Play region of the AHB/APB bridge can be accessed
by various word size, however the implementation is clearly
restricted to 32-bit:

  static uint64_t grlib_apb_pnp_read(void *opaque, hwaddr offset, unsigned size)
  {
  APBPnp *apb_pnp = GRLIB_APB_PNP(opaque);

  return apb_pnp->regs[offset >> 2];
  }

Set the MemoryRegionOps::impl min/max fields to 32-bit, so
memory.c::access_with_adjusted_size() can adjust when the
access is not 32-bit.

This is required to run RTEMS on leon3, the grlib scanning
functions do byte accesses.

Reported-by: Jiri Gaisler 
Signed-off-by: Philippe Mathieu-Daudé 
Reviewed-by: KONRAD Frederic 
Message-Id: <20191025110114.27091-3-phi...@redhat.com>
Signed-off-by: Laurent Vivier 
---
 hw/misc/grlib_ahb_apb_pnp.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/hw/misc/grlib_ahb_apb_pnp.c b/hw/misc/grlib_ahb_apb_pnp.c
index f3c015d2c35f..e230e2536361 100644
--- a/hw/misc/grlib_ahb_apb_pnp.c
+++ b/hw/misc/grlib_ahb_apb_pnp.c
@@ -242,6 +242,10 @@ static const MemoryRegionOps grlib_apb_pnp_ops = {
 .read   = grlib_apb_pnp_read,
 .write  = grlib_apb_pnp_write,
 .endianness = DEVICE_BIG_ENDIAN,
+.impl = {
+.min_access_size = 4,
+.max_access_size = 4,
+},
 };
 
 static void grlib_apb_pnp_realize(DeviceState *dev, Error **errp)
-- 
2.21.0




[PULL v3 3/3] global: Squash 'the the'

2019-11-06 Thread Laurent Vivier
From: "Dr. David Alan Gilbert" 

'the' has a tendency to double up; squash them back down.

Signed-off-by: Dr. David Alan Gilbert 
Reviewed-by: Alex Bennée 
Reviewed-by: Laurent Vivier 
Reviewed-by: Philippe Mathieu-Daudé 
Message-Id: <20191104185202.102504-1-dgilb...@redhat.com>
[lv: removed disas/libvixl/vixl/invalset.h change]
Signed-off-by: Laurent Vivier 
---
 docs/interop/pr-helper.rst  | 2 +-
 docs/specs/ppc-spapr-hotplug.txt| 2 +-
 docs/specs/ppc-xive.rst | 2 +-
 docs/specs/tpm.txt  | 2 +-
 include/hw/xen/interface/io/blkif.h | 2 +-
 scripts/dump-guest-memory.py| 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/docs/interop/pr-helper.rst b/docs/interop/pr-helper.rst
index 9f76d5bcf98f..e926f0a6c9cb 100644
--- a/docs/interop/pr-helper.rst
+++ b/docs/interop/pr-helper.rst
@@ -10,7 +10,7 @@ can delegate implementation of persistent reservations to an 
external
 restricting access to block devices to specific initiators in a shared
 storage setup.
 
-For a more detailed reference please refer the the SCSI Primary
+For a more detailed reference please refer to the SCSI Primary
 Commands standard, specifically the section on Reservations and the
 "PERSISTENT RESERVE IN" and "PERSISTENT RESERVE OUT" commands.
 
diff --git a/docs/specs/ppc-spapr-hotplug.txt b/docs/specs/ppc-spapr-hotplug.txt
index cc7833108e12..859d52cce6c8 100644
--- a/docs/specs/ppc-spapr-hotplug.txt
+++ b/docs/specs/ppc-spapr-hotplug.txt
@@ -385,7 +385,7 @@ Each LMB list entry consists of the following elements:
   is used to retrieve the right associativity list to be used for this
   LMB.
 - A 32bit flags word. The bit at bit position 0x0008 defines whether
-  the LMB is assigned to the the partition as of boot time.
+  the LMB is assigned to the partition as of boot time.
 
 ibm,dynamic-memory-v2
 
diff --git a/docs/specs/ppc-xive.rst b/docs/specs/ppc-xive.rst
index 148d57eb6ab2..83d43f658b90 100644
--- a/docs/specs/ppc-xive.rst
+++ b/docs/specs/ppc-xive.rst
@@ -163,7 +163,7 @@ Interrupt Priority Register (PIPR) is also updated using 
the IPB. This
 register represent the priority of the most favored pending
 notification.
 
-The PIPR is then compared to the the Current Processor Priority
+The PIPR is then compared to the Current Processor Priority
 Register (CPPR). If it is more favored (numerically less than), the
 CPU interrupt line is raised and the EO bit of the Notification Source
 Register (NSR) is updated to notify the presence of an exception for
diff --git a/docs/specs/tpm.txt b/docs/specs/tpm.txt
index 5d8c26b1adba..9c8cca042da8 100644
--- a/docs/specs/tpm.txt
+++ b/docs/specs/tpm.txt
@@ -89,7 +89,7 @@ TPM upon reboot. The PPI specification defines the operation 
requests and the
 actions the firmware has to take. The system administrator passes the operation
 request number to the firmware through an ACPI interface which writes this
 number to a memory location that the firmware knows. Upon reboot, the firmware
-finds the number and sends commands to the the TPM. The firmware writes the TPM
+finds the number and sends commands to the TPM. The firmware writes the TPM
 result code and the operation request number to a memory location that ACPI can
 read from and pass the result on to the administrator.
 
diff --git a/include/hw/xen/interface/io/blkif.h 
b/include/hw/xen/interface/io/blkif.h
index 8b1be50ce81e..d07fa1e07822 100644
--- a/include/hw/xen/interface/io/blkif.h
+++ b/include/hw/xen/interface/io/blkif.h
@@ -341,7 +341,7 @@
  *  access (even when it should be read-only). If the frontend hits the
  *  maximum number of allowed persistently mapped grants, it can fallback
  *  to non persistent mode. This will cause a performance degradation,
- *  since the the backend driver will still try to map those grants
+ *  since the backend driver will still try to map those grants
  *  persistently. Since the persistent grants protocol is compatible with
  *  the previous protocol, a frontend driver can choose to work in
  *  persistent mode even when the backend doesn't support it.
diff --git a/scripts/dump-guest-memory.py b/scripts/dump-guest-memory.py
index 2c587cbefc57..9371e4581308 100644
--- a/scripts/dump-guest-memory.py
+++ b/scripts/dump-guest-memory.py
@@ -170,7 +170,7 @@ class ELF(object):
 self.ehdr.e_phnum += 1
 
 def to_file(self, elf_file):
-"""Writes all ELF structures to the the passed file.
+"""Writes all ELF structures to the passed file.
 
 Structure:
 Ehdr
-- 
2.21.0




Re: [PATCH v4 05/20] libqtest: Add a layer of abstraciton to send/recv

2019-11-06 Thread Stefan Hajnoczi
On Wed, Oct 30, 2019 at 02:49:52PM +, Oleinik, Alexander wrote:
> @@ -360,6 +383,7 @@ void qtest_quit(QTestState *s)
>  g_free(s);
>  }
>  
> +
>  static void socket_send(int fd, const char *buf, size_t size)
>  {
>  size_t offset;
[...]
> diff --git a/tests/libqtest.h b/tests/libqtest.h
> index c9e21e05b3..31267fc915 100644
> --- a/tests/libqtest.h
> +++ b/tests/libqtest.h
> @@ -728,5 +728,4 @@ bool qtest_probe_child(QTestState *s);
>   * Set expected exit status of the child.
>   */
>  void qtest_set_expected_status(QTestState *s, int status);
> -
>  #endif

Please avoid whitespace changes.

Otherwise:

Reviewed-by: Stefan Hajnoczi 


signature.asc
Description: PGP signature


[PULL v3 0/3] Trivial branch patches

2019-11-06 Thread Laurent Vivier
The following changes since commit 36609b4fa36f0ac934874371874416f7533a5408:

  Merge remote-tracking branch 'remotes/palmer/tags/palmer-for-master-4.2-sf1' 
into staging (2019-11-02 17:59:03 +)

are available in the Git repository at:

  git://github.com/vivier/qemu.git tags/trivial-branch-pull-request

for you to fetch changes up to df59feb197cda31a8b807c13bf509259db9e018f:

  global: Squash 'the the' (2019-11-06 17:19:40 +0100)


Trivial fixes (20191105-v3)

v3: remove disas/libvixl/vixl/invalset.h changes
v2: remove patch from Greg that has lines with more than 80 columns



Dr. David Alan Gilbert (1):
  global: Squash 'the the'

Philippe Mathieu-Daudé (2):
  hw/misc/grlib_ahb_apb_pnp: Avoid crash when writing to PnP registers
  hw/misc/grlib_ahb_apb_pnp: Fix 8-bit accesses

 docs/interop/pr-helper.rst  |  2 +-
 docs/specs/ppc-spapr-hotplug.txt|  2 +-
 docs/specs/ppc-xive.rst |  2 +-
 docs/specs/tpm.txt  |  2 +-
 hw/misc/grlib_ahb_apb_pnp.c | 12 
 include/hw/xen/interface/io/blkif.h |  2 +-
 scripts/dump-guest-memory.py|  2 +-
 7 files changed, 18 insertions(+), 6 deletions(-)

-- 
2.21.0




QEMU HTML documentation now on qemu.org

2019-11-06 Thread Stefan Hajnoczi
Hi,
You can now access the latest QEMU HTML documentation built from
qemu.git/master nightly at:

  https://wiki.qemu.org/docs/qemu-doc.html
  https://wiki.qemu.org/docs/qemu-qmp-ref.html
  https://wiki.qemu.org/docs/qemu-ga-ref.html
  ...as well as interop/ and specs/

Feel free to link to the documentation from the QEMU website and/or
wiki!

The container image that builds the docs is here:

  https://github.com/stefanha/qemu-docs

It is hosted on QEMU's Rackspace cloud account.

Stefan


signature.asc
Description: PGP signature


Re: [Xen-devel] [PULL v2 0/3] Trivial branch patches

2019-11-06 Thread Laurent Vivier
Le 06/11/2019 à 17:05, Peter Maydell a écrit :
> On Tue, 5 Nov 2019 at 20:06, Laurent Vivier  wrote:
>>
>> Le 05/11/2019 à 20:20, no-re...@patchew.org a écrit :
>>> Patchew URL: 
>>> https://patchew.org/QEMU/20191105175010.2591-1-laur...@vivier.eu/
>>>
>>>
>>>
>>> Hi,
>>>
>>> This series seems to have some coding style problems. See output below for
>>> more information:
>>>
>>> Subject: [Xen-devel] [PULL v2 0/3] Trivial branch patches
>>> Type: series
>>> Message-id: 20191105175010.2591-1-laur...@vivier.eu
>>>
>>> === TEST SCRIPT BEGIN ===
>>> #!/bin/bash
>>> git rev-parse base > /dev/null || exit 0
>>> git config --local diff.renamelimit 0
>>> git config --local diff.renames True
>>> git config --local diff.algorithm histogram
>>> ./scripts/checkpatch.pl --mailback base..
>>> === TEST SCRIPT END ===
>>>
>>> Switched to a new branch 'test'
>>> 49a55f7 global: Squash 'the the'
>>> c0b5513 hw/misc/grlib_ahb_apb_pnp: Fix 8-bit accesses
>>> eb43395 hw/misc/grlib_ahb_apb_pnp: Avoid crash when writing to PnP registers
>>>
>>> === OUTPUT BEGIN ===
>>> 1/3 Checking commit eb43395bf8f1 (hw/misc/grlib_ahb_apb_pnp: Avoid crash 
>>> when writing to PnP registers)
>>> 2/3 Checking commit c0b5513f971a (hw/misc/grlib_ahb_apb_pnp: Fix 8-bit 
>>> accesses)
>>> 3/3 Checking commit 49a55f7feb19 (global: Squash 'the the')
>>> ERROR: do not use C99 // comments
>>> #26: FILE: disas/libvixl/vixl/invalset.h:105:
>>> +  // Note that this does not mean the backing storage is empty: it can 
>>> still
>>
>> As reported by David Gilbert, this is a false positive as this file is a
>> C++ file.
> 
> True, but it's also a third-party dependency that we have
> taken a copy of. If we care about fixing its typos in comments
> we should do that by submitting the fixes upstream. We should
> avoid making changes to our local copy of this code because
> it just makes it unnecessarily more difficult to do updates to
> newer versions.
> 
> Could you drop that change, please? (Sorry I didn't notice
> it going by when the patch was originally on list.)

Sure.

Thanks,
Laurent




Re: [PATCH v8 1/3] docs: improve qcow2 spec about extending image header

2019-11-06 Thread Vladimir Sementsov-Ogievskiy
18.10.2019 17:36, Vladimir Sementsov-Ogievskiy wrote:
> 18.10.2019 17:00, Eric Blake wrote:
>> On 10/18/19 4:47 AM, Vladimir Sementsov-Ogievskiy wrote:
>>> Make it more obvious how to add new fields to the version 3 header and
>>> how to interpret them.
>>>
>>> The specification is adjusted so for new defined optional fields:
>>
>> The specification is adjusted to make it clear that future fields are 
>> optional:
>>
>>>
>>> 1. Software may support some of these optional fields and ignore the
>>>     others, which means that features may be backported to downstream
>>>     Qemu independently.
>>> 3. If @header_length is higher than the highest field end that software
>>>     knows, it should assume that topmost unknown additional fields are
>>>     correct, and keep additional unknown fields as is on rewriting the
>>>     image.
>>> 3. If we want to add incompatible field (or a field, for which some its
>>>     values would be incompatible), it must be accompanied by
>>>     incompatible feature bit.
>>>
>>> Also the concept of "default is zero" is clarified, as it's strange to
>>> say that the value of the field is assumed to be zero for the software
>>> version which don't know about the field at all and don't know how to
>>> treat it be it zero or not.
>>>
>>
>> I'd also mention that we want to enforce 8-byte alignment in this cover 
>> letter.
>>
>>> Signed-off-by: Vladimir Sementsov-Ogievskiy 
>>> ---
>>>   docs/interop/qcow2.txt | 26 +++---
>>>   1 file changed, 23 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/docs/interop/qcow2.txt b/docs/interop/qcow2.txt
>>> index af5711e533..4709f3bb30 100644
>>> --- a/docs/interop/qcow2.txt
>>> +++ b/docs/interop/qcow2.txt
>>> @@ -79,9 +79,9 @@ The first cluster of a qcow2 image contains the file 
>>> header:
>>>   Offset into the image file at which the snapshot table
>>>   starts. Must be aligned to a cluster boundary.
>>> -If the version is 3 or higher, the header has the following additional 
>>> fields.
>>> -For version 2, the values are assumed to be zero, unless specified 
>>> otherwise
>>> -in the description of a field.
>>> +For version 2, header is always 72 bytes length and finishes here.
>>> +For version 3 or higher the header length is at least 104 bytes and has at
>>> +least next five fields, up to the @header_length field.
>>
>> For version 2, the header is exactly 72 bytes in length, and finishes here.
>> For version 3 or higher, the header length is at least 104 bytes, including 
>> the next fields through header_length.
>>
>>>    72 -  79:  incompatible_features
>>>   Bitmask of incompatible features. An implementation 
>>> must
>>> @@ -164,6 +164,26 @@ in the description of a field.
>>>   100 - 103:  header_length
>>>   Length of the header structure in bytes. For version 2
>>>   images, the length is always assumed to be 72 bytes.
>>> +    For version 3 it's at least 104 bytes.
>>
>> I'd also add a sentence that this field must be a multiple of 8.
>>
>>> +
>>> +Additional fields (version 3 and higher)
>>> +
>>> +The following fields of the header are optional: if software doesn't know 
>>> how
>>> +to interpret the field, it may be safely ignored, other than preserving the
>>> +field unchanged when rewriting the image header.
>>
>> Maybe:
>>
>> if software doesn't know how to interpret the field, it may be safely 
>> ignored unless a corresponding incompatible feature flag bit is set; 
>> however, the field should be preserved unchanged when rewriting the image 
>> header.
>>
>>> +
>>> +For all additional fields zero value equals to absence of field (absence is
>>> +when field.offset + field.size > @header_length). This implies
>>> +that if software want's to set fields up to some field not aligned to 
>>> multiply
>>> +of 8 it must align header up by zeroes. And on the other hand, if software
>>> +need some optional field which is absent it should assume that it's value 
>>> is
>>> +zero.
>>
>> Maybe:
>>
>> Each optional field that does not have a corresponding incompatible feature 
>> bit must support the value 0 that gives the same default behavior as when 
>> the optional field is omitted.
> 
> Hmmm. That doesn't work, as "corresponding" is something not actually 
> defined. Consider our zstd extension.
> 
> It has corresponding incompatible bit, therefore, this sentence doesn't apply 
> to it. But still, if incompatible bit is unset we can have this field. And 
> it's zero value must correspond
> to the absence of the field.
> 
> So, additional field may use incomaptible bit only for subset of its values.
> 
> But, I see, that you want to allow 0 value to not match field-absence if 
> incompatible bit is set?
> 
> So, may be
> 
> Additional fields has the following compatible behavior by default:
> 
> 1. If software doesn't know how to interpret the field, it may be safely 
> 

Re: [Xen-devel] [PULL v2 0/3] Trivial branch patches

2019-11-06 Thread Peter Maydell
On Tue, 5 Nov 2019 at 20:06, Laurent Vivier  wrote:
>
> Le 05/11/2019 à 20:20, no-re...@patchew.org a écrit :
> > Patchew URL: 
> > https://patchew.org/QEMU/20191105175010.2591-1-laur...@vivier.eu/
> >
> >
> >
> > Hi,
> >
> > This series seems to have some coding style problems. See output below for
> > more information:
> >
> > Subject: [Xen-devel] [PULL v2 0/3] Trivial branch patches
> > Type: series
> > Message-id: 20191105175010.2591-1-laur...@vivier.eu
> >
> > === TEST SCRIPT BEGIN ===
> > #!/bin/bash
> > git rev-parse base > /dev/null || exit 0
> > git config --local diff.renamelimit 0
> > git config --local diff.renames True
> > git config --local diff.algorithm histogram
> > ./scripts/checkpatch.pl --mailback base..
> > === TEST SCRIPT END ===
> >
> > Switched to a new branch 'test'
> > 49a55f7 global: Squash 'the the'
> > c0b5513 hw/misc/grlib_ahb_apb_pnp: Fix 8-bit accesses
> > eb43395 hw/misc/grlib_ahb_apb_pnp: Avoid crash when writing to PnP registers
> >
> > === OUTPUT BEGIN ===
> > 1/3 Checking commit eb43395bf8f1 (hw/misc/grlib_ahb_apb_pnp: Avoid crash 
> > when writing to PnP registers)
> > 2/3 Checking commit c0b5513f971a (hw/misc/grlib_ahb_apb_pnp: Fix 8-bit 
> > accesses)
> > 3/3 Checking commit 49a55f7feb19 (global: Squash 'the the')
> > ERROR: do not use C99 // comments
> > #26: FILE: disas/libvixl/vixl/invalset.h:105:
> > +  // Note that this does not mean the backing storage is empty: it can 
> > still
>
> As reported by David Gilbert, this is a false positive as this file is a
> C++ file.

True, but it's also a third-party dependency that we have
taken a copy of. If we care about fixing its typos in comments
we should do that by submitting the fixes upstream. We should
avoid making changes to our local copy of this code because
it just makes it unnecessarily more difficult to do updates to
newer versions.

Could you drop that change, please? (Sorry I didn't notice
it going by when the patch was originally on list.)

thanks
-- PMM



Re: [PATCH v2 00/21] iotests: Allow ./check -o data_file

2019-11-06 Thread Maxim Levitsky
On Tue, 2019-10-15 at 16:27 +0200, Max Reitz wrote:
> Hi,
> 
> The cover letter from v1 (explaining the motivation behind this series
> and the general structure) is here:
> 
> https://lists.nongnu.org/archive/html/qemu-block/2019-09/msg01323.html
> 
> 
> For v2, I’ve tried to address Maxim’s comments:
> - Patch 1 through 3: New
> - Patch 4: Only print feature bits instead of blacklisting stuff that we
>don’t need
> - Patch 5:
>   - Fix typo
>   - Add comment why 098 needs compat=1.1
> - Patch 16: Use _check_test_img
> - Patch 17: Use the new _filter_json_filename
> - Patch 18: Rethink the incompatible feature filter approach: Instead of
> filtering out the data_file bit, just check whether the
> dirty bit is present (because that is all we want to know)
> - Patch 19: Use the new _filter_json_filename
> - Patch 20: Rebase conflicts due to the changes to patch 5
> - Patch 21:
>   - Add and use _get_data_file
>   - Add a comment how the data_file_filter in _filter_qemu_img_map works
> 

Thank you! I reviewed the series, and it looks fine now.
Best regards,
Maxim Levitsky




Re: [PULL 00/11] Block patches

2019-11-06 Thread Peter Maydell
On Tue, 5 Nov 2019 at 15:43, Stefan Hajnoczi  wrote:
>
> The following changes since commit 36609b4fa36f0ac934874371874416f7533a5408:
>
>   Merge remote-tracking branch 
> 'remotes/palmer/tags/palmer-for-master-4.2-sf1' into staging (2019-11-02 
> 17:59:03 +)
>
> are available in the Git repository at:
>
>   https://github.com/stefanha/qemu.git tags/block-pull-request
>
> for you to fetch changes up to 9fdd7860adec188ed50d2530e9a819e8d953f9bb:
>
>   image-fuzzer: Use OSerror.strerror instead of tuple subscript (2019-11-05 
> 16:36:11 +0100)
>
> 
> Pull request
>
> Let's get the image fuzzer Python 3 changes merged in QEMU 4.2.
>
> 


Applied, thanks.

Please update the changelog at https://wiki.qemu.org/ChangeLog/4.2
for any user-visible changes.

-- PMM



Re: [PATCH v2 21/21] iotests: Allow check -o data_file

2019-11-06 Thread Maxim Levitsky
On Tue, 2019-10-15 at 16:27 +0200, Max Reitz wrote:
> The problem with allowing the data_file option is that you want to use a
> different data file per image used in the test.  Therefore, we need to
> allow patterns like -o data_file='$TEST_IMG.data_file'.
> 
> Then, we need to filter it out from qemu-img map, qemu-img create, and
> remove the data file in _rm_test_img.
> 
> Signed-off-by: Max Reitz 
> ---
>  tests/qemu-iotests/common.filter | 23 +--
>  tests/qemu-iotests/common.rc | 22 +-
>  2 files changed, 42 insertions(+), 3 deletions(-)
> 
> diff --git a/tests/qemu-iotests/common.filter 
> b/tests/qemu-iotests/common.filter
> index 63bc6f6f26..9dd05689d1 100644
> --- a/tests/qemu-iotests/common.filter
> +++ b/tests/qemu-iotests/common.filter
> @@ -121,7 +121,13 @@ _filter_actual_image_size()
>  # replace driver-specific options in the "Formatting..." line
>  _filter_img_create()
>  {
> -$SED -e "s#$REMOTE_TEST_DIR#TEST_DIR#g" \
> +data_file_filter=()
> +if data_file=$(_get_data_file "$TEST_IMG"); then
> +data_file_filter=(-e "s# data_file=$data_file##")
> +fi
> +
> +$SED "${data_file_filter[@]}" \
> +-e "s#$REMOTE_TEST_DIR#TEST_DIR#g" \
>  -e "s#$IMGPROTO:$TEST_DIR#TEST_DIR#g" \
>  -e "s#$TEST_DIR#TEST_DIR#g" \
>  -e "s#$IMGFMT#IMGFMT#g" \
> @@ -204,9 +210,22 @@ _filter_img_info()
>  # human and json output
>  _filter_qemu_img_map()
>  {
> +# Assuming the data_file value in $IMGOPTS contains a '$TEST_IMG',
> +# create a filter that replaces the data file name by $TEST_IMG.
> +# Example:
> +#   In $IMGOPTS: 'data_file=$TEST_IMG.data_file'
> +#   Then data_file_pattern == '\(.*\).data_file'
> +#   And  data_file_filter  == -e 's#\(.*\).data_file#\1#
> +data_file_filter=()
> +if data_file_pattern=$(_get_data_file '\\(.*\\)'); then
> +data_file_filter=(-e "s#$data_file_pattern#\\1#")
> +fi
> +
>  $SED -e 's/\([0-9a-fx]* *[0-9a-fx]* *\)[0-9a-fx]* */\1/g' \
>  -e 's/"offset": [0-9]\+/"offset": OFFSET/g' \
> --e 's/Mapped to *//' | _filter_testdir | _filter_imgfmt
> +-e 's/Mapped to *//' \
> +"${data_file_filter[@]}" \
> +| _filter_testdir | _filter_imgfmt
>  }
>  
>  _filter_nbd()
> diff --git a/tests/qemu-iotests/common.rc b/tests/qemu-iotests/common.rc
> index f3784077de..bed789a691 100644
> --- a/tests/qemu-iotests/common.rc
> +++ b/tests/qemu-iotests/common.rc
> @@ -277,6 +277,20 @@ _stop_nbd_server()
>  fi
>  }
>  
> +# Gets the data_file value from IMGOPTS and replaces the '$TEST_IMG'
> +# pattern by '$1'
> +# Caution: The replacement is done with sed, so $1 must be escaped
> +#  properly.  (The delimiter is '#'.)
> +_get_data_file()
> +{
> +if ! echo "$IMGOPTS" | grep -q 'data_file='; then
> +return 1
> +fi
> +
> +echo "$IMGOPTS" | sed -e 's/.*data_file=\([^,]*\).*/\1/' \
> +| sed -e "s#\\\$TEST_IMG#$1#"
> +}
> +
>  _make_test_img()
>  {
>  # extra qemu-img options can be added by tests
> @@ -297,7 +311,8 @@ _make_test_img()
>  fi
>  
>  if [ -n "$IMGOPTS" ]; then
> -optstr=$(_optstr_add "$optstr" "$IMGOPTS")
> +imgopts_expanded=$(echo "$IMGOPTS" | sed -e 
> "s#\\\$TEST_IMG#$img_name#")
> +optstr=$(_optstr_add "$optstr" "$imgopts_expanded")
>  fi
>  if [ -n "$IMGKEYSECRET" ]; then
>  object_options="--object secret,id=keysec0,data=$IMGKEYSECRET"
> @@ -376,6 +391,11 @@ _rm_test_img()
>  # Remove all the extents for vmdk
>  "$QEMU_IMG" info "$img" 2>/dev/null | grep 'filename:' | cut -f 2 
> -d: \
>  | xargs -I {} rm -f "{}"
> +elif [ "$IMGFMT" = "qcow2" ]; then
> +# Remove external data file
> +if data_file=$(_get_data_file "$img"); then
> +rm -f "$data_file"
> +fi
>  fi
>  rm -f "$img"
>  }


Reviewed-by: Maxim Levitsky 

Best regards,
Maxim Levitsky




Re: [PATCH v2 20/21] iotests: Disable data_file where it cannot be used

2019-11-06 Thread Maxim Levitsky
On Tue, 2019-10-15 at 16:27 +0200, Max Reitz wrote:
> Signed-off-by: Max Reitz 
> ---
>  tests/qemu-iotests/007 | 5 +++--
>  tests/qemu-iotests/014 | 2 ++
>  tests/qemu-iotests/015 | 5 +++--
>  tests/qemu-iotests/026 | 5 -
>  tests/qemu-iotests/029 | 5 +++--
>  tests/qemu-iotests/031 | 6 +++---
>  tests/qemu-iotests/036 | 5 +++--
>  tests/qemu-iotests/039 | 3 +++
>  tests/qemu-iotests/046 | 2 ++
>  tests/qemu-iotests/048 | 2 ++
>  tests/qemu-iotests/051 | 5 +++--
>  tests/qemu-iotests/058 | 5 +++--
>  tests/qemu-iotests/060 | 6 --
>  tests/qemu-iotests/061 | 6 --
>  tests/qemu-iotests/062 | 2 +-
>  tests/qemu-iotests/066 | 2 +-
>  tests/qemu-iotests/067 | 6 --
>  tests/qemu-iotests/068 | 5 +++--
>  tests/qemu-iotests/071 | 3 +++
>  tests/qemu-iotests/073 | 2 ++
>  tests/qemu-iotests/074 | 2 ++
>  tests/qemu-iotests/080 | 5 +++--
>  tests/qemu-iotests/090 | 2 ++
>  tests/qemu-iotests/098 | 6 --
>  tests/qemu-iotests/099 | 3 ++-
>  tests/qemu-iotests/103 | 5 +++--
>  tests/qemu-iotests/108 | 6 --
>  tests/qemu-iotests/112 | 5 +++--
>  tests/qemu-iotests/114 | 2 ++
>  tests/qemu-iotests/121 | 3 +++
>  tests/qemu-iotests/138 | 2 ++
>  tests/qemu-iotests/156 | 2 ++
>  tests/qemu-iotests/176 | 7 +--
>  tests/qemu-iotests/191 | 2 ++
>  tests/qemu-iotests/201 | 6 +++---
>  tests/qemu-iotests/214 | 3 ++-
>  tests/qemu-iotests/217 | 3 ++-
>  tests/qemu-iotests/220 | 5 +++--
>  tests/qemu-iotests/243 | 6 --
>  tests/qemu-iotests/244 | 5 +++--
>  tests/qemu-iotests/250 | 2 ++
>  tests/qemu-iotests/267 | 5 +++--
>  42 files changed, 117 insertions(+), 52 deletions(-)
> 


> diff --git a/tests/qemu-iotests/007 b/tests/qemu-iotests/007
> index 7d3544b479..160683adf8 100755
> --- a/tests/qemu-iotests/007
> +++ b/tests/qemu-iotests/007
> @@ -41,8 +41,9 @@ trap "_cleanup; exit \$status" 0 1 2 3 15
>  _supported_fmt qcow2
>  _supported_proto generic
>  # refcount_bits must be at least 4 so we can create ten internal snapshots
> -# (1 bit supports none, 2 bits support two, 4 bits support 14)
> -_unsupported_imgopts 'refcount_bits=\(1\|2\)[^0-9]'
> +# (1 bit supports none, 2 bits support two, 4 bits support 14);
> +# snapshot are generally impossible with external data files
> +_unsupported_imgopts 'refcount_bits=\(1\|2\)[^0-9]' data_file
ACK
>  
>  echo
>  echo "creating image"



> diff --git a/tests/qemu-iotests/014 b/tests/qemu-iotests/014
> index 2f728a1956..e1221c0fff 100755
> --- a/tests/qemu-iotests/014
> +++ b/tests/qemu-iotests/014
> @@ -43,6 +43,8 @@ trap "_cleanup; exit \$status" 0 1 2 3 15
>  _supported_fmt qcow2
>  _supported_proto file
>  _supported_os Linux
> +# Compression and snapshots do not work with external data files
> +_unsupported_imgopts data_file
ACK
>  
>  TEST_OFFSETS="0 4294967296"
>  TEST_OPS="writev read write readv"



> diff --git a/tests/qemu-iotests/015 b/tests/qemu-iotests/015
> index eec5387f3d..4d8effd0ae 100755
> --- a/tests/qemu-iotests/015
> +++ b/tests/qemu-iotests/015
> @@ -40,8 +40,9 @@ trap "_cleanup; exit \$status" 0 1 2 3 15
>  # actually any format that supports snapshots
>  _supported_fmt qcow2
>  _supported_proto generic
> -# Internal snapshots are (currently) impossible with refcount_bits=1
> -_unsupported_imgopts 'refcount_bits=1[^0-9]'
> +# Internal snapshots are (currently) impossible with refcount_bits=1,
> +# and generally impossible with external data files
ACK
> +_unsupported_imgopts 'refcount_bits=1[^0-9]' data_file
>  
>  echo
>  echo "creating image"


> diff --git a/tests/qemu-iotests/026 b/tests/qemu-iotests/026
> index 3430029ed6..a4aa74764f 100755
> --- a/tests/qemu-iotests/026
> +++ b/tests/qemu-iotests/026
> @@ -49,7 +49,10 @@ _supported_cache_modes writethrough none
>  # 32 and 64 bits do not work either, however, due to different leaked cluster
>  # count on error.
>  # Thus, the only remaining option is refcount_bits=16.
> -_unsupported_imgopts 'refcount_bits=\([^1]\|.\([^6]\|$\)\)'
> +#
> +# As for data_file, none of the refcount tests can work for it.
ACK
> +_unsupported_imgopts 'refcount_bits=\([^1]\|.\([^6]\|$\)\)' \
> +data_file
>  
>  echo "Errors while writing 128 kB"
>  echo



> diff --git a/tests/qemu-iotests/029 b/tests/qemu-iotests/029
> index 9254ede5e5..2161a4b87a 100755
> --- a/tests/qemu-iotests/029
> +++ b/tests/qemu-iotests/029
> @@ -42,8 +42,9 @@ trap "_cleanup; exit \$status" 0 1 2 3 15
>  _supported_fmt qcow2
>  _supported_proto generic
>  _unsupported_proto vxhs
> -# Internal snapshots are (currently) impossible with refcount_bits=1
> -_unsupported_imgopts 'refcount_bits=1[^0-9]'
> +# Internal snapshots are (currently) impossible with refcount_bits=1,
> +# and generally impossible with external data files
ACK
> +_unsupported_imgopts 'refcount_bits=1[^0-9]' data_file
>  
>  offset_size=24
>  offset_l1_size=36



> diff --git a/tests/qemu-iotests/031 b/tests/qemu-iotests/031
> index c44fcf91bb..646ecd593f 100755
> --- a/tests/qemu-iotests/031
> +++ b/tests/qemu-iotests/031
> @@ -40,9 +40,9 @@ trap 

Re: [PATCH v2 19/21] iotests: Make 198 work with data_file

2019-11-06 Thread Maxim Levitsky
On Tue, 2019-10-15 at 16:27 +0200, Max Reitz wrote:
> We do not care about the json:{} filenames here, so we can just filter
> them out and thus make the test work both with and without external data
> files.
> 
> Signed-off-by: Max Reitz 
> ---
>  tests/qemu-iotests/198 | 6 --
>  tests/qemu-iotests/198.out | 4 ++--
>  2 files changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/tests/qemu-iotests/198 b/tests/qemu-iotests/198
> index c8f824cfae..fb0d5a29d3 100755
> --- a/tests/qemu-iotests/198
> +++ b/tests/qemu-iotests/198
> @@ -92,13 +92,15 @@ echo
>  echo "== checking image base =="
>  $QEMU_IMG info --image-opts $IMGSPECBASE | _filter_img_info 
> --format-specific \
>  | sed -e "/^disk size:/ D" -e '/refcount bits:/ D' -e '/compat:/ D' \
> -  -e '/lazy refcounts:/ D' -e '/corrupt:/ D'
> +  -e '/lazy refcounts:/ D' -e '/corrupt:/ D' -e '/^\s*data file/ D' \
> +| _filter_json_filename
>  
>  echo
>  echo "== checking image layer =="
>  $QEMU_IMG info --image-opts $IMGSPECLAYER | _filter_img_info 
> --format-specific \
>  | sed -e "/^disk size:/ D" -e '/refcount bits:/ D' -e '/compat:/ D' \
> -  -e '/lazy refcounts:/ D' -e '/corrupt:/ D'
> +  -e '/lazy refcounts:/ D' -e '/corrupt:/ D' -e '/^\s*data file/ D' \
> +| _filter_json_filename
>  
>  
>  # success, all done
> diff --git a/tests/qemu-iotests/198.out b/tests/qemu-iotests/198.out
> index e86b175e39..831ce3a289 100644
> --- a/tests/qemu-iotests/198.out
> +++ b/tests/qemu-iotests/198.out
> @@ -32,7 +32,7 @@ read 16777216/16777216 bytes at offset 0
>  16 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
>  
>  == checking image base ==
> -image: json:{"encrypt.key-secret": "sec0", "driver": "IMGFMT", "file": 
> {"driver": "file", "filename": "TEST_DIR/t.IMGFMT.base"}}
> +image: json:{ /* filtered */ }
>  file format: IMGFMT
>  virtual size: 16 MiB (16777216 bytes)
>  Format specific information:
> @@ -74,7 +74,7 @@ Format specific information:
>  master key iters: 1024
>  
>  == checking image layer ==
> -image: json:{"encrypt.key-secret": "sec1", "driver": "IMGFMT", "file": 
> {"driver": "file", "filename": "TEST_DIR/t.IMGFMT"}}
> +image: json:{ /* filtered */ }
>  file format: IMGFMT
>  virtual size: 16 MiB (16777216 bytes)
>  backing file: TEST_DIR/t.IMGFMT.base


Reviewed-by: Maxim Levitsky 

Best regards,
Maxim Levitsky




Re: [PATCH v2 18/21] iotests: Make 137 work with data_file

2019-11-06 Thread Maxim Levitsky
On Tue, 2019-10-15 at 16:27 +0200, Max Reitz wrote:
> When using an external data file, there are no refcounts for data
> clusters.  We thus have to adjust the corruption test in this patch to
> not be based around a data cluster allocation, but the L2 table
> allocation (L2 tables are still refcounted with external data files).
> 
> Furthermore, we should not print qcow2.py's list of incompatible
> features because it differs depending on whether there is an external
> data file or not.
> 
> With those two changes, the test will work both with an external data
> files (once that options works with the iotests at all).
> 
> Signed-off-by: Max Reitz 
> ---
>  tests/qemu-iotests/137 | 15 +++
>  tests/qemu-iotests/137.out |  6 ++
>  2 files changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/tests/qemu-iotests/137 b/tests/qemu-iotests/137
> index 6cf2997577..7ae86892f7 100755
> --- a/tests/qemu-iotests/137
> +++ b/tests/qemu-iotests/137
> @@ -138,14 +138,21 @@ $QEMU_IO \
>  "$TEST_IMG" 2>&1 | _filter_qemu_io
>  
>  # The dirty bit must not be set
> -$PYTHON qcow2.py "$TEST_IMG" dump-header | grep incompatible_features
> +# (Filter the external data file bit)
> +if $PYTHON qcow2.py "$TEST_IMG" dump-header | grep incompatible_features \
> +| grep -q '\<0\>'
> +then
> +echo 'ERROR: Dirty bit set'
> +else
> +echo 'OK: Dirty bit not set'
> +fi
>  
>  # Similarly we can test whether corruption detection has been enabled:
> -# Create L1/L2, overwrite first entry in refcount block, allocate something.
> +# Create L1, overwrite refcounts, force allocation of L2 by writing
> +# data.
>  # Disabling the checks should fail, so the corruption must be detected.
>  _make_test_img 64M
> -$QEMU_IO -c "write 0 64k" "$TEST_IMG" | _filter_qemu_io
> -poke_file "$TEST_IMG" "$((0x2))" "\x00\x00"
> +poke_file "$TEST_IMG" "$((0x2))" "\x00\x00\x00\x00\x00\x00\x00\x00"
>  $QEMU_IO \
>  -c "reopen -o overlap-check=none,lazy-refcounts=42" \
>  -c "write 64k 64k" \
> 



> diff --git a/tests/qemu-iotests/137.out b/tests/qemu-iotests/137.out
> index bd4523a853..86377c80cd 100644
> --- a/tests/qemu-iotests/137.out
> +++ b/tests/qemu-iotests/137.out
> @@ -36,11 +36,9 @@ qemu-io: Unsupported value 'blubb' for qcow2 option 
> 'overlap-check'. Allowed are
>  wrote 512/512 bytes at offset 0
>  512 bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
>  ./common.rc: Killed  ( VALGRIND_QEMU="${VALGRIND_QEMU_IO}" 
> _qemu_proc_exec "${VALGRIND_LOGFILE}" "$QEMU_IO_PROG" $QEMU_IO_ARGS "$@" )
> -incompatible_features []
> +OK: Dirty bit not set
>  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=67108864
> -wrote 65536/65536 bytes at offset 0
> -64 KiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
>  qemu-io: Parameter 'lazy-refcounts' expects 'on' or 'off'
> -qcow2: Marking image as corrupt: Preventing invalid write on metadata 
> (overlaps with qcow2_header); further corruption events will be suppressed
> +qcow2: Marking image as corrupt: Preventing invalid allocation of L2 table 
> at offset 0; further corruption events will be suppressed
>  write failed: Input/output error
>  *** done


Reviewed-by: Maxim Levitsky 

Best regards,
Maxim Levitsky




Re: [PATCH v2 17/21] iotests: Make 110 work with data_file

2019-11-06 Thread Maxim Levitsky
On Tue, 2019-10-15 at 16:27 +0200, Max Reitz wrote:
> The only difference is that the json:{} filename of the image looks
> different.  We actually do not care about that filename in this test, we
> are only interested in (1) that there is a json:{} filename, and (2)
> whether the backing filename can be constructed.
> 
> So just filter out the json:{} data, thus making this test pass both
> with and without data_file.
> 
> Signed-off-by: Max Reitz 
> ---
>  tests/qemu-iotests/110 | 7 +--
>  tests/qemu-iotests/110.out | 4 ++--
>  2 files changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/tests/qemu-iotests/110 b/tests/qemu-iotests/110
> index f78df0e6e1..139c02c2cf 100755
> --- a/tests/qemu-iotests/110
> +++ b/tests/qemu-iotests/110
> @@ -67,6 +67,7 @@ echo
>  # Across blkdebug without a config file, you cannot reconstruct filenames, so
>  # qemu is incapable of knowing the directory of the top image from the 
> filename
>  # alone. However, using bdrv_dirname(), it should still work.
> +# (Filter out the json:{} filename so this test works with external data 
> files)
>  TEST_IMG="json:{
>  'driver': '$IMGFMT',
>  'file': {
> @@ -82,7 +83,8 @@ TEST_IMG="json:{
>  }
>  ]
>  }
> -}" _img_info | _filter_img_info | grep -v 'backing file format'
> +}" _img_info | _filter_img_info | grep -v 'backing file format' \
> +| _filter_json_filename
>  
>  echo
>  echo '=== Backing name is always relative to the backed image ==='
> @@ -114,7 +116,8 @@ TEST_IMG="json:{
>  }
>  ]
>  }
> -}" _img_info | _filter_img_info | grep -v 'backing file format'
> +}" _img_info | _filter_img_info | grep -v 'backing file format' \
> +| _filter_json_filename
>  
>  
>  # success, all done
> diff --git a/tests/qemu-iotests/110.out b/tests/qemu-iotests/110.out
> index f60b26390e..f835553a99 100644
> --- a/tests/qemu-iotests/110.out
> +++ b/tests/qemu-iotests/110.out
> @@ -11,7 +11,7 @@ backing file: t.IMGFMT.base (actual path: 
> TEST_DIR/t.IMGFMT.base)
>  
>  === Non-reconstructable filename ===
>  
> -image: json:{"driver": "IMGFMT", "file": {"set-state.0.event": "read_aio", 
> "image": {"driver": "file", "filename": "TEST_DIR/t.IMGFMT"}, "driver": 
> "blkdebug", "set-state.0.new_state": 42}}
> +image: json:{ /* filtered */ }
>  file format: IMGFMT
>  virtual size: 64 MiB (67108864 bytes)
>  backing file: t.IMGFMT.base (actual path: TEST_DIR/t.IMGFMT.base)
> @@ -22,7 +22,7 @@ Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=67108864 
> backing_file=t.IMGFMT.b
>  
>  === Nodes without a common directory ===
>  
> -image: json:{"driver": "IMGFMT", "file": {"children": [{"driver": "file", 
> "filename": "TEST_DIR/t.IMGFMT"}, {"driver": "file", "filename": 
> "TEST_DIR/t.IMGFMT.copy"}], "driver": "quorum", "vote-
> threshold": 1}}
> +image: json:{ /* filtered */ }
>  file format: IMGFMT
>  virtual size: 64 MiB (67108864 bytes)
>  backing file: t.IMGFMT.base (cannot determine actual path)

Reviewed-by: Maxim Levitsky 

Best regards,
Maxim Levitsky




Re: [PATCH v2 12/21] iotests: Drop IMGOPTS use in 267

2019-11-06 Thread Maxim Levitsky
On Tue, 2019-10-15 at 16:27 +0200, Max Reitz wrote:
> Overwriting IMGOPTS means ignoring all user-supplied options, which is
> not what we want.  Replace the current IMGOPTS use by a new BACKING_FILE
> variable.
> 
> Signed-off-by: Max Reitz 
> ---
>  tests/qemu-iotests/267 | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/tests/qemu-iotests/267 b/tests/qemu-iotests/267
> index d37a67c012..eda45449d4 100755
> --- a/tests/qemu-iotests/267
> +++ b/tests/qemu-iotests/267
> @@ -68,7 +68,11 @@ size=128M
>  
>  run_test()
>  {
> -_make_test_img $size
> +if [ -n "$BACKING_FILE" ]; then
> +_make_test_img -b "$BACKING_FILE" $size
> +else
> +_make_test_img $size
> +fi
>  printf "savevm snap0\ninfo snapshots\nloadvm snap0\n" | run_qemu "$@" | 
> _filter_date
>  }
>  
> @@ -119,12 +123,12 @@ echo
>  
>  TEST_IMG="$TEST_IMG.base" _make_test_img $size
>  
> -IMGOPTS="backing_file=$TEST_IMG.base" \
> +BACKING_FILE="$TEST_IMG.base" \
>  run_test -blockdev 
> driver=file,filename="$TEST_IMG.base",node-name=backing-file \
>   -blockdev driver=file,filename="$TEST_IMG",node-name=file \
>   -blockdev 
> driver=$IMGFMT,file=file,backing=backing-file,node-name=fmt
>  
> -IMGOPTS="backing_file=$TEST_IMG.base" \
> +BACKING_FILE="$TEST_IMG.base" \
>  run_test -blockdev 
> driver=file,filename="$TEST_IMG.base",node-name=backing-file \
>   -blockdev driver=$IMGFMT,file=backing-file,node-name=backing-fmt \
>   -blockdev driver=file,filename="$TEST_IMG",node-name=file \
> @@ -141,7 +145,7 @@ echo
>  echo "=== -blockdev with NBD server on the backing file ==="
>  echo
>  
> -IMGOPTS="backing_file=$TEST_IMG.base" _make_test_img $size
> +_make_test_img -b "$TEST_IMG.base" $size
>  cat <  nbd_server_start unix:$TEST_DIR/nbd
>  nbd_server_add -w backing-fmt

Reviewed-by: Maxim Levitsky 

Best regards,
Maxim Levitsky




Re: [PATCH v2 16/21] iotests: Make 091 work with data_file

2019-11-06 Thread Maxim Levitsky
On Tue, 2019-10-15 at 16:27 +0200, Max Reitz wrote:
> The image end offset as reported by qemu-img check is different when
> using an external data file; we do not care about its value here, so we
> can just filter it.  Incidentally, common.rc already has _check_test_img
> for us which does exactly that.
> 
> Signed-off-by: Max Reitz 
> ---
>  tests/qemu-iotests/091 | 2 +-
>  tests/qemu-iotests/091.out | 2 --
>  2 files changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/tests/qemu-iotests/091 b/tests/qemu-iotests/091
> index f4b44659ae..0874fa84c8 100755
> --- a/tests/qemu-iotests/091
> +++ b/tests/qemu-iotests/091
> @@ -101,7 +101,7 @@ echo "Check image pattern"
>  ${QEMU_IO} -c "read -P 0x22 0 4M" "${TEST_IMG}" | _filter_testdir | 
> _filter_qemu_io
>  
>  echo "Running 'qemu-img check -r all \$TEST_IMG'"
> -"${QEMU_IMG}" check -r all "${TEST_IMG}" 2>&1 | _filter_testdir | 
> _filter_qemu
> +_check_test_img -r all
>  
>  echo "*** done"
>  rm -f $seq.full
> diff --git a/tests/qemu-iotests/091.out b/tests/qemu-iotests/091.out
> index 5017f8c2d9..5ec7b00f13 100644
> --- a/tests/qemu-iotests/091.out
> +++ b/tests/qemu-iotests/091.out
> @@ -23,6 +23,4 @@ read 4194304/4194304 bytes at offset 0
>  4 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
>  Running 'qemu-img check -r all $TEST_IMG'
>  No errors were found on the image.
> -80/16384 = 0.49% allocated, 0.00% fragmented, 0.00% compressed clusters
> -Image end offset: 5570560
>  *** done
Reviewed-by: Maxim Levitsky 

Best regards,
Maxim Levitsky





Re: [PATCH v2 14/21] iotests: Use _rm_test_img for deleting test images

2019-11-06 Thread Maxim Levitsky
On Tue, 2019-10-15 at 16:27 +0200, Max Reitz wrote:
> Just rm will not delete external data files.  Use _rm_test_img every
> time we delete a test image.
> 
> (In the process, clean up the indentation of every _cleanup() this patch
> touches.)
> 
> ((Also, use quotes consistently.  I am happy to see unquoted instances
> like "rm -rf $TEST_DIR/..." go.))
> 
> Signed-off-by: Max Reitz 
> ---
>  tests/qemu-iotests/005 |  2 +-
>  tests/qemu-iotests/019 |  6 +++---
>  tests/qemu-iotests/020 |  6 +++---
>  tests/qemu-iotests/024 | 10 +-
>  tests/qemu-iotests/028 |  2 +-
>  tests/qemu-iotests/029 |  2 +-
>  tests/qemu-iotests/043 |  4 +++-
>  tests/qemu-iotests/048 |  2 +-
>  tests/qemu-iotests/050 |  4 ++--
>  tests/qemu-iotests/053 |  4 ++--
>  tests/qemu-iotests/058 |  2 +-
>  tests/qemu-iotests/059 |  2 +-
>  tests/qemu-iotests/061 |  2 +-
>  tests/qemu-iotests/063 |  6 --
>  tests/qemu-iotests/069 |  2 +-
>  tests/qemu-iotests/074 |  2 +-
>  tests/qemu-iotests/080 |  2 +-
>  tests/qemu-iotests/081 |  6 +++---
>  tests/qemu-iotests/085 |  9 ++---
>  tests/qemu-iotests/088 |  2 +-
>  tests/qemu-iotests/092 |  2 +-
>  tests/qemu-iotests/094 |  2 +-
>  tests/qemu-iotests/095 |  5 +++--
>  tests/qemu-iotests/099 |  7 ---
>  tests/qemu-iotests/109 |  4 ++--
>  tests/qemu-iotests/110 |  4 ++--
>  tests/qemu-iotests/122 |  6 --
>  tests/qemu-iotests/123 |  2 +-
>  tests/qemu-iotests/141 |  4 +++-
>  tests/qemu-iotests/142 |  2 +-
>  tests/qemu-iotests/144 |  4 +++-
>  tests/qemu-iotests/153 | 10 +++---
>  tests/qemu-iotests/156 |  8 ++--
>  tests/qemu-iotests/159 |  2 +-
>  tests/qemu-iotests/160 |  3 ++-
>  tests/qemu-iotests/161 |  4 ++--
>  tests/qemu-iotests/170 |  2 +-
>  tests/qemu-iotests/172 |  6 +++---
>  tests/qemu-iotests/173 |  3 ++-
>  tests/qemu-iotests/178 |  2 +-
>  tests/qemu-iotests/182 |  2 +-
>  tests/qemu-iotests/183 |  2 +-
>  tests/qemu-iotests/185 |  4 ++--
>  tests/qemu-iotests/187 |  6 +++---
>  tests/qemu-iotests/190 |  2 +-
>  tests/qemu-iotests/191 |  6 +++---
>  tests/qemu-iotests/195 |  2 +-
>  tests/qemu-iotests/197 |  2 +-
>  tests/qemu-iotests/200 |  3 ++-
>  tests/qemu-iotests/215 |  2 +-
>  tests/qemu-iotests/225 |  2 +-
>  tests/qemu-iotests/229 |  3 ++-
>  tests/qemu-iotests/232 |  4 +++-
>  tests/qemu-iotests/243 |  2 +-
>  tests/qemu-iotests/244 |  4 ++--
>  tests/qemu-iotests/247 |  4 +++-
>  tests/qemu-iotests/249 |  4 ++--
>  tests/qemu-iotests/252 |  2 +-
>  58 files changed, 119 insertions(+), 96 deletions(-)
> 
> diff --git a/tests/qemu-iotests/005 b/tests/qemu-iotests/005
> index 58442762fe..2b651f2c37 100755
> --- a/tests/qemu-iotests/005
> +++ b/tests/qemu-iotests/005
> @@ -62,7 +62,7 @@ if [ "$IMGFMT" = "raw" ]; then
>  if ! truncate --size=5T "$TEST_IMG"; then
>  _notrun "file system on $TEST_DIR does not support large enough 
> files"
>  fi
> -rm "$TEST_IMG"
> +_rm_test_img "$TEST_IMG"
>  fi
>  
>  echo
> diff --git a/tests/qemu-iotests/019 b/tests/qemu-iotests/019
> index b4f5234609..813a84acac 100755
> --- a/tests/qemu-iotests/019
> +++ b/tests/qemu-iotests/019
> @@ -30,9 +30,9 @@ status=1# failure is the default!
>  
>  _cleanup()
>  {
> - _cleanup_test_img
> -rm -f "$TEST_IMG.base"
> -rm -f "$TEST_IMG.orig"
> +_cleanup_test_img
> +_rm_test_img "$TEST_IMG.base"
> +_rm_test_img "$TEST_IMG.orig"
>  }
>  trap "_cleanup; exit \$status" 0 1 2 3 15
>  
> diff --git a/tests/qemu-iotests/020 b/tests/qemu-iotests/020
> index f41b92f35f..20f8f185d0 100755
> --- a/tests/qemu-iotests/020
> +++ b/tests/qemu-iotests/020
> @@ -28,9 +28,9 @@ status=1# failure is the default!
>  
>  _cleanup()
>  {
> - _cleanup_test_img
> -rm -f "$TEST_IMG.base"
> -rm -f "$TEST_IMG.orig"
> +_cleanup_test_img
> +_rm_test_img "$TEST_IMG.base"
> +_rm_test_img "$TEST_IMG.orig"
>  }
>  trap "_cleanup; exit \$status" 0 1 2 3 15
>  
> diff --git a/tests/qemu-iotests/024 b/tests/qemu-iotests/024
> index 23298c6f59..e2e766241e 100755
> --- a/tests/qemu-iotests/024
> +++ b/tests/qemu-iotests/024
> @@ -29,12 +29,12 @@ status=1  # failure is the default!
>  _cleanup()
>  {
>  _cleanup_test_img
> -rm -f "$TEST_DIR/t.$IMGFMT.base_old"
> -rm -f "$TEST_DIR/t.$IMGFMT.base_new"
> +_rm_test_img "$TEST_DIR/t.$IMGFMT.base_old"
> +_rm_test_img "$TEST_DIR/t.$IMGFMT.base_new"
>  
> -rm -f "$TEST_DIR/subdir/t.$IMGFMT"
> -rm -f "$TEST_DIR/subdir/t.$IMGFMT.base_old"
> -rm -f "$TEST_DIR/subdir/t.$IMGFMT.base_new"
> +_rm_test_img "$TEST_DIR/subdir/t.$IMGFMT"
> +_rm_test_img "$TEST_DIR/subdir/t.$IMGFMT.base_old"
> +_rm_test_img "$TEST_DIR/subdir/t.$IMGFMT.base_new"
>  rmdir "$TEST_DIR/subdir" 2> /dev/null
>  }
>  trap "_cleanup; exit \$status" 0 1 2 3 15
> diff --git a/tests/qemu-iotests/028 b/tests/qemu-iotests/028
> index 71301ec6e5..caf1258647 100755
> --- a/tests/qemu-iotests/028
> +++ b/tests/qemu-iotests/028
> @@ -32,7 +32,7 @@ status=1# failure is the 

Re: logfile issue

2019-11-06 Thread Robert Foley
On Mon, 4 Nov 2019 at 07:13, Alex Bennée  wrote:

> I wonder if using RCU to swap out the new and old FD would make things a
> bit smoother here? You would have to tweak the qemu_log_lock/unlock
> functions to preserve the current FD around the lock and call_rcu a
> freeing function when a new handle is set.

Thanks for your comments on this.
We agree that using RCU is a great solution here.  We have this patch
well underway and plan to post a patch in the next few days.

-Rob

On Mon, 4 Nov 2019 at 07:13, Alex Bennée  wrote:
>
>
> Robert Foley  writes:
>
> > We hit an issue when trying to change the log file from the monitor
> > console.  The root of the issue here is that the qemu_logfile handle
> > is not thread safe.  So when we try to close the file, we end up with
> > a seg fault.  The full analysis is below along with some possible
> > solutions.
> > Will plan to post a patch soon, but any comments or opinions on our
> > proposed solution would be appreciated.  Thanks.
> >
> > The version of QEMU we are using is: master as of about Oct 15,
> > 9020e9526cd08c4dc99d54dba48730de2908c970.
> >
> > This is what we did to reproduce the issue.
> > First we enable logging and select the log file.
> > (qemu) log in_asm,out_asm,op
> > (qemu) logfile asm.out
> >
> > Then we start this command in the guest.  This just keeps the guest
> > performing operations that result in logging to be constantly
> > generated.
> > $ for i in {0..1000}; do ls -l; done
> >
> > Next we switch to the monitor console and change the file.
> > (qemu) logfile asm_new.log
> >
> > This action causes a seg fault.  Please see the stack trace (below).
> >
> > The code, which changes the log file unconditionally
> > (qemu_set_log_filename()), closes the qemu_logfile, sets it to NULL,
> > and then opens the new file.
> > Since the file handle is still in use, we end up with a seg fault when
> > the code which is trying to log ends up using a NULL file handle.
>
> Yep, good catch.
>
> > We are considering a few solutions.
> >
> > A straightforward solution would be to simply prevent the file from
> > being changed while logging is enabled.  In other words, force the
> > user to first disable logging before changing the log file.
> > This solution seems to cover the general case.  However, if a user
> > were to disable logging and change the log file in quick succession,
> > we would still be subject to a similar race.  A log call could still
> > make it through the logging enable check and proceed to use a file
> > handle that gets changed to NULL.
> >
> > Another option is to add a mutex to prevent the qemu_logfile handle
> > from being changed while it is in use.  This certainly works and has
> > the advantage of being fairly straightforward.  Also we are thinking
> > that since the mutex would only be used when logging is enabled it has
> > the advantage of not having an effect on the normal case performance.
> > Another option is to implement a simple atomic ref count and prevent
> > the file from being changed while there are outstanding references.
>
> The mutex is the simplest but I wonder if it show up on heavy usage? The
> log file is already doing file locking for the areas that want
> contiguous log statements.
>
> I wonder if using RCU to swap out the new and old FD would make things a
> bit smoother here? You would have to tweak the qemu_log_lock/unlock
> functions to preserve the current FD around the lock and call_rcu a
> freeing function when a new handle is set.
>
> > We are leaning towards the mutex option, and plan to post a patch
> > soon, but would appreciate comments or opinions on this solution.
> >
> > Thanks,
> > Rob Foley
> >
> > stack trace
> > ==
> > Thread 10 "qemu-system-aar" received signal SIGSEGV, Segmentation fault.
> > [Switching to Thread 0x113f9d90 (LWP 9493)] __flockfile
> > (stream=0x0) at ../sysdeps/pthread/flockfile.c:27
> > 27 ../sysdeps/pthread/flockfile.c: No such file or directory.
> > (gdb) bt
> > #0  __flockfile (stream=0x0) at ../sysdeps/pthread/flockfile.c:27
> > #1  0xe0fac8b8 in qemu_flockfile (f=) at
> > /home/rob/qemu/qemu_unchanged/include/sysemu/os-posix.h:87
> > #2  qemu_log_lock () at /home/rob/qemu/qemu_unchanged/include/qemu/log.h:57
> > #3  translator_loop (ops=0xe17f1348 ,
> > db=0x113f9088, db@entry=0x113f9098,
> > cpu=cpu@entry=0xaaab0a52bc50,
> > tb=tb@entry=0x4c92d000 ,
> > max_insns=max_insns@entry=512) at
> > /home/rob/qemu/qemu_unchanged/accel/tcg/translator.c:121
> > #4  0xe10c1c18 in gen_intermediate_code
> > (cpu=cpu@entry=0xaaab0a52bc50, tb=tb@entry=0x4c92d000
> > , max_insns=max_insns@entry=512)
> > at /home/rob/qemu/qemu_unchanged/target/arm/translate.c:11320
> > #5  0xe0fab248 in tb_gen_code (cpu=0xaaab0a52bc50,
> > cpu@entry=0xabe2a000, pc=187650897458448, cs_base=65536,
> > flags=43690, cflags=-16252928, cflags@entry=524288)
> > at 

Re: [PATCH v2 10/21] iotests: Replace IMGOPTS= by -o

2019-11-06 Thread Maxim Levitsky
On Tue, 2019-10-15 at 16:27 +0200, Max Reitz wrote:
> Tests should not overwrite all user-supplied image options, but only add
> to it (which will effectively overwrite conflicting values).  Accomplish
> this by passing options to _make_test_img via -o instead of $IMGOPTS.
> 
> For some tests, there is no functional change because they already only
> appended options to IMGOPTS.  For these, this patch is just a
> simplification.
> 
> For others, this is a change, so they now heed user-specified $IMGOPTS.
> Some of those tests do not work with all image options, though, so we
> need to disable them accordingly.
> 
> Signed-off-by: Max Reitz 
> ---
>  tests/qemu-iotests/031 |  9 ---
>  tests/qemu-iotests/039 | 24 ++
>  tests/qemu-iotests/059 | 18 ++---
>  tests/qemu-iotests/060 |  6 ++---
>  tests/qemu-iotests/061 | 57 ++
>  tests/qemu-iotests/079 |  3 +--
>  tests/qemu-iotests/106 |  2 +-
>  tests/qemu-iotests/108 |  2 +-
>  tests/qemu-iotests/112 | 32 
>  tests/qemu-iotests/115 |  3 +--
>  tests/qemu-iotests/121 |  6 ++---
>  tests/qemu-iotests/125 |  2 +-
>  tests/qemu-iotests/137 |  2 +-
>  tests/qemu-iotests/138 |  3 +--
>  tests/qemu-iotests/175 |  2 +-
>  tests/qemu-iotests/190 |  2 +-
>  tests/qemu-iotests/191 |  3 +--
>  tests/qemu-iotests/220 |  4 ++-
>  tests/qemu-iotests/243 |  6 +++--
>  tests/qemu-iotests/244 | 10 +---
>  tests/qemu-iotests/250 |  3 +--
>  tests/qemu-iotests/265 |  2 +-
>  22 files changed, 100 insertions(+), 101 deletions(-)
> 



> diff --git a/tests/qemu-iotests/031 b/tests/qemu-iotests/031
> index a3c25ec237..c44fcf91bb 100755
> --- a/tests/qemu-iotests/031
> +++ b/tests/qemu-iotests/031
> @@ -40,19 +40,22 @@ trap "_cleanup; exit \$status" 0 1 2 3 15
>  # This tests qcow2-specific low-level functionality
>  _supported_fmt qcow2
>  _supported_proto file
> +# We want to test compat=0.10, which does not support refcount widths
> +# other than 16
> +_unsupported_imgopts 'refcount_bits=\([^1]\|.\([^6]\|$\)\)'
In theory the test could be cloned to only restrict refcount_bits to 16 for the 
0.10 version
but this is probably not worth it given the nature of the test.

>  
>  CLUSTER_SIZE=65536
>  
>  # qcow2.py output depends on the exact options used, so override the command
>  # line here as an exception
> -for IMGOPTS in "compat=0.10" "compat=1.1"; do
> +for compat in "compat=0.10" "compat=1.1"; do
>  
>  echo
> -echo = Testing with -o $IMGOPTS =
> +echo = Testing with -o $compat =
>  echo
>  echo === Create image with unknown header extension ===
>  echo
> -_make_test_img 64M
> +_make_test_img -o $compat 64M
>  $PYTHON qcow2.py "$TEST_IMG" add-header-ext 0x12345678 "This is a test 
> header extension"
>  $PYTHON qcow2.py "$TEST_IMG" dump-header
>  _check_test_img
> 


> diff --git a/tests/qemu-iotests/039 b/tests/qemu-iotests/039
> index 325da63a4c..99563bf126 100755
> --- a/tests/qemu-iotests/039
> +++ b/tests/qemu-iotests/039
> @@ -50,8 +50,7 @@ size=128M
>  echo
>  echo "== Checking that image is clean on shutdown =="
>  
> -IMGOPTS="compat=1.1,lazy_refcounts=on"
> -_make_test_img $size
> +_make_test_img -o "compat=1.1,lazy_refcounts=on" $size
>  
>  $QEMU_IO -c "write -P 0x5a 0 512" "$TEST_IMG" | _filter_qemu_io
>  
> @@ -62,8 +61,7 @@ _check_test_img
>  echo
>  echo "== Creating a dirty image file =="
>  
> -IMGOPTS="compat=1.1,lazy_refcounts=on"
> -_make_test_img $size
> +_make_test_img -o "compat=1.1,lazy_refcounts=on" $size
>  
>  _NO_VALGRIND \
>  $QEMU_IO -c "write -P 0x5a 0 512" \
> @@ -98,8 +96,7 @@ $QEMU_IO -c "read -P 0x5a 0 512" "$TEST_IMG" | 
> _filter_qemu_io
>  echo
>  echo "== Opening a dirty image read/write should repair it =="
>  
> -IMGOPTS="compat=1.1,lazy_refcounts=on"
> -_make_test_img $size
> +_make_test_img -o "compat=1.1,lazy_refcounts=on" $size
>  
>  _NO_VALGRIND \
>  $QEMU_IO -c "write -P 0x5a 0 512" \
> @@ -117,8 +114,7 @@ $PYTHON qcow2.py "$TEST_IMG" dump-header | grep 
> incompatible_features
>  echo
>  echo "== Creating an image file with lazy_refcounts=off =="
>  
> -IMGOPTS="compat=1.1,lazy_refcounts=off"
> -_make_test_img $size
> +_make_test_img -o "compat=1.1,lazy_refcounts=off" $size
>  
>  _NO_VALGRIND \
>  $QEMU_IO -c "write -P 0x5a 0 512" \
> @@ -132,11 +128,9 @@ _check_test_img
>  echo
>  echo "== Committing to a backing file with lazy_refcounts=on =="
>  
> -IMGOPTS="compat=1.1,lazy_refcounts=on"
> -TEST_IMG="$TEST_IMG".base _make_test_img $size
> +TEST_IMG="$TEST_IMG".base _make_test_img -o "compat=1.1,lazy_refcounts=on" 
> $size
>  
> -IMGOPTS="compat=1.1,lazy_refcounts=on,backing_file=$TEST_IMG.base"
> -_make_test_img $size
> +_make_test_img -o "compat=1.1,lazy_refcounts=on,backing_file=$TEST_IMG.base" 
> $size
>  
>  $QEMU_IO -c "write 0 512" "$TEST_IMG" | _filter_qemu_io
>  $QEMU_IMG commit "$TEST_IMG"
> @@ -151,8 +145,7 @@ TEST_IMG="$TEST_IMG".base _check_test_img
>  echo

Re: [PATCH v2 05/21] iotests: Replace IMGOPTS by _unsupported_imgopts

2019-11-06 Thread Maxim Levitsky
On Tue, 2019-10-15 at 16:27 +0200, Max Reitz wrote:
> Some tests require compat=1.1 and thus set IMGOPTS='compat=1.1'
> globally.  That is not how it should be done; instead, they should
> simply set _unsupported_imgopts to compat=0.10 (compat=1.1 is the
> default anyway).
> 
> This makes the tests heed user-specified $IMGOPTS.  Some do not work
> with all image options, though, so we need to disable them accordingly.
> 
> Signed-off-by: Max Reitz 
> ---
>  tests/qemu-iotests/036 | 3 +--
>  tests/qemu-iotests/060 | 4 ++--
>  tests/qemu-iotests/062 | 3 ++-
>  tests/qemu-iotests/066 | 3 ++-
>  tests/qemu-iotests/068 | 3 ++-
>  tests/qemu-iotests/098 | 4 ++--
>  6 files changed, 11 insertions(+), 9 deletions(-)
> 
> diff --git a/tests/qemu-iotests/036 b/tests/qemu-iotests/036
> index 5f929ad3be..bbaf0ef45b 100755
> --- a/tests/qemu-iotests/036
> +++ b/tests/qemu-iotests/036
> @@ -43,9 +43,8 @@ trap "_cleanup; exit \$status" 0 1 2 3 15
>  # This tests qcow2-specific low-level functionality
>  _supported_fmt qcow2
>  _supported_proto file
> -
>  # Only qcow2v3 and later supports feature bits
> -IMGOPTS="compat=1.1"
> +_unsupported_imgopts 'compat=0.10'
>  
>  echo
>  echo === Image with unknown incompatible feature bit ===
> diff --git a/tests/qemu-iotests/060 b/tests/qemu-iotests/060
> index b91d8321bb..9c2ef42522 100755
> --- a/tests/qemu-iotests/060
> +++ b/tests/qemu-iotests/060
> @@ -48,6 +48,8 @@ _filter_io_error()
>  _supported_fmt qcow2
>  _supported_proto file
>  _supported_os Linux
> +# These tests only work for compat=1.1 images with refcount_bits=16
> +_unsupported_imgopts 'compat=0.10' 'refcount_bits=\([^1]\|.\([^6]\|$\)\)'
Looks like the reason for that is that the test hardcodes (or guesses that is) 
various qcow2 structures
thing I have seen few times already in the iotests.
Not now but sometime in the future it would be nice to extend qcow2.py (or 
something
like that) to dump location of all qcow2 structures so that the guesswork could 
be eliminated.

>  
>  rt_offset=65536  # 0x1 (XXX: just an assumption)
>  rb_offset=131072 # 0x2 (XXX: just an assumption)
> @@ -55,8 +57,6 @@ l1_offset=196608 # 0x3 (XXX: just an assumption)
>  l2_offset=262144 # 0x4 (XXX: just an assumption)
>  l2_offset_after_snapshot=524288 # 0x8 (XXX: just an assumption)
>  
> -IMGOPTS="compat=1.1"
> -
>  OPEN_RW="open -o overlap-check=all $TEST_IMG"
>  # Overlap checks are done before write operations only, therefore opening an
>  # image read-only makes the overlap-check option irrelevant
> diff --git a/tests/qemu-iotests/062 b/tests/qemu-iotests/062
> index d5f818fcce..ac0d2a9a3b 100755
> --- a/tests/qemu-iotests/062
> +++ b/tests/qemu-iotests/062
> @@ -40,8 +40,9 @@ trap "_cleanup; exit \$status" 0 1 2 3 15
>  # This tests qocw2-specific low-level functionality
If you respin that patch for some reason, you could fix the typo above.
>  _supported_fmt qcow2
>  _supported_proto generic
> +# We need zero clusters and snapshots
> +_unsupported_imgopts 'compat=0.10' 'refcount_bits=1[^0-9]'
>  
> -IMGOPTS="compat=1.1"
>  IMG_SIZE=64M
>  
>  echo
> diff --git a/tests/qemu-iotests/066 b/tests/qemu-iotests/066
> index 28f8c98412..00eb80d89e 100755
> --- a/tests/qemu-iotests/066
> +++ b/tests/qemu-iotests/066
> @@ -39,9 +39,10 @@ trap "_cleanup; exit \$status" 0 1 2 3 15
>  # This tests qocw2-specific low-level functionality
^^ Same here
>  _supported_fmt qcow2
>  _supported_proto generic
> +# We need zero clusters and snapshots
> +_unsupported_imgopts 'compat=0.10' 'refcount_bits=1[^0-9]'
>  
>  # Intentionally create an unaligned image
> -IMGOPTS="compat=1.1"
>  IMG_SIZE=$((64 * 1024 * 1024 + 512))
>  
>  echo
> diff --git a/tests/qemu-iotests/068 b/tests/qemu-iotests/068
> index 22f5ca3ba6..65650fca9a 100755
> --- a/tests/qemu-iotests/068
> +++ b/tests/qemu-iotests/068
> @@ -39,8 +39,9 @@ trap "_cleanup; exit \$status" 0 1 2 3 15
>  # This tests qocw2-specific low-level functionality
>  _supported_fmt qcow2
>  _supported_proto generic
> +# Internal snapshots are (currently) impossible with refcount_bits=1
> +_unsupported_imgopts 'compat=0.10' 'refcount_bits=1[^0-9]'
>  
> -IMGOPTS="compat=1.1"
>  IMG_SIZE=128K
>  
>  case "$QEMU_DEFAULT_MACHINE" in
> diff --git a/tests/qemu-iotests/098 b/tests/qemu-iotests/098
> index 1c1d1c468f..700068b328 100755
> --- a/tests/qemu-iotests/098
> +++ b/tests/qemu-iotests/098
> @@ -40,8 +40,8 @@ trap "_cleanup; exit \$status" 0 1 2 3 15
>  
>  _supported_fmt qcow2
>  _supported_proto file
> -
> -IMGOPTS="compat=1.1"
> +# The code path we want to test here only works for compat=1.1 images
> +_unsupported_imgopts 'compat=0.10'
>  
>  for event in l1_update empty_image_prepare reftable_update refblock_alloc; do
>  


Reviewed-by: Maxim Levitsky 

Best regards,
Maxim Levitsky




Re: [PATCH v2 04/21] iotests: Filter refcount_order in 036

2019-11-06 Thread Maxim Levitsky
On Tue, 2019-10-15 at 16:27 +0200, Max Reitz wrote:
> This test can run just fine with other values for refcount_bits, so we
> should filter the value from qcow2.py's dump-header.  In fact, we can
> filter everything but the feature bits and header extensions, because
> that is what the test is about.

> 
> (036 currently ignores user-specified image options, but that will be
> fixed in the next patch.)
> 
> Signed-off-by: Max Reitz 
> ---
>  tests/qemu-iotests/036 |  9 ---
>  tests/qemu-iotests/036.out | 48 --
>  2 files changed, 6 insertions(+), 51 deletions(-)
> 
> diff --git a/tests/qemu-iotests/036 b/tests/qemu-iotests/036
> index f06ff67408..5f929ad3be 100755
> --- a/tests/qemu-iotests/036
> +++ b/tests/qemu-iotests/036
> @@ -55,7 +55,8 @@ $PYTHON qcow2.py "$TEST_IMG" set-feature-bit incompatible 63
>  
>  # Without feature table
>  $PYTHON qcow2.py "$TEST_IMG" del-header-ext 0x6803f857
> -$PYTHON qcow2.py "$TEST_IMG" dump-header
> +$PYTHON qcow2.py "$TEST_IMG" dump-header | grep features
> +$PYTHON qcow2.py "$TEST_IMG" dump-header-exts
>  _img_info
>  
>  # With feature table containing bit 63
> @@ -103,14 +104,16 @@ echo === Create image with unknown autoclear feature 
> bit ===
>  echo
>  _make_test_img 64M
>  $PYTHON qcow2.py "$TEST_IMG" set-feature-bit autoclear 63
> -$PYTHON qcow2.py "$TEST_IMG" dump-header
> +$PYTHON qcow2.py "$TEST_IMG" dump-header | grep features
> +$PYTHON qcow2.py "$TEST_IMG" dump-header-exts
>  
>  echo
>  echo === Repair image ===
>  echo
>  _check_test_img -r all
>  
> -$PYTHON qcow2.py "$TEST_IMG" dump-header
> +$PYTHON qcow2.py "$TEST_IMG" dump-header | grep features
> +$PYTHON qcow2.py "$TEST_IMG" dump-header-exts
>  
>  # success, all done
>  echo "*** done"
> diff --git a/tests/qemu-iotests/036.out b/tests/qemu-iotests/036.out
> index 15229a9604..0b52b934e1 100644
> --- a/tests/qemu-iotests/036.out
> +++ b/tests/qemu-iotests/036.out
> @@ -3,25 +3,9 @@ QA output created by 036
>  === Image with unknown incompatible feature bit ===
>  
>  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=67108864
> -magic 0x514649fb
> -version   3
> -backing_file_offset   0x0
> -backing_file_size 0x0
> -cluster_bits  16
> -size  67108864
> -crypt_method  0
> -l1_size   1
> -l1_table_offset   0x3
> -refcount_table_offset 0x1
> -refcount_table_clusters   1
> -nb_snapshots  0
> -snapshot_offset   0x0
>  incompatible_features [63]
>  compatible_features   []
>  autoclear_features[]
> -refcount_order4
> -header_length 104
> -
>  qemu-img: Could not open 'TEST_DIR/t.IMGFMT': Unsupported IMGFMT feature(s): 
> Unknown incompatible feature: 8000
>  qemu-img: Could not open 'TEST_DIR/t.IMGFMT': Unsupported IMGFMT feature(s): 
> Test feature
>  
> @@ -37,25 +21,9 @@ qemu-img: Could not open 'TEST_DIR/t.IMGFMT': Unsupported 
> IMGFMT feature(s): tes
>  === Create image with unknown autoclear feature bit ===
>  
>  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=67108864
> -magic 0x514649fb
> -version   3
> -backing_file_offset   0x0
> -backing_file_size 0x0
> -cluster_bits  16
> -size  67108864
> -crypt_method  0
> -l1_size   1
> -l1_table_offset   0x3
> -refcount_table_offset 0x1
> -refcount_table_clusters   1
> -nb_snapshots  0
> -snapshot_offset   0x0
>  incompatible_features []
>  compatible_features   []
>  autoclear_features[63]
> -refcount_order4
> -header_length 104
> -
>  Header extension:
>  magic 0x6803f857
>  length192
> @@ -65,25 +33,9 @@ data  
>  === Repair image ===
>  
>  No errors were found on the image.
> -magic 0x514649fb
> -version   3
> -backing_file_offset   0x0
> -backing_file_size 0x0
> -cluster_bits  16
> -size  67108864
> -crypt_method  0
> -l1_size   1
> -l1_table_offset   0x3
> -refcount_table_offset 0x1
> -refcount_table_clusters   1
> -nb_snapshots  0
> -snapshot_offset   0x0
>  incompatible_features []
>  compatible_features   []
>  autoclear_features[]
> -refcount_order4
> -header_length 104
> -
>  Header extension:
>  magic 0x6803f857
>  length192

Great!
Reviewed-by: Maxim Levitsky 

Best regards,
Maxim Levitsky




Re: [PATCH v2 03/21] iotests: Add _filter_json_filename

2019-11-06 Thread Maxim Levitsky
On Tue, 2019-10-15 at 16:27 +0200, Max Reitz wrote:
> Signed-off-by: Max Reitz 
> ---
>  tests/qemu-iotests/common.filter | 24 
>  1 file changed, 24 insertions(+)
> 
> diff --git a/tests/qemu-iotests/common.filter 
> b/tests/qemu-iotests/common.filter
> index 9f418b4881..63bc6f6f26 100644
> --- a/tests/qemu-iotests/common.filter
> +++ b/tests/qemu-iotests/common.filter
> @@ -227,5 +227,29 @@ _filter_qmp_empty_return()
>  grep -v '{"return": {}}'
>  }
>  
> +_filter_json_filename()
> +{
> +$PYTHON -c 'import sys
> +result, *fnames = sys.stdin.read().split("json:{")

Very minor nitpick, maybe I would give 'fnames' a more generic name,
since its is just result of a split, thus not really a list of filenames.
Feel free to ignore that though.

> +depth = 0
> +for fname in fnames:
> +depth += 1 # For the opening brace in the split separator
> +for chr_i, chr in enumerate(fname):
> +if chr == "{":
> +depth += 1
> +elif chr == "}":
> +depth -= 1
> +if depth == 0:
> +break
> +
> +# json:{} filenames may be nested; filter out everything from
> +# inside the outermost one
> +if depth == 0:
> +chr_i += 1 # First character past the filename
> +result += "json:{ /* filtered */ }" + fname[chr_i:]
> +
> +sys.stdout.write(result)'
> +}
> +
>  # make sure this script returns success
>  true

I must admit that I haven't run tested it, but it looks like it should work.
Reviewed-by: Maxim Levitsky 

Best regards,
Maxim Levitsky





Re: [PATCH v3 00/12] linux-user sparc fixes

2019-11-06 Thread Laurent Vivier
Le 06/11/2019 à 15:58, no-re...@patchew.org a écrit :
> Patchew URL: 
> https://patchew.org/QEMU/20191106113318.10226-1-richard.hender...@linaro.org/
> 
> 
> 
> Hi,
> 
> This series seems to have some coding style problems. See output below for
> more information:
> 
> Subject: [PATCH v3 00/12] linux-user sparc fixes
> Type: series
> Message-id: 20191106113318.10226-1-richard.hender...@linaro.org
> 
> === TEST SCRIPT BEGIN ===
> #!/bin/bash
> git rev-parse base > /dev/null || exit 0
> git config --local diff.renamelimit 0
> git config --local diff.renames True
> git config --local diff.algorithm histogram
> ./scripts/checkpatch.pl --mailback base..
> === TEST SCRIPT END ===
> 
> Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384
> From https://github.com/patchew-project/qemu
>  - [tag update]  patchew/20191106130309.6737-1-jandr...@gmail.com -> 
> patchew/20191106130309.6737-1-jandr...@gmail.com
>  - [tag update]  patchew/20191106141424.27244-1-edgar.igles...@gmail.com 
> -> patchew/20191106141424.27244-1-edgar.igles...@gmail.com
>  * [new tag] 
> patchew/20191106145127.23700-1-marcel.apfelb...@gmail.com -> 
> patchew/20191106145127.23700-1-marcel.apfelb...@gmail.com
> Switched to a new branch 'test'
> 33486ee linux-user/alpha: Set r20 secondary return value
> 4c5f970 linux-user/sparc: Fix cpu_clone_regs_*
> 38c0642 linux-user: Introduce cpu_clone_regs_parent
> 8fd10b2 linux-user: Rename cpu_clone_regs to cpu_clone_regs_child
> 1c6ebcb linux-user/sparc64: Fix target_signal_frame
> b1257ef linux-user/sparc: Fix WREG usage in setup_frame
> 5f40252 linux-user/sparc: Use WREG_SP constant in sparc/signal.c
> 2e7ffe6 linux-user/sparc: Begin using WREG constants in sparc/signal.c
> b87f31db linux-user/sparc: Use WREG constants in sparc/target_cpu.h
> 08fdb43 target/sparc: Define an enumeration for accessing env->regwptr
> 7e876dd tests/tcg/multiarch/linux-test: Fix error check for shmat
> 4dae54d scripts/qemu-binfmt-conf: Update for sparc64
> 
> === OUTPUT BEGIN ===
> 1/12 Checking commit 4dae54d6afb3 (scripts/qemu-binfmt-conf: Update for 
> sparc64)
> WARNING: line over 80 characters
> #36: FILE: scripts/qemu-binfmt-conf.sh:41:
> +sparc64_magic='\x7fELF\x02\x02\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x2b'
> 
> ERROR: line over 90 characters
> #37: FILE: scripts/qemu-binfmt-conf.sh:42:
> +sparc64_mask='\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff'
> 

All magic and mask are like this in scripts/qemu-binfmt-conf.sh, these
errors can be ignored.

Thanks,
Laurent




Re: [PATCH v2 02/21] iotests/qcow2.py: Split feature fields into bits

2019-11-06 Thread Maxim Levitsky
On Tue, 2019-10-15 at 16:27 +0200, Max Reitz wrote:
> Print the feature fields as a set of bits so that filtering is easier.
> 
> Signed-off-by: Max Reitz 
> ---
>  tests/qemu-iotests/031.out  | 36 +--
>  tests/qemu-iotests/036.out  | 18 +-
>  tests/qemu-iotests/039.out  | 22 ++--
>  tests/qemu-iotests/060.out  | 20 +--
>  tests/qemu-iotests/061.out  | 72 ++---
>  tests/qemu-iotests/137.out  |  2 +-
>  tests/qemu-iotests/qcow2.py | 18 +++---
>  7 files changed, 99 insertions(+), 89 deletions(-)
> 
> diff --git a/tests/qemu-iotests/031.out b/tests/qemu-iotests/031.out
> index 68a74d03b9..d535e407bc 100644
> --- a/tests/qemu-iotests/031.out
> +++ b/tests/qemu-iotests/031.out
> @@ -18,9 +18,9 @@ refcount_table_offset 0x1
>  refcount_table_clusters   1
>  nb_snapshots  0
>  snapshot_offset   0x0
> -incompatible_features 0x0
> -compatible_features   0x0
> -autoclear_features0x0
> +incompatible_features []
> +compatible_features   []
> +autoclear_features[]
>  refcount_order4
>  header_length 72
>  
> @@ -46,9 +46,9 @@ refcount_table_offset 0x1
>  refcount_table_clusters   1
>  nb_snapshots  0
>  snapshot_offset   0x0
> -incompatible_features 0x0
> -compatible_features   0x0
> -autoclear_features0x0
> +incompatible_features []
> +compatible_features   []
> +autoclear_features[]
>  refcount_order4
>  header_length 72
>  
> @@ -74,9 +74,9 @@ refcount_table_offset 0x1
>  refcount_table_clusters   1
>  nb_snapshots  0
>  snapshot_offset   0x0
> -incompatible_features 0x0
> -compatible_features   0x0
> -autoclear_features0x0
> +incompatible_features []
> +compatible_features   []
> +autoclear_features[]
>  refcount_order4
>  header_length 72
>  
> @@ -109,9 +109,9 @@ refcount_table_offset 0x1
>  refcount_table_clusters   1
>  nb_snapshots  0
>  snapshot_offset   0x0
> -incompatible_features 0x0
> -compatible_features   0x0
> -autoclear_features0x0
> +incompatible_features []
> +compatible_features   []
> +autoclear_features[]
>  refcount_order4
>  header_length 104
>  
> @@ -142,9 +142,9 @@ refcount_table_offset 0x1
>  refcount_table_clusters   1
>  nb_snapshots  0
>  snapshot_offset   0x0
> -incompatible_features 0x0
> -compatible_features   0x0
> -autoclear_features0x0
> +incompatible_features []
> +compatible_features   []
> +autoclear_features[]
>  refcount_order4
>  header_length 104
>  
> @@ -175,9 +175,9 @@ refcount_table_offset 0x1
>  refcount_table_clusters   1
>  nb_snapshots  0
>  snapshot_offset   0x0
> -incompatible_features 0x0
> -compatible_features   0x0
> -autoclear_features0x0
> +incompatible_features []
> +compatible_features   []
> +autoclear_features[]
>  refcount_order4
>  header_length 104
>  
> diff --git a/tests/qemu-iotests/036.out b/tests/qemu-iotests/036.out
> index e489b44386..15229a9604 100644
> --- a/tests/qemu-iotests/036.out
> +++ b/tests/qemu-iotests/036.out
> @@ -16,9 +16,9 @@ refcount_table_offset 0x1
>  refcount_table_clusters   1
>  nb_snapshots  0
>  snapshot_offset   0x0
> -incompatible_features 0x8000
> -compatible_features   0x0
> -autoclear_features0x0
> +incompatible_features [63]
> +compatible_features   []
> +autoclear_features[]
>  refcount_order4
>  header_length 104
>  
> @@ -50,9 +50,9 @@ refcount_table_offset 0x1
>  refcount_table_clusters   1
>  nb_snapshots  0
>  snapshot_offset   0x0
> -incompatible_features 0x0
> -compatible_features   0x0
> -autoclear_features0x8000
> +incompatible_features []
> +compatible_features   []
> +autoclear_features[63]
>  refcount_order4
>  header_length 104
>  
> @@ -78,9 +78,9 @@ refcount_table_offset 0x1
>  refcount_table_clusters   1
>  nb_snapshots  0
>  snapshot_offset   0x0
> -incompatible_features 0x0
> -compatible_features   0x0
> -autoclear_features0x0
> +incompatible_features []
> +compatible_features   []
> +autoclear_features[]
>  refcount_order4
>  header_length 104
>  
> diff --git a/tests/qemu-iotests/039.out b/tests/qemu-iotests/039.out
> index 2e356d51b6..bdafa3ace3 100644
> --- a/tests/qemu-iotests/039.out
> +++ b/tests/qemu-iotests/039.out
> @@ -4,7 +4,7 @@ QA output created by 039
>  Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=134217728
>  wrote 512/512 bytes at offset 

Re: [PATCH v2 01/21] iotests/qcow2.py: Add dump-header-exts

2019-11-06 Thread Maxim Levitsky
On Tue, 2019-10-15 at 16:27 +0200, Max Reitz wrote:
> This is useful for tests that want to whitelist fields from dump-header
> (with grep) but still print all header extensions.
> 
> Signed-off-by: Max Reitz 
> ---
>  tests/qemu-iotests/qcow2.py | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/tests/qemu-iotests/qcow2.py b/tests/qemu-iotests/qcow2.py
> index b392972d1b..d813b4fc81 100755
> --- a/tests/qemu-iotests/qcow2.py
> +++ b/tests/qemu-iotests/qcow2.py
> @@ -154,6 +154,10 @@ def cmd_dump_header(fd):
>  h.dump()
>  h.dump_extensions()
>  
> +def cmd_dump_header_exts(fd):
> +h = QcowHeader(fd)
> +h.dump_extensions()
> +
>  def cmd_set_header(fd, name, value):
>  try:
>  value = int(value, 0)
> @@ -230,6 +234,7 @@ def cmd_set_feature_bit(fd, group, bit):
>  
>  cmds = [
>  [ 'dump-header',  cmd_dump_header,  0, 'Dump image 
> header and header extensions' ],
> +[ 'dump-header-exts', cmd_dump_header_exts, 0, 'Dump image 
> header extensions' ],
>  [ 'set-header',   cmd_set_header,   2, 'Set a field in 
> the header'],
>  [ 'add-header-ext',   cmd_add_header_ext,   2, 'Add a header 
> extension' ],
>  [ 'add-header-ext-stdio', cmd_add_header_ext_stdio, 1, 'Add a header 
> extension, data from stdin' ],
Reviewed-by: Maxim Levitsky 

Best regards,
Maxim Levitsky




Re: [RFC PATCH 00/18] Add qemu-storage-daemon

2019-11-06 Thread Max Reitz
On 06.11.19 15:58, Kevin Wolf wrote:
> Am 06.11.2019 um 15:37 hat Max Reitz geschrieben:
>> On 17.10.19 15:01, Kevin Wolf wrote:
>>> This series adds a new tool 'qemu-storage-daemon', which can be used to
>>> export and perform operations on block devices.
>>
>> Looks good to me.
>>
>> I remember a discussion at some KVM Forum a couple of years ago where
>> someone (Berto?) was asking about adding QMP to qemu-nbd.  I found it a
>> pragmatic solution, but I remember that Markus was against it, based on
>> the fact that we wanted qemu -M none.
> 
> Yes, but it turned out that qemu -M none is a bit too heavyweight in
> practice and fixing that would involve a lot of work. As I understand it
> (mostly what I took from discussions on the list), even if someone were
> interested in doing that and started now, it's the kind of thing that
> would take multiple years.

I didn’t want to give the impression I wouldn’t agree. O:-)

(I agree completely, and basically that was my
understanding/opinion/feeling back when we discussed it, too.)

> As long as we keep the code simple and the interesting parts are just
> reused and shared with the system emulator and other tools, it shouldn't
> be hard to maintain.
> 
>> Well, but anyway.  Just as I didn’t have anything against adding QMP to
>> qemu-nbd, I don’t have anything against adding a new application that
>> kind of fulfills the same purpose.  And I think introducing a new
>> application instead of reusing qemu-nbd that focuses on all-around QAPI
>> compatibility (which qemu-nbd decidedly does not have) makes sense.
> 
> Yes, QAPI is one big reason for creating a new tool that doesn't need to
> support the old qemu-nbd command line. Another is that we can add other
> types of exports that are not NBD.

Sure.

>> The only thing I don’t like is the name, but that’s what  is for.
>> :-)
> 
> I'm open for suggestions, but I thought 'qsd' was a bit too terse. :-)
> 
> (Actually, maybe we could even pick something that doesn't mention
> storage or block? After all, it can do all kinds of QEMU backends in
> theory. Not sure if there's any standalone use for them, but who
> knows...)

Be careful, if we stuff too much into it, we’ll end up with just qemu
again. :-)

Max



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH v2 0/2] Avoid sending zero-size packets

2019-11-06 Thread Stefan Hajnoczi
On Mon, Jul 22, 2019 at 01:24:44PM +, Oleinik, Alexander wrote:
> While fuzzing the virtio-net tx vq, I ran into an assertion failure due
> to iov_copy offsets larger than the total iov size. Though there is
> a check to cover this, it does not execute when !n->has_vnet_hdr. This
> patch tries to fix this. 
> The call stack for the assertion failure:
> 
> #8 in __assert_fail (libc.so.6+0x300f1)
> #9 in iov_copy iov.c:266:5
> #10 in virtio_net_flush_tx virtio-net.c:2073:23
> #11 in virtio_net_tx_bh virtio-net.c:2197:11
> #12 in aio_bh_poll async.c:118:13
> #13 in aio_dispatch aio-posix.c:460:5
> #14 in aio_ctx_dispatch async.c:261:5
> #15 in g_main_context_dispatch (libglib-2.0.so.0+0x4df2d)
> #16 in glib_pollfds_poll main-loop.c:213:9
> #17 in os_host_main_loop_wait main-loop.c:236
> #18 in main_loop_wait main-loop.c:512
> #19 in virtio_net_tx_fuzz virtio-net-fuzz.c:160:3
> 
> v2: add details to  comment for the change to qemu_sendv_packet_async
> 
> Alexander Oleinik (2):
>   net: assert that tx packets have nonzero size
>   virtio-net: check that tx packet has positive size
> 
>  hw/net/virtio-net.c | 15 +--
>  net/net.c   |  9 +
>  2 files changed, 18 insertions(+), 6 deletions(-)
> 
> -- 
> 2.20.1

Ping


signature.asc
Description: PGP signature


Re: [PATCH v4 00/20] Add virtual device fuzzing support

2019-11-06 Thread Stefan Hajnoczi
On Wed, Oct 30, 2019 at 08:23:57AM -0700, no-re...@patchew.org wrote:
> Patchew URL: https://patchew.org/QEMU/20191030144926.11873-1-alx...@bu.edu/
> 
> 
> 
> Hi,
> 
> This series failed the docker-quick@centos7 build test. Please find the 
> testing commands and
> their output below. If you have Docker installed, you can probably reproduce 
> it
> locally.
> 
> === TEST SCRIPT BEGIN ===
> #!/bin/bash
> make docker-image-centos7 V=1 NETWORK=1
> time make docker-test-quick@centos7 SHOW_ENV=1 J=14 NETWORK=1
> === TEST SCRIPT END ===
> 
>   CC  tests/test-qapi-types-sub-sub-module.o
>   CC  tests/test-qapi-visit.o
>   CC  tests/include/test-qapi-visit-sub-module.o
> /tmp/qemu-test/src/tests/test-char.c:31:13: error: static declaration of 
> 'main_loop' follows non-static declaration
>  static void main_loop(void)
>  ^
> In file included from /tmp/qemu-test/src/tests/test-char.c:10:0:
> /tmp/qemu-test/src/include/sysemu/sysemu.h:117:6: note: previous declaration 
> of 'main_loop' was here
>  void main_loop(void);
>   ^
> make: *** [tests/test-char.o] Error 1
> make: *** Waiting for unfinished jobs
> Traceback (most recent call last):
>   File "./tests/docker/docker.py", line 662, in 

Oops, the main_loop() change definitely broke tests/test-char.c.  Please
take a look.

Stefan


signature.asc
Description: PGP signature


Re: [PATCH v4 06/20] module: check module wasn't already initialized

2019-11-06 Thread Stefan Hajnoczi
On Wed, Oct 30, 2019 at 02:49:52PM +, Oleinik, Alexander wrote:
> From: Alexander Oleinik 
> 
> The virtual-device fuzzer must initialize QOM, prior to running
> vl:qemu_init, so that it can use the qos_graph to identify the arguments
> required to initialize a guest for libqos-assisted fuzzing. This change
> prevents errors when vl:qemu_init tries to (re)initialize the previously
> initialized QOM module.
> 
> Signed-off-by: Alexander Oleinik 
> ---
>  util/module.c | 7 +++
>  1 file changed, 7 insertions(+)

Reviewed-by: Stefan Hajnoczi 


signature.asc
Description: PGP signature


  1   2   3   >