From: Liu Jingqi <jingqi.liu@intel.com>

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 <jingqi.liu@intel.com>
Signed-off-by: Tao Xu <tao3.xu@intel.com>
---
 numa.c          | 124 ++++++++++++++++++++++++++++++++++++++++++++++++
 qapi/misc.json  |  92 ++++++++++++++++++++++++++++++++++-
 qemu-options.hx |  28 ++++++++++-
 3 files changed, 241 insertions(+), 3 deletions(-)

diff --git a/numa.c b/numa.c
index 9ee4f6f258..97b77356ad 100644
--- a/numa.c
+++ b/numa.c
@@ -40,6 +40,7 @@
 #include "qemu/option.h"
 #include "qemu/config-file.h"
 #include "qemu/cutils.h"
+#include "hw/acpi/hmat.h"
 
 QemuOptsList qemu_numa_opts = {
     .name = "numa",
@@ -180,6 +181,123 @@ static void parse_numa_distance(NumaDistOptions *dist, Error **errp)
     have_numa_distance = true;
 }
 
+static void parse_numa_hmat_lb(MachineState *ms, NumaHmatLBOptions *node,
+                               Error **errp)
+{
+    struct numa_hmat_lb_info *hmat_lb = 0;
+
+    if (node->data_type <= HMATLB_DATA_TYPE_WRITE_LATENCY) {
+        if (!node->has_latency) {
+            error_setg(errp, "Please specify the latency.");
+            return;
+        }
+        if (node->has_bandwidth) {
+            error_setg(errp, "Please do not specify the bandwidth "
+                       "since the data type is latency.");
+            return;
+        }
+        if (node->has_base_bw) {
+            error_setg(errp, "Please do not specify the base-bw "
+                       "since the data type is latency.");
+            return;
+        }
+    }
+
+    if (node->data_type >= HMATLB_DATA_TYPE_ACCESS_BANDWIDTH) {
+        if (!node->has_bandwidth) {
+            error_setg(errp, "Please specify the bandwidth.");
+            return;
+        }
+        if (node->has_latency) {
+            error_setg(errp, "Please do not specify the latency "
+                       "since the data type is bandwidth.");
+            return;
+        }
+        if (node->has_base_lat) {
+            error_setg(errp, "Please do not specify the base-lat "
+                       "since the data type is bandwidth.");
+            return;
+        }
+    }
+
+    if (node->initiator >= nb_numa_nodes) {
+        error_setg(errp, "Invalid initiator=%"
+                   PRIu16 ", it should be less than %d.",
+                   node->initiator, nb_numa_nodes);
+        return;
+    }
+    if (!numa_info[node->initiator].is_initiator) {
+        error_setg(errp, "Invalid initiator=%"
+                   PRIu16 ", it isn't an initiator proximity domain.",
+                   node->initiator);
+        return;
+    }
+
+    if (node->target >= nb_numa_nodes) {
+        error_setg(errp, "Invalid initiator=%"
+                   PRIu16 ", it should be less than %d.",
+                   node->target, nb_numa_nodes);
+        return;
+    }
+    if (!numa_info[node->target].is_target) {
+        error_setg(errp, "Invalid target=%"
+                   PRIu16 ", it isn't a target proximity domain.",
+                   node->target);
+        return;
+    }
+
+    if (node->has_latency) {
+        hmat_lb = hmat_lb_info[node->hierarchy][node->data_type];
+        if (!hmat_lb) {
+            hmat_lb = g_malloc0(sizeof(*hmat_lb));
+            hmat_lb_info[node->hierarchy][node->data_type] = hmat_lb;
+        } else if (hmat_lb->latency[node->initiator][node->target]) {
+            error_setg(errp, "Duplicate configuration of the latency for "
+                       "initiator=%" PRIu16 " and target=%" PRIu16 ".",
+                       node->initiator, node->target);
+            return;
+        }
+
+        /* Only the first time of setting the base unit is valid. */
+        if ((hmat_lb->base_lat == 0) && (node->has_base_lat)) {
+            hmat_lb->base_lat = node->base_lat;
+        }
+
+        hmat_lb->latency[node->initiator][node->target] = node->latency;
+    }
+
+    if (node->has_bandwidth) {
+        hmat_lb = hmat_lb_info[node->hierarchy][node->data_type];
+
+        if (!hmat_lb) {
+            hmat_lb = g_malloc0(sizeof(*hmat_lb));
+            hmat_lb_info[node->hierarchy][node->data_type] = hmat_lb;
+        } else if (hmat_lb->bandwidth[node->initiator][node->target]) {
+            error_setg(errp, "Duplicate configuration of the bandwidth for "
+                       "initiator=%" PRIu16 " and target=%" PRIu16 ".",
+                       node->initiator, node->target);
+            return;
+        }
+
+        /* Only the first time of setting the base unit is valid. */
+        if (hmat_lb->base_bw == 0) {
+            if (!node->has_base_bw) {
+                error_setg(errp, "Please provide the base-bw!");
+                return;
+            } else {
+                hmat_lb->base_bw = node->base_bw;
+            }
+        }
+
+        hmat_lb->bandwidth[node->initiator][node->target] = node->bandwidth;
+    }
+
+    if (hmat_lb) {
+        hmat_lb->hierarchy = node->hierarchy;
+        hmat_lb->data_type = node->data_type;
+    }
+}
+
 static
 void set_numa_options(MachineState *ms, NumaOptions *object, Error **errp)
 {
@@ -213,6 +331,12 @@ void set_numa_options(MachineState *ms, NumaOptions *object, Error **errp)
         machine_set_cpu_numa_node(ms, qapi_NumaCpuOptions_base(&object->u.cpu),
                                   &err);
         break;
+    case NUMA_OPTIONS_TYPE_HMAT_LB:
+        parse_numa_hmat_lb(ms, &object->u.hmat_lb, &err);
+        if (err) {
+            goto end;
+        }
+        break;
     default:
         abort();
     }
