Hi Colin, thanks for your mail, please see my comments below.
On 1/29/23 03:51, Colin Parker wrote: > 1) I have had problems with paging on amd64. In the definition of pte_e > in kernel/arch/amd64/include/arch/mm/page.h, there are these lines: > > unsigned int addr_12_31 : 30; > unsigned int addr_32_51 : 21; > > I don't know why it shouldn't be this: > > unsigned int addr_12_31 : 20; > unsigned int addr_32_62 : 31; Yes, both of these seem wrong, the first one is probably the more serious one. It's also a very good catch! This went unnoticed for so long because in order for it to manifest one actually needs more than 4G of physical memory, right? At the same time, it is not clear to me why we bothered to split the physical address here and didn't do just something like: - unsigned int addr_12_31 : 30; - unsigned int addr_32_51 : 21; + unsigned long addr_12_51 : 40; + unsigned int reserved : 11; This would simplify the surrounding macros too and let the compiler do the bit operations for us. Also note that the physical address should be limited to the architectural maximum of 52 bits, so we should probably keep the reserved bits separate. > 2) When booting SMP, HelenOS reserves physical address range > 0x8000-0x14000 for the AP bootstrap code. I suppose under BIOS, grub > behaves differently, but under UEFI that address range is considered > open space by grub in which the modules can be loaded. So, ns module > gets placed at address 0x1000, then the kernel copies AP bootstrap code > over the top of part of it. As soon as ns makes a function call into the > address range that was overwritten, it will give some confusing error > (page fault, invalid instruction, etc.) So I wrote a quick fix to search > for conflicts in the init task modules and the AP bootstrap area, and > copy them to a safe region. Unfortunately that all has to be done at an > early stage before the AP bootstrap code is copied, so there's limited > memory mapping/allocation available. My method for searching for a place > to move the module ended up getting kind of messy [2], but it did get > the system to boot (with the proviso above about USB). Interesting. I think when this code was first written there were no UEFI systems around. I'll need to think about this one a little longer. Cheers, Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/listinfo/helenos-devel
