Messages in this thread | | | Date | Wed, 24 Sep 2008 15:31:56 +0300 | From | Avi Kivity <> | Subject | Re: Populating multiple ptes at fault time |
| |
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
| |