From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: Buggy interaction of live migration and p2m updates Date: Fri, 21 Nov 2014 10:54:55 +0000 Message-ID: <546F19FF.5070706@citrix.com> References: <546E32BB.8090909@citrix.com> <546F25700200007800049AB4@smtp.nue.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <546F25700200007800049AB4@smtp.nue.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Juergen Gross , Wei Liu , Ian Campbell , Tim Deegan , Ian Jackson , Xen-devel List , David Vrabel , Shriram Rajagopalan , Hongyang Yang List-Id: xen-devel@lists.xenproject.org On 21/11/14 10:43, Jan Beulich wrote: >>>> On 20.11.14 at 19:28, 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