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

[Michael S. Tsirkin]

On Thu, Dec 18, 2014 at 06:49:09PM +0000, Dr. David Alan Gilbert wrote:
> * Michael S. Tsirkin (address@hidden) 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.

Really always: whenever resize callback updates all
guest visible state.

> 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

That would be a job of the resize function: it can update kvm.

> > 
> > 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 / address@hidden / Manchester, UK