mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Paul Mackerras <paulus@samba.org>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: Jesse Barnes <jbarnes@engr.sgi.com>,
	akpm@osdl.org, linux-kernel@vger.kernel.org, riel@redhat.com,
	Ian.Pratt@cl.cam.ac.uk, kurt@garloff.de,
	Christian.Limpach@cl.cam.ac.uk
Subject: Re: [PATCH] Xen/i386 cleanups - AGP bus/phys cleanups
Date: Thu, 17 Mar 2005 20:34:47 +1100	[thread overview]
Message-ID: <16953.20279.77584.501222@cargo.ozlabs.ibm.com> (raw)
In-Reply-To: <29ab1884ee5724e9efcfe43f14d13376@cl.cam.ac.uk>

Keir Fraser writes:

> 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.

This code needs real physical addresses, which are not the same things
as bus addresses.  I thought from what Rik said that virt_to_phys
should give you real physical addresses, while virt_to_pfn would give
you the contiguous "physical" page numbers - is that the case?

> 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?

Well, a northbridge register.  The northbridge is in a privileged
position in that it controls the memory and can access all of it
directly using physical addresses, something which PCI or other
devices can't.  The address you poke into a register to define the
base of the table is a physical address.  How could it be a bus
address, when the whole point of the table is to translate bus
addresses to physical addresses?  If it was a bus address you would
have to know where the table was before you could work out where the
table was.

> 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 

No, the GART is a bridge between a bus and memory, and the GATT
entries are physical addresses.

> 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 

This is also wrong - the base address of the GATT is a physical
address not a bus address.  This change will break agpgart on ppc64
systems and I won't be able to play bzflag on my G5 any more. :)
dma_alloc_coherent allocates iommu entries and returns a bus address,
but the addresses coming out of the GART don't go through a further
translation through the iommu.

> 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.

It sounds like xen is trying to overload the concepts of physical and
bus addresses to represent the mapping from "logical" addresses seen
by the kernel to "absolute" addresses (the "real" physical
addresses).  IMHO that is a mistake and will only lead to trouble.

Regards,
Paul.

  reply	other threads:[~2005-03-17  9:33 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-16 11:48 Keir Fraser
2005-03-16 14:31 ` Christoph Hellwig
2005-03-16 14:58   ` Keir Fraser
2005-03-16 15:01   ` Rik van Riel
2005-03-16 18:10     ` Christoph Hellwig
2005-03-16 18:35       ` Keir Fraser
2005-03-16 18:42         ` Jesse Barnes
2005-03-16 19:08           ` Keir Fraser
2005-03-16 19:06         ` Christoph Hellwig
2005-03-16 19:11           ` Keir Fraser
2005-03-16 17:40   ` Alan Cox
2005-03-16 17:54 ` Jesse Barnes
2005-03-16 21:24 ` Paul Mackerras
2005-03-16 22:06   ` Jesse Barnes
2005-03-16 23:55     ` Rik van Riel
2005-03-17  0:39       ` Paul Mackerras
2005-03-17  1:05         ` Tupshin Harper
2005-03-17  3:44         ` Rik van Riel
2005-03-17  4:42       ` Christoph Hellwig
2005-03-17  4:58         ` Rik van Riel
2005-03-17  9:16     ` Keir Fraser
2005-03-17  9:34       ` Paul Mackerras [this message]
2005-03-17 10:56         ` Keir Fraser
2005-03-19 10:07           ` Eric W. Biederman
2005-03-19 10:56             ` Christian Limpach
2005-03-19 13:01               ` Keir Fraser
2005-03-17 13:53         ` Alan Cox
2005-03-18  0:16           ` Paul Mackerras
2005-03-18  4:23             ` Rik van Riel
2005-03-18  9:05             ` Keir Fraser

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=16953.20279.77584.501222@cargo.ozlabs.ibm.com \
    --to=paulus@samba.org \
    --cc=Christian.Limpach@cl.cam.ac.uk \
    --cc=Ian.Pratt@cl.cam.ac.uk \
    --cc=Keir.Fraser@cl.cam.ac.uk \
    --cc=akpm@osdl.org \
    --cc=jbarnes@engr.sgi.com \
    --cc=kurt@garloff.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riel@redhat.com \
    /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

all inboxes | Powered by JetHome®