[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220718224635.GF4609@nvidia.com>
Date: Mon, 18 Jul 2022 19:46:35 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Alex Williamson <alex.williamson@...hat.com>
Cc: Yishai Hadas <yishaih@...dia.com>, saeedm@...dia.com,
kvm@...r.kernel.org, netdev@...r.kernel.org, kuba@...nel.org,
kevin.tian@...el.com, joao.m.martins@...cle.com, leonro@...dia.com,
maorg@...dia.com, cohuck@...hat.com
Subject: Re: [PATCH V2 vfio 05/11] vfio: Add an IOVA bitmap support
On Mon, Jul 18, 2022 at 04:30:10PM -0600, Alex Williamson wrote:
> > Signed-off-by: Joao Martins <joao.m.martins@...cle.com>
> > Signed-off-by: Yishai Hadas <yishaih@...dia.com>
> > ---
> > drivers/vfio/Makefile | 6 +-
> > drivers/vfio/iova_bitmap.c | 164 ++++++++++++++++++++++++++++++++++++
> > include/linux/iova_bitmap.h | 46 ++++++++++
>
> I'm still working my way through the guts of this, but why is it being
> proposed within the vfio driver when this is not at all vfio specific,
> proposes it's own separate header, and doesn't conform with any of the
> namespace conventions of being a sub-component of vfio? Is this
> ultimately meant for lib/ or perhaps an extension of iova.c within the
> iommu subsystem? Thanks,
I am expecting when iommufd dirty tracking comes we will move this
file into drivers/iommu/iommufd/ and it will provide it. So it was
written to make that a simple rename vs changing everything.
Until we have that, this seems like the best place for it
Jason
Powered by blists - more mailing lists