From: Andrea Arcangeli <aarcange@redhat.com>
To: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>,
qemu-devel@nongnu.org, quintela@redhat.com, lvivier@redhat.com,
peterx@redhat.com
Subject: Re: [Qemu-devel] [PATCH 1/2] Postcopy: Force allocation of all-zero precopy pages
Date: Wed, 26 Apr 2017 21:37:43 +0200 [thread overview]
Message-ID: <20170426193743.GF3508@redhat.com> (raw)
In-Reply-To: <20170426190442.GG2394@work-vm>
Hello,
On Wed, Apr 26, 2017 at 08:04:43PM +0100, Dr. David Alan Gilbert wrote:
> * Christian Borntraeger (borntraeger@de.ibm.com) wrote:
> > On 04/26/2017 08:37 PM, Dr. David Alan Gilbert (git) wrote:
> > > From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> > >
> > > When an all-zero page is received during the precopy
> > > phase of a postcopy-enabled migration we must force
> > > allocation otherwise accesses to the page will still
> > > get blocked by userfault.
> > >
> > > Symptom:
> > > a) If the page is accessed by a device during device-load
> > > then we get a deadlock as the source finishes sending
> > > all its pages but the destination device-load is still
> > > paused and so doesn't clean up.
> > >
> > > b) If the page is accessed later, then the thread will stay
> > > paused until the end of migration rather than carrying on
> > > running, until we release userfault at the end.
> > >
> > > Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
> > > Reported-by: Christian Borntraeger <borntraeger@de.ibm.com>
> >
> > CC stable? after all the guest hangs on both sides
> >
> > Has survived 40 migrations (usually failed at the 2nd)
> > Tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
>
> Great...but.....
> Andrea (added to the mail) says this shouldn't be necessary.
> The read we were doing in the is_zero_range() should have been sufficient
> to get the page mapped and that zero page should have survived.
>
> So - I guess that's back a step, we need to figure out why the
> page disapepars for you.
Yes reading during precopy is enough to fill the hole and prevent
userfault missing faults to trigger.
Somehow the pagetable must be mapped by a zeropage or a hugezeropage
or a regular page allocated during a previous precopy pass or a
pre-zeroed subpage part of a THP.
Even if the hugezeropage is splitted later by a MADV_DONTNEED with
postcopy starts, they will become 4k zeropages.
After a read succeeds, nothing (except MADV_DONTNEED or other explicit
syscalls which qemu would need to invoke explicitly between
is_zero_range and UFFDIO_REGISTER) should be able to bring the
pagetable back to its "pte_none/pmd_none" state that will then trigger
missing userfaults during postcopy later.
Thanks,
Andrea
next prev parent reply other threads:[~2017-04-26 19:37 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-26 18:37 [Qemu-devel] [PATCH 0/2] Postcopy fix and traces Dr. David Alan Gilbert (git)
2017-04-26 18:37 ` [Qemu-devel] [PATCH 1/2] Postcopy: Force allocation of all-zero precopy pages Dr. David Alan Gilbert (git)
2017-04-26 19:00 ` Christian Borntraeger
2017-04-26 19:04 ` Dr. David Alan Gilbert
2017-04-26 19:37 ` Andrea Arcangeli [this message]
2017-04-27 3:20 ` Peter Xu
2017-04-27 6:44 ` Christian Borntraeger
2017-04-27 13:47 ` Andrea Arcangeli
2017-04-28 13:19 ` Christian Borntraeger
2017-04-28 14:24 ` Dr. David Alan Gilbert
2017-04-26 19:52 ` Christian Borntraeger
2017-04-26 19:54 ` Christian Borntraeger
2017-04-26 19:35 ` Juan Quintela
2017-04-27 8:03 ` Dr. David Alan Gilbert
2017-04-26 18:37 ` [Qemu-devel] [PATCH 2/2] migration: Extra tracing Dr. David Alan Gilbert (git)
2017-04-26 18:48 ` Christian Borntraeger
2017-05-02 13:17 ` Philippe Mathieu-Daudé
2017-05-04 8:40 ` 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=20170426193743.GF3508@redhat.com \
--to=aarcange@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=dgilbert@redhat.com \
--cc=lvivier@redhat.com \
--cc=peterx@redhat.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).