On Thu, Dec 18, 2014 at 06:49:09PM +0000, Dr. David Alan Gilbert wrote: > * Michael S. Tsirkin (m...@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.
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 / dgilb...@redhat.com / Manchester, UK
