[Linux-ia64] settings AR.k0 to ia64_iobase is wrong?

[Linux-ia64] settings AR.k0 to ia64_iobase is wrong?

[nomura]

Hello,

2.4.7 has problem in booting due to ar.k0 rewrite.
Here is my proposal to fix it.

It seems that new ar.k0 initialization in 2.4.7 changes ar.k0 value
set by SAL and results in access to illegal address by SAL.
Since ar.k0 is already set up properly by SAL for their use, 
shouldn't we change it in setup_arch()?

To be more precise, on our platform, SAL sets ar.k0 to 0x80000ffffc000000
for uncached access to 0xffffc000000. Linux changes it to 0xffffc000000
not taking SAL address mapping into consideration.

Attached patch changes setup_arch() to keep ar.k0 value to SAL setting.
I confirmed the patch working both with Intel SAL and our platform's SAL.

--
NOMURA, Jun'ichi <j-nomura@ce.jp.nec.com, nomura@hpc.bs1.fc.nec.co.jp>
HPC Operating System Group, 1st Computers Software Division,
Computers Software Operations Unit, NEC Solutions.


Index: arch/ia64/kernel/setup.c
=================================RCS file: /home/cvsadm/cvsroot/linux/arch/ia64/kernel/setup.c,v
retrieving revision 1.1.1.7.6.2
diff -u -r1.1.1.7.6.2 setup.c
--- arch/ia64/kernel/setup.c	2001/07/27 09:30:29	1.1.1.7.6.2
+++ arch/ia64/kernel/setup.c	2001/07/31 05:15:09
@@ -314,10 +314,9 @@
 	 *  AR.KR0 if no appropriate entry is found in the memory map.
 	 */
 	ia64_iobase = efi_get_iobase();
