On Wed, Jul 25, 2018, 7:48 PM Maxime Villard <m...@m00nbsd.net> wrote:
> Le 25/07/2018 à 16:09, Kamil Rytarowski a écrit :
> > On 25.07.2018 16:01, Maxime Villard wrote:
> >> Le 25/07/2018 à 15:54, Siddharth Muralee a écrit :
> >>> Hello,
> >>> While going through sys/arch/amd64/pmap.h, I came across
> >>> KERN_BASE[1] and confused it for KERNBASE[2]. Looking deeper into the
> >>> same I think someone made the same mistake in dtrace_isa.c{3](I might
> >>> be wrong).
> >>> I compared how the same variable was used in amd64[4] and
> >>> i386[5]. There seems to be a mismatch. I computed the values for
> >>> KERN_BASE and KERNBASE for amd64 and
> >>>
> >>> * KERN_BASE = 0x800000000000
> >>> * KERNBASE = 0xffffffff80000000
> >>>
> >>> I think this may be an error. However, the names are definitely a bit
> >>> confusing and there is no documentation to suggest what they are for.
> >>
> >> They are not the same. KERNBASE is the base where .text etc are located.
> >> KERN_BASE is where the kernel map begins (VM_MIN_KERNEL_ADDRESS).
> >>
> >> In fact, KERN_BASE is incorrect, there should be a VA_SIGN_NEG() around
> the
> >> multiplication. I've always known this, but I don't know if it's really
> >> harmful, so by default I've never fixed it.
> >
> > I propose to either rename or fix KERN_BASE according to VA_SIGN_NET().
> >
> > These names are confusing.
>
> The confusion likely comes from i386. On i386, VM_MIN_KERNEL_ADDRESS and
> KERNBASE are equal.
>
> The only dtrace user I see is dtrace_toxic_ranges(). I'm not sure what's
> going on down there, but I think we want to exclude all of userland. So
> the call should probably just be:
>
> (*func)(0, VM_MAX_ADDRESS)
>
> Then we remove KERN_BASE.
>
KERN_BASE is used only once in dtrace and no where else - if it indeed is
the same as VM_MIN_KERNEL_ADDRESS then we can just substitute it. I didn't
understand how VM_MAX_ADDRESS comes there.
Also why is KERNBASE > VM_MAX_KERNEL_ADDRESS in amd64 and equal to
VM_MIN_KERNEL_ADDRESS in i386(or did you mean VM_MAX_KERNEL_ADDRESS)
