linux-kernel - Re: [PATCH 04/13] pci: New pci_dma

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 16 May 2012 22:06:53 -0600
From:	Alex Williamson <alex.williamson@...hat.com>
To:	David Gibson <david@...son.dropbear.id.au>
Cc:	benh@...nel.crashing.org, aik@...abs.ru, joerg.roedel@....com,
	dwmw2@...radead.org, chrisw@...s-sol.org, agraf@...e.de,
	benve@...co.com, aafabbri@...co.com, B08248@...escale.com,
	B07421@...escale.com, avi@...hat.com, konrad.wilk@...cle.com,
	kvm@...r.kernel.org, qemu-devel@...gnu.org,
	iommu@...ts.linux-foundation.org, linux-pci@...r.kernel.org,
	linux-kernel@...r.kernel.org, gregkh@...uxfoundation.org,
	bhelgaas@...gle.com
Subject: Re: [PATCH 04/13] pci: New pci_dma_quirk()

On Thu, 2012-05-17 at 13:39 +1000, David Gibson wrote:
> On Fri, May 11, 2012 at 04:55:55PM -0600, Alex Williamson wrote:
> > Integrating IOMMU groups more closely into the driver core allows
> > us to more easily work around DMA quirks.  The Ricoh multifunction
> > controller is a favorite example of devices that are currently
> > incompatible with IOMMU isolation as all the functions use the
> > requestor ID of function 0 for DMA.  Passing this device into
> > pci_dma_quirk returns the PCI device to use for DMA.  The IOMMU
> > driver can then construct an IOMMU group including both devices.
> > 
> > Signed-off-by: Alex Williamson <alex.williamson@...hat.com>
> > ---
> > 
> >  drivers/pci/quirks.c |   22 ++++++++++++++++++++++
> >  include/linux/pci.h  |    2 ++
> >  2 files changed, 24 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> > index 4bf7102..6f9f7f9 100644
> > --- a/drivers/pci/quirks.c
> > +++ b/drivers/pci/quirks.c
> > @@ -3109,3 +3109,25 @@ int pci_dev_specific_reset(struct pci_dev *dev, int probe)
> >  
> >  	return -ENOTTY;
> >  }
> > +
> > +struct pci_dev *pci_dma_quirk(struct pci_dev *dev)
> > +{
> > +	struct pci_dev *dma_dev = dev;
> > +
> > +	/*
> > +	 * https://bugzilla.redhat.com/show_bug.cgi?id=605888
> > +	 *
> > +	 * Some Ricoh devices use the function 0 source ID for DMA on
> > +	 * other functions of a multifunction device.  The DMA devices
> > +	 * is therefore function 0, which will have implications of the
> > +	 * iommu grouping of these devices.
> > +	 */
> > +	if (dev->vendor == PCI_VENDOR_ID_RICOH &&
> > +	    (dev->device == 0xe822 || dev->device == 0xe230 ||
> > +	     dev->device == 0xe832 || dev->device == 0xe476)) {
> > +		dma_dev = pci_get_slot(dev->bus,
> > +				       PCI_DEVFN(PCI_SLOT(dev->devfn), 0));
> > +	}
> 
> Hrm.  This seems like a very generic name for a function performing a
> very specific test.  We could well have devices with the same problem
> in future, so shouldn't this be set up so the same quirk can be easily
> added to new device ids without changing the function code itself.

I've since added a USB quirk here to group all the USB functions in a
slot.  I'll take a closer look at the quirk helpers to see if anything
makes this easier, but I didn't see much point in spending a lot of time
over-optimizing this for 1 or 2 quirks that we can just step through in
a monolithic function.  Thanks,

Alex

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/