Gibt es dahinter eine logische Entscheidungsfindung, die nach meinem Verständnis nur die gleichen Informationen wie die CPUID-Anweisung von x86 enthält, also warum wird sie nur EL1 zugänglich gemacht? Ist das in irgendeiner Weise sicherer oder ist es vielleicht nur "über Sicherheit"?
Es soll die Abstraktion von Aufgaben auf Benutzerberechtigungsebene von der Hardware unterstützen, auf der sie ausgeführt werden.
Ein Betriebssystem kann auf einer höheren Berechtigungsebene ausgeführt werden und auf die Cache-Größendaten zusammen mit anderen Daten über die Hardware zugreifen, auf der es ausgeführt wird. Es liegt in der Verantwortung eines solchen Betriebssystems, sich mit der Hardware zu befassen und sie von den Programmen auf Benutzerebene zu abstrahieren.
Tasks/Prozesse auf Benutzerebene sollten möglichst nicht wissen, auf welcher CPU sie laufen. Dies verhindert das Schreiben von Software im Benutzermodus, die auf die bestimmte Hardware abgestimmt ist, auf der sie sich befindet. Solche Software läuft dann möglicherweise nicht korrekt auf einer anderen CPU, was die Wiederverwendung und Portabilität verringert. Details wie die Cache-Größe liegen bei vielen Programmen unter dem Interesse.
Das Betriebssystem erlaubt normalerweise Benutzertasks/-prozessen, Hardwaredaten zu erhalten, die die Designer des Betriebssystems/Systems für relevant oder nützlich halten, über die API (Funktionsaufrufe an das Betriebssystem).
Dies ist ein wenig Spekulation, aber: ARM-Architekturen wurden immer im Hinblick auf Multiprocessing entwickelt; Selbst der niedrigste Cortex-M0 verfügt beispielsweise über eine Menge Hardware-Automatisierung, wenn es um die Kontextumschaltung geht. Jetzt kommt Cortex-M0 normalerweise ohne Cache.
Es ist durchaus denkbar, dass die Designer beim Einfügen von Caches bereits an die Möglichkeit gedacht haben, dass eine Implementierung eines Siliziumherstellers Teile des Caches vor der vom Benutzer ausgeführten Software verbergen möchte, sodass es ein logisches Problem gibt, der Userland-Software mitzuteilen, wie groß der Cache ist, da diese Größe möglicherweise nicht auf sie zutrifft. Besonders auf Cortex-R wäre das sehr sinnvoll – Sie möchten vielleicht einen Teil der Daten auf „Betriebssystemebene“ in einem Cache mit deterministischer Latenz aufbewahren, also verstecken Sie diesen Cache vor dem anderen Kontext. (Beachten Sie, dass dies für ARM besonders einfach ist – es gibt verschiedene Stack-Modi, die von einem einzelnen Registerbit gesteuert werden, und Ihr Cache-Controller könnte sich einfach darauf stützen, um zu entscheiden, ob es in Ordnung ist, ein Stück Cache zu zerstören oder nicht.)
pjc50
Matt
pjc50