Thread (47 messages) flat view 47 messages, 9 authors, 2014-11-06

Re: [PATCH 10/17] mm: rmap preparation for remap_anon_pages

From: Paolo Bonzini <pbonzini@redhat.com>
Date: 2014-10-07 17:15:48
Also in: kvm, linux-mm, lkml, qemu-devel

Il 07/10/2014 19:07, Dr. David Alan Gilbert ha scritto:
quoted
quoted
So I'd *much* rather have a "write()" style interface (ie _copying_
bytes from user space into a newly allocated page that gets mapped)
than a "remap page" style interface
Something like that might work for the postcopy case; it doesn't work
for some of the other uses that need to stop a page being changed by the
guest, but then need to somehow get a copy of that page internally to QEMU,
and perhaps provide it back later.
I cannot parse this.  Which uses do you have in mind?  Is it for
QEMU-specific or is it for other applications of userfaults?

As long as the page is atomically mapped, I'm not sure what the
difference from remap_anon_pages are (as far as the destination page is
concerned).  Are you thinking of having userfaults enabled on the source
as well?

Paolo
remap_anon_pages worked for those cases
as well; I can't think of another current way of doing it in userspace.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help