From: Muli Ben-Yehuda <muli@il.ibm.com>
To: Joerg Roedel <joerg.roedel@amd.com>
Cc: Amit Shah <amit.shah@redhat.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
iommu@lists.linux-foundation.org,
David Woodhouse <dwmw2@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Subject: Re: [PATCH 9/9] x86/iommu: use dma_ops_list in get_dma_ops
Date: Sat, 27 Sep 2008 03:13:21 +0300 [thread overview]
Message-ID: <20080927001321.GI9118@il.ibm.com> (raw)
In-Reply-To: <20080926123243.GE27928@amd.com>
On Fri, Sep 26, 2008 at 02:32:43PM +0200, Joerg Roedel wrote:
> Ok, the allocation only matters for dma_alloc_coherent. Fujita
> introduced a generic software-based dma_alloc_coherent recently
> which you can use for that. I think implementing PVDMA into an own
> dma_ops backend and multiplex it using my patches introduces less
> overhead than an additional layer over the current dma_ops
> implementation.
I'm not sure what you have in mind, but I agree with Amit that
conceptually pvdma should be called after the guest's "native" dma_ops
have done their thing. This is not just for nommu, consider a guest
that is using an (emulated) hardware IOMMU, or that wants to use
swiotlb. We can't replicate their functionality in the pv_dma_ops
layer, we have to let them run first and then pass deal with whatever
we get back.
> Another two questions to your approach: What happens if a
> dma_alloc_coherent allocation crosses page boundarys and the gpa's
> are not contiguous in host memory? How will dma masks be handled?
That's a very good question. The host will need to be aware of a
device's DMA capabilities in order to return I/O addresses (which
could be hpa's if you don't have an IOMMU) that satisfy them. That's
quite a pain.
Cheers,
Muli
--
The First Workshop on I/O Virtualization (WIOV '08)
Dec 2008, San Diego, CA, http://www.usenix.org/wiov08/
xxx
SYSTOR 2009---The Israeli Experimental Systems Conference
http://www.haifa.il.ibm.com/conferences/systor2009/
next prev parent reply other threads:[~2008-09-27 0:14 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-22 18:21 [PATCH 0/9][RFC] stackable dma_ops for x86 Joerg Roedel
2008-09-22 18:21 ` [PATCH 1/9] x86/iommu: add necessary types for stackable dma_ops Joerg Roedel
2008-09-22 18:21 ` [PATCH 2/9] x86/iommu: add stackable dma_ops registration interface Joerg Roedel
2008-09-22 18:21 ` [PATCH 3/9] x86/iommu: change PCI-NOMMU to use dma_ops register interface Joerg Roedel
2008-09-22 18:21 ` [PATCH 4/9] x86/iommu: change SWIOTLB " Joerg Roedel
2008-09-22 18:21 ` [PATCH 5/9] x86/iommu: change GART " Joerg Roedel
2008-09-22 18:21 ` [PATCH 6/9] x86/iommu: change Calgary " Joerg Roedel
2008-09-23 14:37 ` Muli Ben-Yehuda
2008-09-30 11:10 ` Ingo Molnar
2008-09-30 11:58 ` Joerg Roedel
2008-09-30 13:30 ` Muli Ben-Yehuda
2008-09-30 15:38 ` Ingo Molnar
2008-09-30 18:33 ` Muli Ben-Yehuda
2008-09-22 18:21 ` [PATCH 7/9] x86/iommu: change AMD IOMMU " Joerg Roedel
2008-09-22 18:21 ` [PATCH 8/9] x86/iommu: change Intel " Joerg Roedel
2008-09-22 18:21 ` [PATCH 9/9] x86/iommu: use dma_ops_list in get_dma_ops Joerg Roedel
2008-09-26 7:56 ` Amit Shah
2008-09-26 8:59 ` Joerg Roedel
2008-09-26 10:49 ` Amit Shah
2008-09-26 12:32 ` Joerg Roedel
2008-09-27 0:13 ` Muli Ben-Yehuda [this message]
2008-09-28 19:13 ` Joerg Roedel
2008-09-29 9:30 ` Muli Ben-Yehuda
2008-09-29 9:36 ` Joerg Roedel
2008-09-29 13:16 ` FUJITA Tomonori
2008-09-29 13:33 ` Joerg Roedel
2008-09-30 19:44 ` Muli Ben-Yehuda
2008-10-01 7:19 ` Joerg Roedel
2008-10-03 8:38 ` Muli Ben-Yehuda
2008-09-26 11:00 ` Joerg Roedel
2008-09-28 14:21 ` FUJITA Tomonori
2008-09-28 18:44 ` Joerg Roedel
2008-09-29 9:25 ` Muli Ben-Yehuda
2008-09-29 9:29 ` Joerg Roedel
2008-09-22 18:36 ` [PATCH 0/9][RFC] stackable dma_ops for x86 Arjan van de Ven
2008-09-22 18:39 ` Joerg Roedel
2008-09-23 2:41 ` Jeremy Fitzhardinge
2008-09-23 2:50 ` Arjan van de Ven
2008-09-28 14:21 ` FUJITA Tomonori
2008-09-28 18:49 ` Joerg Roedel
2008-09-29 13:16 ` FUJITA Tomonori
2008-09-29 13:26 ` Joerg Roedel
2008-09-29 13:42 ` FUJITA Tomonori
2008-09-29 13:51 ` Joerg Roedel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080927001321.GI9118@il.ibm.com \
--to=muli@il.ibm.com \
--cc=amit.shah@redhat.com \
--cc=dwmw2@infradead.org \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=iommu@lists.linux-foundation.org \
--cc=joerg.roedel@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.