From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] x86/PV: fix unintended dependency of m2p-strict mode on migration-v2 Date: Mon, 1 Feb 2016 16:34:03 +0000 Message-ID: <56AF88FB.4020202@citrix.com> References: <5694DEAA02000078000C5D7A@prv-mh.provo.novell.com> <5694E9BF.8090005@citrix.com> <5695279002000078000C5F80@prv-mh.provo.novell.com> <56966C62.5010201@citrix.com> <56967D1A02000078000C65C3@prv-mh.provo.novell.com> <56967484.1060002@citrix.com> <5696862C02000078000C6667@prv-mh.provo.novell.com> <56AF69B102000078000CCFB0@prv-mh.provo.novell.com> <56AF66B4.4000307@citrix.com> <56AF95D902000078000CD184@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aQHQX-0000dD-6n for xen-devel@lists.xenproject.org; Mon, 01 Feb 2016 16:34:09 +0000 In-Reply-To: <56AF95D902000078000CD184@prv-mh.provo.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: xen-devel , Keir Fraser List-Id: xen-devel@lists.xenproject.org On 01/02/16 16:28, Jan Beulich wrote: >>>> On 01.02.16 at 15:07, wrote: >> On 01/02/16 13:20, Jan Beulich wrote: >>> Ping? (I'd really like to get this resolved, so we don't need to >>> indefinitely run with non-upstream behavior in our distros.) >> My remaining issue is whether this loop gets executed by default. >> >> I realise that there is a difference between legacy and v2 migration, >> and that v2 migration by default worked. If that means we managed to >> skip this loop in its entirety for v2, then I am far less concerned >> about the overhead. > But had been there before: Of course we could skip the loop if > the bit in d->vm_assist doesn't change. But as expressed before, > with you having already indicated that perhaps it would be better > to have v2 migration do the relevant operations in the other (v1) > order, the moment that was actually done the benefit of avoiding > the loop would be gone. > > To be clear - if rendering the code dead (which is what you ask > for) until v2 migration happens to get changed is the only way to > get this code in, I will submit a v2 with that extra conditional. Migration v2 currently loads vcpu context before pinning the pagetables, which means that the vm_assist should get set up properly, before L4 tables are processed. It was my understanding that this is the correct way around, and m2p-strict mode only broke when you backported it to migration v1 systems? ~Andrew