Re: [PATCH v5 07/14] PCI: Add driver dma ownership management

2022-02-23 Thread Jason Gunthorpe via iommu
On Wed, Feb 23, 2022 at 12:00:56PM -0600, Bjorn Helgaas wrote:

> >  static int pci_dma_configure(struct device *dev)
> >  {
> > +   struct pci_driver *driver = to_pci_driver(dev->driver);
> > struct device *bridge;
> > int ret = 0;
> >  
> > +   if (!driver->no_kernel_api_dma) {
> 
> Ugh.  Double negative, totally agree this needs a better name that
> reverses the sense.  Every place you use it, you negate it again.

Greg came up with driver_managed_dma which is in the v6 version:

https://lore.kernel.org/all/20220218005521.172832-5-baolu...@linux.intel.com/

Thanks,
Jason
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v5 07/14] PCI: Add driver dma ownership management

2022-02-23 Thread Bjorn Helgaas
In subject,

s/dma/DMA/ to match the other patches

On Tue, Jan 04, 2022 at 09:56:37AM +0800, Lu Baolu wrote:
> Multiple PCI devices may be placed in the same IOMMU group because
> they cannot be isolated from each other. These devices must either be
> entirely under kernel control or userspace control, never a mixture. This
> checks and sets DMA ownership during driver binding, and release the
> ownership during driver unbinding.
> 
> The device driver may set a new flag (no_kernel_api_dma) to skip calling
> iommu_device_use_dma_api() during the binding process. For instance, the
> userspace framework drivers (vfio etc.) which need to manually claim
> their own dma ownership when assigning the device to userspace.

s/vfio/VFIO/ when used as an acronym (occurs in several patches)

> + * @no_kernel_api_dma: Device driver doesn't use kernel DMA API for DMA.
> + *   Drivers which don't require DMA or want to manually claim the
> + *   owner type (e.g. userspace driver frameworks) could set this
> + *   flag.

s/Drivers which/Drivers that/

>  static int pci_dma_configure(struct device *dev)
>  {
> + struct pci_driver *driver = to_pci_driver(dev->driver);
>   struct device *bridge;
>   int ret = 0;
>  
> + if (!driver->no_kernel_api_dma) {

Ugh.  Double negative, totally agree this needs a better name that
reverses the sense.  Every place you use it, you negate it again.

> + if (ret && !driver->no_kernel_api_dma)
> + iommu_device_unuse_dma_api(dev);

> +static void pci_dma_cleanup(struct device *dev)
> +{
> + struct pci_driver *driver = to_pci_driver(dev->driver);
> +
> + if (!driver->no_kernel_api_dma)
> + iommu_device_unuse_dma_api(dev);
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v5 07/14] PCI: Add driver dma ownership management

2022-02-14 Thread Lu Baolu

On 2/14/22 9:43 PM, Jason Gunthorpe wrote:

On Mon, Feb 14, 2022 at 02:39:18PM +0100, Greg Kroah-Hartman wrote:


A driver that sets this flag can still decide to enable the dma API on
its own. eg tegra drivers do this.


So you are just forcing the driver to manage this all on their own, so
how about, "driver_managed_dma", or even shorter "managed_dma"?


Yeah, I like "driver_managed_dma" alot, it captures the entire idea


This makes a lot of sense. For most drivers, they don't need to care
about this flag as all DMAs are handled through the kernel DMA API. For
VFIO or similar drivers, they know how to manage the DMA themselves and
set this flag so that the IOMMU layer will allow them to setup and
manage their own I/O address space.

If there is no better naming, I'd like to use this and add some comments
for device drivers developers.

Thanks a lot to Greg and Jason.

Best regards,
baolu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v5 07/14] PCI: Add driver dma ownership management

2022-02-14 Thread Jason Gunthorpe via iommu
On Mon, Feb 14, 2022 at 02:39:18PM +0100, Greg Kroah-Hartman wrote:

> > A driver that sets this flag can still decide to enable the dma API on
> > its own. eg tegra drivers do this.
> 
> So you are just forcing the driver to manage this all on their own, so
> how about, "driver_managed_dma", or even shorter "managed_dma"?

Yeah, I like "driver_managed_dma" alot, it captures the entire idea

Thanks,
Jason
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v5 07/14] PCI: Add driver dma ownership management

2022-02-14 Thread Greg Kroah-Hartman
On Mon, Feb 14, 2022 at 09:11:17AM -0400, Jason Gunthorpe wrote:
> On Mon, Feb 14, 2022 at 01:51:06PM +0100, Greg Kroah-Hartman wrote:
> > On Mon, Feb 14, 2022 at 08:38:42AM -0400, Jason Gunthorpe wrote:
> > > On Mon, Feb 14, 2022 at 11:03:42AM +0100, Greg Kroah-Hartman wrote:
> > > > On Tue, Jan 04, 2022 at 09:56:37AM +0800, Lu Baolu wrote:
> > > > > Multiple PCI devices may be placed in the same IOMMU group because
> > > > > they cannot be isolated from each other. These devices must either be
> > > > > entirely under kernel control or userspace control, never a mixture. 
> > > > > This
> > > > > checks and sets DMA ownership during driver binding, and release the
> > > > > ownership during driver unbinding.
> > > > > 
> > > > > The device driver may set a new flag (no_kernel_api_dma) to skip 
> > > > > calling
> > > > > iommu_device_use_dma_api() during the binding process. For instance, 
> > > > > the
> > > > > userspace framework drivers (vfio etc.) which need to manually claim
> > > > > their own dma ownership when assigning the device to userspace.
> > > > > 
> > > > > Signed-off-by: Lu Baolu 
> > > > >  include/linux/pci.h  |  5 +
> > > > >  drivers/pci/pci-driver.c | 21 +
> > > > >  2 files changed, 26 insertions(+)
> > > > > 
> > > > > diff --git a/include/linux/pci.h b/include/linux/pci.h
> > > > > index 18a75c8e615c..d29a990e3f02 100644
> > > > > +++ b/include/linux/pci.h
> > > > > @@ -882,6 +882,10 @@ struct module;
> > > > >   *  created once it is bound to the driver.
> > > > >   * @driver:  Driver model structure.
> > > > >   * @dynids:  List of dynamically added device IDs.
> > > > > + * @no_kernel_api_dma: Device driver doesn't use kernel DMA API for 
> > > > > DMA.
> > > > > + *   Drivers which don't require DMA or want to manually 
> > > > > claim the
> > > > > + *   owner type (e.g. userspace driver frameworks) could set 
> > > > > this
> > > > > + *   flag.
> > > > 
> > > > Again with the bikeshedding, but this name is a bit odd.  Of course it's
> > > > in the kernel, this is all kernel code, so you can drop that.  And
> > > > again, "negative" flags are rough.  So maybe just "prevent_dma"?
> > > 
> > > That is misleading too, it is not that DMA is prevented, but that the
> > > kernel's dma_api has not been setup.
> > 
> > "has not been" or "will not be"?
> 
> "has not been" as that action was supposed to happen before probe(),
> but the flag skips it.
> 
> A driver that sets this flag can still decide to enable the dma API on
> its own. eg tegra drivers do this.

So you are just forcing the driver to manage this all on their own, so
how about, "driver_managed_dma", or even shorter "managed_dma"?

> > What you want to prevent is the iommu core claiming the device
> > automatically, right?  So how about "prevent_iommu_dma"?
> 
> "claim" is not a good description. iommu always "claims" the device -
> eg sets a domain, sets the dev and bus parameters, etc.
> 
> This really is only about setting up the in-kernel dma api, eg
> allowing dma_map_sg()/etc to work.
> 
> dma api is just one way to operate the iommu, there are others too.
> 
> Think of this flag as 
>   false = the driver is going to use the dma api (most common)
>   true = the driver will decide how to use the iommu by itself
> 
> Does it help think of a clearer name?

See above, you want a driver author to know instantly what this is and
not have to look anything up.
"I_will_manage_the_dma_myself_as_I_really_know_what_I_am_doing" might be
good, but a bit too long :)

