Re: Resolved: Unexpected page fault from 0xdc003 ad address 0x??

[Bas Wijnen]

Marcus Brinkmann wrote:
> At Thu, 26 Aug 2004 11:13:12 +0200,
> Bas Wijnen <address@hidden> wrote:
>
> > I have the feeling it has to do with the code size.  When I try to start a
> > task server which only does puts ("task is running");, it works fine.
>
>
> I can reproduce this now.  The issue was easily found: physmem's
> container map function doesn't take into account the destination
> virtual address.

Ah, that makes sense.  I checked the page tables myself, but didn't do 
careful checking to see if there were holes in the list.

> The only problem is that this leads to potentially a very large list
> of fpages spanning a certain map operation (consider mapping the
> region 0x0000-0x8000 to 0x1000-0x9000, and similar for much larger
> regions).  So, we might have to abort the operation at some point if
> we run out of space for map items in the message, and return a partial
> result (always allowed).  But then the startup code must keep
> requesting partial mappings until it got all of them.  (The cheap way
> out would be to acknowledge that we only support 4KB pages on ia32
> [ignoring 4MB pages for now], and map each page individually).

Isn't it better to just skip parts of physmem's address space, to make 
sure the alignment of the served page is equal in both address spaces? 
If 0x8000 bytes are requested at address 0x1000, it will have to be cut 
into 1, 2, 4, 1 pages.  So if physmem's first free page is at 0xb000,
it should serve 0xb000-0xc000, 0xc000-0xe000, 0x10000-0x14000, and 
0xe000-0xf000 (or 0x14000-0x15000, whatever makes more sense for the 
implementation.)  The code in physmem/zalloc.c looked like it would do 
exactly that.

> For now, however, we only map very small chunks, so it will fit into a
> single message.  I will add the necessary code to physmem.  The
> startup code can wait.

Ok.

Thanks,
Bas

signature.asc
Description: OpenPGP digital signature