[Qemu-devel] [PATCH v2 0/3] Migration-safe ACPI table sizing algorithm

[Qemu-devel] [PATCH v2 0/3] Migration-safe ACPI table sizing algorithm

[Paolo Bonzini]

In the emergency last-minute patches of QEMU 2.1 we did two things:

- fixed migration problems from 1.7 or 2.0 to 2.1 due to changes in
  ACPI table sizes

- ensured that future versions will not break migration compatibility
  with 2.2 for reasonable configurations (with ACPI tables smaller
  than a hundred kilobytes, roughly)

However, this came at the cost of wasting 128 KB unconditionally on
even the smaller configuration, and we didn't provide a mechanism to
ensure compatibility with larger configurations.

This series provides this mechanism.  As mentioned early, the design
is to consider the SSDT immutable and versioned (together with other
non-AML tables such as HPET, TPMA and MADT, SRAT, MCFG, DMAR).
The DSDT instead can change more or less arbitrarily.  To do this,
we add padding after the DSDT to allow for future growth (patch 1).

Once we do this, the size of the ACPI table fw_cfg "file" is constant
given a machine type and a command-line, so we do not need anymore the
larger 128KB padding (patch 2).

Patch 3 is just cleanups.

Paolo

v1->v2: drop linuxboot changes, instead modify the option ROM
        in a separate patch

Paolo Bonzini (3):
  pc: introduce new ACPI table sizing algorithm
  pc: go back to smaller ACPI tables
  pc: clean up pre-2.1 compatibility code

 hw/i386/acpi-build.c | 20 +++++++++++---------
 hw/i386/pc_piix.c    | 20 +++++++++++++++++++-
 hw/i386/pc_q35.c     |  6 ++++--
 include/hw/i386/pc.h |  2 ++
 4 files changed, 36 insertions(+), 12 deletions(-)

-- 
2.1.0

[Qemu-devel] [PATCH v2 1/3] pc: introduce new ACPI table sizing algorithm

[Paolo Bonzini]

Add padding after the DSDT.  Tables that vary depending on the
command-line arguments will have to be byte-equivalent across QEMU
versions >= 2.2, while fixed tables (including the DSDT) can be
changed freely.

This new algorithm will let us present smaller ACPI blobs to
the guest, which avoids bugs with -kernel/-initrd and 32-bit
RHEL5 guests.  However, this patch does not change the size of
the blobs yet; for now, the values of the parameters are tuned
to have 2.1-compatible sizes.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 hw/i386/acpi-build.c | 11 +++++++----
 hw/i386/pc_piix.c    |  5 +++++
 include/hw/i386/pc.h |  2 ++
 3 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index a313321..6bffc75 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -65,8 +65,6 @@
 #define ACPI_BUILD_LEGACY_CPU_AML_SIZE    97
 #define ACPI_BUILD_ALIGN_SIZE             0x1000
 
-#define ACPI_BUILD_TABLE_SIZE             0x20000
-
 typedef struct AcpiCpuInfo {
     DECLARE_BITMAP(found_cpus, ACPI_CPU_HOTPLUG_ID_LIMIT);
 } AcpiCpuInfo;
@@ -1597,6 +1595,10 @@ void acpi_build(PcGuestInfo *guest_info, AcpiBuildTables *tables)
     acpi_add_table(table_offsets, tables->table_data);
     build_fadt(tables->table_data, tables->linker, &pm, facs, dsdt);
 
