qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Xu
Subject: Re: [Qemu-devel] [PATCH] migration: avoid copying ignore-shared ramblock when in incoming migration
Date: Mon, 25 Mar 2019 11:39:48 +0800
User-agent: Mutt/1.10.1 (2018-07-13)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]