RE: [PATCH 1/6 v8] iommu/fsl: Store iommu domain information pointer in archdata.
> -Original Message- > From: Yoder Stuart-B08248 > Sent: Friday, March 01, 2013 9:52 PM > To: Alexey Kardashevskiy; Sethi Varun-B16395 > Cc: Kumar Gala; Benjamin Herrenschmidt; iommu@lists.linux-foundation.org; > linuxppc-...@lists.ozlabs.org list; linux-ker...@vger.kernel.org list; > Wood Scott-B07421; Joerg Roedel; Paul Mackerras; David Gibson; Alex > Williamson > Subject: RE: [PATCH 1/6 v8] iommu/fsl: Store iommu domain information > pointer in archdata. > > > > > -Original Message- > > From: Alexey Kardashevskiy [mailto:a...@ozlabs.ru] > > Sent: Friday, March 01, 2013 4:07 AM > > To: Sethi Varun-B16395 > > Cc: Kumar Gala; Benjamin Herrenschmidt; > > iommu@lists.linux-foundation.org; linuxppc-...@lists.ozlabs.org list; > > linux-ker...@vger.kernel.org list; Wood Scott-B07421; Yoder > > Stuart-B08248; Joerg Roedel; Paul Mackerras; David Gibson; Alex > > Williamson > > Subject: Re: [PATCH 1/6 v8] iommu/fsl: Store iommu domain information > pointer in archdata. > > > > btw the device struct already has a pointer to its iommu_group, and > > the iommu_group struct itself has a pointer void *iommu_data which you > > could use for anything you want (iommu_group_get_iommudata(), > > iommu_group_set_iommudata()). > > > > By design you are expected to add iommu groups to a domain but not > > devices so I am not so sure that you really need a pointer to domain > > in the device struct. > > Well, at the lowest level the IOMMU API does attach devices to domains-- > i.e. > API attach_dev(). So, it seems to conceptually make sense to have a ptr > from the device to the associated domain. When you implement > attach_dev() you need to be able to see whether the device is already > attached to > a domain. Adding a couple of levels of indirection...from device to > group to domain...doesn't seems to make things simpler or better IMHO. > > x86 keeps a pointer to the domain in device archdata and since there is a > direct correlation between a device and domain I'd rather see it where > this patch has it. > As Stuart stated this allows us to maintain the device <-> domain relationship at the lowest level. -Varun ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] Quirk to support Marvell 88SE91xx SATA controllers with Intel IOMMU.
On Sat, Mar 2, 2013 at 7:18 AM, Justin Piszcz wrote: > > Against a clean 3.7.10 (from ftp.kernel.org) > > # patch -p1 < > ../patch/RFC-Fix-Intel-IOMMU-support-for-Marvell-88SE91xx-SATA-controllers.. > patch > patching file drivers/iommu/intel-iommu.c > patching file drivers/pci/quirks.c > Hunk #1 succeeded at 3230 (offset 3 lines). > patching file include/linux/pci.h > # pwd > /usr/src/linux-3.7.10 > I've downloaded and patched the 3.7.10 tarball and still get the same output I got before; different output from yours. I'm not sure the patch is complete or applying correctly, are you? Could you please check whether the patch you're applying is the same as the attached file? > Full dmesg with the patch applied: (but with IOMMU off) > http://home.comcast.net/~jpiszcz/20130301/dmesg-full.txt > > Full dmesg (as much as possible through netconsole with IOMMU on) > http://home.comcast.net/~jpiszcz/20130301/dmesg-iommu-on.txt > > Let me know if anything else is needed, thanks. I think some important error messages might have been lost here. You captured a complete dmesg at https://home.comcast.net/~jpiszcz/20121128/dmesg.txt with iommu on. Are you still able to get the same with 3.7.10 if you exclude this patch, or has something else changed? a. marvell_ghost_funcs.patch Description: Binary data ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 3.2] iommu/amd: Initialize device table after dma_ops
Hi Ben, On Sat, Mar 02, 2013 at 11:00:35PM +, Ben Hutchings wrote: > I'm not convinced about this backport, because the order of > initialisation already changed a lot after 3.2 and before the upstream > commit. So I'm going to wait for Joerg to confirm that this makes sense > before adding it to the patch queue. The patch looks good, it fixes a race condition during amd_iommu initialization. I'll also gave the backport a test to be sure it doesn't break anything. Thanks, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
