settings AR.k0 to ia64_iobase is wrong?

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 <[email protected], [email protected]> 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
@@ -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);

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

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 <[email protected], [email protected]> 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
@@ -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;

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

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
[email protected]
(916)748-2461

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

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

@@ -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();