Sean Christopherson <[email protected]> writes: > On Thu, Jun 04, 2026, Ackerley Tng wrote: >> Sean Christopherson <[email protected]> writes: >> >> + KVM: selftests: Test conversion with elevated page refcount >> >> + Askar pointed out that soon vmsplice may not pin pages. Should I >> >> pin pages through CONFIG_GUP_TEST like in [2]? I prefer not to >> >> take a dependency on CONFIG_GUP_TEST. >> > >> > I'm not exactly excited about taking a dependency on CONFIG_GUP_TEST >> > either, but >> > it probably is the least awful choice. E.g. KVM also pins pages is >> > certain flows, >> > but we're _also_ actively working to remove the need to pin. >> > >> > Hmm, maybe IORING_REGISTER_PBUF_RING? AFAICT, it's almost literally a >> > "pin user >> > memory" syscall. >> > >> >> Hmm that takes a dependency on io_uring, which isn't always compiled >> in. Between CONFIG_IO_URING and CONFIG_GUP_TEST, I'd rather >> CONFIG_GUP_TEST. > > Or try both? If it's not a ridiculous amount of work.
CONFIG_GUP_TEST was tried in [1] [1] https://lore.kernel.org/all/baa8838f623102931e755cf34c86314b305af49c.1747264138.git.ackerley...@google.com/ It looks like this static void pin_pages(void *vaddr, uint64_t size) { const struct pin_longterm_test args = { .addr = (uint64_t)vaddr, .size = size, .flags = PIN_LONGTERM_TEST_FLAG_USE_WRITE, }; gup_test_fd = open("/sys/kernel/debug/gup_test", O_RDWR); TEST_REQUIRE(gup_test_fd > 0); TEST_ASSERT_EQ(ioctl(gup_test_fd, PIN_LONGTERM_TEST_START, &args), 0); } static void unpin_pages(void) { TEST_ASSERT_EQ(ioctl(gup_test_fd, PIN_LONGTERM_TEST_STOP), 0); } So in the test I'll call pin_pages(), then try to convert, see that it fails with EAGAIN and reports the expected error_offset, then I call unpin_pages(), then I convert again and expect success. Are you uncomfortable with the CONFIG_GUP_TEST interface? What would you like me to try with CONFIG_IO_URING? I'm thinking that the main difference between the two is just down to which non-default CONFIG option we want to take for guest_memfd tests.
