[RESEND PATCH v15 07/11] KVM: arm: page logging 2nd stage fault handling

[Christoffer Dall]

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