On Thu, Jan 08, 2015 at 08:28:46AM -0800, Mario Smarduch wrote: > On 01/08/2015 02:45 AM, Christoffer Dall wrote: > > On Wed, Jan 07, 2015 at 05:43:18PM -0800, Mario Smarduch wrote: > >> Hi Christoffer, > >> before going through your comments, I discovered that > >> in 3.18.0-rc2 - a generic __get_user_pages_fast() > >> was implemented, now ARM picks this up. This causes > >> gfn_to_pfn_prot() to return meaningful 'writable' > >> value for a read fault, provided the region is writable. > >> > >> Prior to that the weak version returned 0 and 'writable' > >> had no optimization effect to set pte/pmd - RW on > >> a read fault. > >> > >> As a consequence dirty logging broke in 3.18, I was seeing > Correction on this, proper __get_user_pages_fast() > behavior exposed a bug in page logging code. > > >> weird but very intermittent issues. I just put in the > >> additional few lines to fix it, prevent pte RW (only R) on > >> read faults while logging writable region. > >> > >> On 01/07/2015 04:38 AM, Christoffer Dall wrote: > >>> On Wed, Dec 17, 2014 at 06:07:29PM -0800, Mario Smarduch wrote: > >>>> This patch is a followup to v15 patch series, with following changes: > >>>> - When clearing/dissolving a huge, PMD mark huge page range dirty, since > >>>> the state of whole range is unknown. After the huge page is dissolved > >>>> dirty page logging is at page granularity. > >>> > >>> What is the sequence of events where you could have dirtied another page > >>> within the PMD range after the user initially requested dirty page > >>> logging? > >> > >> No there is none. My issue was the start point for tracking dirty pages > >> and that would be second call to dirty log read. Not first > >> call after initial write protect where any page in range can > >> be assumed dirty. I'll remove this, not sure if there would be any > >> use case to call dirty log only once. > >> > > > > Calling dirty log once can not give you anything meaningful, right? You > > must assume all memory is 'dirty' at this point, no? > > There is the interval between KVM_MEM_LOG_DIRTY_PAGES and first > call to KVM_GET_DIRTY_LOG. Not sure of any use case, maybe enable > logging, wait a while do a dirty log read, disable logging. > Get an accumulated snapshot of dirty page activity. > ok, so from the time the user calls KVM_MEM_LOG_DIRTY_PAGES, then any fault on any huge page will dissolve that huge page into pages, and each dirty page will be logged accordingly for the first call to KVM_GET_DIRTY_LOG, right? What am I missing here? -Christoffer -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
