All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH for-5.0 v2 0/3] acpi: Fixes for inconsistency in ACPI MR size during migration
@ 2020-04-03 10:18 Shameer Kolothum
  2020-04-03 10:18 ` [PATCH for-5.0 v2 1/3] acpi: Use macro for table-loader file name Shameer Kolothum
                   ` (3 more replies)
  0 siblings, 4 replies; 11+ messages in thread
From: Shameer Kolothum @ 2020-04-03 10:18 UTC (permalink / raw)
  To: qemu-devel, qemu-arm, eric.auger, imammedo
  Cc: peter.maydell, xiaoguangrong.eric, david, mst, dgilbert, xuwei5,
	linuxarm, shannon.zhaosl, lersek

This is to fix few issues discovered while adding NVDIMM hot-add
support to arm/virt. These were previously part of [1] and since
the fixes are generic in nature and might be an issue in x86 as
well, they are being treated separately now.

1. https://patchwork.kernel.org/patch/11432371/

v1 --> V2
 - patch #2, Addressed comments from Dave and MST

Updates from [1]:
 -Added R-by and A-by tags.
 -Edited commit log for patch#2
 -Updated patch#3 as per David's comment

David Hildenbrand (1):
  exec: Fix for qemu_ram_resize() callback

Shameer Kolothum (2):
  acpi: Use macro for table-loader file name
  fw_cfg: Migrate ACPI table mr sizes separately

 exec.c                      | 16 ++++++-
 hw/arm/virt-acpi-build.c    |  2 +-
 hw/core/machine.c           |  1 +
 hw/i386/acpi-build.c        |  2 +-
 hw/nvram/fw_cfg.c           | 91 ++++++++++++++++++++++++++++++++++++-
 include/hw/acpi/aml-build.h |  1 +
 include/hw/nvram/fw_cfg.h   |  6 +++
 7 files changed, 114 insertions(+), 5 deletions(-)

-- 
2.17.1




^ permalink raw reply	[flat|nested] 11+ messages in thread

* [PATCH for-5.0 v2 1/3] acpi: Use macro for table-loader file name
  2020-04-03 10:18 [PATCH for-5.0 v2 0/3] acpi: Fixes for inconsistency in ACPI MR size during migration Shameer Kolothum
@ 2020-04-03 10:18 ` Shameer Kolothum
  2020-04-03 10:45   ` Philippe Mathieu-Daudé
  2020-04-03 10:18 ` [PATCH for-5.0 v2 2/3] fw_cfg: Migrate ACPI table mr sizes separately Shameer Kolothum
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 11+ messages in thread
From: Shameer Kolothum @ 2020-04-03 10:18 UTC (permalink / raw)
  To: qemu-devel, qemu-arm, eric.auger, imammedo
  Cc: peter.maydell, xiaoguangrong.eric, david, mst, dgilbert, xuwei5,
	linuxarm, shannon.zhaosl, lersek

Use macro for "etc/table-loader" and move it to the header
file similar to ACPI_BUILD_TABLE_FILE/ACPI_BUILD_RSDP_FILE etc.

Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
---
 hw/arm/virt-acpi-build.c    | 2 +-
 hw/i386/acpi-build.c        | 2 +-
 include/hw/acpi/aml-build.h | 1 +
 3 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index 7ef0733d71..81d41a3990 100644
--- a/hw/arm/virt-acpi-build.c
+++ b/hw/arm/virt-acpi-build.c
@@ -929,7 +929,7 @@ void virt_acpi_setup(VirtMachineState *vms)
 
     build_state->linker_mr =
         acpi_add_rom_blob(virt_acpi_build_update, build_state,
-                          tables.linker->cmd_blob, "etc/table-loader", 0);
+                          tables.linker->cmd_blob, ACPI_BUILD_LOADER_FILE, 0);
 
     fw_cfg_add_file(vms->fw_cfg, ACPI_BUILD_TPMLOG_FILE, tables.tcpalog->data,
                     acpi_data_len(tables.tcpalog));
diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 2a7e55bae7..23c77eeb95 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -3043,7 +3043,7 @@ void acpi_setup(void)
 
     build_state->linker_mr =
         acpi_add_rom_blob(acpi_build_update, build_state,
-                          tables.linker->cmd_blob, "etc/table-loader", 0);
+                          tables.linker->cmd_blob, ACPI_BUILD_LOADER_FILE, 0);
 
     fw_cfg_add_file(x86ms->fw_cfg, ACPI_BUILD_TPMLOG_FILE,
                     tables.tcpalog->data, acpi_data_len(tables.tcpalog));
diff --git a/include/hw/acpi/aml-build.h b/include/hw/acpi/aml-build.h
index de4a406568..0f4ed53d7f 100644
--- a/include/hw/acpi/aml-build.h
+++ b/include/hw/acpi/aml-build.h
@@ -13,6 +13,7 @@
 #define ACPI_BUILD_TABLE_FILE "etc/acpi/tables"
 #define ACPI_BUILD_RSDP_FILE "etc/acpi/rsdp"
 #define ACPI_BUILD_TPMLOG_FILE "etc/tpm/log"
+#define ACPI_BUILD_LOADER_FILE "etc/table-loader"
 
 #define AML_NOTIFY_METHOD "NTFY"
 
-- 
2.17.1




^ permalink raw reply related	[flat|nested] 11+ messages in thread

* [PATCH for-5.0 v2 2/3] fw_cfg: Migrate ACPI table mr sizes separately
  2020-04-03 10:18 [PATCH for-5.0 v2 0/3] acpi: Fixes for inconsistency in ACPI MR size during migration Shameer Kolothum
  2020-04-03 10:18 ` [PATCH for-5.0 v2 1/3] acpi: Use macro for table-loader file name Shameer Kolothum
@ 2020-04-03 10:18 ` Shameer Kolothum
  2020-04-07 14:17   ` Philippe Mathieu-Daudé
  2020-04-03 10:18 ` [PATCH for-5.0 v2 3/3] exec: Fix for qemu_ram_resize() callback Shameer Kolothum
  2020-04-03 12:37 ` [PATCH for-5.0 v2 0/3] acpi: Fixes for inconsistency in ACPI MR size during migration Michael S. Tsirkin
  3 siblings, 1 reply; 11+ messages in thread
From: Shameer Kolothum @ 2020-04-03 10:18 UTC (permalink / raw)
  To: qemu-devel, qemu-arm, eric.auger, imammedo
  Cc: peter.maydell, xiaoguangrong.eric, david, mst, dgilbert, xuwei5,
	linuxarm, shannon.zhaosl, lersek

Any sub-page size update to ACPI MRs will be lost during
migration, as we use aligned size in ram_load_precopy() ->
qemu_ram_resize() path. This will result in inconsistency in
FWCfgEntry sizes between source and destination. In order to avoid
this, save and restore them separately during migration.

Up until now, this problem may not be that relevant for x86 as both
ACPI table and Linker MRs gets padded and aligned. Also at present,
qemu_ram_resize() doesn't invoke callback to update FWCfgEntry for
unaligned size changes. But since we are going to fix the
qemu_ram_resize() in the subsequent patch, the issue may become
more serious especially for RSDP MR case.

Moreover, the issue will soon become prominent in arm/virt as well
where the MRs are not padded or aligned at all and eventually have
acpi table changes as part of future additions like NVDIMM hot-add
feature.

Suggested-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
Acked-by: David Hildenbrand <david@redhat.com>
---
v1 --> v2
 - Changed *_mr_size from size_t to uint64_t to address portability.
 - post_copy only done if sizes are not aligned.

Please find previous discussions here,
https://patchwork.kernel.org/patch/11339591/#23140343
---
 hw/core/machine.c         |  1 +
 hw/nvram/fw_cfg.c         | 91 ++++++++++++++++++++++++++++++++++++++-
 include/hw/nvram/fw_cfg.h |  6 +++
 3 files changed, 97 insertions(+), 1 deletion(-)

