From: Richard Henderson <rth@twiddle.net>
To: Alexander Graf <agraf@suse.de>
Cc: Anthony Liguori <aliguori@us.ibm.com>,
aik@ozlabs.ru, Joerg.Rodel@amd.com, qemu-devel@nongnu.org,
eduard.munteanu@linux360.ro,
David Gibson <david@gibson.dropbear.id.au>
Subject: Re: [Qemu-devel] Supporting emulation of IOMMUs
Date: Fri, 29 Apr 2011 07:27:38 -0700 [thread overview]
Message-ID: <4DBACADA.2000209@twiddle.net> (raw)
In-Reply-To: <4DB9E2BA.7050602@twiddle.net>
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:
> 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.
> 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.
r~
next prev parent reply other threads:[~2011-04-29 14:27 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 [this message]
2011-05-09 3:28 ` David Gibson
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=4DBACADA.2000209@twiddle.net \
--to=rth@twiddle.net \
--cc=Joerg.Rodel@amd.com \
--cc=agraf@suse.de \
--cc=aik@ozlabs.ru \
--cc=aliguori@us.ibm.com \
--cc=david@gibson.dropbear.id.au \
--cc=eduard.munteanu@linux360.ro \
--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).