From: Peter Xu <peterx@redhat.com>
To: Alexey <a.perevalov@samsung.com>
Cc: i.maximets@samsung.com, qemu-devel@nongnu.org,
dgilbert@redhat.com, quintela@redhat.com
Subject: Re: [Qemu-devel] [PATCH v5 3/3] migration: add bitmap for received page
Date: Wed, 28 Jun 2017 15:34:21 +0800 [thread overview]
Message-ID: <20170628073421.GJ14652@pxdev.xzpeter.org> (raw)
In-Reply-To: <20170627104057.GB4827@aperevalov-ubuntu>
On Tue, Jun 27, 2017 at 01:40:58PM +0300, Alexey wrote:
> On Tue, Jun 27, 2017 at 06:17:40PM +0800, Peter Xu wrote:
> > On Tue, Jun 27, 2017 at 05:50:27AM -0400, Alexey Perevalov wrote:
> >
> > [...]
> >
> > > @@ -60,6 +62,14 @@ static inline void *ramblock_ptr(RAMBlock *block, ram_addr_t offset)
> > > return (char *)block->host + offset;
> > > }
> > >
> > > +static inline unsigned long int ramblock_recv_bitmap_offset(void *host_addr,
> > > + RAMBlock *rb)
> > > +{
> > > + uint64_t host_addr_offset =
> > > + (uint64_t)(uintptr_t)(host_addr - (void *)rb->host);
> > > + return host_addr_offset >> TARGET_PAGE_BITS;
> > > +}
> > > +
> > > long qemu_getrampagesize(void);
> > > unsigned long last_ram_page(void);
> > > RAMBlock *qemu_ram_alloc_from_file(ram_addr_t size, MemoryRegion *mr,
> > > diff --git a/migration/migration.c b/migration/migration.c
> > > index 71e38bc..53fbd41 100644
> > > --- a/migration/migration.c
> > > +++ b/migration/migration.c
> > > @@ -143,6 +143,7 @@ MigrationIncomingState *migration_incoming_get_current(void)
> > > qemu_mutex_init(&mis_current.rp_mutex);
> > > qemu_event_init(&mis_current.main_thread_load_event, false);
> > > once = true;
> > > + ramblock_recv_map_init();
> >
> > One tiny more comment: shall we init this at the beginning of incoming
> > migration? Maybe into migration_fd_process_incoming(), before entering
> > the coroutine?
> maybe this function (migration_incoming_get_current) is not best place
> to initialize something in ramblock list from point of
> view maintainability.
Yes, the point is, it is only inited once per QEMU instance, while
actually it should be inited for each incoming migration procedure
(though I think yes we will normally have one incoming migration per
QEMU instance...).
> >
> > Then, for the destruction of it below...
> >
> > [...]
> >
> > > @@ -2324,8 +2352,14 @@ static int ram_load_setup(QEMUFile *f, void *opaque)
> > >
> > > static int ram_load_cleanup(void *opaque)
> > > {
> > > + RAMBlock *rb;
> > > xbzrle_load_cleanup();
> > > compress_threads_load_cleanup();
> > > +
> > > + RAMBLOCK_FOREACH(rb) {
> > > + g_free(rb->receivedmap);
> > > + rb->receivedmap = NULL;
> > > + }
> >
> > ... maybe move to migration_incoming_state_destroy()?
> I'll think about it, because ram_load_cleanup in current Juan's
> patch set is not calling in postcopy scenario.
Sure.
>
> >
> > And, I didn't really find ram_load_cleanup() in my repo. Am I missing
> > something?
> you need Juan's [PATCH v2 0/5] Create setup/cleanup methods for
> migration incoming side
Ok. Then no problem. Thanks,
>
> >
> > Other than above, this patch looks good to me. Thanks,
> >
> > --
> > Peter Xu
> >
>
> --
>
> BR
> Alexey
--
Peter Xu
next prev parent reply other threads:[~2017-06-28 7:34 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20170627095331eucas1p12a729c667ed1b48fd6d7806c384880eb@eucas1p1.samsung.com>
2017-06-27 9:50 ` [Qemu-devel] [PATCH v5 0/3] Add bitmap for received pages in postcopy migration Alexey Perevalov
[not found] ` <CGME20170627095332eucas1p2e787fcca6adceddf87f7dc50fe82183d@eucas1p2.samsung.com>
2017-06-27 9:50 ` [Qemu-devel] [PATCH v5 1/3] migration: postcopy_place_page factoring out Alexey Perevalov
[not found] ` <CGME20170627095332eucas1p1d005cb2b05068fc8c48f46eb48292430@eucas1p1.samsung.com>
2017-06-27 9:50 ` [Qemu-devel] [PATCH v5 2/3] migration: introduce qemu_ufd_copy_ioctl helper Alexey Perevalov
[not found] ` <CGME20170627095333eucas1p28a2d86104f8df64c05758cd08f1a48df@eucas1p2.samsung.com>
2017-06-27 9:50 ` [Qemu-devel] [PATCH v5 3/3] migration: add bitmap for received page Alexey Perevalov
2017-06-27 10:17 ` Peter Xu
2017-06-27 10:40 ` Alexey
2017-06-28 7:34 ` Peter Xu [this message]
2017-06-27 10:53 ` Juan Quintela
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170628073421.GJ14652@pxdev.xzpeter.org \
--to=peterx@redhat.com \
--cc=a.perevalov@samsung.com \
--cc=dgilbert@redhat.com \
--cc=i.maximets@samsung.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).