Currently, when defining a HMAT cache for a NUMA node (in
parse_numa_hmat_cache()) there is this check that forces users to
define HMAT latency/bandwidth first. There is no real need for
this, because nothing in the parse function relies on that and
the HMAT table is constructed way later - when ACPI table is
constructed.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
---
 hw/core/numa.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/hw/core/numa.c b/hw/core/numa.c
index 316bc50d75..338453461c 100644
--- a/hw/core/numa.c
+++ b/hw/core/numa.c
@@ -384,7 +384,6 @@ void parse_numa_hmat_cache(MachineState *ms, NumaHmatCacheOptions *node,
                            Error **errp)
 {
     int nb_numa_nodes = ms->numa_state->num_nodes;
-    NodeInfo *numa_info = ms->numa_state->nodes;
     NumaHmatCacheOptions *hmat_cache = NULL;
 
     if (node->node_id >= nb_numa_nodes) {
@@ -393,13 +392,6 @@ void parse_numa_hmat_cache(MachineState *ms, NumaHmatCacheOptions *node,
         return;
     }
 
-    if (numa_info[node->node_id].lb_info_provided != (BIT(0) | BIT(1))) {
-        error_setg(errp, "The latency and bandwidth information of "
-                   "node-id=%" PRIu32 " should be provided before memory side "
-                   "cache attributes", node->node_id);
-        return;
-    }
-
     if (node->level < 1 || node->level >= HMAT_LB_LEVELS) {
         error_setg(errp, "Invalid level=%" PRIu8 ", it should be larger than 0 "
                    "and less than or equal to %d", node->level,
-- 
2.26.2

On Fri, 29 May 2020 15:33:47 +0200
Michal Privoznik <mprivozn@redhat.com> wrote:

> Currently, when defining a HMAT cache for a NUMA node (in
> parse_numa_hmat_cache()) there is this check that forces users to
> define HMAT latency/bandwidth first. There is no real need for
> this, because nothing in the parse function relies on that and
> the HMAT table is constructed way later - when ACPI table is
> constructed.

see comment in
  https://lists.gnu.org/archive/html/qemu-devel/2019-11/msg01206.html

in short doing check at this time allow us not to have more complex
check later on.

perhaps it needs a comment so that later it won't be dropped by accident

> 
> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
> ---
>  hw/core/numa.c | 8 --------
>  1 file changed, 8 deletions(-)
> 
> diff --git a/hw/core/numa.c b/hw/core/numa.c
> index 316bc50d75..338453461c 100644
> --- a/hw/core/numa.c
> +++ b/hw/core/numa.c
> @@ -384,7 +384,6 @@ void parse_numa_hmat_cache(MachineState *ms, NumaHmatCacheOptions *node,
>                             Error **errp)
>  {
>      int nb_numa_nodes = ms->numa_state->num_nodes;
> -    NodeInfo *numa_info = ms->numa_state->nodes;
>      NumaHmatCacheOptions *hmat_cache = NULL;
>  
>      if (node->node_id >= nb_numa_nodes) {
> @@ -393,13 +392,6 @@ void parse_numa_hmat_cache(MachineState *ms, NumaHmatCacheOptions *node,
>          return;
>      }
>  
> -    if (numa_info[node->node_id].lb_info_provided != (BIT(0) | BIT(1))) {
> -        error_setg(errp, "The latency and bandwidth information of "
> -                   "node-id=%" PRIu32 " should be provided before memory side "
> -                   "cache attributes", node->node_id);
> -        return;
> -    }
> -
>      if (node->level < 1 || node->level >= HMAT_LB_LEVELS) {
>          error_setg(errp, "Invalid level=%" PRIu8 ", it should be larger than 0 "
>                     "and less than or equal to %d", node->level,

On 5/29/20 4:59 PM, Igor Mammedov wrote:
> On Fri, 29 May 2020 15:33:47 +0200
> Michal Privoznik <mprivozn@redhat.com> wrote:
> 
>> Currently, when defining a HMAT cache for a NUMA node (in
>> parse_numa_hmat_cache()) there is this check that forces users to
>> define HMAT latency/bandwidth first. There is no real need for
>> this, because nothing in the parse function relies on that and
>> the HMAT table is constructed way later - when ACPI table is
>> constructed.
> 
> see comment in
>    https://lists.gnu.org/archive/html/qemu-devel/2019-11/msg01206.html
> 
> in short doing check at this time allow us not to have more complex
> check later on.
> 
> perhaps it needs a comment so that later it won't be dropped by accident

Fair enough. Discard this one then and I will post a patch that document 
this.

Michal