Re: [Xen-changelog] [linux-2.6.18-xen] Add "#ifdef ARCH_HAS_DEV_MEM" to archtecture specific file_operations.

Re: [Xen-changelog] [linux-2.6.18-xen] Add "#ifdef ARCH_HAS_DEV_MEM" to archtecture specific file_operations.

[Hollis Blanchard]

This is producing warnings for me on PowerPC, which does not define
ARCH_HAS_DEV_MEM:

/home/hollisb/source/linux-2.6.18-xen-ppc.hg/drivers/xen/char/mem.c:151:
warning: 'xen_mmap_mem' defined but not used
/home/hollisb/source/linux-2.6.18-xen-ppc.hg/drivers/xen/char/mem.c:172:
warning: 'memory_lseek' defined but not used
/home/hollisb/source/linux-2.6.18-xen-ppc.hg/drivers/xen/char/mem.c:195:
warning: 'open_mem' defined but not used

As far as I can see, x86 does not define ARCH_HAS_DEV_MEM either, so
should see the same problem?

On Fri, 2007-07-06 at 10:15 -0700, Xen patchbot-linux-2.6.18-xen wrote:
> # HG changeset patch
> # User kfraser@localhost.localdomain
> # Date 1183728779 -3600
> # Node ID 4a08141e62ca189577041d8854bb478e5fbe502f
> # Parent  9e66b8728bd3a5d857500117c421051ae7dd0d61
> Add "#ifdef ARCH_HAS_DEV_MEM" to archtecture specific file_operations.
> Signed-off-by: Jun Kamada <kama@jp.fujitsu.com>
> ---
>  drivers/xen/Kconfig       |    4 ++++
>  drivers/xen/char/Makefile |    3 +--
>  drivers/xen/char/mem.c    |    4 ++++
>  3 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff -r 9e66b8728bd3 -r 4a08141e62ca drivers/xen/Kconfig
> --- a/drivers/xen/Kconfig	Fri Jul 06 14:01:27 2007 +0100
> +++ b/drivers/xen/Kconfig	Fri Jul 06 14:32:59 2007 +0100
> @@ -281,4 +281,8 @@ config XEN_XENCOMM
>  config XEN_XENCOMM
>  	bool
> 
> +config XEN_DEVMEM
> +	bool
> +	default y
> +
>  endif
> diff -r 9e66b8728bd3 -r 4a08141e62ca drivers/xen/char/Makefile
> --- a/drivers/xen/char/Makefile	Fri Jul 06 14:01:27 2007 +0100
> +++ b/drivers/xen/char/Makefile	Fri Jul 06 14:32:59 2007 +0100
> @@ -1,2 +1,1 @@
> -
> -obj-y	:= mem.o
> +obj-$(CONFIG_XEN_DEVMEM)	:= mem.o
> diff -r 9e66b8728bd3 -r 4a08141e62ca drivers/xen/char/mem.c
> --- a/drivers/xen/char/mem.c	Fri Jul 06 14:01:27 2007 +0100
> +++ b/drivers/xen/char/mem.c	Fri Jul 06 14:32:59 2007 +0100
> @@ -33,6 +33,7 @@ static inline int valid_phys_addr_range(
>  }
>  #endif
> 
> +#ifdef ARCH_HAS_DEV_MEM
>  /*
>   * This funcion reads the *physical* memory. The f_pos points directly to the 
>   * memory location. 
> @@ -135,6 +136,7 @@ static ssize_t write_mem(struct file * f
>  	*ppos += written;
>  	return written;
>  }
> +#endif
> 
>  #ifndef ARCH_HAS_DEV_MEM_MMAP_MEM
>  static inline int uncached_access(struct file *file)
> @@ -194,6 +196,7 @@ static int open_mem(struct inode * inode
>  	return capable(CAP_SYS_RAWIO) ? 0 : -EPERM;
>  }
> 
> +#ifdef ARCH_HAS_DEV_MEM
>  const struct file_operations mem_fops = {
>  	.llseek		= memory_lseek,
>  	.read		= read_mem,
> @@ -201,3 +204,4 @@ const struct file_operations mem_fops = 
>  	.mmap		= xen_mmap_mem,
>  	.open		= open_mem,
>  };
> +#endif
> 
> _______________________________________________
> Xen-changelog mailing list
> Xen-changelog@lists.xensource.com
> http://lists.xensource.com/xen-changelog
-- 
Hollis Blanchard
IBM Linux Technology Center

Re: Re: [Xen-changelog] [linux-2.6.18-xen] Add "#ifdef ARCH_HAS_DEV_MEM" to archtecture specific file_operations.

[Keir Fraser]

We define it in asm/mach-xen/asm/io.h.

However, the patch *is* of questionable value. It guards the only non-static
definition in the file with #ifdef ARCH_HAS_DEV_MEM. Which begs the question
why you would build the file at all if !ARCH_HAS_DEV_MEM. I'll revert it.

By the way, I wonder how PPC manages to build both drivers/char/mem.c and
drivers/xen/char/mem.c without ARCH_HAS_DEV_MEM? The model is supposed to be
that mem_fops defined by the Xen file is picked up by the generic file. If
!ARCH_HAS_DEV_MEM then that doesn't happen -- so who picks up the Xen
mem_fops?

 -- Keir

On 6/7/07 21:25, "Hollis Blanchard" <hollisb@us.ibm.com> wrote:

> This is producing warnings for me on PowerPC, which does not define
> ARCH_HAS_DEV_MEM:
> 
> /home/hollisb/source/linux-2.6.18-xen-ppc.hg/drivers/xen/char/mem.c:151:
> warning: 'xen_mmap_mem' defined but not used
> /home/hollisb/source/linux-2.6.18-xen-ppc.hg/drivers/xen/char/mem.c:172:
> warning: 'memory_lseek' defined but not used
> /home/hollisb/source/linux-2.6.18-xen-ppc.hg/drivers/xen/char/mem.c:195:
> warning: 'open_mem' defined but not used
> 
> As far as I can see, x86 does not define ARCH_HAS_DEV_MEM either, so
> should see the same problem?
> 
> On Fri, 2007-07-06 at 10:15 -0700, Xen patchbot-linux-2.6.18-xen wrote:
>> # HG changeset patch
>> # User kfraser@localhost.localdomain
>> # Date 1183728779 -3600
>> # Node ID 4a08141e62ca189577041d8854bb478e5fbe502f
>> # Parent  9e66b8728bd3a5d857500117c421051ae7dd0d61
>> Add "#ifdef ARCH_HAS_DEV_MEM" to archtecture specific file_operations.
>> Signed-off-by: Jun Kamada <kama@jp.fujitsu.com>
>> ---
>>  drivers/xen/Kconfig       |    4 ++++
>>  drivers/xen/char/Makefile |    3 +--
>>  drivers/xen/char/mem.c    |    4 ++++
>>  3 files changed, 9 insertions(+), 2 deletions(-)
>> 
>> diff -r 9e66b8728bd3 -r 4a08141e62ca drivers/xen/Kconfig
>> --- a/drivers/xen/Kconfig Fri Jul 06 14:01:27 2007 +0100
>> +++ b/drivers/xen/Kconfig Fri Jul 06 14:32:59 2007 +0100
>> @@ -281,4 +281,8 @@ config XEN_XENCOMM
>>  config XEN_XENCOMM
>> bool
>> 
>> +config XEN_DEVMEM
>> + bool
>> + default y
>> +
>>  endif
>> diff -r 9e66b8728bd3 -r 4a08141e62ca drivers/xen/char/Makefile
>> --- a/drivers/xen/char/Makefile Fri Jul 06 14:01:27 2007 +0100
>> +++ b/drivers/xen/char/Makefile Fri Jul 06 14:32:59 2007 +0100
>> @@ -1,2 +1,1 @@
>> -
>> -obj-y := mem.o
>> +obj-$(CONFIG_XEN_DEVMEM) := mem.o
>> diff -r 9e66b8728bd3 -r 4a08141e62ca drivers/xen/char/mem.c
>> --- a/drivers/xen/char/mem.c Fri Jul 06 14:01:27 2007 +0100
>> +++ b/drivers/xen/char/mem.c Fri Jul 06 14:32:59 2007 +0100
>> @@ -33,6 +33,7 @@ static inline int valid_phys_addr_range(
>>  }
>>  #endif
>> 
>> +#ifdef ARCH_HAS_DEV_MEM
>>  /*
>>   * This funcion reads the *physical* memory. The f_pos points directly to
>> the 
>>   * memory location.
>> @@ -135,6 +136,7 @@ static ssize_t write_mem(struct file * f
>> *ppos += written;
>> return written;
>>  }
>> +#endif
>> 
>>  #ifndef ARCH_HAS_DEV_MEM_MMAP_MEM
>>  static inline int uncached_access(struct file *file)
>> @@ -194,6 +196,7 @@ static int open_mem(struct inode * inode
>> return capable(CAP_SYS_RAWIO) ? 0 : -EPERM;
>>  }
>> 
>> +#ifdef ARCH_HAS_DEV_MEM
>>  const struct file_operations mem_fops = {
>> .llseek  = memory_lseek,
>> .read  = read_mem,
>> @@ -201,3 +204,4 @@ const struct file_operations mem_fops =
>> .mmap  = xen_mmap_mem,
>> .open  = open_mem,
>>  };
>> +#endif
>> 
>> _______________________________________________
>> Xen-changelog mailing list
>> Xen-changelog@lists.xensource.com
>> http://lists.xensource.com/xen-changelog

Re: Re: [Xen-changelog] [linux-2.6.18-xen] Add "#ifdef ARCH_HAS_DEV_MEM" to archtecture specific file_operations.

[Hollis Blanchard]

On Sat, 2007-07-07 at 10:01 +0100, Keir Fraser wrote:
> 
> By the way, I wonder how PPC manages to build both drivers/char/mem.c and
> drivers/xen/char/mem.c without ARCH_HAS_DEV_MEM? The model is supposed to be
> that mem_fops defined by the Xen file is picked up by the generic file. If
> !ARCH_HAS_DEV_MEM then that doesn't happen -- so who picks up the Xen
> mem_fops? 

Hmmm, yeah. Looks like we haven't tested that... :)

-- 
Hollis Blanchard
IBM Linux Technology Center

Re: Re: [Xen-changelog] [linux-2.6.18-xen] Add "#ifdef ARCH_HAS_DEV_MEM" to archtecture specific file_operations.

[Keir Fraser]

On 9/7/07 20:20, "Hollis Blanchard" <hollisb@us.ibm.com> wrote:

>> By the way, I wonder how PPC manages to build both drivers/char/mem.c and
>> drivers/xen/char/mem.c without ARCH_HAS_DEV_MEM? The model is supposed to be
>> that mem_fops defined by the Xen file is picked up by the generic file. If
>> !ARCH_HAS_DEV_MEM then that doesn't happen -- so who picks up the Xen
>> mem_fops? 
> 
> Hmmm, yeah. Looks like we haven't tested that... :)

If you don't need to build both then there is potentially no problem with
the Xen file hijacking the xlate_dev_mem() functions.

 -- Keir

Re: Re: [Xen-changelog] [linux-2.6.18-xen] Add "#ifdef ARCH_HAS_DEV_MEM" to archtecture specific file_operations.

[Hollis Blanchard]

On Mon, 2007-07-09 at 20:26 +0100, Keir Fraser wrote:
> On 9/7/07 20:20, "Hollis Blanchard" <hollisb@us.ibm.com> wrote:
> 
> >> By the way, I wonder how PPC manages to build both drivers/char/mem.c and
> >> drivers/xen/char/mem.c without ARCH_HAS_DEV_MEM? The model is supposed to be
> >> that mem_fops defined by the Xen file is picked up by the generic file. If
> >> !ARCH_HAS_DEV_MEM then that doesn't happen -- so who picks up the Xen
> >> mem_fops? 
> > 
> > Hmmm, yeah. Looks like we haven't tested that... :)
> 
> If you don't need to build both then there is potentially no problem with
> the Xen file hijacking the xlate_dev_mem() functions.

PowerPC Linux builds support for multiple platforms, including multiple
hypervisors, into a single binary (paravirt_ops was inspired by ppc_md).
For the most part our Xen patches continue this model, but because we
don't really test our Xen kernel on non-Xen platforms, there are a
couple bugs that would need fixing.

So compile-time ifdefs for /dev/mem won't work long-term, but I'm not
really worried about it.

-- 
Hollis Blanchard
IBM Linux Technology Center

Re: [XenPPC] Re: Re: [Xen-changelog] [linux-2.6.18-xen] Add "#ifdef ARCH_HAS_DEV_MEM" to archtecture specific file_operations.

[Jimi Xenidis]

On Jul 9, 2007, at 3:41 PM, Hollis Blanchard wrote:

> On Mon, 2007-07-09 at 20:26 +0100, Keir Fraser wrote:
>> On 9/7/07 20:20, "Hollis Blanchard" <hollisb@us.ibm.com> wrote:
>>
>>>> By the way, I wonder how PPC manages to build both drivers/char/ 
>>>> mem.c and
>>>> drivers/xen/char/mem.c without ARCH_HAS_DEV_MEM? The model is  
>>>> supposed to be
>>>> that mem_fops defined by the Xen file is picked up by the  
>>>> generic file. If
>>>> !ARCH_HAS_DEV_MEM then that doesn't happen -- so who picks up  
>>>> the Xen
>>>> mem_fops?
>>>
>>> Hmmm, yeah. Looks like we haven't tested that... :)

yeah, we have :)
xlate_dev_mem_ptr() works just fine for us, so drivers/char/mem.c  
just works and the xen version of the ops is never considered.

Actually we should be forcing CONFIG_XEN_DEVMEM, but the Makefile  
ignores it.
-JX

Re: [XenPPC] Re: Re: [Xen-changelog] [linux-2.6.18-xen] Add "#ifdef ARCH_HAS_DEV_MEM" to archtecture specific file_operations.

[Jimi Xenidis]

On Jul 9, 2007, at 4:23 PM, Jimi Xenidis wrote:

>
> On Jul 9, 2007, at 3:41 PM, Hollis Blanchard wrote:
>
>> On Mon, 2007-07-09 at 20:26 +0100, Keir Fraser wrote:
>>> On 9/7/07 20:20, "Hollis Blanchard" <hollisb@us.ibm.com> wrote:
>>>
>>>>> By the way, I wonder how PPC manages to build both drivers/char/ 
>>>>> mem.c and
>>>>> drivers/xen/char/mem.c without ARCH_HAS_DEV_MEM? The model is  
>>>>> supposed to be
>>>>> that mem_fops defined by the Xen file is picked up by the  
>>>>> generic file. If
>>>>> !ARCH_HAS_DEV_MEM then that doesn't happen -- so who picks up  
>>>>> the Xen
>>>>> mem_fops?
>>>>
>>>> Hmmm, yeah. Looks like we haven't tested that... :)
>
> yeah, we have :)
> xlate_dev_mem_ptr() works just fine for us, so drivers/char/mem.c  
> just works and the xen version of the ops is never considered.
>
> Actually we should be forcing CONFIG_XEN_DEVMEM, but the Makefile  
> ignores it.
s/CONFIG_XEN_DEVMEM/CONFIG_XEN_DEVMEM=n/
> -JX
>
> _______________________________________________
> Xen-ppc-devel mailing list
> Xen-ppc-devel@lists.xensource.com
> http://lists.xensource.com/xen-ppc-devel

Re: Re: [Xen-changelog] [linux-2.6.18-xen] Add "#ifdef ARCH_HAS_DEV_MEM" to archtecture specific file_operations.

[Jun Kamada]

[-- Attachment #1: Type: text/plain, Size: 635 bytes --]

Keir-san and Hollis-san,

On Sat, 07 Jul 2007 10:01:31 +0100
Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote:
> We define it in asm/mach-xen/asm/io.h.
> 
> However, the patch *is* of questionable value. It guards the only non-static
> definition in the file with #ifdef ARCH_HAS_DEV_MEM. Which begs the question
> why you would build the file at all if !ARCH_HAS_DEV_MEM. I'll revert it.

I'm sorry that I had posted the incomplete patch. I will attach a new
one modified. The patch resolves ploblems mentioned above?

Best regards,

-----
Jun Kamada
Linux Technology Development Div.
Server Systems Unit
Fujitsu Ltd.
kama@jp.fujitsu.com

[-- Attachment #2: add_ifdef_arch_has_dev_mem.patch --]
[-- Type: application/octet-stream, Size: 1157 bytes --]

# HG changeset patch
# User Jun Kamada <kama@jp.fujitsu.com>
# Date 1184125315 -32400
# Node ID d427a098231e8aba4c930d9b54fce4be52952a53
# Parent  86ac3059ab675a1c80ab02be513afb57b5e63efa
ARCH_HAS_DEV_MEM for read_mem() and write_mem() in drivers/xen/char/mem.c

Signed-off-by: Jun Kamada <kama@jp.fujitsu.com>

diff -r 86ac3059ab67 -r d427a098231e drivers/xen/char/mem.c
--- a/drivers/xen/char/mem.c	Tue Jul 10 11:18:07 2007 -0600
+++ b/drivers/xen/char/mem.c	Wed Jul 11 12:41:55 2007 +0900
@@ -33,6 +33,7 @@ static inline int valid_phys_addr_range(
 }
 #endif
 
+#ifdef ARCH_HAS_DEV_MEM
 /*
  * This funcion reads the *physical* memory. The f_pos points directly to the 
  * memory location. 
@@ -135,6 +136,7 @@ static ssize_t write_mem(struct file * f
 	*ppos += written;
 	return written;
 }
+#endif
 
 #ifndef ARCH_HAS_DEV_MEM_MMAP_MEM
 static inline int uncached_access(struct file *file)
@@ -196,8 +198,10 @@ static int open_mem(struct inode * inode
 
 const struct file_operations mem_fops = {
 	.llseek		= memory_lseek,
+#ifdef ARCH_HAS_DEV_MEM
 	.read		= read_mem,
 	.write		= write_mem,
+#endif
 	.mmap		= xen_mmap_mem,
 	.open		= open_mem,
 };

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Re: [Xen-changelog] [linux-2.6.18-xen] Add "#ifdef ARCH_HAS_DEV_MEM" to archtecture specific file_operations.

[Keir Fraser]

On 11/7/07 06:44, "Jun Kamada" <kama@jp.fujitsu.com> wrote:

>> We define it in asm/mach-xen/asm/io.h.
>> 
>> However, the patch *is* of questionable value. It guards the only non-static
>> definition in the file with #ifdef ARCH_HAS_DEV_MEM. Which begs the question
>> why you would build the file at all if !ARCH_HAS_DEV_MEM. I'll revert it.
> 
> I'm sorry that I had posted the incomplete patch. I will attach a new
> one modified. The patch resolves ploblems mentioned above?

The case of building drivers/xen/char/mem.c, yet not defining
ARCH_HAS_DEV_MEM, does not seem useful. Who will pick up and use the
mem_fops defined by drivers/xen/char/mem.c?

At the very least this seems abusive of ARCH_HAS_DEV_MEM, and you might be
better off defining a different macro name? But I think you need to explain
to us what it is you're actually trying to achieve.

 -- Keir

Re: Re: [Xen-changelog] [linux-2.6.18-xen] Add "#ifdef ARCH_HAS_DEV_MEM" to archtecture specific file_operations.

[Jun Kamada]

Keir-san,

On Wed, 11 Jul 2007 11:00:37 +0100
Keir Fraser <keir@xensource.com> wrote:
> The case of building drivers/xen/char/mem.c, yet not defining
> ARCH_HAS_DEV_MEM, does not seem useful. Who will pick up and use the
> mem_fops defined by drivers/xen/char/mem.c?
> 
> At the very least this seems abusive of ARCH_HAS_DEV_MEM, and you might be
> better off defining a different macro name? But I think you need to explain
> to us what it is you're actually trying to achieve.

I would like to deal with the drivers/xen/char/mem.c as follows. How do
you think about it? It will cause any problem?

- I will post a patch, which removes definition of ARCH_HAS_DEV_MEM, to
  xen-ia64-devel later.
- If needed, I will post a revert patch of 
  "xen-ia64-devel.hg c/s 12544:395aa5609e6d". (Creating the revert patch
  may be difficult...)

> better off defining a different macro name? But I think you need to explain
> to us what it is you're actually trying to achieve.

We would like to map machine address to guest physical address at PCI
initialization phase but at mmap system call in order to support Xwindow.
The patch I posted is one of the patch which disables mapping process at
mmap system call.

Best regards,

-----
Jun Kamada
Linux Technology Development Div.
Server Systems Unit
Fujitsu Ltd.
kama@jp.fujitsu.com

Re: [Xen-devel] Re: [Xen-changelog] [linux-2.6.18-xen] Add "#ifdefARCH_HAS_DEV_MEM" to archtecture specific file_operations.

[Akio Takebe]

[-- Attachment #1: Mail message body --]
[-- Type: text/plain, Size: 1686 bytes --]

Hi, Kama, Keir and Isaku

>On Wed, 11 Jul 2007 11:00:37 +0100
>Keir Fraser <keir@xensource.com> wrote:
>> The case of building drivers/xen/char/mem.c, yet not defining
>> ARCH_HAS_DEV_MEM, does not seem useful. Who will pick up and use the
>> mem_fops defined by drivers/xen/char/mem.c?
>> 
>> At the very least this seems abusive of ARCH_HAS_DEV_MEM, and you might be
>> better off defining a different macro name? But I think you need to explain
>> to us what it is you're actually trying to achieve.
>
>I would like to deal with the drivers/xen/char/mem.c as follows. How do
>you think about it? It will cause any problem?
>
>- I will post a patch, which removes definition of ARCH_HAS_DEV_MEM, to
>  xen-ia64-devel later.
>- If needed, I will post a revert patch of 
>  "xen-ia64-devel.hg c/s 12544:395aa5609e6d". (Creating the revert patch
>  may be difficult...)
Xen-ia64 already don't need to modify drivers/xen/char/mem.c.
But as you mentioned, current drivers/xen/char/mem.c has some parts
for xen-ia64. So we may need to cleanup drivers/xen/char/mem.c.

I made a attached revert patch of xen-unstablecs12513[1]
(same as xen-ia64 cs12544). Keir, Isaku, how about it?

If the patch is applied, we cannot compile linux-xen-ia64.
But I have a patch of reverting cs12873[2],
if the patch is also applied, we can compile linux-xen-ia64 again.
I think Kama will post this patch to xen-ia64-devel soon.

Signed-off-by: Akio Takebe <takebe_akio@jp.fujitsu.com>
Signed-off-by: Jun Kamada <kama@jp.fujitsu.com>

[1] cs12513
http://xenbits.xensource.com/xen-unstable.hg?rev/395aa5609e6d
[2] cs12873
http://xenbits.xensource.com/xen-unstable.hg?rev/e5e6893ec699

Best Regards,

Akio Takebe

[-- Attachment #2: revert_12513.patch --]
[-- Type: application/octet-stream, Size: 3482 bytes --]

diff -r 86ac3059ab67 drivers/xen/char/mem.c
--- a/drivers/xen/char/mem.c	Tue Jul 10 11:18:07 2007 -0600
+++ b/drivers/xen/char/mem.c	Thu Jul 12 23:49:29 2007 +0900
@@ -26,12 +26,13 @@
 #include <asm/io.h>
 #include <asm/hypervisor.h>
 
-#ifndef ARCH_HAS_VALID_PHYS_ADDR_RANGE
-static inline int valid_phys_addr_range(unsigned long addr, size_t count)
+static inline int uncached_access(struct file *file)
 {
-	return 1;
+	if (file->f_flags & O_SYNC)
+		return 1;
+	/* Xen sets correct MTRR type on non-RAM for us. */
+	return 0;
 }
