linux-kernel - Re: [PATCH v2 -mm 0/2] x86: per-device dma_mapping

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, 22 May 2008 16:13:02 +0530
From:	Amit Shah <amit.shah@...ranet.com>
To:	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>
Cc:	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	muli@...ibm.com, alexisb@...ibm.com, andi@...stfloor.org,
	kvm@...r.kernel.org, avi@...ranet.com
Subject: Re: [PATCH v2 -mm 0/2] x86: per-device dma_mapping_ops

On Monday 19 May 2008 12:01:27 FUJITA Tomonori wrote:
> This is an updated version of the patchset to add per-device
> dma_mapping_ops support for CONFIG_X86_64 like POWER architecture
> does:
>
> http://lkml.org/lkml/2008/5/13/36
>
> This is against 2.6.26-rc2-mm1 (the changes since the v1 are pretty
> trivial like dropping the change for v850 arch).
>
> This enables us to cleanly fix the Calgary IOMMU issue that some
> devices are not behind the IOMMU [1].
>
> I think that per-device dma_mapping_ops support would be also helpful
> for KVM people to support PCI passthrough but Andi thinks that this
> makes it difficult to support the PCI passthrough (see the above
> thread). So I CC'ed this to KVM camp. Comments are appreciated.

I think what's more useful is a chain with a properly defined order or 
hierarchy (based on what Muli suggested last time we discussed this

http://lkml.org/lkml/2007/11/12/44 )

The suggested order was (in calling order):
pvdma->hardare->nommu/swiotlb

The discussion in the thread pointed to above has details as to why.

> A pointer to dma_mapping_ops to struct dev_archdata is added. If the
> pointer is non NULL, DMA operations in asm/dma-mapping.h use it. If
> it's NULL, the system-wide dma_ops pointer is used as before.


> If it's useful for KVM people, I plan to implement a mechanism to
> register a hook called when a new pci (or dma capable) device is

OK; this sounds helpful. the hook can make a hypercall and confirm with the 
host kernel if the device in question is an assigned physical device. If yes, 
we replace the dma_ops. Though, the original intent of having stackable ops 
is that we might want to go through the swiotlb in the guest even for an 
assigned device if the guest dma addresses are not in the addressable range 
of the guest chipset.

> created (it works with hot plugging). It enables IOMMUs to set up an
> appropriate dma_mapping_ops per device.

>From what we've discussed so far, it looks like stackable dma ops will 
definitely be needed. Does this patchset provide something that stacking 
won't?

> [1] http://lkml.org/lkml/2008/5/8/423

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