+    if (guest_info->fixed_table_align) {
+        acpi_align_size(tables->table_data, guest_info->fixed_table_align);
+    }
+
     ssdt = tables->table_data->len;
     acpi_add_table(table_offsets, tables->table_data);
     build_ssdt(tables->table_data, tables->linker, &cpu, &pm, &misc, &pci,
@@ -1681,14 +1683,15 @@ void acpi_build(PcGuestInfo *guest_info, AcpiBuildTables *tables)
         g_array_set_size(tables->table_data, legacy_table_size);
     } else {
         /* Make sure we have a buffer in case we need to resize the tables. */
-        if (tables->table_data->len > ACPI_BUILD_TABLE_SIZE / 2) {
+        if (!guest_info->fixed_table_align &&
+	    tables->table_data->len > guest_info->acpi_table_align / 2) {
             /* As of QEMU 2.1, this fires with 160 VCPUs and 255 memory slots.  */
             error_report("Warning: ACPI tables are larger than 64k.");
             error_report("Warning: migration may not work.");
             error_report("Warning: please remove CPUs, NUMA nodes, "
                          "memory slots or PCI bridges.");
         }
-        acpi_align_size(tables->table_data, ACPI_BUILD_TABLE_SIZE);
+        acpi_align_size(tables->table_data, guest_info->acpi_table_align);
     }
 
     acpi_align_size(tables->linker, ACPI_BUILD_ALIGN_SIZE);
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 103d756..060f6ec 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -61,6 +61,8 @@ static const int ide_irq[MAX_IDE_BUS] = { 14, 15 };
 
 static bool has_acpi_build = true;
 static int legacy_acpi_table_size;
+static int fixed_table_align = 0;
+static int acpi_table_align = 131072;
 static bool smbios_defaults = true;
 static bool smbios_legacy_mode;
 /* Make sure that guest addresses aligned at 1Gbyte boundaries get mapped to
@@ -164,6 +166,8 @@ static void pc_init1(MachineState *machine,
 
     guest_info->has_acpi_build = has_acpi_build;
     guest_info->legacy_acpi_table_size = legacy_acpi_table_size;
+    guest_info->fixed_table_align = fixed_table_align;
+    guest_info->acpi_table_align = acpi_table_align;
 
     guest_info->isapc_ram_fw = !pci_enabled;
     guest_info->has_reserved_memory = has_reserved_memory;
@@ -321,6 +325,7 @@ static void pc_compat_2_0(MachineState *machine)
      * QEMU 1.7 it is 6414.  For RHEL/CentOS 7.0 it is 6418.
      */
     legacy_acpi_table_size = 6652;
+    acpi_table_align = 4096;
     smbios_legacy_mode = true;
     has_reserved_memory = false;
     pc_set_legacy_acpi_data_size();
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 77316d5..517e729 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -94,6 +94,8 @@ struct PcGuestInfo {
     uint64_t *node_cpu;
     FWCfgState *fw_cfg;
     int legacy_acpi_table_size;
+    int fixed_table_align;
+    int acpi_table_align;
     bool has_acpi_build;
     bool has_reserved_memory;
 };
-- 
2.1.0

[Qemu-devel] [PATCH v2 2/3] pc: go back to smaller ACPI tables

[Paolo Bonzini]

The new algorithm introduced by the previous patch lets us make tables
smaller and avoid bugs due to large tables.

Use it for 2.2+ machine types by tweaking the default fixed_table_align
and acpi_table_align values.  At the same time, preserve backwards-compatible
logic for pc-i440fx-2.1.

Without this patch:
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x0000000007fdffff] usable
[    0.000000] BIOS-e820: [mem 0x0000000007fe0000-0x0000000007ffffff] reserved
...
[    0.000000] init_memory_mapping: [mem 0x07000000-0x07fdffff] usable
[    0.000000] RAMDISK: [mem 0x07112000-0x07fdffff]

With this patch:
[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x0000000007ffafff] usable
[    0.000000] BIOS-e820: [mem 0x0000000007ffb000-0x0000000007ffffff] reserved
...
[    0.000000] init_memory_mapping: [mem 0x07000000-0x07ffafff]
[    0.000000] RAMDISK: [mem 0x07122000-0x07feffff]

Thanks to the new linuxboot option ROM, the initrd is loaded 64k above.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 hw/i386/pc_piix.c | 19 ++++++++++++++++---
 hw/i386/pc_q35.c  |  6 ++++--
 2 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 060f6ec..0d3a191 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -61,8 +61,8 @@ static const int ide_irq[MAX_IDE_BUS] = { 14, 15 };
 
 static bool has_acpi_build = true;
 static int legacy_acpi_table_size;
