This patch modifies /dev/mem to call io_remap_page_range rather than
remap_page_range under CONFIG_XEN. (the two definitions are different
under arch xen, unlike most other architectures). This allows the X
server and other programs that use /dev/mem for MMIO to work under
Xen.
Signed-off-by: [email protected]
---
diff -Nurp pristine-linux-2.6.9/drivers/char/mem.c linux-2.6.9-xen0/drivers/char/mem.c
--- pristine-linux-2.6.9/drivers/char/mem.c 2004-10-18 22:54:19.000000000 +0100
+++ linux-2.6.9-xen0/drivers/char/mem.c 2004-11-17 00:12:37.000000000 +0000
@@ -26,6 +26,7 @@
#include <asm/uaccess.h>
#include <asm/io.h>
+#include <asm/pgalloc.h>
#ifdef CONFIG_IA64
# include <linux/efi.h>
@@ -42,7 +43,12 @@ extern void tapechar_init(void);
*/
static inline int uncached_access(struct file *file, unsigned long addr)
{
-#if defined(__i386__)
+#ifdef CONFIG_XEN
+ if (file->f_flags & O_SYNC)
+ return 1;
+ /* Xen sets correct MTRR type on non-RAM for us. */
+ return 0;
+#elif defined(__i386__)
/*
* On the PPro and successors, the MTRRs are used to set
* memory types for physical addresses outside main memory,
@@ -210,9 +216,15 @@ static int mmap_mem(struct file * file,
if (uncached)
vma->vm_flags |= VM_IO;
+#if defined(CONFIG_XEN)
+ if (io_remap_page_range(vma, vma->vm_start, offset,
+ vma->vm_end-vma->vm_start, vma->vm_page_prot))
+ return -EAGAIN;
+#else
if (remap_page_range(vma, vma->vm_start, offset, vma->vm_end-vma->vm_start,
vma->vm_page_prot))
return -EAGAIN;
+#endif
return 0;
}
> On Wed, 2004-11-17 at 15:56, Ian Pratt wrote:
> > +#if defined(CONFIG_XEN)
> > + if (io_remap_page_range(vma, vma->vm_start, offset,
> > + vma->vm_end-vma->vm_start, vma->vm_page_prot))
> > + return -EAGAIN;
> > +#else
> > if (remap_page_range(vma, vma->vm_start, offset, vma->vm_end-vma->vm_start,
> > vma->vm_page_prot))
> > return -EAGAIN;
> > +#endif
> > return 0;
> > }
>
> Do *all* calls to remap_page_range() under your arch need to be
> converted like this, or is this the only one? Seems like something that
> should be done with header magic instead.
It's a bit tricky...
As I understand it, /dev/mem on x86 could potentially be used for
three distinct purposes:
1 mapping the bottom 1MB of physical (bus) address space
2 mapping MMIO devices (beyond physical memory)
3 'copy-on-access' mappings of physical pages
This overloading creates a problem for us, as physical addresses
are not the same as bus addresses in Xen. The first two uses
require bus addresses, the third physical addresses.
I'm not actually aware of any applications that use
copy-on-access mappings of physical memory via /dev/mem, but
there are a whole bunch (most notable the X server) that use
/dev/mem for accessing the <1MB (BIOS) and MMIO frame buffer
regions. Hence, it makes sense for us to choose to interpret the
offset passed in when mapping /dev/mem as a bus address, calling
io_remap_page_range.
As to whether there are any uses of remap_page_range within the
kernel that rely on behaviour 3, I'm not sure. Possibly the use
in af_packet.c does? Not sure.
If there really are no uses, an alternative patch would be to
introduce an ARCH_HAS_REMAP_PAGE_RANGE. Would this be preferable?
Since drivers/char/mem.c already isn't exactly a thing of beauty
we were hoping we might get away with an extra CONFIG_XEN ;-)
Cheers,
Ian
On Wed, 2004-11-17 at 17:05, Ian Pratt wrote:
> If there really are no uses, an alternative patch would be to
> introduce an ARCH_HAS_REMAP_PAGE_RANGE. Would this be preferable?
Well, first of all, remap_page_range() is now deprecated, so some of
this might not even be relevant. :)
My only worry is that you might want *all* calls to
remap_page/pfn_range() to be to io_remap_page/pfn_range() for your
arch. If this isn't the case, then there really isn't an issue. And,
yes, mem.c is a mess.
Thanks for the explanation.
-- Dave
On Wed, 2004-11-17 at 15:56, Ian Pratt wrote:
> +#if defined(CONFIG_XEN)
> + if (io_remap_page_range(vma, vma->vm_start, offset,
> + vma->vm_end-vma->vm_start, vma->vm_page_prot))
> + return -EAGAIN;
> +#else
> if (remap_page_range(vma, vma->vm_start, offset, vma->vm_end-vma->vm_start,
> vma->vm_page_prot))
> return -EAGAIN;
> +#endif
> return 0;
> }
Do *all* calls to remap_page_range() under your arch need to be
converted like this, or is this the only one? Seems like something that
should be done with header magic instead.
-- Dave
Ian Pratt <[email protected]> wrote:
>
>
> This patch modifies /dev/mem to call io_remap_page_range rather than
> remap_page_range under CONFIG_XEN.
And this patch has tabs replaced with whitespace and also does not apply.
> diff -Nurp pristine-linux-2.6.9/drivers/char/mem.c linux-2.6.9-xen0/drivers/char/mem.c
linux-2.6.9 is very very old in kernel time.
> if (remap_page_range(vma, vma->vm_start, offset, vma->vm_end-vma->vm_start,
There is no mention of `remap_page_range' in current kernels.
Please, always generate patches against current kernels. You can use
Linus's bk tree or the latest snapshot from
ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots.
Sort out what's going on with your email client, email the patches to
yourself first, make sure they still apply, then resend.
Thanks.