-	if (ia64_iobase)
-		/* set AR.KR0 since this is all we use it for anyway */
-		ia64_set_kr(IA64_KR_IO_BASE, ia64_iobase);
-	else {
+	if (ia64_iobase) {
+		/* do nothing */
+	} else {
 		ia64_iobase = ia64_get_kr(IA64_KR_IO_BASE);
 		printk("No I/O port range found in EFI memory map, falling back to AR.KR0\n");
 		printk("I/O port base = 0x%lx\n", ia64_iobase);

Re: [Linux-ia64] settings AR.k0 to ia64_iobase is wrong?

[David Mosberger]

>>>>> On Tue, 31 Jul 2001 15:36:18 +0900, nomura@hpc.bs1.fc.nec.co.jp said:

  Nomura> To be more precise, on our platform, SAL sets ar.k0 to
  Nomura> 0x80000ffffc000000 for uncached access to
  Nomura> 0xffffc000000.

This isn't right.  There is no way a VA->PA translation can set bit 63
so address 0x80000ffffc000000 could only be generated in physical
mode, which Linux (almost) never uses.  The address 0xffffc000000 is
correct since Linux will access the memory range only through uncached
space (region 6).

	--david

Re: [Linux-ia64] settings AR.k0 to ia64_iobase is wrong?

[nomura]

> This isn't right.  There is no way a VA->PA translation can set bit 63
> so address 0x80000ffffc000000 could only be generated in physical
> mode, which Linux (almost) never uses.  The address 0xffffc000000 is
> correct since Linux will access the memory range only through uncached
> space (region 6).

I didn't talk about VA-PA translation nor I/O memory range access by linux.
'mapping' was the wrong word, I'm afraid.

I mean ar.k0 seems to be used by SAL in physical mode and setting ar.k0 to
cached attribute is problematic.
I think setting bit63 to 1 (i.e. physical mode uncached) is better and safer
solution than just putting cached attribute physical address in ar.k0, unless
anyone or any part of code suffers from the bit.

Here is the updated patch which does not remove ia64_set_kr but set
uncached attribute bit on ia64_iobase in efi_get_iobase().
How about it?

--
NOMURA, Jun'ichi <j-nomura@ce.jp.nec.com, nomura@hpc.bs1.fc.nec.co.jp>
HPC Operating System Group, 1st Computers Software Division,
Computers Software Operations Unit, NEC Solutions.


Index: arch/ia64/kernel/efi.c
=================================RCS file: /home/cvsadm/cvsroot/linux/arch/ia64/kernel/efi.c,v
retrieving revision 1.1.1.7.6.1
diff -u -r1.1.1.7.6.1 efi.c
--- arch/ia64/kernel/efi.c	2001/07/27 06:54:28	1.1.1.7.6.1
+++ arch/ia64/kernel/efi.c	2001/07/31 07:37:49
@@ -473,7 +473,7 @@
 		if (md->type = EFI_MEMORY_MAPPED_IO_PORT_SPACE) {
 			/* paranoia attribute checking */
 			if (md->attribute = (EFI_MEMORY_UC | EFI_MEMORY_RUNTIME))
-				return md->phys_addr;
+				return (1UL<<63) | md->phys_addr; /* Bit63=1: Uncached */
 		}
 	}
 	return 0;

Re: [Linux-ia64] settings AR.k0 to ia64_iobase is wrong?

[David Mosberger]

>>>>> On Tue, 31 Jul 2001 19:06:28 +0900, nomura@hpc.bs1.fc.nec.co.jp said:

  >> This isn't right.  There is no way a VA->PA translation can set
  >> bit 63 so address 0x80000ffffc000000 could only be generated in
  >> physical mode, which Linux (almost) never uses.  The address
  >> 0xffffc000000 is correct since Linux will access the memory range
  >> only through uncached space (region 6).

  Nomura> I didn't talk about VA-PA translation nor I/O memory range
  Nomura> access by linux.  'mapping' was the wrong word, I'm afraid.

What I'm saying is that an address with bit 63 set is not a proper
physical address (it's nothing that will ever show up on the physical
address bus) and therefore cannot be addressed using virtual
addressing.  Thus, such an address is useless for Linux.

  Nomura> I mean ar.k0 seems to be used by SAL in physical mode and
  Nomura> setting ar.k0 to cached attribute is problematic.

I don't know about SAL internals, but if SAL uses it in physical mode,
it needs to make sure that it's accessing it in uncached mode.  This
seems to work just fine on all existing Intel and HP systems so it
certainly seems possible.

  Nomura> I think setting bit63 to 1 (i.e. physical mode uncached) is
  Nomura> better and safer solution than just putting cached attribute
  Nomura> physical address in ar.k0, unless anyone or any part of code
  Nomura> suffers from the bit.

No, setting bit 63 is not a solution.  k0 must contain the physical
base address of the legacy I/O space, no more, no less.

	--david

RE: [Linux-ia64] settings AR.k0 to ia64_iobase is wrong?

[Dong Wei]

AR.k0 contains the virtual address that SAL uses for the IO Port Base.
The SAL spec asks the OSes not to change this value until the IVAs are
taken over. The reason for this is that some implementation of SAL
contains the x86 BIOS code.

The AR.k0 value reported by SAL is of no use to the OSes because it is a
virtual address used by SAL only, not by the OSes. OSes get the physical
IO Port Base from the EFI GetMemoryMap call. 

After the OS gets the physical IO Port base, it should apply the OS
PA-VA mapping.

Regards,

Dong Wei
Systems Architecture
Hewlett Packard
dong_wei@hp.com
(916)748-2461 

> -----Original Message-----
> From: linux-ia64-admin@linuxia64.org 
> [mailto:linux-ia64-admin@linuxia64.org] On Behalf Of David Mosberger
> Sent: Tuesday, July 31, 2001 11:06 AM
> To: nomura@hpc.bs1.fc.nec.co.jp
> Cc: linux-ia64@linuxia64.org
> Subject: Re: [Linux-ia64] settings AR.k0 to ia64_iobase is wrong?
> 
> 
> >>>>> On Tue, 31 Jul 2001 19:06:28 +0900, 
> nomura@hpc.bs1.fc.nec.co.jp said:
> 
>   >> This isn't right.  There is no way a VA->PA translation can set
>   >> bit 63 so address 0x80000ffffc000000 could only be generated in
>   >> physical mode, which Linux (almost) never uses.  The address
>   >> 0xffffc000000 is correct since Linux will access the memory range
>   >> only through uncached space (region 6).
> 
>   Nomura> I didn't talk about VA-PA translation nor I/O memory range
>   Nomura> access by linux.  'mapping' was the wrong word, I'm afraid.
> 
> What I'm saying is that an address with bit 63 set is not a proper
> physical address (it's nothing that will ever show up on the physical
> address bus) and therefore cannot be addressed using virtual
> addressing.  Thus, such an address is useless for Linux.
> 
>   Nomura> I mean ar.k0 seems to be used by SAL in physical mode and
>   Nomura> setting ar.k0 to cached attribute is problematic.
> 
> I don't know about SAL internals, but if SAL uses it in physical mode,
> it needs to make sure that it's accessing it in uncached mode.  This
> seems to work just fine on all existing Intel and HP systems so it
> certainly seems possible.
> 
>   Nomura> I think setting bit63 to 1 (i.e. physical mode uncached) is
>   Nomura> better and safer solution than just putting cached attribute
>   Nomura> physical address in ar.k0, unless anyone or any part of code
>   Nomura> suffers from the bit.
> 
> No, setting bit 63 is not a solution.  k0 must contain the physical
> base address of the legacy I/O space, no more, no less.
> 
> 	--david
> 
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64
> 

RE: [Linux-ia64] settings AR.k0 to ia64_iobase is wrong?

[David Mosberger]

>>>>> On Tue, 31 Jul 2001 11:57:09 -0700, "Dong Wei" <dong_wei@hp.com> said:

  Dong> AR.k0 contains the virtual address that SAL uses for the IO
  Dong> Port Base.  The SAL spec asks the OSes not to change this
  Dong> value until the IVAs are taken over. The reason for this is
  Dong> that some implementation of SAL contains the x86 BIOS code.

Yup.  We don't violate this assumption as we switch the IVA long
before we touch AR.k0.

	--david

RE: [Linux-ia64] settings AR.k0 to ia64_iobase is wrong?

[Mallick, Asit K]

David,

The setup code is not setting the virtual address in the ar.k0. Here is a
patch to set the virtual address.

Thanks,
Asit

--- linux-2.4.7/arch/ia64/kernel/setup.c        Tue Jul 31 14:57:10 2001
+++ linux/arch/ia64/kernel/setup.c      Wed Aug  1 14:26:44 2001
@@ -314,15 +314,15 @@
         *  AR.KR0 if no appropriate entry is found in the memory map.
         */
        ia64_iobase = efi_get_iobase();
-       if (ia64_iobase)
-               /* set AR.KR0 since this is all we use it for anyway */
-               ia64_set_kr(IA64_KR_IO_BASE, ia64_iobase);
-       else {
+       if (!ia64_iobase) {
                ia64_iobase = ia64_get_kr(IA64_KR_IO_BASE);
                printk("No I/O port range found in EFI memory map, falling
back to AR.KR0\n");
                printk("I/O port base = 0x%lx\n", ia64_iobase);
        }
        ia64_iobase = __IA64_UNCACHED_OFFSET | (ia64_iobase & ~PAGE_OFFSET);
+
+       /* set AR.KR0 since this is all we use it for anyway */
+       ia64_set_kr(IA64_KR_IO_BASE, ia64_iobase);
 
 #ifdef CONFIG_SMP
        cpu_physical_id(0) = hard_smp_processor_id();


> -----Original Message-----
> From: David Mosberger [mailto:davidm@hpl.hp.com]
> Sent: Tuesday, July 31, 2001 12:23 PM
> To: dong@rose.hp.com
> Cc: nomura@hpc.bs1.fc.nec.co.jp; linux-ia64@linuxia64.org;
> mani.ayyar@intel.com
> Subject: RE: [Linux-ia64] settings AR.k0 to ia64_iobase is wrong?
> 
> 
> >>>>> On Tue, 31 Jul 2001 11:57:09 -0700, "Dong Wei" 
> <dong_wei@hp.com> said:
> 
>   Dong> AR.k0 contains the virtual address that SAL uses for the IO
>   Dong> Port Base.  The SAL spec asks the OSes not to change this
>   Dong> value until the IVAs are taken over. The reason for this is
>   Dong> that some implementation of SAL contains the x86 BIOS code.
> 
> Yup.  We don't violate this assumption as we switch the IVA long
> before we touch AR.k0.
> 
> 	--david
> 
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64
>