Andrea Arcangeli wrote:
On Tue, Apr 14, 2009 at 03:09:25PM -0700, Andrew Morton wrote:
On Thu, 9 Apr 2009 06:58:40 +0300
Izik Eidus <ieidus@xxxxxxxxxx> wrote:
replace_page() allow changing the mapping of pte from one physical page
into diffrent physical page.
At a high level, this is very similar to what page migration does. Yet
this implementation shares nothing with the page migration code.
Can this situation be improved?
This was discussed last time too. Basically the thing is that using
migration entry with its special page fault paths, for this looks a
bit of an overkill complexity and unnecessary dependency on the
migration code.
I agree about that.
All we need is to mark the pte readonly. replace_page
is a no brainer then. The brainer part is page_wrprotect
(page_wrprotect is like fork).
The data visibility in the final memcmp you mentioned in the other
mail is supposedly taken care of by page_wrprotect too. It already
does flush_cache_page for the virtual indexed and not physically
tagged caches. page_wrprotect has to also IPI all CPUs to nuke any not
wrprotected tlb entry. I don't think we need further smp memory
barriers when we're guaranteed all tlb entries are wrprotected in the
other cpus and an IPI and invlpg run in them, to be sure we read the
data stable during memcmp even if we read through the kernel
pagetables and the last userland write happened through userland ptes
before they become effective wrprotected by the IPI.
Yup agree.
--
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
