search for: userfaultfd

Hi, this is an idea that is based on Andrea Arcangeli's original idea to host enforce guest access to memory given up using virtio-balloon using userfaultfd in the hypervisor. While looking into the details, I realized that host-enforcing virtio-balloon would result in way too many problems (mainly backwards compatibility) and would also have some conceptual restrictions that I want to avoid. So I developed the idea of virtio-mem - "paravirtualize...

Hi, this is an idea that is based on Andrea Arcangeli's original idea to host enforce guest access to memory given up using virtio-balloon using userfaultfd in the hypervisor. While looking into the details, I realized that host-enforcing virtio-balloon would result in way too many problems (mainly backwards compatibility) and would also have some conceptual restrictions that I want to avoid. So I developed the idea of virtio-mem - "paravirtualize...

...ople that just thought about something like this in the concept of fake DAX. On 16.06.2017 16:20, David Hildenbrand wrote: > Hi, > > this is an idea that is based on Andrea Arcangeli's original idea to > host enforce guest access to memory given up using virtio-balloon using > userfaultfd in the hypervisor. While looking into the details, I > realized that host-enforcing virtio-balloon would result in way too many > problems (mainly backwards compatibility) and would also have some > conceptual restrictions that I want to avoid. So I developed the idea of > virtio-mem -...

> On 12/08/2016 08:45 PM, Li, Liang Z wrote: > > What's the conclusion of your discussion? It seems you want some > > statistic before deciding whether to ripping the bitmap from the ABI, > > am I right? > > I think Andrea and David feel pretty strongly that we should remove the > bitmap, unless we have some data to support keeping it. I don't feel as >

> On 12/08/2016 08:45 PM, Li, Liang Z wrote: > > What's the conclusion of your discussion? It seems you want some > > statistic before deciding whether to ripping the bitmap from the ABI, > > am I right? > > I think Andrea and David feel pretty strongly that we should remove the > bitmap, unless we have some data to support keeping it. I don't feel as >

...of the guest (not without major changes that maps a hugetlb page with 4k ptes at least). While for a more cooperative usage of hugetlbfs guests, it's simply not useful to inflate the balloon at anything less than the "HPAGE_SIZE" hugetlbfs granularity. We also plan to use userfaultfd to make the balloon driver host enforced (will work fine on hugetlbfs 2M and tmpfs too) but that's going to be invisible to the ABI so it's not strictly relevant for this discussion. On a side note, registering userfaultfd on the ballooned range, will keep khugepaged at bay so it won't...

...and shows how it is being used. It contains > further information. Also have a look at the description of patch nr 4 in > this series. > > This work is the result of the initital idea of Andrea Arcangeli to host > enforce guest access to memory inflated in virtio-balloon using > userfaultfd, which turned out to be problematic to implement. That's how > I came up with virtio-mem. > > -------------------------------------------------------------------------- > 1. High level concept > -------------------------------------------------------------------------- > &gt...

...uest_offset_cached schedules and locks up the host. kvm->srcu (or kvm->slots_lock) is also not taken and kvm_write_guest_offset_cached needs to call kvm_memslots which requires it. This I think is why postcopy live migration locks up with current upstream, and it doesn't seem related to userfaultfd at all (initially I suspected the vmf conversion but it wasn't that) and in theory it can happen with heavy swapping or page migration too. Just the page is written so frequently it's unlikely to be swapped out. The page being written so frequently also means it's very likely found as...

...uest_offset_cached schedules and locks up the host. kvm->srcu (or kvm->slots_lock) is also not taken and kvm_write_guest_offset_cached needs to call kvm_memslots which requires it. This I think is why postcopy live migration locks up with current upstream, and it doesn't seem related to userfaultfd at all (initially I suspected the vmf conversion but it wasn't that) and in theory it can happen with heavy swapping or page migration too. Just the page is written so frequently it's unlikely to be swapped out. The page being written so frequently also means it's very likely found as...

On Fri, Jun 16, 2017 at 04:20:02PM +0200, David Hildenbrand wrote: > Hi, > > this is an idea that is based on Andrea Arcangeli's original idea to > host enforce guest access to memory given up using virtio-balloon using > userfaultfd in the hypervisor. While looking into the details, I > realized that host-enforcing virtio-balloon would result in way too many > problems (mainly backwards compatibility) and would also have some > conceptual restrictions that I want to avoid. So I developed the idea of > virtio-mem -...

...17:04, Michael S. Tsirkin wrote: > On Fri, Jun 16, 2017 at 04:20:02PM +0200, David Hildenbrand wrote: >> Hi, >> >> this is an idea that is based on Andrea Arcangeli's original idea to >> host enforce guest access to memory given up using virtio-balloon using >> userfaultfd in the hypervisor. While looking into the details, I >> realized that host-enforcing virtio-balloon would result in way too many >> problems (mainly backwards compatibility) and would also have some >> conceptual restrictions that I want to avoid. So I developed the idea of >&g...

