Christ! Don't zero out the shared memory page during Virtual Memory initialization! The page is already well in-use by the time we were zeroing it out, and this is also the reason why all the attempts to move MmInit1 into MmInitSystem had previously failed -- the NtSystemRoot path would get written during initialization (But before MmInitSystem), and MmInit1 would then zero out the entire structure.

Not only does this allow us to do MmInit1 in MmInitSystem, where it should be, but it also fixes the fact that several KUSER_SHARED_DATA flags were being zeroed out.
As an added benefit, ARM/PPC ports now need to worry about Mm much later then before (well after the HAL has initialized and interrupts are enabled).


svn path=/trunk/; revision=32373

reactos/ntoskrnl/ke/i386/kiinit.c

@@ -536,9 +536,6 @@ KiInitializeKernel(IN PKPROCESS InitProcess,
     /* HACK for MmUpdatePageDir */
     ((PETHREAD)InitThread)->ThreadsProcess = (PEPROCESS)InitProcess;
 
-    /* Initialize Kernel Memory Address Space */
-    MmInit1();
-
     /* Set basic CPU Features that user mode can read */
     SharedUserData->ProcessorFeatures[PF_MMX_INSTRUCTIONS_AVAILABLE] =
         (KeFeatureBits & KF_MMX) ? TRUE: FALSE;

reactos/ntoskrnl/mm/mminit.c

@@ -182,7 +182,6 @@ MmInitVirtualMemory()
                       0,
                       BoundaryAddressMultiple);
    MmSharedDataPagePhysicalAddress.QuadPart = 2 << PAGE_SHIFT;
-   RtlZeroMemory(BaseAddress, Length);
 
    /*
     *
@@ -420,6 +419,9 @@ MmInitSystem(IN ULONG Phase,
     ULONG Flags = 0;
     if (Phase == 0)
     {
+        /* Initialize Mm bootstrap */
+        MmInit1();
+
         /* Initialize the Loader Lock */
         KeInitializeMutant(&MmSystemLoadLock, FALSE);