Avoid moving stack (involving SeaOS, JamesM 2.0)

[piranha]

Yeah, you need the cross compiler to build the kernel. You need the repo at code.google.com/p/seaos-os to build the cross compiler. The configure script in that one will automatically checkout the other two repos. I warn you though, the building of the cross compiler hasn't been tested very much, and it makes a fair amount of assumptions about the system (because I haven't worked on it much yet), so it may take some doing to get it to build. I think the reason for the dependency file error is that it uses the cross compiler to generate the deps files.

-JL

[Dominator]

Yeah, you need the cross compiler to build the kernel. You need the repo at code.google.com/p/seaos-os to build the cross compiler. The configure script in that one will automatically checkout the other two repos. I warn you though, the building of the cross compiler hasn't been tested very much, and it makes a fair amount of assumptions about the system (because I haven't worked on it much yet), so it may take some doing to get it to build. I think the reason for the dependency file error is that it uses the cross compiler to generate the deps files.

-JL

Yeah the configuration script requires grub instead of grub2.. Might need to tweak around that a little bit. So, can you explain the role of the "page_directory" field in virtual.c and how it works? For example, you pre-mapped the heap's tables in vm_init into the "pd" page directory, but I can't see any connection between "pd" and "page_directory". Also, how come the entries in "page_directory" are still accessible after the switch in vm_init_2? I mimiced your code, but any subsequent call to vm_map will PANIC, since page_directory[(any va)] is not present any more.

[piranha]

page_directory is set to 0xFFBFF000, which is the 1023rd entry in the 1022nd table of the page directory. In clone.c, those entries are set. Basically, that page (0xFFBFF000) is mapped to the physical address of the page directory itself - thus we can access the page directory pretty easily. It's still accessible because page_directory is just a virtual address that never changes. What that address is mapped to changes when a new page directory is loaded on a schedule() call. You say "page_directory[(any va)]". Does that mean that you're trying to pass a full address as an index to page_directory?

-JL

[Dominator]

page_directory is set to 0xFFBFF000, which is the 1023rd entry in the 1022nd table of the page directory. In clone.c, those entries are set. Basically, that page (0xFFBFF000) is mapped to the physical address of the page directory itself - thus we can access the page directory pretty easily. It's still accessible because page_directory is just a virtual address that never changes. What that address is mapped to changes when a new page directory is loaded on a schedule() call. You say "page_directory[(any va)]". Does that mean that you're trying to pass a full address as an index to page_directory?

-JL

Thanks for the reply. It seems that .vm_clone is updating entries in the “new”（or was that “dir”？） directory, which is a copy of page_directory. I assume these two directories will have different virtual addresses since the new one comes from kmalloc_ap （Please correct me if I'm wrong, because my linked list version of kmalloc returns 0xD0000000 as the address of the new directory）. I had to add a line “page_directory = c;” after the switch in init_vm_2 to get later vm_map calls to work, but that seems to break the purpose of clone. When I said （any va） I meant page table indices computed from the va. Sorry about that confusion.

Long story short: After clone and switch, c[idx] will give me the same physical address as what page_directory[idx] would have contained before the switch, but accessing page_directory[idx] will just panic now.

[piranha]

page_directory contains the virtual address that is mapped to the physical address of the current page directory. kmalloc_ap does return a virtual address, but it also returns a physical address (obtained by passing a pointer to the function). When the new directory is allocated, we have two addresses - the virtual address (around 0xD0000000) and the physical address. The virtual address 0xFFBFF000 is mapped to the physical address of the new directory. Thus accessing page_directory[0] would be the same as accessing new[0] (in vm_clone). page_directory itself (the address that that variable contains) should not be modified. Instead, the page directory should correctly reference itself so it can be accessed freely from page_directory.

-JL

[Dominator]

page_directory contains the virtual address that is mapped to the physical address of the current page directory. kmalloc_ap does return a virtual address, but it also returns a physical address (obtained by passing a pointer to the function). When the new directory is allocated, we have two addresses - the virtual address (around 0xD0000000) and the physical address. The virtual address 0xFFBFF000 is mapped to the physical address of the new directory. Thus accessing page_directory[0] would be the same as accessing new[0] (in vm_clone). page_directory itself (the address that that variable contains) should not be modified. Instead, the page directory should correctly reference itself so it can be accessed freely from page_directory.

-JL

Thanks. I might have missed somewhere in clone that established the mapping between the physical address and 0xFFBFF000. I will double check it once I get my computer.

[Dominator]

page_directory contains the virtual address that is mapped to the physical address of the current page directory. kmalloc_ap does return a virtual address, but it also returns a physical address (obtained by passing a pointer to the function). When the new directory is allocated, we have two addresses - the virtual address (around 0xD0000000) and the physical address. The virtual address 0xFFBFF000 is mapped to the physical address of the new directory. Thus accessing page_directory[0] would be the same as accessing new[0] (in vm_clone). page_directory itself (the address that that variable contains) should not be modified. Instead, the page directory should correctly reference itself so it can be accessed freely from page_directory.

-JL

Agh got that. I was having

Code: Select all

  tmp[1023] = vmm_get_physaddr((uint32_t)dir_phys | PAGE_PRESENT | PAGE_WRITE);
  dir[1022] = vmm_get_physaddr((uint32_t)tmp_phys | PAGE_PRESENT | PAGE_WRITE);

in my vm_clone, where dir_phys and tmp_phys are already physical addresses.........Stupid mistake caused by starting in higher half with paging enabled. I really need to clean this up later on.

Anyway, thanks a lot for your thorough explanation that helped me pinpoint my error. I still haven't got tasking fully working, but hopefully I can figure that out.