Erläuterung erforderlich unter \ Device \ PhysicalMemory unter Windows

Question

\Device\PhysicalMemory ist ein Abschnitt Objekt, das in Win32-API-Bedingungen eine Speicherabbilddatei ist. Angesichts seines Namens könnte es ein MMF vollständig RAM unterstützt werden; Eins-zu-Eins-Mapping von physikalischen Seiten.

Und das ist so ziemlich meine Frage: ist dieser Abschnitt Objekt repräsentiert physische Speicher oder den nicht ausgelagerten Systemadressraum nicht ausgelagerten?

Und wenn es ersteres ist, was ist mit "Löchern" im physischen Speicher? Zum Beispiel auf PAE-fähigen Systemen kann der physikalische Speicher, der dem Systemadressraum zugrunde liegt, tatsächlich "fragmentiert" sein. Was passiert, wenn ich nach dem Zuordnen einer Ansicht in dieses \Device\PhysicalMemory Sektionsobjekt auf solche Löcher zugreifen würde?

Der Grund, warum ich verwirrt bin, ist, weil die MmMapIoSpace-Funktion einen PHYSICAL_ADDRESS PhysicalAddress-Parameter übernimmt und diese physische Adresse dem nicht ausgelagerten Systemadressraum zuordnet. Siehe auch andere Speichermanagerfunktionen wie MmAllocateContiguousMemory. Es scheint ziemlich gefährlich, tatsächlichen physischen Speicher zur Verfügung zu stellen und so zu tun, es kann in zusammenhängender Weise zugegriffen werden.

So eindeutig gibt es eine Zuordnung, die nicht unbedingt eins zu eins zwischen nicht ausgelagerten physischen Speicher und nicht ausgelagerten Systemadressraum ist.

Der Versuch, die oben genannten und eine Reihe von verwandten Begriffen in Windows Internals, 6. Ausgabe zu finden. gab keine definitive Antwort. Kapitel 10 befasst sich hauptsächlich mit dem, was die WDK-Dokumentation Systemadressraum nennt. Deshalb frage ich hier.

Stellen Sie sicher, dass Sie auf autoritative Quellen für Ihre Antwort verweisen.

Answer 1

\Device\PhysicalMemory ist ein Sektionsobjekt, das direkt vom physischen Speicher unterstützt wird. Sein Ansichtsversatz repräsentiert tatsächliche physikalische Adressen. Als solches ist es nicht zusammenhängend und um es zu benutzen, müssen Sie wissen, welche Bereiche gültig sind.

Es gibt wenig autoritative Informationen zur Verwendung von \ Device \ PhysicalMemory, da Microsoft davon ausgeht, dass dies nicht erforderlich ist. In der Tat haben sie die Verwendung dieses Abschnitts so schwierig wie möglich gemacht, ohne sie vollständig in Windows XP/2003 zu entfernen.

So weit wie MmMapIoSpace: Gerätetreiber, die zugeordneten Speicher benötigen, fordern sie während der PnP-Initialisierung über Ressourcen an. Windows weist Seitenbereiche des physischen Arbeitsspeichers zur ausschließlichen Verwendung durch Gerätetreiber zu und gibt CmResourceTypeMemory-Ressourcen zurück, um den zugewiesenen Arbeitsspeicher zu beschreiben. Der Gerätetreiber verwendet dann MmMapIoSpace zum Abrufen einer barrierefreien Adresse im Kernelmodus. Der Treiber gibt niemals eine zufällige Adresse für die Zuordnung aus. Dies wird in der MmMapIoSpace MSDN docs und anderen Seiten von dieser Seite beschrieben beschrieben.

Beachten Sie, dass Sie bei Verwendung dieses Abschnitts oder MmMapIoSpace darauf achten müssen, dass jeder zugeordnete Speicher die gleiche Caching-Semantik wie andere Zuordnungen für dieselbe physische Adresse verwendet. Wenn keine Beschädigung auftreten könnte, ist dies besonders wichtig, wenn Daten mit dem Mapping geschrieben werden. Dies ist normalerweise kein Problem für MmMapIoSpace, wenn es wie von Microsoft beabsichtigt verwendet wird, da der Eigentümergerätetreiber wissen sollte, wie mit konsistentem Caching gemappt wird. Wenn Sie den Abschnitt verwenden, haben Sie keine Möglichkeit zu wissen, ob der Speicher durch einen anderen Code inkompatibel zugeordnet wurde.

Der Treiberüberprüfer zeigt an, dass bei Verwendung des Abschnitts oder MmMapIoSpace keine konsistente Zuordnung verwendet wurde, und melden sie als Fehler des fehlerhaften Zuordners.In Windows 10 tritt diese Art von Bericht auch ohne Treiberüberprüfung auf, was es sehr schwierig macht, eine der beiden Methoden zu verwenden, ohne einen OS-Stopp zu verursachen.

Sie geben nicht an, was Sie zu tun versuchen, aber ich vermute, dass Sie möglicherweise daran interessiert sind, MmCopyMemory mit der MM_COPY_MEMORY_PHYSICAL zu betrachten - siehe MmCopyMemory MSDN docs.