Re: [patch 3/5] Dont map PAL memory if physicall calls are going to be made

From: Horms <horms_at_verge.net.au>
Date: 2006-12-13 13:00:40
On Tue, Oct 24, 2006 at 02:47:38PM -0500, Jack Steiner wrote:
> On Mon, Oct 23, 2006 at 05:48:43PM +0900, Horms wrote:
> > There seems to be no reason to map the PAL code into memory if
> > physical calls are going to be made.
> 
> 
> If you don't map PAL, I assume that all PAL calls are going to be made in
> physical addressing mode. However, I don't see any code that actually forces
> PAL calls to be made in physical addressing mode. Is that your intent? 
> Don't you also need to save the PAL start address as a physical address.
> See the call to ia64_pal_handler_init().

Thanks. On furtuther investigation I think that this patch is bogus.
I will remove it from the series.

> In addition, it looks like slave cpus still call efi_map_pal_code()
> to map PAL - see start_secondary().

Just for the record, that itself is easy enough to get around by
checking for efi.mapped in efi_map_pal_code() or start_secondary().

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

-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Received on Wed Dec 13 13:18:44 2006

This archive was generated by hypermail 2.1.8 : 2006-12-13 13:19:55 EST