-#endif
 
 /*
  * This funcion reads the *physical* memory. The f_pos points directly to the 
@@ -44,9 +45,6 @@ static ssize_t read_mem(struct file * fi
 	ssize_t read = 0, sz;
 	void __iomem *v;
 
-	if (!valid_phys_addr_range(p, count))
-		return -EFAULT;
-
 	while (count > 0) {
 		/*
 		 * Handle first page in case it's not aligned
@@ -58,7 +56,7 @@ static ssize_t read_mem(struct file * fi
 
 		sz = min_t(unsigned long, sz, count);
 
-		v = xen_xlate_dev_mem_ptr(p, sz);
+		v = ioremap(p, sz);
 		if (IS_ERR(v) || v == NULL) {
 			/*
 			 * Some programs (e.g., dmidecode) groove off into
@@ -75,7 +73,7 @@ static ssize_t read_mem(struct file * fi
 		}
 
 		ignored = copy_to_user(buf, v, sz);
-		xen_xlate_dev_mem_ptr_unmap(v);
+		iounmap(v);
 		if (ignored)
 			return -EFAULT;
 		buf += sz;
@@ -95,9 +93,6 @@ static ssize_t write_mem(struct file * f
 	ssize_t written = 0, sz;
 	void __iomem *v;
 
-	if (!valid_phys_addr_range(p, count))
-		return -EFAULT;
-
 	while (count > 0) {
 		/*
 		 * Handle first page in case it's not aligned
@@ -109,7 +104,7 @@ static ssize_t write_mem(struct file * f
 
 		sz = min_t(unsigned long, sz, count);
 
-		v = xen_xlate_dev_mem_ptr(p, sz);
+		v = ioremap(p, sz);
 		if (v == NULL)
 			break;
 		if (IS_ERR(v)) {
@@ -119,7 +114,7 @@ static ssize_t write_mem(struct file * f
 		}
 
 		ignored = copy_from_user(v, buf, sz);
-		xen_xlate_dev_mem_ptr_unmap(v);
+		iounmap(v);
 		if (ignored) {
 			written += sz - ignored;
 			if (written)
@@ -137,14 +132,6 @@ static ssize_t write_mem(struct file * f
 }
 
 #ifndef ARCH_HAS_DEV_MEM_MMAP_MEM
-static inline int uncached_access(struct file *file)
-{
-	if (file->f_flags & O_SYNC)
-		return 1;
-	/* Xen sets correct MTRR type on non-RAM for us. */
-	return 0;
-}
-
 static int xen_mmap_mem(struct file * file, struct vm_area_struct * vma)
 {
 	size_t size = vma->vm_end - vma->vm_start;
diff -r 86ac3059ab67 include/asm-i386/mach-xen/asm/io.h
--- a/include/asm-i386/mach-xen/asm/io.h	Tue Jul 10 11:18:07 2007 -0600
+++ b/include/asm-i386/mach-xen/asm/io.h	Thu Jul 12 23:47:18 2007 +0900
@@ -53,8 +53,7 @@
  * Convert a physical pointer to a virtual kernel pointer for /dev/mem
  * access
  */
-#define xen_xlate_dev_mem_ptr(p, sz)	ioremap(p, sz)
-#define xen_xlate_dev_mem_ptr_unmap(p)	iounmap(p)
+#define xen_xlate_dev_mem_ptr(p)	__va(p)
 
 /*
  * Convert a virtual cached pointer to an uncached pointer
diff -r 86ac3059ab67 include/asm-x86_64/mach-xen/asm/io.h
--- a/include/asm-x86_64/mach-xen/asm/io.h	Tue Jul 10 11:18:07 2007 -0600
+++ b/include/asm-x86_64/mach-xen/asm/io.h	Thu Jul 12 23:47:10 2007 +0900
@@ -315,8 +315,7 @@ extern int iommu_bio_merge;
  * Convert a physical pointer to a virtual kernel pointer for /dev/mem
  * access
  */
-#define xen_xlate_dev_mem_ptr(p, sz)	ioremap(p, sz)
-#define xen_xlate_dev_mem_ptr_unmap(p)	iounmap(p)
+#define xen_xlate_dev_mem_ptr(p)	__va(p)
 
 /*
  * Convert a virtual cached pointer to an uncached pointer

[-- Attachment #3: revert_12873.patch --]
[-- Type: application/octet-stream, Size: 4964 bytes --]

# HG changeset patch
# User root@pq480-rhel5.soft.fujitsu.com
# Date 1184254766 -32400
# Node ID c94d485e18d7fb33abab4c1e6761d9d62a192603
# Parent  02987ed7948ad0b0253fbc53991bf61ae2e305e4
revert 12873:[IA64] paraviatualize /dev/mem to enable X.
http://xenbits.xensource.com/xen-unstable.hg?rev/e5e6893ec699

diff -r 02987ed7948a -r c94d485e18d7 arch/ia64/Kconfig
--- a/arch/ia64/Kconfig	Fri Jul 13 00:00:44 2007 +0900
+++ b/arch/ia64/Kconfig	Fri Jul 13 00:39:26 2007 +0900
@@ -582,6 +582,9 @@ if XEN
 if XEN
 config XEN_SMPBOOT
 	default n
+
+config XEN_DEVMEM
+	default n
 endif
 
 source "drivers/xen/Kconfig"
diff -r 02987ed7948a -r c94d485e18d7 arch/ia64/xen/Makefile
--- a/arch/ia64/xen/Makefile	Fri Jul 13 00:00:44 2007 +0900
+++ b/arch/ia64/xen/Makefile	Fri Jul 13 00:39:26 2007 +0900
@@ -4,6 +4,6 @@
 
 obj-y := hypercall.o xenivt.o xenentry.o xensetup.o xenpal.o xenhpski.o \
 	 hypervisor.o util.o xencomm.o xcom_hcall.o xcom_mini.o \
-	 xcom_privcmd.o mem.o xen_dma.o
+	 xcom_privcmd.o xen_dma.o
 
 obj-$(CONFIG_IA64_GENERIC) += machvec.o
diff -r 02987ed7948a -r c94d485e18d7 arch/ia64/xen/mem.c
--- a/arch/ia64/xen/mem.c	Fri Jul 13 00:00:44 2007 +0900
+++ /dev/null	Thu Jan 01 00:00:00 1970 +0000
@@ -1,75 +0,0 @@
-/*
- *  Originally from linux/drivers/char/mem.c
- *
- *  Copyright (C) 1991, 1992  Linus Torvalds
- *
- *  Added devfs support. 
- *    Jan-11-1998, C. Scott Ananian <cananian@alumni.princeton.edu>
- *  Shared /dev/zero mmaping support, Feb 2000, Kanoj Sarcar <kanoj@sgi.com>
- */
-/*
- * taken from
- * linux/drivers/char/mem.c and linux-2.6-xen-sparse/drivers/xen/char/mem.c.
- * adjusted for IA64 and made transparent.
- * Copyright (c) 2006 Isaku Yamahata <yamahata at valinux co jp>
- *                    VA Linux Systems Japan K.K.
- */
-
-#include <linux/mm.h>
-#include <linux/efi.h>
-
-/*
- * Architectures vary in how they handle caching for addresses
- * outside of main memory.
- *
- */
-static inline int uncached_access(struct file *file, unsigned long addr)
-{
-	/*
-	 * On ia64, we ignore O_SYNC because we cannot tolerate memory attribute aliases.
-	 */
-	return !(efi_mem_attributes(addr) & EFI_MEMORY_WB);
-}
-
-int xen_mmap_mem(struct file * file, struct vm_area_struct * vma)
-{
-	unsigned long addr = vma->vm_pgoff << PAGE_SHIFT;
-	size_t size = vma->vm_end - vma->vm_start;
-
-
-#if 0
-	/*
-	 *XXX FIXME: linux-2.6.16.29, linux-2.6.17
-	 *    valid_mmap_phys_addr_range() in linux/arch/ia64/kernel/efi.c
-	 *    fails checks.
-	 *    linux-2.6.18.1's returns always 1. 
-	 *    Its comments says
-	 *
-         * MMIO regions are often missing from the EFI memory map.
-         * We must allow mmap of them for programs like X, so we
-         * currently can't do any useful validation.
-         */
-	if (!valid_mmap_phys_addr_range(addr, &size))
-		return -EINVAL;
-	if (size < vma->vm_end - vma->vm_start)
-		return -EINVAL;
-#endif
-
-	if (is_running_on_xen()) {
-		unsigned long offset = HYPERVISOR_ioremap(addr, size);
-		if (IS_ERR_VALUE(offset))
-			return offset;
-	}
-
-	if (uncached_access(file, vma->vm_pgoff << PAGE_SHIFT))
-		vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
-
-        /* Remap-pfn-range will mark the range VM_IO and VM_RESERVED */
-        if (remap_pfn_range(vma,
-                            vma->vm_start,
-                            vma->vm_pgoff,
-                            size,
-                            vma->vm_page_prot))
-                return -EAGAIN;
-        return 0;
-}
diff -r 02987ed7948a -r c94d485e18d7 include/asm-ia64/io.h
--- a/include/asm-ia64/io.h	Fri Jul 13 00:00:44 2007 +0900
+++ b/include/asm-ia64/io.h	Fri Jul 13 00:39:26 2007 +0900
@@ -129,10 +129,6 @@ extern int valid_mmap_phys_addr_range (u
 	 ((bvec_to_pseudophys((vec1)) + (vec1)->bv_len) ==		\
 	  bvec_to_pseudophys((vec2))))
 
-/* We will be supplying our own /dev/mem implementation */
-#define ARCH_HAS_DEV_MEM
-#define ARCH_HAS_DEV_MEM_MMAP_MEM
-int xen_mmap_mem(struct file * file, struct vm_area_struct * vma);
 #endif /* CONFIG_XEN */
 
 # endif /* KERNEL */
diff -r 02987ed7948a -r c94d485e18d7 include/asm-ia64/uaccess.h
--- a/include/asm-ia64/uaccess.h	Fri Jul 13 00:00:44 2007 +0900
+++ b/include/asm-ia64/uaccess.h	Fri Jul 13 00:39:26 2007 +0900
@@ -365,7 +365,6 @@ ia64_done_with_exception (struct pt_regs
 }
 
 #define ARCH_HAS_TRANSLATE_MEM_PTR	1
-#ifndef CONFIG_XEN
 static __inline__ char *
 xlate_dev_mem_ptr (unsigned long p)
 {
@@ -380,25 +379,6 @@ xlate_dev_mem_ptr (unsigned long p)
 
 	return ptr;
 }
-#else
-static __inline__ char *
-xen_xlate_dev_mem_ptr (unsigned long p, ssize_t sz)
-{
-	unsigned long pfn = p >> PAGE_SHIFT;
-
-	if (pfn_valid(pfn) && !PageUncached(pfn_to_page(pfn)))
-		return __va(p);
-
-	return ioremap(p, sz);
-}
-
-static __inline__ void
-xen_xlate_dev_mem_ptr_unmap (char* v)
-{
-	if (REGION_NUMBER(v) == RGN_UNCACHED)
-		iounmap(v);
-}
-#endif
 
 /*
  * Convert a virtual cached kernel memory pointer to an uncached pointer

[-- Attachment #4: Type: text/plain, Size: 152 bytes --]

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@lists.xensource.com
http://lists.xensource.com/xen-ia64-devel

Re: Re: [Xen-changelog] [linux-2.6.18-xen] Add "#ifdefARCH_HAS_DEV_MEM" to archtecture specific file_operations.

[Keir Fraser]

I am happy to apply these if this is the right direction for ia64. Will
someone else (e.g., Alex, Isaku) ack them if so, please?

 -- Keir

On 13/7/07 03:42, "Akio Takebe" <takebe_akio@jp.fujitsu.com> wrote:

> Xen-ia64 already don't need to modify drivers/xen/char/mem.c.
> But as you mentioned, current drivers/xen/char/mem.c has some parts
> for xen-ia64. So we may need to cleanup drivers/xen/char/mem.c.
> 
> I made a attached revert patch of xen-unstablecs12513[1]
> (same as xen-ia64 cs12544). Keir, Isaku, how about it?

Re: Re: [Xen-changelog] [linux-2.6.18-xen] Add "#ifdefARCH_HAS_DEV_MEM" to archtecture specific file_operations.

[Isaku Yamahata]

On Fri, Jul 13, 2007 at 01:54:10PM +0100, Keir Fraser wrote:
> 
> I am happy to apply these if this is the right direction for ia64. Will
> someone else (e.g., Alex, Isaku) ack them if so, please?

Fine for me.
acked-by: Isaku Yamahata <yamahata@valinux.co.jp>

-- 
yamahata

Re: Re: [Xen-changelog] [linux-2.6.18-xen] Add "#ifdefARCH_HAS_DEV_MEM" to archtecture specific file_operations.

[Keir Fraser]

On 13/7/07 15:54, "Isaku Yamahata" <yamahata@valinux.co.jp> wrote:

> On Fri, Jul 13, 2007 at 01:54:10PM +0100, Keir Fraser wrote:
>> 
>> I am happy to apply these if this is the right direction for ia64. Will
>> someone else (e.g., Alex, Isaku) ack them if so, please?
> 
> Fine for me.
> acked-by: Isaku Yamahata <yamahata@valinux.co.jp>

Okay, revert of 12513 is now applied. I assume the other patch will be
applied to the ia64 linux tree.

 -- Keir