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:40 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 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.