thanks,

greg k-h
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v5 07/14] PCI: Add driver dma ownership management

2022-02-14 Thread Jason Gunthorpe via iommu
On Mon, Feb 14, 2022 at 01:51:06PM +0100, Greg Kroah-Hartman wrote:
> On Mon, Feb 14, 2022 at 08:38:42AM -0400, Jason Gunthorpe wrote:
> > On Mon, Feb 14, 2022 at 11:03:42AM +0100, Greg Kroah-Hartman wrote:
> > > On Tue, Jan 04, 2022 at 09:56:37AM +0800, Lu Baolu wrote:
> > > > Multiple PCI devices may be placed in the same IOMMU group because
> > > > they cannot be isolated from each other. These devices must either be
> > > > entirely under kernel control or userspace control, never a mixture. 
> > > > This
> > > > checks and sets DMA ownership during driver binding, and release the
> > > > ownership during driver unbinding.
> > > > 
> > > > The device driver may set a new flag (no_kernel_api_dma) to skip calling
> > > > iommu_device_use_dma_api() during the binding process. For instance, the
> > > > userspace framework drivers (vfio etc.) which need to manually claim
> > > > their own dma ownership when assigning the device to userspace.
> > > > 
> > > > Signed-off-by: Lu Baolu 
> > > >  include/linux/pci.h  |  5 +
> > > >  drivers/pci/pci-driver.c | 21 +
> > > >  2 files changed, 26 insertions(+)
> > > > 
> > > > diff --git a/include/linux/pci.h b/include/linux/pci.h
> > > > index 18a75c8e615c..d29a990e3f02 100644
> > > > +++ b/include/linux/pci.h
> > > > @@ -882,6 +882,10 @@ struct module;
> > > >   *  created once it is bound to the driver.
> > > >   * @driver:Driver model structure.
> > > >   * @dynids:List of dynamically added device IDs.
> > > > + * @no_kernel_api_dma: Device driver doesn't use kernel DMA API for 
> > > > DMA.
> > > > + * Drivers which don't require DMA or want to manually 
> > > > claim the
> > > > + * owner type (e.g. userspace driver frameworks) could set 
> > > > this
> > > > + * flag.
> > > 
> > > Again with the bikeshedding, but this name is a bit odd.  Of course it's
> > > in the kernel, this is all kernel code, so you can drop that.  And
> > > again, "negative" flags are rough.  So maybe just "prevent_dma"?
> > 
> > That is misleading too, it is not that DMA is prevented, but that the
> > kernel's dma_api has not been setup.
> 
> "has not been" or "will not be"?

