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
| ||
|
Date: Thu, 29 Jul 2010 15:01:35 +0200 From: Arnd Bergmann <arnd@...db.de> To: "Roedel, Joerg" <Joerg.Roedel@....com> Cc: FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>, "stepanm@...eaurora.org" <stepanm@...eaurora.org>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, "linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>, "dwalker@...eaurora.org" <dwalker@...eaurora.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: Re: [PATCH 1/2] arm: msm: Add System MMU support. On Thursday 29 July 2010, Roedel, Joerg wrote: > On Thu, Jul 29, 2010 at 07:25:47AM -0400, Arnd Bergmann wrote: > > On Thursday 29 July 2010, Roedel, Joerg wrote: > > > > > > You designed it for what you need at the time. It should have been > > > > named appropriately to avoid confusion. Later, when we actually > > > > understand what other IOMMUs need, we can evolve the specific API for > > > > generic purposes. Then we can rename the API to more generic. > > > > > > At the time the iommu-api was written is was generic enough for what we > > > had. So it was designed as an generic API. At this point in time nobody > > > knew what the future requirements would we. So today it turns out that > > > it is not generic enough anymore for latest hardware. The logical > > > consequence is to fix this in the iommu-api. > > > > Well, I think the real question is why we have two APIs that both claim > > to work with IOMMUs in a generic way and how we could unify the two. > > The DMA-API itself does not claim to be an iommu-frontend. The purpose > of the DMA-API is to convert physical memory addresses into dma handles > and do all the management of these handles. Backend implementations can > use hardware iommus for this task. But depending on the hardware in the > system the DMA-API can very well be implemented without any hardware > support. This is an important difference to the IOMMU-API which needs > hardware because it exposes hardware iommu features to software. Well, you could call that a limitation in the IOMMU API ;-) The idea behind the DMA mapping API is to allow a device driver to work without knowing if the hardware can, cannot or must use an IOMMU. > > I really think we should not extend the (KVM) IOMMU API further but > > just use the generic DMA mapping api for KVM and extend it as necessary. > > It already has the concept of cache coherency and mapping/unmapping > > that are in the IOMMU API and could be extended to support domains > > as well, through the use of dma_attrs. > > If we find a nice and clean way to expose lower-level iommu > functionality through the DMA-API, thats fine. We could certainly > discuss ideas in this direction. I think this is going to be hard > because the DMA-API today does not provide enough flexibility to let the > user choose both sides of a io-virtual<->cpu-physical address mapping. > Thats fine for most drivers because it makes sense for them to use the > generic io-address-allocator the DMA-API provides but not for KVM which > needs this flexibility. One way to do this would be to add a new attribute, e.g. enum dma_attr { DMA_ATTR_WRITE_BARRIER, DMA_ATTR_WEAK_ORDERING, DMA_ATTR_FIXED_MAPPING, /* this one is new */ DMA_ATTR_MAX, }; struct dma_attrs { unsigned long flags[__DMA_ATTRS_LONGS]; dma_add_t dest; }; Nothing except for KVM would need to use that attribute, and KVM would obviously need a way to check if this is supported by the underlying implementation. Arnd -- 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