Re: [Qemu-devel] [PATCH v2 0/8] acpi: make ROMs resizeable

["Dr. David Alan Gilbert" <dgilbert@redhat.com>]

* Michael S. Tsirkin (mst@redhat.com) wrote:
> This is v2 of the patchset.
> Changes since v1:
>     - Any RAM can now be resizeable - there's no requirement
>       that it's device RAM any longer.
>     - For simplicity, max_size RAM is always pre-allocated
>     - Added memory_region_set_size, to keep MR size consistent
>       in case MR is guest visible (even though for current users,
>       it never is)
> 
> At the moment we migrate ROMs which reside in fw cfg, which allows
> changing ROM code at will, and supports migrating largish blocks early,
> with good performance.
> However, we are running into a problem: changing size breaks
> migration every time.
> This already requires somewhat messy compatibility support in
> acpi generation code, and it looks like there'll be more to come.
> 
> In particular, recent patchsets by Igor et al. change table sizes in
> unpredictable ways.
> 
> Rather than try to guess the correct size once and for all,
> this patchset tries to make code future-proof, by
> adding support for resizeable ram blocks.
> 
> A (possibly very high) amount of space in ram_addr_t space is reserved
> and allocated in host for each block, but never used by fw cfg.
> If incoming block size differs from current size, block is
> reallocated. FW CFG is also notified and updated accordingly.
> 
> As reviewers felt that making all RAM "resizeable" in this
> way might make debugging migration harder, these patches
> set a per-block flag and only allow resizing for blocks
> where this was explicitly requested.
> 
> Note: migration stream is unaffected by these patches.
> This makes it possible to enable this functionality
> unconditionally, for all machine types.
> 
> In the future, this API might be handy for other things, besides ROMs.

I'm generally happy with this set for what you're using it for,
except that I'd like some big hairy warnings in comments
near the resize functions to make it clear when it's safe
to do it.

What I don't really understand is how it would work for anything mapped
into guest address space, how that mapping would be updated.

Dave

> 
> Michael S. Tsirkin (8):
>   cpu: add cpu_physical_memory_clear_dirty_range_nocode
>   memory: add memory_region_set_size
>   exec: cpu_physical_memory_set/clear_dirty_range
>   exec: split length -> used_length/max_length
>   exec: qemu_ram_alloc_resizeable, qemu_ram_resize
>   arch_init: support resizing on incoming migration
>   memory: API to allocate resizeable RAM MR
>   acpi-build: make ROMs RAM blocks resizeable
> 
>  hw/lm32/lm32_hwsetup.h  |   3 +-
>  include/exec/cpu-all.h  |  12 +++--
>  include/exec/memory.h   |  34 +++++++++++++
>  include/exec/ram_addr.h |  22 +++++++--
>  include/hw/loader.h     |   4 +-
>  arch_init.c             |  28 ++++++-----
>  exec.c                  | 129 +++++++++++++++++++++++++++++++++++++-----------
>  hw/core/loader.c        |  18 +++++--
>  hw/i386/acpi-build.c    |  19 +++++--
>  memory.c                |  33 +++++++++++++
>  10 files changed, 242 insertions(+), 60 deletions(-)
> 
> -- 
> MST
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK