Re: [PATCH 5/5] add setting gs/fsbase

[Luca]

Il 20 aprile 2023 12:46:51 UTC, Sergey Bugaev <bugaevc@gmail.com> ha scritto:
>On Thu, Apr 20, 2023 at 3:33 PM Samuel Thibault <samuel.thibault@gnu.org> 
>wrote:
>> Sergey Bugaev, le jeu. 20 avril 2023 15:27:15 +0300, a ecrit:
>> > On Thu, Apr 20, 2023 at 3:08 PM Samuel Thibault <samuel.thibault@gnu.org> 
>> > wrote:
>> > > > > See 56010b73e81e2cb1082e418699f98353598fe671 and its __mig_memcpy.
>> > > >
>> > > > Interesting; but that one's dealing with the SHARED case, isn't it?
>> > >
>> > > Yes but I guess it fixed the static case too?
>> >
>> > For the shared case, yes, lib*user will now reference
>> > __mig_memcpy from libc.so, and that one needs a simple relocation
>> > without ifunc.
>>
>> Ah, I missed the part that said that __mig_memcpy just calls the
>> (ifunc-) memcpy.
>>
>> I guess I shouldn't be replying when I don't actually have time to check
>> all ins and outs of what I'm talking about :)
>
>It's alright, I'm guilty of that too :) And also indeed I have just
>spent hours debugging this, so I have some mental model of what's
>going on (whether a correct one is another question...), but if you
>haven't looked into this for some time, you wouldn't.
>
>> > What would be a correct value then, 1 << 48?
>>
>> I don't know by heart, but something like that yes.
>
>Well that value is making gnumach crash before the task even runs :(
>
>XNU has 0x7ffffffff000, which is still larger than 0x200000000000, so
>I'm going to try that one. Though they probably mean 0x800000000000
>and have just left a single page of address space for the commpage.

There is likely some limitation in the pmap module in gnumach, IIRC it should 
statically allocate the user L3 page tables as long as the limit is below the 
first 512GB, but I never really tested it yet. Would it work for you to shrink 
temporarily the VM space, at least for testing?

Luxa