lkml.org 
[lkml]   [2014]   [Oct]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 10/17] mm: rmap preparation for remap_anon_pages
    Il 07/10/2014 19:07, Dr. David Alan Gilbert ha scritto:
    >> >
    >> > 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.



    \
     
     \ /
      Last update: 2014-10-07 19:41    [W:5.586 / U:0.372 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site