-static int fixed_table_align = 0;
-static int acpi_table_align = 131072;
+static int fixed_table_align = 16384;
+static int acpi_table_align = 4096;
 static bool smbios_defaults = true;
 static bool smbios_legacy_mode;
 /* Make sure that guest addresses aligned at 1Gbyte boundaries get mapped to
@@ -306,6 +306,12 @@ static void pc_init_pci(MachineState *machine)
     pc_init1(machine, 1, 1);
 }
 
+static void pc_compat_2_1(MachineState *machine)
+{
+    fixed_table_align = 0;
+    acpi_table_align = 131072;
+}
+
 static void pc_compat_2_0(MachineState *machine)
 {
     /* This value depends on the actual DSDT and SSDT compiled into
@@ -324,6 +330,7 @@ static void pc_compat_2_0(MachineState *machine)
      * 6652 is valid for QEMU 2.0, the right value for pc-i440fx-1.7 on
      * QEMU 1.7 it is 6414.  For RHEL/CentOS 7.0 it is 6418.
      */
+    pc_compat_2_1(machine);
     legacy_acpi_table_size = 6652;
     acpi_table_align = 4096;
     smbios_legacy_mode = true;
@@ -373,6 +380,12 @@ static void pc_compat_1_2(MachineState *machine)
     x86_cpu_compat_disable_kvm_features(FEAT_KVM, KVM_FEATURE_PV_EOI);
 }
 
