Sprachen: English | 简体中文 | 繁體中文 | 日本語 | 한국어 | Français | Deutsch | Español | Italiano | Русский | العربية
CPU-Ausführung ist unabhängig von Gastbetriebssystem, Image-Loader und Aufrufkonvention. Mit NEVERD_ENABLE_CPU_EMULATION lässt sie sich allein bauen; NEVERD_ENABLE_DRIVER_EMULATION schließt zusätzlich das Windows-Treibermodell ein. Der Architekturleitfaden beschreibt Zuständigkeiten, Backend-Auswahl und Plattformgrenzen.
NEVERD_ENABLE_SEMANTIC_TESTS ist standardmäßig ON und steuert die Testgruppe in unittests/semantic samt ihren Sammelzielen. Für native CPU-Tests ohne Unicorn bleibt BUILD_TESTING=ON aktiv; zusätzlich werden NEVERD_ENABLE_SEMANTIC_TESTS=OFF und NEVERD_EMULATION_BACKEND_UNICORN=OFF gesetzt. Native KVM/WHP-Tests bleiben damit verfügbar, auch unter Windows ARM64/MSVC mit geeigneten SDK-Headern. Unicorn unter Windows ARM64 benötigt weiterhin eine ARM64-LLVM-MinGW-Toolchain. Diese Trennung des Builds belegt noch keine native ARM64-Ausführung.
Die öffentliche ExecutionConfiguration wird vom CPU-Factory-Code und der Fähigkeitsabfrage gemeinsam verwendet. Anforderungen werden vor CPU-Allokation oder Adressraumzuordnung geprüft. Weggelassene Werte nehmen das feste Vertragsprofil; explizit nicht unterstützte Werte schlagen fehl.
| JSON-Feld | Standard | Bedeutung |
|---|---|---|
backend |
auto |
auto, unicorn, kvm oder whp |
contract |
software-cpu-v1 |
Versionierte Ausführungssemantik |
architecture |
x86_64 |
x86_64 oder aarch64 |
privilege |
Vertragsprofil | flat, supervisor oder user; muss zum Vertrag passen |
virtual_address_bits |
Vertragsprofil | Geprüfte Profile: 48 Bit; flache Profile: direkter 64-Bit-Mapping-Namensraum |
page_size |
4096 | Gast-Mapping-Größe; andere Werte werden abgelehnt |
required_features |
[] |
Erforderliche Namen aus ExecutionConfiguration.def |
driver-strict akzeptiert x64; software-cpu-v1 x64 und ARM64. checked-x64-v1 und checked-aarch64-v1 verlangen die jeweilige Architektur und Supervisor-Privileg. checked-user-x64-v1 und checked-user-aarch64-v1 führen den begrenzten, vertragsabhängigen Befehlsumfang mit MMU-Isolation bei CPL3 beziehungsweise EL0 und expliziten Service-Request-Exits aus. Unterstützt werden Unicorn sowie ein zum Host passendes KVM/WHP; auto folgt der Hostauswahl. direct-user-x64-v1 führt den x64-User-Befehlssatz für Workloads, deren Start Milliarden Befehle benötigt, auf Unicorn oder dem hostgleichen KVM/WHP-Transport zwischen architektonischen Ereignissen aus, statt ihn einzeln schrittweise auszuführen. Es lässt nichts zu und beobachtet weder Befehle noch Speicherzugriffe; allein die Gast-Seitentabellen stellen die CPL3-Isolation bereit. Seine Dienstgrenze entspricht checked-user-x64-v1: Die System-Call-Erweiterung bleibt deaktiviert, daher ist ein Dienstbefehl das Undefined-Opcode-Ereignis an der Adresse, an der der Gast den Dienst anfordert, und wird als derselbe ausstehende Dienst gemeldet. Der Lauf nutzt ein Zeitbudget, nie ein Befehlsbudget oder Quantum. Unicorn und hostgleiches KVM/WHP implementieren es; HVF bleibt ausgeschlossen. Unicorn bildet Dienst-Hooks auf dieselbe ursprüngliche PC-Grenze ab und sichert den CPU-Zustand bei Unterbrechung. Ausführungs-Watches gelten weiterhin: Ihre Seiten werden nicht ausführbar gemacht, sodass der erste Abruf in einen überwachten Bereich an derselben Grenze faultet, an der ein geprüfter Instruktions-Watch anhält. Beobachtungsgesteuertes Entpacken stellt einen Einstieg zwischen expliziten Watch-Grenzen wieder her. Flache Profile versprechen keine architektonische User-/Supervisor-Isolation. Die geprüften ARM64- und x64-Profile unterstützen die unten genannten begrenzten FP/SIMD-Familien. Supervisor-x64 ergänzt begrenzte MMIO-Transaktionen und vorbereitete String-Lesezugriffe; User-Profile lehnen Gerätemappings ab. Port-I/O bleibt ausgeschlossen. Nur die User-Profile melden service_traps.
ExecutionSession::watchMemoryWrites fordert RAM-Invalidierung nach bestätigten Befehlseffekten an. Geprüfte CPUs vergleichen physische Bytebereiche; direkte x64-Ausführung kann auch andere Schreibzugriffe derselben physischen Seite melden. Eine Meldung beweist keine Byteänderung und belastet nicht den folgenden Befehl. Gastfehler und ausstehende Dienste behalten Vorrang. Watches folgen aktuellen Mappings und Aliasen; nicht unterstützte CPUs lehnen nichtleere Mengen ab. instructionSize prüft einen gestoppten Befehl mit dem Ausführungsdecoder, ohne einen Gastfehler zu veröffentlichen.
Partielle x64-Seitenüberwachung verwendet dekodierte Kontrollflussregionen und interne Ausführungsstopps: KVM/WHP nutzen Hardware-Ausführungsbreakpoints, Unicorn adressbegrenzte Hooks. Unbekannter Kontrollfluss und zu viele Grenzen behalten Prozessorschritte bei. Schreibschutz der physischen Codeseite verwirft den Plan vor Codeänderungen. Die Fortsetzung von PUSHF/POPF setzt kein TF; ein echtes Gast-#DB bleibt eine Gastausnahme. Reine Überwachungsänderungen aktualisieren betroffene Blatteinträge und behalten RAM-Referenzen. Änderungen an Zuordnung, Privileg, Ausnahmemonitor oder physischem Transportfenster verwerfen das Layout. Ein begrenzter Cache verwendet Kontrollflusspläne erst nach erneuter Prüfung aller zur Dekodierung verwendeten Bytes, auch bei Änderungen über Aliasse inaktiver Seiten. Die Inspektion liest ein zugängliches Präfix in einem Zugriff, ohne einen fehlerhaften Rest zu lesen.
User-Ausführung benötigt auf jeder gemappten Seite UserAccessible zusätzlich zum passenden Recht Read, Write oder Execute. Bestehende Mappings sind standardmäßig Supervisor-Seiten; Aliase behalten unabhängige Rechte, auch wenn sie dieselben physischen Bytes teilen. UserAccessible allein erlaubt keinen Zugriff. Vertrauenswürdige Hostzugriffe und Supervisor-CPUs verwenden RWX. Beispiel:
Configuration.Contract = ExecutionContract::CheckedUserX64;
Configuration.Privilege = ExecutionPrivilege::User;
auto CPU = llvm::cantFail(createExecutionBackend(Configuration, Space)).CPU;
llvm::cantFail(CPU->map(Code, 4096, Read | Write | Execute | UserAccessible));Das Privileg ist durch den Vertrag festgelegt; Kontextwiederherstellung oder Adressraumwechsel ändert es nicht, und x64-Segmentselektoren können es nicht erhöhen. Wiederherstellbare Datenzugriffsfehler behalten Instruktion und Register unverändert, bis der zuständige Besitzer sie behandelt. canAccess prüft genau die angeforderten Rechte; für User-Sichtbarkeit muss UserAccessible mitgeprüft werden. Seitentabellen sind private CPU-Projektionen, keine veränderbaren Gasttabellen oder Privilegwechsel-API. Bei ARM64 sind User-Seiten zusätzlich auf EL1 nicht ausführbar.
Unbekannte oder nullwertige Felder, ungültige Namen/Breiten, doppelte Features und nicht unterstützte Kombinationen schlagen fehl. Eingaben sind auf 64 KiB begrenzt; alte CPU-Factories und Driver-C-Optionen bleiben kompatibel.
ExecutionFeature::ParallelCPUs (parallel_cpus) aktiviert checked x64/ARM64 mit KVM, WHP oder Unicorn auf getrennten Host-Threads und gemeinsamer physischer RAM. Nachweislich nichtschreibende native Befehle können sich überlappen. Wartende Schreiber sperren neue Befehle und warten vor Veröffentlichung auf Leser. Die Effekte sind sequenziell konsistent; Abbruch beim Warten und Rollback bleiben möglich. Mappingänderungen und Host-Schreibzugriffe warten auf das Ende aller Läufe. Am selben CPU-Objekt ist nur stop() threadübergreifend sicher. Die CPU-Ausführung bleibt standardmäßig kooperativ; OS-Scheduling und die Untersuchung schwacher Speicherordnungen sind eigenständige Verträge.
Parallele WHP-CPUs verwenden unabhängige VPs in einer gemeinsamen Partition: höchstens 31 gleichzeitig gebundene parallele CPUs zusätzlich zum kooperativen VP. Private GPA-Bereiche und Transport-RAM trennen die Projektionen; ARM64 verwendet eigene ASIDs und nicht globale Übersetzungen. Vor jeder nativen Ausführung werden Code und deklarierte Operanden kopiert; nur deklarierte Ausgabebytes gelangen in die gemeinsame RAM-Transaktion. Beobachter lesen den maßgeblichen RAM. KVM und checked Unicorn greifen direkt auf gemeinsamen Speicher zu. HVF und Unicorns Software-Vertrag bieten diese Fähigkeit nicht an.
MMIOAtomics (mmio_atomics) benötigt GuestMMIOCallbacks::PrepareAtomic. Supervisor-x64 unterstützt zugelassene Austausch-, Vergleichsaustausch-, Ganzzahl- und Bitänderungen; ARM64 unterstützt LSE einschließlich CASP. Erlaubt sind natürlich ausgerichtete 1/2/4/8/16 Byte. x64 berechnet Register/FLAGS mit dem Originalbefehl in privatem Speicher, ARM64 mit der gemeinsamen LSE-Semantik. Vorbereitung hat keine Effekte; Commit prüft Lebensdauer/Version und veröffentlicht einmalig. Vorheriger Abbruch oder Fehler erhält CPU/Gerät; ein erfolgreicher Commit hat Vorrang vor gleichzeitigem Abbruch. Kein Read+Write-Ersatz. Kernel-Registerbanken behalten deklarierte 1/2/4-Byte-Breiten und verwerfen alte Vorschauen nach gleichwertigen Schreibzugriffen, Stromzustandswechseln oder Freigabe. Normale ARM64-Gerätetransfers, exklusive Gerätemonitore, Benutzer-MMIO und beliebige Hardware bleiben ausgeschlossen.
neverd cpu-capabilities
neverd cpu-capabilities \
--configuration='{"contract":"checked-aarch64-v1","architecture":"aarch64"}' \
--probe-hostDas Schema hat Version 1. Der Bericht trennt requested_configuration (vor Profilvorgaben), normalisierte configuration, statische semantische capabilities, Adapter-Build/ABI unter build und host (null ohne --probe-host). Eine Host-Abfrage initialisiert eine temporäre CPU über privatem RAM und belegt nur die Initialisierbarkeit, nicht die Kompatibilität beliebiger Workloads. Verfügbarkeit kann sich ändern; nicht verfügbare Backends werden nie stillschweigend ersetzt. CLI liefert für einen gültigen Bericht einschließlich eines nicht verfügbaren Backends 0, für ungültige Konfiguration/Abfrage 1.
neverd_cpu_capabilities_json akzeptiert eine Sitzung, optionales Konfigurations-JSON und ProbeHost 0 oder 1; ein geladenes Binary ist nicht erforderlich. Ergebnis mit neverd_free_string freigeben; NULL signalisiert einen Fehler, dessen Text neverd_last_error liefert. CPU-deaktivierte Builds behalten die Funktion und melden die Deaktivierung. Python-Plugins fragen über session.cpu_capabilities(...) ab. C++ kann executionCapabilities, resolveExecutionConfiguration, queryExecutionBackendBuild und probeExecutionBackend getrennt aufrufen; createExecutionBackend bindet eine CPU an einen bestehenden Adressraum oder legt privaten RAM samt Standardraum an.
CPU.runUntilExit(PC, TimeoutMicroseconds) liefert ein typisiertes ExecutionExit. Setupfehler ergeben llvm::Error; gestartete Läufe melden explizit Stop, Deadline, Service-Request, wiederherstellbaren Fehler, Gastfehler/-trap, nicht unterstützte Operation, Geräte-/Backendfehler oder unerklärten Engine-Stopp. CPU-/Geräte-/Backendfehler haben Vorrang vor gleichzeitigem Stop oder Deadline; beide unabhängigen Fakten und Fehlerdetails bleiben erhalten. Das Zeitlimit muss positiv sein und sowohl Dauer als auch absolute Deadline darstellen können; andernfalls schlägt der Aufruf vor Änderungen am CPU-Zustand fehl. Jede Ausführung braucht ein endliches Budget; Null bedeutet weder unbegrenzte Ausführung noch einen gültigen Sofort-Timeout. Die Kontrolle ist kooperativ, keine harte Echtzeitgrenze. Wiederherstellbare Fehler werden durch das Ergebnis nicht verbraucht; der OS-Besitzer muss sie übernehmen und einen validierten Ausnahmeübergang installieren. Die alten APIs run, fault und timedOut bleiben bestehen. Externe CPU-Implementierungen, die nur run überschreiben, lehnen die neue typisierte Grenze ab.
Geprüftes User-x64 fängt nur die genaue, unpräfixierte SYSCALL-Kodierung ab; User-ARM64 fängt SVC #imm16 ab. SYSENTER, INT, HVC, BRK und andere Wege bleiben nicht unterstützt. Zuerst läuft der Instruktionsbeobachter. Ohne Stop/Fehler gibt der CPU ExecutionExitKind::ServiceRequest vor Ausführung der Instruktion oder Eintritt ins Backend zurück, mit Typ, ursprünglichem PC, sequenziellem NextPC und SVC-Immediate. Register, Flags, Stack und Privileg bleiben unverändert: insbesondere gibt es noch keine RCX/R11-SYSCALL-Clobber und keinen ARM64-Ausnahmevektor. Das SVC-Immediate ist kein universeller Dienstnummernwert.
Die Anfrage bleibt anhängig und blockiert Ausführung, CPU-Mutation, Adressraumwechsel sowie Kontextaufnahme/-wiederherstellung, bis der OS-Besitzer sie im angehaltenen Zustand genau einmal mit takeServiceRequest() übernimmt. Der Besitzer dekodiert die OS-ABI, behandelt den Dienst und setzt Ergebnisregister sowie nächsten PC/Ausnahmeübergang explizit. Nicht unterstützte Dienste schlagen dort fehl; erneut am ursprünglichen PC starten erzeugt eine neue Anfrage. Es gibt kein implizites NOP oder erfundenes erfolgreiches Ergebnis. Ein Service-Event hat Vorrang vor Stop/Deadline, Gast- oder Backendfehler haben höhere Priorität. CPU-Stopp, Software-HLT, Deadline oder Gast-Trap beweisen keinen erfolgreichen Workload. Das separate Linux-Prozessprofil modelliert eigene OS-Dienste und belegt keine Windows-, Android- oder Darwin-Laufzeit. Native Windows- und ARM64-Läufe benötigen weiterhin Laufzeitvalidierung.
Die Beschreibungen maskierter x64-Befehle bilden die portable Basis. KVM/WHP ergänzen precise_simd_exceptions für driver-strict, checked-x64-v1 und checked-user-x64-v1: Die native Startprüfung bestätigt ein präzises #XM und beide Wiederholungen vor unmaskierten MXCSR-Schreibzugriffen, LDMXCSR und Windows-CONTEXT-Wiederherstellung. ExecutionProfiles.def verwaltet die Auswahl; supportsSIMDExceptions zeigt die Fähigkeit der Instanz. Checked Unicorn bleibt maskiert; ARM64 und HVF erhalten hier keine neue Ausnahmefähigkeit.
Natives x64 KVM/WHP liefert echte #XM-Fehler über X64SIMDException an Treiber-C-SEH. Hardwarefehler-CONTEXT erhält XMM0–15 und MXCSR. Filter, finally-Aufrufe beim Ausnahme-Unwind und ausgewählte Handler laufen mit MXCSR 0x1f80 und gelöschtem DF. Ein negativer Filter kann XMM und das obere CONTEXT.MxCsr ändern und die ursprüngliche Instruktion wiederholen; die Gast-CPU-Maske begrenzt MXCSR. FltSave.MxCsr steuert die Kernel-Wiederherstellung nicht. Modellierte API-Ausnahmen behalten Ganzzahl-/Steuerfelder; Änderungen an x87/AVX bleiben unzulässig.
Geprüftes x64 unterstützt begrenzte Legacy-SSE/SSE2-Moves und Logik, MOVLHPS/MOVHLPS sowie maskierte skalare CVTTSS2SI/CVTTSD2SI/SUBSS/SUBSD-Formen. MXCSR erhält Sticky-Status, Rundung und FTZ; nicht maskierte Ausnahmen werden abgelehnt. KVM/WHP synchronisieren alle 16 XMM-Register und MXCSR; nicht gelistete Codierungen und Operanden bleiben ausgeschlossen.
Geprüftes x64 erlaubt auch maskierte Legacy-Formen SS, SD, PS, PD von ADD, SUB, MUL, DIV, SQRT, MIN, MAX. X64SSEInstructions.def verwaltet Breiten, Ausrichtung und Zulassung zentral. MaskedSSEArithmeticMatchesIndependentHostExecution vergleicht Register/RAM mit einem unabhängigen Host-CPU-Orakel: vier Rundungsmodi, FTZ, vorzeichenbehaftete Nullen, Subnormalzahlen und NaNs. SSEMemoryObserverStopsBeforeResultAndStatusChanges prüft den Stopp vor Effekten. x87 und AVX bleiben ausgeschlossen.
Im portablen Softwareprofil wendet Unicorn DAZ auf den von den klassischen Befehlen MINSS/MINSD/MINPS/MINPD und MAXSS/MAXSD/MAXPS/MAXPD ausgewählten Wert an. Ein ausgewählter subnormaler Eingang wird zu einer vorzeichenbehafteten Null; NaN-Nutzdaten und vorhandene MXCSR-Statusbits bleiben erhalten. test_x86_sse_minmax_daz prüft Register-, RAM- und Registeraliasformen mit ein- und ausgeschaltetem DAZ, allen Rundungsmodi, FTZ und kumulierten Statusbits.
KVM/WHP ermitteln MXCSR_MASK durch private Ausführung von FXSAVE64 und prüfen DAZ mit einer Rechenoperation auf einer vorzeichenbehafteten subnormalen Zahl. Checked Unicorn liefert seine Softwaremaske. supportedControlBits meldet die unveränderliche CPU-Maske, die FX/XSAVE, Kontextabbilder und Windows CONTEXT gemeinsam verwenden. Checked LDMXCSR/STMXCSR greifen genau auf m32 zu, prüfen den gesamten RAM-Bereich und erhalten den Zustand bei Fehlern oder Abbruch durch Beobachter. Geladene reservierte Bits lösen #GP aus; portable Ausführung lehnt unmaskierte SIMD-Ausnahmen ab. X64MXCSRTests.cpp prüft Steuerung und Wiederholung; X64DAZData vergleicht alle 28 zugelassenen SSE-Rechenformen mit den Originalbefehlen des Hosts unter DAZ, Rundung und FTZ. Die DAZ-Unterstützung von HVF wird nicht erweitert.
Die native x64-Startvalidierung nutzt ein gemeinsames Budget von 5 s für die kalte Transportvorbereitung und sämtliche Prüfschritte. Gastlaufzeitbudgets bleiben unabhängig. Bei einer Unterbrechung werden Instruktionsphase, stop_requested und deadline_reached gemeldet; Fehlertyp und Transportdiagnose bleiben erhalten. Es gibt weder einen automatischen Neuversuch noch die Freigabe einer unvollständig validierten CPU.
PAUSE (F3 90) wird über die gemeinsame x64-Maschinenschnittstelle auf KVM/WHP und checked Unicorn ausgeführt, einschließlich des nativen Vertrags driver-strict. X64PauseTests.cpp prüft den vollständigen Zustandserhalt, Stopps vor der Ausführung, die Kontextwiederherstellung, die Ablehnung eines ungültigen LOCK sowie Fristablauf und Fortsetzung von Warteschleifen. Dieser Prozessorhinweis plant keine Gastthreads ein und garantiert keine bestimmte Verzögerung.
PUSHFQ (9C) und 16-Bit-PUSHF (66 9C) laufen über natives KVM/WHP und checked Unicorn, einschließlich driver-strict. Die gemeinsame ISA-Schicht entfernt das interne Einzelschritt-TF aus dem Stackabbild, bevor sie die RAM-Transaktion bestätigt. Die implizite Stackadressierung verwendet das vollständige RSP; die Präfixreihenfolge bestimmt die Operandenbreite. Berechtigungsprüfung des gesamten Bereichs, Beobachterstopps und Wiederholung nach Fehlern erhalten die Atomarität. X64PushFlagsTests.cpp prüft alle 256 erlaubten Flagkombinationen, neun Kodierungen, seitenübergreifende Aliase, Benutzerrechte, Abbruch und Kontextwiederherstellung.
POPFQ (9D) und 16-Bit-POPF (66 9D) stellen Flags in der gemeinsamen x64-ISA-Schicht für KVM, WHP und checked Unicorn einschließlich driver-strict wieder her. Bei festem IOPL null darf CPL0 IF ändern; CPL3 erhält IF und IOPL. Reservierte Bits und VM/VIF/VIP werden ignoriert, RF wird gelöscht. Wirksame Änderungen an Gast-TF, NT, AC, ID oder CPL0-IOPL bleiben ununterstützt und scheitern vor der Veröffentlichung. Nach vollständigem Lesen des Stacks werden FLAGS/RSP/RIP atomar aktualisiert; der volle RSP und die wirksame Präfixreihenfolge bestimmen den Operanden. Der Stack darf schreibgeschützt sein oder ausführbaren Speicher aliasieren. Der gemeinsame Abschluss verhindert das Löschen des internen Transport-TF. X64PopFlagsTests.cpp vergleicht unabhängige native CPL3-Instruktionen und prüft jedes Eingabebit, Fehler, Beobachter und die anschließende native Ausführung.
Checked x64 lässt CLC/STC/CMC und LAHF/SAHF zu. Übertragsbefehle verwenden den Transport; AH-Transfers teilen einen ISA-Übergang für KVM, WHP und checked Unicorn einschließlich nativem driver-strict. LAHF schreibt fünf Statusflags und feste Bits nach AH; SAHF ändert nur CF/PF/AF/ZF/SF. OF/IF/DF und andere Register bleiben erhalten. Ignorierte Präfixe einschließlich aller REX-Werte verwenden weiterhin implizites AH. X64StatusFlagsTests.cpp prüft originale Hostbefehle, vollständigen Zustand, Abbruch und Fortsetzung. Der festgelegte Unicorn-Übersetzer erhält implizites AH unter REX auch im portablen Profil und weist LOCK für diese fünf Befehle vor jeder Zustandsänderung ab.
Checked x64 führt SHLD/SHRD über KVM, WHP und Unicorn mit 16/32/64-Bit-Zielen und imm8- oder CL-Zählwerten aus. Es gilt die Architekturmaske; undefinierte 16-Bit-Zählwerte über 16 werden vor jeder Wirkung abgewiesen. RAM-Ziele nutzen Lese-/Schreibprüfungen in exakter Breite und die vorhandene Transaktion: Ergebnisbeobachtung vor Veröffentlichung, Rücknahme von CPU und Speicher bei Abbruch. LOCK und Geräteoperanden bleiben ausgeschlossen.
X64ScalarShiftInstructions.def definiert die Auswirkungen von SHL/SHR/SAR, ROL/ROR und RCL/RCR auf 8/16/32/64-Bit-Ziele. Register- und RAM-Formen unterstützen die implizite Anzahl 1, imm8 oder CL, einschließlich nach der Maskierung nuller Anzahlen und SAL-Aliassen. RAM-Schreibzugriffe durchlaufen Berechtigungsprüfungen, Ergebnisbeobachter und die gemeinsame Transaktion; Stopps und Callback-Fehler stellen CPU und Speicher wieder her. KVM, WHP und Unicorn im geprüften Modus teilen diese Grenze. LOCK- und MMIO-Formen bleiben ununterstützt.
X64LoopInstructions.def lässt LOOP/LOOPE/LOOPNE über den Prozessortransport zu. Die Adressgröße wählt RCX oder das mit Nullen erweiterte ECX; FLAGS bleibt unverändert. Die Zielbreite folgt dem CPU-Modell: Intel ignoriert 66H im Long Mode, AMD behält die 16-Bit-Überschreibung bei, und REX.W hat Vorrang. Natives KVM/WHP verwendet den Hostprozessor, Unicorn sein voreingestelltes Intel-Haswell-Modell. Gemeinsame Zulassungsregeln weisen LOCK und REP vor Seiteneffekten ab, auch wenn der Decoder sie auslässt.
X64BranchModel stimmt die Dekodierung relativer JMP/Jcc mit der Ausführung ab. Native KVM/WHP messen beim zeitlich begrenzten Start nicht genommene 66H-Sprünge und den Vorrang von REX.W; geprüftes Unicorn nutzt sein Intel-Modell. Das unveränderliche Ergebnis wählt den Decoder für Beobachter und Windows-Treiberrichtlinie. Intel behält im Long Mode rel32 und die volle Zielbreite bei; AMD berücksichtigt seine 16-Bit-Überschreibung. Unvollständige Bytes scheitern vor Beobachtern oder CPU-Eintritt.
X64StackInstructions.def erlaubt 16/64-Bit-PUSH/POP mit allgemeinen Registern und gewöhnlichem RAM sowie PUSH mit Direktwert auf KVM, WHP und geprüftem Unicorn einschließlich driver-strict. PUSH liest vor dem Verringern von RSP; POP berechnet ein RSP/ESP-basiertes Ziel nach dem Erhöhen. Die Adressbreitenbegrenzung gilt nur für den expliziten Operanden. Vollständige Rechteprüfung, geordnete Beobachtung und eine RAM-Transaktion verhindern Teiländerungen an CPU und Speicher bei Fehlern, Abbruch oder Callback-Fehlern. LOCK und Geräteoperanden bleiben ausgeschlossen.
KVM, WHP und checked Unicorn unterstützen auch LEAVE mit 16/64 Bit. Der gespeicherte Rahmen wird auch mit 67H über den vollständigen RBP gelesen; die 16-Bit-Form erhält die übrigen RBP-Bits. Fehler oder abgebrochene Lesezugriffe erhalten den ursprünglichen RSP und CPU-Kontext. LOCK, REP und Rahmen im Gerätespeicher bleiben ausgeschlossen.
KVM, WHP und checked Unicorn unterstützen ENTER mit 16/64 Bit: vorzeichenlose 16-Bit-Allokation, Verschachtelung modulo 32, vollständige RSP/RBP und wirksame Präfixreihenfolge. Bei einem Gastfehler bleiben abgeschlossene Stack-Schreibzugriffe sichtbar; RSP, RBP und PC behalten ihre Eingangswerte. Die abschließende Stackprüfung kontrolliert Schreibrechte über die ganze Operandenbreite, ohne Daten zu schreiben. LOCK, REP, APX-Präfixe und Geräteframes bleiben ausgeschlossen.
Geprüftes x64 lässt den Zwei-Byte-Nahrücksprung F3 C3 zu. Compiler setzen das Wiederholungspräfix vor einen Rücksprung, der ein Sprungziel ist, und der Prozessor ignoriert es; der Befehl ist daher der bereits zugelassene C3-Transfer mit demselben Stapellesezugriff. Jeder andere Rücksprung mit Präfix, einschließlich F2 C3, eines zweiten Präfixes, einer Operandengrößenänderung und F3 C2 iw, bleibt außerhalb des Vertrags. X64ReturnPrefixTests.cpp prüft KVM, WHP und geprüftes Unicorn.
X64PackedIntegerInstructions.def lässt 45 gepackte Ganzzahloperationen von legacy SSE2 zu: modulare und sättigende Addition/Subtraktion, Vergleiche, Multiplikation, Mittelwerte, Extrema, Bytedifferenzen sowie Packen und Entpacken. XMM und ausgerichtete 128-Bit-RAM-Quellen nutzen den bestehenden checked-Pfad von KVM, WHP und Unicorn. FLAGS und MXCSR bleiben unverändert; Fehler und Beobachterabbrüche bewahren den Zustand. MMX, VEX/EVEX und Geräteoperanden bleiben ausgeschlossen.
X64PackedShiftInstructions.def lässt zehn klassische gepackte SSE2-Schiebeoperationen zu. Elementweises Schieben akzeptiert imm8 oder XMM/ausgerichtete m128-Zähler; byteweises Schieben nur imm8. Variable Zähler verwenden die unteren 64 Bits ohne Vorzeichen und ohne skalare Maskierung; die oberen 64 Bits werden ignoriert. Auch bei null oder übergroßen Zählern werden alle 16 Speicherbytes geprüft und gelesen. FLAGS und MXCSR bleiben unverändert; MMX, VEX/EVEX und Geräteoperanden bleiben ausgeschlossen.
X64VectorOperands.def definiert vollständige Operandenformen für klassische SSE-Transfers, Berechnungen, Verschiebungen, Konvertierungen und Masken. MOVMSKPS, MOVMSKPD und PMOVMSKB extrahieren XMM-Vorzeichenbits nach r32/r64 und setzen die übrigen Zielbits auf null. KVM, WHP und checked Unicorn nutzen dieselben Zulassungsregeln; FLAGS, MXCSR und Quellregister bleiben erhalten. Speicheroperanden für Masken sowie MMX- und VEX/EVEX-Formen bleiben ausgeschlossen.
X64ShuffleInstructions.def ergänzt PSHUFD, PSHUFHW, PSHUFLW, SHUFPS und SHUFPD. X64VectorOperands.def verlangt drei vollständige Operanden: XMM-Ziel, XMM- oder ausgerichtete m128-Quelle und imm8. Die Originalbefehle wählen unveränderte Lane-Bits aus und erhalten FLAGS und MXCSR. Speicherformen prüfen alle 16 Bytes; Ausrichtungsfehler treten vor Datenbeobachtungen auf. KVM, WHP und checked Unicorn teilen diese Regeln. Dasselbe Inventar erlaubt UNPCKLPS, UNPCKHPS, UNPCKLPD und UNPCKHPD mit genau zwei Operanden. Sie verschachteln unveränderte Elemente aus ursprünglichem Ziel und Quelle. Hardware darf nur die ausgewählten 64 Bits lesen; checked RAM prüft den ausgerichteten m128-Operanden.
MOVLPS, MOVHPS, MOVLPD und MOVHPD übertragen genau acht RAM-Bytes ohne Ausrichtungsanforderung. X64VectorInstructions.def deklariert die zu speichernde Hälfte; X64VectorOperands.def verlangt ein XMM/m64-Paar. Ladevorgänge erhalten die übrigen 64 Bits, und Beobachter hoher Speichervorgänge erhalten die obere Hälfte. KVM, WHP und checked Unicorn teilen Berechtigungsprüfungen über den gesamten Bereich und die RAM-Rücknahme. Die reinen Registerformen MOVHLPS/MOVLHPS behalten ihre eigene Semantik.
CVTSI2SS und CVTSI2SD wandeln vorzeichenbehaftete 32/64-Bit-Ganzzahlen gemäß MXCSR-Rundung um und erhalten den Präzisionsstatus. Die gemeinsame Regel IntegerSource verlangt ein XMM-Ziel und r32/r64 oder m32/m64 als Quelle. Legacy-Formen erhalten die oberen 96/64 Zielbits; Speicherprüfungen verwenden die Ganzzahlbreite. KVM, WHP und checked Unicorn führen den Originalbefehl aus. MMX und VEX/EVEX bleiben ausgeschlossen.
CVTSS2SI und CVTSD2SI erzeugen über die gemeinsame Regel IntegerResult vorzeichenbehaftete 32/64-Bit-Ganzzahlen gemäß MXCSR-Rundung; CVTTSS2SI und CVTTSD2SI runden immer gegen null. Maskierte NaN- oder Bereichsfehler liefern den Integer-Indefinite-Wert und setzen den Invalid-Status; gültige ungenaue Ergebnisse setzen den Präzisionsstatus. Bestehende Statusbits, FLAGS und XMM-Quellen bleiben erhalten. r32-Ergebnisse löschen die obere GPR-Hälfte. RAM liest die Breite der Gleitkommaquelle unabhängig vom Ziel; FTZ verwirft keine subnormalen Eingaben. Dies gilt für KVM, WHP und checked Unicorn.
COMISS, COMISD, UCOMISS und UCOMISD vergleichen skalare XMM- oder m32/m64-Operanden über die gemeinsame Regel Source. Sie setzen CF/PF/ZF, löschen OF/SF/AF und erhalten andere FLAGS und Quell-Lanes. COMIS meldet Invalid für jedes NaN, UCOMIS nur für signalisierende NaNs; NaN-Behandlung hat Vorrang vor dem Denormal-Status. MXCSR-Statusbits bleiben erhalten; Rundung und FTZ ändern den Vergleich nicht. KVM, WHP und checked Unicorn teilen exakte Speicherprüfungen. Die Vergleichsfunktionen der festgelegten Unicorn-Version verwenden die vorhandene Klassifikation subnormaler Eingaben.
CMPSS, CMPSD, CMPPS und CMPPD führen die acht klassischen Prädikate auf KVM, WHP und checked Unicorn aus. Die gemeinsame Regel Source akzeptiert dekodierte Aliase; reservierte Steuerwerte bleiben ausgeschlossen. Skalare Formen erhalten obere Lanes und lesen m32/m64, gepackte Formen verlangen ausgerichtetes m128. FLAGS und bestehender MXCSR-Status bleiben erhalten; Invalid-/Denormal-Status wird je aktiver Lane gesammelt. Capstone verantwortet Familien-IDs und SSE-Bedingungen und ersetzt die bisherige ID-Korrektur allein im Lifter. Unicorn klassifiziert subnormale Eingaben in jeder Vergleichsfunktion.
CVTSS2SD, CVTSD2SS, CVTPS2PD und CVTPD2PS konvertieren klassische SSE-Präzision über die gemeinsame Regel Source. Skalare Ergebnisse erhalten die oberen 64/96 Zielbits. Gepackte Erweiterung liest m64 und schreibt zwei Doubles; Verengung liest ausgerichtetes m128, schreibt zwei Singles und löscht die oberen 64 Bits. Originalbefehle auf KVM, WHP und checked Unicorn erhalten FLAGS und sammeln maskierten MXCSR-Status gemäß Rundung und FTZ. Unicorn klassifiziert jeden aktiven subnormalen Eingang in seinen Konvertierungsfunktionen. VEX/EVEX bleiben ausgeschlossen.
CVTDQ2PS und CVTDQ2PD konvertieren gepackte vorzeichenbehaftete 32-Bit-Ganzzahlen über Source. Einfache Präzision liest ausgerichtetes m128 mit MXCSR-Rundung; doppelte Präzision liest auch unausgerichtetes m64 und ist exakt. Das gesamte Ziel-XMM wird ersetzt; FLAGS und vorhandener MXCSR-Status bleiben erhalten, ungenaue einfache Ergebnisse setzen den Präzisionsstatus. KVM, WHP und checked Unicorn führen Originalbefehle aus. Unicorn erkennt beide gepackten Erweiterungen und liest acht Bytes. MMX und VEX/EVEX bleiben ausgeschlossen.
CVTPS2DQ und CVTPD2DQ verwenden MXCSR-Rundung; CVTTPS2DQ und CVTTPD2DQ schneiden gegen null ab. Source verlangt ausgerichtetes m128 oder XMM. NaN oder Bereichsüberschreitung einer Lane erzeugt signed32 indefinite und den Invalid-Status; andere gültige ungenaue Lanes setzen unabhängig den Präzisionsstatus. Singles ergeben vier Ganzzahlen, Doubles zwei mit gelöschten oberen 64 Zielbits. FLAGS und vorhandener MXCSR-Status bleiben erhalten; FTZ verwirft keine subnormalen Eingaben. KVM, WHP und checked Unicorn führen Originalbefehle aus. MMX und VEX/EVEX bleiben ausgeschlossen.
X64AlignmentTests.cpp prüft, dass fehlausgerichtete Operanden zugelassener aligned-SSE-Befehle einen behebbaren oder terminalen #GP(0) vor Datenbeobachtern, Rechteprüfungen oder Geräte-Callbacks melden. Der gesamte öffentliche x64-Registerkontext, PC und RAM bleiben erhalten. Der Adressbreitenumlauf erfolgt vor der Addition von FS/GS; nach Adresskorrektur wird derselbe Befehl wiederholt. Direkte KVM/WHP-Maschinentests prüfen die Hardwaregrenze unabhängig. Windows ring3 stellt klassifizierte operand_alignment-Fehler zu; andere Ursachen für #GP bleiben ununterstützt.
Der Thread-Pointer umfasst x64-FS/GS-Basis und ARM64-TPIDR_EL0 mit den exakten MRS/MSR-Codierungen. Native Transporte und CPU-Snapshots erhalten diesen Zustand getrennt vom Speicher; dadurch entstehen weder OS-Threads noch TLS-Blöcke. Supervisor-x64 unterstützt ausgerichtete skalare MMIO-Transaktionen mit 1/2/4 Byte und ein MOVS-Element pro Restart-Grenze. Gerätequellen brauchen einen reinen Prepared-Read mit höchstens einmaligem Commit. Gerätemappings bleiben für User-Profile ausgeschlossen; RMW, breites MMIO und Port-I/O ebenfalls.
KVM und WHP brechen aktive native Eintritte ab und bestätigen den Abbruch, bevor Ausführungsressourcen freigegeben werden. KVM nutzt einen privaten Ausführungsthread und eine temporär entsperrte Realtime-Signalmaske; das gewählte Signal darf während des Eintritts nicht ignoriert werden. Caller-Masken und -Handler bleiben unverändert. Bei ungewissem Gastfortschritt ist Abbruch terminal; eine harte Echtzeitfrist wird nicht garantiert.
Checked x64 führt DIV/IDIV mit echten Prozessorergebnissen und #DE aus. KVM nutzt eine private Supervisor-IDT/IST, WHP eine explizite Ausnahme-Bitmap; ursprünglicher Kontext und verfügbare Fehlercodes bleiben von Transportfehlern getrennt. Das OS konsumiert das wiederaufnehmbare Ereignis vor dem Setzen einer Fortsetzung. Windows-Treiber behandeln Nulldivision und Quotientenüberlauf als STATUS_INTEGER_DIVIDE_BY_ZERO, mit echten SEH-Filtern, __finally und Wiederholung. NeverDX64ExceptionTests baut ohne Unicorn; DriverWDMCPUException prüft originale WDK-Fälle. Nicht verfügbare ARM64-Hosts werden explizit übersprungen.
RAMTransaction erfasst unter der physischen Ausführungslease nur die vereinigten deklarierten Schreibbereiche einer Instruktion. Vor Ergebnisbeobachtern wird der ursprüngliche RAM wiederhergestellt; Abbruch, Transportfehler und Beobachterausnahmen veröffentlichen weder Teilwrites noch Register. Prozessorfehler behalten nach RAM-Rollback ihren architektonischen Ausnahmestatus. ARM64-Einzel- und Paarstores verwenden dieselbe Instanz. x64 führt XCHG, XADD und CMPXCHG mit 8/16/32/64 Bit aus; gesperrte und implizit gesperrte Formen erfordern natürliche Ausrichtung. NeverDRAMTransactionTests vergleicht Ergebnisse mit der Host-CPU und prüft Rollback, Aliase und Rechte; fehlende Plattformen werden ausdrücklich übersprungen. Geräte-Atomics verwenden ihren eigenen Anbieter. CPU-Snapshots setzen bereits bestätigten RAM nicht zurück.
CMPXCHG8B und CMPXCHG16B führen ihre Originalbefehle mit KVM, WHP und checked Unicorn in Treiber- und Benutzerprofilen aus. Erfolgreiche und fehlgeschlagene Vergleiche benötigen Lese- und Schreibrechte; Fehler werden als Schreibzugriffe eingeordnet. CMPXCHG16B prüft vor dem Speicherzugriff die 16-Byte-Ausrichtung und meldet bei einem Verstoß #GP(0). Beide Ergebnisbeobachtungen gehören zu einer RAM-Transaktion: Ein Stopp oder eine Ausnahme in einem Callback veröffentlicht weder Register- noch RAM-Änderungen. Unverriegeltes CMPXCHG8B darf Seitengrenzen überschreiten; verriegelte Operanden erfordern weiterhin natürliche Ausrichtung. X64WideAtomicTests.cpp vergleicht originale Host-Ergebnisse und direkte native Fehler und prüft Aliase, Präfixe, Adressierung, Reparatur und Abbruch. Eigene Windows-Treiber- und Ring3-PE-Fixtures führen beide Breiten aus; die WDK-Fixture führt außerdem _InterlockedCompareExchange128 aus. Das CPU-Modell muss CMPXCHG16B unterstützen.
NeverDEmulationArch besitzt ISA-Verträge, Seitentabellen und das FP-Layout, das native Transporte und Unicorn gemeinsam nutzen. x64-Kontexte erhalten Steuerung, Status, TOP, physische Tags, Opcode, Befehls-/Datenzeiger und acht 80-Bit-Register. FP0–FP7 verwenden RegisterValue; skalare Zugriffe lehnen eine Kürzung ab. FPTag ist die physische Maske nicht leerer Register. NeverDX64FPTests prüft alle TOP-Werte, exakte Operationen gegen Host-FXSAVE/FXRSTOR und die Wiederherstellung. Dies lässt keine x87-Befehle im checked-Vertrag zu und beweist nicht sämtliche Rundungssemantik. Fehlende native Hosts werden ausdrücklich übersprungen.
driver-strict unterstützt KVM auf passenden Linux-x64-Hosts und WHP auf passenden Windows-x64-Hosts; auto wählt diesen nativen Transport, unterschiedliche ISAs verwenden Unicorn. Explizites Unicorn und die bisherige V1-API behalten das portable Softwareprofil. Native Ausführung prüft kanonische Adressen und Effekte vor dem Eintritt; fehlende Hardware führt ohne Rückfall zum Fehler. Nicht unterstützte Instruktionen und OS-Verhalten bleiben explizite Fehler. Die native Windows-x64-CI besteht bei deaktiviertem Unicorn alle 359 Pflichtprüfungen: 131 CPU-Prüfungen, 224 Treiberergebnisse aus 26 eingebauten Images, 46 WDK-Images und 40 Szenariofällen an bevorzugten und verschobenen Adressen sowie vier SEH-Grenzprüfungen (9d4c130c). Native ARM64-Nachweise fehlen weiterhin; allgemeine Treiber- oder Android/Darwin-Kompatibilität ist damit nicht belegt.
Das ausgewählte Profil lässt sich mit executionCapabilities(Contract, ISA, Backend) abfragen. NativeLegacyX64 beschreibt die native Ausführung von x64-Treibern. NeverDNativeDriverTests prüft den vorhandenen Treiberkorpus und kann auch in einem Build ohne Unicorn laufen.
Geprüftes ARM64 besitzt eine gemeinsame Grenze für den vollständigen Zustand. Registers.def definiert 39 skalare Felder und 32 Vektoren mit 128 Bit; captureAArch64State sammelt alle Werte, wendet Bitbreiten an und normalisiert NZCV vor einer einzigen Veröffentlichung. Unicorn, KVM, WHP und HVF übertragen denselben Bestand einschließlich TPIDR_EL0, TPIDRRO_EL0, TPIDR_EL1, FPCR und FPSR. Native Adapter aktivieren FP/SIMD über CPACR_EL1. Fehlgeschlagene Lesevorgänge und abgebrochene Eintritte erhalten den gesamten Aufruferzustand.
Der ARM64-KVM/WHP/HVF-Start führt das private Programm AArch64MachineProbe.def aus: NOP, FP32-Addition mit Rundung gegen positive Unendlichkeit und SIMD-Addition auf zwei Spuren. Jeder Schritt vergleicht alle 39 skalaren Felder und 32 Vektoren, einschließlich TLS, NZCV, gelöschter oberer Ergebnisbits und erhaltenem/kumulativem FPCR/FPSR-Zustand. Die Probe verwendet nur Supervisor-Monitorspeicher und eine gemeinsame Gesamtfrist. Die Proben belegen nur die begrenzte Initialisierung. Die Workload-Validierung für Linux ARM64 KVM und Windows ARM64 WHP steht noch aus; native macOS-Ergebnisse sind im HVF-Leitfaden dokumentiert. Das Programm umfasst außerdem die A/B-Signierung und Authentifizierung von Rücksprungadressen bei deaktivierten Schlüsseln sowie alle vier BTI-Formen auf ungeschützten Seiten.
Die Probe führt außerdem zweimal MRS CTR_EL0 sowie DC CVAU, DSB ISH, IC IVAU und ISB aus und prüft stabile Cachegeometrie und vollständigen Zustand. Checked EL0/EL1 erlaubt die Originalbefehle, alle benannten Basisoptionen von DSB und nur ISB SY. CTR stammt von der gewählten virtuellen CPU und kann je Transport abweichen. Cacheziele müssen mit den aktuellen Rechten lesbares normales RAM bezeichnen; unaligned Adressen und Aliase sind erlaubt, andere Ziele werden als nicht unterstützt abgewiesen. Wartung erzeugt keine Datenlese- oder Schreibereignisse. Die Projektion hält die Befehlsausführung kohärent, modelliert aber weder private Cacheinhalte noch paralleles Hardware-SMP. NeverDAArch64CacheTests prüft Zustand, schreibgeschützte Seitenenden, Ablehnungen, Stopps, Kontexte, Budgets und Gastcodeänderungen über seitenübergreifende RW/RX-Aliase. Nicht verfügbare KVM/WHP-Hosts werden ausdrücklich übersprungen.
Die native x64-Initialisierung von KVM/WHP/HVF führt X64MachineProbe.def in privaten Supervisor-Seiten aus. Eine gemeinsame Frist umfasst NOP, FP32-Addition mit Rundung gegen positive Unendlichkeit, SIMD-Addition mit zwei Lanes sowie FS/GS- und CS/SS/CR8-Lesezugriffe; jeder Schritt vergleicht den vollständigen Skalar-, XMM-, physischen x87- und Steuerzustand. x64- und ARM64-Proben benötigen das exklusive Ausführungsrecht des physischen Speichers. MemoryProjection besitzt die Cache-Identität (ISA, Adressraum, Mapping-Generation, Privileg und Monitorvariante) und den Verlauf bestätigter Wurzeln je ISA. Vor dem Überschreiben wird der Cache ungültig: fehlgeschlagener Ersatz darf keine teilweise geschriebenen Tabellen wiederverwenden, und Aufrufer liefern keine veralteten Wurzeln. Die Proben belegen nur die begrenzte Initialisierung. Die Workload-Validierung für Linux ARM64 KVM und Windows ARM64 WHP steht noch aus; native macOS-Ergebnisse sind im HVF-Leitfaden dokumentiert.
Der gemeinsame XSAVE-Decoder unterscheidet den initialen SSE-Zustand im Standard- und Kompaktformat. Bei gelöschtem XSTATE_BV[1] initialisieren beide XMM; das Standardformat liest und prüft weiterhin MXCSR, das Kompaktformat initialisiert MXCSR. X64XsaveCases.def enthält unabhängige Datenlayouts und eigene XRSTOR-Hostprogramme. X64XsaveTests.cpp prüft atomare Ablehnung und vergleicht beide Formate mit tatsächlicher Hostausführung unter Erhalt des FP/SSE-Zustands des Aufrufers. Fehlen die Hostarchitektur oder die benötigte Befehlsfunktion, wird der Hostvergleich ausdrücklich übersprungen.
X64FPState.def deklariert kompakte Transportlayouts für AVX, AVX-512, CET_U/CET_S und AMX einschließlich der Komponentenausrichtung auf 64 Byte. Vorhandene Erweiterungsdaten müssen dem Null-Initialzustand entsprechen; fehlende Komponenten und Füllbytes definieren keinen Zustand. Layoutbits bestimmen Offsets; unbekannte Layouts, nicht initiale Daten und falsche Längen scheitern vor der Veröffentlichung. CompactedOffsetsFollowLayoutRatherThanPresentBits, WideLayoutIgnoresAbsentComponentsAndAlignmentPadding, InitialCETComponentsDoNotHideFPState und InitialWideComponentsDoNotHideFPState prüfen WHP-Pakete mit 872 und 10752 Byte. Der Transport erlaubt keine Ausführung dieser Erweiterungsbefehle.
WhpXsaveRegisters.def ergänzt vollständige XSAVE-Pakete durch benannte x87/SSE-Steuerregister. Letzter Opcode sowie Instruktions- und Datenzeiger werden explizit geschrieben und vom Host gelesen. Leere Paketfelder können ergänzt werden; widersprüchliche Nichtnullwerte oder gemeinsame Steuerfelder führen vor der Veröffentlichung zum Fehler. NamedMetadataRestoresOmittedPacketFields prüft fehlende Felder unter Erhalt der gesamten FP-Nutzdaten.
Native FOP/FIP/FDP folgen den x87-Sicherungsregeln des Hosts. AMD darf diese Felder ohne ausstehende unmaskierte Ausnahme löschen; Snapshots behalten die beobachteten Werte. X64MachineProbe.def und exakte NOP/Kontexttests setzen einen konsistenten ausstehenden Ausnahmezustand, damit jedes Feld gültig bleibt und ohne ausgeblendete Unterschiede verglichen wird. Die FXRSTOR64/FXSAVE64-Referenz im Hostprozess prüft beide Zustände; Backends ersetzen Hostergebnisse niemals durch Eingabemetadaten.
Der gemeinsame Codec encodeX64XsaveState / decodeX64XsaveState besitzt Standard- und komprimierte FP/SSE-Pakete, die physische TOP-Rotation, Initialzustände fehlender Komponenten und atomare Prüfung. WHP verwendet vollständige XSAVE-APIs, bevorzugt WHvGetVirtualProcessorState / WHvSetVirtualProcessorState, mit älteren XSAVE-APIs als Kompatibilitätsweg. Einzelne ältere x87-Register ersetzen kein vollständiges Paket. Nicht initiale Erweiterungskomponenten, fehlerhafte Header, ungültige Steuerwerte und verkürzte Erfassungen scheitern ausdrücklich. WHP-Mappingfehler behalten HRESULT, GPA und Größe für die Diagnose.
CheckedX64Instructions.def erlaubt vorzeichenloses MUL mit 8/16/32/64 Bit und CBW/CWDE/CDQE/CWD/CDQ/CQO über den vorhandenen CPU-Transport. NeverDX64IntegerTests verwendet unabhängige Kodierungen und Erwartungswerte aus X64IntegerCases.def auf beiden Privilegstufen: Erhalt unveränderter Registerteile, 32-Bit-Nullerweiterung, beide Produkthälften, definierte CF/OF-Ergebnisse und unveränderte Flags bei Vorzeichenerweiterung. Multiplikation in gewöhnlichem RAM behält Rechteprüfungen für den gesamten Zugriffsbereich und Lese-Beobachter bei; ein Fehler oder Beobachterstopp erhält implizite Ausgaberegister und PC. Geräteoperanden bleiben nicht unterstützt. Die Fälle laufen auch mit checked Unicorn; nicht verfügbare native Transporte werden ausdrücklich übersprungen.
X64BitInstructions.def erlaubt BT/BTS/BTR/BTC für Register und gewöhnlichen RAM mit 16/32/64 Bit. Ein Registerindex wird in Operandenbreite vorzeichenbehaftet ausgewertet und wählt ein ganzes Wort; ein unmittelbarer Index bleibt im Basiswort. Die Kürzung auf die Adressbreite erfolgt vor dem Addieren der FS/GS-Basis. Der Prozessor liefert CF und Schreibwerte; RAMTransaction hält das Ergebnis bis zur Annahme durch die Beobachter zurück. Berechtigungen werden über den gesamten Bereich einschließlich separater Seiten und Aliase geprüft. Stopps, Callback-Fehler und verweigerte Zugriffe erhalten CPU und RAM. LOCK verlangt natürliche Ausrichtung; MMIO-Änderungen benötigen einen ausdrücklichen Anbieter vorbereiteter Atomics. X64BitStringTests.cpp vergleicht unabhängige Kodierungen mit echter x64-Ausführung und prüft negative Indizes, Breitenkürzung, Seitengrenzen, Abbruch und ungültige LOCK-Formen. Siehe die Intel-Befehlsreferenz.
X64StringInstructions.def definiert MOVS/STOS/LODS für normalen RAM mit 8/16/32/64 Bit; CLD/STD ändert nur das Richtungsflag. Jedes REP-Element prüft den gesamten Operanden vor Beobachteraufrufen und wird an einer Wiederaufnahmegrenze übernommen. Spätere Fehler erhalten fertige Elemente; Abbruch oder Callback-Ausnahme lässt das aktuelle Element unverändert. FS/GS wird erst nach Begrenzung der Adressbreite und nur zur Quelle addiert. AL/AX erhält obere Bits, EAX erweitert mit Nullen. Bei REP mit Zähler null und 32-Bit-Adressen müssen die oberen Zählerbits und für MOVS/STOS die oberen Bits der beteiligten Adressregister null sein: Reale Prozessoren liefern sonst unterschiedliche Ergebnisse. REPNE für MOVS/STOS/LODS und STOS/LODS-Geräteoperanden bleiben ausgeschlossen. X64StringTransferTests.cpp vergleicht Breiten, Richtung, Überlappung und Nullzähler mit unabhängigen Hostbefehlen und prüft Rechte, Aliasse, Adressumlauf, Fehler und Wiederaufnahme. Der originale WDK-Ressourcentreiber führt über driver_resource_strings.def alle vier STOS/LODS-Breiten aus.
X64StringInstructions.def definiert außerdem CMPS/SCAS auf normalem RAM mit 8/16/32/64 Bit und REPE/REPNE. Jedes Element prüft alle Leseoperanden vor Beobachtern, aktualisiert sechs arithmetische Flags und endet bei der ersten Abbruchbedingung. Ein Datenfehler stellt die Flags vom Beginn dieses ununterbrochenen REP wieder her; abgeschlossene Zeiger- und Zähleränderungen bleiben erhalten. Ein öffentlicher Wiedereinstieg beginnt mit dem veröffentlichten CPU-Zustand. Stopps und Beobachterausnahmen verändern das aktuelle Element nicht; nach vorzeitigem Ende wird das nächste Element nicht gelesen. FS/GS betrifft nur die CMPS-Quelle; SCAS bewahrt Akkumulator und ungenutztes Quellregister. Geräteoperanden und mehrdeutige obere Bits bei inaktivem 32-Bit-Zähler bleiben ausgeschlossen. X64StringComparisonTests.cpp vergleicht unabhängige Hostbefehle, Flags, Richtung, Aliase, Adressumlauf, Rechte und Wiederaufnahme; ein Linux-x64-Signaltest erfasst echte Fehlerregister. Der originale WDK-Ressourcentreiber führt beide bedingten Wiederholungen in allen vier Breiten über driver_resource_strings.def aus. Siehe Intel-Referenz. Das native Linux-Orakel prüft Fehler vor und nach dem ersten Element. Es unterscheidet Intels Wiederherstellung der Anfangsflags von den auf AMD EPYC 7763 unter Hyper-V beobachteten Flags des letzten Vergleichs (native Beobachtungen); unbekannte CPU-Hersteller führen zu einem ausdrücklichen Fehler. Checked-Gäste stellen auf allen Backends die Anfangsflags wieder her.
Bestehende WHP-CPUs teilen eine native Partition; endgültiges Schließen und erneutes Erstellen verwenden dieselbe Registersperre. WhpResourceCache.h verwendet den kooperativen VP 0 erneut; vor einem Wechsel der logischen CPU werden dieser VP und seine Abbildungen entfernt. Parallele CPUs behalten eigene VPs und GPA-Bereiche. Registerübertragungen, XSAVE und Abbruchanforderungen richten sich an den jeweiligen VP. x64 behält die standardmäßigen XSAVE-Funktionen des Hosts bei und prüft die tatsächliche Konfiguration mit WHvGetPartitionProperty. Die Ablaufplanung bleibt standardmäßig kooperativ.
CheckedBackend hält pro CPU einen Lesepuffer und einen cs_disasm_iter-Instruktionsdatensatz vor. Jeder Schritt liest die erlaubten Bytes neu und dekodiert sie erneut; dekodierte Ergebnisse werden nach Codeänderungen, Aliasänderungen oder Wiederaufnahme nicht weiterverwendet. Die Ausführungsberechtigung weist rekursive Aufrufe vor dem Zugriff auf den wiederverwendeten Speicher ab. So entfallen Allokationen pro Instruktion, während Beobachtung, Systemdienstabfang und genaue Fehlerbehandlung erhalten bleiben. Der Einzelschritt der festgelegten Unicorn-Version endet auch bei indirekter Übersetzungssuche vor dem Lesen der Folgeinstruktion und zählt interne Wiederholungen von Codeschreibzugriffen nicht als abgeschlossene Instruktionen.
WhpX64Processor.h verwaltet die Wiederverwendung von x64-WHP-Registern je virtuellem Prozessor. Feste Pakete nutzen WhpX64Registers.def und X64HostRegisters.def; jeder erfolgreiche Schritt erfasst weiterhin Allgemein-, Steuer- und Segmentregister sowie den vollständigen FP/SSE-Zustand. Nur vollständig bestätigte Debug-Ausgänge erlauben unveränderte Eingaben auszulassen. Vergleiche ignorieren reservierte Bits und Union-Füllbytes. Änderungen an CR3, CPL, TLS, Allgemein- oder FP-Eingaben werden installiert; Teilfehler, Abbruch und Ausnahmen verwerfen die Wiederverwendung. Neue VPs beginnen mit einer vollständigen Installation. Dies reduziert Übertragungen, erweitert weder den Befehlssatz noch belegt es eine durchgängige Beschleunigung.
WHP erfasst die x87/SSE-Metadaten aus WhpXsaveRegisters.def gemeinsam mit den gewöhnlichen Registern in einem Aufruf von WHvGetVirtualProcessorRegisters. Die angehaltene vCPU bleibt durch dieselbe Partitions-Lease geschützt. Vollständige XSAVE-Erfassung und alle Konsistenzprüfungen erfolgen weiterhin vor der Veröffentlichung. Pro Schritt entfällt ein Host-API-Aufruf; ein gemessener Durchsatzgewinn wird damit nicht behauptet.
CheckedAArch64Instructions.def und AArch64InstructionEffects erlauben in EL0/EL1 begrenzte Basis-FP32/FP64-Arithmetik, Vergleiche, Transfers und SIMD fester Breite. FPCR erhält vier Rundungsmodi, FZ und DN; FPSR erhält kumulative Zustände und QC. Nicht unterstützte Bits werden vor Änderungen abgelehnt. FP16-Arithmetik, SVE/SME, unmaskierte Ausnahmen, optionale Erweiterungen und nicht gelistete Formen schlagen ausdrücklich fehl. Windows-ARM64-Treiberladen und weitere OS-Umgebungen werden nicht hinzugefügt.
AArch64InstructionEffects besitzt skalare und FP/SIMD-RAM-Bereiche für einzelne und gepaarte Operanden bis 128 Bit. Der gemeinsame Adressraum prüft jede Seite vor Eintritt; RAMTransaction übernimmt nur vollständige deklarierte physische Schreibbereiche. Ein 128-Bit-Schreibbeobachter erhält vor Effekten zwei geordnete 64-Bit-Wörter. Stops und Fehler erhalten RAM, Vektoren und Writeback. Gleiche Xn/Vn-Nummern sind gültig; umlaufende Paarbereiche werden abgelehnt. NeverDAArch64MemoryTests verwendet unabhängige AArch64CrossPageCases.def und AArch64VectorMemoryCases.def.
KVM x64/ARM64 verwendet KvmRunControl für Vorbereitung, KVM_RUN und Zustandserfassung auf demselben privaten vCPU-Worker. Auch bei EINTR erfolgt die Vorbereitung einmal; Abbruch oder Lesefehler verhindern Veröffentlichung. KvmAArch64Machine.cpp führt Übersetzungspflege und vollständige Skalar-/Vektortransfers unter einer gemeinsamen Schrittfrist aus. Der Aufrufer veröffentlicht nach Bestätigung; ISA-Decodierung, RAM-Transaktionen, OS-Politik und Beobachter bleiben bei ihm. Native ARM64-Laufzeitnachweise stehen aus.
KVM vergleicht allgemeine Register und den vollständigen FP/SSE-Zustand anhand von X64HostRegisters.def und X64FPState.def mit der letzten bestätigten Debug-Erfassung und setzt geänderte Eingaben erneut. Host-Schreibzugriffe und Kontextwiederherstellung werden mitverglichen; Ausnahmen, Abbruch und Fehler verwerfen die Wiederverwendung. Einzelschrittsteuerung und Lesen des tatsächlichen allgemeinen/FP-Zustands erfolgen weiterhin für jede Instruktion.
Unter x64 fragt KVM KVM_CAP_SYNC_REGS ab und nutzt die unterstützten Sätze KVM_SYNC_X86_REGS und KVM_SYNC_X86_SREGS unabhängig. Ein bestätigtes KVM_RUN liefert die tatsächlichen Register über gemeinsamen Speicher; aufeinanderfolgende erfolgreiche Schritte können KVM_GET_REGS und KVM_GET_SREGS einsparen. Nicht unterstützte Sätze oder eine fehlgeschlagene optionale Abfrage behalten den ioctl-Pfad. Geänderte Eingaben werden weiterhin vor KVM_SET_GUEST_DEBUG installiert; gemeinsame Dirty-Bits bleiben null. Ausnahmen, Abbruch und Erfassungsfehler verwerfen die Wiederverwendung. Die vollständige FP/SSE-Erfassung bleibt Pflicht; unveränderte FP-Eingaben vermeiden erneutes XSAVE-Kodieren. Dies reduziert Übertragungsaufrufe, belegt aber keine durchgängige Beschleunigung. KVM-API.
Hardwareausführung allein garantiert keine geringere Gesamtlatenz. Die aktuelle native Ausführung führt Zulassungsprüfung, Beobachtung, Zustandsübertragung und VM-Austritt pro Instruktion aus. Vergleichen Sie dieselben ursprünglichen Images und Szenarien mit identischen Instruktions- und Ereignisbudgets und berichten Sie Ergebnisgleichheit zusammen mit Laufzeiten; zur CLI-Latenz gehören Start und Laden.
Geprüftes Unicorn verwendet MachineRunControl: Ein Zeitrahmen umfasst ARM64-Pflege, Gastausführung und vollständige Zustandserfassung. UC_HOOK_CODE prüft das geliehene Stopptoken und die Frist am Instruktionseingang. Der synchrone Engine-Aufruf gibt die Hook-Referenz vor seiner Rückkehr frei; der Maschinenschritt behält die Kontrolle bis zur Veröffentlichung. Unicorn und WHP erfassen den vollständigen CPU-Zustand zunächst privat und prüfen dieselbe Kontrolle vor Veröffentlichung eines erfolgreichen Schritts. WHP legt den Zeitrahmen einmal vor der Vorbereitung fest. Eine authentifizierte x64-CPU-Ausnahme hat Vorrang vor einem während der Erfassung eintreffenden Stop. Die geprüfte RAM-Transaktion verwirft bei abgebrochener Erfassung spekulative Schreibzugriffe; der uneingeschränkte Softwarevertrag bleibt unverändert. MachineInterruptedError trennt bestätigten Abbruch von Host- oder Erfassungsfehlern. Die gemeinsame geprüfte CPU liefert Stopped oder Deadline, erhält CPU/RAM und erlaubt einen erneuten Versuch; echte Fehler bleiben auch bei gleichzeitigem Stop BackendFailure.
RunDeadline::invoke weist einen bereits gestoppten oder abgelaufenen WHP-Eintritt vor dem Hostaufruf zurück, bewahrt bei Abbruch das tatsächliche Hostergebnis und bestätigt das Ende der Unterbrechungsrückrufe vor Freigabe des geliehenen Stopptokens. KVM und WHP prüfen das vollständig erfasste private Zustandspaket im aufrufenden Thread mit Ausführungsrecht, bevor sie einen gleichzeitigen Stopp oder Fristablauf einordnen. Tatsächliche Host- und Erfassungsfehler sowie authentifizierte x64-CPU-Ausnahmen behalten Vorrang. Ein gewöhnlicher Erfolgszustand bleibt bis zum Ende der Abbruchprüfung privat; eine bestätigte Unterbrechung verwirft spekulative CPU/RAM-Effekte und erlaubt einen neuen Versuch. Vorbereitung, native Ausführung und Erfassung teilen sich eine einzige Schrittfrist. Die Abbruchkontrolle ist kooperativ und garantiert keine harte Echtzeitgrenze.
hvf · Hypervisor.framework · Apple Silicon → ARM64 · Intel Mac → x86-64.
Setup, signing and native hardware validation (English)
Checked ARM64 unterstützt LDXR/STXR mit 8/16/32/64 Bit, Registerpaare LDXP/STXP mit 32/64 Bit, Acquire/Release-Varianten und CLREX. KVM, WHP und Checked Unicorn teilen einen ISA-Monitor mit physischen Reservierungsgranulen von 16 Byte; Einzelschritt-Ausstiege verhindern keinen Schleifenfortschritt. Bestätigte Schreibzugriffe invalidieren Reservierungen auch bei unveränderten Bytes, einschließlich Aliasen und gehaltenen Sichten. Stopps bewahren unveröffentlichte Zustände; Snapshots können zwischenzeitliche Schreibzugriffe nicht zurücknehmen. Checked-Exklusivzugriffe folgen FEAT_LSE2: nicht ausgerichtete Operanden innerhalb eines ausgerichteten 16-Byte-Blocks sind zulässig; das Überschreiten erzeugt alignment. Gleich breite bedingte Stores passen zum reservierten physischen Reservierungsbereich. Ausrichtung und Rechte werden vor dem Ergebnis des bedingten Speicherns geprüft, auch bei ungültiger Reservierung. Exklusive Befehle benötigen weiterhin gewöhnliche RAM. ARM64 Unicorn nutzt diesen Monitor auch im Vertrag Software, einschließlich gemeinsam genutzten physischen RAMs zwischen Software- und checked-CPUs. Unicorn behält im Vertrag Software das natürliche Ausrichtungsmodell seiner Engine bei.
Dieselbe ISA-Schicht unterstützt FEAT_LSE CAS/CASP, SWP, LDADD/LDCLR/LDEOR/LDSET sowie vorzeichenbehaftetes und vorzeichenloses Min/Max für Byte, Halbwort, Wort und Doppelwort einschließlich Acquire/Release. Checked verwendet die obige Ausrichtung; Unicorn Software behält natürliche Ausrichtung. Vergleiche beachten die Operandenbreite, zurückgegebene Altwerte werden nullerweitert. Ein erfolgloses CAS benötigt ebenfalls Schreibrechte und schreibt den Altwert zurück: Diese von Arm erlaubte Wahl invalidiert physische Reservierungen. Callbacks sehen den alten CPU/RAM-Zustand; Abbruch und synchrone Fehler veröffentlichen keine Teileffekte. Die Verträge für parallele CPUs und MMIO-Atomics definieren gleichzeitige Abschlüsse. MRS/MSR NZCV überträgt die vier Bedingungsflags gemäß den Regeln für reservierte Bits und das Nullregister. Leserechte werden zuerst geprüft: Ein nicht lesbarer Operand meldet einen Lesefehler, ein nur lesbarer Operand einen Schreibfehler, entsprechend den originalen Windows-ARM64-Beobachtungen.
Explizite CPU0-Präemption, virtuelle Zeit und Grenzen beschreibt Treiber-Scheduling.