From: "George Spelvin" <linux@horizon.com>
To: acooks@gmail.com, alex.williamson@redhat.com, linux@horizon.com
Cc: iommu@lists.linux-foundation.org, linux-ide@vger.kernel.org,
linux-pci@vger.kernel.org
Subject: Re: [PATCH] Quirk for buggy dma source tags with Intel IOMMU.
Date: 20 Jan 2014 21:00:42 -0500 [thread overview]
Message-ID: <20140121020042.29941.qmail@science.horizon.com> (raw)
In-Reply-To: <CAJtEV7bkfB=REaJkf+jb33_2h=_5YoZogQNw4SKmmWwZcF8NZA@mail.gmail.com>
New recipient: Alex Williamson, who added the pci_get_dma_source()
quirk that resembles this one.
Alex, Andrew is working on a patch to fix some more buggy
PCIe devices like the Ricoh ones that you added a quirk for.
His current patch can be found at
https://bugzilla.kernel.org/show_bug.cgi?id=42679#c22
Ir only works on Intel IOMMUs, and sort of duplicates the functionality
of your quirk.
Obviously, I hate the duplication and would like to fold them together,
but there are a few fundamental differences.
Most notably, Andrew's patch enables the incorrect requester ID
*in addition to* the correct one. I'm not sure if this is necessary,
but it seems like a nice defensive feature in case the vendor fixes
the problem in a minor rev, and the ability is also needed by PCIe
phantom function support,
The other thing is that pci_get_dma_source returns a pci_dev, but
Andrew's patch deals with devices which use requester IDs which
don't correspond to existing PCI devices at all:
- Marvell SATA controllers which exist only as devid 00.0, but generate
request devids of 00.1. (The latter function might be PATA support
on chips which support that.)
- Mellanox 26428 Infiniband controllers which also only provide one
function, but use a source devid of 00.6
- An LSI MegaRAID SAS 2078 PCI-X controller that is device 0e.0, but
generates request devids of 08.0
- An Adaptec RAID controller ie 0e.0 that makes requests as 01.0.
My thought for implementing Andrew's version was to add an 8-bit devfn_quirk
field to struct pci_dev that contains the delta to the devfn that will
appear in the source requester ID.
(By using a delta rather than the target value, the default value of 0
means "no quirk".)
This would be initialized at boot time using a standard PCI quirk,
avoiding the need for linearly searching potentially long device lists
every time an IOMMU mapping is set up.
(Even if I only use a single-bit flag, that would avoid the list
searching for all the non-buggy devices.)
But I'm not quite sure what the locking rules are on the whole swap_pci_ref
business. Or if the Ricoh devices have to be handled more carefully
because multiple functions need to arbitrate over the IOMMU tables
for function 0.
Can I request some sage guidance from someone with more experience in the
area?
Thank you!
next prev parent reply other threads:[~2014-01-21 2:00 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-20 13:13 [PATCH] Quirk for buggy dma source tags with Intel IOMMU George Spelvin
2014-01-20 15:45 ` Andrew Cooks
2014-01-20 19:01 ` George Spelvin
[not found] ` <20140120190102.13636.qmail-FT9nftu9LUyCkawlElnc8EEOCMrvLtNR@public.gmane.org>
2014-01-20 23:45 ` Andrew Cooks
2014-01-21 2:00 ` George Spelvin [this message]
[not found] ` <20140121020042.29941.qmail-FT9nftu9LUyCkawlElnc8EEOCMrvLtNR@public.gmane.org>
2014-01-21 2:52 ` Andrew Cooks
2014-01-21 3:53 ` George Spelvin
2014-01-20 23:35 ` George Spelvin
[not found] ` <20140120233543.15159.qmail-FT9nftu9LUyCkawlElnc8EEOCMrvLtNR@public.gmane.org>
2014-01-21 1:54 ` Andrew Cooks
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140121020042.29941.qmail@science.horizon.com \
--to=linux@horizon.com \
--cc=acooks@gmail.com \
--cc=alex.williamson@redhat.com \
--cc=iommu@lists.linux-foundation.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).