linux-kernel - Re: [RFC patch] init default dma_ops to prepare intel_iommu

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 13 Aug 2009 09:49:33 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Luming Yu <luming.yu@...il.com>
Cc:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
	fenghua.yu@...el.com, tony.luck@...el.com,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org
Subject: Re: [RFC patch] init default dma_ops to prepare intel_iommu_init 
 failure

On Thu, 2009-08-13 at 16:11 +0800, Luming Yu wrote:
> I treat this as -32 or -33 stuff, because I don't see a real system is blocking
> on the problem. I found this problem when I was trying to disable some drhd
> for debugging a real iommu issue...that one has priority.

(The real bug you were chasing is fixed, isn't it? Or worked around, at
least, since the BIOS in question is still closed source and broken.)

But by talking about disabling _some_ drhd units, you've just reminded
me that the problem is far more interesting -- we can have the IOMMU
active for _some_ devices but not others.

I was toying with the idea of putting the intel_dma_ops into
dev->archdata for each pci device at boot or hotplug time, and leaving
the global variable alone. We can calculate the dev->iommu mapping at
that point too. And we can stop being quite so broken w.r.t. PCI
hotplug...

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse@...el.com                              Intel Corporation

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/