Re: CVS commit: src/sys/arch/xen/x86

[Cherry G. Mathew <cherry%zyx.in@localhost>]

>>>>> "Maxime" == Maxime Villard <max%m00nbsd.net@localhost> writes:

    Maxime> Le 08/08/2016 à 04:27, Cherry G. Mathew a écrit :
    >> On 2 August 2016 at 19:51, Maxime Villard <maxv%netbsd.org@localhost <mailto:maxv%netbsd.org@localhost>> wrote:
    >> 
    >> Module Name: src Committed By: maxv Date: Tue Aug 2 14:21:53 UTC
    >> 2016
    >> 
    >> Modified Files: src/sys/arch/xen/x86: x86_xpmap.c
    >> 
    >> Log Message: Map the kernel text, rodata and data+bss
    >> independently on Xen, with respectively RX, R and RW.
    >> 
    >> 
    >> 
    >> Hi - wondering why you're getting more divergence from generic
    >> x86 -

    Maxime> We are not getting more divergence.

    >> is there a way to do this (and the pg_nx stuff for eg:) without
    >> having to special case this in Xen ?

    Maxime> Not really. On a normal x86, when the kernel starts, the CPU
    Maxime> does not yet have 64bit registers, paging, WP, NX, MSRs,
    Maxime> etc. The kernel itself enables them, and to do so, it uses
    Maxime> temporary variables and a temporary page tree before
    Maxime> relocating itself at KERNBASE. All this needs to be done in
    Maxime> assembly.

    Maxime> On Xen, however, when the kernel starts, the CPU already has
    Maxime> 64bit registers, paging etc, so the only thing the kernel
    Maxime> has to do is creating its own page table, and for that
    Maxime> purpose it also uses temporary variables, such as pg_nx.
    Maxime> This time, it all can be done in C.

    Maxime> This initialization process is referred to as the locore,
    Maxime> and even if machdep and pmap can be shared between
    Maxime> amd64<->i386<->PAE<->Xen, the locore cannot. When it comes
    Maxime> to pg_nx, we cannot use pmap_pg_nx, since it is part of the
    Maxime> pmap, which is shared and initialized later. For that same
    Maxime> reason, we use nox_flag in assembly in the amd64 and i386
    Maxime> locores.

Sorry for the delay in responding - thanks for the detailed response - I
am familiar with this area of the codebase - I was only concerned at
code replication - I see your point about being unable to avoid this at
early boot though.

I am working on some code that may intersect with this area of code -
will get back to you more then.... 

Thanks again.
-- 
~cherry