diff --git a/qapi/misc.json b/qapi/misc.json
index 24d20a880a..b18eb28459 100644
--- a/qapi/misc.json
+++ b/qapi/misc.json
@@ -2746,10 +2746,12 @@
 #
 # @cpu: property based CPU(s) to node mapping (Since: 2.10)
 #
+# @hmat-lb: memory latency and bandwidth information (Since: 2.13)
+#
 # Since: 2.1
 ##
 { 'enum': 'NumaOptionsType',
-  'data': [ 'node', 'dist', 'cpu' ] }
+  'data': [ 'node', 'dist', 'cpu', 'hmat-lb' ] }
 
 ##
 # @NumaOptions:
@@ -2764,7 +2766,8 @@
   'data': {
     'node': 'NumaNodeOptions',
     'dist': 'NumaDistOptions',
-    'cpu': 'NumaCpuOptions' }}
+    'cpu': 'NumaCpuOptions',
+    'hmat-lb': 'NumaHmatLBOptions' }}
 
 ##
 # @NumaNodeOptions:
@@ -2827,6 +2830,91 @@
    'base': 'CpuInstanceProperties',
    'data' : {} }
 
+##
+# @HmatLBMemoryHierarchy:
+#
+# The memory hierarchy in the System Locality Latency
+# and Bandwidth Information Structure of HMAT
+#
+# @memory: the structure represents the memory performance
+#
+# @last-level: last level memory of memory side cached memory
+#
+# @1st-level: first level memory of memory side cached memory
+#
+# @2nd-level: second level memory of memory side cached memory
+#
+# @3rd-level: third level memory of memory side cached memory
+#
+# Since: 2.13
+##
+{ 'enum': 'HmatLBMemoryHierarchy',
+  'data': [ 'memory', 'last-level', '1st-level',
+            '2nd-level', '3rd-level' ] }
+
+##
+# @HmatLBDataType:
+#
+# Data type in the System Locality Latency
+# and Bandwidth Information Structure of HMAT
+#
+# @access-latency: access latency
+#
+# @read-latency: read latency
+#
+# @write-latency: write latency
+#
+# @access-bandwidth: access bandwitch
+#
+# @read-bandwidth: read bandwidth
+#
+# @write-bandwidth: write bandwidth
+#
+# Since: 2.13
+##
+{ 'enum': 'HmatLBDataType',
+  'data': [ 'access-latency', 'read-latency', 'write-latency',
+            'access-bandwidth', 'read-bandwidth', 'write-bandwidth' ] }
+
+##
+# @NumaHmatLBOptions:
+#
+# Set the system locality latency and bandwidth information
+# between Initiator and Target proximity Domains.
+#
+# @initiator: the Initiator Proximity Domain.
+#
+# @target: the Target Proximity Domain.
+#
+# @hierarchy: the Memory Hierarchy. Indicates the performance
+#             of memory or side cache.
+#
+# @data-type: presents the type of data, access/read/write
+#             latency or hit latency.
+#
+# @base-lat: the base unit for latency in nanoseconds.
+#
+# @base-bw: the base unit for bandwidth in megabytes per second(MB/s).
+#
+# @latency: the value of latency based on Base Unit from @initiator
+#           to @target proximity domain.
+#
+# @bandwidth: the value of bandwidth based on Base Unit between
+#             @initiator and @target proximity domain.
+#
+# Since: 2.13
+##
+{ 'struct': 'NumaHmatLBOptions',
+  'data': {
+   'initiator': 'uint16',
+   'target': 'uint16',
+   'hierarchy': 'HmatLBMemoryHierarchy',
+   'data-type': 'HmatLBDataType',
+   '*base-lat': 'uint64',
+   '*base-bw': 'uint64',
+   '*latency': 'uint16',
+   '*bandwidth': 'uint16' }}
+
 ##
 # @HostMemPolicy:
 #
