On (Mon) 17 Nov 2014 [22:08:46], Michael S. Tsirkin wrote:
> 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.
>
> 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
> for each block, but never allocated.
> If incoming block size differs from current size, block is
> reallocated. FW CFG is also notified and updated accordingly.
>
> To simplify things, I didn't add support for resizing
> actual RAM: device RAM such as fw cfg ROMs are never mapped
> into guests directly, so instead I added an API to
> flag device RAM explicitly, and manage them using
> simple alloc/free/realloc
>
> Considering this promises to rid us of worries about ROM size considerations
> once and for all, I thinking about pushing this as a "kind of bugfix" before
> 2.2, so we don't need to maintain more band-aids in 2.3 and on.
I'd rather wait for 2.3; we've done this for a couple of releases
already, so what's one more. And we're at rc2 already..
> 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 might be handy for other things,
> such as changing kernels loaded on command line
> across migrations.
I think that'll be too risky; unless we do S4 before / after
migration to ensure the kernel realises things might be changing
beneath its feet.
Amit
