Re: [PATCH 2/2] [IA64] Add phys_efi command line option

Re: [PATCH 2/2] [IA64] Add phys_efi command line option

[Horms]

Hi,

I am resending this patch, which builds on the patch sent earlier
in this thread to allow physical mode SAL/EFI to work.

-- 
Simon Horman (Horms)
  horms@verge.net.au
  http://verge.net.au/~horms/

[IA64] Add phys_efi command line option

This patch adds a command line option, phys_efi, which forces
EFI calls to stay in physical mode. This is mainly for the purpose
of being able to test the physical mode code path.

I believe that it may also be needed in order to kexec between
OS/hypervisors with different memory layouts, such as Linux->Xen and vice
versa, which have 0xe000... and 0xf000... as their page offset respecively.
However, I am still working on verifying this.

Signed-Off-By: Simon Horman <horms@verge.net.au>
 

 Documentation/kernel-parameters.txt |    4 ++++
 arch/ia64/kernel/efi.c              |    9 ++++++++-
 2 files changed, 12 insertions(+), 1 deletion(-)

Index: linux-2.6/arch/ia64/kernel/efi.c
=================================--- linux-2.6.orig/arch/ia64/kernel/efi.c	2007-02-07 11:53:10.000000000 +0900
+++ linux-2.6/arch/ia64/kernel/efi.c	2007-02-07 13:14:15.000000000 +0900
@@ -414,6 +414,7 @@
 	u64 efi_desc_size;
 	char *cp, vendor[100] = "unknown";
 	extern char saved_command_line[];
+	int phys_efi = 0;
 	int i;
 
 	/* it's too early to be able to use the standard kernel command line support... */
@@ -424,6 +425,9 @@
 			max_addr = GRANULEROUNDDOWN(memparse(cp + 9, &cp));
 		} else if (memcmp(cp, "min_addr=", 9) = 0) {
 			min_addr = GRANULEROUNDDOWN(memparse(cp + 9, &cp));
+		} else if (memcmp(cp, "phys_efi", 8) = 0) {
+			phys_efi = 1;
+			cp+=8;
 		} else {
 			while (*cp != ' ' && *cp)
 				++cp;
@@ -528,7 +532,10 @@
 #endif
 
 	efi_map_pal_code();
-	efi_enter_virtual_mode();
+	if (phys_efi)
+		printk("Forcing EFI to stay in physical mode\n");
+	else
+		efi_enter_virtual_mode();
 }
 
 void
Index: linux-2.6/Documentation/kernel-parameters.txt
=================================--- linux-2.6.orig/Documentation/kernel-parameters.txt	2007-02-07 11:52:41.000000000 +0900
+++ linux-2.6/Documentation/kernel-parameters.txt	2007-02-07 11:53:11.000000000 +0900
@@ -1276,6 +1276,10 @@
 	pg.		[PARIDE]
 			See Documentation/paride.txt.
 
+	phys_efi	[IA-64] Force EFI, PAL and SAL calls to be made
+			in physical mode. Otherwise, if possible virtual mode
+			calls are made.
+
 	pirq=		[SMP,APIC] Manual mp-table setup
 			See Documentation/i386/IO-APIC.txt.
 

Re: [PATCH 2/2] [IA64] Add phys_efi command line option

[Jay Lan]

Horms wrote:
> Hi,
> 
> I am resending this patch, which builds on the patch sent earlier
> in this thread to allow physical mode SAL/EFI to work.
> 

Hi Horms,

Do you plan to introduce this new option as a default to kexec in non-
Linux<->Xen kexec situations? We are concerned because physical mode
SAL/EFI calls do not currently work on SN platform.

Thanks,
 - jay

Re: [PATCH 2/2] [IA64] Add phys_efi command line option

[Horms]

On Thu, Feb 08, 2007 at 01:48:56PM -0800, Jay Lan wrote:
> Horms wrote:
> > Hi,
> > 
> > I am resending this patch, which builds on the patch sent earlier
> > in this thread to allow physical mode SAL/EFI to work.
> > 
> 
> Hi Horms,
> 
> Do you plan to introduce this new option as a default to kexec in non-
> Linux<->Xen kexec situations? We are concerned because physical mode
> SAL/EFI calls do not currently work on SN platform.

