[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250617230030.GB1575786@nvidia.com>
Date: Tue, 17 Jun 2025 20:00:30 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Peter Xu <peterx@...hat.com>
Cc: kernel test robot <lkp@...el.com>, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, kvm@...r.kernel.org,
oe-kbuild-all@...ts.linux.dev,
Andrew Morton <akpm@...ux-foundation.org>,
Alex Williamson <alex.williamson@...hat.com>,
Zi Yan <ziy@...dia.com>, Alex Mastro <amastro@...com>,
David Hildenbrand <david@...hat.com>,
Nico Pache <npache@...hat.com>
Subject: Re: [PATCH 4/5] vfio: Introduce vfio_device_ops.get_unmapped_area
hook
On Tue, Jun 17, 2025 at 04:01:11PM -0400, Peter Xu wrote:
> > So what is VFIO doing that requires CONFIG_ARCH_SUPPORTS_HUGE_PFNMAP?
>
> It's the fallback part for vfio device, not vfio_pci device. vfio_pci
> device doesn't need this special treatment after moving to the new helper
> because that hides everything. vfio_device still needs it.
>
> So, we have two ops that need to be touched to support this:
>
> vfio_device_fops
> vfio_pci_ops
>
> For the 1st one's vfio_device_fops.get_unmapped_area(), it'll need its own
> fallback which must be mm_get_unmapped_area() to keep the old behavior, and
> that was defined only if CONFIG_MMU.
OK, CONFIG_MMU makes a little bit of sense
> IOW, if one day file_operations.get_unmapped_area() would allow some other
> retval to be able to fallback to the default (mm_get_unmapped_area()), then
> we don't need this special ifdef. But now it's not ready for that..
That can't be fixed with a config, the logic in vfio_device_fops has
to be
if (!device->ops->get_unmapped_area()
return .. do_default thing..
return device->ops->get_unmapped()
Has nothing to do with CONFIG_ARCH_SUPPORTS_HUGE_PFNMAP, there are
more device->ops that just PCI.
If you do the API with an align/order argument then the default
behavior should happen when passing PAGE_SIZE.
Jason
Powered by blists - more mailing lists