diff --git a/qemu-options.hx b/qemu-options.hx
index d4f3564b78..88f078c846 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -163,16 +163,19 @@ DEF("numa", HAS_ARG, QEMU_OPTION_numa,
     "-numa node[,mem=size][,cpus=firstcpu[-lastcpu]][,nodeid=node]\n"
     "-numa node[,memdev=id][,cpus=firstcpu[-lastcpu]][,nodeid=node]\n"
     "-numa dist,src=source,dst=destination,val=distance\n"
-    "-numa cpu,node-id=node[,socket-id=x][,core-id=y][,thread-id=z]\n",
+    "-numa cpu,node-id=node[,socket-id=x][,core-id=y][,thread-id=z]\n"
+    "-numa hmat-lb,initiator=node,target=node,hierarchy=memory|last-level,data-type=access-latency|read-latency|write-latency[,base-lat=blat][,base-bw=bbw][,latency=lat][,bandwidth=bw]\n",
     QEMU_ARCH_ALL)
 STEXI
 @item -numa node[,mem=@var{size}][,cpus=@var{firstcpu}[-@var{lastcpu}]][,nodeid=@var{node}]
 @itemx -numa node[,memdev=@var{id}][,cpus=@var{firstcpu}[-@var{lastcpu}]][,nodeid=@var{node}]
 @itemx -numa dist,src=@var{source},dst=@var{destination},val=@var{distance}
 @itemx -numa cpu,node-id=@var{node}[,socket-id=@var{x}][,core-id=@var{y}][,thread-id=@var{z}]
+@itemx -numa hmat-lb,initiator=@var{node},target=@var{node},hierarchy=@var{str},data-type=@var{str}[,base-lat=@var{blat}][,base-bw=@var{bbw}][,latency=@var{lat}][,bandwidth=@var{bw}]
 @findex -numa
 Define a NUMA node and assign RAM and VCPUs to it.
 Set the NUMA distance from a source node to a destination node.
+Set the ACPI Heterogeneous Memory Attribute for the given nodes.
 
 Legacy VCPU assignment uses @samp{cpus} option where
 @var{firstcpu} and @var{lastcpu} are CPU indexes. Each
@@ -230,6 +233,29 @@ specified resources, it just assigns existing resources to NUMA
 nodes. This means that one still has to use the @option{-m},
 @option{-smp} options to allocate RAM and VCPUs respectively.
 
