Re: [Qemu-devel] [PATCH] migration: avoid copying ignore-shared ramblock when in incoming migration

[Peter Maydell]

On Thu, 21 Mar 2019 at 06:20, Peter Xu <address@hidden> wrote:
> I tried to dig on how x86 implemented the "-kernel" parameter and I
> noticed that it's dumping the kernel image into fw_cfg and probably
> that's also the reason why this should not be a problem for x86
> because rom reset on x86 won't overwrite the image.  Meanwhile, it
> seems totally different comparing to what has been done by ARM, which
> should probably be using rom_add_elf_program() to load the image if my
> reading is correct, so the kernel image is a ROM on ARM even if it can
> be written... Is my understanding correct?

The "usual" case for x86 passes the kernel through the fw_cfg
device, whereas the "usual" case for arm has rom-blobs that are
written directly to the backing RAMBlock for the flash device
or for real RAM. But it's possible also to have x86 configurations
and command lines which write to the real RAM. For instance if
you use the 'generic loader' device (documented in
docs/generic-loader.txt) to load auxiliary data files into RAM
on x86 you will hit the same problem.

> With that, I still feel that hacking into the memory write functions
> are tricky and I feel like it could bring hard to debug issues.  Would
> it be possible that we identify somehow that this ROM is a fake one
> (since it can actually be written) and we ignore the reset of it when
> proper (e.g., the initial reset on destination)?

I don't know what you mean by 'fake ROM' and anyway
this all applies to RAM as well...

thanks
-- PMM