From: "Zhao, Yu" <yu.zhao@intel.com>
To: Matthew Wilcox <matthew@wil.cx>
Cc: "jbarnes@virtuousgeek.org" <jbarnes@virtuousgeek.org>,
"dwmw2@infradead.org" <dwmw2@infradead.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"iommu@lists.linux-foundation.org"
<iommu@lists.linux-foundation.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 0/6] ATS capability support for Intel IOMMU
Date: Fri, 13 Feb 2009 13:27:02 +0800 [thread overview]
Message-ID: <499504A6.3050107@intel.com> (raw)
In-Reply-To: <20090213034457.GM3624@parisc-linux.org>
Matthew Wilcox wrote:
> On Thu, Feb 12, 2009 at 08:50:32PM +0800, Yu Zhao wrote:
>> 2, avoid using pci_find_ext_capability every time when reading ATS
>> Invalidate Queue Depth (Matthew Wilcox)
>
> er ... I didn't say it was a problem. I said I couldn't tell if it was a
> problem. There's no point in taking up an extra 4 bytes per pci_dev if
> it's not a performance problem. How often do we query the queue depth?
> Is this something a device driver will call once per device and then
> remember for itself, or only use at setup? Or is it something we call
> every millisecond?
>
The query function is called only once per device in v2 patch series. The
queue depth is cached in a VT-d private data structure, and it's used when
device driver calls pci_unmap_single or pci_unmap_sg. My concern was that
packing everything into `pci_dev' would make it grows very fast.
For v3, the queue depth is removed from the VT-d `device_domain_info'.
Instead, it's cached in `pci_dev', and the query function is called every
time when the queue depth is needed. It would be easier to write the
IOMMU-specific ATS code for AMD, IBM and other vendors' IOMMUs, if they
have same requirement as Intel's (needs to query the queue depth every
time when invalidating the IOMMU TLB cache inside the device). So it looks
having the queue depth in `pci_dev' is reasonable, but I'm not sure.
Following is the logics I used in v2.
diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c
index 261b6bd..a7ff7cb 100644
--- a/drivers/pci/intel-iommu.c
+++ b/drivers/pci/intel-iommu.c
@@ -240,6 +241,8 @@ struct device_domain_info {
struct list_head global; /* link to global list */
u8 bus; /* PCI bus numer */
u8 devfn; /* PCI devfn number */
+ int qdep; /* invalidate queue depth */
+ struct intel_iommu *iommu; /* IOMMU used by this device */
struct pci_dev *dev; /* it's NULL for PCIE-to-PCI bridge */
struct dmar_domain *domain; /* pointer to domain */
};
<snipped>
+ info->iommu = iommu;
+ info->qdep = pci_ats_qdep(info->dev);
+ if (!info->qdep)
+ return NULL;
<snipped>
+ list_for_each_entry(info, &domain->devices, link) {
+ if (!info->dev || !pci_ats_enabled(info->dev))
+ continue;
+
+ sid = info->bus << 8 | info->devfn;
+ rc = qi_flush_dev_iotlb(info->iommu, sid,
+ info->qdep, addr, mask);
+ if (rc)
+ printk(KERN_ERR "IOMMU: flush device IOTLB failed\n");
+ }
+ spin_unlock_irqrestore(&device_domain_lock, flags);
+}
next prev parent reply other threads:[~2009-02-13 5:27 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-12 12:50 [PATCH v3 0/6] ATS capability support for Intel IOMMU Yu Zhao
2009-02-12 12:50 ` [PATCH v3 1/6] PCI: support the ATS capability Yu Zhao
2009-02-12 12:50 ` [PATCH v3 2/6] VT-d: parse ATSR in DMA Remapping Reporting Structure Yu Zhao
2009-02-12 12:50 ` [PATCH v3 3/6] VT-d: add queue invalidation fault status support Yu Zhao
2009-02-12 12:50 ` [PATCH v3 4/6] VT-d: add device IOTLB invalidation support Yu Zhao
2009-02-12 12:50 ` [PATCH v3 5/6] VT-d: cleanup iommu_flush_iotlb_psi and flush_unmaps Yu Zhao
2009-02-12 12:50 ` [PATCH v3 6/6] VT-d: support the device IOTLB Yu Zhao
2009-02-14 23:20 ` Grant Grundler
2009-02-26 3:21 ` Yu Zhao
2009-02-13 3:44 ` [PATCH v3 0/6] ATS capability support for Intel IOMMU Matthew Wilcox
2009-02-13 5:27 ` Zhao, Yu [this message]
2009-02-14 22:59 ` Grant Grundler
2009-02-26 2:50 ` Yu Zhao
2009-02-26 3:46 ` Greg KH
2009-02-27 7:19 ` Grant Grundler
2009-03-20 2:30 ` Jesse Barnes
2009-03-20 2:30 ` Jesse Barnes
2009-03-20 2:47 ` Zhao, Yu
2009-03-20 11:15 ` David Woodhouse
2009-03-23 5:22 ` Yu Zhao
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=499504A6.3050107@intel.com \
--to=yu.zhao@intel.com \
--cc=dwmw2@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--cc=jbarnes@virtuousgeek.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=matthew@wil.cx \
/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