From: "Roedel, Joerg" <Joerg.Roedel@amd.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: chrisw <chrisw@sous-sol.org>,
Alexey Kardashevskiy <aik@au1.ibm.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
Paul Mackerras <pmac@au1.ibm.com>,
qemu-devel <qemu-devel@nongnu.org>,
Aaron Fabbri <aafabbri@cisco.com>,
iommu <iommu@lists.linux-foundation.org>,
Avi Kivity <avi@redhat.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
"benve@cisco.com" <benve@cisco.com>
Subject: Re: [Qemu-devel] kvm PCI assignment & VFIO ramblings
Date: Thu, 25 Aug 2011 12:54:02 +0200 [thread overview]
Message-ID: <20110825105402.GB1923@amd.com> (raw)
In-Reply-To: <1314220434.2859.203.camel@bling.home>
Hi Alex,
On Wed, Aug 24, 2011 at 05:13:49PM -0400, Alex Williamson wrote:
> Is this roughly what you're thinking of for the iommu_group component?
> Adding a dev_to_group iommu ops callback let's us consolidate the sysfs
> support in the iommu base. Would AMD-Vi do something similar (or
> exactly the same) for group #s? Thanks,
The concept looks good, I have some comments, though. On AMD-Vi the
implementation would look a bit different because there is a
data-structure were the information can be gathered from, so no need for
PCI bus scanning there.
> diff --git a/drivers/base/iommu.c b/drivers/base/iommu.c
> index 6e6b6a1..6b54c1a 100644
> --- a/drivers/base/iommu.c
> +++ b/drivers/base/iommu.c
> @@ -17,20 +17,56 @@
> */
>
> #include <linux/bug.h>
> +#include <linux/device.h>
> #include <linux/types.h>
> #include <linux/module.h>
> #include <linux/slab.h>
> #include <linux/errno.h>
> #include <linux/iommu.h>
> +#include <linux/pci.h>
>
> static struct iommu_ops *iommu_ops;
>
> +static ssize_t show_iommu_group(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "%lx", iommu_dev_to_group(dev));
Probably add a 0x prefix so userspace knows the format?
> +}
> +static DEVICE_ATTR(iommu_group, S_IRUGO, show_iommu_group, NULL);
> +
> +static int add_iommu_group(struct device *dev, void *unused)
> +{
> + if (iommu_dev_to_group(dev) >= 0)
> + return device_create_file(dev, &dev_attr_iommu_group);
> +
> + return 0;
> +}
> +
> +static int device_notifier(struct notifier_block *nb,
> + unsigned long action, void *data)
> +{
> + struct device *dev = data;
> +
> + if (action == BUS_NOTIFY_ADD_DEVICE)
> + return add_iommu_group(dev, NULL);
> +
> + return 0;
> +}
> +
> +static struct notifier_block device_nb = {
> + .notifier_call = device_notifier,
> +};
> +
> void register_iommu(struct iommu_ops *ops)
> {
> if (iommu_ops)
> BUG();
>
> iommu_ops = ops;
> +
> + /* FIXME - non-PCI, really want for_each_bus() */
> + bus_register_notifier(&pci_bus_type, &device_nb);
> + bus_for_each_dev(&pci_bus_type, NULL, NULL, add_iommu_group);
> }
We need to solve this differently. ARM is starting to use the iommu-api
too and this definitly does not work there. One possible solution might
be to make the iommu-ops per-bus.
> bool iommu_found(void)
> @@ -94,6 +130,14 @@ int iommu_domain_has_cap(struct iommu_domain *domain,
> }
> EXPORT_SYMBOL_GPL(iommu_domain_has_cap);
>
> +long iommu_dev_to_group(struct device *dev)
> +{
> + if (iommu_ops->dev_to_group)
> + return iommu_ops->dev_to_group(dev);
> + return -ENODEV;
> +}
> +EXPORT_SYMBOL_GPL(iommu_dev_to_group);
Please rename this to iommu_device_group(). The dev_to_group name
suggests a conversion but it is actually just a property of the device.
Also the return type should not be long but something that fits into
32bit on all platforms. Since you use -ENODEV, probably s32 is a good
choice.
> +
> int iommu_map(struct iommu_domain *domain, unsigned long iova,
> phys_addr_t paddr, int gfp_order, int prot)
> {
> diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c
> index f02c34d..477259c 100644
> --- a/drivers/pci/intel-iommu.c
> +++ b/drivers/pci/intel-iommu.c
> @@ -404,6 +404,7 @@ static int dmar_map_gfx = 1;
> static int dmar_forcedac;
> static int intel_iommu_strict;
> static int intel_iommu_superpage = 1;
> +static int intel_iommu_no_mf_groups;
>
> #define DUMMY_DEVICE_DOMAIN_INFO ((struct device_domain_info *)(-1))
> static DEFINE_SPINLOCK(device_domain_lock);
> @@ -438,6 +439,10 @@ static int __init intel_iommu_setup(char *str)
> printk(KERN_INFO
> "Intel-IOMMU: disable supported super page\n");
> intel_iommu_superpage = 0;
> + } else if (!strncmp(str, "no_mf_groups", 12)) {
> + printk(KERN_INFO
> + "Intel-IOMMU: disable separate groups for multifunction devices\n");
> + intel_iommu_no_mf_groups = 1;
This should really be a global iommu option and not be VT-d specific.
>
> str += strcspn(str, ",");
> @@ -3902,6 +3907,52 @@ static int intel_iommu_domain_has_cap(struct iommu_domain *domain,
> return 0;
> }
>
> +/* Group numbers are arbitrary. Device with the same group number
> + * indicate the iommu cannot differentiate between them. To avoid
> + * tracking used groups we just use the seg|bus|devfn of the lowest
> + * level we're able to differentiate devices */
> +static long intel_iommu_dev_to_group(struct device *dev)
> +{
> + struct pci_dev *pdev = to_pci_dev(dev);
> + struct pci_dev *bridge;
> + union {
> + struct {
> + u8 devfn;
> + u8 bus;
> + u16 segment;
> + } pci;
> + u32 group;
> + } id;
> +
> + if (iommu_no_mapping(dev))
> + return -ENODEV;
> +
> + id.pci.segment = pci_domain_nr(pdev->bus);
> + id.pci.bus = pdev->bus->number;
> + id.pci.devfn = pdev->devfn;
> +
> + if (!device_to_iommu(id.pci.segment, id.pci.bus, id.pci.devfn))
> + return -ENODEV;
> +
> + bridge = pci_find_upstream_pcie_bridge(pdev);
> + if (bridge) {
> + if (pci_is_pcie(bridge)) {
> + id.pci.bus = bridge->subordinate->number;
> + id.pci.devfn = 0;
> + } else {
> + id.pci.bus = bridge->bus->number;
> + id.pci.devfn = bridge->devfn;
> + }
> + }
> +
> + /* Virtual functions always get their own group */
> + if (!pdev->is_virtfn && intel_iommu_no_mf_groups)
> + id.pci.devfn = PCI_DEVFN(PCI_SLOT(id.pci.devfn), 0);
> +
> + /* FIXME - seg # >= 0x8000 on 32b */
> + return id.group;
> +}
This looks like code duplication in the VT-d driver. It doesn't need to
be generalized now, but we should keep in mind to do a more general
solution later.
Maybe it is beneficial if the IOMMU drivers only setup the number in
dev->arch.iommu.groupid and the iommu-api fetches it from there then.
But as I said, this is some more work and does not need to be done for
this patch(-set).
> +
> static struct iommu_ops intel_iommu_ops = {
> .domain_init = intel_iommu_domain_init,
> .domain_destroy = intel_iommu_domain_destroy,
> @@ -3911,6 +3962,7 @@ static struct iommu_ops intel_iommu_ops = {
> .unmap = intel_iommu_unmap,
> .iova_to_phys = intel_iommu_iova_to_phys,
> .domain_has_cap = intel_iommu_domain_has_cap,
> + .dev_to_group = intel_iommu_dev_to_group,
> };
>
> static void __devinit quirk_iommu_rwbf(struct pci_dev *dev)
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index 0a2ba40..90c1a86 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -45,6 +45,7 @@ struct iommu_ops {
> unsigned long iova);
> int (*domain_has_cap)(struct iommu_domain *domain,
> unsigned long cap);
> + long (*dev_to_group)(struct device *dev);
> };
>
> #ifdef CONFIG_IOMMU_API
> @@ -65,6 +66,7 @@ extern phys_addr_t iommu_iova_to_phys(struct iommu_domain *domain,
> unsigned long iova);
> extern int iommu_domain_has_cap(struct iommu_domain *domain,
> unsigned long cap);
> +extern long iommu_dev_to_group(struct device *dev);
>
> #else /* CONFIG_IOMMU_API */
>
> @@ -121,6 +123,10 @@ static inline int domain_has_cap(struct iommu_domain *domain,
> return 0;
> }
>
> +static inline long iommu_dev_to_group(struct device *dev);
> +{
> + return -ENODEV;
> +}
> #endif /* CONFIG_IOMMU_API */
>
> #endif /* __LINUX_IOMMU_H */
>
>
>
--
AMD Operating System Research Center
Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo, Andrew Bowd
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632
next prev parent reply other threads:[~2011-08-25 11:24 UTC|newest]
Thread overview: 93+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1311983933.8793.42.camel@pasglop>
2011-07-30 18:20 ` [Qemu-devel] kvm PCI assignment & VFIO ramblings Alex Williamson
2011-07-30 23:54 ` Benjamin Herrenschmidt
2011-08-01 18:59 ` Alex Williamson
2011-08-02 2:00 ` Benjamin Herrenschmidt
2011-07-30 23:55 ` Benjamin Herrenschmidt
2011-08-02 8:28 ` David Gibson
2011-08-02 18:14 ` Alex Williamson
2011-08-02 18:35 ` Alex Williamson
2011-08-03 2:04 ` David Gibson
2011-08-03 3:44 ` Alex Williamson
2011-08-04 0:39 ` David Gibson
2011-08-08 8:28 ` Avi Kivity
2011-08-09 23:24 ` Alex Williamson
2011-08-10 2:48 ` Benjamin Herrenschmidt
2011-08-20 16:51 ` Alex Williamson
2011-08-22 5:55 ` David Gibson
2011-08-22 15:45 ` Alex Williamson
2011-08-22 21:01 ` Benjamin Herrenschmidt
2011-08-23 19:30 ` Alex Williamson
2011-08-23 23:51 ` Benjamin Herrenschmidt
2011-08-24 3:40 ` Alexander Graf
2011-08-24 14:47 ` Alex Williamson
2011-08-24 8:43 ` Joerg Roedel
2011-08-24 14:56 ` Alex Williamson
2011-08-25 11:01 ` Roedel, Joerg
2011-08-23 2:38 ` David Gibson
2011-08-23 16:23 ` Alex Williamson
2011-08-23 23:41 ` Benjamin Herrenschmidt
2011-08-24 3:36 ` Alexander Graf
2011-08-22 6:30 ` Avi Kivity
2011-08-22 10:46 ` Joerg Roedel
2011-08-22 10:51 ` Avi Kivity
2011-08-22 12:36 ` Roedel, Joerg
2011-08-22 12:42 ` Avi Kivity
2011-08-22 12:55 ` Roedel, Joerg
2011-08-22 13:06 ` Avi Kivity
2011-08-22 13:15 ` Roedel, Joerg
2011-08-22 13:17 ` Avi Kivity
2011-08-22 14:37 ` Roedel, Joerg
2011-08-22 20:53 ` Benjamin Herrenschmidt
2011-08-22 17:25 ` Joerg Roedel
2011-08-22 19:17 ` Alex Williamson
2011-08-23 13:14 ` Roedel, Joerg
2011-08-23 17:08 ` Alex Williamson
2011-08-24 8:52 ` Roedel, Joerg
2011-08-24 15:07 ` Alex Williamson
2011-08-25 12:31 ` Roedel, Joerg
2011-08-25 13:25 ` Alexander Graf
2011-08-26 4:24 ` David Gibson
2011-08-26 9:24 ` Roedel, Joerg
2011-08-28 13:14 ` Avi Kivity
2011-08-28 13:56 ` Joerg Roedel
2011-08-28 14:04 ` Avi Kivity
2011-08-30 16:14 ` Joerg Roedel
2011-08-22 21:03 ` Benjamin Herrenschmidt
2011-08-23 13:18 ` Roedel, Joerg
2011-08-23 23:35 ` Benjamin Herrenschmidt
2011-08-24 8:53 ` Roedel, Joerg
2011-08-22 20:29 ` aafabbri
2011-08-22 20:49 ` Benjamin Herrenschmidt
2011-08-22 21:38 ` aafabbri
2011-08-22 21:49 ` Benjamin Herrenschmidt
2011-08-23 0:52 ` aafabbri
2011-08-23 6:54 ` Benjamin Herrenschmidt
2011-08-23 11:09 ` Joerg Roedel
2011-08-23 17:01 ` Alex Williamson
2011-08-23 17:33 ` Aaron Fabbri
2011-08-23 18:01 ` Alex Williamson
2011-08-24 9:10 ` Joerg Roedel
2011-08-24 21:13 ` Alex Williamson
2011-08-25 10:54 ` Roedel, Joerg [this message]
2011-08-25 15:38 ` Don Dutile
2011-08-25 16:46 ` Roedel, Joerg
2011-08-25 17:20 ` Alex Williamson
2011-08-25 18:05 ` Joerg Roedel
2011-08-26 18:04 ` Alex Williamson
2011-08-30 16:13 ` Joerg Roedel
2011-08-23 11:04 ` Joerg Roedel
2011-08-23 16:54 ` aafabbri
2011-08-24 9:14 ` Roedel, Joerg
2011-08-24 9:33 ` David Gibson
2011-08-24 11:03 ` Roedel, Joerg
2011-08-26 4:20 ` David Gibson
2011-08-26 9:33 ` Roedel, Joerg
2011-08-26 14:07 ` Alexander Graf
2011-08-26 15:24 ` Joerg Roedel
2011-08-26 15:29 ` Alexander Graf
2011-08-26 17:52 ` Aaron Fabbri
2011-08-26 19:35 ` Chris Wright
2011-08-26 20:17 ` Aaron Fabbri
2011-08-26 21:06 ` Chris Wright
2011-08-30 1:29 ` David Gibson
2011-08-04 10:35 ` Joerg Roedel
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=20110825105402.GB1923@amd.com \
--to=joerg.roedel@amd.com \
--cc=aafabbri@cisco.com \
--cc=aik@au1.ibm.com \
--cc=alex.williamson@redhat.com \
--cc=avi@redhat.com \
--cc=benve@cisco.com \
--cc=chrisw@sous-sol.org \
--cc=iommu@lists.linux-foundation.org \
--cc=kvm@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=pmac@au1.ibm.com \
--cc=qemu-devel@nongnu.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).