+Use 'hmat-lb' to set System Locality Latency and Bandwidth Information
+between initiator NUMA node and target NUMA node to build ACPI Heterogeneous Attribute Memory Table (HMAT).
+Initiator NUMA node can create memory requests, usually including one or more processors.
+Target NUMA node contains addressable memory.
+
+For example:
+@example
+-m 2G \
+-smp 3,sockets=2,maxcpus=3 \
+-numa node,cpus=0-1,nodeid=0 \
+-numa node,mem=1G,cpus=2,nodeid=1 \
+-numa node,mem=1G,nodeid=2 \
+-numa hmat-lb,initiator=0,target=1,hierarchy=memory,data-type=access-latency,base-lat=10,base-bw=20,latency=10,bandwidth=10 \
+-numa hmat-lb,initiator=1,target=2,hierarchy=1st-level,data-type=access-latency,base-bw=10,bandwidth=20
+@end example
+
+When the processors in NUMA node 0 access memory in NUMA node 1,
+the first line containing 'hmat-lb' sets the latency and bandwidth information.
+The latency is @var{lat} multiplied by @var{blat} and the bandwidth is @var{bw} multiplied by @var{bbw}.
+
+When the processors in NUMA node 1 access memory in NUMA node 2 that acts as 2nd level memory side cache,
+the second line containing 'hmat-lb' sets the access hit bandwidth information.
+
 ETEXI
 
 DEF("add-fd", HAS_ARG, QEMU_OPTION_add_fd,
-- 
2.17.1

On 1/11/19 9:34 AM, Tao Xu wrote:
> From: Liu Jingqi <jingqi.liu@intel.com>
> 
> 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 <jingqi.liu@intel.com>
> Signed-off-by: Tao Xu <tao3.xu@intel.com>
> ---
>  numa.c          | 124 ++++++++++++++++++++++++++++++++++++++++++++++++
>  qapi/misc.json  |  92 ++++++++++++++++++++++++++++++++++-
>  qemu-options.hx |  28 ++++++++++-
>  3 files changed, 241 insertions(+), 3 deletions(-)

> +++ b/qapi/misc.json
> @@ -2746,10 +2746,12 @@
>  #
>  # @cpu: property based CPU(s) to node mapping (Since: 2.10)
>  #
> +# @hmat-lb: memory latency and bandwidth information (Since: 2.13)

s/2.13/4.0/ (probably in multiple spots in your series)


> +##
> +# @HmatLBMemoryHierarchy:
> +#
> +# The memory hierarchy in the System Locality Latency
> +# and Bandwidth Information Structure of HMAT
> +#
> +# @memory: the structure represents the memory performance
> +#
> +# @last-level: last level memory of memory side cached memory
> +#
> +# @1st-level: first level memory of memory side cached memory
> +#
> +# @2nd-level: second level memory of memory side cached memory
> +#
> +# @3rd-level: third level memory of memory side cached memory

Let's spell these first-level, second-level, third-level (rather than
adding even more spots where we have enums with leading digits)

> +#
> +# Since: 2.13
> +##
> +{ 'enum': 'HmatLBMemoryHierarchy',
> +  'data': [ 'memory', 'last-level', '1st-level',
> +            '2nd-level', '3rd-level' ] }
> +
> +##
> +# @HmatLBDataType:
> +#
> +# Data type in the System Locality Latency
> +# and Bandwidth Information Structure of HMAT
> +#
> +# @access-latency: access latency
> +#
> +# @read-latency: read latency
> +#
> +# @write-latency: write latency
> +#
> +# @access-bandwidth: access bandwitch
> +#

s/bandwitch/bandwidth/

> +# @read-bandwidth: read bandwidth
> +#
> +# @write-bandwidth: write bandwidth

All 6 of these should probably list their units.

> +#
> +# Since: 2.13
> +##
> +{ 'enum': 'HmatLBDataType',
> +  'data': [ 'access-latency', 'read-latency', 'write-latency',
> +            'access-bandwidth', 'read-bandwidth', 'write-bandwidth' ] }
> +
> +##
> +# @NumaHmatLBOptions:
> +#
> +# Set the system locality latency and bandwidth information
> +# between Initiator and Target proximity Domains.
> +#
> +# @initiator: the Initiator Proximity Domain.
> +#
> +# @target: the Target Proximity Domain.
> +#
> +# @hierarchy: the Memory Hierarchy. Indicates the performance
> +#             of memory or side cache.
> +#
> +# @data-type: presents the type of data, access/read/write
> +#             latency or hit latency.
> +#
> +# @base-lat: the base unit for latency in nanoseconds.
> +#
> +# @base-bw: the base unit for bandwidth in megabytes per second(MB/s).
> +#
> +# @latency: the value of latency based on Base Unit from @initiator
> +#           to @target proximity domain.
> +#
> +# @bandwidth: the value of bandwidth based on Base Unit between
> +#             @initiator and @target proximity domain.
> +#
> +# Since: 2.13
> +##
> +{ 'struct': 'NumaHmatLBOptions',
> +  'data': {
> +   'initiator': 'uint16',
> +   'target': 'uint16',
> +   'hierarchy': 'HmatLBMemoryHierarchy',
> +   'data-type': 'HmatLBDataType',
> +   '*base-lat': 'uint64',
> +   '*base-bw': 'uint64',
> +   '*latency': 'uint16',
> +   '*bandwidth': 'uint16' }}
> +
>  ##
>  # @HostMemPolicy:
>  #


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

