From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hongyang Yang Subject: Re: [RFC PATCH 3/3] remus: adjust x86 pv restore to support remus Date: Thu, 10 Jul 2014 17:32:54 +0800 Message-ID: <53BE5DC6.5040906@cn.fujitsu.com> References: <1404892050-24650-1-git-send-email-yanghy@cn.fujitsu.com> <1404892050-24650-4-git-send-email-yanghy@cn.fujitsu.com> <53BD2477.1070505@citrix.com> <53BD26E0.9030406@citrix.com> <53BE08BD.3060308@cn.fujitsu.com> <53BE5C1A.8060800@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <53BE5C1A.8060800@citrix.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: Andrew Cooper , xen-devel@lists.xen.org Cc: rshriram@cs.ubc.ca, Ian.Jackson@eu.citrix.com, Ian.Campbell@citrix.com List-Id: xen-devel@lists.xenproject.org On 07/10/2014 05:25 PM, Andrew Cooper wrote: > On 10/07/14 04:30, Hongyang Yang wrote: >> >> >> On 07/09/2014 07:26 PM, Andrew Cooper wrote: >>> On 09/07/14 12:16, Andrew Cooper wrote: >>>> On 09/07/14 08:47, Yang Hongyang wrote: >>>>> cache vcpu context when restore, and set context when stream >>>>> complete. >>>> Can you explain why this is needed? I can't see why it should be >>>> required. >>> >>> Actually, as part of reviewing this I have worked out why this is >>> needed. >>> >>> It is a latent bug in the migration v2 series with all the x86 pv vcpu >>> state (not just the basic state), which is not triggered by a well >>> behaved sender. >>> >>> I shall fix it up in the base series. >> >> That's great, remember the bug I talked to you on IRC last time? This >> patch was targeted to avoid the bug, but I don't know why this bug >> happened, which I can tell is that if we don't cache the state, >> we will get mapping error when restore the CPU state next time, >> can you explain it in detail? Thanks in advance. > > Once you have loaded cr3 (and cr1 for 64bit guests) once, the pages > containing pagetable data turn into real pagetables, after which the > restorer can no longer map them RW and update their contents. That's the point, thank you for the explanation! I was wondering how you will fix it up? defer the load of the cr3 by cacheing the cpu state or something else? maybe pin/unpin pagetables will also help? > > ~Andrew > . > -- Thanks, Yang.