Hi all, thanks for the comments, I am digging into another potential error in the ignore-shared live migration. After that, I will send out the v2 asap B.R. Catherine
On Mon, 25 Mar 2019 at 11:39, Peter Xu <pet...@redhat.com> wrote: > > On Fri, Mar 22, 2019 at 10:12:11AM +0000, Dr. David Alan Gilbert wrote: > > [...] > > > > In general, when we reset the system, we want to bring it > > > back to exactly the state that it was in when QEMU was > > > first started. That means we need to reload all the rom blob > > > data into memory (because the guest might have modified > > > that memory while it was running). > > > > > > If I understand correctly from other threads, the idea is > > > that some of the RAM is shared between source and destination > > > so it does not need to be manually copied during migration. > > > If that is correct, then perhaps the right thing is that > > > in the rom_reset code: > > > * if this rom blob is being loaded into a "shared" ram block > > > * and this reset is happening specifically before an > > > inbound migration > > > * then skip loading the rom blob data > > > > > > ? > > > > > > I don't know the right way to determine either the "is this > > > a shared ram area" or "is this the reset prior to inbound > > > migration", but perhaps you can fill that in. > > > > Right, so in Catherine's patch there's a simple in_incoming_migration > > and checking ramblock_is_ignored; it might be better to use the > > qemu_ram_is_shared() call and I wonder if we can just check for being in > > RUN_STATE_INMIGRATE - if that's early enough. > > Yes I feel like runstate_check(RUN_STATE_INMIGRATE) should be enough > to replace the new variable. And I'm even thinking whether we need to > check qemu_ram_is_shared() at all... if rom_reset() simply refills the > ROM data into the RAMs, then IIUC that operation could be skipped for > all incoming migrations because all those ROM data (no matter they are > filled into shared RAM or not) should already have been filled on the > source side and: > > - if the ROM data's RAMBlock is shared backend, the latest data should > already been there on the shared backend files, or, > > - if the ROM data's RAMBlock is not shared backend, they'll eventually > be migrated to the destination later on after this rom_reset() on > destination by the general RAM migration code. > > Regards, > > -- > Peter Xu