diff --git a/hw/core/machine.c b/hw/core/machine.c
index de0c425605..c1a444cb75 100644
--- a/hw/core/machine.c
+++ b/hw/core/machine.c
@@ -39,6 +39,7 @@ GlobalProperty hw_compat_4_2[] = {
     { "usb-redir", "suppress-remote-wake", "off" },
     { "qxl", "revision", "4" },
     { "qxl-vga", "revision", "4" },
+    { "fw_cfg", "acpi-mr-restore", "false" },
 };
 const size_t hw_compat_4_2_len = G_N_ELEMENTS(hw_compat_4_2);
 
diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index 179b302f01..4be6c9d9fd 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -39,6 +39,7 @@
 #include "qemu/config-file.h"
 #include "qemu/cutils.h"
 #include "qapi/error.h"
+#include "hw/acpi/aml-build.h"
 
 #define FW_CFG_FILE_SLOTS_DFLT 0x20
 
@@ -610,6 +611,55 @@ bool fw_cfg_dma_enabled(void *opaque)
     return s->dma_enabled;
 }
 
+static bool fw_cfg_acpi_mr_restore(void *opaque)
+{
+    FWCfgState *s = opaque;
+    bool mr_aligned;
+
+    mr_aligned = QEMU_IS_ALIGNED(s->table_mr_size, qemu_real_host_page_size) &&
+                 QEMU_IS_ALIGNED(s->linker_mr_size, qemu_real_host_page_size) &&
+                 QEMU_IS_ALIGNED(s->rsdp_mr_size, qemu_real_host_page_size);
+    return s->acpi_mr_restore && !mr_aligned;
+}
+
+static void fw_cfg_update_mr(FWCfgState *s, uint16_t key, size_t size)
+{
+    MemoryRegion *mr;
+    ram_addr_t offset;
+    int arch = !!(key & FW_CFG_ARCH_LOCAL);
+    void *ptr;
+
+    key &= FW_CFG_ENTRY_MASK;
+    assert(key < fw_cfg_max_entry(s));
+
+    ptr = s->entries[arch][key].data;
+    mr = memory_region_from_host(ptr, &offset);
+
+    memory_region_ram_resize(mr, size, &error_abort);
+}
+
+static int fw_cfg_acpi_mr_restore_post_load(void *opaque, int version_id)
+{
+    FWCfgState *s = opaque;
+    int i, index;
+
+    assert(s->files);
+
+    index = be32_to_cpu(s->files->count);
+
+    for (i = 0; i < index; i++) {
+        if (!strcmp(s->files->f[i].name, ACPI_BUILD_TABLE_FILE)) {
+            fw_cfg_update_mr(s, FW_CFG_FILE_FIRST + i, s->table_mr_size);
+        } else if (!strcmp(s->files->f[i].name, ACPI_BUILD_LOADER_FILE)) {
+            fw_cfg_update_mr(s, FW_CFG_FILE_FIRST + i, s->linker_mr_size);
+        } else if (!strcmp(s->files->f[i].name, ACPI_BUILD_RSDP_FILE)) {
+            fw_cfg_update_mr(s, FW_CFG_FILE_FIRST + i, s->rsdp_mr_size);
+        }
+    }
+
+    return 0;
+}
+
 static const VMStateDescription vmstate_fw_cfg_dma = {
     .name = "fw_cfg/dma",
     .needed = fw_cfg_dma_enabled,
@@ -619,6 +669,20 @@ static const VMStateDescription vmstate_fw_cfg_dma = {
     },
 };
 
+static const VMStateDescription vmstate_fw_cfg_acpi_mr = {
+    .name = "fw_cfg/acpi_mr",
+    .version_id = 1,
+    .minimum_version_id = 1,
+    .needed = fw_cfg_acpi_mr_restore,
+    .post_load = fw_cfg_acpi_mr_restore_post_load,
+    .fields = (VMStateField[]) {
+        VMSTATE_UINT64(table_mr_size, FWCfgState),
+        VMSTATE_UINT64(linker_mr_size, FWCfgState),
+        VMSTATE_UINT64(rsdp_mr_size, FWCfgState),
+        VMSTATE_END_OF_LIST()
+    },
+};
+
 static const VMStateDescription vmstate_fw_cfg = {
     .name = "fw_cfg",
     .version_id = 2,
@@ -631,6 +695,7 @@ static const VMStateDescription vmstate_fw_cfg = {
     },
     .subsections = (const VMStateDescription*[]) {
         &vmstate_fw_cfg_dma,
+        &vmstate_fw_cfg_acpi_mr,
         NULL,
     }
 };
@@ -815,6 +880,23 @@ static struct {
 #define FW_CFG_ORDER_OVERRIDE_LAST 200
 };
 
+/*
+ * Any sub-page size update to these table MRs will be lost during migration,
+ * as we use aligned size in ram_load_precopy() -> qemu_ram_resize() path.
+ * In order to avoid the inconsistency in sizes save them seperately and
+ * migrate over in vmstate post_load().
+ */
+static void fw_cfg_acpi_mr_save(FWCfgState *s, const char *filename, size_t len)
+{
+    if (!strcmp(filename, ACPI_BUILD_TABLE_FILE)) {
+        s->table_mr_size = len;
+    } else if (!strcmp(filename, ACPI_BUILD_LOADER_FILE)) {
+        s->linker_mr_size = len;
+    } else if (!strcmp(filename, ACPI_BUILD_RSDP_FILE)) {
+        s->rsdp_mr_size = len;
+    }
+}
+
 static int get_fw_cfg_order(FWCfgState *s, const char *name)
 {
     int i;
@@ -914,6 +996,7 @@ void fw_cfg_add_file_callback(FWCfgState *s,  const char *filename,
     trace_fw_cfg_add_file(s, index, s->files->f[index].name, len);
 
     s->files->count = cpu_to_be32(count+1);
+    fw_cfg_acpi_mr_save(s, filename, len);
 }
 
 void fw_cfg_add_file(FWCfgState *s,  const char *filename,
@@ -937,6 +1020,7 @@ void *fw_cfg_modify_file(FWCfgState *s, const char *filename,
             ptr = fw_cfg_modify_bytes_read(s, FW_CFG_FILE_FIRST + i,
                                            data, len);
             s->files->f[i].size   = cpu_to_be32(len);
+            fw_cfg_acpi_mr_save(s, filename, len);
             return ptr;
         }
     }
@@ -973,7 +1057,10 @@ static void fw_cfg_machine_ready(struct Notifier *n, void *data)
     qemu_register_reset(fw_cfg_machine_reset, s);
 }
 
