From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kai Huang Subject: Re: PML (Page Modification Logging) design for Xen Date: Fri, 13 Feb 2015 10:15:25 +0800 Message-ID: <54DD5E3D.2040509@linux.intel.com> References: <54DB129D.3060102@linux.intel.com> <54DB4294.1080406@citrix.com> <54DB6392020000780005F08B@mail.emea.novell.com> <54DC1171.1030000@linux.intel.com> <54DC4C1A.6010404@linux.intel.com> <20150212124213.GB82524@deinos.phlegethon.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20150212124213.GB82524@deinos.phlegethon.org> 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 , "Tian, Kevin" Cc: Andrew Cooper , "keir@xen.org" , Jan Beulich , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 02/12/2015 08:42 PM, Tim Deegan wrote: > At 07:08 +0000 on 12 Feb (1423721283), Tian, Kevin wrote: >> for general log dirty, ept_invalidate_emt is required because there is >> access permission change (dirtied page becomes rw after 1st fault, >> so need to change them back to ro again for the new dirty tracking >> round). But for PML, there's no permission change at all (always rw), >> so such behavior should be noted by general logdirty layer for better >> optimization. > AIUI the reason for calling ept_invalidate_emt() is to avoid having to > update a large number of EPTEs at once. If you still need to update a > large number of EPTEs (to clear the Dirty bits), that has to me > preemptable, or else use ept_invalidate_emt(). > > Or have I misunderstood? I think you are correct. We still need to use ept_invalidate_emt for clearing D-bit, unless we invent a new paging layer interface, say paging_enable_log_dirty_gfn, which explicitly enables log-dirty for single GFN, either by write protection, or clearing D-bit, in case of PML. Thanks, -Kai > > Tim.