> -----Original Message----- > From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Thursday, April 04, 2013 10:22 AM > To: Sethi Varun-B16395 > Cc: Joerg Roedel; Yoder Stuart-B08248; Wood Scott-B07421; > io...@lists.linux-foundation.org; linuxppc- > d...@lists.ozlabs.org; linux-ker...@vger.kernel.org; > ga...@kernel.crashing.org; b...@kernel.crashing.org > Subject: Re: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu > implementation. > > On Thu, 2013-04-04 at 13:00 +0000, Sethi Varun-B16395 wrote: > > > > > -----Original Message----- > > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > > Sent: Wednesday, April 03, 2013 11:32 PM > > > To: Joerg Roedel > > > Cc: Sethi Varun-B16395; Yoder Stuart-B08248; Wood Scott-B07421; > > > io...@lists.linux-foundation.org; linuxppc-dev@lists.ozlabs.org; linux- > > > ker...@vger.kernel.org; ga...@kernel.crashing.org; > > > b...@kernel.crashing.org > > > Subject: Re: [PATCH 5/5 v11] iommu/fsl: Freescale PAMU driver and iommu > > > implementation. > > > > > > On Tue, 2013-04-02 at 18:18 +0200, Joerg Roedel wrote: > > > > Cc'ing Alex Williamson > > > > > > > > Alex, can you please review the iommu-group part of this patch? > > > > > > Sure, it looks pretty reasonable. AIUI, all PCI devices are below some > > > kind of host bridge that is either new and supports partitioning or old > > > and doesn't. I don't know if that's a visibility or isolation > > > requirement, perhaps PCI ACS-ish. In the new host bridge case, each > > > device gets a group. This seems not to have any quirks for multifunction > > > devices though. On AMD and Intel IOMMUs we test multifunction device ACS > > > support to determine whether all the functions should be in the same > > > group. Is there any reason to trust multifunction devices on PAMU? > > > > > [Sethi Varun-B16395] In the case where we can partition endpoints we > > can distinguish transactions based on the bus,device,function number > > combination. This support is available in the PCIe controller (host > > bridge). > > So can x86 IOMMUs, that's the visibility aspect of IOMMU groups. > Visibility alone doesn't necessarily imply that a device is isolated > though. A multifunction PCI device that doesn't expose ACS support may > not isolate functions from each other. For example a peer-to-peer DMA > between functions may not be translated by the upstream IOMMU. IOMMU > groups should encompass both visibility and isolation. > > > > I also find it curious what happens to the iommu group of the host > > > bridge. In the partitionable case the host bridge group is removed, in > > > the non-partitionable case the host bridge group becomes the group for > > > the children, removing the host bridge. It's unique to PAMU so far that > > > these host bridges are even in an iommu group (x86 only adds pci > > > devices), but I don't see it as necessarily wrong leaving it in either > > > scenario. Does it solve some problem to remove them from the groups? > > > Thanks, > > [Sethi Varun-B16395] The PCIe controller isn't a partitionable entity, > > it would always be owned by the host. > > Ownership of a device shouldn't play into the group context. An IOMMU > group should be defined by it's visibility and isolation from other > devices. Whether the PCIe controller is allowed to be handed to > userspace is a question for VFIO. Thanks,
Right now the add_device() callback gets called for all platform devices (including PCI controller) and PCI devices. PCI controllers are a kind of special case in that their device tree node has a property indicating that it is DMA capable...but in fact the PCI controller itself does not DMA, but it's the PCI endpoints under it. So, as you noted the bridge/controller shouldn't be in an IOMMU group and so since the platform 'add device' code didn't special case PCI controllers, this patch removes their group if it's there. Stuart _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