-
+static Property fw_cfg_properties[] = {
+    DEFINE_PROP_BOOL("acpi-mr-restore", FWCfgState, acpi_mr_restore, true),
+    DEFINE_PROP_END_OF_LIST(),
+};
 
 static void fw_cfg_common_realize(DeviceState *dev, Error **errp)
 {
@@ -1097,6 +1184,8 @@ static void fw_cfg_class_init(ObjectClass *klass, void *data)
 
     dc->reset = fw_cfg_reset;
     dc->vmsd = &vmstate_fw_cfg;
+
+    device_class_set_props(dc, fw_cfg_properties);
 }
 
 static const TypeInfo fw_cfg_info = {
diff --git a/include/hw/nvram/fw_cfg.h b/include/hw/nvram/fw_cfg.h
index b5291eefad..25d9307018 100644
--- a/include/hw/nvram/fw_cfg.h
+++ b/include/hw/nvram/fw_cfg.h
@@ -53,6 +53,12 @@ struct FWCfgState {
     dma_addr_t dma_addr;
     AddressSpace *dma_as;
     MemoryRegion dma_iomem;
+
+    /* restore during migration */
+    bool acpi_mr_restore;
+    uint64_t table_mr_size;
+    uint64_t linker_mr_size;
+    uint64_t rsdp_mr_size;
 };
 
 struct FWCfgIoState {
-- 
2.17.1




^ permalink raw reply related	[flat|nested] 11+ messages in thread

* [PATCH for-5.0 v2 3/3] exec: Fix for qemu_ram_resize() callback
  2020-04-03 10:18 [PATCH for-5.0 v2 0/3] acpi: Fixes for inconsistency in ACPI MR size during migration Shameer Kolothum
  2020-04-03 10:18 ` [PATCH for-5.0 v2 1/3] acpi: Use macro for table-loader file name Shameer Kolothum
  2020-04-03 10:18 ` [PATCH for-5.0 v2 2/3] fw_cfg: Migrate ACPI table mr sizes separately Shameer Kolothum
@ 2020-04-03 10:18 ` Shameer Kolothum
  2020-04-03 10:50   ` Philippe Mathieu-Daudé
  2020-04-03 12:37 ` [PATCH for-5.0 v2 0/3] acpi: Fixes for inconsistency in ACPI MR size during migration Michael S. Tsirkin
  3 siblings, 1 reply; 11+ messages in thread
From: Shameer Kolothum @ 2020-04-03 10:18 UTC (permalink / raw)
  To: qemu-devel, qemu-arm, eric.auger, imammedo
  Cc: peter.maydell, xiaoguangrong.eric, david, mst, dgilbert, xuwei5,
	linuxarm, shannon.zhaosl, lersek

From: David Hildenbrand <david@redhat.com>

Summarizing the issue:
1. Memory regions contain ram blocks with a different size,  if the
   size is  not properly aligned. While memory regions can have an
   unaligned size, ram blocks can't. This is true when creating
   resizable memory region with  an unaligned size.
2. When resizing a ram block/memory region, the size of the memory
   region  is set to the aligned size. The callback is called with
   the aligned size. The unaligned piece is lost.

Because of the above, if ACPI blob length modifications happens
after the initial virt_acpi_build() call, and the changed blob
length is within the PAGE size boundary, then the revised size
is not seen by the firmware on Guest reboot.

Hence make sure callback is called if memory region size is changed,
irrespective of aligned or not.

Signed-off-by: David Hildenbrand <david@redhat.com>
[Shameer: added commit log]
Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
Reviewed-by: Igor Mammedov <imammedo@redhat.com>
---
Please find previous discussion here,
https://patchwork.kernel.org/patch/11432375/#23216751
---
 exec.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/exec.c b/exec.c
index de9d949902..2874bb5088 100644
--- a/exec.c
+++ b/exec.c
@@ -2074,11 +2074,23 @@ static int memory_try_enable_merging(void *addr, size_t len)
  */
 int qemu_ram_resize(RAMBlock *block, ram_addr_t newsize, Error **errp)
 {
+    const ram_addr_t unaligned_size = newsize;
+
     assert(block);
 
     newsize = HOST_PAGE_ALIGN(newsize);
 
     if (block->used_length == newsize) {
+        /*
+         * We don't have to resize the ram block (which only knows aligned
+         * sizes), however, we have to notify if the unaligned size changed.
+         */
+        if (unaligned_size != memory_region_size(block->mr)) {
+            memory_region_set_size(block->mr, unaligned_size);
+            if (block->resized) {
+                block->resized(block->idstr, unaligned_size, block->host);
+            }
+        }
         return 0;
     }
 
@@ -2102,9 +2114,9 @@ int qemu_ram_resize(RAMBlock *block, ram_addr_t newsize, Error **errp)
     block->used_length = newsize;
     cpu_physical_memory_set_dirty_range(block->offset, block->used_length,
                                         DIRTY_CLIENTS_ALL);
-    memory_region_set_size(block->mr, newsize);
+    memory_region_set_size(block->mr, unaligned_size);
     if (block->resized) {
-        block->resized(block->idstr, newsize, block->host);
+        block->resized(block->idstr, unaligned_size, block->host);
     }
     return 0;
 }
-- 
2.17.1




^ permalink raw reply related	[flat|nested] 11+ messages in thread

* Re: [PATCH for-5.0 v2 1/3] acpi: Use macro for table-loader file name
  2020-04-03 10:18 ` [PATCH for-5.0 v2 1/3] acpi: Use macro for table-loader file name Shameer Kolothum
@ 2020-04-03 10:45   ` Philippe Mathieu-Daudé
  0 siblings, 0 replies; 11+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-04-03 10:45 UTC (permalink / raw)
  To: Shameer Kolothum, qemu-devel, qemu-arm, eric.auger, imammedo
  Cc: peter.maydell, xiaoguangrong.eric, mst, david, dgilbert, xuwei5,
	linuxarm, shannon.zhaosl, lersek

On 4/3/20 12:18 PM, Shameer Kolothum wrote:
> Use macro for "etc/table-loader" and move it to the header
> file similar to ACPI_BUILD_TABLE_FILE/ACPI_BUILD_RSDP_FILE etc.
> 
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> Reviewed-by: Igor Mammedov <imammedo@redhat.com>

Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>

> ---
>   hw/arm/virt-acpi-build.c    | 2 +-
>   hw/i386/acpi-build.c        | 2 +-
>   include/hw/acpi/aml-build.h | 1 +
>   3 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
> index 7ef0733d71..81d41a3990 100644
> --- a/hw/arm/virt-acpi-build.c
> +++ b/hw/arm/virt-acpi-build.c
> @@ -929,7 +929,7 @@ void virt_acpi_setup(VirtMachineState *vms)
>   
>       build_state->linker_mr =
>           acpi_add_rom_blob(virt_acpi_build_update, build_state,
> -                          tables.linker->cmd_blob, "etc/table-loader", 0);
> +                          tables.linker->cmd_blob, ACPI_BUILD_LOADER_FILE, 0);
>   
>       fw_cfg_add_file(vms->fw_cfg, ACPI_BUILD_TPMLOG_FILE, tables.tcpalog->data,
>                       acpi_data_len(tables.tcpalog));
> diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
> index 2a7e55bae7..23c77eeb95 100644
> --- a/hw/i386/acpi-build.c
> +++ b/hw/i386/acpi-build.c
> @@ -3043,7 +3043,7 @@ void acpi_setup(void)
>   
>       build_state->linker_mr =
>           acpi_add_rom_blob(acpi_build_update, build_state,
> -                          tables.linker->cmd_blob, "etc/table-loader", 0);
> +                          tables.linker->cmd_blob, ACPI_BUILD_LOADER_FILE, 0);
>   
>       fw_cfg_add_file(x86ms->fw_cfg, ACPI_BUILD_TPMLOG_FILE,
>                       tables.tcpalog->data, acpi_data_len(tables.tcpalog));
> diff --git a/include/hw/acpi/aml-build.h b/include/hw/acpi/aml-build.h
> index de4a406568..0f4ed53d7f 100644
> --- a/include/hw/acpi/aml-build.h
> +++ b/include/hw/acpi/aml-build.h
> @@ -13,6 +13,7 @@
>   #define ACPI_BUILD_TABLE_FILE "etc/acpi/tables"
>   #define ACPI_BUILD_RSDP_FILE "etc/acpi/rsdp"
>   #define ACPI_BUILD_TPMLOG_FILE "etc/tpm/log"
> +#define ACPI_BUILD_LOADER_FILE "etc/table-loader"
>   
>   #define AML_NOTIFY_METHOD "NTFY"
>   
> 



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH for-5.0 v2 3/3] exec: Fix for qemu_ram_resize() callback
  2020-04-03 10:18 ` [PATCH for-5.0 v2 3/3] exec: Fix for qemu_ram_resize() callback Shameer Kolothum
@ 2020-04-03 10:50   ` Philippe Mathieu-Daudé
  0 siblings, 0 replies; 11+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-04-03 10:50 UTC (permalink / raw)
  To: Shameer Kolothum, qemu-devel, qemu-arm, eric.auger, imammedo
  Cc: peter.maydell, xiaoguangrong.eric, mst, david, dgilbert, xuwei5,
	linuxarm, shannon.zhaosl, lersek

On 4/3/20 12:18 PM, Shameer Kolothum wrote:
> From: David Hildenbrand <david@redhat.com>
> 
> Summarizing the issue:
> 1. Memory regions contain ram blocks with a different size,  if the
>     size is  not properly aligned. While memory regions can have an
>     unaligned size, ram blocks can't. This is true when creating
>     resizable memory region with  an unaligned size.
> 2. When resizing a ram block/memory region, the size of the memory
>     region  is set to the aligned size. The callback is called with
>     the aligned size. The unaligned piece is lost.
> 
> Because of the above, if ACPI blob length modifications happens
> after the initial virt_acpi_build() call, and the changed blob
> length is within the PAGE size boundary, then the revised size
> is not seen by the firmware on Guest reboot.
> 
> Hence make sure callback is called if memory region size is changed,
> irrespective of aligned or not.
> 
> Signed-off-by: David Hildenbrand <david@redhat.com>
> [Shameer: added commit log]
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> Reviewed-by: Igor Mammedov <imammedo@redhat.com>

Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>

> ---
> Please find previous discussion here,
> https://patchwork.kernel.org/patch/11432375/#23216751
> ---
>   exec.c | 16 ++++++++++++++--
>   1 file changed, 14 insertions(+), 2 deletions(-)
> 
> diff --git a/exec.c b/exec.c
> index de9d949902..2874bb5088 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -2074,11 +2074,23 @@ static int memory_try_enable_merging(void *addr, size_t len)
>    */
>   int qemu_ram_resize(RAMBlock *block, ram_addr_t newsize, Error **errp)
>   {
> +    const ram_addr_t unaligned_size = newsize;
> +
>       assert(block);
>   
>       newsize = HOST_PAGE_ALIGN(newsize);
>   
>       if (block->used_length == newsize) {
> +        /*
> +         * We don't have to resize the ram block (which only knows aligned
> +         * sizes), however, we have to notify if the unaligned size changed.
> +         */
> +        if (unaligned_size != memory_region_size(block->mr)) {
> +            memory_region_set_size(block->mr, unaligned_size);
> +            if (block->resized) {
> +                block->resized(block->idstr, unaligned_size, block->host);
> +            }
> +        }
>           return 0;
>       }
>   
> @@ -2102,9 +2114,9 @@ int qemu_ram_resize(RAMBlock *block, ram_addr_t newsize, Error **errp)
>       block->used_length = newsize;
>       cpu_physical_memory_set_dirty_range(block->offset, block->used_length,
>                                           DIRTY_CLIENTS_ALL);
> -    memory_region_set_size(block->mr, newsize);
> +    memory_region_set_size(block->mr, unaligned_size);
>       if (block->resized) {
> -        block->resized(block->idstr, newsize, block->host);
> +        block->resized(block->idstr, unaligned_size, block->host);
>       }
>       return 0;
>   }
> 



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH for-5.0 v2 0/3] acpi: Fixes for inconsistency in ACPI MR size during migration
  2020-04-03 10:18 [PATCH for-5.0 v2 0/3] acpi: Fixes for inconsistency in ACPI MR size during migration Shameer Kolothum
                   ` (2 preceding siblings ...)
  2020-04-03 10:18 ` [PATCH for-5.0 v2 3/3] exec: Fix for qemu_ram_resize() callback Shameer Kolothum
@ 2020-04-03 12:37 ` Michael S. Tsirkin
  3 siblings, 0 replies; 11+ messages in thread
From: Michael S. Tsirkin @ 2020-04-03 12:37 UTC (permalink / raw)
  To: Shameer Kolothum
  Cc: peter.maydell, xiaoguangrong.eric, shannon.zhaosl, david,
	linuxarm, qemu-devel, xuwei5, dgilbert, eric.auger, qemu-arm,
	imammedo, lersek

On Fri, Apr 03, 2020 at 11:18:24AM +0100, Shameer Kolothum wrote:
> This is to fix few issues discovered while adding NVDIMM hot-add
> support to arm/virt. These were previously part of [1] and since
> the fixes are generic in nature and might be an issue in x86 as
> well, they are being treated separately now.

OK I'll queue this unless someone has any objections.

> 1. https://patchwork.kernel.org/patch/11432371/
> 
> v1 --> V2
>  - patch #2, Addressed comments from Dave and MST
> 
> Updates from [1]:
>  -Added R-by and A-by tags.
>  -Edited commit log for patch#2
>  -Updated patch#3 as per David's comment
> 
> David Hildenbrand (1):
>   exec: Fix for qemu_ram_resize() callback
> 
> Shameer Kolothum (2):
>   acpi: Use macro for table-loader file name
>   fw_cfg: Migrate ACPI table mr sizes separately
> 
>  exec.c                      | 16 ++++++-
>  hw/arm/virt-acpi-build.c    |  2 +-
>  hw/core/machine.c           |  1 +
>  hw/i386/acpi-build.c        |  2 +-
>  hw/nvram/fw_cfg.c           | 91 ++++++++++++++++++++++++++++++++++++-
>  include/hw/acpi/aml-build.h |  1 +
>  include/hw/nvram/fw_cfg.h   |  6 +++
>  7 files changed, 114 insertions(+), 5 deletions(-)
> 
> -- 
> 2.17.1
> 



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH for-5.0 v2 2/3] fw_cfg: Migrate ACPI table mr sizes separately
  2020-04-03 10:18 ` [PATCH for-5.0 v2 2/3] fw_cfg: Migrate ACPI table mr sizes separately Shameer Kolothum
@ 2020-04-07 14:17   ` Philippe Mathieu-Daudé
  2020-04-07 14:34     ` Michael S. Tsirkin
  0 siblings, 1 reply; 11+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-04-07 14:17 UTC (permalink / raw)
  To: Shameer Kolothum, qemu-devel, qemu-arm, eric.auger, imammedo
  Cc: peter.maydell, xiaoguangrong.eric, mst, david, dgilbert, xuwei5,
	linuxarm, shannon.zhaosl, lersek

On 4/3/20 12:18 PM, Shameer Kolothum wrote:
> Any sub-page size update to ACPI MRs will be lost during
> migration, as we use aligned size in ram_load_precopy() ->
> qemu_ram_resize() path. This will result in inconsistency in
> FWCfgEntry sizes between source and destination. In order to avoid
> this, save and restore them separately during migration.
> 
> Up until now, this problem may not be that relevant for x86 as both
> ACPI table and Linker MRs gets padded and aligned. Also at present,
> qemu_ram_resize() doesn't invoke callback to update FWCfgEntry for
> unaligned size changes. But since we are going to fix the
> qemu_ram_resize() in the subsequent patch, the issue may become
> more serious especially for RSDP MR case.
> 
> Moreover, the issue will soon become prominent in arm/virt as well
> where the MRs are not padded or aligned at all and eventually have
> acpi table changes as part of future additions like NVDIMM hot-add
> feature.
> 
> Suggested-by: David Hildenbrand <david@redhat.com>
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> Acked-by: David Hildenbrand <david@redhat.com>
> ---
> v1 --> v2
>   - Changed *_mr_size from size_t to uint64_t to address portability.
>   - post_copy only done if sizes are not aligned.
> 
> Please find previous discussions here,
> https://patchwork.kernel.org/patch/11339591/#23140343
> ---
>   hw/core/machine.c         |  1 +
>   hw/nvram/fw_cfg.c         | 91 ++++++++++++++++++++++++++++++++++++++-
>   include/hw/nvram/fw_cfg.h |  6 +++
>   3 files changed, 97 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/core/machine.c b/hw/core/machine.c
> index de0c425605..c1a444cb75 100644
> --- a/hw/core/machine.c
> +++ b/hw/core/machine.c
> @@ -39,6 +39,7 @@ GlobalProperty hw_compat_4_2[] = {
>       { "usb-redir", "suppress-remote-wake", "off" },
>       { "qxl", "revision", "4" },
>       { "qxl-vga", "revision", "4" },
> +    { "fw_cfg", "acpi-mr-restore", "false" },
>   };
>   const size_t hw_compat_4_2_len = G_N_ELEMENTS(hw_compat_4_2);
>   
> diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
> index 179b302f01..4be6c9d9fd 100644
> --- a/hw/nvram/fw_cfg.c
> +++ b/hw/nvram/fw_cfg.c
> @@ -39,6 +39,7 @@
>   #include "qemu/config-file.h"
>   #include "qemu/cutils.h"
>   #include "qapi/error.h"
> +#include "hw/acpi/aml-build.h"
>   
>   #define FW_CFG_FILE_SLOTS_DFLT 0x20
>   
> @@ -610,6 +611,55 @@ bool fw_cfg_dma_enabled(void *opaque)
>       return s->dma_enabled;
>   }
>   
> +static bool fw_cfg_acpi_mr_restore(void *opaque)
> +{
> +    FWCfgState *s = opaque;
> +    bool mr_aligned;
> +
> +    mr_aligned = QEMU_IS_ALIGNED(s->table_mr_size, qemu_real_host_page_size) &&
> +                 QEMU_IS_ALIGNED(s->linker_mr_size, qemu_real_host_page_size) &&
> +                 QEMU_IS_ALIGNED(s->rsdp_mr_size, qemu_real_host_page_size);
> +    return s->acpi_mr_restore && !mr_aligned;

This code is hard to review.

Is this equivalent?

     if (!s->acpi_mr_restore) {
         return false;
     }
     if (!QEMU_IS_ALIGNED(s->table_mr_size, qemu_real_host_page_size)) {
         return false;
     }
     if (!QEMU_IS_ALIGNED(s->linker_mr_size, qemu_real_host_page_size)) {
         return false;
     }
     if (!QEMU_IS_ALIGNED(s->rsdp_mr_size, qemu_real_host_page_size)) {
         return false;
     }
     return true;

> +}
> +
> +static void fw_cfg_update_mr(FWCfgState *s, uint16_t key, size_t size)
> +{
> +    MemoryRegion *mr;
> +    ram_addr_t offset;
> +    int arch = !!(key & FW_CFG_ARCH_LOCAL);
> +    void *ptr;
> +
> +    key &= FW_CFG_ENTRY_MASK;
> +    assert(key < fw_cfg_max_entry(s));
> +
> +    ptr = s->entries[arch][key].data;
> +    mr = memory_region_from_host(ptr, &offset);
> +
> +    memory_region_ram_resize(mr, size, &error_abort);
> +}
> +
> +static int fw_cfg_acpi_mr_restore_post_load(void *opaque, int version_id)
> +{
> +    FWCfgState *s = opaque;
> +    int i, index;
> +
> +    assert(s->files);
> +
> +    index = be32_to_cpu(s->files->count);
> +
> +    for (i = 0; i < index; i++) {
> +        if (!strcmp(s->files->f[i].name, ACPI_BUILD_TABLE_FILE)) {
> +            fw_cfg_update_mr(s, FW_CFG_FILE_FIRST + i, s->table_mr_size);
> +        } else if (!strcmp(s->files->f[i].name, ACPI_BUILD_LOADER_FILE)) {
> +            fw_cfg_update_mr(s, FW_CFG_FILE_FIRST + i, s->linker_mr_size);
> +        } else if (!strcmp(s->files->f[i].name, ACPI_BUILD_RSDP_FILE)) {
> +            fw_cfg_update_mr(s, FW_CFG_FILE_FIRST + i, s->rsdp_mr_size);
> +        }
> +    }
> +
> +    return 0;
> +}
> +
>   static const VMStateDescription vmstate_fw_cfg_dma = {
>       .name = "fw_cfg/dma",
>       .needed = fw_cfg_dma_enabled,
> @@ -619,6 +669,20 @@ static const VMStateDescription vmstate_fw_cfg_dma = {
>       },
>   };
>   
> +static const VMStateDescription vmstate_fw_cfg_acpi_mr = {
> +    .name = "fw_cfg/acpi_mr",
> +    .version_id = 1,
> +    .minimum_version_id = 1,
> +    .needed = fw_cfg_acpi_mr_restore,
> +    .post_load = fw_cfg_acpi_mr_restore_post_load,
> +    .fields = (VMStateField[]) {
> +        VMSTATE_UINT64(table_mr_size, FWCfgState),
> +        VMSTATE_UINT64(linker_mr_size, FWCfgState),
> +        VMSTATE_UINT64(rsdp_mr_size, FWCfgState),
> +        VMSTATE_END_OF_LIST()
> +    },
> +};
> +
>   static const VMStateDescription vmstate_fw_cfg = {
>       .name = "fw_cfg",
>       .version_id = 2,
> @@ -631,6 +695,7 @@ static const VMStateDescription vmstate_fw_cfg = {
>       },
>       .subsections = (const VMStateDescription*[]) {
>           &vmstate_fw_cfg_dma,
> +        &vmstate_fw_cfg_acpi_mr,
>           NULL,
>       }
>   };
> @@ -815,6 +880,23 @@ static struct {
>   #define FW_CFG_ORDER_OVERRIDE_LAST 200
>   };
>   
> +/*
> + * Any sub-page size update to these table MRs will be lost during migration,
> + * as we use aligned size in ram_load_precopy() -> qemu_ram_resize() path.
> + * In order to avoid the inconsistency in sizes save them seperately and
> + * migrate over in vmstate post_load().
> + */
> +static void fw_cfg_acpi_mr_save(FWCfgState *s, const char *filename, size_t len)
> +{
> +    if (!strcmp(filename, ACPI_BUILD_TABLE_FILE)) {
> +        s->table_mr_size = len;
> +    } else if (!strcmp(filename, ACPI_BUILD_LOADER_FILE)) {
> +        s->linker_mr_size = len;
> +    } else if (!strcmp(filename, ACPI_BUILD_RSDP_FILE)) {
> +        s->rsdp_mr_size = len;
> +    }
> +}
> +
>   static int get_fw_cfg_order(FWCfgState *s, const char *name)
>   {
>       int i;
> @@ -914,6 +996,7 @@ void fw_cfg_add_file_callback(FWCfgState *s,  const char *filename,
>       trace_fw_cfg_add_file(s, index, s->files->f[index].name, len);
>   
>       s->files->count = cpu_to_be32(count+1);
> +    fw_cfg_acpi_mr_save(s, filename, len);
>   }
>   
>   void fw_cfg_add_file(FWCfgState *s,  const char *filename,
> @@ -937,6 +1020,7 @@ void *fw_cfg_modify_file(FWCfgState *s, const char *filename,
>               ptr = fw_cfg_modify_bytes_read(s, FW_CFG_FILE_FIRST + i,
>                                              data, len);
>               s->files->f[i].size   = cpu_to_be32(len);
> +            fw_cfg_acpi_mr_save(s, filename, len);
>               return ptr;
>           }
>       }
> @@ -973,7 +1057,10 @@ static void fw_cfg_machine_ready(struct Notifier *n, void *data)
>       qemu_register_reset(fw_cfg_machine_reset, s);
>   }
>   
> -
> +static Property fw_cfg_properties[] = {
> +    DEFINE_PROP_BOOL("acpi-mr-restore", FWCfgState, acpi_mr_restore, true),
> +    DEFINE_PROP_END_OF_LIST(),
> +};
>   
>   static void fw_cfg_common_realize(DeviceState *dev, Error **errp)
>   {
> @@ -1097,6 +1184,8 @@ static void fw_cfg_class_init(ObjectClass *klass, void *data)
>   
>       dc->reset = fw_cfg_reset;
>       dc->vmsd = &vmstate_fw_cfg;
> +
> +    device_class_set_props(dc, fw_cfg_properties);
>   }
>   
>   static const TypeInfo fw_cfg_info = {
> diff --git a/include/hw/nvram/fw_cfg.h b/include/hw/nvram/fw_cfg.h
> index b5291eefad..25d9307018 100644
> --- a/include/hw/nvram/fw_cfg.h
> +++ b/include/hw/nvram/fw_cfg.h
> @@ -53,6 +53,12 @@ struct FWCfgState {
>       dma_addr_t dma_addr;
>       AddressSpace *dma_as;
>       MemoryRegion dma_iomem;
> +
> +    /* restore during migration */
> +    bool acpi_mr_restore;
> +    uint64_t table_mr_size;
> +    uint64_t linker_mr_size;
> +    uint64_t rsdp_mr_size;
>   };
>   
>   struct FWCfgIoState {
> 



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH for-5.0 v2 2/3] fw_cfg: Migrate ACPI table mr sizes separately
  2020-04-07 14:17   ` Philippe Mathieu-Daudé
@ 2020-04-07 14:34     ` Michael S. Tsirkin
  2020-04-07 14:54       ` David Hildenbrand
  0 siblings, 1 reply; 11+ messages in thread
From: Michael S. Tsirkin @ 2020-04-07 14:34 UTC (permalink / raw)
  To: Philippe Mathieu-Daudé
  Cc: peter.maydell, xiaoguangrong.eric, david, shannon.zhaosl,
	linuxarm, qemu-devel, Shameer Kolothum, dgilbert, eric.auger,
	qemu-arm, xuwei5, imammedo, lersek

On Tue, Apr 07, 2020 at 04:17:46PM +0200, Philippe Mathieu-Daudé wrote:
> On 4/3/20 12:18 PM, Shameer Kolothum wrote:
> > Any sub-page size update to ACPI MRs will be lost during
> > migration, as we use aligned size in ram_load_precopy() ->
> > qemu_ram_resize() path. This will result in inconsistency in
> > FWCfgEntry sizes between source and destination. In order to avoid
> > this, save and restore them separately during migration.
> > 
> > Up until now, this problem may not be that relevant for x86 as both
> > ACPI table and Linker MRs gets padded and aligned. Also at present,
> > qemu_ram_resize() doesn't invoke callback to update FWCfgEntry for
> > unaligned size changes. But since we are going to fix the
> > qemu_ram_resize() in the subsequent patch, the issue may become
> > more serious especially for RSDP MR case.
> > 
> > Moreover, the issue will soon become prominent in arm/virt as well
> > where the MRs are not padded or aligned at all and eventually have
> > acpi table changes as part of future additions like NVDIMM hot-add
> > feature.
> > 
> > Suggested-by: David Hildenbrand <david@redhat.com>
> > Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> > Acked-by: David Hildenbrand <david@redhat.com>
> > ---
> > v1 --> v2
> >   - Changed *_mr_size from size_t to uint64_t to address portability.
> >   - post_copy only done if sizes are not aligned.
> > 
> > Please find previous discussions here,
> > https://patchwork.kernel.org/patch/11339591/#23140343
> > ---
> >   hw/core/machine.c         |  1 +
> >   hw/nvram/fw_cfg.c         | 91 ++++++++++++++++++++++++++++++++++++++-
> >   include/hw/nvram/fw_cfg.h |  6 +++
> >   3 files changed, 97 insertions(+), 1 deletion(-)
> > 
> > diff --git a/hw/core/machine.c b/hw/core/machine.c
> > index de0c425605..c1a444cb75 100644
> > --- a/hw/core/machine.c
> > +++ b/hw/core/machine.c
> > @@ -39,6 +39,7 @@ GlobalProperty hw_compat_4_2[] = {
> >       { "usb-redir", "suppress-remote-wake", "off" },
> >       { "qxl", "revision", "4" },
> >       { "qxl-vga", "revision", "4" },
> > +    { "fw_cfg", "acpi-mr-restore", "false" },
> >   };
> >   const size_t hw_compat_4_2_len = G_N_ELEMENTS(hw_compat_4_2);
> > diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
> > index 179b302f01..4be6c9d9fd 100644
> > --- a/hw/nvram/fw_cfg.c
> > +++ b/hw/nvram/fw_cfg.c
> > @@ -39,6 +39,7 @@
> >   #include "qemu/config-file.h"
> >   #include "qemu/cutils.h"
> >   #include "qapi/error.h"
> > +#include "hw/acpi/aml-build.h"
> >   #define FW_CFG_FILE_SLOTS_DFLT 0x20
> > @@ -610,6 +611,55 @@ bool fw_cfg_dma_enabled(void *opaque)
> >       return s->dma_enabled;
> >   }
> > +static bool fw_cfg_acpi_mr_restore(void *opaque)
> > +{
> > +    FWCfgState *s = opaque;
> > +    bool mr_aligned;
> > +
> > +    mr_aligned = QEMU_IS_ALIGNED(s->table_mr_size, qemu_real_host_page_size) &&
> > +                 QEMU_IS_ALIGNED(s->linker_mr_size, qemu_real_host_page_size) &&
> > +                 QEMU_IS_ALIGNED(s->rsdp_mr_size, qemu_real_host_page_size);
> > +    return s->acpi_mr_restore && !mr_aligned;
> 
> This code is hard to review.
> 
> Is this equivalent?
> 
>     if (!s->acpi_mr_restore) {
>         return false;
>     }
>     if (!QEMU_IS_ALIGNED(s->table_mr_size, qemu_real_host_page_size)) {
>         return false;
>     }
>     if (!QEMU_IS_ALIGNED(s->linker_mr_size, qemu_real_host_page_size)) {
>         return false;
>     }
>     if (!QEMU_IS_ALIGNED(s->rsdp_mr_size, qemu_real_host_page_size)) {
>         return false;
>     }
>     return true;

I think I prefer the original version though. Matter of taste?

> > +}
> > +
> > +static void fw_cfg_update_mr(FWCfgState *s, uint16_t key, size_t size)
> > +{
> > +    MemoryRegion *mr;
> > +    ram_addr_t offset;
> > +    int arch = !!(key & FW_CFG_ARCH_LOCAL);
> > +    void *ptr;
> > +
> > +    key &= FW_CFG_ENTRY_MASK;
> > +    assert(key < fw_cfg_max_entry(s));
> > +
> > +    ptr = s->entries[arch][key].data;
> > +    mr = memory_region_from_host(ptr, &offset);
> > +
> > +    memory_region_ram_resize(mr, size, &error_abort);
> > +}
> > +
> > +static int fw_cfg_acpi_mr_restore_post_load(void *opaque, int version_id)
> > +{
> > +    FWCfgState *s = opaque;
> > +    int i, index;
> > +
> > +    assert(s->files);
> > +
> > +    index = be32_to_cpu(s->files->count);
> > +
> > +    for (i = 0; i < index; i++) {
> > +        if (!strcmp(s->files->f[i].name, ACPI_BUILD_TABLE_FILE)) {
> > +            fw_cfg_update_mr(s, FW_CFG_FILE_FIRST + i, s->table_mr_size);
> > +        } else if (!strcmp(s->files->f[i].name, ACPI_BUILD_LOADER_FILE)) {
> > +            fw_cfg_update_mr(s, FW_CFG_FILE_FIRST + i, s->linker_mr_size);
> > +        } else if (!strcmp(s->files->f[i].name, ACPI_BUILD_RSDP_FILE)) {
> > +            fw_cfg_update_mr(s, FW_CFG_FILE_FIRST + i, s->rsdp_mr_size);
> > +        }
> > +    }
> > +
> > +    return 0;
> > +}
> > +
> >   static const VMStateDescription vmstate_fw_cfg_dma = {
> >       .name = "fw_cfg/dma",
> >       .needed = fw_cfg_dma_enabled,
> > @@ -619,6 +669,20 @@ static const VMStateDescription vmstate_fw_cfg_dma = {
> >       },
> >   };
> > +static const VMStateDescription vmstate_fw_cfg_acpi_mr = {
> > +    .name = "fw_cfg/acpi_mr",
> > +    .version_id = 1,
> > +    .minimum_version_id = 1,
> > +    .needed = fw_cfg_acpi_mr_restore,
> > +    .post_load = fw_cfg_acpi_mr_restore_post_load,
> > +    .fields = (VMStateField[]) {
> > +        VMSTATE_UINT64(table_mr_size, FWCfgState),
> > +        VMSTATE_UINT64(linker_mr_size, FWCfgState),
> > +        VMSTATE_UINT64(rsdp_mr_size, FWCfgState),
> > +        VMSTATE_END_OF_LIST()
> > +    },
> > +};
> > +
> >   static const VMStateDescription vmstate_fw_cfg = {
> >       .name = "fw_cfg",
> >       .version_id = 2,
> > @@ -631,6 +695,7 @@ static const VMStateDescription vmstate_fw_cfg = {
> >       },
> >       .subsections = (const VMStateDescription*[]) {
> >           &vmstate_fw_cfg_dma,
> > +        &vmstate_fw_cfg_acpi_mr,
> >           NULL,
> >       }
> >   };
> > @@ -815,6 +880,23 @@ static struct {
> >   #define FW_CFG_ORDER_OVERRIDE_LAST 200
> >   };
> > +/*
> > + * Any sub-page size update to these table MRs will be lost during migration,
> > + * as we use aligned size in ram_load_precopy() -> qemu_ram_resize() path.
> > + * In order to avoid the inconsistency in sizes save them seperately and
> > + * migrate over in vmstate post_load().
> > + */
> > +static void fw_cfg_acpi_mr_save(FWCfgState *s, const char *filename, size_t len)
> > +{
> > +    if (!strcmp(filename, ACPI_BUILD_TABLE_FILE)) {
> > +        s->table_mr_size = len;
> > +    } else if (!strcmp(filename, ACPI_BUILD_LOADER_FILE)) {
> > +        s->linker_mr_size = len;
> > +    } else if (!strcmp(filename, ACPI_BUILD_RSDP_FILE)) {
> > +        s->rsdp_mr_size = len;
> > +    }
> > +}
> > +
> >   static int get_fw_cfg_order(FWCfgState *s, const char *name)
> >   {
> >       int i;
> > @@ -914,6 +996,7 @@ void fw_cfg_add_file_callback(FWCfgState *s,  const char *filename,
> >       trace_fw_cfg_add_file(s, index, s->files->f[index].name, len);
> >       s->files->count = cpu_to_be32(count+1);
> > +    fw_cfg_acpi_mr_save(s, filename, len);
> >   }
> >   void fw_cfg_add_file(FWCfgState *s,  const char *filename,
> > @@ -937,6 +1020,7 @@ void *fw_cfg_modify_file(FWCfgState *s, const char *filename,
> >               ptr = fw_cfg_modify_bytes_read(s, FW_CFG_FILE_FIRST + i,
> >                                              data, len);
> >               s->files->f[i].size   = cpu_to_be32(len);
> > +            fw_cfg_acpi_mr_save(s, filename, len);
> >               return ptr;
> >           }
> >       }
> > @@ -973,7 +1057,10 @@ static void fw_cfg_machine_ready(struct Notifier *n, void *data)
> >       qemu_register_reset(fw_cfg_machine_reset, s);
> >   }
> > -
> > +static Property fw_cfg_properties[] = {
> > +    DEFINE_PROP_BOOL("acpi-mr-restore", FWCfgState, acpi_mr_restore, true),
> > +    DEFINE_PROP_END_OF_LIST(),
> > +};
> >   static void fw_cfg_common_realize(DeviceState *dev, Error **errp)
> >   {
> > @@ -1097,6 +1184,8 @@ static void fw_cfg_class_init(ObjectClass *klass, void *data)
> >       dc->reset = fw_cfg_reset;
> >       dc->vmsd = &vmstate_fw_cfg;
> > +
> > +    device_class_set_props(dc, fw_cfg_properties);
> >   }
> >   static const TypeInfo fw_cfg_info = {
> > diff --git a/include/hw/nvram/fw_cfg.h b/include/hw/nvram/fw_cfg.h
> > index b5291eefad..25d9307018 100644
> > --- a/include/hw/nvram/fw_cfg.h
> > +++ b/include/hw/nvram/fw_cfg.h
> > @@ -53,6 +53,12 @@ struct FWCfgState {
> >       dma_addr_t dma_addr;
> >       AddressSpace *dma_as;
> >       MemoryRegion dma_iomem;
> > +
> > +    /* restore during migration */
> > +    bool acpi_mr_restore;
> > +    uint64_t table_mr_size;
> > +    uint64_t linker_mr_size;
> > +    uint64_t rsdp_mr_size;
> >   };
> >   struct FWCfgIoState {
> > 



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH for-5.0 v2 2/3] fw_cfg: Migrate ACPI table mr sizes separately
  2020-04-07 14:34     ` Michael S. Tsirkin
@ 2020-04-07 14:54       ` David Hildenbrand
  2020-04-07 17:03         ` Philippe Mathieu-Daudé
  0 siblings, 1 reply; 11+ messages in thread
From: David Hildenbrand @ 2020-04-07 14:54 UTC (permalink / raw)
  To: Michael S. Tsirkin, Philippe Mathieu-Daudé
  Cc: peter.maydell, xiaoguangrong.eric, shannon.zhaosl, linuxarm,
	qemu-devel, Shameer Kolothum, dgilbert, eric.auger, qemu-arm,
	xuwei5, imammedo, lersek

On 07.04.20 16:34, Michael S. Tsirkin wrote:
> On Tue, Apr 07, 2020 at 04:17:46PM +0200, Philippe Mathieu-Daudé wrote:
>> On 4/3/20 12:18 PM, Shameer Kolothum wrote:
>>> Any sub-page size update to ACPI MRs will be lost during
>>> migration, as we use aligned size in ram_load_precopy() ->
>>> qemu_ram_resize() path. This will result in inconsistency in
>>> FWCfgEntry sizes between source and destination. In order to avoid
>>> this, save and restore them separately during migration.
>>>
>>> Up until now, this problem may not be that relevant for x86 as both
>>> ACPI table and Linker MRs gets padded and aligned. Also at present,
>>> qemu_ram_resize() doesn't invoke callback to update FWCfgEntry for
>>> unaligned size changes. But since we are going to fix the
>>> qemu_ram_resize() in the subsequent patch, the issue may become
>>> more serious especially for RSDP MR case.
>>>
>>> Moreover, the issue will soon become prominent in arm/virt as well
>>> where the MRs are not padded or aligned at all and eventually have
>>> acpi table changes as part of future additions like NVDIMM hot-add
>>> feature.
>>>
>>> Suggested-by: David Hildenbrand <david@redhat.com>
>>> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
>>> Acked-by: David Hildenbrand <david@redhat.com>
>>> ---
>>> v1 --> v2
>>>   - Changed *_mr_size from size_t to uint64_t to address portability.
>>>   - post_copy only done if sizes are not aligned.
>>>
>>> Please find previous discussions here,
>>> https://patchwork.kernel.org/patch/11339591/#23140343
>>> ---
>>>   hw/core/machine.c         |  1 +
>>>   hw/nvram/fw_cfg.c         | 91 ++++++++++++++++++++++++++++++++++++++-
>>>   include/hw/nvram/fw_cfg.h |  6 +++
>>>   3 files changed, 97 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/hw/core/machine.c b/hw/core/machine.c
>>> index de0c425605..c1a444cb75 100644
>>> --- a/hw/core/machine.c
>>> +++ b/hw/core/machine.c
>>> @@ -39,6 +39,7 @@ GlobalProperty hw_compat_4_2[] = {
>>>       { "usb-redir", "suppress-remote-wake", "off" },
>>>       { "qxl", "revision", "4" },
>>>       { "qxl-vga", "revision", "4" },
>>> +    { "fw_cfg", "acpi-mr-restore", "false" },
>>>   };
>>>   const size_t hw_compat_4_2_len = G_N_ELEMENTS(hw_compat_4_2);
>>> diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
>>> index 179b302f01..4be6c9d9fd 100644
>>> --- a/hw/nvram/fw_cfg.c
>>> +++ b/hw/nvram/fw_cfg.c
>>> @@ -39,6 +39,7 @@
>>>   #include "qemu/config-file.h"
>>>   #include "qemu/cutils.h"
>>>   #include "qapi/error.h"
>>> +#include "hw/acpi/aml-build.h"
>>>   #define FW_CFG_FILE_SLOTS_DFLT 0x20
>>> @@ -610,6 +611,55 @@ bool fw_cfg_dma_enabled(void *opaque)
>>>       return s->dma_enabled;
>>>   }
>>> +static bool fw_cfg_acpi_mr_restore(void *opaque)
>>> +{
>>> +    FWCfgState *s = opaque;
>>> +    bool mr_aligned;
>>> +
>>> +    mr_aligned = QEMU_IS_ALIGNED(s->table_mr_size, qemu_real_host_page_size) &&
>>> +                 QEMU_IS_ALIGNED(s->linker_mr_size, qemu_real_host_page_size) &&
>>> +                 QEMU_IS_ALIGNED(s->rsdp_mr_size, qemu_real_host_page_size);
>>> +    return s->acpi_mr_restore && !mr_aligned;
>>
>> This code is hard to review.
>>
>> Is this equivalent?
>>
>>     if (!s->acpi_mr_restore) {
>>         return false;
>>     }
>>     if (!QEMU_IS_ALIGNED(s->table_mr_size, qemu_real_host_page_size)) {
>>         return false;
>>     }
>>     if (!QEMU_IS_ALIGNED(s->linker_mr_size, qemu_real_host_page_size)) {
>>         return false;
>>     }
>>     if (!QEMU_IS_ALIGNED(s->rsdp_mr_size, qemu_real_host_page_size)) {
>>         return false;
>>     }
>>     return true;
> 
> I think I prefer the original version though. Matter of taste?

At least I find the original code fairly easy to read - just as the
proposed alternative. So, yes, matter of taste I'd say.


-- 
Thanks,

David / dhildenb



^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH for-5.0 v2 2/3] fw_cfg: Migrate ACPI table mr sizes separately
  2020-04-07 14:54       ` David Hildenbrand
@ 2020-04-07 17:03         ` Philippe Mathieu-Daudé
  0 siblings, 0 replies; 11+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-04-07 17:03 UTC (permalink / raw)
  To: David Hildenbrand, Michael S. Tsirkin
  Cc: peter.maydell, xiaoguangrong.eric, shannon.zhaosl, linuxarm,
	qemu-devel, Shameer Kolothum, dgilbert, eric.auger, qemu-arm,
	xuwei5, imammedo, lersek

On 4/7/20 4:54 PM, David Hildenbrand wrote:
> On 07.04.20 16:34, Michael S. Tsirkin wrote:
>> On Tue, Apr 07, 2020 at 04:17:46PM +0200, Philippe Mathieu-Daudé wrote:
>>> On 4/3/20 12:18 PM, Shameer Kolothum wrote:
>>>> Any sub-page size update to ACPI MRs will be lost during
>>>> migration, as we use aligned size in ram_load_precopy() ->
>>>> qemu_ram_resize() path. This will result in inconsistency in
>>>> FWCfgEntry sizes between source and destination. In order to avoid
>>>> this, save and restore them separately during migration.
>>>>
>>>> Up until now, this problem may not be that relevant for x86 as both
>>>> ACPI table and Linker MRs gets padded and aligned. Also at present,
>>>> qemu_ram_resize() doesn't invoke callback to update FWCfgEntry for
>>>> unaligned size changes. But since we are going to fix the
>>>> qemu_ram_resize() in the subsequent patch, the issue may become
>>>> more serious especially for RSDP MR case.
>>>>
>>>> Moreover, the issue will soon become prominent in arm/virt as well
>>>> where the MRs are not padded or aligned at all and eventually have
>>>> acpi table changes as part of future additions like NVDIMM hot-add
>>>> feature.
>>>>
>>>> Suggested-by: David Hildenbrand <david@redhat.com>
>>>> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
>>>> Acked-by: David Hildenbrand <david@redhat.com>
>>>> ---
>>>> v1 --> v2
>>>>    - Changed *_mr_size from size_t to uint64_t to address portability.
>>>>    - post_copy only done if sizes are not aligned.
>>>>
>>>> Please find previous discussions here,
>>>> https://patchwork.kernel.org/patch/11339591/#23140343
>>>> ---
>>>>    hw/core/machine.c         |  1 +
>>>>    hw/nvram/fw_cfg.c         | 91 ++++++++++++++++++++++++++++++++++++++-
>>>>    include/hw/nvram/fw_cfg.h |  6 +++
>>>>    3 files changed, 97 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/hw/core/machine.c b/hw/core/machine.c
>>>> index de0c425605..c1a444cb75 100644
>>>> --- a/hw/core/machine.c
>>>> +++ b/hw/core/machine.c
>>>> @@ -39,6 +39,7 @@ GlobalProperty hw_compat_4_2[] = {
>>>>        { "usb-redir", "suppress-remote-wake", "off" },
>>>>        { "qxl", "revision", "4" },
>>>>        { "qxl-vga", "revision", "4" },
>>>> +    { "fw_cfg", "acpi-mr-restore", "false" },
>>>>    };
>>>>    const size_t hw_compat_4_2_len = G_N_ELEMENTS(hw_compat_4_2);
>>>> diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
>>>> index 179b302f01..4be6c9d9fd 100644
>>>> --- a/hw/nvram/fw_cfg.c
>>>> +++ b/hw/nvram/fw_cfg.c
>>>> @@ -39,6 +39,7 @@
>>>>    #include "qemu/config-file.h"
>>>>    #include "qemu/cutils.h"
>>>>    #include "qapi/error.h"
>>>> +#include "hw/acpi/aml-build.h"
>>>>    #define FW_CFG_FILE_SLOTS_DFLT 0x20
>>>> @@ -610,6 +611,55 @@ bool fw_cfg_dma_enabled(void *opaque)
>>>>        return s->dma_enabled;
>>>>    }
>>>> +static bool fw_cfg_acpi_mr_restore(void *opaque)
>>>> +{
>>>> +    FWCfgState *s = opaque;
>>>> +    bool mr_aligned;
>>>> +
>>>> +    mr_aligned = QEMU_IS_ALIGNED(s->table_mr_size, qemu_real_host_page_size) &&
>>>> +                 QEMU_IS_ALIGNED(s->linker_mr_size, qemu_real_host_page_size) &&
>>>> +                 QEMU_IS_ALIGNED(s->rsdp_mr_size, qemu_real_host_page_size);
>>>> +    return s->acpi_mr_restore && !mr_aligned;
>>>
>>> This code is hard to review.
>>>
>>> Is this equivalent?
>>>
>>>      if (!s->acpi_mr_restore) {
>>>          return false;
>>>      }
>>>      if (!QEMU_IS_ALIGNED(s->table_mr_size, qemu_real_host_page_size)) {
>>>          return false;
>>>      }
>>>      if (!QEMU_IS_ALIGNED(s->linker_mr_size, qemu_real_host_page_size)) {
>>>          return false;
>>>      }
>>>      if (!QEMU_IS_ALIGNED(s->rsdp_mr_size, qemu_real_host_page_size)) {
>>>          return false;
>>>      }
>>>      return true;
>>
>> I think I prefer the original version though. Matter of taste?
> 
> At least I find the original code fairly easy to read - just as the
> proposed alternative. So, yes, matter of taste I'd say.

OK :)



^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2020-04-07 17:04 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-03 10:18 [PATCH for-5.0 v2 0/3] acpi: Fixes for inconsistency in ACPI MR size during migration Shameer Kolothum
2020-04-03 10:18 ` [PATCH for-5.0 v2 1/3] acpi: Use macro for table-loader file name Shameer Kolothum
2020-04-03 10:45   ` Philippe Mathieu-Daudé
2020-04-03 10:18 ` [PATCH for-5.0 v2 2/3] fw_cfg: Migrate ACPI table mr sizes separately Shameer Kolothum
2020-04-07 14:17   ` Philippe Mathieu-Daudé
2020-04-07 14:34     ` Michael S. Tsirkin
2020-04-07 14:54       ` David Hildenbrand
2020-04-07 17:03         ` Philippe Mathieu-Daudé
2020-04-03 10:18 ` [PATCH for-5.0 v2 3/3] exec: Fix for qemu_ram_resize() callback Shameer Kolothum
2020-04-03 10:50   ` Philippe Mathieu-Daudé
2020-04-03 12:37 ` [PATCH for-5.0 v2 0/3] acpi: Fixes for inconsistency in ACPI MR size during migration Michael S. Tsirkin

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.