Michael Ellerman <mpe@xxxxxxxxxxxxxx> writes: > "Aneesh Kumar K.V" <aneesh.kumar@xxxxxxxxxxxxx> writes: > >> The current code doesn't do page migration if the page allocated is a compound page. >> With HugeTLB migration support, we can end up allocating hugetlb pages from >> CMA region. Also, THP pages can be allocated from CMA region. This patch updates >> the code to handle compound pages correctly. The patch also switches to a single >> get_user_pages with the right count, instead of doing one get_user_pages per page. >> That avoids reading page table multiple times. > > It's not very obvious from the above description that the migration > logic is now being done by get_user_pages_longterm(), it just looks like > it's all being deleted in this patch. Would be good to mention that. > >> Since these page reference updates are long term pin, switch to >> get_user_pages_longterm. That makes sure we fail correctly if the guest RAM >> is backed by DAX pages. > > Can you explain that in more detail? DAX pages lifetime is dictated by file system rules and as such, we need to make sure that we free these pages on operations like truncate and punch hole. If we have long term pin on these pages, which are mostly return to userspace with elevated page count, the entity holding the long term pin may not be aware of the fact that file got truncated and the file system blocks possibly got reused. That can result in corruption. Work is going on to solve this issue by either making operations like truncate wait or to make these elevated reference counted page/file system blocks not to be released back to the file system free list. Till then we prevent long term pin on DAX pages. Now that we have an API for long term pin, we should ideally be using that in the vfio code. > >> The patch also converts the hpas member of mm_iommu_table_group_mem_t to a union. >> We use the same storage location to store pointers to struct page. We cannot >> update all the code path use struct page *, because we access hpas in real mode >> and we can't do that struct page * to pfn conversion in real mode. > > That's a pain, it's asking for bugs mixing two different values in the > same array. But I guess it's the least worst option. > > It sounds like that's a separate change you could do in a separate > patch. But it's not, because it's tied to the fact that we're doing a > single GUP call. -aneesh
