Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups
From: Keir Fraser
Date: Thu Mar 17 2005 - 04:15:44 EST
On 16 Mar 2005, at 22:06, Jesse Barnes wrote:
The distinction is that physical addresses are what are used to access
physical memory, whereas bus addresses are what appears on some
external bus (usually PCI). The GATT sits between an external (AGP)
bus and memory, so while the GATT is indexed using bus addresses, its
entries contain physical addresses. So in fact virt_to_phys is the
correct thing to use to calculate values to put in GATT entries.
Thanks for the explanation Paul, now the code actually makes sense.
Converting to the DMA mapping API doesn't make sense at all in this
context
then, since we're basically programming the GATT (an IOMMU type table)
with
physical addresses. Ken, are you sure you need to make these changes
at all?
Does Xen break w/o them?
Yes, Xen will break w/o them, because physical addresses are an
illusory trick that the guest OS plays on itself to give itself the
impression of a contiguous memory map. We use _to_machine and _to_bus
macros to get 'real' physical addresses.
For allocating the GATT itself, using dma_alloc_coherent() as done in
my patch certainly seems sane -- the bus base address of that table is
poked into a chipset register, right?
As for poking entries into the GATT, I guess I'm not sure what ought to
be used. virt_to_phys() doesn't sound right to me: the GART is a bridge
between two buses, so some sort of bus mapping would still be in order
imo. Perhaps Linux should allow mapping requests to be tagged with a
bridge id, like in *BSD? :-)
So: I would very much like you to take the patches I made to generic.c
that replace __get_free_pages() calls with dma_alloc_coherent(). For
now, the patch lines that poke into the GATT I guess stay as they are.
We can maintain an out-of-tree patch for Xen, or perhaps if
virt_to_phys() is not used very much we can override its definition.
-- Keir
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/