+static void pc_init_pci_2_1(MachineState *machine)
+{
+    pc_compat_2_1(machine);
+    pc_init_pci(machine);
+}
+
 static void pc_init_pci_2_0(MachineState *machine)
 {
     pc_compat_2_0(machine);
@@ -476,7 +489,7 @@ static QEMUMachine pc_i440fx_machine_v2_2 = {
 static QEMUMachine pc_i440fx_machine_v2_1 = {
     PC_I440FX_2_1_MACHINE_OPTIONS,
     .name = "pc-i440fx-2.1",
-    .init = pc_init_pci,
+    .init = pc_init_pci_2_1,
     .compat_props = (GlobalProperty[]) {
         PC_COMPAT_2_1,
         { /* end of list */ }
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index d4a907c..3443f32 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -153,10 +153,12 @@ static void pc_q35_init(MachineState *machine)
     guest_info->has_acpi_build = has_acpi_build;
     guest_info->has_reserved_memory = has_reserved_memory;
 
-    /* Migration was not supported in 2.0 for Q35, so do not bother
-     * with this hack (see hw/i386/acpi-build.c).
+    /* Migration was not supported in 2.0 for Q35, so do not bother with
+     * hacks around the ACPI table size (see hw/i386/acpi-build.c).
      */
     guest_info->legacy_acpi_table_size = 0;
+    guest_info->fixed_table_align = 16384;
+    guest_info->acpi_table_align = 4096;
 
     if (smbios_defaults) {
         MachineClass *mc = MACHINE_GET_CLASS(machine);
-- 
2.1.0

[Qemu-devel] [PATCH v2 3/3] pc: clean up pre-2.1 compatibility code

[Paolo Bonzini]

Now that the alignment is parameterized, we can share the call to
acpi_align_size between all three (1.7-2.0/2.1/2.2+) sizing algorithms.

Also, with the new rule that SSDT cannot change except with
machine-type compat code, the magic 97 constant for a CPU's
AML size is not anymore "legacy", so rename it.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
---
 hw/i386/acpi-build.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/hw/i386/acpi-build.c b/hw/i386/acpi-build.c
index 6bffc75..ec6828e 100644
--- a/hw/i386/acpi-build.c
+++ b/hw/i386/acpi-build.c
@@ -62,8 +62,8 @@
  * a little bit, there should be plenty of free space since the DSDT
  * shrunk by ~1.5k between QEMU 2.0 and QEMU 2.1.
  */
-#define ACPI_BUILD_LEGACY_CPU_AML_SIZE    97
-#define ACPI_BUILD_ALIGN_SIZE             0x1000
+#define ACPI_BUILD_CPU_AML_SIZE    97
+#define ACPI_BUILD_ALIGN_SIZE      0x1000
 
 typedef struct AcpiCpuInfo {
     DECLARE_BITMAP(found_cpus, ACPI_CPU_HOTPLUG_ID_LIMIT);
@@ -1672,10 +1672,9 @@ void acpi_build(PcGuestInfo *guest_info, AcpiBuildTables *tables)
          */
         int legacy_aml_len =
             guest_info->legacy_acpi_table_size +
-            ACPI_BUILD_LEGACY_CPU_AML_SIZE * max_cpus;
+            ACPI_BUILD_CPU_AML_SIZE * max_cpus;
         int legacy_table_size =
-            ROUND_UP(tables->table_data->len - aml_len + legacy_aml_len,
-                     ACPI_BUILD_ALIGN_SIZE);
+            tables->table_data->len - aml_len + legacy_aml_len;
         if (tables->table_data->len > legacy_table_size) {
             /* Should happen only with PCI bridges and -M pc-i440fx-2.0.  */
             error_report("Warning: migration may not work.");
@@ -1691,8 +1690,8 @@ void acpi_build(PcGuestInfo *guest_info, AcpiBuildTables *tables)
             error_report("Warning: please remove CPUs, NUMA nodes, "
                          "memory slots or PCI bridges.");
         }
-        acpi_align_size(tables->table_data, guest_info->acpi_table_align);
     }
+    acpi_align_size(tables->table_data, guest_info->acpi_table_align);
 
     acpi_align_size(tables->linker, ACPI_BUILD_ALIGN_SIZE);
 
-- 
2.1.0

Re: [Qemu-devel] [PATCH v2 0/3] Migration-safe ACPI table sizing algorithm

[Paolo Bonzini]

On 06/10/2014 16:56, Paolo Bonzini wrote:
> In the emergency last-minute patches of QEMU 2.1 we did two things:
> 
> - fixed migration problems from 1.7 or 2.0 to 2.1 due to changes in
>   ACPI table sizes
> 
> - ensured that future versions will not break migration compatibility
>   with 2.2 for reasonable configurations (with ACPI tables smaller
>   than a hundred kilobytes, roughly)
> 
> However, this came at the cost of wasting 128 KB unconditionally on
> even the smaller configuration, and we didn't provide a mechanism to
> ensure compatibility with larger configurations.
> 
> This series provides this mechanism.  As mentioned early, the design
> is to consider the SSDT immutable and versioned (together with other
> non-AML tables such as HPET, TPMA and MADT, SRAT, MCFG, DMAR).
> The DSDT instead can change more or less arbitrarily.  To do this,
> we add padding after the DSDT to allow for future growth (patch 1).
> 
> Once we do this, the size of the ACPI table fw_cfg "file" is constant
> given a machine type and a command-line, so we do not need anymore the
> larger 128KB padding (patch 2).
> 
> Patch 3 is just cleanups.
> 
> Paolo
> 
> v1->v2: drop linuxboot changes, instead modify the option ROM
>         in a separate patch
> 
> Paolo Bonzini (3):
>   pc: introduce new ACPI table sizing algorithm
>   pc: go back to smaller ACPI tables
>   pc: clean up pre-2.1 compatibility code
> 
>  hw/i386/acpi-build.c | 20 +++++++++++---------
>  hw/i386/pc_piix.c    | 20 +++++++++++++++++++-
>  hw/i386/pc_q35.c     |  6 ++++--
>  include/hw/i386/pc.h |  2 ++
>  4 files changed, 36 insertions(+), 12 deletions(-)
> 

Ping?

Paolo

Re: [Qemu-devel] [PATCH v2 0/3] Migration-safe ACPI table sizing algorithm

[Paolo Bonzini]

On 11/11/2014 18:13, Paolo Bonzini wrote:
> 
> 
> On 06/10/2014 16:56, Paolo Bonzini wrote:
>> In the emergency last-minute patches of QEMU 2.1 we did two things:
>>
>> - fixed migration problems from 1.7 or 2.0 to 2.1 due to changes in
>>   ACPI table sizes
>>
>> - ensured that future versions will not break migration compatibility
>>   with 2.2 for reasonable configurations (with ACPI tables smaller
>>   than a hundred kilobytes, roughly)
>>
>> However, this came at the cost of wasting 128 KB unconditionally on
>> even the smaller configuration, and we didn't provide a mechanism to
>> ensure compatibility with larger configurations.
>>
>> This series provides this mechanism.  As mentioned early, the design
>> is to consider the SSDT immutable and versioned (together with other
>> non-AML tables such as HPET, TPMA and MADT, SRAT, MCFG, DMAR).
>> The DSDT instead can change more or less arbitrarily.  To do this,
>> we add padding after the DSDT to allow for future growth (patch 1).
>>
>> Once we do this, the size of the ACPI table fw_cfg "file" is constant
>> given a machine type and a command-line, so we do not need anymore the
>> larger 128KB padding (patch 2).
>>
>> Patch 3 is just cleanups.
>>
>> Paolo
>>
>> v1->v2: drop linuxboot changes, instead modify the option ROM
>>         in a separate patch
>>
>> Paolo Bonzini (3):
>>   pc: introduce new ACPI table sizing algorithm
>>   pc: go back to smaller ACPI tables
>>   pc: clean up pre-2.1 compatibility code
>>
>>  hw/i386/acpi-build.c | 20 +++++++++++---------
>>  hw/i386/pc_piix.c    | 20 +++++++++++++++++++-
>>  hw/i386/pc_q35.c     |  6 ++++--
>>  include/hw/i386/pc.h |  2 ++
>>  4 files changed, 36 insertions(+), 12 deletions(-)
>>
> 
> Ping?

Ping??

Paolo

Re: [Qemu-devel] [PATCH v2 0/3] Migration-safe ACPI table sizing algorithm

[Michael S. Tsirkin]

On Thu, Nov 20, 2014 at 07:05:05AM +0100, Paolo Bonzini wrote:
> 
> 
> On 11/11/2014 18:13, Paolo Bonzini wrote:
> > 
> > 
> > On 06/10/2014 16:56, Paolo Bonzini wrote:
> >> In the emergency last-minute patches of QEMU 2.1 we did two things:
> >>
> >> - fixed migration problems from 1.7 or 2.0 to 2.1 due to changes in
> >>   ACPI table sizes
> >>
> >> - ensured that future versions will not break migration compatibility
> >>   with 2.2 for reasonable configurations (with ACPI tables smaller
> >>   than a hundred kilobytes, roughly)
> >>
> >> However, this came at the cost of wasting 128 KB unconditionally on
> >> even the smaller configuration, and we didn't provide a mechanism to
> >> ensure compatibility with larger configurations.
> >>
> >> This series provides this mechanism.  As mentioned early, the design
> >> is to consider the SSDT immutable and versioned (together with other
> >> non-AML tables such as HPET, TPMA and MADT, SRAT, MCFG, DMAR).
> >> The DSDT instead can change more or less arbitrarily.  To do this,
> >> we add padding after the DSDT to allow for future growth (patch 1).
> >>
> >> Once we do this, the size of the ACPI table fw_cfg "file" is constant
> >> given a machine type and a command-line, so we do not need anymore the
> >> larger 128KB padding (patch 2).
> >>
> >> Patch 3 is just cleanups.
> >>
> >> Paolo
> >>
> >> v1->v2: drop linuxboot changes, instead modify the option ROM
> >>         in a separate patch
> >>
> >> Paolo Bonzini (3):
> >>   pc: introduce new ACPI table sizing algorithm
> >>   pc: go back to smaller ACPI tables
> >>   pc: clean up pre-2.1 compatibility code
> >>
> >>  hw/i386/acpi-build.c | 20 +++++++++++---------
> >>  hw/i386/pc_piix.c    | 20 +++++++++++++++++++-
> >>  hw/i386/pc_q35.c     |  6 ++++--
> >>  include/hw/i386/pc.h |  2 ++
> >>  4 files changed, 36 insertions(+), 12 deletions(-)
> >>
> > 
> > Ping?
> 
> Ping??
> 
> Paolo

I thought we agreed we'll consider alternate approaches after 2.2?
I would prefer not to have yet another mode to support
if we can help it.

-- 
MST

Re: [Qemu-devel] [PATCH v2 0/3] Migration-safe ACPI table sizing algorithm

[Paolo Bonzini]

On 20/11/2014 07:55, Michael S. Tsirkin wrote:
> I thought we agreed we'll consider alternate approaches after 2.2?
> I would prefer not to have yet another mode to support
> if we can help it.

I agree, but:

1) looks like there is stronger opposition to your patch than I thought,
so a 2.2 solution as in this patch becomes more palatable

2) reviewing patches is always nice, and helps evaluating the advantages
of either approach

Paolo

Re: [Qemu-devel] [PATCH v2 0/3] Migration-safe ACPI table sizing algorithm

[Michael S. Tsirkin]

On Thu, Nov 20, 2014 at 08:11:05AM +0100, Paolo Bonzini wrote:
> 
> 
> On 20/11/2014 07:55, Michael S. Tsirkin wrote:
> > I thought we agreed we'll consider alternate approaches after 2.2?
> > I would prefer not to have yet another mode to support
> > if we can help it.
> 
> I agree, but:
> 
> 1) looks like there is stronger opposition to your patch than I thought,
> so a 2.2 solution as in this patch becomes more palatable

Why the urgency? It's not fixing any regressions, is it?
I would rather not add yet another mode for 2.2,
we'll likely have a new mode in 2.3 but I'd like that to
be the last one.

> 2) reviewing patches is always nice, and helps evaluating the advantages
> of either approach
> 
> Paolo

I'll do my best, sorry about the delay - I'm trying to prioritize
2.2 work at the moment.

-- 
MST

Re: [Qemu-devel] [PATCH v2 0/3] Migration-safe ACPI table sizing algorithm

[Paolo Bonzini]

On 20/11/2014 08:55, Michael S. Tsirkin wrote:
> On Thu, Nov 20, 2014 at 08:11:05AM +0100, Paolo Bonzini wrote:
>>
>>
>> On 20/11/2014 07:55, Michael S. Tsirkin wrote:
>>> I thought we agreed we'll consider alternate approaches after 2.2?
>>> I would prefer not to have yet another mode to support
>>> if we can help it.
>>
>> I agree, but:
>>
>> 1) looks like there is stronger opposition to your patch than I thought,
>> so a 2.2 solution as in this patch becomes more palatable
> 
> Why the urgency? It's not fixing any regressions, is it?
> I would rather not add yet another mode for 2.2,
> we'll likely have a new mode in 2.3 but I'd like that to
> be the last one.