So far the only way that I know to make Linux<->Xen and Xen<->Linux
Linux kexec/kdump transitions work is to use this phys_efi technique.
I realise that it doesn't work on SN. But it does seem to me that
a solution that works on some platforms (e.g. Tiger) is better than
no solution at all.

I'm not planing to have kexec set this flag under you nose or anything
like that. But rather to allow people (who's platform's support it) to
use it. 

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/

Re: [PATCH 2/2] [IA64] Add phys_efi command line option

[Jack Steiner]

On Fri, Feb 09, 2007 at 09:41:37AM +0900, Horms wrote:
> On Thu, Feb 08, 2007 at 01:48:56PM -0800, Jay Lan wrote:
> > Horms wrote:
> > > Hi,
> > > 
> > > I am resending this patch, which builds on the patch sent earlier
> > > in this thread to allow physical mode SAL/EFI to work.
> > > 
> > 
> > Hi Horms,
> > 
> > Do you plan to introduce this new option as a default to kexec in non-
> > Linux<->Xen kexec situations? We are concerned because physical mode
> > SAL/EFI calls do not currently work on SN platform.
> 
> So far the only way that I know to make Linux<->Xen and Xen<->Linux
> Linux kexec/kdump transitions work is to use this phys_efi technique.
> I realise that it doesn't work on SN. But it does seem to me that
> a solution that works on some platforms (e.g. Tiger) is better than
> no solution at all.

At some point in time, we may want to support XEN on our platform.
Will we need to support phys_efi to make that work? 

If I understand your comment, phys_efi will never be required to
kexec a kdump kernel from linux. Right??



-- jack

Re: [PATCH 2/2] [IA64] Add phys_efi command line option

[Horms]

On Thu, Feb 08, 2007 at 08:16:04PM -0600, Jack Steiner wrote:
> On Fri, Feb 09, 2007 at 09:41:37AM +0900, Horms wrote:
> > On Thu, Feb 08, 2007 at 01:48:56PM -0800, Jay Lan wrote:
> > > Horms wrote:
> > > > Hi,
> > > > 
> > > > I am resending this patch, which builds on the patch sent earlier
> > > > in this thread to allow physical mode SAL/EFI to work.
> > > > 
> > > 
> > > Hi Horms,
> > > 
> > > Do you plan to introduce this new option as a default to kexec in non-
> > > Linux<->Xen kexec situations? We are concerned because physical mode
> > > SAL/EFI calls do not currently work on SN platform.
> > 
> > So far the only way that I know to make Linux<->Xen and Xen<->Linux
> > Linux kexec/kdump transitions work is to use this phys_efi technique.
> > I realise that it doesn't work on SN. But it does seem to me that
> > a solution that works on some platforms (e.g. Tiger) is better than
> > no solution at all.

Before I start, I'd like to note that currently the kernel tries to fall
back to phys_efi if it can't map the efi table, and that the phys_efi
code path is broken. The first patch I posted fixes that problem (though
probably not on SN). This second patch merely allows the user to force
that behaviour.

> At some point in time, we may want to support XEN on our platform.
> Will we need to support phys_efi to make that work? 
> 
> If I understand your comment, phys_efi will never be required to
> kexec a kdump kernel from linux. Right??

phys_efi is not required for:
  * Xen to run on ia64
  * Kexec from Linux -> Linux
  * Kexec from Xen -> Xen

What phys_efi is required - or to be more precice, the best (only)
solution thus far - for is:
  * Kexec from Y -> Z where Y.PAGE_OFFSET != Z.PAGE_OFFSET
    This includes:
    - Kexec from Linux -> Xen
    - Kexec from Xen -> Linux
    - Kdump from Xen (-> Linux, Kdump -> Xen makes little sense to me)

The reason for this is that when EFI goes into virtual mode,
the addresses set up are dependant on PAGE_OFFSET. So clearly
if PAGE_OFFSET changes (because we kexec) the EFI mappins also
need to be changed. But the EFI specification states that the
mapping can only be made at most once. So the idea of phys_efi is
to do this zero times, and take PAGE_OFFSET out of the picture with
respect to EFI.

Another possible plan is to somehow virtualise efi, and it
can use some predetermined PAGE_OFFSET internally. But I think
its safe to say that the phys_efi approach is simpler, though
with the catch that it doesn't work on all platforms.

-- 
Horms
  H: http://www.vergenet.net/~horms/
  W: http://www.valinux.co.jp/en/