From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Live migration with MMIO pages Date: Fri, 02 Nov 2007 10:42:07 +0000 Message-ID: References: <1193995893.4327.55.camel@moonstone.uk.level5networks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1193995893.4327.55.camel@moonstone.uk.level5networks.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Kieran Mansley , Tim Deegan Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 2/11/07 09:31, "Kieran Mansley" wrote: >> You could do that. I think the correct test is shadow_mode_refcounts(); >> as Keir pointed out, guests whose refcounting isn't done by the shadow >> code will have had their pagetables validated bby the PV MMU interface. >> >> The test around the log-dirty code can just be on mfn_valid(). > > Attached is a new patch with those changes. Seems much more sensible to > me that way too, and it works just as well. I changed the final chunk test from !shadow_mode_translate() to shadow_mode_refcounts(). I think refcounts is a better test than translate here, and also I think your test was the wrong way round! I also note that guarding the mark-dirty-or-zap-writable-bit with mfn_valid() is not really correct. mfn_valid() only checks whether the mfn < max_page. I bet this would not work if you migrate on a machine with 4GB of RAM, as the MMIO hole will be below max_page. Really mfn_valid needs to handle such MMIO holes, or the shadow code needs to be using a test other than mfn_valid in many places (e.g., the function iomem_page_test() that you added before). -- Keir