I don't think there's a need to add both patches.  If mine goes in, and
it can go in 2.2 since it is "just another mode", there is no need for
resizable MemoryRegions.

Paolo

>> 2) reviewing patches is always nice, and helps evaluating the advantages
>> of either approach
>>
>> Paolo
> 
> I'll do my best, sorry about the delay - I'm trying to prioritize
> 2.2 work at the moment.
> 

Re: [Qemu-devel] [PATCH v2 0/3] Migration-safe ACPI table sizing algorithm

[Michael S. Tsirkin]

On Thu, Nov 20, 2014 at 11:04:13AM +0100, Paolo Bonzini wrote:
> 
> 
> On 20/11/2014 08:55, Michael S. Tsirkin wrote:
> > On Thu, Nov 20, 2014 at 08:11:05AM +0100, Paolo Bonzini wrote:
> >>
> >>
> >> On 20/11/2014 07:55, Michael S. Tsirkin wrote:
> >>> I thought we agreed we'll consider alternate approaches after 2.2?
> >>> I would prefer not to have yet another mode to support
> >>> if we can help it.
> >>
> >> I agree, but:
> >>
> >> 1) looks like there is stronger opposition to your patch than I thought,
> >> so a 2.2 solution as in this patch becomes more palatable
> > 
> > Why the urgency? It's not fixing any regressions, is it?
> > I would rather not add yet another mode for 2.2,
> > we'll likely have a new mode in 2.3 but I'd like that to
> > be the last one.
> 
> I don't think there's a need to add both patches.  If mine goes in, and
> it can go in 2.2 since it is "just another mode",

It's a mode we don't need - adding it does not fix any bugs.

> there is no need for
> resizable MemoryRegions.
> 
> Paolo

There will be need - otherwise each change will keep adding modes.

> >> 2) reviewing patches is always nice, and helps evaluating the advantages
> >> of either approach
> >>
> >> Paolo
> > 
> > I'll do my best, sorry about the delay - I'm trying to prioritize
> > 2.2 work at the moment.
> > 
-- 
MST