Re: Populating multiple ptes at fault time

[Avi Kivity <avi@redhat.com>]

Jeremy Fitzhardinge wrote:
> Avi Kivity wrote:
>   
>>> The only direct use of pte_young() is in zap_pte_range, within a
>>> mmu_lazy region.  So syncing the A bit state on entering lazy mmu mode
>>> would work fine there.
>>>
>>>   
>>>       
>> Ugh, leaving lazy pte.a mode when entering lazy mmu mode?
>>     
>
> Well, sort of but not quite.  The kernel's announcing its about to start
> processing a batch of ptes, so the hypervisor can take the opportunity
> to update their state before processing.  "Lazy-mode" is from the
> perspective of the kernel lazily updating some state the hypervisor
> might care about, and the sync happens when leaving mode.
>
> The flip-side is when the hypervisor is lazily updating some state the
> kernel cares about, so it makes sense that the sync when the kernel
> enters its lazy mode.  But the analogy isn't very good because we don't
> really have an explicit notion of "hypervisor lazy mode", or a formal
> handoff of shared state between the kernel and hypervisor.  But in this
> case the behaviour isn't too bad.
>
>   

Handwavy.  I think the two notions are separate <insert handwavy 
counter-arguments>.

>>> The call via page_referenced_one() doesn't seem to have a very
>>> convenient hook though.  Perhaps putting something in
>>> page_check_address() would do the job.
>>>
>>>   
>>>       
>> Why there?
>>
>> Why not explicitly in the callers?  We need more than to exit lazy
>> pte.a mode, we also need to enter it again later.
>>
>>     
>
> Because that's the code that actually walks the pagetable and has the
> address of the pte; it just returns a pte_t, not a pte_t *.  It depends
> on whether you want fetch the A bit via ptep or vaddr (in general we
> pass mm, ptep and vaddr to ops which operate on the current pagetable).
>   

pte_clear_flush_young_notify_etc() seems even closer.

-- 
error compiling committee.c: too many arguments to function