[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220315143858.GY11336@nvidia.com>
Date: Tue, 15 Mar 2022 11:38:58 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Matthew Rosato <mjrosato@...ux.ibm.com>
Cc: linux-s390@...r.kernel.org, alex.williamson@...hat.com,
cohuck@...hat.com, schnelle@...ux.ibm.com, farman@...ux.ibm.com,
pmorel@...ux.ibm.com, borntraeger@...ux.ibm.com, hca@...ux.ibm.com,
gor@...ux.ibm.com, gerald.schaefer@...ux.ibm.com,
agordeev@...ux.ibm.com, svens@...ux.ibm.com, frankja@...ux.ibm.com,
david@...hat.com, imbrenda@...ux.ibm.com, vneethv@...ux.ibm.com,
oberpar@...ux.ibm.com, freude@...ux.ibm.com, thuth@...hat.com,
pasic@...ux.ibm.com, joro@...tes.org, will@...nel.org,
pbonzini@...hat.com, corbet@....net, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org, iommu@...ts.linux-foundation.org,
linux-doc@...r.kernel.org
Subject: Re: [PATCH v4 15/32] vfio: introduce KVM-owned IOMMU type
On Tue, Mar 15, 2022 at 09:49:01AM -0400, Matthew Rosato wrote:
> The rationale for splitting steps 1 and 2 are that VFIO_SET_IOMMU doesn't
> have a mechanism for specifying more than the type as an arg, no? Otherwise
> yes, you could specify a kvm fd at this point and it would have some other
> advantages (e.g. skip notifier). But we still can't use the IOMMU for
> mapping until step 3.
Stuff like this is why I'd be much happier if this could join our
iommfd project so we can have clean modeling of the multiple iommu_domains.
Jason
Powered by blists - more mailing lists