Mitch Bradley wrote:
quoted text
> 
> d) OFW itself lives at the top of the virtual address space, just below 
> the ROM.  (The ROM is mapped virtual=physical  for convenience)  OFW 
> uses RAM allocated from the top of physical memory, mapped at the 
> aforementioned high virtual addresses.  One page directory entry - the 
> next to last one - is used for that RAM mapping and also for mapping 
> additional miscellaneous I/O devices.  The 8MB frame buffer requires 2 
> additional PDEs, just below.  When Linux takes over the display, OFW no 
> longer needs the frame buffer mapping, but it is convenient to preserve 
> that mapping temporarily while using OFW as a debugger.
> 

So let me see here... you want the virtual address range [0xffc00000, 
0xfff00000) to be reserved for OFW, and you are prohibiting the kernel 
from using PAE?

quoted text
> e) Low memory - everything except the ~1Meg that OFW lives in - is 
> mapped virtual=physical.

Are you making this assumption when called from the kernel, too?

quoted text
> j) Linux must save the following information during early startup:
>  1) The callback function address - either from the initial value of eax 
> or from the OFW info block.
>  2) The the next-to-last page directory entry - just the pointer to the 
> page table.  The page table itself lives in OFW's reserved memory.
> 
> k) When calling back into OFW, Linux must:
>  1) Establish a page directory that contains OFW's PDE (saved in j2 
> above) and that maps the client interface argument array, including any 
> buffer pointers.
>  2) Call callback_function with the address of the argument array in 
> eax.  (Ordinary 32-bit near call).
> 
> For all of the OLPC kernel's current callbacks into OFW, the 
> requirements (j2) and (k1) are easily satisfied by "priming" 
> swapper_pg_dir with the contents of the current page directory (as 
> pointed to by the CR3 register).

I do not like it, simply because it amounts to "initialize this 
otherwise zero-initialized piece of data without making any kind of 
reservations and blindly hope nothing else overwrites it."

I'm also troubled with the assumption that the kernel doesn't use PAE. 
I realize that this is not an issue for OLPC, but it certainly makes 
this a less-than-generic solution.

Having mapped page table entries which are not under kernel control is a 
very serious problem for PAT - PAT requires, by hardware specification, 
the kernel to eliminate all potential aliases with different mappings.

One way to deal with this, of course, is to save the firmware-provided 
PGD and only use it for OFW calls.  On the other hand, perhaps a better 
questions is to what extent it is needed at all.

Furthermore, since you're using a nonstandard OFW interface (not 
compliant with the x86 OFW binding document), all of this should be 
called something like OLPC_OFW to make it clear that it's the OLPC variant.

If I had designed this, I would probably have used an SMI; since you 
have control over the firmware you can do that.  SMI saves the entire 
machine state including all the modes, cleans them all up for you, and 
puts it all back together at RSM time.  It is slow, of course, but it 
completely decouples the firmware and the OS, which is why it's used.

	-hpa

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/