[patch 0/5] Physical mode SAL calls

[patch 0/5] Physical mode SAL calls

[Horms]

Hi,

I am reposting this series of patches, as some of the posts that made up
the original series seem to have never made the list.

Currently the EFI code will fallback to physical mode if it
can't map itself into virtual memory. However, if this occurs
SAL calls fail, because the kernel runs them in virtual mode regardless.
This fails because sometimes the PAL calls actually call EFI code
internally, expecting it to be maped into a virtial area of memory,
which it isn't.

This series of patches also addes a kernel command line option
to force EFI (and SAL) to stay in physical mode. This is primarily
for testing that physical mode calls work with this patchset.

But I believe that physical mode EFI calls will be needed
to successfully kexec between kernels (or hypervisors) that
have a different PAGE_OFFSET (e.g. linux and xen), as
the EFI code can only be mapped zero or one times. That is,
if linux maps it, xen won't be able to run, and vice versa.
But by staying with physical mode calls the problem goes away.

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

Re: [patch 0/5] Physical mode SAL calls

[Jack Steiner]

SN systems support additional vendor-specific SAL calls. Some
of these pass kernel addresses to SAL for input or output buffers.
At a minimum, these buffer addresses need to be converted to 
physical addresses if SAL is run in physical mode.

In addition, I think there may be additional problems with our SAL
if we try to run only in physical mode. I'll take a look.....


-- jack

Re: [patch 0/5] Physical mode SAL calls

[Horms]

On Mon, Oct 23, 2006 at 10:15:58AM -0500, Jack Steiner wrote:
> SN systems support additional vendor-specific SAL calls. Some
> of these pass kernel addresses to SAL for input or output buffers.
> At a minimum, these buffer addresses need to be converted to 
> physical addresses if SAL is run in physical mode.
> 
> In addition, I think there may be additional problems with our SAL
> if we try to run only in physical mode. I'll take a look.....

Thanks. These patches do seem to work fairly well on my Tiger 2.
But its obviously a fairly tricky area.

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

Re: [patch 0/5] Physical mode SAL calls

[Horms]

On Mon, Oct 23, 2006 at 10:15:58AM -0500, Jack Steiner wrote:
> SN systems support additional vendor-specific SAL calls. Some
> of these pass kernel addresses to SAL for input or output buffers.
> At a minimum, these buffer addresses need to be converted to 
> physical addresses if SAL is run in physical mode.

That is sounds quite problematic in terms of not mapping EFI.

Appart from fixing up broken code paths, the main motivation for this
patch is to allow kexecing between different operating systems (e.g.
from xen to linux and vice versa) which have different base addresses.
In a nutshell, get arround the fact that you can't remap EFI on the
second boot by never mapping it at all.

Do you think it is at all possible for this kind of approach to work on
SN systems? If not, the next best idea that I have is to somehow
virtualise the EFI, and have all kexeable systems (linux, xen, ...)
agree to use that. But that idea is farily complex, and I'm not
even sure it can work.

> In addition, I think there may be additional problems with our SAL
> if we try to run only in physical mode. I'll take a look.....

Thanks

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