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]
Message-Id: <20090813153014Z.fujita.tomonori@lab.ntt.co.jp>
Date:	Thu, 13 Aug 2009 15:30:51 +0900
From:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
To:	luming.yu@...il.com
Cc:	fujita.tomonori@....ntt.co.jp, fenghua.yu@...el.com,
	dwmw2@...radead.org, 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, 13 Aug 2009 13:48:45 +0800
Luming Yu <luming.yu@...il.com> wrote:

> >>
> >> This check can not be removed. Otherwise, swiotlb_dma_ops will always override
> >> previous dma_ops value.
> >
> > Yeah.
> 
> I think pci_swiotlb_init needs to be cleaned up for both x86_{32,64} and ia64.

Yeah, it has been on my todo list. But we can't clean up only
pci_swiotlb_init. We need to take care of the whole dma setup code.


> it should be used to init default dma_ops, and the call site of it should be
> as early as platform_dma_init in mem_init. SInce swiotlb_dma_ops is pitched as
> default dma_ops for x86, ia64,

It's more complicated. x86_32 should use nommu_dma_ops. x86_64 should
use nommu_dma_ops if swiotlb is not necessary.

About IA64, swiotlb is not always available (IA64_HP_ZX1 and
IA64_SIG_SN2).


> we really don't need to let pci_swiotlb_init
> know iommu_deteced, dmar_disabled or iommu_passthrough...and anything
> like that..

Yeah. That's one of reasons why I want to rewrite the IA64 and X86 dma
setup code again.


> Please note the major wrong assumption of the current implementation is
> "iommu_deteced == iommu working" that I was trying to fix.

Yeah, I see that. But it had been correct for long time; we had been
happy about the logic that if we detect iommu but it doesn't work then
we are dead.

The x86 dma setup code can enable both hardware IOMMU and
swiotlb. It's a bit similar to what you need for IA64.


Anyway, my patch should fix this problem. Have you tried it?

http://marc.info/?l=linux-kernel&m=125013354518721&w=2


It's fine for now, I think.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