* Peter Maydell (peter.mayd...@linaro.org) wrote: > On Thu, 21 Mar 2019 at 15:32, Catherine Ho <catherine.h...@gmail.com> wrote: > > So in igore-shared case, dtb is not required here ? > > Can you explain what the "ignore-shared" case is?
It's a migration capability added recently by Yury Kotov, which as you say below, skips migration of shared ram blocks. The definition of 'shared' is that the RAMBlock rb->flags has RAM_SHARED set, and that normally corresponds to when we call mmap with MAP_SHARED. The user visible version of that is normally if you set up memory with a hostmem backend it has a 'share' property. So 'ignore-shared' corresponds to 'share=on' on the memory backend. > 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. Dave > > Maybe I could add a flag in struct Rom to set it when the rom is created by > > rom_add_blob_fixed_as()? And in rom_reset, just bypass this rom when > > in_incoming_migration && ignore_shared > > No, I think this is wrong -- the particular function used > to create the rom blob data should not affect how we are > treating it. > > thanks > -- PMM -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