...17:04, Michael S. Tsirkin wrote: > On Fri, Jun 16, 2017 at 04:20:02PM +0200, David Hildenbrand wrote: >> Hi, >> >> this is an idea that is based on Andrea Arcangeli's original idea to >> host enforce guest access to memory given up using virtio-balloon using >> userfaultfd in the hypervisor. While looking into the details, I >> realized that host-enforcing virtio-balloon would result in way too many >> problems (mainly backwards compatibility) and would also have some >> conceptual restrictions that I want to avoid. So I developed the idea of >&g...

...te: > > On Fri, Jun 16, 2017 at 04:20:02PM +0200, David Hildenbrand wrote: > >> Hi, > >> > >> this is an idea that is based on Andrea Arcangeli's original idea to > >> host enforce guest access to memory given up using virtio-balloon using > >> userfaultfd in the hypervisor. While looking into the details, I > >> realized that host-enforcing virtio-balloon would result in way too many > >> problems (mainly backwards compatibility) and would also have some > >> conceptual restrictions that I want to avoid. So I developed the...

...ock) is also not taken and > kvm_write_guest_offset_cached needs to call kvm_memslots which > requires it. > let me check the details later. thanks for pointing it out. > This I think is why postcopy live migration locks up with current > upstream, and it doesn't seem related to userfaultfd at all (initially > I suspected the vmf conversion but it wasn't that) and in theory it > can happen with heavy swapping or page migration too. > > Just the page is written so frequently it's unlikely to be swapped > out. The page being written so frequently also means it'...

...count, gup_flags, > + pages, NULL, NULL); get_user_pages_remote() can wait for disk I/O (for swapping stuff back in), which we'd probably like to avoid here. And I think it can also wait for userfaultfd handling from userspace? zap_page_range() (which is what e.g. MADV_DONTNEED uses) might be a better fit, since it can yank entries out of the page table (forcing the next write fault to allocate a new zeroed page) without faulting them into RAM. > + if (count <=...

A migrating transparent huge page has to already be unmapped. Otherwise, the page could be modified while it is being copied to a new page and data could be lost. The function __split_huge_pmd() checks for a PMD migration entry before calling __split_huge_pmd_locked() leading one to think that __split_huge_pmd_locked() can handle splitting a migrating PMD. However, the code always increments the

...e_private_entry(page, + vma->vm_flags & VM_WRITE)); + } else { + entry = mk_huge_pmd(page, vma->vm_page_prot); + entry = maybe_pmd_mkwrite(pmd_mkdirty(entry), vma); + } + + ptl = pmd_lock(mm, pmdp); + + if (check_stable_address_space(mm)) + goto unlock_abort; + + /* + * Check for userfaultfd but do not deliver the fault. Instead, + * just back off. + */ + if (userfaultfd_missing(vma)) + goto unlock_abort; + + if (pmd_present(*pmdp)) { + if (!is_huge_zero_pmd(*pmdp)) + goto unlock_abort; + flush = true; + } else if (!pmd_none(*pmdp)) + goto unlock_abort; + + get_page(page); + pa...

...)); > + } else { > + entry = mk_huge_pmd(page, vma->vm_page_prot); > + entry = maybe_pmd_mkwrite(pmd_mkdirty(entry), vma); > + } > + > + ptl = pmd_lock(mm, pmdp); > + > + if (check_stable_address_space(mm)) > + goto unlock_abort; > + > + /* > + * Check for userfaultfd but do not deliver the fault. Instead, > + * just back off. > + */ > + if (userfaultfd_missing(vma)) > + goto unlock_abort; > + > + if (pmd_present(*pmdp)) { > + if (!is_huge_zero_pmd(*pmdp)) > + goto unlock_abort; > + flush = true; > + } else if (!pmd_none(*pmd...

...e_private_entry(page, + vma->vm_flags & VM_WRITE)); + } else { + entry = mk_huge_pmd(page, vma->vm_page_prot); + entry = maybe_pmd_mkwrite(pmd_mkdirty(entry), vma); + } + + ptl = pmd_lock(mm, pmdp); + + if (check_stable_address_space(mm)) + goto unlock_abort; + + /* + * Check for userfaultfd but do not deliver the fault. Instead, + * just back off. + */ + if (userfaultfd_missing(vma)) + goto unlock_abort; + + if (pmd_present(*pmdp)) { + if (!is_huge_zero_pmd(*pmdp)) + goto unlock_abort; + flush = true; + } else if (!pmd_none(*pmdp)) + goto unlock_abort; + + get_page(page); + pa...

change from v6: fix typos and remove uncessary comments. change from v5: spilt x86/kvm patch into guest/host part. introduce kvm_write_guest_offset_cached. fix some typos. rebase patch onto 4.9.2 change from v4: spilt x86 kvm vcpu preempted check into two patches. add documentation patch. add x86 vcpu preempted check patch under xen add s390 vcpu preempted check patch change from v3: