From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Juergen Gross <JGross@suse.com>, Wei Liu <wei.liu2@citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com>, Tim Deegan <tim@xen.org>,
Ian Jackson <Ian.Jackson@eu.citrix.com>,
Xen-devel List <xen-devel@lists.xen.org>,
David Vrabel <david.vrabel@citrix.com>,
Shriram Rajagopalan <rshriram@cs.ubc.ca>,
Hongyang Yang <yanghy@cn.fujitsu.com>
Subject: Re: Buggy interaction of live migration and p2m updates
Date: Fri, 21 Nov 2014 10:54:55 +0000 [thread overview]
Message-ID: <546F19FF.5070706@citrix.com> (raw)
In-Reply-To: <546F25700200007800049AB4@smtp.nue.novell.com>
On 21/11/14 10:43, Jan Beulich wrote:
>>>> On 20.11.14 at 19:28, <andrew.cooper3@citrix.com> wrote:
>> Should the guest change the p2m structure during live migration, the
>> toolstack ends up with a stale p2m with a non-p2m frame in the middle,
>> resulting in bogus cross-referencing. Should the guest change an entry
>> in the p2m, the p2m frame itself will be resent as it would be marked as
>> dirty in the logdirty bitmap, but the target pfn will remain unsent and
>> probably stale on the receiving side.
> MMU_MACHPHYS_UPDATE processing marks the page being changed
> as dirty. Perhaps guest_physmap_{add,remove}_page() (or certain
> callers thereof) should do so too?
>
> Jan
>
This is certainly needed to fix HVM ballooning and live migration
issues, although now you point it out, it applies just as much to PV
guests as HVM guests.
I believe this might allow the toolstack to avoid keeping a second copy
of the p2m.
~Andrew
next prev parent reply other threads:[~2014-11-21 10:54 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-20 18:28 Buggy interaction of live migration and p2m updates Andrew Cooper
2014-11-21 5:41 ` Juergen Gross
2014-11-21 10:32 ` Andrew Cooper
2014-11-27 15:14 ` Tim Deegan
2014-11-21 9:43 ` Ian Campbell
2014-11-21 10:24 ` Andrew Cooper
2014-11-21 10:46 ` Ian Campbell
2014-11-21 11:07 ` Andrew Cooper
2014-11-21 11:15 ` Ian Campbell
2014-11-21 11:20 ` Juergen Gross
2014-11-21 11:24 ` Ian Campbell
2014-11-21 12:15 ` Jan Beulich
2014-11-21 12:20 ` Jürgen Groß
2014-11-21 10:43 ` Jan Beulich
2014-11-21 10:54 ` Andrew Cooper [this message]
2014-11-27 15:00 ` Tim Deegan
2014-11-27 15:16 ` Andrew Cooper
2014-11-27 15:28 ` Tim Deegan
2014-11-27 15:41 ` Andrew Cooper
2014-12-01 14:38 ` David Vrabel
2014-12-01 16:58 ` Andrew Cooper
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=546F19FF.5070706@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=JBeulich@suse.com \
--cc=JGross@suse.com \
--cc=david.vrabel@citrix.com \
--cc=rshriram@cs.ubc.ca \
--cc=tim@xen.org \
--cc=wei.liu2@citrix.com \
--cc=xen-devel@lists.xen.org \
--cc=yanghy@cn.fujitsu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.