On 1/15/2019 3:38 AM, Eric Blake wrote:
> On 1/11/19 9:34 AM, Tao Xu wrote:
>> From: Liu Jingqi <jingqi.liu@intel.com>
>>
>> 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 <jingqi.liu@intel.com>
>> Signed-off-by: Tao Xu <tao3.xu@intel.com>
>> ---
>>   numa.c          | 124 ++++++++++++++++++++++++++++++++++++++++++++++++
>>   qapi/misc.json  |  92 ++++++++++++++++++++++++++++++++++-
>>   qemu-options.hx |  28 ++++++++++-
>>   3 files changed, 241 insertions(+), 3 deletions(-)
>> +++ b/qapi/misc.json
>> @@ -2746,10 +2746,12 @@
>>   #
>>   # @cpu: property based CPU(s) to node mapping (Since: 2.10)
>>   #
>> +# @hmat-lb: memory latency and bandwidth information (Since: 2.13)
> s/2.13/4.0/ (probably in multiple spots in your series) 
Hi Eric,

Thank you for your comments. The spell mistakes in patches 1/9 to 6/9
have been corrected in patch 7/9. Because patches 1/9 to 6/9 are jingqi's
initial V1 patchesand7/9 to 9/9 are the changes compared withV1.

About s/2.13/4.0/,do you mean ACPI HMAT will not be merged before QEMU
4.0?

In addition, do you have any other comments about these patches?
Thank you very much!

Tao
>> +##
>> +# @HmatLBMemoryHierarchy:
>> +#
>> +# The memory hierarchy in the System Locality Latency
>> +# and Bandwidth Information Structure of HMAT
>> +#
>> +# @memory: the structure represents the memory performance
>> +#
>> +# @last-level: last level memory of memory side cached memory
>> +#
>> +# @1st-level: first level memory of memory side cached memory
>> +#
>> +# @2nd-level: second level memory of memory side cached memory
>> +#
>> +# @3rd-level: third level memory of memory side cached memory
> Let's spell these first-level, second-level, third-level (rather than
> adding even more spots where we have enums with leading digits)
>
>> +#
>> +# Since: 2.13
>> +##
>> +{ 'enum': 'HmatLBMemoryHierarchy',
>> +  'data': [ 'memory', 'last-level', '1st-level',
>> +            '2nd-level', '3rd-level' ] }
>> +
>> +##
>> +# @HmatLBDataType:
>> +#
>> +# Data type in the System Locality Latency
>> +# and Bandwidth Information Structure of HMAT
>> +#
>> +# @access-latency: access latency
>> +#
>> +# @read-latency: read latency
>> +#
>> +# @write-latency: write latency
>> +#
>> +# @access-bandwidth: access bandwitch
>> +#
> s/bandwitch/bandwidth/
>
>> +# @read-bandwidth: read bandwidth
>> +#
>> +# @write-bandwidth: write bandwidth
> All 6 of these should probably list their units.
>
>> +#
>> +# Since: 2.13
>> +##
>> +{ 'enum': 'HmatLBDataType',
>> +  'data': [ 'access-latency', 'read-latency', 'write-latency',
>> +            'access-bandwidth', 'read-bandwidth', 'write-bandwidth' ] }
>> +
>> +##
>> +# @NumaHmatLBOptions:
>> +#
>> +# Set the system locality latency and bandwidth information
>> +# between Initiator and Target proximity Domains.
>> +#
>> +# @initiator: the Initiator Proximity Domain.
>> +#
>> +# @target: the Target Proximity Domain.
>> +#
>> +# @hierarchy: the Memory Hierarchy. Indicates the performance
>> +#             of memory or side cache.
>> +#
>> +# @data-type: presents the type of data, access/read/write
>> +#             latency or hit latency.
>> +#
>> +# @base-lat: the base unit for latency in nanoseconds.
>> +#
>> +# @base-bw: the base unit for bandwidth in megabytes per second(MB/s).
>> +#
>> +# @latency: the value of latency based on Base Unit from @initiator
>> +#           to @target proximity domain.
>> +#
>> +# @bandwidth: the value of bandwidth based on Base Unit between
>> +#             @initiator and @target proximity domain.
>> +#
>> +# Since: 2.13
>> +##
>> +{ 'struct': 'NumaHmatLBOptions',
>> +  'data': {
>> +   'initiator': 'uint16',
>> +   'target': 'uint16',
>> +   'hierarchy': 'HmatLBMemoryHierarchy',
>> +   'data-type': 'HmatLBDataType',
>> +   '*base-lat': 'uint64',
>> +   '*base-bw': 'uint64',
>> +   '*latency': 'uint16',
>> +   '*bandwidth': 'uint16' }}
>> +
>>   ##
>>   # @HostMemPolicy:
>>   #
>