"has not been" as that action was supposed to happen before probe(),
but the flag skips it.

A driver that sets this flag can still decide to enable the dma API on
its own. eg tegra drivers do this.

> What you want to prevent is the iommu core claiming the device
> automatically, right?  So how about "prevent_iommu_dma"?

"claim" is not a good description. iommu always "claims" the device -
eg sets a domain, sets the dev and bus parameters, etc.

This really is only about setting up the in-kernel dma api, eg
allowing dma_map_sg()/etc to work.

dma api is just one way to operate the iommu, there are others too.

Think of this flag as 
  false = the driver is going to use the dma api (most common)
  true = the driver will decide how to use the iommu by itself

Does it help think of a clearer name?

Jason
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v5 07/14] PCI: Add driver dma ownership management

2022-02-14 Thread Greg Kroah-Hartman
On Mon, Feb 14, 2022 at 08:38:42AM -0400, Jason Gunthorpe wrote:
> On Mon, Feb 14, 2022 at 11:03:42AM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Jan 04, 2022 at 09:56:37AM +0800, Lu Baolu wrote:
> > > Multiple PCI devices may be placed in the same IOMMU group because
> > > they cannot be isolated from each other. These devices must either be
> > > entirely under kernel control or userspace control, never a mixture. This
> > > checks and sets DMA ownership during driver binding, and release the
> > > ownership during driver unbinding.
> > > 
> > > The device driver may set a new flag (no_kernel_api_dma) to skip calling
> > > iommu_device_use_dma_api() during the binding process. For instance, the
> > > userspace framework drivers (vfio etc.) which need to manually claim
> > > their own dma ownership when assigning the device to userspace.
> > > 
> > > Signed-off-by: Lu Baolu 
> > >  include/linux/pci.h  |  5 +
> > >  drivers/pci/pci-driver.c | 21 +
> > >  2 files changed, 26 insertions(+)
> > > 
> > > diff --git a/include/linux/pci.h b/include/linux/pci.h
> > > index 18a75c8e615c..d29a990e3f02 100644
> > > +++ b/include/linux/pci.h
> > > @@ -882,6 +882,10 @@ struct module;
> > >   *  created once it is bound to the driver.
> > >   * @driver:  Driver model structure.
> > >   * @dynids:  List of dynamically added device IDs.
> > > + * @no_kernel_api_dma: Device driver doesn't use kernel DMA API for DMA.
> > > + *   Drivers which don't require DMA or want to manually 
> > > claim the
> > > + *   owner type (e.g. userspace driver frameworks) could set 
> > > this
> > > + *   flag.
> > 
> > Again with the bikeshedding, but this name is a bit odd.  Of course it's
> > in the kernel, this is all kernel code, so you can drop that.  And
> > again, "negative" flags are rough.  So maybe just "prevent_dma"?
> 
> That is misleading too, it is not that DMA is prevented, but that the
> kernel's dma_api has not been setup.

