qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paul Brook <paul@codesourcery.com>
To: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
Cc: joro@8bytes.org, avi@redhat.com, kvm@vger.kernel.org,
	qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [RFC PATCH 4/7] ide: IOMMU support
Date: Thu, 15 Jul 2010 11:58:56 +0100	[thread overview]
Message-ID: <201007151158.57006.paul@codesourcery.com> (raw)
In-Reply-To: <20100714231100.GC7065@localhost>

> On Wed, Jul 14, 2010 at 02:53:03PM +0100, Paul Brook wrote:
> > > Memory accesses must go through the IOMMU layer.
> > 
> > No. Devices should not know or care whether an IOMMU is present.
> 
> They don't really care. iommu_get() et al. are convenience functions
> which can and do return NULL when there's no IOMMU and device code can
> pass that NULL around without checking. 

Devices should not need to know any of this. You're introducing a significant 
amount of duplication and complexity into every device.

The assumption that all accesses will go through the same IOMMU is also false. 
Accesses to devices on the same bus will not be translated by the IOMMU. 
Currently there are probably also other things that will break in this case, 
but your API seems fundamentally incapable of handling this.

> I could've probably made the r/w
> functions take only the DeviceState in addition to normal args, but
> wanted to avoid looking up the related structures on each I/O operation.

That's exactly what you should be doing.  If this is inefficient then there 
are much better ways of fixing this. e.g. by not having the device perform so 
many accesses, or by adding some sort of translation cache.

> > You should be adding a DeviceState argument to
> > cpu_physical_memory_{rw,map}. This should then handle IOMMU translation
> > transparently.
> > 
> > You also need to accomodate the the case where multiple IOMMU are
> > present.
> 
> We don't assume there's a single IOMMU in the generic layer. The
> callbacks within 'struct iommu' could very well dispatch the request to
> one of multiple, coexisting IOMMUs.

So you've now introduced yet another copy of the translation code. Not only 
does every device have to be IOMMU aware, but every IOMMU also has to be aware 
of nested IOMMUs.

Paul

  reply	other threads:[~2010-07-15 10:59 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-14  5:45 [Qemu-devel] [RFC PATCH 0/7] AMD IOMMU emulation patchset Eduard - Gabriel Munteanu
2010-07-14  5:45 ` [Qemu-devel] [RFC PATCH 1/7] Generic IOMMU layer Eduard - Gabriel Munteanu
2010-07-14  6:07   ` malc
2010-07-14 22:47     ` Eduard - Gabriel Munteanu
2010-07-14  5:45 ` [Qemu-devel] [RFC PATCH 2/7] AMD IOMMU emulation Eduard - Gabriel Munteanu
2010-07-14 20:16   ` Paul Brook
2010-07-14  5:45 ` [Qemu-devel] [RFC PATCH 3/7] pci: call IOMMU hooks Eduard - Gabriel Munteanu
2010-07-14  7:37   ` Isaku Yamahata
2010-07-14 22:50     ` Eduard - Gabriel Munteanu
2010-07-14  5:45 ` [Qemu-devel] [RFC PATCH 4/7] ide: IOMMU support Eduard - Gabriel Munteanu
2010-07-14 13:53   ` [Qemu-devel] " Paul Brook
2010-07-14 18:33     ` Joerg Roedel
2010-07-14 20:13       ` Paul Brook
2010-07-14 21:29         ` Anthony Liguori
2010-07-14 22:24           ` Chris Wright
2010-07-15 10:28             ` Paul Brook
2010-07-15 16:52               ` Chris Wright
2010-07-15 17:02                 ` Avi Kivity
2010-07-15 17:17                   ` Chris Wright
2010-07-15 17:22                     ` Avi Kivity
2010-07-15 17:25                       ` Chris Wright
2010-07-15 17:27                     ` Eduard - Gabriel Munteanu
2010-07-15 17:22                   ` Joerg Roedel
2010-07-15 17:14                 ` Chris Wright
2010-07-15  9:10           ` Joerg Roedel
2010-07-15 12:45             ` Anthony Liguori
2010-07-15 14:45               ` Joerg Roedel
2010-07-15 16:45               ` Eduard - Gabriel Munteanu
2010-07-15 17:42                 ` Anthony Liguori
2010-07-15 10:33           ` Paul Brook
2010-07-15 12:42             ` Anthony Liguori
2010-07-15 14:02               ` Paul Brook
2010-07-14 23:39         ` Eduard - Gabriel Munteanu
2010-07-15  9:22         ` Joerg Roedel
2010-07-15 10:49           ` Paul Brook
2010-07-15 14:59             ` Joerg Roedel
2010-07-14 23:11     ` Eduard - Gabriel Munteanu
2010-07-15 10:58       ` Paul Brook [this message]
2010-07-14  5:45 ` [Qemu-devel] [RFC PATCH 5/7] rtl8139: " Eduard - Gabriel Munteanu
2010-07-14  5:45 ` [Qemu-devel] [RFC PATCH 6/7] eepro100: " Eduard - Gabriel Munteanu
2010-07-14  5:45 ` [Qemu-devel] [RFC PATCH 7/7] ac97: " Eduard - Gabriel Munteanu
2010-07-14  6:09   ` malc

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=201007151158.57006.paul@codesourcery.com \
    --to=paul@codesourcery.com \
    --cc=avi@redhat.com \
    --cc=eduard.munteanu@linux360.ro \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    /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).