On 8/13/2024 2:45 PM, Peter Xu wrote:
On Tue, Aug 13, 2024 at 11:00:37AM -0600, Alex Williamson wrote:
Note that the old-QEMU contents of all ramblocks must be preserved, just like
in live migration. Live migration copies the contents in the stream. Live
update
preserves the contents in place by preserving the memfd. Thus memfd serves
two purposes: preserving old contents, and preserving DMA mapped pinned pages.
IMHO the 1st purpose is a fake one. IOW:
- Preserving content will be important on large RAM/ROM regions. When
it's small, it shouldn't matter a huge deal, IMHO, because this is
about "how fast we can migrate / live upgrade'. IOW, this is not a
functional requirement.
Regardless of the size of a ROM region, how would it ever be faster to
migrate ROMs rather that reload them from stable media on the target?
Furthermore, what mechanism other than migrating the ROM do we have to
guarantee the contents of the ROM are identical?
IIRC we need to migrate ROMs in some form because they can be different on
src/dst, e.g., ROM files can upgrade after QEMU upgrades. Here either
putting them onto migration stream, or making that fd-based should work.
Agreed.
Frankly I don't solidly know the details on why they can't be different.
Any ramblock may change if the contents are read from a file in
the QEMU distribution, or if the contents are composed by QEMU code.
My current understanding was that if one device boots with one version of
ROM/firmware, then it's possible the device keep interacting with the ROM
region in some way (in the form of referring addresses in this specific
version of ROM?), so that it may stop working if the ROM content changed.
Yes, the guest may continue to read data or execute code from the block.
IOW, if my understanding is correct, new ROM files won't get used after
migration automatically, but it requires one system reset. When a system
reset triggered after VM migrated to destination host, it'll reload device
ROMs with the files specified (which will start to point to the upgraded
version of ROM files), and IIUC that's where the devices will boostrap with
the new ROM / BIOS files.
Agreed.
I have a hard time accepting that ROMs are only migrated for
performance
AFAICT, it's never about performance or making it faster when putting ROM
data on wire. Even in this context where Steve wanted to use fd backing
the ROMs, then putting that on wire is still slower than sharing fds.
Here my previous comment / point was that this should be a small region, so
it shouldn't matter a huge deal for ROMs to migrate either through the wire
or via the fd page cache. I wanted to remove one more dependency that we
may even need the new -alloc-anon parameter as it doesn't sound required
for ROM migrations.
Agreed that performance is not the issue. I use memfd for correctness.
Also note that my new proposal deletes the alloc-anon parameter. I allocate
non-command-line ramblocks unconditionally using memfd_create.
- Steve
and there isn't some aspect of migrating them to ensure the
contents remain identical, and by that token CPR would also need to
preserve the contents to provide the same guarantee. Thanks,
Thanks,
