Hi Jakub,
Thanks for your message.
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.
>
Ok, this should be straightforward, see here:
https://github.com/cvparker/helenos/commit/db1c9bb259a7cee9c0bdc92ff07f89483e33542b.
It works under QEMU. Although as you said, the problem only manifests when
addresses above 4 GB are used, so might be worth double-checking that I did
the casts right.
> 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.
>
Apple was an early adopter of UEFI, so my guess is that's why the problem
showed up on their hardware first. I don't claim my solution is
particularly elegant right now, but I don't know what else can be done. I
don't know enough about SMP on the amd64 platform to know if it's
absolutely required to have that low memory available or not. I suppose the
APs have to boot in 16-bit real mode and they are limited to the first 1
MiB of memory? If it is, the other options I considered were:
1) Delay copying AP bootstrap code until later in the boot process when
better memory management is available. However, I'm not sure if this is
feasible if the kernel wants to start the APs before that.
2) Try to convince grub not to use this space. There is a relocatable tag
in multiboot2 that allows telling grub a minimum and maximum value defining
a range to load the kernel image and a preferred value, but grub wouldn't
even load the image with that tag present when I tried, and I'm not sure if
those min/max values also apply to modules. HelenOS kernel is also not
relocatable AFAIK, so it would have to choose the preferred location or it
would crash.
3) Add a dummy module that we didn't mind overwriting. But there is no
guarantee in the multiboot2 standard that grub will load the dummy module
in the lowest address just because we list it first, so if grub's behavior
changes it would cause a regression.
4) Concatenate the modules into the kernel. One could still load dummy
module files in order to get grub to send their command lines, if needed.
CP
_______________________________________________
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/listinfo/helenos-devel
