qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: David Gibson <dwg@au1.ibm.com>
To: Richard Henderson <rth@twiddle.net>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
	aik@ozlabs.ru, Joerg.Rodel@amd.com,
	Alexander Graf <agraf@suse.de>,
	qemu-devel@nongnu.org, eduard.munteanu@linux360.ro
Subject: Re: [Qemu-devel] Supporting emulation of IOMMUs
Date: Mon, 9 May 2011 13:28:20 +1000	[thread overview]
Message-ID: <20110509032820.GD20682@yookeroo.fritz.box> (raw)
In-Reply-To: <4DBACADA.2000209@twiddle.net>

On Fri, Apr 29, 2011 at 07:27:38AM -0700, Richard Henderson wrote:
> On 04/28/2011 02:57 PM, Richard Henderson wrote:
> > I've had a read through the patches posted in January.  It all does
> > seem relatively sane.  At least, I can readily see how I would apply
> > these interfaces to my Alpha port without trouble.
> 
> I take that back, I see one rather annoying problem: the assumption
> that the translate function operates on some sort of standalone device.
> 
> This assumption is present in two places:

Yeah, I noticed this problem too, though I think it's in the AMD IOMMU
support patch rather than the DMA translation core.

> > void pci_register_iommu(PCIDevice *dev, DMATranslateFunc *translate);
> 
> Here, you're assuming that the IOMMU is a device on the PCI bus itself.
> 
> While this may indeed be how the AMD-IOMMU presents itself for the 
> convenience of the pc-minded operating system, that's certainly not how
> the hardware is implemented.  In practice it's a function of the PCI
> host controller.  And indeed, that's how it is presented to the system
> for the Sparc and Alpha controllers with which I am familiar.  I assume
> it's similar for PowerPC, but I've never looked.

Yes, that's right.  On pSeries platforms IOMMU translations are
configured using hcalls.

> > struct DMAMmu {
> >     DeviceState *iommu;
> >     DMATranslateFunc *translate;
> >     QLIST_HEAD(memory_maps, DMAMemoryMap) memory_maps;
> > };
> 
> Here, you're assuming that the "iommu state" is a standalone qdev.
> 
> This is probably true most of the time, given that 
> 
>   FROM_SYSBUS(PCIHostState, sysbus_from_qdev(dev))
> 
> is true.  However, the Alpha Typhoon chipset has two pci host
> controllers that are tied together in ways that would be 
> difficult, or at least irritating, to represent as two separate
> qdev entities.
> 
> I suggest that, like many other places we have callbacks, this
> should be an opaque value private to the translate function.
> 
> In your AMD-IOMMU case you can then do
> 
>   pci_register_iommu(dev->bus, amd_iommu_translate, st);
> 
> and avoid 
> 
> >     PCIDevice *pci_dev = container_of(dev, PCIDevice, dma);
> >     PCIDevice *iommu_dev = DO_UPCAST(PCIDevice, qdev, dev->mmu->iommu);
> >     AMDIOMMUState *st = DO_UPCAST(AMDIOMMUState, dev, iommu_dev);
> 
> at the beginning of your translate function.  You currently have
> three levels of casting and pointer chasing; surely you can agree
> that having a single cast from void* is much easier to follow.
> 
> In my Alpha case I can then do
> 
>   pci_register_iommu(pci_bus0, typhoon_iommu_translate, &state->pchip0);
>   pci_register_iommu(pci_bus1, typhoon_iommu_translate, &state->pchip1);
> 
> and be off to the races.

Yes, I think that makes sense.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

  reply	other threads:[~2011-05-09  3:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-21  7:03 [Qemu-devel] Supporting emulation of IOMMUs David Gibson
2011-04-21  9:39 ` Alexander Graf
2011-04-28 21:57   ` Richard Henderson
2011-04-29 14:27     ` Richard Henderson
2011-05-09  3:28       ` David Gibson [this message]
2011-05-09  2:06     ` David Gibson
2011-05-09  2:05   ` David Gibson
2011-04-21 18:47 ` Eduard - Gabriel Munteanu
2011-05-10  1:44   ` David Gibson
2011-05-14 15:27     ` Eduard - Gabriel Munteanu
2011-05-14 23:16       ` Benjamin Herrenschmidt
2011-04-26 15:58 ` 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=20110509032820.GD20682@yookeroo.fritz.box \
    --to=dwg@au1.ibm.com \
    --cc=Joerg.Rodel@amd.com \
    --cc=agraf@suse.de \
    --cc=aik@ozlabs.ru \
    --cc=aliguori@us.ibm.com \
    --cc=eduard.munteanu@linux360.ro \
    --cc=qemu-devel@nongnu.org \
    --cc=rth@twiddle.net \
    /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).