From: "Stephen C. Tweedie" <sct@redhat.com>
To: Kanoj Sarcar <kanoj@google.engr.sgi.com>
Cc: "Stephen C. Tweedie" <sct@redhat.com>,
Roman Zippel <roman@augan.com>,
linux-mm@kvack.org, linux-kernel@vger.rutgers.edu,
rmk@arm.linux.org.uk, nico@cam.org, davem@redhat.com,
davidm@hpl.hp.com, alan@lxorguk.ukuu.org.uk
Subject: Re: pte_pagenr/MAP_NR deleted in pre6
Date: Thu, 17 Aug 2000 10:11:21 +0100 [thread overview]
Message-ID: <20000817101121.G4037@redhat.com> (raw)
In-Reply-To: <200008162222.PAA95137@google.engr.sgi.com>; from kanoj@google.engr.sgi.com on Wed, Aug 16, 2000 at 03:22:07PM -0700
Hi,
On Wed, Aug 16, 2000 at 03:22:07PM -0700, Kanoj Sarcar wrote:
> > It's part of what is necessary if we want to push kiobufs into the
> > driver layers. page_to_pfn is needed to for PAE36 support so that
> > PCI64 or dual-address-cycle drivers can handle physical addresses
> > longer than 32 bits long.
>
> While we are on this topic, something like
>
> #define page_to_phys(page) \
> ((((page)-(page)->zone->zone_mem_map) << PAGE_SHIFT) \
> + ((page)->zone->zone_start_paddr))
>
> should work on all platforms on 2.4. (You might have to add in an
> unsigned long long somewhere in there for PAE36).
The long long is exactly what we need to avoid: PAE36 still has
pointers as 32-bit values. Only ptes get the 64-bit treatment.
Adding a BUG() test to detect illegal accesses to >4GB pages on PAE36
would be fine. If we have the appropriate bounce buffer support in
place in pci_dma or wherever suits it, then by the time a driver is
doing page_to_phys() it should already have created the appropriate
bounce buffers and so the BUG() test is fine.
For DAC/PCI64 drivers, though, we need a separate macro like
page_to_pfn so that we can identify the physical address via a 32-bit
value. The driver can then shift that into a 64-bit long long if it
wants to --- there's no need to introduce new 64-bit macros into the
mm just for this special case.
Cheers,
Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
next prev parent reply other threads:[~2000-08-17 9:11 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-08-10 17:18 pte_pagenr/MAP_NR deleted in pre6 Kanoj Sarcar
2000-08-11 2:24 ` David S. Miller
2000-08-14 0:34 ` Anton Blanchard
2000-08-11 11:50 ` Roman Zippel
2000-08-11 13:20 ` Russell King
2000-08-11 14:56 ` Roman Zippel
2000-08-12 9:18 ` Bjorn Wesen
2000-08-11 17:21 ` Kanoj Sarcar
2000-08-14 9:29 ` Roman Zippel
2000-08-15 16:19 ` Stephen C. Tweedie
2000-08-16 8:25 ` Roman Zippel
2000-08-16 17:13 ` Kanoj Sarcar
2000-08-16 18:20 ` Stephen C. Tweedie
2000-08-16 18:24 ` David S. Miller
2000-08-16 19:53 ` Stephen C. Tweedie
2000-08-16 18:47 ` Kanoj Sarcar
2000-08-16 18:39 ` David S. Miller
2000-08-16 19:30 ` Stephen C. Tweedie
2000-08-16 22:22 ` Kanoj Sarcar
2000-08-17 9:11 ` Stephen C. Tweedie [this message]
2000-08-17 19:07 ` Kanoj Sarcar
2000-08-17 19:01 ` David S. Miller
2000-08-17 19:19 ` Alan Cox
2000-08-17 19:20 ` David S. Miller
2000-08-17 19:33 ` Alan Cox
2000-08-17 19:36 ` Kanoj Sarcar
2000-09-07 14:31 ` Ralf Baechle
2000-08-17 19:50 ` Kanoj Sarcar
2000-08-17 19:41 ` David S. Miller
2000-09-07 14:26 ` Ralf Baechle
2000-08-17 19:56 ` Alan Cox
2000-08-17 19:24 ` Alan Cox
2000-08-17 19:32 ` Kanoj Sarcar
2000-08-17 19:30 ` David S. Miller
2000-08-17 20:00 ` Kanoj Sarcar
2000-08-16 18:17 ` Stephen C. Tweedie
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=20000817101121.G4037@redhat.com \
--to=sct@redhat.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=davem@redhat.com \
--cc=davidm@hpl.hp.com \
--cc=kanoj@google.engr.sgi.com \
--cc=linux-kernel@vger.rutgers.edu \
--cc=linux-mm@kvack.org \
--cc=nico@cam.org \
--cc=rmk@arm.linux.org.uk \
--cc=roman@augan.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.