* Re: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
@ 2023-06-22 8:25 ` David Hildenbrand
0 siblings, 0 replies; 46+ messages in thread
From: David Hildenbrand @ 2023-06-22 8:25 UTC (permalink / raw)
To: Vivek Kasireddy, dri-devel, linux-mm
Cc: Mike Kravetz, Gerd Hoffmann, Dongwon Kim, Andrew Morton,
James Houghton, Jerome Marchand, Junxiao Chang,
Kirill A . Shutemov, Michal Hocko, Muchun Song, Jason Gunthorpe,
John Hubbard
On 22.06.23 09:27, Vivek Kasireddy wrote:
> The first patch ensures that the mappings needed for handling mmap
> operation would be managed by using the pfn instead of struct page.
> The second patch restores support for mapping hugetlb pages where
> subpages of a hugepage are not directly used anymore (main reason
> for revert) and instead the hugetlb pages and the relevant offsets
> are used to populate the scatterlist for dma-buf export and for
> mmap operation.
>
> Testcase: default_hugepagesz=2M hugepagesz=2M hugepages=2500 options
> were passed to the Host kernel and Qemu was launched with these
> relevant options: qemu-system-x86_64 -m 4096m....
> -device virtio-gpu-pci,max_outputs=1,blob=true,xres=1920,yres=1080
> -display gtk,gl=on
> -object memory-backend-memfd,hugetlb=on,id=mem1,size=4096M
> -machine memory-backend=mem1
>
> Replacing -display gtk,gl=on with -display gtk,gl=off above would
> exercise the mmap handler.
>
While I think the VM_PFNMAP approach is much better and should fix that
issue at hand, I thought more about missing memlock support and realized
that we might have to fix something else. SO I'm going to raise the
issue here.
I think udmabuf chose the wrong interface to do what it's doing, that
makes it harder to fix it eventually.
Instead of accepting a range in a memfd, it should just have accepted a
user space address range and then used
pin_user_pages(FOLL_WRITE|FOLL_LONGTERM) to longterm-pin the pages
"officially".
So what's the issue? Udma effectively pins pages longterm ("possibly
forever") simply by grabbing a reference on them. These pages might
easily reside in ZONE_MOVABLE or in MIGRATE_CMA pageblocks.
So what udmabuf does is break memory hotunplug and CMA, because it turns
pages that have to remain movable unmovable.
In the pin_user_pages(FOLL_LONGTERM) case we make sure to migrate these
pages. See mm/gup.c:check_and_migrate_movable_pages() and especially
folio_is_longterm_pinnable(). We'd probably have to implement something
similar for udmabuf, where we detect such unpinnable pages and migrate them.
For example, pairing udmabuf with vfio (which pins pages using
pin_user_pages(FOLL_LONGTERM)) in QEMU will most probably not work in
all cases: if udmabuf longterm pinned the pages "the wrong way", vfio
will fail to migrate them during FOLL_LONGTERM and consequently fail
pin_user_pages(). As long as udmabuf holds a reference on these pages,
that will never succeed.
There are *probably* more issues on the QEMU side when udmabuf is paired
with things like MADV_DONTNEED/FALLOC_FL_PUNCH_HOLE used for
virtio-balloon, virtio-mem, postcopy live migration, ... for example, in
the vfio/vdpa case we make sure that we disallow most of these, because
otherwise there can be an accidental "disconnect" between the pages
mapped into the VM (guest view) and the pages mapped into the IOMMU
(device view), for example, after a reboot.
--
Cheers,
David / dhildenb
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
2023-06-22 8:25 ` David Hildenbrand
@ 2023-06-22 21:33 ` Mike Kravetz
-1 siblings, 0 replies; 46+ messages in thread
From: Mike Kravetz @ 2023-06-22 21:33 UTC (permalink / raw)
To: David Hildenbrand
Cc: James Houghton, Jerome Marchand, Dongwon Kim, Junxiao Chang,
Muchun Song, Vivek Kasireddy, dri-devel, linux-mm, Michal Hocko,
Gerd Hoffmann, Jason Gunthorpe, John Hubbard, Andrew Morton,
Kirill A . Shutemov
[-- Attachment #1: Type: text/plain, Size: 950 bytes --]
On 06/22/23 10:25, David Hildenbrand wrote:
> On 22.06.23 09:27, Vivek Kasireddy wrote:
>
> There are *probably* more issues on the QEMU side when udmabuf is paired
> with things like MADV_DONTNEED/FALLOC_FL_PUNCH_HOLE used for virtio-balloon,
> virtio-mem, postcopy live migration, ... for example, in the vfio/vdpa case
> we make sure that we disallow most of these, because otherwise there can be
> an accidental "disconnect" between the pages mapped into the VM (guest view)
> and the pages mapped into the IOMMU (device view), for example, after a
> reboot.
>
Yes, this "disconnect" is still possible. Attached is a test program I
hacked up based on the udmabuf selftest. You can see different content
in the memfd pages and udma pages.
FYI- I can verify this new udmabuf code is not accessing struct pages of
hugetlb tail pages, as this test program BUG'ed if hugetlb vmemmap
optimization was enabled in the old udmabuf.
--
Mike Kravetz
[-- Attachment #2: udmabuf.c --]
[-- Type: text/plain, Size: 3726 bytes --]
// SPDX-License-Identifier: GPL-2.0
#define _GNU_SOURCE
#define __EXPORTED_HEADERS__
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <fcntl.h>
#include <malloc.h>
#include <sys/mman.h>
#include <sys/ioctl.h>
#include <sys/syscall.h>
#include <linux/memfd.h>
#include <linux/udmabuf.h>
#define TEST_PREFIX "drivers/dma-buf/udmabuf"
#define NUM_PAGES 2
static int my_getpagesize(void)
{
/* huge page size */
return getpagesize() * 512;
}
#if 0
static int memfd_create(const char *name, unsigned int flags)
{
return syscall(__NR_memfd_create, name, flags);
}
#endif
int main(int argc, char *argv[])
{
struct udmabuf_create create;
int devfd, memfd, buf, ret;
off_t size;
void *mem;
int i;
char foo;
int mem_fd, udma_fd;
void *addr1, *addr2;
devfd = open("/dev/udmabuf", O_RDWR);
if (devfd < 0) {
printf("%s: [skip,no-udmabuf: Unable to access DMA buffer device file]\n",
TEST_PREFIX);
exit(77);
}
mem_fd = memfd_create("udmabuf-test", MFD_HUGETLB | MFD_ALLOW_SEALING);
if (mem_fd < 0) {
printf("%s: [skip,no-memfd]\n", TEST_PREFIX);
exit(77);
}
ret = fcntl(mem_fd, F_ADD_SEALS, F_SEAL_SHRINK);
if (ret < 0) {
printf("%s: [skip,fcntl-add-seals]\n", TEST_PREFIX);
exit(77);
}
size = my_getpagesize() * NUM_PAGES;
ret = ftruncate(mem_fd, size);
if (ret == -1) {
printf("%s: [FAIL,memfd-truncate]\n", TEST_PREFIX);
exit(1);
}
/* touch all pages */
addr1 = mmap(NULL, size, PROT_READ|PROT_WRITE, MAP_SHARED, mem_fd, 0);
if (addr1 == MAP_FAILED) {
printf("%s: [FAIL,mmap]\n", TEST_PREFIX);
exit(1);
}
for (i = 0; i < size / getpagesize(); i++) {
*((char *)addr1 + (i * getpagesize())) = 'a';
}
memset(&create, 0, sizeof(create));
#if 0
/* should fail (offset not page aligned) */
create.memfd = mem_fd;
create.offset = getpagesize()/2;
create.size = getpagesize();
buf = ioctl(devfd, UDMABUF_CREATE, &create);
if (buf >= 0) {
printf("%s: [FAIL,test-1]\n", TEST_PREFIX);
exit(1);
}
/* should fail (size not multiple of page) */
create.memfd = mem_fd;
create.offset = 0;
create.size = getpagesize()/2;
buf = ioctl(devfd, UDMABUF_CREATE, &create);
if (buf >= 0) {
printf("%s: [FAIL,test-2]\n", TEST_PREFIX);
exit(1);
}
/* should fail (not memfd) */
create.memfd = 0; /* stdin */
create.offset = 0;
create.size = size;
buf = ioctl(devfd, UDMABUF_CREATE, &create);
if (buf >= 0) {
printf("%s: [FAIL,test-3]\n", TEST_PREFIX);
exit(1);
}
#endif
/* should work */
create.memfd = mem_fd;
create.offset = getpagesize() * 256;
create.size = getpagesize() * 4;
udma_fd = ioctl(devfd, UDMABUF_CREATE, &create);
if (udma_fd < 0) {
perror("UDMABUF_CREATE");
printf("%s: [FAIL,test-4]\n", TEST_PREFIX);
exit(1);
}
printf("before hole punch\n");
(void)getchar();
ret = fallocate(mem_fd, FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE,
0, my_getpagesize());
if (ret)
perror("fallocate punch hole");
printf("after hole punch\n");
(void)getchar();
for (i = 0; i < size / getpagesize(); i++) {
*((char *)addr1 + (i * getpagesize())) = 'b';
}
printf("after touch again\n");
(void)getchar();
/* touch all pages */
addr2 = mmap(NULL, getpagesize() * 4, PROT_READ|PROT_WRITE, MAP_SHARED, udma_fd, 0);
if (addr2 == MAP_FAILED) {
perror("mmap");
printf("%s: udma_fd mmap fail\n", TEST_PREFIX);
exit(1);
}
for (i = 0; i < 4; i++) {
foo = *((char *)addr2 + (i * getpagesize()));
printf("udmabuf %c\n", foo);
}
for (i = 256; i < 260; i++) {
foo = *((char *)addr1 + (i * getpagesize()));
printf("memfd %c\n", foo);
}
fprintf(stderr, "%s: ok\n", TEST_PREFIX);
close(udma_fd);
close(mem_fd);
close(devfd);
return 0;
}
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
@ 2023-06-22 21:33 ` Mike Kravetz
0 siblings, 0 replies; 46+ messages in thread
From: Mike Kravetz @ 2023-06-22 21:33 UTC (permalink / raw)
To: David Hildenbrand
Cc: Vivek Kasireddy, dri-devel, linux-mm, Gerd Hoffmann, Dongwon Kim,
Andrew Morton, James Houghton, Jerome Marchand, Junxiao Chang,
Kirill A . Shutemov, Michal Hocko, Muchun Song, Jason Gunthorpe,
John Hubbard
[-- Attachment #1: Type: text/plain, Size: 950 bytes --]
On 06/22/23 10:25, David Hildenbrand wrote:
> On 22.06.23 09:27, Vivek Kasireddy wrote:
>
> There are *probably* more issues on the QEMU side when udmabuf is paired
> with things like MADV_DONTNEED/FALLOC_FL_PUNCH_HOLE used for virtio-balloon,
> virtio-mem, postcopy live migration, ... for example, in the vfio/vdpa case
> we make sure that we disallow most of these, because otherwise there can be
> an accidental "disconnect" between the pages mapped into the VM (guest view)
> and the pages mapped into the IOMMU (device view), for example, after a
> reboot.
>
Yes, this "disconnect" is still possible. Attached is a test program I
hacked up based on the udmabuf selftest. You can see different content
in the memfd pages and udma pages.
FYI- I can verify this new udmabuf code is not accessing struct pages of
hugetlb tail pages, as this test program BUG'ed if hugetlb vmemmap
optimization was enabled in the old udmabuf.
--
Mike Kravetz
[-- Attachment #2: udmabuf.c --]
[-- Type: text/plain, Size: 3726 bytes --]
// SPDX-License-Identifier: GPL-2.0
#define _GNU_SOURCE
#define __EXPORTED_HEADERS__
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <errno.h>
#include <fcntl.h>
#include <malloc.h>
#include <sys/mman.h>
#include <sys/ioctl.h>
#include <sys/syscall.h>
#include <linux/memfd.h>
#include <linux/udmabuf.h>
#define TEST_PREFIX "drivers/dma-buf/udmabuf"
#define NUM_PAGES 2
static int my_getpagesize(void)
{
/* huge page size */
return getpagesize() * 512;
}
#if 0
static int memfd_create(const char *name, unsigned int flags)
{
return syscall(__NR_memfd_create, name, flags);
}
#endif
int main(int argc, char *argv[])
{
struct udmabuf_create create;
int devfd, memfd, buf, ret;
off_t size;
void *mem;
int i;
char foo;
int mem_fd, udma_fd;
void *addr1, *addr2;
devfd = open("/dev/udmabuf", O_RDWR);
if (devfd < 0) {
printf("%s: [skip,no-udmabuf: Unable to access DMA buffer device file]\n",
TEST_PREFIX);
exit(77);
}
mem_fd = memfd_create("udmabuf-test", MFD_HUGETLB | MFD_ALLOW_SEALING);
if (mem_fd < 0) {
printf("%s: [skip,no-memfd]\n", TEST_PREFIX);
exit(77);
}
ret = fcntl(mem_fd, F_ADD_SEALS, F_SEAL_SHRINK);
if (ret < 0) {
printf("%s: [skip,fcntl-add-seals]\n", TEST_PREFIX);
exit(77);
}
size = my_getpagesize() * NUM_PAGES;
ret = ftruncate(mem_fd, size);
if (ret == -1) {
printf("%s: [FAIL,memfd-truncate]\n", TEST_PREFIX);
exit(1);
}
/* touch all pages */
addr1 = mmap(NULL, size, PROT_READ|PROT_WRITE, MAP_SHARED, mem_fd, 0);
if (addr1 == MAP_FAILED) {
printf("%s: [FAIL,mmap]\n", TEST_PREFIX);
exit(1);
}
for (i = 0; i < size / getpagesize(); i++) {
*((char *)addr1 + (i * getpagesize())) = 'a';
}
memset(&create, 0, sizeof(create));
#if 0
/* should fail (offset not page aligned) */
create.memfd = mem_fd;
create.offset = getpagesize()/2;
create.size = getpagesize();
buf = ioctl(devfd, UDMABUF_CREATE, &create);
if (buf >= 0) {
printf("%s: [FAIL,test-1]\n", TEST_PREFIX);
exit(1);
}
/* should fail (size not multiple of page) */
create.memfd = mem_fd;
create.offset = 0;
create.size = getpagesize()/2;
buf = ioctl(devfd, UDMABUF_CREATE, &create);
if (buf >= 0) {
printf("%s: [FAIL,test-2]\n", TEST_PREFIX);
exit(1);
}
/* should fail (not memfd) */
create.memfd = 0; /* stdin */
create.offset = 0;
create.size = size;
buf = ioctl(devfd, UDMABUF_CREATE, &create);
if (buf >= 0) {
printf("%s: [FAIL,test-3]\n", TEST_PREFIX);
exit(1);
}
#endif
/* should work */
create.memfd = mem_fd;
create.offset = getpagesize() * 256;
create.size = getpagesize() * 4;
udma_fd = ioctl(devfd, UDMABUF_CREATE, &create);
if (udma_fd < 0) {
perror("UDMABUF_CREATE");
printf("%s: [FAIL,test-4]\n", TEST_PREFIX);
exit(1);
}
printf("before hole punch\n");
(void)getchar();
ret = fallocate(mem_fd, FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE,
0, my_getpagesize());
if (ret)
perror("fallocate punch hole");
printf("after hole punch\n");
(void)getchar();
for (i = 0; i < size / getpagesize(); i++) {
*((char *)addr1 + (i * getpagesize())) = 'b';
}
printf("after touch again\n");
(void)getchar();
/* touch all pages */
addr2 = mmap(NULL, getpagesize() * 4, PROT_READ|PROT_WRITE, MAP_SHARED, udma_fd, 0);
if (addr2 == MAP_FAILED) {
perror("mmap");
printf("%s: udma_fd mmap fail\n", TEST_PREFIX);
exit(1);
}
for (i = 0; i < 4; i++) {
foo = *((char *)addr2 + (i * getpagesize()));
printf("udmabuf %c\n", foo);
}
for (i = 256; i < 260; i++) {
foo = *((char *)addr1 + (i * getpagesize()));
printf("memfd %c\n", foo);
}
fprintf(stderr, "%s: ok\n", TEST_PREFIX);
close(udma_fd);
close(mem_fd);
close(devfd);
return 0;
}
^ permalink raw reply [flat|nested] 46+ messages in thread
* RE: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
2023-06-22 8:25 ` David Hildenbrand
@ 2023-06-23 6:13 ` Kasireddy, Vivek
-1 siblings, 0 replies; 46+ messages in thread
From: Kasireddy, Vivek @ 2023-06-23 6:13 UTC (permalink / raw)
To: David Hildenbrand, dri-devel@lists.freedesktop.org,
linux-mm@kvack.org
Cc: James Houghton, Jerome Marchand, Kim, Dongwon, Chang, Junxiao,
Muchun Song, Hocko, Michal, Gerd Hoffmann, Jason Gunthorpe,
John Hubbard, Andrew Morton, Kirill A . Shutemov, Mike Kravetz
Hi David,
> > The first patch ensures that the mappings needed for handling mmap
> > operation would be managed by using the pfn instead of struct page.
> > The second patch restores support for mapping hugetlb pages where
> > subpages of a hugepage are not directly used anymore (main reason
> > for revert) and instead the hugetlb pages and the relevant offsets
> > are used to populate the scatterlist for dma-buf export and for
> > mmap operation.
> >
> > Testcase: default_hugepagesz=2M hugepagesz=2M hugepages=2500
> options
> > were passed to the Host kernel and Qemu was launched with these
> > relevant options: qemu-system-x86_64 -m 4096m....
> > -device virtio-gpu-pci,max_outputs=1,blob=true,xres=1920,yres=1080
> > -display gtk,gl=on
> > -object memory-backend-memfd,hugetlb=on,id=mem1,size=4096M
> > -machine memory-backend=mem1
> >
> > Replacing -display gtk,gl=on with -display gtk,gl=off above would
> > exercise the mmap handler.
> >
>
> While I think the VM_PFNMAP approach is much better and should fix that
> issue at hand, I thought more about missing memlock support and realized
> that we might have to fix something else. SO I'm going to raise the
> issue here.
>
> I think udmabuf chose the wrong interface to do what it's doing, that
> makes it harder to fix it eventually.
>
> Instead of accepting a range in a memfd, it should just have accepted a
> user space address range and then used
> pin_user_pages(FOLL_WRITE|FOLL_LONGTERM) to longterm-pin the pages
> "officially".
Udmabuf indeed started off by using user space address range and GUP but
the dma-buf subsystem maintainer had concerns with that approach in v2.
It also had support for mlock in that version. Here is v2 and the relevant
conversation:
https://patchwork.freedesktop.org/patch/210992/?series=39879&rev=2
>
> So what's the issue? Udma effectively pins pages longterm ("possibly
> forever") simply by grabbing a reference on them. These pages might
> easily reside in ZONE_MOVABLE or in MIGRATE_CMA pageblocks.
>
> So what udmabuf does is break memory hotunplug and CMA, because it
> turns
> pages that have to remain movable unmovable.
>
> In the pin_user_pages(FOLL_LONGTERM) case we make sure to migrate
> these
> pages. See mm/gup.c:check_and_migrate_movable_pages() and especially
> folio_is_longterm_pinnable(). We'd probably have to implement something
> similar for udmabuf, where we detect such unpinnable pages and migrate
> them.
The pages udmabuf pins are only those associated with Guest (GPU driver/virtio-gpu)
resources (or buffers allocated and pinned from shmem via drm GEM). Some
resources are short-lived, and some are long-lived and whenever a resource
gets destroyed, the pages are unpinned. And, not all resources have their pages
pinned. The resource that is pinned for the longest duration is the FB and that's
because it is updated every ~16ms (assuming 1920x1080@60) by the Guest
GPU driver. We can certainly pin/unpin the FB after it is accessed on the Host
as a workaround, but I guess that may not be very efficient given the amount
of churn it would create.
Also, as far as migration or S3/S4 is concerned, my understanding is that all
the Guest resources are destroyed and recreated again. So, wouldn't something
similar happen during memory hotunplug?
>
>
> For example, pairing udmabuf with vfio (which pins pages using
> pin_user_pages(FOLL_LONGTERM)) in QEMU will most probably not work in
> all cases: if udmabuf longterm pinned the pages "the wrong way", vfio
> will fail to migrate them during FOLL_LONGTERM and consequently fail
> pin_user_pages(). As long as udmabuf holds a reference on these pages,
> that will never succeed.
Dma-buf rules (for exporters) indicate that the pages only need to be pinned
during the map_attachment phase (and until unmap attachment happens).
In other words, only when the sg_table is created by udmabuf. I guess one
option would be to not hold any references during UDMABUF_CREATE and
only grab references to the pages (as and when it gets used) during this step.
Would this help?
>
>
> There are *probably* more issues on the QEMU side when udmabuf is
> paired
> with things like MADV_DONTNEED/FALLOC_FL_PUNCH_HOLE used for
> virtio-balloon, virtio-mem, postcopy live migration, ... for example, in
> the vfio/vdpa case we make sure that we disallow most of these, because
> otherwise there can be an accidental "disconnect" between the pages
> mapped into the VM (guest view) and the pages mapped into the IOMMU
> (device view), for example, after a reboot.
Ok; I am not sure if I can figure out if there is any acceptable way to address
these issues but given the current constraints associated with udmabuf, what
do you suggest is the most reasonable way to deal with these problems you
have identified?
Thanks,
Vivek
>
> --
> Cheers,
>
> David / dhildenb
^ permalink raw reply [flat|nested] 46+ messages in thread* RE: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
@ 2023-06-23 6:13 ` Kasireddy, Vivek
0 siblings, 0 replies; 46+ messages in thread
From: Kasireddy, Vivek @ 2023-06-23 6:13 UTC (permalink / raw)
To: David Hildenbrand, dri-devel@lists.freedesktop.org,
linux-mm@kvack.org
Cc: Mike Kravetz, Gerd Hoffmann, Kim, Dongwon, Andrew Morton,
James Houghton, Jerome Marchand, Chang, Junxiao,
Kirill A . Shutemov, Hocko, Michal, Muchun Song, Jason Gunthorpe,
John Hubbard
Hi David,
> > The first patch ensures that the mappings needed for handling mmap
> > operation would be managed by using the pfn instead of struct page.
> > The second patch restores support for mapping hugetlb pages where
> > subpages of a hugepage are not directly used anymore (main reason
> > for revert) and instead the hugetlb pages and the relevant offsets
> > are used to populate the scatterlist for dma-buf export and for
> > mmap operation.
> >
> > Testcase: default_hugepagesz=2M hugepagesz=2M hugepages=2500
> options
> > were passed to the Host kernel and Qemu was launched with these
> > relevant options: qemu-system-x86_64 -m 4096m....
> > -device virtio-gpu-pci,max_outputs=1,blob=true,xres=1920,yres=1080
> > -display gtk,gl=on
> > -object memory-backend-memfd,hugetlb=on,id=mem1,size=4096M
> > -machine memory-backend=mem1
> >
> > Replacing -display gtk,gl=on with -display gtk,gl=off above would
> > exercise the mmap handler.
> >
>
> While I think the VM_PFNMAP approach is much better and should fix that
> issue at hand, I thought more about missing memlock support and realized
> that we might have to fix something else. SO I'm going to raise the
> issue here.
>
> I think udmabuf chose the wrong interface to do what it's doing, that
> makes it harder to fix it eventually.
>
> Instead of accepting a range in a memfd, it should just have accepted a
> user space address range and then used
> pin_user_pages(FOLL_WRITE|FOLL_LONGTERM) to longterm-pin the pages
> "officially".
Udmabuf indeed started off by using user space address range and GUP but
the dma-buf subsystem maintainer had concerns with that approach in v2.
It also had support for mlock in that version. Here is v2 and the relevant
conversation:
https://patchwork.freedesktop.org/patch/210992/?series=39879&rev=2
>
> So what's the issue? Udma effectively pins pages longterm ("possibly
> forever") simply by grabbing a reference on them. These pages might
> easily reside in ZONE_MOVABLE or in MIGRATE_CMA pageblocks.
>
> So what udmabuf does is break memory hotunplug and CMA, because it
> turns
> pages that have to remain movable unmovable.
>
> In the pin_user_pages(FOLL_LONGTERM) case we make sure to migrate
> these
> pages. See mm/gup.c:check_and_migrate_movable_pages() and especially
> folio_is_longterm_pinnable(). We'd probably have to implement something
> similar for udmabuf, where we detect such unpinnable pages and migrate
> them.
The pages udmabuf pins are only those associated with Guest (GPU driver/virtio-gpu)
resources (or buffers allocated and pinned from shmem via drm GEM). Some
resources are short-lived, and some are long-lived and whenever a resource
gets destroyed, the pages are unpinned. And, not all resources have their pages
pinned. The resource that is pinned for the longest duration is the FB and that's
because it is updated every ~16ms (assuming 1920x1080@60) by the Guest
GPU driver. We can certainly pin/unpin the FB after it is accessed on the Host
as a workaround, but I guess that may not be very efficient given the amount
of churn it would create.
Also, as far as migration or S3/S4 is concerned, my understanding is that all
the Guest resources are destroyed and recreated again. So, wouldn't something
similar happen during memory hotunplug?
>
>
> For example, pairing udmabuf with vfio (which pins pages using
> pin_user_pages(FOLL_LONGTERM)) in QEMU will most probably not work in
> all cases: if udmabuf longterm pinned the pages "the wrong way", vfio
> will fail to migrate them during FOLL_LONGTERM and consequently fail
> pin_user_pages(). As long as udmabuf holds a reference on these pages,
> that will never succeed.
Dma-buf rules (for exporters) indicate that the pages only need to be pinned
during the map_attachment phase (and until unmap attachment happens).
In other words, only when the sg_table is created by udmabuf. I guess one
option would be to not hold any references during UDMABUF_CREATE and
only grab references to the pages (as and when it gets used) during this step.
Would this help?
>
>
> There are *probably* more issues on the QEMU side when udmabuf is
> paired
> with things like MADV_DONTNEED/FALLOC_FL_PUNCH_HOLE used for
> virtio-balloon, virtio-mem, postcopy live migration, ... for example, in
> the vfio/vdpa case we make sure that we disallow most of these, because
> otherwise there can be an accidental "disconnect" between the pages
> mapped into the VM (guest view) and the pages mapped into the IOMMU
> (device view), for example, after a reboot.
Ok; I am not sure if I can figure out if there is any acceptable way to address
these issues but given the current constraints associated with udmabuf, what
do you suggest is the most reasonable way to deal with these problems you
have identified?
Thanks,
Vivek
>
> --
> Cheers,
>
> David / dhildenb
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
2023-06-23 6:13 ` Kasireddy, Vivek
@ 2023-06-23 16:35 ` Peter Xu
-1 siblings, 0 replies; 46+ messages in thread
From: Peter Xu @ 2023-06-23 16:35 UTC (permalink / raw)
To: Kasireddy, Vivek
Cc: James Houghton, Jerome Marchand, Kim, Dongwon, David Hildenbrand,
Chang, Junxiao, Muchun Song, dri-devel@lists.freedesktop.org,
linux-mm@kvack.org, Hocko, Michal, Gerd Hoffmann, Jason Gunthorpe,
John Hubbard, Andrew Morton, Kirill A . Shutemov, Mike Kravetz
On Fri, Jun 23, 2023 at 06:13:02AM +0000, Kasireddy, Vivek wrote:
> Hi David,
>
> > > The first patch ensures that the mappings needed for handling mmap
> > > operation would be managed by using the pfn instead of struct page.
> > > The second patch restores support for mapping hugetlb pages where
> > > subpages of a hugepage are not directly used anymore (main reason
> > > for revert) and instead the hugetlb pages and the relevant offsets
> > > are used to populate the scatterlist for dma-buf export and for
> > > mmap operation.
> > >
> > > Testcase: default_hugepagesz=2M hugepagesz=2M hugepages=2500
> > options
> > > were passed to the Host kernel and Qemu was launched with these
> > > relevant options: qemu-system-x86_64 -m 4096m....
> > > -device virtio-gpu-pci,max_outputs=1,blob=true,xres=1920,yres=1080
> > > -display gtk,gl=on
> > > -object memory-backend-memfd,hugetlb=on,id=mem1,size=4096M
> > > -machine memory-backend=mem1
> > >
> > > Replacing -display gtk,gl=on with -display gtk,gl=off above would
> > > exercise the mmap handler.
> > >
> >
> > While I think the VM_PFNMAP approach is much better and should fix that
> > issue at hand, I thought more about missing memlock support and realized
> > that we might have to fix something else. SO I'm going to raise the
> > issue here.
> >
> > I think udmabuf chose the wrong interface to do what it's doing, that
> > makes it harder to fix it eventually.
> >
> > Instead of accepting a range in a memfd, it should just have accepted a
> > user space address range and then used
> > pin_user_pages(FOLL_WRITE|FOLL_LONGTERM) to longterm-pin the pages
> > "officially".
> Udmabuf indeed started off by using user space address range and GUP but
> the dma-buf subsystem maintainer had concerns with that approach in v2.
> It also had support for mlock in that version. Here is v2 and the relevant
> conversation:
> https://patchwork.freedesktop.org/patch/210992/?series=39879&rev=2
>
> >
> > So what's the issue? Udma effectively pins pages longterm ("possibly
> > forever") simply by grabbing a reference on them. These pages might
> > easily reside in ZONE_MOVABLE or in MIGRATE_CMA pageblocks.
> >
> > So what udmabuf does is break memory hotunplug and CMA, because it
> > turns
> > pages that have to remain movable unmovable.
> >
> > In the pin_user_pages(FOLL_LONGTERM) case we make sure to migrate
> > these
> > pages. See mm/gup.c:check_and_migrate_movable_pages() and especially
> > folio_is_longterm_pinnable(). We'd probably have to implement something
> > similar for udmabuf, where we detect such unpinnable pages and migrate
> > them.
> The pages udmabuf pins are only those associated with Guest (GPU driver/virtio-gpu)
> resources (or buffers allocated and pinned from shmem via drm GEM). Some
> resources are short-lived, and some are long-lived and whenever a resource
> gets destroyed, the pages are unpinned. And, not all resources have their pages
> pinned. The resource that is pinned for the longest duration is the FB and that's
> because it is updated every ~16ms (assuming 1920x1080@60) by the Guest
> GPU driver. We can certainly pin/unpin the FB after it is accessed on the Host
> as a workaround, but I guess that may not be very efficient given the amount
> of churn it would create.
>
> Also, as far as migration or S3/S4 is concerned, my understanding is that all
> the Guest resources are destroyed and recreated again. So, wouldn't something
> similar happen during memory hotunplug?
>
> >
> >
> > For example, pairing udmabuf with vfio (which pins pages using
> > pin_user_pages(FOLL_LONGTERM)) in QEMU will most probably not work in
> > all cases: if udmabuf longterm pinned the pages "the wrong way", vfio
> > will fail to migrate them during FOLL_LONGTERM and consequently fail
> > pin_user_pages(). As long as udmabuf holds a reference on these pages,
> > that will never succeed.
> Dma-buf rules (for exporters) indicate that the pages only need to be pinned
> during the map_attachment phase (and until unmap attachment happens).
> In other words, only when the sg_table is created by udmabuf. I guess one
> option would be to not hold any references during UDMABUF_CREATE and
> only grab references to the pages (as and when it gets used) during this step.
> Would this help?
IIUC the refcount is needed, otherwise I don't see what to protect the page
from being freed and even reused elsewhere before map_attachment().
It seems the previous concern on using gup was majorly fork(), if this is it:
https://patchwork.freedesktop.org/patch/210992/?series=39879&rev=2#comment_414213
Could it also be guarded by just making sure the pages are MAP_SHARED when
creating the udmabuf, if fork() is a requirement of the feature?
I had a feeling that the userspace still needs to always do the right thing
to make it work, even using pure PFN mappings.
For instance, what if the userapp just punchs a hole in the shmem/hugetlbfs
file after creating the udmabuf (I see that F_SEAL_SHRINK is required, but
at least not F_SEAL_WRITE with current impl), and fault a new page into the
page cache?
Thanks,
>
> >
> >
> > There are *probably* more issues on the QEMU side when udmabuf is
> > paired
> > with things like MADV_DONTNEED/FALLOC_FL_PUNCH_HOLE used for
> > virtio-balloon, virtio-mem, postcopy live migration, ... for example, in
> > the vfio/vdpa case we make sure that we disallow most of these, because
> > otherwise there can be an accidental "disconnect" between the pages
> > mapped into the VM (guest view) and the pages mapped into the IOMMU
> > (device view), for example, after a reboot.
> Ok; I am not sure if I can figure out if there is any acceptable way to address
> these issues but given the current constraints associated with udmabuf, what
> do you suggest is the most reasonable way to deal with these problems you
> have identified?
>
> Thanks,
> Vivek
>
> >
> > --
> > Cheers,
> >
> > David / dhildenb
>
--
Peter Xu
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
@ 2023-06-23 16:35 ` Peter Xu
0 siblings, 0 replies; 46+ messages in thread
From: Peter Xu @ 2023-06-23 16:35 UTC (permalink / raw)
To: Kasireddy, Vivek
Cc: David Hildenbrand, dri-devel@lists.freedesktop.org,
linux-mm@kvack.org, Mike Kravetz, Gerd Hoffmann, Kim, Dongwon,
Andrew Morton, James Houghton, Jerome Marchand, Chang, Junxiao,
Kirill A . Shutemov, Hocko, Michal, Muchun Song, Jason Gunthorpe,
John Hubbard
On Fri, Jun 23, 2023 at 06:13:02AM +0000, Kasireddy, Vivek wrote:
> Hi David,
>
> > > The first patch ensures that the mappings needed for handling mmap
> > > operation would be managed by using the pfn instead of struct page.
> > > The second patch restores support for mapping hugetlb pages where
> > > subpages of a hugepage are not directly used anymore (main reason
> > > for revert) and instead the hugetlb pages and the relevant offsets
> > > are used to populate the scatterlist for dma-buf export and for
> > > mmap operation.
> > >
> > > Testcase: default_hugepagesz=2M hugepagesz=2M hugepages=2500
> > options
> > > were passed to the Host kernel and Qemu was launched with these
> > > relevant options: qemu-system-x86_64 -m 4096m....
> > > -device virtio-gpu-pci,max_outputs=1,blob=true,xres=1920,yres=1080
> > > -display gtk,gl=on
> > > -object memory-backend-memfd,hugetlb=on,id=mem1,size=4096M
> > > -machine memory-backend=mem1
> > >
> > > Replacing -display gtk,gl=on with -display gtk,gl=off above would
> > > exercise the mmap handler.
> > >
> >
> > While I think the VM_PFNMAP approach is much better and should fix that
> > issue at hand, I thought more about missing memlock support and realized
> > that we might have to fix something else. SO I'm going to raise the
> > issue here.
> >
> > I think udmabuf chose the wrong interface to do what it's doing, that
> > makes it harder to fix it eventually.
> >
> > Instead of accepting a range in a memfd, it should just have accepted a
> > user space address range and then used
> > pin_user_pages(FOLL_WRITE|FOLL_LONGTERM) to longterm-pin the pages
> > "officially".
> Udmabuf indeed started off by using user space address range and GUP but
> the dma-buf subsystem maintainer had concerns with that approach in v2.
> It also had support for mlock in that version. Here is v2 and the relevant
> conversation:
> https://patchwork.freedesktop.org/patch/210992/?series=39879&rev=2
>
> >
> > So what's the issue? Udma effectively pins pages longterm ("possibly
> > forever") simply by grabbing a reference on them. These pages might
> > easily reside in ZONE_MOVABLE or in MIGRATE_CMA pageblocks.
> >
> > So what udmabuf does is break memory hotunplug and CMA, because it
> > turns
> > pages that have to remain movable unmovable.
> >
> > In the pin_user_pages(FOLL_LONGTERM) case we make sure to migrate
> > these
> > pages. See mm/gup.c:check_and_migrate_movable_pages() and especially
> > folio_is_longterm_pinnable(). We'd probably have to implement something
> > similar for udmabuf, where we detect such unpinnable pages and migrate
> > them.
> The pages udmabuf pins are only those associated with Guest (GPU driver/virtio-gpu)
> resources (or buffers allocated and pinned from shmem via drm GEM). Some
> resources are short-lived, and some are long-lived and whenever a resource
> gets destroyed, the pages are unpinned. And, not all resources have their pages
> pinned. The resource that is pinned for the longest duration is the FB and that's
> because it is updated every ~16ms (assuming 1920x1080@60) by the Guest
> GPU driver. We can certainly pin/unpin the FB after it is accessed on the Host
> as a workaround, but I guess that may not be very efficient given the amount
> of churn it would create.
>
> Also, as far as migration or S3/S4 is concerned, my understanding is that all
> the Guest resources are destroyed and recreated again. So, wouldn't something
> similar happen during memory hotunplug?
>
> >
> >
> > For example, pairing udmabuf with vfio (which pins pages using
> > pin_user_pages(FOLL_LONGTERM)) in QEMU will most probably not work in
> > all cases: if udmabuf longterm pinned the pages "the wrong way", vfio
> > will fail to migrate them during FOLL_LONGTERM and consequently fail
> > pin_user_pages(). As long as udmabuf holds a reference on these pages,
> > that will never succeed.
> Dma-buf rules (for exporters) indicate that the pages only need to be pinned
> during the map_attachment phase (and until unmap attachment happens).
> In other words, only when the sg_table is created by udmabuf. I guess one
> option would be to not hold any references during UDMABUF_CREATE and
> only grab references to the pages (as and when it gets used) during this step.
> Would this help?
IIUC the refcount is needed, otherwise I don't see what to protect the page
from being freed and even reused elsewhere before map_attachment().
It seems the previous concern on using gup was majorly fork(), if this is it:
https://patchwork.freedesktop.org/patch/210992/?series=39879&rev=2#comment_414213
Could it also be guarded by just making sure the pages are MAP_SHARED when
creating the udmabuf, if fork() is a requirement of the feature?
I had a feeling that the userspace still needs to always do the right thing
to make it work, even using pure PFN mappings.
For instance, what if the userapp just punchs a hole in the shmem/hugetlbfs
file after creating the udmabuf (I see that F_SEAL_SHRINK is required, but
at least not F_SEAL_WRITE with current impl), and fault a new page into the
page cache?
Thanks,
>
> >
> >
> > There are *probably* more issues on the QEMU side when udmabuf is
> > paired
> > with things like MADV_DONTNEED/FALLOC_FL_PUNCH_HOLE used for
> > virtio-balloon, virtio-mem, postcopy live migration, ... for example, in
> > the vfio/vdpa case we make sure that we disallow most of these, because
> > otherwise there can be an accidental "disconnect" between the pages
> > mapped into the VM (guest view) and the pages mapped into the IOMMU
> > (device view), for example, after a reboot.
> Ok; I am not sure if I can figure out if there is any acceptable way to address
> these issues but given the current constraints associated with udmabuf, what
> do you suggest is the most reasonable way to deal with these problems you
> have identified?
>
> Thanks,
> Vivek
>
> >
> > --
> > Cheers,
> >
> > David / dhildenb
>
--
Peter Xu
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
2023-06-23 16:35 ` Peter Xu
@ 2023-06-23 16:37 ` Jason Gunthorpe
-1 siblings, 0 replies; 46+ messages in thread
From: Jason Gunthorpe @ 2023-06-23 16:37 UTC (permalink / raw)
To: Peter Xu
Cc: James Houghton, Jerome Marchand, Kim, Dongwon, David Hildenbrand,
Chang, Junxiao, Muchun Song, Kasireddy, Vivek,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
Hocko, Michal, Gerd Hoffmann, John Hubbard, Andrew Morton,
Kirill A . Shutemov, Mike Kravetz
On Fri, Jun 23, 2023 at 12:35:45PM -0400, Peter Xu wrote:
> It seems the previous concern on using gup was majorly fork(), if this is it:
>
> https://patchwork.freedesktop.org/patch/210992/?series=39879&rev=2#comment_414213
Fork and GUP have been fixed since that comment anyhow there is no
longer a problem using GUP and fork together.
> Could it also be guarded by just making sure the pages are MAP_SHARED when
> creating the udmabuf, if fork() is a requirement of the feature?
Also a resaonable thing to do
> For instance, what if the userapp just punchs a hole in the shmem/hugetlbfs
> file after creating the udmabuf (I see that F_SEAL_SHRINK is required, but
> at least not F_SEAL_WRITE with current impl), and fault a new page into the
> page cache?
It becomes incoherent just like all other GUP users if userspace
explicitly manipulates the VMAs. It is no different to what happens
with VFIO, qemu should treat this memory the same as it does for VFIO
memory.
Jason
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
@ 2023-06-23 16:37 ` Jason Gunthorpe
0 siblings, 0 replies; 46+ messages in thread
From: Jason Gunthorpe @ 2023-06-23 16:37 UTC (permalink / raw)
To: Peter Xu
Cc: Kasireddy, Vivek, David Hildenbrand,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org, Mike Kravetz,
Gerd Hoffmann, Kim, Dongwon, Andrew Morton, James Houghton,
Jerome Marchand, Chang, Junxiao, Kirill A . Shutemov,
Hocko, Michal, Muchun Song, John Hubbard
On Fri, Jun 23, 2023 at 12:35:45PM -0400, Peter Xu wrote:
> It seems the previous concern on using gup was majorly fork(), if this is it:
>
> https://patchwork.freedesktop.org/patch/210992/?series=39879&rev=2#comment_414213
Fork and GUP have been fixed since that comment anyhow there is no
longer a problem using GUP and fork together.
> Could it also be guarded by just making sure the pages are MAP_SHARED when
> creating the udmabuf, if fork() is a requirement of the feature?
Also a resaonable thing to do
> For instance, what if the userapp just punchs a hole in the shmem/hugetlbfs
> file after creating the udmabuf (I see that F_SEAL_SHRINK is required, but
> at least not F_SEAL_WRITE with current impl), and fault a new page into the
> page cache?
It becomes incoherent just like all other GUP users if userspace
explicitly manipulates the VMAs. It is no different to what happens
with VFIO, qemu should treat this memory the same as it does for VFIO
memory.
Jason
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
2023-06-23 16:37 ` Jason Gunthorpe
@ 2023-06-23 17:28 ` Peter Xu
-1 siblings, 0 replies; 46+ messages in thread
From: Peter Xu @ 2023-06-23 17:28 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: James Houghton, Jerome Marchand, Kim, Dongwon, David Hildenbrand,
Chang, Junxiao, Muchun Song, Kasireddy, Vivek,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
Hocko, Michal, Gerd Hoffmann, John Hubbard, Andrew Morton,
Kirill A . Shutemov, Mike Kravetz
On Fri, Jun 23, 2023 at 01:37:58PM -0300, Jason Gunthorpe wrote:
> On Fri, Jun 23, 2023 at 12:35:45PM -0400, Peter Xu wrote:
>
> > It seems the previous concern on using gup was majorly fork(), if this is it:
> >
> > https://patchwork.freedesktop.org/patch/210992/?series=39879&rev=2#comment_414213
>
> Fork and GUP have been fixed since that comment anyhow there is no
> longer a problem using GUP and fork together.
Ah, I read it previously as a requirement that the child will also be able
the see the same / coherent page when manipulating the dmabuf later after
fork(), e.g., the udmabuf can be created before fork().
>
> > Could it also be guarded by just making sure the pages are MAP_SHARED when
> > creating the udmabuf, if fork() is a requirement of the feature?
>
> Also a resaonable thing to do
>
> > For instance, what if the userapp just punchs a hole in the shmem/hugetlbfs
> > file after creating the udmabuf (I see that F_SEAL_SHRINK is required, but
> > at least not F_SEAL_WRITE with current impl), and fault a new page into the
> > page cache?
>
> It becomes incoherent just like all other GUP users if userspace
> explicitly manipulates the VMAs. It is no different to what happens
> with VFIO, qemu should treat this memory the same as it does for VFIO
> memory.
Agreed.
--
Peter Xu
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
@ 2023-06-23 17:28 ` Peter Xu
0 siblings, 0 replies; 46+ messages in thread
From: Peter Xu @ 2023-06-23 17:28 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Kasireddy, Vivek, David Hildenbrand,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org, Mike Kravetz,
Gerd Hoffmann, Kim, Dongwon, Andrew Morton, James Houghton,
Jerome Marchand, Chang, Junxiao, Kirill A . Shutemov,
Hocko, Michal, Muchun Song, John Hubbard
On Fri, Jun 23, 2023 at 01:37:58PM -0300, Jason Gunthorpe wrote:
> On Fri, Jun 23, 2023 at 12:35:45PM -0400, Peter Xu wrote:
>
> > It seems the previous concern on using gup was majorly fork(), if this is it:
> >
> > https://patchwork.freedesktop.org/patch/210992/?series=39879&rev=2#comment_414213
>
> Fork and GUP have been fixed since that comment anyhow there is no
> longer a problem using GUP and fork together.
Ah, I read it previously as a requirement that the child will also be able
the see the same / coherent page when manipulating the dmabuf later after
fork(), e.g., the udmabuf can be created before fork().
>
> > Could it also be guarded by just making sure the pages are MAP_SHARED when
> > creating the udmabuf, if fork() is a requirement of the feature?
>
> Also a resaonable thing to do
>
> > For instance, what if the userapp just punchs a hole in the shmem/hugetlbfs
> > file after creating the udmabuf (I see that F_SEAL_SHRINK is required, but
> > at least not F_SEAL_WRITE with current impl), and fault a new page into the
> > page cache?
>
> It becomes incoherent just like all other GUP users if userspace
> explicitly manipulates the VMAs. It is no different to what happens
> with VFIO, qemu should treat this memory the same as it does for VFIO
> memory.
Agreed.
--
Peter Xu
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
2023-06-23 17:28 ` Peter Xu
@ 2023-06-26 12:57 ` Jason Gunthorpe
-1 siblings, 0 replies; 46+ messages in thread
From: Jason Gunthorpe @ 2023-06-26 12:57 UTC (permalink / raw)
To: Peter Xu
Cc: James Houghton, Jerome Marchand, Kim, Dongwon, David Hildenbrand,
Chang, Junxiao, Muchun Song, Kasireddy, Vivek,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
Hocko, Michal, Gerd Hoffmann, John Hubbard, Andrew Morton,
Kirill A . Shutemov, Mike Kravetz
On Fri, Jun 23, 2023 at 01:28:24PM -0400, Peter Xu wrote:
> On Fri, Jun 23, 2023 at 01:37:58PM -0300, Jason Gunthorpe wrote:
> > On Fri, Jun 23, 2023 at 12:35:45PM -0400, Peter Xu wrote:
> >
> > > It seems the previous concern on using gup was majorly fork(), if this is it:
> > >
> > > https://patchwork.freedesktop.org/patch/210992/?series=39879&rev=2#comment_414213
> >
> > Fork and GUP have been fixed since that comment anyhow there is no
> > longer a problem using GUP and fork together.
>
> Ah, I read it previously as a requirement that the child will also be able
> the see the same / coherent page when manipulating the dmabuf later after
> fork(), e.g., the udmabuf can be created before fork().
That always worked, just use MAP_SHARED.
Jason
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
@ 2023-06-26 12:57 ` Jason Gunthorpe
0 siblings, 0 replies; 46+ messages in thread
From: Jason Gunthorpe @ 2023-06-26 12:57 UTC (permalink / raw)
To: Peter Xu
Cc: Kasireddy, Vivek, David Hildenbrand,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org, Mike Kravetz,
Gerd Hoffmann, Kim, Dongwon, Andrew Morton, James Houghton,
Jerome Marchand, Chang, Junxiao, Kirill A . Shutemov,
Hocko, Michal, Muchun Song, John Hubbard
On Fri, Jun 23, 2023 at 01:28:24PM -0400, Peter Xu wrote:
> On Fri, Jun 23, 2023 at 01:37:58PM -0300, Jason Gunthorpe wrote:
> > On Fri, Jun 23, 2023 at 12:35:45PM -0400, Peter Xu wrote:
> >
> > > It seems the previous concern on using gup was majorly fork(), if this is it:
> > >
> > > https://patchwork.freedesktop.org/patch/210992/?series=39879&rev=2#comment_414213
> >
> > Fork and GUP have been fixed since that comment anyhow there is no
> > longer a problem using GUP and fork together.
>
> Ah, I read it previously as a requirement that the child will also be able
> the see the same / coherent page when manipulating the dmabuf later after
> fork(), e.g., the udmabuf can be created before fork().
That always worked, just use MAP_SHARED.
Jason
^ permalink raw reply [flat|nested] 46+ messages in thread
* RE: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
2023-06-23 16:35 ` Peter Xu
@ 2023-06-26 7:45 ` Kasireddy, Vivek
-1 siblings, 0 replies; 46+ messages in thread
From: Kasireddy, Vivek @ 2023-06-26 7:45 UTC (permalink / raw)
To: Peter Xu
Cc: James Houghton, Jerome Marchand, Kim, Dongwon, David Hildenbrand,
Chang, Junxiao, Muchun Song, dri-devel@lists.freedesktop.org,
linux-mm@kvack.org, Hocko, Michal, Gerd Hoffmann, Jason Gunthorpe,
John Hubbard, Andrew Morton, Kirill A . Shutemov, Mike Kravetz
Hi Peter,
>
> On Fri, Jun 23, 2023 at 06:13:02AM +0000, Kasireddy, Vivek wrote:
> > Hi David,
> >
> > > > The first patch ensures that the mappings needed for handling mmap
> > > > operation would be managed by using the pfn instead of struct page.
> > > > The second patch restores support for mapping hugetlb pages where
> > > > subpages of a hugepage are not directly used anymore (main reason
> > > > for revert) and instead the hugetlb pages and the relevant offsets
> > > > are used to populate the scatterlist for dma-buf export and for
> > > > mmap operation.
> > > >
> > > > Testcase: default_hugepagesz=2M hugepagesz=2M hugepages=2500
> > > options
> > > > were passed to the Host kernel and Qemu was launched with these
> > > > relevant options: qemu-system-x86_64 -m 4096m....
> > > > -device virtio-gpu-pci,max_outputs=1,blob=true,xres=1920,yres=1080
> > > > -display gtk,gl=on
> > > > -object memory-backend-memfd,hugetlb=on,id=mem1,size=4096M
> > > > -machine memory-backend=mem1
> > > >
> > > > Replacing -display gtk,gl=on with -display gtk,gl=off above would
> > > > exercise the mmap handler.
> > > >
> > >
> > > While I think the VM_PFNMAP approach is much better and should fix
> that
> > > issue at hand, I thought more about missing memlock support and
> realized
> > > that we might have to fix something else. SO I'm going to raise the
> > > issue here.
> > >
> > > I think udmabuf chose the wrong interface to do what it's doing, that
> > > makes it harder to fix it eventually.
> > >
> > > Instead of accepting a range in a memfd, it should just have accepted a
> > > user space address range and then used
> > > pin_user_pages(FOLL_WRITE|FOLL_LONGTERM) to longterm-pin the
> pages
> > > "officially".
> > Udmabuf indeed started off by using user space address range and GUP
> but
> > the dma-buf subsystem maintainer had concerns with that approach in v2.
> > It also had support for mlock in that version. Here is v2 and the relevant
> > conversation:
> > https://patchwork.freedesktop.org/patch/210992/?series=39879&rev=2
> >
> > >
> > > So what's the issue? Udma effectively pins pages longterm ("possibly
> > > forever") simply by grabbing a reference on them. These pages might
> > > easily reside in ZONE_MOVABLE or in MIGRATE_CMA pageblocks.
> > >
> > > So what udmabuf does is break memory hotunplug and CMA, because it
> > > turns
> > > pages that have to remain movable unmovable.
> > >
> > > In the pin_user_pages(FOLL_LONGTERM) case we make sure to migrate
> > > these
> > > pages. See mm/gup.c:check_and_migrate_movable_pages() and
> especially
> > > folio_is_longterm_pinnable(). We'd probably have to implement
> something
> > > similar for udmabuf, where we detect such unpinnable pages and
> migrate
> > > them.
> > The pages udmabuf pins are only those associated with Guest (GPU
> driver/virtio-gpu)
> > resources (or buffers allocated and pinned from shmem via drm GEM).
> Some
> > resources are short-lived, and some are long-lived and whenever a
> resource
> > gets destroyed, the pages are unpinned. And, not all resources have their
> pages
> > pinned. The resource that is pinned for the longest duration is the FB and
> that's
> > because it is updated every ~16ms (assuming 1920x1080@60) by the Guest
> > GPU driver. We can certainly pin/unpin the FB after it is accessed on the
> Host
> > as a workaround, but I guess that may not be very efficient given the
> amount
> > of churn it would create.
> >
> > Also, as far as migration or S3/S4 is concerned, my understanding is that all
> > the Guest resources are destroyed and recreated again. So, wouldn't
> something
> > similar happen during memory hotunplug?
> >
> > >
> > >
> > > For example, pairing udmabuf with vfio (which pins pages using
> > > pin_user_pages(FOLL_LONGTERM)) in QEMU will most probably not work
> in
> > > all cases: if udmabuf longterm pinned the pages "the wrong way", vfio
> > > will fail to migrate them during FOLL_LONGTERM and consequently fail
> > > pin_user_pages(). As long as udmabuf holds a reference on these pages,
> > > that will never succeed.
> > Dma-buf rules (for exporters) indicate that the pages only need to be
> pinned
> > during the map_attachment phase (and until unmap attachment happens).
> > In other words, only when the sg_table is created by udmabuf. I guess one
> > option would be to not hold any references during UDMABUF_CREATE and
> > only grab references to the pages (as and when it gets used) during this
> step.
> > Would this help?
>
> IIUC the refcount is needed, otherwise I don't see what to protect the page
> from being freed and even reused elsewhere before map_attachment().
>
> It seems the previous concern on using gup was majorly fork(), if this is it:
>
> https://patchwork.freedesktop.org/patch/210992/?series=39879&rev=2#co
> mment_414213
>
> Could it also be guarded by just making sure the pages are MAP_SHARED
> when
> creating the udmabuf, if fork() is a requirement of the feature?
>
> I had a feeling that the userspace still needs to always do the right thing
> to make it work, even using pure PFN mappings.
>
> For instance, what if the userapp just punchs a hole in the shmem/hugetlbfs
> file after creating the udmabuf (I see that F_SEAL_SHRINK is required, but
> at least not F_SEAL_WRITE with current impl), and fault a new page into the
> page cache?
IIUC, Qemu creates and owns the memfd that is associated with Guest memory.
And if it punches a hole in its own memfd that goes through Guest pinned pages
associated with buffers/resources, then I think the proper way to fix this is to
somehow notify the Guest driver (virtio-gpu in this case) that the backing store
of the affected resources is no longer valid and that the resources need to be
destroyed and re-created again.
Having said that, one option I could think of is to probably install a mmu_notifier
associated with the relevant pages in udmabuf and once we get notified about
any invalidation event concerning any of the pages, we'd fail any subsequent
attempt to access these pages and propagate the error across the stack.
However, it feels like udmabuf is not the right place to handle this issue because
there are very limited options for taking proper corrective action if Qemu decides
to punch a hole in Guest memory that takes out pages that are pinned.
Thanks,
Vivek
>
> Thanks,
>
> >
> > >
> > >
> > > There are *probably* more issues on the QEMU side when udmabuf is
> > > paired
> > > with things like MADV_DONTNEED/FALLOC_FL_PUNCH_HOLE used for
> > > virtio-balloon, virtio-mem, postcopy live migration, ... for example, in
> > > the vfio/vdpa case we make sure that we disallow most of these, because
> > > otherwise there can be an accidental "disconnect" between the pages
> > > mapped into the VM (guest view) and the pages mapped into the IOMMU
> > > (device view), for example, after a reboot.
> > Ok; I am not sure if I can figure out if there is any acceptable way to
> address
> > these issues but given the current constraints associated with udmabuf,
> what
> > do you suggest is the most reasonable way to deal with these problems you
> > have identified?
> >
> > Thanks,
> > Vivek
> >
> > >
> > > --
> > > Cheers,
> > >
> > > David / dhildenb
> >
>
> --
> Peter Xu
>
^ permalink raw reply [flat|nested] 46+ messages in thread* RE: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
@ 2023-06-26 7:45 ` Kasireddy, Vivek
0 siblings, 0 replies; 46+ messages in thread
From: Kasireddy, Vivek @ 2023-06-26 7:45 UTC (permalink / raw)
To: Peter Xu
Cc: David Hildenbrand, dri-devel@lists.freedesktop.org,
linux-mm@kvack.org, Mike Kravetz, Gerd Hoffmann, Kim, Dongwon,
Andrew Morton, James Houghton, Jerome Marchand, Chang, Junxiao,
Kirill A . Shutemov, Hocko, Michal, Muchun Song, Jason Gunthorpe,
John Hubbard
Hi Peter,
>
> On Fri, Jun 23, 2023 at 06:13:02AM +0000, Kasireddy, Vivek wrote:
> > Hi David,
> >
> > > > The first patch ensures that the mappings needed for handling mmap
> > > > operation would be managed by using the pfn instead of struct page.
> > > > The second patch restores support for mapping hugetlb pages where
> > > > subpages of a hugepage are not directly used anymore (main reason
> > > > for revert) and instead the hugetlb pages and the relevant offsets
> > > > are used to populate the scatterlist for dma-buf export and for
> > > > mmap operation.
> > > >
> > > > Testcase: default_hugepagesz=2M hugepagesz=2M hugepages=2500
> > > options
> > > > were passed to the Host kernel and Qemu was launched with these
> > > > relevant options: qemu-system-x86_64 -m 4096m....
> > > > -device virtio-gpu-pci,max_outputs=1,blob=true,xres=1920,yres=1080
> > > > -display gtk,gl=on
> > > > -object memory-backend-memfd,hugetlb=on,id=mem1,size=4096M
> > > > -machine memory-backend=mem1
> > > >
> > > > Replacing -display gtk,gl=on with -display gtk,gl=off above would
> > > > exercise the mmap handler.
> > > >
> > >
> > > While I think the VM_PFNMAP approach is much better and should fix
> that
> > > issue at hand, I thought more about missing memlock support and
> realized
> > > that we might have to fix something else. SO I'm going to raise the
> > > issue here.
> > >
> > > I think udmabuf chose the wrong interface to do what it's doing, that
> > > makes it harder to fix it eventually.
> > >
> > > Instead of accepting a range in a memfd, it should just have accepted a
> > > user space address range and then used
> > > pin_user_pages(FOLL_WRITE|FOLL_LONGTERM) to longterm-pin the
> pages
> > > "officially".
> > Udmabuf indeed started off by using user space address range and GUP
> but
> > the dma-buf subsystem maintainer had concerns with that approach in v2.
> > It also had support for mlock in that version. Here is v2 and the relevant
> > conversation:
> > https://patchwork.freedesktop.org/patch/210992/?series=39879&rev=2
> >
> > >
> > > So what's the issue? Udma effectively pins pages longterm ("possibly
> > > forever") simply by grabbing a reference on them. These pages might
> > > easily reside in ZONE_MOVABLE or in MIGRATE_CMA pageblocks.
> > >
> > > So what udmabuf does is break memory hotunplug and CMA, because it
> > > turns
> > > pages that have to remain movable unmovable.
> > >
> > > In the pin_user_pages(FOLL_LONGTERM) case we make sure to migrate
> > > these
> > > pages. See mm/gup.c:check_and_migrate_movable_pages() and
> especially
> > > folio_is_longterm_pinnable(). We'd probably have to implement
> something
> > > similar for udmabuf, where we detect such unpinnable pages and
> migrate
> > > them.
> > The pages udmabuf pins are only those associated with Guest (GPU
> driver/virtio-gpu)
> > resources (or buffers allocated and pinned from shmem via drm GEM).
> Some
> > resources are short-lived, and some are long-lived and whenever a
> resource
> > gets destroyed, the pages are unpinned. And, not all resources have their
> pages
> > pinned. The resource that is pinned for the longest duration is the FB and
> that's
> > because it is updated every ~16ms (assuming 1920x1080@60) by the Guest
> > GPU driver. We can certainly pin/unpin the FB after it is accessed on the
> Host
> > as a workaround, but I guess that may not be very efficient given the
> amount
> > of churn it would create.
> >
> > Also, as far as migration or S3/S4 is concerned, my understanding is that all
> > the Guest resources are destroyed and recreated again. So, wouldn't
> something
> > similar happen during memory hotunplug?
> >
> > >
> > >
> > > For example, pairing udmabuf with vfio (which pins pages using
> > > pin_user_pages(FOLL_LONGTERM)) in QEMU will most probably not work
> in
> > > all cases: if udmabuf longterm pinned the pages "the wrong way", vfio
> > > will fail to migrate them during FOLL_LONGTERM and consequently fail
> > > pin_user_pages(). As long as udmabuf holds a reference on these pages,
> > > that will never succeed.
> > Dma-buf rules (for exporters) indicate that the pages only need to be
> pinned
> > during the map_attachment phase (and until unmap attachment happens).
> > In other words, only when the sg_table is created by udmabuf. I guess one
> > option would be to not hold any references during UDMABUF_CREATE and
> > only grab references to the pages (as and when it gets used) during this
> step.
> > Would this help?
>
> IIUC the refcount is needed, otherwise I don't see what to protect the page
> from being freed and even reused elsewhere before map_attachment().
>
> It seems the previous concern on using gup was majorly fork(), if this is it:
>
> https://patchwork.freedesktop.org/patch/210992/?series=39879&rev=2#co
> mment_414213
>
> Could it also be guarded by just making sure the pages are MAP_SHARED
> when
> creating the udmabuf, if fork() is a requirement of the feature?
>
> I had a feeling that the userspace still needs to always do the right thing
> to make it work, even using pure PFN mappings.
>
> For instance, what if the userapp just punchs a hole in the shmem/hugetlbfs
> file after creating the udmabuf (I see that F_SEAL_SHRINK is required, but
> at least not F_SEAL_WRITE with current impl), and fault a new page into the
> page cache?
IIUC, Qemu creates and owns the memfd that is associated with Guest memory.
And if it punches a hole in its own memfd that goes through Guest pinned pages
associated with buffers/resources, then I think the proper way to fix this is to
somehow notify the Guest driver (virtio-gpu in this case) that the backing store
of the affected resources is no longer valid and that the resources need to be
destroyed and re-created again.
Having said that, one option I could think of is to probably install a mmu_notifier
associated with the relevant pages in udmabuf and once we get notified about
any invalidation event concerning any of the pages, we'd fail any subsequent
attempt to access these pages and propagate the error across the stack.
However, it feels like udmabuf is not the right place to handle this issue because
there are very limited options for taking proper corrective action if Qemu decides
to punch a hole in Guest memory that takes out pages that are pinned.
Thanks,
Vivek
>
> Thanks,
>
> >
> > >
> > >
> > > There are *probably* more issues on the QEMU side when udmabuf is
> > > paired
> > > with things like MADV_DONTNEED/FALLOC_FL_PUNCH_HOLE used for
> > > virtio-balloon, virtio-mem, postcopy live migration, ... for example, in
> > > the vfio/vdpa case we make sure that we disallow most of these, because
> > > otherwise there can be an accidental "disconnect" between the pages
> > > mapped into the VM (guest view) and the pages mapped into the IOMMU
> > > (device view), for example, after a reboot.
> > Ok; I am not sure if I can figure out if there is any acceptable way to
> address
> > these issues but given the current constraints associated with udmabuf,
> what
> > do you suggest is the most reasonable way to deal with these problems you
> > have identified?
> >
> > Thanks,
> > Vivek
> >
> > >
> > > --
> > > Cheers,
> > >
> > > David / dhildenb
> >
>
> --
> Peter Xu
>
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
2023-06-26 7:45 ` Kasireddy, Vivek
@ 2023-06-26 17:52 ` Peter Xu
-1 siblings, 0 replies; 46+ messages in thread
From: Peter Xu @ 2023-06-26 17:52 UTC (permalink / raw)
To: Kasireddy, Vivek
Cc: James Houghton, Jerome Marchand, Kim, Dongwon, David Hildenbrand,
Chang, Junxiao, Muchun Song, dri-devel@lists.freedesktop.org,
linux-mm@kvack.org, Hocko, Michal, Gerd Hoffmann, Jason Gunthorpe,
John Hubbard, Andrew Morton, Kirill A . Shutemov, Mike Kravetz
On Mon, Jun 26, 2023 at 07:45:37AM +0000, Kasireddy, Vivek wrote:
> Hi Peter,
>
> >
> > On Fri, Jun 23, 2023 at 06:13:02AM +0000, Kasireddy, Vivek wrote:
> > > Hi David,
> > >
> > > > > The first patch ensures that the mappings needed for handling mmap
> > > > > operation would be managed by using the pfn instead of struct page.
> > > > > The second patch restores support for mapping hugetlb pages where
> > > > > subpages of a hugepage are not directly used anymore (main reason
> > > > > for revert) and instead the hugetlb pages and the relevant offsets
> > > > > are used to populate the scatterlist for dma-buf export and for
> > > > > mmap operation.
> > > > >
> > > > > Testcase: default_hugepagesz=2M hugepagesz=2M hugepages=2500
> > > > options
> > > > > were passed to the Host kernel and Qemu was launched with these
> > > > > relevant options: qemu-system-x86_64 -m 4096m....
> > > > > -device virtio-gpu-pci,max_outputs=1,blob=true,xres=1920,yres=1080
> > > > > -display gtk,gl=on
> > > > > -object memory-backend-memfd,hugetlb=on,id=mem1,size=4096M
> > > > > -machine memory-backend=mem1
> > > > >
> > > > > Replacing -display gtk,gl=on with -display gtk,gl=off above would
> > > > > exercise the mmap handler.
> > > > >
> > > >
> > > > While I think the VM_PFNMAP approach is much better and should fix
> > that
> > > > issue at hand, I thought more about missing memlock support and
> > realized
> > > > that we might have to fix something else. SO I'm going to raise the
> > > > issue here.
> > > >
> > > > I think udmabuf chose the wrong interface to do what it's doing, that
> > > > makes it harder to fix it eventually.
> > > >
> > > > Instead of accepting a range in a memfd, it should just have accepted a
> > > > user space address range and then used
> > > > pin_user_pages(FOLL_WRITE|FOLL_LONGTERM) to longterm-pin the
> > pages
> > > > "officially".
> > > Udmabuf indeed started off by using user space address range and GUP
> > but
> > > the dma-buf subsystem maintainer had concerns with that approach in v2.
> > > It also had support for mlock in that version. Here is v2 and the relevant
> > > conversation:
> > > https://patchwork.freedesktop.org/patch/210992/?series=39879&rev=2
> > >
> > > >
> > > > So what's the issue? Udma effectively pins pages longterm ("possibly
> > > > forever") simply by grabbing a reference on them. These pages might
> > > > easily reside in ZONE_MOVABLE or in MIGRATE_CMA pageblocks.
> > > >
> > > > So what udmabuf does is break memory hotunplug and CMA, because it
> > > > turns
> > > > pages that have to remain movable unmovable.
> > > >
> > > > In the pin_user_pages(FOLL_LONGTERM) case we make sure to migrate
> > > > these
> > > > pages. See mm/gup.c:check_and_migrate_movable_pages() and
> > especially
> > > > folio_is_longterm_pinnable(). We'd probably have to implement
> > something
> > > > similar for udmabuf, where we detect such unpinnable pages and
> > migrate
> > > > them.
> > > The pages udmabuf pins are only those associated with Guest (GPU
> > driver/virtio-gpu)
> > > resources (or buffers allocated and pinned from shmem via drm GEM).
> > Some
> > > resources are short-lived, and some are long-lived and whenever a
> > resource
> > > gets destroyed, the pages are unpinned. And, not all resources have their
> > pages
> > > pinned. The resource that is pinned for the longest duration is the FB and
> > that's
> > > because it is updated every ~16ms (assuming 1920x1080@60) by the Guest
> > > GPU driver. We can certainly pin/unpin the FB after it is accessed on the
> > Host
> > > as a workaround, but I guess that may not be very efficient given the
> > amount
> > > of churn it would create.
> > >
> > > Also, as far as migration or S3/S4 is concerned, my understanding is that all
> > > the Guest resources are destroyed and recreated again. So, wouldn't
> > something
> > > similar happen during memory hotunplug?
> > >
> > > >
> > > >
> > > > For example, pairing udmabuf with vfio (which pins pages using
> > > > pin_user_pages(FOLL_LONGTERM)) in QEMU will most probably not work
> > in
> > > > all cases: if udmabuf longterm pinned the pages "the wrong way", vfio
> > > > will fail to migrate them during FOLL_LONGTERM and consequently fail
> > > > pin_user_pages(). As long as udmabuf holds a reference on these pages,
> > > > that will never succeed.
> > > Dma-buf rules (for exporters) indicate that the pages only need to be
> > pinned
> > > during the map_attachment phase (and until unmap attachment happens).
> > > In other words, only when the sg_table is created by udmabuf. I guess one
> > > option would be to not hold any references during UDMABUF_CREATE and
> > > only grab references to the pages (as and when it gets used) during this
> > step.
> > > Would this help?
> >
> > IIUC the refcount is needed, otherwise I don't see what to protect the page
> > from being freed and even reused elsewhere before map_attachment().
> >
> > It seems the previous concern on using gup was majorly fork(), if this is it:
> >
> > https://patchwork.freedesktop.org/patch/210992/?series=39879&rev=2#co
> > mment_414213
> >
> > Could it also be guarded by just making sure the pages are MAP_SHARED
> > when
> > creating the udmabuf, if fork() is a requirement of the feature?
> >
> > I had a feeling that the userspace still needs to always do the right thing
> > to make it work, even using pure PFN mappings.
> >
> > For instance, what if the userapp just punchs a hole in the shmem/hugetlbfs
> > file after creating the udmabuf (I see that F_SEAL_SHRINK is required, but
> > at least not F_SEAL_WRITE with current impl), and fault a new page into the
> > page cache?
> IIUC, Qemu creates and owns the memfd that is associated with Guest memory.
> And if it punches a hole in its own memfd that goes through Guest pinned pages
> associated with buffers/resources, then I think the proper way to fix this is to
> somehow notify the Guest driver (virtio-gpu in this case) that the backing store
> of the affected resources is no longer valid and that the resources need to be
> destroyed and re-created again.
>
> Having said that, one option I could think of is to probably install a mmu_notifier
> associated with the relevant pages in udmabuf and once we get notified about
> any invalidation event concerning any of the pages, we'd fail any subsequent
> attempt to access these pages and propagate the error across the stack.
Sounds right, maybe it needs to go back to the old GUP solution, though, as
mmu notifiers are also mm-based not fd-based. Or to be explicit, I think
it'll be pin_user_pages(FOLL_LONGTERM) with the new API. It'll also solve
the movable pages issue on pinning.
>
> However, it feels like udmabuf is not the right place to handle this issue because
> there are very limited options for taking proper corrective action if Qemu decides
> to punch a hole in Guest memory that takes out pages that are pinned.
I'm not familiar with the use case that much, but IMHO it's fine if the
driver relies on proper behaviors of userapp to work.
IIUC the worst case here is the udmabuf holds some pages that are not the
pages of the guest mem anymore, but it only happens on misbehaved
userspace, then it looks all fine as long as they can at least be properly
released when releasing the udmabuf. It'll be better if the udmabuf can
fail hard when detecting this, but IMHO even that can be optional depending
on the need, while any corrective action will be even one step further.
Thanks,
--
Peter Xu
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
@ 2023-06-26 17:52 ` Peter Xu
0 siblings, 0 replies; 46+ messages in thread
From: Peter Xu @ 2023-06-26 17:52 UTC (permalink / raw)
To: Kasireddy, Vivek
Cc: David Hildenbrand, dri-devel@lists.freedesktop.org,
linux-mm@kvack.org, Mike Kravetz, Gerd Hoffmann, Kim, Dongwon,
Andrew Morton, James Houghton, Jerome Marchand, Chang, Junxiao,
Kirill A . Shutemov, Hocko, Michal, Muchun Song, Jason Gunthorpe,
John Hubbard
On Mon, Jun 26, 2023 at 07:45:37AM +0000, Kasireddy, Vivek wrote:
> Hi Peter,
>
> >
> > On Fri, Jun 23, 2023 at 06:13:02AM +0000, Kasireddy, Vivek wrote:
> > > Hi David,
> > >
> > > > > The first patch ensures that the mappings needed for handling mmap
> > > > > operation would be managed by using the pfn instead of struct page.
> > > > > The second patch restores support for mapping hugetlb pages where
> > > > > subpages of a hugepage are not directly used anymore (main reason
> > > > > for revert) and instead the hugetlb pages and the relevant offsets
> > > > > are used to populate the scatterlist for dma-buf export and for
> > > > > mmap operation.
> > > > >
> > > > > Testcase: default_hugepagesz=2M hugepagesz=2M hugepages=2500
> > > > options
> > > > > were passed to the Host kernel and Qemu was launched with these
> > > > > relevant options: qemu-system-x86_64 -m 4096m....
> > > > > -device virtio-gpu-pci,max_outputs=1,blob=true,xres=1920,yres=1080
> > > > > -display gtk,gl=on
> > > > > -object memory-backend-memfd,hugetlb=on,id=mem1,size=4096M
> > > > > -machine memory-backend=mem1
> > > > >
> > > > > Replacing -display gtk,gl=on with -display gtk,gl=off above would
> > > > > exercise the mmap handler.
> > > > >
> > > >
> > > > While I think the VM_PFNMAP approach is much better and should fix
> > that
> > > > issue at hand, I thought more about missing memlock support and
> > realized
> > > > that we might have to fix something else. SO I'm going to raise the
> > > > issue here.
> > > >
> > > > I think udmabuf chose the wrong interface to do what it's doing, that
> > > > makes it harder to fix it eventually.
> > > >
> > > > Instead of accepting a range in a memfd, it should just have accepted a
> > > > user space address range and then used
> > > > pin_user_pages(FOLL_WRITE|FOLL_LONGTERM) to longterm-pin the
> > pages
> > > > "officially".
> > > Udmabuf indeed started off by using user space address range and GUP
> > but
> > > the dma-buf subsystem maintainer had concerns with that approach in v2.
> > > It also had support for mlock in that version. Here is v2 and the relevant
> > > conversation:
> > > https://patchwork.freedesktop.org/patch/210992/?series=39879&rev=2
> > >
> > > >
> > > > So what's the issue? Udma effectively pins pages longterm ("possibly
> > > > forever") simply by grabbing a reference on them. These pages might
> > > > easily reside in ZONE_MOVABLE or in MIGRATE_CMA pageblocks.
> > > >
> > > > So what udmabuf does is break memory hotunplug and CMA, because it
> > > > turns
> > > > pages that have to remain movable unmovable.
> > > >
> > > > In the pin_user_pages(FOLL_LONGTERM) case we make sure to migrate
> > > > these
> > > > pages. See mm/gup.c:check_and_migrate_movable_pages() and
> > especially
> > > > folio_is_longterm_pinnable(). We'd probably have to implement
> > something
> > > > similar for udmabuf, where we detect such unpinnable pages and
> > migrate
> > > > them.
> > > The pages udmabuf pins are only those associated with Guest (GPU
> > driver/virtio-gpu)
> > > resources (or buffers allocated and pinned from shmem via drm GEM).
> > Some
> > > resources are short-lived, and some are long-lived and whenever a
> > resource
> > > gets destroyed, the pages are unpinned. And, not all resources have their
> > pages
> > > pinned. The resource that is pinned for the longest duration is the FB and
> > that's
> > > because it is updated every ~16ms (assuming 1920x1080@60) by the Guest
> > > GPU driver. We can certainly pin/unpin the FB after it is accessed on the
> > Host
> > > as a workaround, but I guess that may not be very efficient given the
> > amount
> > > of churn it would create.
> > >
> > > Also, as far as migration or S3/S4 is concerned, my understanding is that all
> > > the Guest resources are destroyed and recreated again. So, wouldn't
> > something
> > > similar happen during memory hotunplug?
> > >
> > > >
> > > >
> > > > For example, pairing udmabuf with vfio (which pins pages using
> > > > pin_user_pages(FOLL_LONGTERM)) in QEMU will most probably not work
> > in
> > > > all cases: if udmabuf longterm pinned the pages "the wrong way", vfio
> > > > will fail to migrate them during FOLL_LONGTERM and consequently fail
> > > > pin_user_pages(). As long as udmabuf holds a reference on these pages,
> > > > that will never succeed.
> > > Dma-buf rules (for exporters) indicate that the pages only need to be
> > pinned
> > > during the map_attachment phase (and until unmap attachment happens).
> > > In other words, only when the sg_table is created by udmabuf. I guess one
> > > option would be to not hold any references during UDMABUF_CREATE and
> > > only grab references to the pages (as and when it gets used) during this
> > step.
> > > Would this help?
> >
> > IIUC the refcount is needed, otherwise I don't see what to protect the page
> > from being freed and even reused elsewhere before map_attachment().
> >
> > It seems the previous concern on using gup was majorly fork(), if this is it:
> >
> > https://patchwork.freedesktop.org/patch/210992/?series=39879&rev=2#co
> > mment_414213
> >
> > Could it also be guarded by just making sure the pages are MAP_SHARED
> > when
> > creating the udmabuf, if fork() is a requirement of the feature?
> >
> > I had a feeling that the userspace still needs to always do the right thing
> > to make it work, even using pure PFN mappings.
> >
> > For instance, what if the userapp just punchs a hole in the shmem/hugetlbfs
> > file after creating the udmabuf (I see that F_SEAL_SHRINK is required, but
> > at least not F_SEAL_WRITE with current impl), and fault a new page into the
> > page cache?
> IIUC, Qemu creates and owns the memfd that is associated with Guest memory.
> And if it punches a hole in its own memfd that goes through Guest pinned pages
> associated with buffers/resources, then I think the proper way to fix this is to
> somehow notify the Guest driver (virtio-gpu in this case) that the backing store
> of the affected resources is no longer valid and that the resources need to be
> destroyed and re-created again.
>
> Having said that, one option I could think of is to probably install a mmu_notifier
> associated with the relevant pages in udmabuf and once we get notified about
> any invalidation event concerning any of the pages, we'd fail any subsequent
> attempt to access these pages and propagate the error across the stack.
Sounds right, maybe it needs to go back to the old GUP solution, though, as
mmu notifiers are also mm-based not fd-based. Or to be explicit, I think
it'll be pin_user_pages(FOLL_LONGTERM) with the new API. It'll also solve
the movable pages issue on pinning.
>
> However, it feels like udmabuf is not the right place to handle this issue because
> there are very limited options for taking proper corrective action if Qemu decides
> to punch a hole in Guest memory that takes out pages that are pinned.
I'm not familiar with the use case that much, but IMHO it's fine if the
driver relies on proper behaviors of userapp to work.
IIUC the worst case here is the udmabuf holds some pages that are not the
pages of the guest mem anymore, but it only happens on misbehaved
userspace, then it looks all fine as long as they can at least be properly
released when releasing the udmabuf. It'll be better if the udmabuf can
fail hard when detecting this, but IMHO even that can be optional depending
on the need, while any corrective action will be even one step further.
Thanks,
--
Peter Xu
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
2023-06-26 17:52 ` Peter Xu
@ 2023-06-26 18:14 ` David Hildenbrand
-1 siblings, 0 replies; 46+ messages in thread
From: David Hildenbrand @ 2023-06-26 18:14 UTC (permalink / raw)
To: Peter Xu, Kasireddy, Vivek
Cc: James Houghton, Jerome Marchand, Kim, Dongwon, Chang, Junxiao,
Muchun Song, dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
Hocko, Michal, Gerd Hoffmann, Jason Gunthorpe, John Hubbard,
Andrew Morton, Kirill A . Shutemov, Mike Kravetz
On 26.06.23 19:52, Peter Xu wrote:
> On Mon, Jun 26, 2023 at 07:45:37AM +0000, Kasireddy, Vivek wrote:
>> Hi Peter,
>>
>>>
>>> On Fri, Jun 23, 2023 at 06:13:02AM +0000, Kasireddy, Vivek wrote:
>>>> Hi David,
>>>>
>>>>>> The first patch ensures that the mappings needed for handling mmap
>>>>>> operation would be managed by using the pfn instead of struct page.
>>>>>> The second patch restores support for mapping hugetlb pages where
>>>>>> subpages of a hugepage are not directly used anymore (main reason
>>>>>> for revert) and instead the hugetlb pages and the relevant offsets
>>>>>> are used to populate the scatterlist for dma-buf export and for
>>>>>> mmap operation.
>>>>>>
>>>>>> Testcase: default_hugepagesz=2M hugepagesz=2M hugepages=2500
>>>>> options
>>>>>> were passed to the Host kernel and Qemu was launched with these
>>>>>> relevant options: qemu-system-x86_64 -m 4096m....
>>>>>> -device virtio-gpu-pci,max_outputs=1,blob=true,xres=1920,yres=1080
>>>>>> -display gtk,gl=on
>>>>>> -object memory-backend-memfd,hugetlb=on,id=mem1,size=4096M
>>>>>> -machine memory-backend=mem1
>>>>>>
>>>>>> Replacing -display gtk,gl=on with -display gtk,gl=off above would
>>>>>> exercise the mmap handler.
>>>>>>
>>>>>
>>>>> While I think the VM_PFNMAP approach is much better and should fix
>>> that
>>>>> issue at hand, I thought more about missing memlock support and
>>> realized
>>>>> that we might have to fix something else. SO I'm going to raise the
>>>>> issue here.
>>>>>
>>>>> I think udmabuf chose the wrong interface to do what it's doing, that
>>>>> makes it harder to fix it eventually.
>>>>>
>>>>> Instead of accepting a range in a memfd, it should just have accepted a
>>>>> user space address range and then used
>>>>> pin_user_pages(FOLL_WRITE|FOLL_LONGTERM) to longterm-pin the
>>> pages
>>>>> "officially".
>>>> Udmabuf indeed started off by using user space address range and GUP
>>> but
>>>> the dma-buf subsystem maintainer had concerns with that approach in v2.
>>>> It also had support for mlock in that version. Here is v2 and the relevant
>>>> conversation:
>>>> https://patchwork.freedesktop.org/patch/210992/?series=39879&rev=2
>>>>
>>>>>
>>>>> So what's the issue? Udma effectively pins pages longterm ("possibly
>>>>> forever") simply by grabbing a reference on them. These pages might
>>>>> easily reside in ZONE_MOVABLE or in MIGRATE_CMA pageblocks.
>>>>>
>>>>> So what udmabuf does is break memory hotunplug and CMA, because it
>>>>> turns
>>>>> pages that have to remain movable unmovable.
>>>>>
>>>>> In the pin_user_pages(FOLL_LONGTERM) case we make sure to migrate
>>>>> these
>>>>> pages. See mm/gup.c:check_and_migrate_movable_pages() and
>>> especially
>>>>> folio_is_longterm_pinnable(). We'd probably have to implement
>>> something
>>>>> similar for udmabuf, where we detect such unpinnable pages and
>>> migrate
>>>>> them.
>>>> The pages udmabuf pins are only those associated with Guest (GPU
>>> driver/virtio-gpu)
>>>> resources (or buffers allocated and pinned from shmem via drm GEM).
>>> Some
>>>> resources are short-lived, and some are long-lived and whenever a
>>> resource
>>>> gets destroyed, the pages are unpinned. And, not all resources have their
>>> pages
>>>> pinned. The resource that is pinned for the longest duration is the FB and
>>> that's
>>>> because it is updated every ~16ms (assuming 1920x1080@60) by the Guest
>>>> GPU driver. We can certainly pin/unpin the FB after it is accessed on the
>>> Host
>>>> as a workaround, but I guess that may not be very efficient given the
>>> amount
>>>> of churn it would create.
>>>>
>>>> Also, as far as migration or S3/S4 is concerned, my understanding is that all
>>>> the Guest resources are destroyed and recreated again. So, wouldn't
>>> something
>>>> similar happen during memory hotunplug?
>>>>
>>>>>
>>>>>
>>>>> For example, pairing udmabuf with vfio (which pins pages using
>>>>> pin_user_pages(FOLL_LONGTERM)) in QEMU will most probably not work
>>> in
>>>>> all cases: if udmabuf longterm pinned the pages "the wrong way", vfio
>>>>> will fail to migrate them during FOLL_LONGTERM and consequently fail
>>>>> pin_user_pages(). As long as udmabuf holds a reference on these pages,
>>>>> that will never succeed.
>>>> Dma-buf rules (for exporters) indicate that the pages only need to be
>>> pinned
>>>> during the map_attachment phase (and until unmap attachment happens).
>>>> In other words, only when the sg_table is created by udmabuf. I guess one
>>>> option would be to not hold any references during UDMABUF_CREATE and
>>>> only grab references to the pages (as and when it gets used) during this
>>> step.
>>>> Would this help?
>>>
>>> IIUC the refcount is needed, otherwise I don't see what to protect the page
>>> from being freed and even reused elsewhere before map_attachment().
>>>
>>> It seems the previous concern on using gup was majorly fork(), if this is it:
>>>
>>> https://patchwork.freedesktop.org/patch/210992/?series=39879&rev=2#co
>>> mment_414213
>>>
>>> Could it also be guarded by just making sure the pages are MAP_SHARED
>>> when
>>> creating the udmabuf, if fork() is a requirement of the feature?
>>>
>>> I had a feeling that the userspace still needs to always do the right thing
>>> to make it work, even using pure PFN mappings.
>>>
>>> For instance, what if the userapp just punchs a hole in the shmem/hugetlbfs
>>> file after creating the udmabuf (I see that F_SEAL_SHRINK is required, but
>>> at least not F_SEAL_WRITE with current impl), and fault a new page into the
>>> page cache?
>> IIUC, Qemu creates and owns the memfd that is associated with Guest memory.
>> And if it punches a hole in its own memfd that goes through Guest pinned pages
>> associated with buffers/resources, then I think the proper way to fix this is to
>> somehow notify the Guest driver (virtio-gpu in this case) that the backing store
>> of the affected resources is no longer valid and that the resources need to be
>> destroyed and re-created again.
>>
>> Having said that, one option I could think of is to probably install a mmu_notifier
>> associated with the relevant pages in udmabuf and once we get notified about
>> any invalidation event concerning any of the pages, we'd fail any subsequent
>> attempt to access these pages and propagate the error across the stack.
>
> Sounds right, maybe it needs to go back to the old GUP solution, though, as
> mmu notifiers are also mm-based not fd-based. Or to be explicit, I think
> it'll be pin_user_pages(FOLL_LONGTERM) with the new API. It'll also solve
> the movable pages issue on pinning.
It better should be pin_user_pages(FOLL_LONGTERM). But I'm afraid we
cannot achieve that without breaking the existing kernel interface ...
So we might have to implement the same page migration as gup does on
FOLL_LONGTERM here ... maybe there are more such cases/drivers that
actually require that handling when simply taking pages out of the
memfd, believing they can hold on to them forever.
>
>>
>> However, it feels like udmabuf is not the right place to handle this issue because
>> there are very limited options for taking proper corrective action if Qemu decides
>> to punch a hole in Guest memory that takes out pages that are pinned.
>
> I'm not familiar with the use case that much, but IMHO it's fine if the
> driver relies on proper behaviors of userapp to work.
>
> IIUC the worst case here is the udmabuf holds some pages that are not the
> pages of the guest mem anymore, but it only happens on misbehaved
> userspace, then it looks all fine as long as they can at least be properly
> released when releasing the udmabuf. It'll be better if the udmabuf can
> fail hard when detecting this, but IMHO even that can be optional depending
> on the need, while any corrective action will be even one step further.
For vfio the issue are e.g., VM reboots, not a misbehaving guest. If the
old guest kernel inflated the balloon and we reboot the VM, VFIO will
still reference the old pages and the new (unaware kernel) might use
that previously inflated memory to communicate with the devices. Because
of that, we disable balloon inflation when vfio is active in QEMU.
[there are more cases like unloading the balloon driver or deflating the
balloon, and then using that memory for communicating with the device]
Maybe it's all fine with udmabuf because of the way it is setup/torn
down by the guest driver. Unfortunately I can't tell.
--
Cheers,
David / dhildenb
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
@ 2023-06-26 18:14 ` David Hildenbrand
0 siblings, 0 replies; 46+ messages in thread
From: David Hildenbrand @ 2023-06-26 18:14 UTC (permalink / raw)
To: Peter Xu, Kasireddy, Vivek
Cc: dri-devel@lists.freedesktop.org, linux-mm@kvack.org, Mike Kravetz,
Gerd Hoffmann, Kim, Dongwon, Andrew Morton, James Houghton,
Jerome Marchand, Chang, Junxiao, Kirill A . Shutemov,
Hocko, Michal, Muchun Song, Jason Gunthorpe, John Hubbard
On 26.06.23 19:52, Peter Xu wrote:
> On Mon, Jun 26, 2023 at 07:45:37AM +0000, Kasireddy, Vivek wrote:
>> Hi Peter,
>>
>>>
>>> On Fri, Jun 23, 2023 at 06:13:02AM +0000, Kasireddy, Vivek wrote:
>>>> Hi David,
>>>>
>>>>>> The first patch ensures that the mappings needed for handling mmap
>>>>>> operation would be managed by using the pfn instead of struct page.
>>>>>> The second patch restores support for mapping hugetlb pages where
>>>>>> subpages of a hugepage are not directly used anymore (main reason
>>>>>> for revert) and instead the hugetlb pages and the relevant offsets
>>>>>> are used to populate the scatterlist for dma-buf export and for
>>>>>> mmap operation.
>>>>>>
>>>>>> Testcase: default_hugepagesz=2M hugepagesz=2M hugepages=2500
>>>>> options
>>>>>> were passed to the Host kernel and Qemu was launched with these
>>>>>> relevant options: qemu-system-x86_64 -m 4096m....
>>>>>> -device virtio-gpu-pci,max_outputs=1,blob=true,xres=1920,yres=1080
>>>>>> -display gtk,gl=on
>>>>>> -object memory-backend-memfd,hugetlb=on,id=mem1,size=4096M
>>>>>> -machine memory-backend=mem1
>>>>>>
>>>>>> Replacing -display gtk,gl=on with -display gtk,gl=off above would
>>>>>> exercise the mmap handler.
>>>>>>
>>>>>
>>>>> While I think the VM_PFNMAP approach is much better and should fix
>>> that
>>>>> issue at hand, I thought more about missing memlock support and
>>> realized
>>>>> that we might have to fix something else. SO I'm going to raise the
>>>>> issue here.
>>>>>
>>>>> I think udmabuf chose the wrong interface to do what it's doing, that
>>>>> makes it harder to fix it eventually.
>>>>>
>>>>> Instead of accepting a range in a memfd, it should just have accepted a
>>>>> user space address range and then used
>>>>> pin_user_pages(FOLL_WRITE|FOLL_LONGTERM) to longterm-pin the
>>> pages
>>>>> "officially".
>>>> Udmabuf indeed started off by using user space address range and GUP
>>> but
>>>> the dma-buf subsystem maintainer had concerns with that approach in v2.
>>>> It also had support for mlock in that version. Here is v2 and the relevant
>>>> conversation:
>>>> https://patchwork.freedesktop.org/patch/210992/?series=39879&rev=2
>>>>
>>>>>
>>>>> So what's the issue? Udma effectively pins pages longterm ("possibly
>>>>> forever") simply by grabbing a reference on them. These pages might
>>>>> easily reside in ZONE_MOVABLE or in MIGRATE_CMA pageblocks.
>>>>>
>>>>> So what udmabuf does is break memory hotunplug and CMA, because it
>>>>> turns
>>>>> pages that have to remain movable unmovable.
>>>>>
>>>>> In the pin_user_pages(FOLL_LONGTERM) case we make sure to migrate
>>>>> these
>>>>> pages. See mm/gup.c:check_and_migrate_movable_pages() and
>>> especially
>>>>> folio_is_longterm_pinnable(). We'd probably have to implement
>>> something
>>>>> similar for udmabuf, where we detect such unpinnable pages and
>>> migrate
>>>>> them.
>>>> The pages udmabuf pins are only those associated with Guest (GPU
>>> driver/virtio-gpu)
>>>> resources (or buffers allocated and pinned from shmem via drm GEM).
>>> Some
>>>> resources are short-lived, and some are long-lived and whenever a
>>> resource
>>>> gets destroyed, the pages are unpinned. And, not all resources have their
>>> pages
>>>> pinned. The resource that is pinned for the longest duration is the FB and
>>> that's
>>>> because it is updated every ~16ms (assuming 1920x1080@60) by the Guest
>>>> GPU driver. We can certainly pin/unpin the FB after it is accessed on the
>>> Host
>>>> as a workaround, but I guess that may not be very efficient given the
>>> amount
>>>> of churn it would create.
>>>>
>>>> Also, as far as migration or S3/S4 is concerned, my understanding is that all
>>>> the Guest resources are destroyed and recreated again. So, wouldn't
>>> something
>>>> similar happen during memory hotunplug?
>>>>
>>>>>
>>>>>
>>>>> For example, pairing udmabuf with vfio (which pins pages using
>>>>> pin_user_pages(FOLL_LONGTERM)) in QEMU will most probably not work
>>> in
>>>>> all cases: if udmabuf longterm pinned the pages "the wrong way", vfio
>>>>> will fail to migrate them during FOLL_LONGTERM and consequently fail
>>>>> pin_user_pages(). As long as udmabuf holds a reference on these pages,
>>>>> that will never succeed.
>>>> Dma-buf rules (for exporters) indicate that the pages only need to be
>>> pinned
>>>> during the map_attachment phase (and until unmap attachment happens).
>>>> In other words, only when the sg_table is created by udmabuf. I guess one
>>>> option would be to not hold any references during UDMABUF_CREATE and
>>>> only grab references to the pages (as and when it gets used) during this
>>> step.
>>>> Would this help?
>>>
>>> IIUC the refcount is needed, otherwise I don't see what to protect the page
>>> from being freed and even reused elsewhere before map_attachment().
>>>
>>> It seems the previous concern on using gup was majorly fork(), if this is it:
>>>
>>> https://patchwork.freedesktop.org/patch/210992/?series=39879&rev=2#co
>>> mment_414213
>>>
>>> Could it also be guarded by just making sure the pages are MAP_SHARED
>>> when
>>> creating the udmabuf, if fork() is a requirement of the feature?
>>>
>>> I had a feeling that the userspace still needs to always do the right thing
>>> to make it work, even using pure PFN mappings.
>>>
>>> For instance, what if the userapp just punchs a hole in the shmem/hugetlbfs
>>> file after creating the udmabuf (I see that F_SEAL_SHRINK is required, but
>>> at least not F_SEAL_WRITE with current impl), and fault a new page into the
>>> page cache?
>> IIUC, Qemu creates and owns the memfd that is associated with Guest memory.
>> And if it punches a hole in its own memfd that goes through Guest pinned pages
>> associated with buffers/resources, then I think the proper way to fix this is to
>> somehow notify the Guest driver (virtio-gpu in this case) that the backing store
>> of the affected resources is no longer valid and that the resources need to be
>> destroyed and re-created again.
>>
>> Having said that, one option I could think of is to probably install a mmu_notifier
>> associated with the relevant pages in udmabuf and once we get notified about
>> any invalidation event concerning any of the pages, we'd fail any subsequent
>> attempt to access these pages and propagate the error across the stack.
>
> Sounds right, maybe it needs to go back to the old GUP solution, though, as
> mmu notifiers are also mm-based not fd-based. Or to be explicit, I think
> it'll be pin_user_pages(FOLL_LONGTERM) with the new API. It'll also solve
> the movable pages issue on pinning.
It better should be pin_user_pages(FOLL_LONGTERM). But I'm afraid we
cannot achieve that without breaking the existing kernel interface ...
So we might have to implement the same page migration as gup does on
FOLL_LONGTERM here ... maybe there are more such cases/drivers that
actually require that handling when simply taking pages out of the
memfd, believing they can hold on to them forever.
>
>>
>> However, it feels like udmabuf is not the right place to handle this issue because
>> there are very limited options for taking proper corrective action if Qemu decides
>> to punch a hole in Guest memory that takes out pages that are pinned.
>
> I'm not familiar with the use case that much, but IMHO it's fine if the
> driver relies on proper behaviors of userapp to work.
>
> IIUC the worst case here is the udmabuf holds some pages that are not the
> pages of the guest mem anymore, but it only happens on misbehaved
> userspace, then it looks all fine as long as they can at least be properly
> released when releasing the udmabuf. It'll be better if the udmabuf can
> fail hard when detecting this, but IMHO even that can be optional depending
> on the need, while any corrective action will be even one step further.
For vfio the issue are e.g., VM reboots, not a misbehaving guest. If the
old guest kernel inflated the balloon and we reboot the VM, VFIO will
still reference the old pages and the new (unaware kernel) might use
that previously inflated memory to communicate with the devices. Because
of that, we disable balloon inflation when vfio is active in QEMU.
[there are more cases like unloading the balloon driver or deflating the
balloon, and then using that memory for communicating with the device]
Maybe it's all fine with udmabuf because of the way it is setup/torn
down by the guest driver. Unfortunately I can't tell.
--
Cheers,
David / dhildenb
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
2023-06-26 18:14 ` David Hildenbrand
@ 2023-06-26 18:18 ` Jason Gunthorpe
-1 siblings, 0 replies; 46+ messages in thread
From: Jason Gunthorpe @ 2023-06-26 18:18 UTC (permalink / raw)
To: David Hildenbrand
Cc: James Houghton, Jerome Marchand, Kim, Dongwon, Chang, Junxiao,
Muchun Song, Kasireddy, Vivek, dri-devel@lists.freedesktop.org,
linux-mm@kvack.org, Peter Xu, Hocko, Michal, Gerd Hoffmann,
John Hubbard, Andrew Morton, Kirill A . Shutemov, Mike Kravetz
On Mon, Jun 26, 2023 at 08:14:27PM +0200, David Hildenbrand wrote:
> So we might have to implement the same page migration as gup does on
> FOLL_LONGTERM here ... maybe there are more such cases/drivers that actually
> require that handling when simply taking pages out of the memfd, believing
> they can hold on to them forever.
In general I would like to see an interface to FOLL_LONGTERM pin pages
from a memfd. I would quite happily use that in iommufd as well.
It solves some problems we have there with fork/exec/etc if the pages
are not linked to a mm_struct.
Jason
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
@ 2023-06-26 18:18 ` Jason Gunthorpe
0 siblings, 0 replies; 46+ messages in thread
From: Jason Gunthorpe @ 2023-06-26 18:18 UTC (permalink / raw)
To: David Hildenbrand
Cc: Peter Xu, Kasireddy, Vivek, dri-devel@lists.freedesktop.org,
linux-mm@kvack.org, Mike Kravetz, Gerd Hoffmann, Kim, Dongwon,
Andrew Morton, James Houghton, Jerome Marchand, Chang, Junxiao,
Kirill A . Shutemov, Hocko, Michal, Muchun Song, John Hubbard
On Mon, Jun 26, 2023 at 08:14:27PM +0200, David Hildenbrand wrote:
> So we might have to implement the same page migration as gup does on
> FOLL_LONGTERM here ... maybe there are more such cases/drivers that actually
> require that handling when simply taking pages out of the memfd, believing
> they can hold on to them forever.
In general I would like to see an interface to FOLL_LONGTERM pin pages
from a memfd. I would quite happily use that in iommufd as well.
It solves some problems we have there with fork/exec/etc if the pages
are not linked to a mm_struct.
Jason
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
2023-06-26 18:18 ` Jason Gunthorpe
@ 2023-06-26 19:04 ` Peter Xu
-1 siblings, 0 replies; 46+ messages in thread
From: Peter Xu @ 2023-06-26 19:04 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: James Houghton, Jerome Marchand, Kim, Dongwon, David Hildenbrand,
Chang, Junxiao, Muchun Song, Kasireddy, Vivek,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
Hocko, Michal, Gerd Hoffmann, John Hubbard, Andrew Morton,
Kirill A . Shutemov, Mike Kravetz
On Mon, Jun 26, 2023 at 03:18:48PM -0300, Jason Gunthorpe wrote:
> On Mon, Jun 26, 2023 at 08:14:27PM +0200, David Hildenbrand wrote:
>
> > So we might have to implement the same page migration as gup does on
> > FOLL_LONGTERM here ... maybe there are more such cases/drivers that actually
> > require that handling when simply taking pages out of the memfd, believing
> > they can hold on to them forever.
>
> In general I would like to see an interface to FOLL_LONGTERM pin pages
> from a memfd. I would quite happily use that in iommufd as well.
>
> It solves some problems we have there with fork/exec/etc if the pages
> are not linked to a mm_struct.
Afaiu any fd based approach should mean it'll never work with private
memories, while mm-based should be able to work on any kind. Maybe that's
not a problem - I assume at least udmabuf should just only work with shared
memories; not sure on iommufd, though.
--
Peter Xu
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
@ 2023-06-26 19:04 ` Peter Xu
0 siblings, 0 replies; 46+ messages in thread
From: Peter Xu @ 2023-06-26 19:04 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: David Hildenbrand, Kasireddy, Vivek,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org, Mike Kravetz,
Gerd Hoffmann, Kim, Dongwon, Andrew Morton, James Houghton,
Jerome Marchand, Chang, Junxiao, Kirill A . Shutemov,
Hocko, Michal, Muchun Song, John Hubbard
On Mon, Jun 26, 2023 at 03:18:48PM -0300, Jason Gunthorpe wrote:
> On Mon, Jun 26, 2023 at 08:14:27PM +0200, David Hildenbrand wrote:
>
> > So we might have to implement the same page migration as gup does on
> > FOLL_LONGTERM here ... maybe there are more such cases/drivers that actually
> > require that handling when simply taking pages out of the memfd, believing
> > they can hold on to them forever.
>
> In general I would like to see an interface to FOLL_LONGTERM pin pages
> from a memfd. I would quite happily use that in iommufd as well.
>
> It solves some problems we have there with fork/exec/etc if the pages
> are not linked to a mm_struct.
Afaiu any fd based approach should mean it'll never work with private
memories, while mm-based should be able to work on any kind. Maybe that's
not a problem - I assume at least udmabuf should just only work with shared
memories; not sure on iommufd, though.
--
Peter Xu
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
2023-06-26 19:04 ` Peter Xu
@ 2023-06-27 15:52 ` Jason Gunthorpe
-1 siblings, 0 replies; 46+ messages in thread
From: Jason Gunthorpe @ 2023-06-27 15:52 UTC (permalink / raw)
To: Peter Xu
Cc: James Houghton, Jerome Marchand, Kim, Dongwon, David Hildenbrand,
Chang, Junxiao, Muchun Song, Kasireddy, Vivek,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
Hocko, Michal, Gerd Hoffmann, John Hubbard, Andrew Morton,
Kirill A . Shutemov, Mike Kravetz
On Mon, Jun 26, 2023 at 03:04:21PM -0400, Peter Xu wrote:
> On Mon, Jun 26, 2023 at 03:18:48PM -0300, Jason Gunthorpe wrote:
> > On Mon, Jun 26, 2023 at 08:14:27PM +0200, David Hildenbrand wrote:
> >
> > > So we might have to implement the same page migration as gup does on
> > > FOLL_LONGTERM here ... maybe there are more such cases/drivers that actually
> > > require that handling when simply taking pages out of the memfd, believing
> > > they can hold on to them forever.
> >
> > In general I would like to see an interface to FOLL_LONGTERM pin pages
> > from a memfd. I would quite happily use that in iommufd as well.
> >
> > It solves some problems we have there with fork/exec/etc if the pages
> > are not linked to a mm_struct.
>
> Afaiu any fd based approach should mean it'll never work with private
> memories, while mm-based should be able to work on any kind.
Is there a significant use case to open a memfd and then use
MAP_PRIVATE? Why would anyone want to do that instead of just using
normal mmap anonymous memory?
Jason
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
@ 2023-06-27 15:52 ` Jason Gunthorpe
0 siblings, 0 replies; 46+ messages in thread
From: Jason Gunthorpe @ 2023-06-27 15:52 UTC (permalink / raw)
To: Peter Xu
Cc: David Hildenbrand, Kasireddy, Vivek,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org, Mike Kravetz,
Gerd Hoffmann, Kim, Dongwon, Andrew Morton, James Houghton,
Jerome Marchand, Chang, Junxiao, Kirill A . Shutemov,
Hocko, Michal, Muchun Song, John Hubbard
On Mon, Jun 26, 2023 at 03:04:21PM -0400, Peter Xu wrote:
> On Mon, Jun 26, 2023 at 03:18:48PM -0300, Jason Gunthorpe wrote:
> > On Mon, Jun 26, 2023 at 08:14:27PM +0200, David Hildenbrand wrote:
> >
> > > So we might have to implement the same page migration as gup does on
> > > FOLL_LONGTERM here ... maybe there are more such cases/drivers that actually
> > > require that handling when simply taking pages out of the memfd, believing
> > > they can hold on to them forever.
> >
> > In general I would like to see an interface to FOLL_LONGTERM pin pages
> > from a memfd. I would quite happily use that in iommufd as well.
> >
> > It solves some problems we have there with fork/exec/etc if the pages
> > are not linked to a mm_struct.
>
> Afaiu any fd based approach should mean it'll never work with private
> memories, while mm-based should be able to work on any kind.
Is there a significant use case to open a memfd and then use
MAP_PRIVATE? Why would anyone want to do that instead of just using
normal mmap anonymous memory?
Jason
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
2023-06-27 15:52 ` Jason Gunthorpe
@ 2023-06-27 16:00 ` Peter Xu
-1 siblings, 0 replies; 46+ messages in thread
From: Peter Xu @ 2023-06-27 16:00 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: James Houghton, Jerome Marchand, Kim, Dongwon, David Hildenbrand,
Chang, Junxiao, Muchun Song, Kasireddy, Vivek,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
Hocko, Michal, Gerd Hoffmann, John Hubbard, Andrew Morton,
Kirill A . Shutemov, Mike Kravetz
On Tue, Jun 27, 2023 at 12:52:34PM -0300, Jason Gunthorpe wrote:
> On Mon, Jun 26, 2023 at 03:04:21PM -0400, Peter Xu wrote:
> > On Mon, Jun 26, 2023 at 03:18:48PM -0300, Jason Gunthorpe wrote:
> > > On Mon, Jun 26, 2023 at 08:14:27PM +0200, David Hildenbrand wrote:
> > >
> > > > So we might have to implement the same page migration as gup does on
> > > > FOLL_LONGTERM here ... maybe there are more such cases/drivers that actually
> > > > require that handling when simply taking pages out of the memfd, believing
> > > > they can hold on to them forever.
> > >
> > > In general I would like to see an interface to FOLL_LONGTERM pin pages
> > > from a memfd. I would quite happily use that in iommufd as well.
> > >
> > > It solves some problems we have there with fork/exec/etc if the pages
> > > are not linked to a mm_struct.
> >
> > Afaiu any fd based approach should mean it'll never work with private
> > memories, while mm-based should be able to work on any kind.
>
> Is there a significant use case to open a memfd and then use
> MAP_PRIVATE? Why would anyone want to do that instead of just using
> normal mmap anonymous memory?
I remember David Hildenbrand somewhere mentioned the use case where one
wants to snapshot a VM RAM into a file, then start multiple instances by
loading that VM RAM with MAP_PRIVATE, so it clones a bunch of snapshoted VM
running with a single RAM file shared as a template. Not a generic use
case, I guess.
My question applies not only memfd but also in general - qemu by default
doesn't use memfd afaict, so it boils down to e.g. whether you'll target
the iommufd project to work in that case, where qemu uses anonymous memory.
Privately mapped file memory is only one of those kinds.
--
Peter Xu
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
@ 2023-06-27 16:00 ` Peter Xu
0 siblings, 0 replies; 46+ messages in thread
From: Peter Xu @ 2023-06-27 16:00 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: David Hildenbrand, Kasireddy, Vivek,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org, Mike Kravetz,
Gerd Hoffmann, Kim, Dongwon, Andrew Morton, James Houghton,
Jerome Marchand, Chang, Junxiao, Kirill A . Shutemov,
Hocko, Michal, Muchun Song, John Hubbard
On Tue, Jun 27, 2023 at 12:52:34PM -0300, Jason Gunthorpe wrote:
> On Mon, Jun 26, 2023 at 03:04:21PM -0400, Peter Xu wrote:
> > On Mon, Jun 26, 2023 at 03:18:48PM -0300, Jason Gunthorpe wrote:
> > > On Mon, Jun 26, 2023 at 08:14:27PM +0200, David Hildenbrand wrote:
> > >
> > > > So we might have to implement the same page migration as gup does on
> > > > FOLL_LONGTERM here ... maybe there are more such cases/drivers that actually
> > > > require that handling when simply taking pages out of the memfd, believing
> > > > they can hold on to them forever.
> > >
> > > In general I would like to see an interface to FOLL_LONGTERM pin pages
> > > from a memfd. I would quite happily use that in iommufd as well.
> > >
> > > It solves some problems we have there with fork/exec/etc if the pages
> > > are not linked to a mm_struct.
> >
> > Afaiu any fd based approach should mean it'll never work with private
> > memories, while mm-based should be able to work on any kind.
>
> Is there a significant use case to open a memfd and then use
> MAP_PRIVATE? Why would anyone want to do that instead of just using
> normal mmap anonymous memory?
I remember David Hildenbrand somewhere mentioned the use case where one
wants to snapshot a VM RAM into a file, then start multiple instances by
loading that VM RAM with MAP_PRIVATE, so it clones a bunch of snapshoted VM
running with a single RAM file shared as a template. Not a generic use
case, I guess.
My question applies not only memfd but also in general - qemu by default
doesn't use memfd afaict, so it boils down to e.g. whether you'll target
the iommufd project to work in that case, where qemu uses anonymous memory.
Privately mapped file memory is only one of those kinds.
--
Peter Xu
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
2023-06-27 16:00 ` Peter Xu
@ 2023-06-27 16:04 ` Jason Gunthorpe
-1 siblings, 0 replies; 46+ messages in thread
From: Jason Gunthorpe @ 2023-06-27 16:04 UTC (permalink / raw)
To: Peter Xu
Cc: James Houghton, Jerome Marchand, Kim, Dongwon, David Hildenbrand,
Chang, Junxiao, Muchun Song, Kasireddy, Vivek,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
Hocko, Michal, Gerd Hoffmann, John Hubbard, Andrew Morton,
Kirill A . Shutemov, Mike Kravetz
On Tue, Jun 27, 2023 at 12:00:38PM -0400, Peter Xu wrote:
> On Tue, Jun 27, 2023 at 12:52:34PM -0300, Jason Gunthorpe wrote:
> > On Mon, Jun 26, 2023 at 03:04:21PM -0400, Peter Xu wrote:
> > > On Mon, Jun 26, 2023 at 03:18:48PM -0300, Jason Gunthorpe wrote:
> > > > On Mon, Jun 26, 2023 at 08:14:27PM +0200, David Hildenbrand wrote:
> > > >
> > > > > So we might have to implement the same page migration as gup does on
> > > > > FOLL_LONGTERM here ... maybe there are more such cases/drivers that actually
> > > > > require that handling when simply taking pages out of the memfd, believing
> > > > > they can hold on to them forever.
> > > >
> > > > In general I would like to see an interface to FOLL_LONGTERM pin pages
> > > > from a memfd. I would quite happily use that in iommufd as well.
> > > >
> > > > It solves some problems we have there with fork/exec/etc if the pages
> > > > are not linked to a mm_struct.
> > >
> > > Afaiu any fd based approach should mean it'll never work with private
> > > memories, while mm-based should be able to work on any kind.
> >
> > Is there a significant use case to open a memfd and then use
> > MAP_PRIVATE? Why would anyone want to do that instead of just using
> > normal mmap anonymous memory?
>
> I remember David Hildenbrand somewhere mentioned the use case where one
> wants to snapshot a VM RAM into a file, then start multiple instances by
> loading that VM RAM with MAP_PRIVATE, so it clones a bunch of snapshoted VM
> running with a single RAM file shared as a template. Not a generic use
> case, I guess.
A file I can see, but a file is not a memfd, we are talking
specifically about memfd, aren't we?
> My question applies not only memfd but also in general - qemu by default
> doesn't use memfd afaict, so it boils down to e.g. whether you'll target
> the iommufd project to work in that case, where qemu uses anonymous
> memory.
I think this may change, as I understand it, the approach for
confidential compute is to put the guest memory in a memfd...
> Privately mapped file memory is only one of those kinds.
I think memfd and related shmem-like objects are a reasonable target. We
already know we should not FOLL_LONGTERM pin file backed pages.
Jason
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
@ 2023-06-27 16:04 ` Jason Gunthorpe
0 siblings, 0 replies; 46+ messages in thread
From: Jason Gunthorpe @ 2023-06-27 16:04 UTC (permalink / raw)
To: Peter Xu
Cc: David Hildenbrand, Kasireddy, Vivek,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org, Mike Kravetz,
Gerd Hoffmann, Kim, Dongwon, Andrew Morton, James Houghton,
Jerome Marchand, Chang, Junxiao, Kirill A . Shutemov,
Hocko, Michal, Muchun Song, John Hubbard
On Tue, Jun 27, 2023 at 12:00:38PM -0400, Peter Xu wrote:
> On Tue, Jun 27, 2023 at 12:52:34PM -0300, Jason Gunthorpe wrote:
> > On Mon, Jun 26, 2023 at 03:04:21PM -0400, Peter Xu wrote:
> > > On Mon, Jun 26, 2023 at 03:18:48PM -0300, Jason Gunthorpe wrote:
> > > > On Mon, Jun 26, 2023 at 08:14:27PM +0200, David Hildenbrand wrote:
> > > >
> > > > > So we might have to implement the same page migration as gup does on
> > > > > FOLL_LONGTERM here ... maybe there are more such cases/drivers that actually
> > > > > require that handling when simply taking pages out of the memfd, believing
> > > > > they can hold on to them forever.
> > > >
> > > > In general I would like to see an interface to FOLL_LONGTERM pin pages
> > > > from a memfd. I would quite happily use that in iommufd as well.
> > > >
> > > > It solves some problems we have there with fork/exec/etc if the pages
> > > > are not linked to a mm_struct.
> > >
> > > Afaiu any fd based approach should mean it'll never work with private
> > > memories, while mm-based should be able to work on any kind.
> >
> > Is there a significant use case to open a memfd and then use
> > MAP_PRIVATE? Why would anyone want to do that instead of just using
> > normal mmap anonymous memory?
>
> I remember David Hildenbrand somewhere mentioned the use case where one
> wants to snapshot a VM RAM into a file, then start multiple instances by
> loading that VM RAM with MAP_PRIVATE, so it clones a bunch of snapshoted VM
> running with a single RAM file shared as a template. Not a generic use
> case, I guess.
A file I can see, but a file is not a memfd, we are talking
specifically about memfd, aren't we?
> My question applies not only memfd but also in general - qemu by default
> doesn't use memfd afaict, so it boils down to e.g. whether you'll target
> the iommufd project to work in that case, where qemu uses anonymous
> memory.
I think this may change, as I understand it, the approach for
confidential compute is to put the guest memory in a memfd...
> Privately mapped file memory is only one of those kinds.
I think memfd and related shmem-like objects are a reasonable target. We
already know we should not FOLL_LONGTERM pin file backed pages.
Jason
^ permalink raw reply [flat|nested] 46+ messages in thread
* RE: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
2023-06-26 18:14 ` David Hildenbrand
@ 2023-06-27 6:37 ` Kasireddy, Vivek
-1 siblings, 0 replies; 46+ messages in thread
From: Kasireddy, Vivek @ 2023-06-27 6:37 UTC (permalink / raw)
To: David Hildenbrand, Peter Xu
Cc: James Houghton, Jerome Marchand, Kim, Dongwon, Chang, Junxiao,
Muchun Song, dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
Hocko, Michal, Gerd Hoffmann, Jason Gunthorpe, John Hubbard,
Andrew Morton, Kirill A . Shutemov, Mike Kravetz
Hi David,
> On 26.06.23 19:52, Peter Xu wrote:
> > On Mon, Jun 26, 2023 at 07:45:37AM +0000, Kasireddy, Vivek wrote:
> >> Hi Peter,
> >>
> >>>
> >>> On Fri, Jun 23, 2023 at 06:13:02AM +0000, Kasireddy, Vivek wrote:
> >>>> Hi David,
> >>>>
> >>>>>> The first patch ensures that the mappings needed for handling mmap
> >>>>>> operation would be managed by using the pfn instead of struct page.
> >>>>>> The second patch restores support for mapping hugetlb pages where
> >>>>>> subpages of a hugepage are not directly used anymore (main reason
> >>>>>> for revert) and instead the hugetlb pages and the relevant offsets
> >>>>>> are used to populate the scatterlist for dma-buf export and for
> >>>>>> mmap operation.
> >>>>>>
> >>>>>> Testcase: default_hugepagesz=2M hugepagesz=2M hugepages=2500
> >>>>> options
> >>>>>> were passed to the Host kernel and Qemu was launched with these
> >>>>>> relevant options: qemu-system-x86_64 -m 4096m....
> >>>>>> -device virtio-gpu-pci,max_outputs=1,blob=true,xres=1920,yres=1080
> >>>>>> -display gtk,gl=on
> >>>>>> -object memory-backend-memfd,hugetlb=on,id=mem1,size=4096M
> >>>>>> -machine memory-backend=mem1
> >>>>>>
> >>>>>> Replacing -display gtk,gl=on with -display gtk,gl=off above would
> >>>>>> exercise the mmap handler.
> >>>>>>
> >>>>>
> >>>>> While I think the VM_PFNMAP approach is much better and should fix
> >>> that
> >>>>> issue at hand, I thought more about missing memlock support and
> >>> realized
> >>>>> that we might have to fix something else. SO I'm going to raise the
> >>>>> issue here.
> >>>>>
> >>>>> I think udmabuf chose the wrong interface to do what it's doing, that
> >>>>> makes it harder to fix it eventually.
> >>>>>
> >>>>> Instead of accepting a range in a memfd, it should just have accepted a
> >>>>> user space address range and then used
> >>>>> pin_user_pages(FOLL_WRITE|FOLL_LONGTERM) to longterm-pin the
> >>> pages
> >>>>> "officially".
> >>>> Udmabuf indeed started off by using user space address range and GUP
> >>> but
> >>>> the dma-buf subsystem maintainer had concerns with that approach in
> v2.
> >>>> It also had support for mlock in that version. Here is v2 and the relevant
> >>>> conversation:
> >>>>
> https://patchwork.freedesktop.org/patch/210992/?series=39879&rev=2
> >>>>
> >>>>>
> >>>>> So what's the issue? Udma effectively pins pages longterm ("possibly
> >>>>> forever") simply by grabbing a reference on them. These pages might
> >>>>> easily reside in ZONE_MOVABLE or in MIGRATE_CMA pageblocks.
> >>>>>
> >>>>> So what udmabuf does is break memory hotunplug and CMA, because
> it
> >>>>> turns
> >>>>> pages that have to remain movable unmovable.
> >>>>>
> >>>>> In the pin_user_pages(FOLL_LONGTERM) case we make sure to
> migrate
> >>>>> these
> >>>>> pages. See mm/gup.c:check_and_migrate_movable_pages() and
> >>> especially
> >>>>> folio_is_longterm_pinnable(). We'd probably have to implement
> >>> something
> >>>>> similar for udmabuf, where we detect such unpinnable pages and
> >>> migrate
> >>>>> them.
> >>>> The pages udmabuf pins are only those associated with Guest (GPU
> >>> driver/virtio-gpu)
> >>>> resources (or buffers allocated and pinned from shmem via drm GEM).
> >>> Some
> >>>> resources are short-lived, and some are long-lived and whenever a
> >>> resource
> >>>> gets destroyed, the pages are unpinned. And, not all resources have
> their
> >>> pages
> >>>> pinned. The resource that is pinned for the longest duration is the FB
> and
> >>> that's
> >>>> because it is updated every ~16ms (assuming 1920x1080@60) by the
> Guest
> >>>> GPU driver. We can certainly pin/unpin the FB after it is accessed on the
> >>> Host
> >>>> as a workaround, but I guess that may not be very efficient given the
> >>> amount
> >>>> of churn it would create.
> >>>>
> >>>> Also, as far as migration or S3/S4 is concerned, my understanding is
> that all
> >>>> the Guest resources are destroyed and recreated again. So, wouldn't
> >>> something
> >>>> similar happen during memory hotunplug?
> >>>>
> >>>>>
> >>>>>
> >>>>> For example, pairing udmabuf with vfio (which pins pages using
> >>>>> pin_user_pages(FOLL_LONGTERM)) in QEMU will most probably not
> work
> >>> in
> >>>>> all cases: if udmabuf longterm pinned the pages "the wrong way", vfio
> >>>>> will fail to migrate them during FOLL_LONGTERM and consequently fail
> >>>>> pin_user_pages(). As long as udmabuf holds a reference on these
> pages,
> >>>>> that will never succeed.
> >>>> Dma-buf rules (for exporters) indicate that the pages only need to be
> >>> pinned
> >>>> during the map_attachment phase (and until unmap attachment
> happens).
> >>>> In other words, only when the sg_table is created by udmabuf. I guess
> one
> >>>> option would be to not hold any references during UDMABUF_CREATE
> and
> >>>> only grab references to the pages (as and when it gets used) during this
> >>> step.
> >>>> Would this help?
> >>>
> >>> IIUC the refcount is needed, otherwise I don't see what to protect the
> page
> >>> from being freed and even reused elsewhere before map_attachment().
> >>>
> >>> It seems the previous concern on using gup was majorly fork(), if this is
> it:
> >>>
> >>>
> https://patchwork.freedesktop.org/patch/210992/?series=39879&rev=2#co
> >>> mment_414213
> >>>
> >>> Could it also be guarded by just making sure the pages are MAP_SHARED
> >>> when
> >>> creating the udmabuf, if fork() is a requirement of the feature?
> >>>
> >>> I had a feeling that the userspace still needs to always do the right thing
> >>> to make it work, even using pure PFN mappings.
> >>>
> >>> For instance, what if the userapp just punchs a hole in the
> shmem/hugetlbfs
> >>> file after creating the udmabuf (I see that F_SEAL_SHRINK is required, but
> >>> at least not F_SEAL_WRITE with current impl), and fault a new page into
> the
> >>> page cache?
> >> IIUC, Qemu creates and owns the memfd that is associated with Guest
> memory.
> >> And if it punches a hole in its own memfd that goes through Guest pinned
> pages
> >> associated with buffers/resources, then I think the proper way to fix this is
> to
> >> somehow notify the Guest driver (virtio-gpu in this case) that the backing
> store
> >> of the affected resources is no longer valid and that the resources need to
> be
> >> destroyed and re-created again.
> >>
> >> Having said that, one option I could think of is to probably install a
> mmu_notifier
> >> associated with the relevant pages in udmabuf and once we get notified
> about
> >> any invalidation event concerning any of the pages, we'd fail any
> subsequent
> >> attempt to access these pages and propagate the error across the stack.
> >
> > Sounds right, maybe it needs to go back to the old GUP solution, though, as
> > mmu notifiers are also mm-based not fd-based. Or to be explicit, I think
> > it'll be pin_user_pages(FOLL_LONGTERM) with the new API. It'll also solve
> > the movable pages issue on pinning.
>
> It better should be pin_user_pages(FOLL_LONGTERM). But I'm afraid we
> cannot achieve that without breaking the existing kernel interface ...
Yeah, as you suggest, we unfortunately cannot go back to using GUP
without breaking udmabuf_create UAPI that expects memfds and file
offsets.
>
> So we might have to implement the same page migration as gup does on
> FOLL_LONGTERM here ... maybe there are more such cases/drivers that
> actually require that handling when simply taking pages out of the
> memfd, believing they can hold on to them forever.
IIUC, I don't think just handling the page migration in udmabuf is going to
cut it. It might require active cooperation of the Guest GPU driver as well
if this is even feasible.
>
> >
> >>
> >> However, it feels like udmabuf is not the right place to handle this issue
> because
> >> there are very limited options for taking proper corrective action if Qemu
> decides
> >> to punch a hole in Guest memory that takes out pages that are pinned.
> >
> > I'm not familiar with the use case that much, but IMHO it's fine if the
> > driver relies on proper behaviors of userapp to work.
> >
> > IIUC the worst case here is the udmabuf holds some pages that are not the
> > pages of the guest mem anymore, but it only happens on misbehaved
> > userspace, then it looks all fine as long as they can at least be properly
> > released when releasing the udmabuf. It'll be better if the udmabuf can
> > fail hard when detecting this, but IMHO even that can be optional
> depending
> > on the need, while any corrective action will be even one step further.
>
> For vfio the issue are e.g., VM reboots, not a misbehaving guest. If the
> old guest kernel inflated the balloon and we reboot the VM, VFIO will
> still reference the old pages and the new (unaware kernel) might use
> that previously inflated memory to communicate with the devices. Because
> of that, we disable balloon inflation when vfio is active in QEMU.
>
> [there are more cases like unloading the balloon driver or deflating the
> balloon, and then using that memory for communicating with the device]
>
> Maybe it's all fine with udmabuf because of the way it is setup/torn
> down by the guest driver. Unfortunately I can't tell.
Here are the functions used by virtio-gpu (Guest GPU driver) to allocate
pages for its resources:
__drm_gem_shmem_create: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_gem_shmem_helper.c#L97
Interestingly, the comment in the above function says that the pages
should not be allocated from the MOVABLE zone.
The pages along with their dma addresses are then extracted and shared
with Qemu using these two functions:
drm_gem_get_pages: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_gem.c#L534
virtio_gpu_object_shmem_init: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/virtio/virtgpu_object.c#L135
Qemu then translates the dma addresses into file offsets and creates
udmabufs -- as an optimization to avoid data copies only if blob is set
to true.
I'll need to run some experiments to understand the impact of memfd page
migration (or replacement) on virtio-gpu driver's resources -- and also on the
rest of the Guest graphics stack.
Thanks,
Vivek
>
> --
> Cheers,
>
> David / dhildenb
^ permalink raw reply [flat|nested] 46+ messages in thread* RE: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
@ 2023-06-27 6:37 ` Kasireddy, Vivek
0 siblings, 0 replies; 46+ messages in thread
From: Kasireddy, Vivek @ 2023-06-27 6:37 UTC (permalink / raw)
To: David Hildenbrand, Peter Xu
Cc: dri-devel@lists.freedesktop.org, linux-mm@kvack.org, Mike Kravetz,
Gerd Hoffmann, Kim, Dongwon, Andrew Morton, James Houghton,
Jerome Marchand, Chang, Junxiao, Kirill A . Shutemov,
Hocko, Michal, Muchun Song, Jason Gunthorpe, John Hubbard
Hi David,
> On 26.06.23 19:52, Peter Xu wrote:
> > On Mon, Jun 26, 2023 at 07:45:37AM +0000, Kasireddy, Vivek wrote:
> >> Hi Peter,
> >>
> >>>
> >>> On Fri, Jun 23, 2023 at 06:13:02AM +0000, Kasireddy, Vivek wrote:
> >>>> Hi David,
> >>>>
> >>>>>> The first patch ensures that the mappings needed for handling mmap
> >>>>>> operation would be managed by using the pfn instead of struct page.
> >>>>>> The second patch restores support for mapping hugetlb pages where
> >>>>>> subpages of a hugepage are not directly used anymore (main reason
> >>>>>> for revert) and instead the hugetlb pages and the relevant offsets
> >>>>>> are used to populate the scatterlist for dma-buf export and for
> >>>>>> mmap operation.
> >>>>>>
> >>>>>> Testcase: default_hugepagesz=2M hugepagesz=2M hugepages=2500
> >>>>> options
> >>>>>> were passed to the Host kernel and Qemu was launched with these
> >>>>>> relevant options: qemu-system-x86_64 -m 4096m....
> >>>>>> -device virtio-gpu-pci,max_outputs=1,blob=true,xres=1920,yres=1080
> >>>>>> -display gtk,gl=on
> >>>>>> -object memory-backend-memfd,hugetlb=on,id=mem1,size=4096M
> >>>>>> -machine memory-backend=mem1
> >>>>>>
> >>>>>> Replacing -display gtk,gl=on with -display gtk,gl=off above would
> >>>>>> exercise the mmap handler.
> >>>>>>
> >>>>>
> >>>>> While I think the VM_PFNMAP approach is much better and should fix
> >>> that
> >>>>> issue at hand, I thought more about missing memlock support and
> >>> realized
> >>>>> that we might have to fix something else. SO I'm going to raise the
> >>>>> issue here.
> >>>>>
> >>>>> I think udmabuf chose the wrong interface to do what it's doing, that
> >>>>> makes it harder to fix it eventually.
> >>>>>
> >>>>> Instead of accepting a range in a memfd, it should just have accepted a
> >>>>> user space address range and then used
> >>>>> pin_user_pages(FOLL_WRITE|FOLL_LONGTERM) to longterm-pin the
> >>> pages
> >>>>> "officially".
> >>>> Udmabuf indeed started off by using user space address range and GUP
> >>> but
> >>>> the dma-buf subsystem maintainer had concerns with that approach in
> v2.
> >>>> It also had support for mlock in that version. Here is v2 and the relevant
> >>>> conversation:
> >>>>
> https://patchwork.freedesktop.org/patch/210992/?series=39879&rev=2
> >>>>
> >>>>>
> >>>>> So what's the issue? Udma effectively pins pages longterm ("possibly
> >>>>> forever") simply by grabbing a reference on them. These pages might
> >>>>> easily reside in ZONE_MOVABLE or in MIGRATE_CMA pageblocks.
> >>>>>
> >>>>> So what udmabuf does is break memory hotunplug and CMA, because
> it
> >>>>> turns
> >>>>> pages that have to remain movable unmovable.
> >>>>>
> >>>>> In the pin_user_pages(FOLL_LONGTERM) case we make sure to
> migrate
> >>>>> these
> >>>>> pages. See mm/gup.c:check_and_migrate_movable_pages() and
> >>> especially
> >>>>> folio_is_longterm_pinnable(). We'd probably have to implement
> >>> something
> >>>>> similar for udmabuf, where we detect such unpinnable pages and
> >>> migrate
> >>>>> them.
> >>>> The pages udmabuf pins are only those associated with Guest (GPU
> >>> driver/virtio-gpu)
> >>>> resources (or buffers allocated and pinned from shmem via drm GEM).
> >>> Some
> >>>> resources are short-lived, and some are long-lived and whenever a
> >>> resource
> >>>> gets destroyed, the pages are unpinned. And, not all resources have
> their
> >>> pages
> >>>> pinned. The resource that is pinned for the longest duration is the FB
> and
> >>> that's
> >>>> because it is updated every ~16ms (assuming 1920x1080@60) by the
> Guest
> >>>> GPU driver. We can certainly pin/unpin the FB after it is accessed on the
> >>> Host
> >>>> as a workaround, but I guess that may not be very efficient given the
> >>> amount
> >>>> of churn it would create.
> >>>>
> >>>> Also, as far as migration or S3/S4 is concerned, my understanding is
> that all
> >>>> the Guest resources are destroyed and recreated again. So, wouldn't
> >>> something
> >>>> similar happen during memory hotunplug?
> >>>>
> >>>>>
> >>>>>
> >>>>> For example, pairing udmabuf with vfio (which pins pages using
> >>>>> pin_user_pages(FOLL_LONGTERM)) in QEMU will most probably not
> work
> >>> in
> >>>>> all cases: if udmabuf longterm pinned the pages "the wrong way", vfio
> >>>>> will fail to migrate them during FOLL_LONGTERM and consequently fail
> >>>>> pin_user_pages(). As long as udmabuf holds a reference on these
> pages,
> >>>>> that will never succeed.
> >>>> Dma-buf rules (for exporters) indicate that the pages only need to be
> >>> pinned
> >>>> during the map_attachment phase (and until unmap attachment
> happens).
> >>>> In other words, only when the sg_table is created by udmabuf. I guess
> one
> >>>> option would be to not hold any references during UDMABUF_CREATE
> and
> >>>> only grab references to the pages (as and when it gets used) during this
> >>> step.
> >>>> Would this help?
> >>>
> >>> IIUC the refcount is needed, otherwise I don't see what to protect the
> page
> >>> from being freed and even reused elsewhere before map_attachment().
> >>>
> >>> It seems the previous concern on using gup was majorly fork(), if this is
> it:
> >>>
> >>>
> https://patchwork.freedesktop.org/patch/210992/?series=39879&rev=2#co
> >>> mment_414213
> >>>
> >>> Could it also be guarded by just making sure the pages are MAP_SHARED
> >>> when
> >>> creating the udmabuf, if fork() is a requirement of the feature?
> >>>
> >>> I had a feeling that the userspace still needs to always do the right thing
> >>> to make it work, even using pure PFN mappings.
> >>>
> >>> For instance, what if the userapp just punchs a hole in the
> shmem/hugetlbfs
> >>> file after creating the udmabuf (I see that F_SEAL_SHRINK is required, but
> >>> at least not F_SEAL_WRITE with current impl), and fault a new page into
> the
> >>> page cache?
> >> IIUC, Qemu creates and owns the memfd that is associated with Guest
> memory.
> >> And if it punches a hole in its own memfd that goes through Guest pinned
> pages
> >> associated with buffers/resources, then I think the proper way to fix this is
> to
> >> somehow notify the Guest driver (virtio-gpu in this case) that the backing
> store
> >> of the affected resources is no longer valid and that the resources need to
> be
> >> destroyed and re-created again.
> >>
> >> Having said that, one option I could think of is to probably install a
> mmu_notifier
> >> associated with the relevant pages in udmabuf and once we get notified
> about
> >> any invalidation event concerning any of the pages, we'd fail any
> subsequent
> >> attempt to access these pages and propagate the error across the stack.
> >
> > Sounds right, maybe it needs to go back to the old GUP solution, though, as
> > mmu notifiers are also mm-based not fd-based. Or to be explicit, I think
> > it'll be pin_user_pages(FOLL_LONGTERM) with the new API. It'll also solve
> > the movable pages issue on pinning.
>
> It better should be pin_user_pages(FOLL_LONGTERM). But I'm afraid we
> cannot achieve that without breaking the existing kernel interface ...
Yeah, as you suggest, we unfortunately cannot go back to using GUP
without breaking udmabuf_create UAPI that expects memfds and file
offsets.
>
> So we might have to implement the same page migration as gup does on
> FOLL_LONGTERM here ... maybe there are more such cases/drivers that
> actually require that handling when simply taking pages out of the
> memfd, believing they can hold on to them forever.
IIUC, I don't think just handling the page migration in udmabuf is going to
cut it. It might require active cooperation of the Guest GPU driver as well
if this is even feasible.
>
> >
> >>
> >> However, it feels like udmabuf is not the right place to handle this issue
> because
> >> there are very limited options for taking proper corrective action if Qemu
> decides
> >> to punch a hole in Guest memory that takes out pages that are pinned.
> >
> > I'm not familiar with the use case that much, but IMHO it's fine if the
> > driver relies on proper behaviors of userapp to work.
> >
> > IIUC the worst case here is the udmabuf holds some pages that are not the
> > pages of the guest mem anymore, but it only happens on misbehaved
> > userspace, then it looks all fine as long as they can at least be properly
> > released when releasing the udmabuf. It'll be better if the udmabuf can
> > fail hard when detecting this, but IMHO even that can be optional
> depending
> > on the need, while any corrective action will be even one step further.
>
> For vfio the issue are e.g., VM reboots, not a misbehaving guest. If the
> old guest kernel inflated the balloon and we reboot the VM, VFIO will
> still reference the old pages and the new (unaware kernel) might use
> that previously inflated memory to communicate with the devices. Because
> of that, we disable balloon inflation when vfio is active in QEMU.
>
> [there are more cases like unloading the balloon driver or deflating the
> balloon, and then using that memory for communicating with the device]
>
> Maybe it's all fine with udmabuf because of the way it is setup/torn
> down by the guest driver. Unfortunately I can't tell.
Here are the functions used by virtio-gpu (Guest GPU driver) to allocate
pages for its resources:
__drm_gem_shmem_create: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_gem_shmem_helper.c#L97
Interestingly, the comment in the above function says that the pages
should not be allocated from the MOVABLE zone.
The pages along with their dma addresses are then extracted and shared
with Qemu using these two functions:
drm_gem_get_pages: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_gem.c#L534
virtio_gpu_object_shmem_init: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/virtio/virtgpu_object.c#L135
Qemu then translates the dma addresses into file offsets and creates
udmabufs -- as an optimization to avoid data copies only if blob is set
to true.
I'll need to run some experiments to understand the impact of memfd page
migration (or replacement) on virtio-gpu driver's resources -- and also on the
rest of the Guest graphics stack.
Thanks,
Vivek
>
> --
> Cheers,
>
> David / dhildenb
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
2023-06-27 6:37 ` Kasireddy, Vivek
@ 2023-06-27 7:10 ` David Hildenbrand
-1 siblings, 0 replies; 46+ messages in thread
From: David Hildenbrand @ 2023-06-27 7:10 UTC (permalink / raw)
To: Kasireddy, Vivek, Peter Xu
Cc: James Houghton, Jerome Marchand, Kim, Dongwon, Chang, Junxiao,
Muchun Song, dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
Hocko, Michal, Gerd Hoffmann, Jason Gunthorpe, John Hubbard,
Andrew Morton, Kirill A . Shutemov, Mike Kravetz
On 27.06.23 08:37, Kasireddy, Vivek wrote:
> Hi David,
>
Hi!
sorry for taking a bit longer to reply lately.
[...]
>>> Sounds right, maybe it needs to go back to the old GUP solution, though, as
>>> mmu notifiers are also mm-based not fd-based. Or to be explicit, I think
>>> it'll be pin_user_pages(FOLL_LONGTERM) with the new API. It'll also solve
>>> the movable pages issue on pinning.
>>
>> It better should be pin_user_pages(FOLL_LONGTERM). But I'm afraid we
>> cannot achieve that without breaking the existing kernel interface ...
> Yeah, as you suggest, we unfortunately cannot go back to using GUP
> without breaking udmabuf_create UAPI that expects memfds and file
> offsets.
>
>>
>> So we might have to implement the same page migration as gup does on
>> FOLL_LONGTERM here ... maybe there are more such cases/drivers that
>> actually require that handling when simply taking pages out of the
>> memfd, believing they can hold on to them forever.
> IIUC, I don't think just handling the page migration in udmabuf is going to
> cut it. It might require active cooperation of the Guest GPU driver as well
> if this is even feasible.
The idea is, that once you extract the page from the memfd and it
resides somewhere bad (MIGRATE_CMA, ZONE_MOVABLE), you trigger page
migration. Essentially what migrate_longterm_unpinnable_pages() does:
Why would the guest driver have to be involved? It shouldn't care about
page migration in the hypervisor.
[...]
>> balloon, and then using that memory for communicating with the device]
>>
>> Maybe it's all fine with udmabuf because of the way it is setup/torn
>> down by the guest driver. Unfortunately I can't tell.
> Here are the functions used by virtio-gpu (Guest GPU driver) to allocate
> pages for its resources:
> __drm_gem_shmem_create: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_gem_shmem_helper.c#L97
> Interestingly, the comment in the above function says that the pages
> should not be allocated from the MOVABLE zone.
It doesn't add GFP_MOVABLE, so pages don't end up in
ZONE_MOVABLE/MIGRATE_CMA *in the guest*. But we care about the
ZONE_MOVABLE /MIGRATE_CMA *in the host*. (what the guest does is right,
though)
IOW, what udmabuf does with guest memory on the hypervisor side, not the
guest driver on the guest side.
> The pages along with their dma addresses are then extracted and shared
> with Qemu using these two functions:
> drm_gem_get_pages: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_gem.c#L534
> virtio_gpu_object_shmem_init: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/virtio/virtgpu_object.c#L135
^ so these two target the guest driver as well, right? IOW, there is a
memfd (shmem) in the guest that the guest driver uses to allocate pages
from and there is the memfd in the hypervisor to back guest RAM.
The latter gets registered with udmabuf.
> Qemu then translates the dma addresses into file offsets and creates
> udmabufs -- as an optimization to avoid data copies only if blob is set
> to true.
If the guest OS doesn't end up freeing/reallocating that memory while
it's registered with udmabuf in the hypervisor, then we should be fine.
Because that way, the guest won't end up trigger MADV_DONTNEED by
"accident".
--
Cheers,
David / dhildenb
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
@ 2023-06-27 7:10 ` David Hildenbrand
0 siblings, 0 replies; 46+ messages in thread
From: David Hildenbrand @ 2023-06-27 7:10 UTC (permalink / raw)
To: Kasireddy, Vivek, Peter Xu
Cc: dri-devel@lists.freedesktop.org, linux-mm@kvack.org, Mike Kravetz,
Gerd Hoffmann, Kim, Dongwon, Andrew Morton, James Houghton,
Jerome Marchand, Chang, Junxiao, Kirill A . Shutemov,
Hocko, Michal, Muchun Song, Jason Gunthorpe, John Hubbard
On 27.06.23 08:37, Kasireddy, Vivek wrote:
> Hi David,
>
Hi!
sorry for taking a bit longer to reply lately.
[...]
>>> Sounds right, maybe it needs to go back to the old GUP solution, though, as
>>> mmu notifiers are also mm-based not fd-based. Or to be explicit, I think
>>> it'll be pin_user_pages(FOLL_LONGTERM) with the new API. It'll also solve
>>> the movable pages issue on pinning.
>>
>> It better should be pin_user_pages(FOLL_LONGTERM). But I'm afraid we
>> cannot achieve that without breaking the existing kernel interface ...
> Yeah, as you suggest, we unfortunately cannot go back to using GUP
> without breaking udmabuf_create UAPI that expects memfds and file
> offsets.
>
>>
>> So we might have to implement the same page migration as gup does on
>> FOLL_LONGTERM here ... maybe there are more such cases/drivers that
>> actually require that handling when simply taking pages out of the
>> memfd, believing they can hold on to them forever.
> IIUC, I don't think just handling the page migration in udmabuf is going to
> cut it. It might require active cooperation of the Guest GPU driver as well
> if this is even feasible.
The idea is, that once you extract the page from the memfd and it
resides somewhere bad (MIGRATE_CMA, ZONE_MOVABLE), you trigger page
migration. Essentially what migrate_longterm_unpinnable_pages() does:
Why would the guest driver have to be involved? It shouldn't care about
page migration in the hypervisor.
[...]
>> balloon, and then using that memory for communicating with the device]
>>
>> Maybe it's all fine with udmabuf because of the way it is setup/torn
>> down by the guest driver. Unfortunately I can't tell.
> Here are the functions used by virtio-gpu (Guest GPU driver) to allocate
> pages for its resources:
> __drm_gem_shmem_create: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_gem_shmem_helper.c#L97
> Interestingly, the comment in the above function says that the pages
> should not be allocated from the MOVABLE zone.
It doesn't add GFP_MOVABLE, so pages don't end up in
ZONE_MOVABLE/MIGRATE_CMA *in the guest*. But we care about the
ZONE_MOVABLE /MIGRATE_CMA *in the host*. (what the guest does is right,
though)
IOW, what udmabuf does with guest memory on the hypervisor side, not the
guest driver on the guest side.
> The pages along with their dma addresses are then extracted and shared
> with Qemu using these two functions:
> drm_gem_get_pages: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_gem.c#L534
> virtio_gpu_object_shmem_init: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/virtio/virtgpu_object.c#L135
^ so these two target the guest driver as well, right? IOW, there is a
memfd (shmem) in the guest that the guest driver uses to allocate pages
from and there is the memfd in the hypervisor to back guest RAM.
The latter gets registered with udmabuf.
> Qemu then translates the dma addresses into file offsets and creates
> udmabufs -- as an optimization to avoid data copies only if blob is set
> to true.
If the guest OS doesn't end up freeing/reallocating that memory while
it's registered with udmabuf in the hypervisor, then we should be fine.
Because that way, the guest won't end up trigger MADV_DONTNEED by
"accident".
--
Cheers,
David / dhildenb
^ permalink raw reply [flat|nested] 46+ messages in thread
* RE: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
2023-06-27 7:10 ` David Hildenbrand
@ 2023-06-28 8:04 ` Kasireddy, Vivek
-1 siblings, 0 replies; 46+ messages in thread
From: Kasireddy, Vivek @ 2023-06-28 8:04 UTC (permalink / raw)
To: David Hildenbrand, Peter Xu
Cc: James Houghton, Jerome Marchand, Kim, Dongwon, Chang, Junxiao,
Muchun Song, dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
Hocko, Michal, Gerd Hoffmann, Jason Gunthorpe, John Hubbard,
Andrew Morton, Kirill A . Shutemov, Mike Kravetz
Hi David,
>
> On 27.06.23 08:37, Kasireddy, Vivek wrote:
> > Hi David,
> >
>
> Hi!
>
> sorry for taking a bit longer to reply lately.
No problem.
>
> [...]
>
> >>> Sounds right, maybe it needs to go back to the old GUP solution, though,
> as
> >>> mmu notifiers are also mm-based not fd-based. Or to be explicit, I think
> >>> it'll be pin_user_pages(FOLL_LONGTERM) with the new API. It'll also
> solve
> >>> the movable pages issue on pinning.
> >>
> >> It better should be pin_user_pages(FOLL_LONGTERM). But I'm afraid we
> >> cannot achieve that without breaking the existing kernel interface ...
> > Yeah, as you suggest, we unfortunately cannot go back to using GUP
> > without breaking udmabuf_create UAPI that expects memfds and file
> > offsets.
> >
> >>
> >> So we might have to implement the same page migration as gup does on
> >> FOLL_LONGTERM here ... maybe there are more such cases/drivers that
> >> actually require that handling when simply taking pages out of the
> >> memfd, believing they can hold on to them forever.
> > IIUC, I don't think just handling the page migration in udmabuf is going to
> > cut it. It might require active cooperation of the Guest GPU driver as well
> > if this is even feasible.
>
> The idea is, that once you extract the page from the memfd and it
> resides somewhere bad (MIGRATE_CMA, ZONE_MOVABLE), you trigger page
> migration. Essentially what migrate_longterm_unpinnable_pages() does:
So, IIUC, it looks like calling check_and_migrate_movable_pages() at the time
of creation (udmabuf_create) and when we get notified about something like
FALLOC_FL_PUNCH_HOLE will be all that needs to be done in udmabuf?
>
> Why would the guest driver have to be involved? It shouldn't care about
> page migration in the hypervisor.
Yeah, it appears that the page migration would be transparent to the Guest
driver.
>
> [...]
>
> >> balloon, and then using that memory for communicating with the device]
> >>
> >> Maybe it's all fine with udmabuf because of the way it is setup/torn
> >> down by the guest driver. Unfortunately I can't tell.
> > Here are the functions used by virtio-gpu (Guest GPU driver) to allocate
> > pages for its resources:
> > __drm_gem_shmem_create:
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_gem_sh
> mem_helper.c#L97
> > Interestingly, the comment in the above function says that the pages
> > should not be allocated from the MOVABLE zone.
>
> It doesn't add GFP_MOVABLE, so pages don't end up in
> ZONE_MOVABLE/MIGRATE_CMA *in the guest*. But we care about the
> ZONE_MOVABLE /MIGRATE_CMA *in the host*. (what the guest does is
> right,
> though)
>
> IOW, what udmabuf does with guest memory on the hypervisor side, not the
> guest driver on the guest side.
Ok, got it.
>
> > The pages along with their dma addresses are then extracted and shared
> > with Qemu using these two functions:
> > drm_gem_get_pages:
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_gem.c#
> L534
> > virtio_gpu_object_shmem_init:
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/virtio/virtgpu
> _object.c#L135
>
> ^ so these two target the guest driver as well, right? IOW, there is a
> memfd (shmem) in the guest that the guest driver uses to allocate pages
> from and there is the memfd in the hypervisor to back guest RAM.
>
> The latter gets registered with udmabuf.
Yes, that's exactly what happens.
>
> > Qemu then translates the dma addresses into file offsets and creates
> > udmabufs -- as an optimization to avoid data copies only if blob is set
> > to true.
>
> If the guest OS doesn't end up freeing/reallocating that memory while
> it's registered with udmabuf in the hypervisor, then we should be fine.
IIUC, udmabuf does get notified when something like that happens.
Thanks,
Vivek
>
> Because that way, the guest won't end up trigger MADV_DONTNEED by
> "accident".
>
> --
> Cheers,
>
> David / dhildenb
^ permalink raw reply [flat|nested] 46+ messages in thread
* RE: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
@ 2023-06-28 8:04 ` Kasireddy, Vivek
0 siblings, 0 replies; 46+ messages in thread
From: Kasireddy, Vivek @ 2023-06-28 8:04 UTC (permalink / raw)
To: David Hildenbrand, Peter Xu
Cc: dri-devel@lists.freedesktop.org, linux-mm@kvack.org, Mike Kravetz,
Gerd Hoffmann, Kim, Dongwon, Andrew Morton, James Houghton,
Jerome Marchand, Chang, Junxiao, Kirill A . Shutemov,
Hocko, Michal, Muchun Song, Jason Gunthorpe, John Hubbard
Hi David,
>
> On 27.06.23 08:37, Kasireddy, Vivek wrote:
> > Hi David,
> >
>
> Hi!
>
> sorry for taking a bit longer to reply lately.
No problem.
>
> [...]
>
> >>> Sounds right, maybe it needs to go back to the old GUP solution, though,
> as
> >>> mmu notifiers are also mm-based not fd-based. Or to be explicit, I think
> >>> it'll be pin_user_pages(FOLL_LONGTERM) with the new API. It'll also
> solve
> >>> the movable pages issue on pinning.
> >>
> >> It better should be pin_user_pages(FOLL_LONGTERM). But I'm afraid we
> >> cannot achieve that without breaking the existing kernel interface ...
> > Yeah, as you suggest, we unfortunately cannot go back to using GUP
> > without breaking udmabuf_create UAPI that expects memfds and file
> > offsets.
> >
> >>
> >> So we might have to implement the same page migration as gup does on
> >> FOLL_LONGTERM here ... maybe there are more such cases/drivers that
> >> actually require that handling when simply taking pages out of the
> >> memfd, believing they can hold on to them forever.
> > IIUC, I don't think just handling the page migration in udmabuf is going to
> > cut it. It might require active cooperation of the Guest GPU driver as well
> > if this is even feasible.
>
> The idea is, that once you extract the page from the memfd and it
> resides somewhere bad (MIGRATE_CMA, ZONE_MOVABLE), you trigger page
> migration. Essentially what migrate_longterm_unpinnable_pages() does:
So, IIUC, it looks like calling check_and_migrate_movable_pages() at the time
of creation (udmabuf_create) and when we get notified about something like
FALLOC_FL_PUNCH_HOLE will be all that needs to be done in udmabuf?
>
> Why would the guest driver have to be involved? It shouldn't care about
> page migration in the hypervisor.
Yeah, it appears that the page migration would be transparent to the Guest
driver.
>
> [...]
>
> >> balloon, and then using that memory for communicating with the device]
> >>
> >> Maybe it's all fine with udmabuf because of the way it is setup/torn
> >> down by the guest driver. Unfortunately I can't tell.
> > Here are the functions used by virtio-gpu (Guest GPU driver) to allocate
> > pages for its resources:
> > __drm_gem_shmem_create:
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_gem_sh
> mem_helper.c#L97
> > Interestingly, the comment in the above function says that the pages
> > should not be allocated from the MOVABLE zone.
>
> It doesn't add GFP_MOVABLE, so pages don't end up in
> ZONE_MOVABLE/MIGRATE_CMA *in the guest*. But we care about the
> ZONE_MOVABLE /MIGRATE_CMA *in the host*. (what the guest does is
> right,
> though)
>
> IOW, what udmabuf does with guest memory on the hypervisor side, not the
> guest driver on the guest side.
Ok, got it.
>
> > The pages along with their dma addresses are then extracted and shared
> > with Qemu using these two functions:
> > drm_gem_get_pages:
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_gem.c#
> L534
> > virtio_gpu_object_shmem_init:
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/virtio/virtgpu
> _object.c#L135
>
> ^ so these two target the guest driver as well, right? IOW, there is a
> memfd (shmem) in the guest that the guest driver uses to allocate pages
> from and there is the memfd in the hypervisor to back guest RAM.
>
> The latter gets registered with udmabuf.
Yes, that's exactly what happens.
>
> > Qemu then translates the dma addresses into file offsets and creates
> > udmabufs -- as an optimization to avoid data copies only if blob is set
> > to true.
>
> If the guest OS doesn't end up freeing/reallocating that memory while
> it's registered with udmabuf in the hypervisor, then we should be fine.
IIUC, udmabuf does get notified when something like that happens.
Thanks,
Vivek
>
> Because that way, the guest won't end up trigger MADV_DONTNEED by
> "accident".
>
> --
> Cheers,
>
> David / dhildenb
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
2023-06-22 8:25 ` David Hildenbrand
@ 2023-08-08 16:17 ` Daniel Vetter
-1 siblings, 0 replies; 46+ messages in thread
From: Daniel Vetter @ 2023-08-08 16:17 UTC (permalink / raw)
To: David Hildenbrand
Cc: James Houghton, Jerome Marchand, Dongwon Kim, Junxiao Chang,
Muchun Song, Vivek Kasireddy, dri-devel, linux-mm, Michal Hocko,
Gerd Hoffmann, Jason Gunthorpe, John Hubbard, Andrew Morton,
Kirill A . Shutemov, Mike Kravetz
On Thu, Jun 22, 2023 at 10:25:17AM +0200, David Hildenbrand wrote:
> On 22.06.23 09:27, Vivek Kasireddy wrote:
> > The first patch ensures that the mappings needed for handling mmap
> > operation would be managed by using the pfn instead of struct page.
> > The second patch restores support for mapping hugetlb pages where
> > subpages of a hugepage are not directly used anymore (main reason
> > for revert) and instead the hugetlb pages and the relevant offsets
> > are used to populate the scatterlist for dma-buf export and for
> > mmap operation.
> >
> > Testcase: default_hugepagesz=2M hugepagesz=2M hugepages=2500 options
> > were passed to the Host kernel and Qemu was launched with these
> > relevant options: qemu-system-x86_64 -m 4096m....
> > -device virtio-gpu-pci,max_outputs=1,blob=true,xres=1920,yres=1080
> > -display gtk,gl=on
> > -object memory-backend-memfd,hugetlb=on,id=mem1,size=4096M
> > -machine memory-backend=mem1
> >
> > Replacing -display gtk,gl=on with -display gtk,gl=off above would
> > exercise the mmap handler.
> >
>
> While I think the VM_PFNMAP approach is much better and should fix that
> issue at hand, I thought more about missing memlock support and realized
> that we might have to fix something else. SO I'm going to raise the issue
> here.
>
> I think udmabuf chose the wrong interface to do what it's doing, that makes
> it harder to fix it eventually.
>
> Instead of accepting a range in a memfd, it should just have accepted a user
> space address range and then used pin_user_pages(FOLL_WRITE|FOLL_LONGTERM)
> to longterm-pin the pages "officially".
>
> So what's the issue? Udma effectively pins pages longterm ("possibly
> forever") simply by grabbing a reference on them. These pages might easily
> reside in ZONE_MOVABLE or in MIGRATE_CMA pageblocks.
>
> So what udmabuf does is break memory hotunplug and CMA, because it turns
> pages that have to remain movable unmovable.
>
> In the pin_user_pages(FOLL_LONGTERM) case we make sure to migrate these
> pages. See mm/gup.c:check_and_migrate_movable_pages() and especially
> folio_is_longterm_pinnable(). We'd probably have to implement something
> similar for udmabuf, where we detect such unpinnable pages and migrate them.
>
>
> For example, pairing udmabuf with vfio (which pins pages using
> pin_user_pages(FOLL_LONGTERM)) in QEMU will most probably not work in all
> cases: if udmabuf longterm pinned the pages "the wrong way", vfio will fail
> to migrate them during FOLL_LONGTERM and consequently fail pin_user_pages().
> As long as udmabuf holds a reference on these pages, that will never
> succeed.
Uh this is no good and I totally missed this, because the very first
version of udmabuf used pin_user_pages(FOLL_LONGTERM). I think what we
need here as first fix is a shmem_pin_mapping_page_longterm that does all
the equivalent of pin_user_pages(FOLL_LONGTERM), and use it in udmabuf.
From a quick look the folio conversions that already landed should help
there.
It might also be good if we convert all the gpu driver users of
shmem_read_mapping_page over to that new shmem_pin_mapping_page_longterm,
just for safety. gpu drivers use a private shmem file and adjust the gfp
mask to clear GFP_MOVEABLE, so the biggest issues shouldn't be possible.
But pin(LONGTERM) compared to just getting a page ref has gained quite a
few other differences in the past years, and it would be good to be
consistent I think.
Anything else than longterm pins wont work for udmabuf, because the
locking between struct page/gup.c/mmu_notifier and dma_buf is rather
fundamentally (and by design due to gpu driver requirements) incompatible
with dma_buf locking rules.
> There are *probably* more issues on the QEMU side when udmabuf is paired
> with things like MADV_DONTNEED/FALLOC_FL_PUNCH_HOLE used for virtio-balloon,
> virtio-mem, postcopy live migration, ... for example, in the vfio/vdpa case
> we make sure that we disallow most of these, because otherwise there can be
> an accidental "disconnect" between the pages mapped into the VM (guest view)
> and the pages mapped into the IOMMU (device view), for example, after a
> reboot.
I think once we have the proper longterm pinning for udmabuf we need to
look into what coherency issues are left, and how to best fix them.
udmabuf already requires that the memfd is size sealed to avoid some
issues, we might need to require more. Or on the other side, perhaps
reject or quietly ignore some of the hole punching for longterm pinned
pages, to maintain coherency.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 46+ messages in thread* Re: [PATCH v1 0/2] udmabuf: Add back support for mapping hugetlb pages
@ 2023-08-08 16:17 ` Daniel Vetter
0 siblings, 0 replies; 46+ messages in thread
From: Daniel Vetter @ 2023-08-08 16:17 UTC (permalink / raw)
To: David Hildenbrand
Cc: Vivek Kasireddy, dri-devel, linux-mm, James Houghton,
Jerome Marchand, Dongwon Kim, Junxiao Chang, Muchun Song,
Michal Hocko, Gerd Hoffmann, Jason Gunthorpe, John Hubbard,
Andrew Morton, Kirill A . Shutemov, Mike Kravetz
On Thu, Jun 22, 2023 at 10:25:17AM +0200, David Hildenbrand wrote:
> On 22.06.23 09:27, Vivek Kasireddy wrote:
> > The first patch ensures that the mappings needed for handling mmap
> > operation would be managed by using the pfn instead of struct page.
> > The second patch restores support for mapping hugetlb pages where
> > subpages of a hugepage are not directly used anymore (main reason
> > for revert) and instead the hugetlb pages and the relevant offsets
> > are used to populate the scatterlist for dma-buf export and for
> > mmap operation.
> >
> > Testcase: default_hugepagesz=2M hugepagesz=2M hugepages=2500 options
> > were passed to the Host kernel and Qemu was launched with these
> > relevant options: qemu-system-x86_64 -m 4096m....
> > -device virtio-gpu-pci,max_outputs=1,blob=true,xres=1920,yres=1080
> > -display gtk,gl=on
> > -object memory-backend-memfd,hugetlb=on,id=mem1,size=4096M
> > -machine memory-backend=mem1
> >
> > Replacing -display gtk,gl=on with -display gtk,gl=off above would
> > exercise the mmap handler.
> >
>
> While I think the VM_PFNMAP approach is much better and should fix that
> issue at hand, I thought more about missing memlock support and realized
> that we might have to fix something else. SO I'm going to raise the issue
> here.
>
> I think udmabuf chose the wrong interface to do what it's doing, that makes
> it harder to fix it eventually.
>
> Instead of accepting a range in a memfd, it should just have accepted a user
> space address range and then used pin_user_pages(FOLL_WRITE|FOLL_LONGTERM)
> to longterm-pin the pages "officially".
>
> So what's the issue? Udma effectively pins pages longterm ("possibly
> forever") simply by grabbing a reference on them. These pages might easily
> reside in ZONE_MOVABLE or in MIGRATE_CMA pageblocks.
>
> So what udmabuf does is break memory hotunplug and CMA, because it turns
> pages that have to remain movable unmovable.
>
> In the pin_user_pages(FOLL_LONGTERM) case we make sure to migrate these
> pages. See mm/gup.c:check_and_migrate_movable_pages() and especially
> folio_is_longterm_pinnable(). We'd probably have to implement something
> similar for udmabuf, where we detect such unpinnable pages and migrate them.
>
>
> For example, pairing udmabuf with vfio (which pins pages using
> pin_user_pages(FOLL_LONGTERM)) in QEMU will most probably not work in all
> cases: if udmabuf longterm pinned the pages "the wrong way", vfio will fail
> to migrate them during FOLL_LONGTERM and consequently fail pin_user_pages().
> As long as udmabuf holds a reference on these pages, that will never
> succeed.
Uh this is no good and I totally missed this, because the very first
version of udmabuf used pin_user_pages(FOLL_LONGTERM). I think what we
need here as first fix is a shmem_pin_mapping_page_longterm that does all
the equivalent of pin_user_pages(FOLL_LONGTERM), and use it in udmabuf.
From a quick look the folio conversions that already landed should help
there.
It might also be good if we convert all the gpu driver users of
shmem_read_mapping_page over to that new shmem_pin_mapping_page_longterm,
just for safety. gpu drivers use a private shmem file and adjust the gfp
mask to clear GFP_MOVEABLE, so the biggest issues shouldn't be possible.
But pin(LONGTERM) compared to just getting a page ref has gained quite a
few other differences in the past years, and it would be good to be
consistent I think.
Anything else than longterm pins wont work for udmabuf, because the
locking between struct page/gup.c/mmu_notifier and dma_buf is rather
fundamentally (and by design due to gpu driver requirements) incompatible
with dma_buf locking rules.
> There are *probably* more issues on the QEMU side when udmabuf is paired
> with things like MADV_DONTNEED/FALLOC_FL_PUNCH_HOLE used for virtio-balloon,
> virtio-mem, postcopy live migration, ... for example, in the vfio/vdpa case
> we make sure that we disallow most of these, because otherwise there can be
> an accidental "disconnect" between the pages mapped into the VM (guest view)
> and the pages mapped into the IOMMU (device view), for example, after a
> reboot.
I think once we have the proper longterm pinning for udmabuf we need to
look into what coherency issues are left, and how to best fix them.
udmabuf already requires that the memfd is size sealed to avoid some
issues, we might need to require more. Or on the other side, perhaps
reject or quietly ignore some of the hole punching for longterm pinned
pages, to maintain coherency.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply [flat|nested] 46+ messages in thread