"has not been" or "will not be"?

What you want to prevent is the iommu core claiming the device
automatically, right?  So how about "prevent_iommu_dma"?

naming is hard,

greg k-h
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v5 07/14] PCI: Add driver dma ownership management

2022-02-14 Thread Jason Gunthorpe via iommu
On Mon, Feb 14, 2022 at 11:03:42AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 04, 2022 at 09:56:37AM +0800, Lu Baolu wrote:
> > Multiple PCI devices may be placed in the same IOMMU group because
> > they cannot be isolated from each other. These devices must either be
> > entirely under kernel control or userspace control, never a mixture. This
> > checks and sets DMA ownership during driver binding, and release the
> > ownership during driver unbinding.
> > 
> > The device driver may set a new flag (no_kernel_api_dma) to skip calling
> > iommu_device_use_dma_api() during the binding process. For instance, the
> > userspace framework drivers (vfio etc.) which need to manually claim
> > their own dma ownership when assigning the device to userspace.
> > 
> > Signed-off-by: Lu Baolu 
> >  include/linux/pci.h  |  5 +
> >  drivers/pci/pci-driver.c | 21 +
> >  2 files changed, 26 insertions(+)
> > 
> > diff --git a/include/linux/pci.h b/include/linux/pci.h
> > index 18a75c8e615c..d29a990e3f02 100644
> > +++ b/include/linux/pci.h
> > @@ -882,6 +882,10 @@ struct module;
> >   *  created once it is bound to the driver.
> >   * @driver:Driver model structure.
> >   * @dynids:List of dynamically added device IDs.
> > + * @no_kernel_api_dma: Device driver doesn't use kernel DMA API for DMA.
> > + * Drivers which don't require DMA or want to manually claim the
> > + * owner type (e.g. userspace driver frameworks) could set this
> > + * flag.
> 
> Again with the bikeshedding, but this name is a bit odd.  Of course it's
> in the kernel, this is all kernel code, so you can drop that.  And
> again, "negative" flags are rough.  So maybe just "prevent_dma"?

That is misleading too, it is not that DMA is prevented, but that the
kernel's dma_api has not been setup.

Though I agree the name as-is isn't great, I think the comment is good.

Jason
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v5 07/14] PCI: Add driver dma ownership management

2022-02-14 Thread Greg Kroah-Hartman
On Tue, Jan 04, 2022 at 09:56:37AM +0800, Lu Baolu wrote:
> Multiple PCI devices may be placed in the same IOMMU group because
> they cannot be isolated from each other. These devices must either be
> entirely under kernel control or userspace control, never a mixture. This
> checks and sets DMA ownership during driver binding, and release the
> ownership during driver unbinding.
> 
> The device driver may set a new flag (no_kernel_api_dma) to skip calling
> iommu_device_use_dma_api() during the binding process. For instance, the
> userspace framework drivers (vfio etc.) which need to manually claim
> their own dma ownership when assigning the device to userspace.
> 
> Signed-off-by: Lu Baolu 
> ---
>  include/linux/pci.h  |  5 +
>  drivers/pci/pci-driver.c | 21 +
>  2 files changed, 26 insertions(+)
> 
> diff --git a/include/linux/pci.h b/include/linux/pci.h
> index 18a75c8e615c..d29a990e3f02 100644
> --- a/include/linux/pci.h
> +++ b/include/linux/pci.h
> @@ -882,6 +882,10 @@ struct module;
>   *  created once it is bound to the driver.
>   * @driver:  Driver model structure.
>   * @dynids:  List of dynamically added device IDs.
> + * @no_kernel_api_dma: Device driver doesn't use kernel DMA API for DMA.
> + *   Drivers which don't require DMA or want to manually claim the
> + *   owner type (e.g. userspace driver frameworks) could set this
> + *   flag.

Again with the bikeshedding, but this name is a bit odd.  Of course it's
in the kernel, this is all kernel code, so you can drop that.  And
again, "negative" flags are rough.  So maybe just "prevent_dma"?

thanks,

greg k-h
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu