From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH] x86/HVM: honor p2m_ram_ro in hvm_map_guest_frame_rw() Date: Tue, 11 Aug 2015 10:01:51 -0600 Message-ID: <55CA388F0200007800099C0E@prv-mh.provo.novell.com> References: <55B224660200007800095083@prv-mh.provo.novell.com> <55B22964.2030701@citrix.com> <20150727110933.GA54789@deinos.phlegethon.org> <55CA1A190200007800099975@prv-mh.provo.novell.com> <20150811143407.GB884@deinos.phlegethon.org> <55CA32C90200007800099B76@prv-mh.provo.novell.com> <20150811154526.GC884@deinos.phlegethon.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZPBzy-0006kf-Lj for xen-devel@lists.xenproject.org; Tue, 11 Aug 2015 16:01:58 +0000 In-Reply-To: <20150811154526.GC884@deinos.phlegethon.org> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Tim Deegan Cc: Kevin Tian , Wei Liu , suravee.suthikulpanit@amd.com, Andrew Cooper , Eddie Dong , Aravind Gopalakrishnan , Jun Nakajima , xen-devel , Boris Ostrovsky , Keir Fraser List-Id: xen-devel@lists.xenproject.org >>> On 11.08.15 at 17:45, wrote: > At 09:37 -0600 on 11 Aug (1439285833), Jan Beulich wrote: >> >>> On 11.08.15 at 16:34, wrote: >> > At 07:51 -0600 on 11 Aug (1439279513), Jan Beulich wrote: >> >> >>> On 27.07.15 at 13:09, wrote: >> >> > At 13:02 +0100 on 24 Jul (1437742964), Andrew Cooper wrote: >> >> >> On 24/07/15 10:41, Jan Beulich wrote: >> >> >> > Beyond that log-dirty handling in _hvm_map_guest_frame() looks bogus >> >> >> > too: What if a XEN_DOMCTL_SHADOW_OP_* gets issued and acted upon >> >> >> > between the setting of the dirty flag and the actual write happening? >> >> >> > I.e. shouldn't the flag instead be set in hvm_unmap_guest_frame()? >> >> >> >> >> >> It does indeed. (Ideally the dirty bit should probably be held high for >> >> >> the duration that a mapping exists, but that is absolutely infeasible to >> >> >> do). >> >> > >> >> > IMO that would not be very useful -- a well-behaved toolstack will >> >> > have to make sure that relevant mappings are torn down before >> >> > stop-and-copy. Forcing the dirty bit high in the meantime just makes >> >> > every intermediate pass send a wasted copy of the page, without >> >> > actually closing the race window if the tools are buggy. >> >> >> >> Making sure such mappings got torn down in time doesn't help >> >> when the most recent write happened _after_ the most recent >> >> clearing of the dirty flag in a pass prior to stop-and-copy. >> > >> > This is why e.g. __gnttab_unmap_common sets the dirty bit again >> > as it unmaps. >> >> And how does this help when the mapping survives until the guest >> gets suspended? > > Suspended is fine, so long as it happens before the final read of the > bitmap. I don't follow - nothing unmaps the page in that case, so it wouldn't get marked dirty. But I now realize this is the wrong example: The mapping domain wouldn't get a mapped grant saved, and the granting domain has to rely on the mappings of the grants to be properly torn down before the final pass anyway. Whereas here we're talking about mappings held and dirtying done by Xen itself. Jan