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. Frankly I don't solidly know the details on why they can't be different. 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. 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. > > 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. > 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, -- Peter Xu
