From: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Joerg Roedel <joro@8bytes.org>,
avi@redhat.com, Paul Brook <paul@codesourcery.com>,
kvm@vger.kernel.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Re: [RFC PATCH 4/7] ide: IOMMU support
Date: Thu, 15 Jul 2010 19:45:51 +0300 [thread overview]
Message-ID: <20100715164551.GA16614@localhost> (raw)
In-Reply-To: <4C3F02D2.2090006@codemonkey.ws>
On Thu, Jul 15, 2010 at 07:45:06AM -0500, Anthony Liguori wrote:
>
> No. PCI devices should never call cpu_physical_memory*.
>
> PCI devices should call pci_memory*.
>
> ISA devices should call isa_memory*.
>
> All device memory accesses should go through their respective buses.
> There can be multiple IOMMUs at different levels of the device
> hierarchy. If you don't provide bus-level memory access functions that
> chain through the hierarchy, it's extremely difficult to implement all
> the necessary hooks to perform the translations at different places.
>
> Regards,
>
> Anthony Liguori
>
I liked Paul's initial approach more, at least if I understood him
correctly. Basically I'm suggesting a single memory_* function that
simply asks the bus for I/O and translation. Say you have something like
this:
+ Bus 1
|
---- Memory 1
|
---+ Bus 2 bridge
|
---- Memory 2
|
---+ Bus 3 bridge
|
---- Device
Say Device wants to write to memory. If we have the DeviceState we
needn't concern whether this is a BusOneDevice or BusTwoDevice from
device code itself. We would just call
memory_rw(dev_state, addr, buf, size, is_write);
which simply recurses through DeviceState's and BusState's through their
parent pointers. The actual bus can set up those to provide
identification information and perhaps hooks for translation and access
checking. So memory_rw() looks like this (pseudocode):
static void memory_rw(DeviceState *dev,
target_phys_addr_t addr,
uint8_t *buf,
int size,
int is_write)
{
BusState *bus = get_parent_bus_of_dev(dev);
DeviceState *pdev = get_parent_dev(dev);
target_phys_addr_t taddr;
if (!bus) {
/* This shouldn't happen. */
assert(0);
}
if (bus->responsible_for(addr)) {
raw_physical_memory_rw(addr, buf, size, is_write);
return;
}
taddr = bus->translate(dev, addr);
memory_rw(pdev, taddr, buf, size, is_write);
}
If we do this, it seems there's no need to provide separate
functions. The actual buses must instead initialize those hooks
properly. Translation here is something inherent to the bus, that
handles arbitration between possibly multiple IOMMUs. Our memory would
normally reside on / belong to the top-level bus.
What do you think? (Naming could be better though.)
Eduard
next prev parent reply other threads:[~2010-07-15 16:46 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 [this message]
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
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=20100715164551.GA16614@localhost \
--to=eduard.munteanu@linux360.ro \
--cc=anthony@codemonkey.ws \
--cc=avi@redhat.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=paul@codesourcery.com \
--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).