linux-kernel - Re: [RFC PATCH 0/3] allow fallback to swiotlb on hw iommu init failures

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:	Fri, 23 Oct 2009 09:39:23 -0700
From:	Chris Wright <chrisw@...s-sol.org>
To:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
Cc:	chrisw@...s-sol.org, dwmw2@...radead.org,
	iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/3] allow fallback to swiotlb on hw iommu init
	failures

* FUJITA Tomonori (fujita.tomonori@....ntt.co.jp) wrote:
> On Thu, 22 Oct 2009 18:21:58 -0700
> Chris Wright <chrisw@...s-sol.org> wrote:
> 
> > This short series gives us the ability to allocate the swiotlb and then
> > conditionally free it if we discover it isn't needed.  This allows us to
> > put swiotlb to use when the hw iommu fails to initialize properly.
> > 
> > This needs some changes to the bootmem allocator to give the ability to
> > free reserved bootmem directly to the page allocator after bootmem is
> > torn down.
> 
> The concept sounds fine but the third patch doesn't look correct.
> 
> Seems that the third patch doesn't take into account enabling both hw
> iommu and swiotlb (Calgary does and I guess VT-d and AMD need that
> too).

VT-d isn't using swiotlb.  Nor is AMD, although I think it will pick up
no_iommu on passthrough (seems like it would benefit from swiotlb in
that case).

>  Also (iommu_detected && !dma_ops) trick doesn't work for
> Calgary, IIRC.

Yes, I think you are right.  I had stared at the calgary code and thought
it would DTRT due to calgary's use of no_iommu as fallback, but instead
it will never pick up swiotlb_dma_ops.  The calgary shouldn't even need
to be manually setting up nommu_dma_ops.

>  The third patch also makes the dma startup code more
> complicated.

I completely agree.  The whole dma/iommu startup is already complex
and fragile.  Issues like above made getting the right combination
like whack-a-mole.

> I have half-baked patches to clean up the dma startup code supporting
> the concept. I can work on the top of the first and second
> patches. They need to be CC'ed to the memory people and ACKs, don't
> they?

Great.
--
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/