On 1/21/19 12:03 AM, Tao Xu wrote:

>>>   #
>>> +# @hmat-lb: memory latency and bandwidth information (Since: 2.13)
>> s/2.13/4.0/ (probably in multiple spots in your series) 
> Hi Eric,
> 
> Thank you for your comments. The spell mistakes in patches 1/9 to 6/9
> have been corrected in patch 7/9. Because patches 1/9 to 6/9 are jingqi's
> initial V1 patchesand7/9 to 9/9 are the changes compared withV1.

Still, it's better to rebase the series to avoid the mistakes in the
first place, instead of having churn with a mistake early in the series
corrected only later in the series.  Even if the mistake is corrected by
a different author than the bulk of the patch, as long as there are
Signed-off-by lines for both the original author and the person making
the spelling correction, then proper attribution has been made.

> 
> About s/2.13/4.0/,do you mean ACPI HMAT will not be merged before QEMU
> 4.0?

Correct - 4.0 is the next release planned.  There was no 2.13 release;
after 2.12 was the 3.0 release; the current release is 3.1, and the next
release is 4.0; for more details, see
https://www.qemu.org/2018/08/15/qemu-3-0-0/ for a description of the
current version numbering scheme.  And even making it in time for 4.0
means polishing this by mid-March: https://wiki.qemu.org/Planning/4.0

> 
> In addition, do you have any other comments about these patches?

I was commenting on the high-level user interface issues, but will leave
the bulk of the technical review to those more familiar with the code
being added.

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

On 1/22/2019 1:09 AM, Eric Blake wrote:
> On 1/21/19 12:03 AM, Tao Xu wrote:
> 
>>>>    #
>>>> +# @hmat-lb: memory latency and bandwidth information (Since: 2.13)
>>> s/2.13/4.0/ (probably in multiple spots in your series)
>> Hi Eric,
>>
>> Thank you for your comments. The spell mistakes in patches 1/9 to 6/9
>> have been corrected in patch 7/9. Because patches 1/9 to 6/9 are jingqi's
>> initial V1 patchesand7/9 to 9/9 are the changes compared withV1.
> 
> Still, it's better to rebase the series to avoid the mistakes in the
> first place, instead of having churn with a mistake early in the series
> corrected only later in the series.  Even if the mistake is corrected by
> a different author than the bulk of the patch, as long as there are
> Signed-off-by lines for both the original author and the person making
> the spelling correction, then proper attribution has been made.
> 
>>
>> About s/2.13/4.0/,do you mean ACPI HMAT will not be merged before QEMU
>> 4.0?
> 
> Correct - 4.0 is the next release planned.  There was no 2.13 release;
> after 2.12 was the 3.0 release; the current release is 3.1, and the next
> release is 4.0; for more details, see
> https://www.qemu.org/2018/08/15/qemu-3-0-0/ for a description of the
> current version numbering scheme.  And even making it in time for 4.0
> means polishing this by mid-March: https://wiki.qemu.org/Planning/4.0
> 
>>
>> In addition, do you have any other comments about these patches?
> 
> I was commenting on the high-level user interface issues, but will leave
> the bulk of the technical review to those more familiar with the code
> being added.
> 
Hi Eric, I am sorry for asking you so frequently and don't mean to rush 
you. Could you tell me when I can know this comments on the high-level 
user interface issues? So that I can improve my patch in the next 
version. Thank you and looking forward to your reply!