From: Muli Ben-Yehuda <muli@il.ibm.com>
To: Joerg Roedel <joerg.roedel@amd.com>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
joro@8bytes.org, amit.shah@redhat.com,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
iommu@lists.linux-foundation.org, dwmw2@infradead.org,
mingo@redhat.com, Ben-Ami Yassour1 <benami@il.ibm.com>
Subject: Re: [PATCH 9/9] x86/iommu: use dma_ops_list in get_dma_ops
Date: Fri, 3 Oct 2008 11:38:20 +0300 [thread overview]
Message-ID: <20081003083820.GH6909@il.ibm.com> (raw)
In-Reply-To: <20081001071956.GA27826@amd.com>
On Wed, Oct 01, 2008 at 09:19:56AM +0200, Joerg Roedel wrote:
> > It might be possible to have a per-device slow or fast path, where
> > the fast path is for devices which have no DMA limitations
> > (high-end devices generally don't) and the slow path is for
> > devices which do.
>
> This solves the problem with the DMA masks. But what happens to
> requests that cross guest page boundarys?
I'm not sure I follow. If a buffer is contiguous in the guest space,
it will remain contiguous (i.e., be mapped contiguously) in the IOMMU
I/O address space, even if each I/O PTE ends up mapping a different
physical frame.
> > > With mapping/unmapping through hypercalls we add the
> > > world-switch overhead to the copy-overhead. We can't avoid this
> > > when we have no hardware support at all. But already with older
> > > IOMMUs like Calgary and GART we can at least avoid the
> > > world-switch. And since, for example, every 64 bit capable AMD
> > > processor has a GART we can make use of it.
> >
> > It should be possible to reduce the number and overhead of
> > hypercalls to the point where their cost is immaterial. I think
> > that's fundamentally a better approach.
>
> Ok, we can queue map_sg allocations together an queue them into one
> hypercall. But I remember a paper from you where you wrote that most
> allocations are mapping only one area.
I'm afraid that bit of the paper was poorly done (mea culpa). As far
as I can recall, the majority of dma_alloc_coherent + scatter-gather
list *element* mappings only map a single frame, but we didn't look at
the time at the average length of a scatter gather list and the
frequency of sg list mappings vs. single page mappings. If the length
and frequency are high enough, and you map entire sg lists in a single
hcall or a single batch of hcalls, it might have a nice boost.
> Are there other ways to optimize this? I must say that reducing the
> number of hypercalls was important while thinking about my idea. If
> there are better ways I am all ears to hear from them.
There were a number of ideas mentioned in our paper (for example,
switching drivers from the streaming DMA API to the persistent DMA
API, which will be a big help to the scheme you propose), and Willman,
Rixner and Cox also had some input to the problem[1]. Unfortunately no
implementations exist yet AFAIK.
[1] "Protection Strategies for Direct Access to Virtualized I/O
Devices", by Paul Willmann, Scott Rixner and Alan L. Cox, USENIX '08.
Cheers,
Muli
--
The First Workshop on I/O Virtualization (WIOV '08)
Dec 2008, San Diego, CA, http://www.usenix.org/wiov08/
<->
SYSTOR 2009---The Israeli Experimental Systems Conference
http://www.haifa.il.ibm.com/conferences/systor2009/
next prev parent reply other threads:[~2008-10-03 8:39 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
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 [this message]
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=20081003083820.GH6909@il.ibm.com \
--to=muli@il.ibm.com \
--cc=amit.shah@redhat.com \
--cc=benami@il.ibm.com \
--cc=dwmw2@infradead.org \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=iommu@lists.linux-foundation.org \
--cc=joerg.roedel@amd.com \
--cc=joro@8bytes.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).