Lingue: English | 简体中文 | 繁體中文 | 日本語 | 한국어 | Français | Deutsch | Español | Italiano | Русский | العربية
L’esecuzione CPU è indipendente dal sistema operativo guest, dal loader dell’immagine e dalla convenzione di chiamata. NEVERD_ENABLE_CPU_EMULATION la compila da sola; NEVERD_ENABLE_DRIVER_EMULATION include anche il modello dei driver Windows. La guida all’architettura descrive responsabilità, selezione del backend e limiti attuali delle piattaforme.
NEVERD_ENABLE_SEMANTIC_TESTS ha valore predefinito ON e controlla il gruppo in unittests/semantic e i relativi target aggregati. Per compilare i test CPU nativi senza Unicorn, mantenere BUILD_TESTING=ON e impostare NEVERD_ENABLE_SEMANTIC_TESTS=OFF e NEVERD_EMULATION_BACKEND_UNICORN=OFF. I test nativi KVM/WHP restano disponibili, anche con Windows ARM64/MSVC e gli header SDK appropriati. Abilitare Unicorn su Windows ARM64 richiede ancora una toolchain ARM64 LLVM-MinGW. Questa separazione della compilazione non dimostra l’esecuzione nativa ARM64.
La pubblica ExecutionConfiguration è usata sia dalla factory CPU sia dal report delle capacità. I requisiti sono verificati prima di allocare la CPU o collegare lo spazio degli indirizzi. Valori omessi usano il profilo fisso del contratto; valori espliciti non supportati causano errore.
| Campo JSON | Predefinito | Significato |
|---|---|---|
backend |
auto |
auto, unicorn, kvm oppure whp |
contract |
software-cpu-v1 |
Semantica di esecuzione versionata |
architecture |
x86_64 |
x86_64 o aarch64 |
privilege |
Profilo del contratto | flat, supervisor o user; deve corrispondere al contratto |
virtual_address_bits |
Profilo del contratto | I profili checked usano 48 bit; quelli flat uno spazio di mapping diretto a 64 bit |
page_size |
4096 | Granularità del mapping guest; gli altri valori sono rifiutati |
required_features |
[] |
Nomi richiesti da ExecutionConfiguration.def |
driver-strict accetta x64; software-cpu-v1 x64 e ARM64. checked-x64-v1 e checked-aarch64-v1 richiedono l’architettura indicata e privilegio supervisor. checked-user-x64-v1 e checked-user-aarch64-v1 eseguono l’inventario limitato corrispondente al contratto a CPL3 ed EL0, rispettivamente, con isolamento MMU e uscite esplicite di richiesta servizio. Supportano Unicorn e KVM/WHP compatibili con l’host; auto segue la selezione dell’host. direct-user-x64-v1 esegue l’inventario utente x64 su Unicorn o sul trasporto KVM/WHP con host corrispondente tra gli eventi architetturali anziché eseguirlo passo-passo, per carichi il cui avvio richiede miliardi di istruzioni. Non ammette nulla e non osserva né istruzioni né accessi alla memoria; solo le tabelle delle pagine dell’ospite forniscono l’isolamento CPL3. Il suo confine di servizio coincide con checked-user-x64-v1: l’estensione di chiamata di sistema resta disabilitata, quindi un’istruzione di servizio è l’evento di opcode indefinito all’indirizzo in cui l’ospite richiede il servizio, segnalato come lo stesso servizio in sospeso. L’esecuzione usa un budget di tempo, mai un budget di istruzioni o un quanto. Unicorn e KVM/WHP con host corrispondente lo implementano; HVF resta escluso. Unicorn adatta i propri hook di servizio allo stesso confine del PC originale e conserva lo stato CPU all’interruzione. Le sorveglianze di esecuzione restano in vigore: le loro pagine sono rese non eseguibili, così il primo fetch in un intervallo sorvegliato genera un fault allo stesso confine in cui si ferma una sorveglianza di istruzione checked. Lo spacchettamento guidato dall’osservazione recupera un ingresso tra confini di sorveglianza espliciti. I profili flat non promettono isolamento MMU utente/supervisor. I profili ARM64 e x64 checked ammettono le famiglie FP/SIMD limitate descritte sotto. x64 supervisor aggiunge transazioni MMIO limitate e letture stringa preparate; i profili user rifiutano mapping di dispositivi. L’I/O di porta resta escluso. Solo i profili user dichiarano service_traps.
ExecutionSession::watchMemoryWrites richiede l’invalidazione RAM dopo la conferma degli effetti dell’istruzione. Le CPU checked confrontano intervalli fisici; l’esecuzione diretta x64 può segnalare anche altre scritture nella stessa pagina fisica. Una notifica non prova che i byte siano cambiati e non addebita l’istruzione successiva. Fault guest e servizi pendenti mantengono priorità. Le sorveglianze seguono mapping e alias correnti; le CPU non compatibili rifiutano insiemi non vuoti. instructionSize ispeziona un’istruzione ferma con il decoder di esecuzione senza pubblicare un fault guest.
L’esecuzione user richiede UserAccessible oltre al diritto Read, Write o Execute appropriato su ogni pagina mappata. I mapping esistenti sono supervisor per default; gli alias hanno diritti indipendenti anche se condividono i byte fisici. UserAccessible da solo non autorizza l’accesso. Le operazioni host fidate e le CPU supervisor usano RWX. Esempio:
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));Il contratto fissa il privilegio: il ripristino del contesto e il binding dello spazio non lo modificano, e i selettori di segmento x64 non possono elevarlo. Un fault dati recuperabile conserva istruzione e registri originali finché il proprietario non lo gestisce. canAccess verifica esattamente i diritti richiesti; aggiungere UserAccessible per interrogare la visibilità user. Le page table sono proiezioni CPU private, non espongono tabelle guest mutabili né API per cambiare privilegio. Su ARM64 le pagine user non sono eseguibili anche a EL1.
Campi sconosciuti o nulli, nomi/larghezze numeriche non validi, feature richieste duplicate e combinazioni non supportate falliscono. L’input è limitato a 64 KiB; le vecchie factory CPU e le opzioni C dei driver restano compatibili.
Richiedere ExecutionFeature::ParallelCPUs (parallel_cpus) abilita CPU checked x64/ARM64 su thread host distinti con KVM, WHP o Unicorn e RAM fisica condivisa. Le istruzioni native provate senza scritture RAM possono sovrapporsi. Uno scrittore in attesa blocca nuove ammissioni e attende i lettori prima di pubblicare. Gli effetti sono sequenzialmente coerenti, con attese annullabili e rollback. Mappature e scritture host attendono la fine di tutte le esecuzioni. Solo stop() è sicuro tra thread sullo stesso oggetto CPU. L’esecuzione CPU resta cooperativa per impostazione predefinita; lo scheduling OS e l’esplorazione dei modelli di memoria debole sono contratti separati.
Le CPU WHP parallele usano VP indipendenti in una partizione condivisa, con un massimo di 31 CPU parallele simultanee oltre al VP cooperativo. Intervalli GPA e RAM di trasporto privati isolano le proiezioni; ARM64 usa ASID distinti e traduzioni non globali. Prima di ogni esecuzione nativa vengono copiati codice e operandi dichiarati; solo i byte di uscita dichiarati entrano nella transazione RAM condivisa. Gli osservatori leggono la RAM autorevole. KVM e checked Unicorn usano direttamente la memoria condivisa. HVF e il contratto Software di Unicorn non dichiarano questa capacità.
MMIOAtomics (mmio_atomics) richiede GuestMMIOCallbacks::PrepareAtomic. Supervisor x64 ammette scambi, confronti-scambi, aggiornamenti interi e modifiche di bit autorizzati; ARM64 ammette LSE, incluso CASP. Sono ammessi 1/2/4/8/16 byte naturalmente allineati. x64 calcola registri/FLAGS eseguendo l’istruzione originale in memoria privata; ARM64 riusa la semantica LSE comune. La preparazione non ha effetti; il commit verifica durata/versione e pubblica una sola volta. Arresti o errori precedenti preservano CPU/dispositivo; un commit riuscito prevale su un arresto concorrente. Nessun ripiego Read+Write. I banchi del kernel mantengono larghezze dichiarate di 1/2/4 byte e rifiutano anteprime obsolete dopo scritture identiche, cambi di alimentazione o distruzione. Trasferimenti ordinari e monitor esclusivi di dispositivi ARM64, MMIO utente e hardware arbitrario restano esclusi.
neverd cpu-capabilities
neverd cpu-capabilities \
--configuration='{"contract":"checked-aarch64-v1","architecture":"aarch64"}' \
--probe-hostLo schema è alla versione 1. Il report separa requested_configuration prima dei default di profilo, configuration normalizzata, capabilities semantiche statiche, build per supporto adapter/ABI e host (null senza --probe-host). Il probe inizializza una CPU temporanea su RAM privata: prova solo l’inizializzazione, non la compatibilità di workload arbitrari. La disponibilità può cambiare e un backend indisponibile non viene mai sostituito in silenzio. Il CLI restituisce 0 per un report valido anche se il backend non è disponibile, 1 per configurazione/query non valida.
neverd_cpu_capabilities_json accetta una sessione, JSON di configurazione facoltativo e ProbeHost 0 o 1; non serve un’immagine caricata. Liberare il risultato con neverd_free_string; NULL indica un errore descritto da neverd_last_error. Le build senza CPU esportano la stessa funzione e segnalano esplicitamente la disattivazione. I plugin Python usano session.cpu_capabilities(...). In C++ executionCapabilities, resolveExecutionConfiguration, queryExecutionBackendBuild e probeExecutionBackend sono separabili; createExecutionBackend collega una CPU a uno spazio esistente o crea RAM privata e spazio predefinito.
CPU.runUntilExit(PC, TimeoutMicroseconds) restituisce un ExecutionExit tipizzato. Errori di setup restituiscono llvm::Error; una run avviata segnala stop, deadline, service request, fault recuperabile, fault/trap guest, operazione non supportata, errore device/backend o stop del motore inspiegato. Fault CPU/device/backend prevalgono su stop/deadline simultanei, mantenendo i fatti e dettagli indipendenti. Il timeout deve essere positivo e rappresentabile sia come durata sia come deadline assoluta; altrimenti l’errore avviene prima di modificare la CPU. Ogni invocazione richiede un budget finito; zero non significa né infinito né timeout immediato valido. Il controllo è cooperativo, non una deadline rigida. Il risultato non consuma un fault recuperabile: il proprietario OS deve acquisirlo e installare un trasferimento d’eccezione validato prima di riprendere. Restano disponibili run, fault e timedOut; implementazioni CPU esterne che ridefiniscono solo run rifiutano il nuovo confine tipizzato.
Il profilo user-x64 intercetta solo la codifica esatta senza prefisso di SYSCALL; user-ARM64 intercetta SVC #imm16. SYSENTER, INT, HVC, BRK e altri meccanismi non sono supportati. L’observer delle istruzioni viene eseguito per primo. Se non ferma né causa un fault, la CPU restituisce ExecutionExitKind::ServiceRequest prima dell’istruzione o del backend, con tipo, PC originale, NextPC sequenziale e immediato SVC. Registri, flag, stack e privilegio restano invariati: x64 non ha applicato i clobber RCX/R11 di SYSCALL e ARM64 non è entrato in un exception vector. L’immediato SVC non è un numero servizio universale.
La richiesta resta pendente e blocca esecuzione, mutazione CPU, binding dello spazio e cattura/ripristino del contesto finché il proprietario OS la consuma una sola volta con takeServiceRequest() a CPU ferma. Il proprietario decodifica la ABI OS, gestisce il servizio e sceglie esplicitamente registri risultato e PC/trasferimento d’eccezione. Un servizio non supportato fallisce a quel confine; riprovare il PC originale genera un’altra richiesta, senza NOP o successo implicito. L’evento servizio prevale su stop/deadline simultanei, mentre fault guest/backend prevalgono su di esso. Stop CPU, HLT software, deadline o trap non provano il successo del workload. Il profilo processi Linux ha un modello OS separato e non prova compatibilità Windows, Android o Darwin. L’esecuzione nativa Windows/ARM64 richiede ancora validazione runtime.
Le descrizioni delle istruzioni x64 mascherate sono la base portabile. KVM/WHP aggiungono precise_simd_exceptions a driver-strict, checked-x64-v1 e checked-user-x64-v1: la verifica nativa iniziale controlla un #XM preciso e i due tentativi prima di consentire MXCSR non mascherato, LDMXCSR e ripristino Windows CONTEXT. ExecutionProfiles.def gestisce la selezione; supportsSIMDExceptions espone la capacità dell’istanza. Checked Unicorn resta mascherato; ARM64 e HVF non acquisiscono nuove capacità di eccezione.
KVM/WHP x64 nativi consegnano i veri fault #XM al C SEH dei driver tramite X64SIMDException. Il CONTEXT hardware conserva XMM0–15 e MXCSR. Filtri, finally durante lo svolgimento eccezionale e gestori selezionati eseguono con MXCSR 0x1f80 e DF azzerato. Un filtro negativo può modificare XMM e CONTEXT.MxCsr, limitato dalla maschera del CPU guest, e riprovare l’istruzione originale; FltSave.MxCsr non controlla il ripristino kernel. Le eccezioni delle API modellate conservano i campi interi/di controllo; le modifiche x87/AVX restano rifiutate.
Il profilo x64 checked ammette movimenti e logica SSE/SSE2 legacy limitati, MOVLHPS/MOVHLPS e forme scalari mascherate CVTTSS2SI/CVTTSD2SI/SUBSS/SUBSD. MXCSR conserva stato sticky, arrotondamento e FTZ; l’esecuzione portabile rifiuta le eccezioni non mascherate. KVM/WHP sincronizzano tutti i 16 registri XMM e MXCSR; codifiche e operandi non elencati restano esclusi.
Il profilo x64 checked ammette anche le forme legacy mascherate SS, SD, PS, PD di ADD, SUB, MUL, DIV, SQRT, MIN, MAX. X64SSEInstructions.def centralizza larghezze, allineamento e ammissione. MaskedSSEArithmeticMatchesIndependentHostExecution confronta registri/RAM con un riferimento CPU host indipendente: quattro arrotondamenti, FTZ, zeri con segno, subnormali e NaN. SSEMemoryObserverStopsBeforeResultAndStatusChanges verifica l’arresto prima degli effetti. x87 e AVX restano esclusi.
Nel profilo software portabile, Unicorn applica DAZ al valore selezionato dalle istruzioni classiche MINSS/MINSD/MINPS/MINPD e MAXSS/MAXSD/MAXPS/MAXPD. Un ingresso subnormale selezionato diventa zero con segno; i payload NaN e lo stato MXCSR esistente sono conservati. test_x86_sse_minmax_daz verifica le forme registro, RAM e registri coincidenti con DAZ attivo e disattivo, tutti gli arrotondamenti, FTZ e gli indicatori accumulati.
KVM/WHP rilevano MXCSR_MASK eseguendo privatamente FXSAVE64 e verificano DAZ con un calcolo su un subnormale con segno. Checked Unicorn fornisce la propria maschera software. supportedControlBits restituisce la maschera immutabile della CPU, condivisa da FX/XSAVE, snapshot e Windows CONTEXT. Le istruzioni checked LDMXCSR/STMXCSR accedono esattamente a m32, verificano l’intera area RAM e preservano lo stato in caso di errore o annullamento dell’osservatore. Caricare bit riservati genera #GP; l’esecuzione portabile rifiuta le eccezioni SIMD non mascherate. X64MXCSRTests.cpp verifica controlli e nuovi tentativi; X64DAZData confronta tutte le 28 forme aritmetiche SSE ammesse con le istruzioni originali dell’host con DAZ, arrotondamento e FTZ. Il supporto DAZ di HVF non viene ampliato.
La validazione iniziale x64 nativa usa un unico budget di 5 s, comprendente la preparazione a freddo del trasporto e tutti i passi di verifica. I budget di esecuzione del guest restano indipendenti. Un’interruzione riporta la fase dell’istruzione, stop_requested e deadline_reached, mantenendo il tipo di interruzione e la diagnosi del trasporto. Non si ritenta né si ammette una CPU validata solo in parte.
PAUSE (F3 90) viene eseguita tramite l’interfaccia x64 condivisa su KVM/WHP e Unicorn checked, incluso il contratto nativo driver-strict. X64PauseTests.cpp verifica la conservazione dell’intero stato, l’arresto prima dell’esecuzione, il ripristino del contesto, il rifiuto di un LOCK non valido e la scadenza e ripresa dei cicli di attesa attiva. Questo suggerimento al processore non pianifica i thread guest né garantisce un ritardo specifico.
PUSHFQ (9C) e PUSHF a 16 bit (66 9C) vengono eseguiti tramite KVM/WHP nativi e checked Unicorn, incluso driver-strict. Il livello ISA condiviso rimuove il TF interno di esecuzione passo per passo dall’immagine dello stack prima di confermare la transazione RAM. L’indirizzamento implicito usa RSP completo; l’ordine dei prefissi determina la larghezza. Permessi sull’intero intervallo, arresti degli osservatori e tentativi successivi a un fault preservano l’atomicità. X64PushFlagsTests.cpp copre le 256 combinazioni di flag ammesse, nove codifiche, alias tra pagine, permessi utente, annullamento e ripristino del contesto.
POPFQ (9D) e POPF a 16 bit (66 9D) ripristinano i flag nel livello ISA x64 condiviso per KVM, WHP e checked Unicorn, incluso driver-strict. Con IOPL fisso a zero, CPL0 può cambiare IF; CPL3 conserva IF e IOPL. I bit riservati e VM/VIF/VIP vengono ignorati e RF viene azzerato. Le modifiche effettive a TF, NT, AC, ID del guest o a IOPL in CPL0 restano non supportate e falliscono prima della pubblicazione. La lettura completa dello stack precede l’aggiornamento atomico di FLAGS/RSP/RIP; si usano RSP completo e l’ordine effettivo dei prefissi. Lo stack può essere in sola lettura o un alias di memoria eseguibile. Il completamento condiviso evita di cancellare il TF interno del trasporto. X64PopFlagsTests.cpp confronta istruzioni CPL3 native indipendenti e verifica ogni bit in ingresso, errori, osservatori ed esecuzione nativa successiva.
Checked x64 ammette CLC/STC/CMC e LAHF/SAHF. Le istruzioni di riporto usano il trasporto; i trasferimenti AH condividono una transizione ISA tra KVM, WHP e checked Unicorn, incluso driver-strict nativo. LAHF scrive cinque flag e i bit fissi in AH; SAHF modifica soltanto CF/PF/AF/ZF/SF. OF/IF/DF e gli altri registri restano invariati. I prefissi ignorati, inclusi tutti i valori REX, mantengono AH implicito. X64StatusFlagsTests.cpp verifica istruzioni originali, stato completo, annullamento e ripresa. Il traduttore Unicorn fissato conserva AH implicito con REX anche nel profilo portabile e rifiuta LOCK per queste cinque istruzioni prima di modificare lo stato.
Checked x64 esegue SHLD/SHRD tramite KVM, WHP e Unicorn con destinazioni a 16/32/64 bit e conteggi imm8 o CL. Applica la maschera architetturale; i conteggi indefiniti superiori a 16 per operandi a 16 bit sono rifiutati prima degli effetti. RAM usa controlli di lettura/scrittura della larghezza esatta e la transazione esistente: osservazione prima della pubblicazione e ripristino CPU/memoria in caso di annullamento. LOCK e operandi dispositivo restano esclusi.
X64ScalarShiftInstructions.def definisce gli effetti sulle destinazioni a 8/16/32/64 bit di SHL/SHR/SAR, ROL/ROR e RCL/RCR. Le forme registro e RAM accettano un conteggio implicito di 1, imm8 o CL, inclusi i conteggi azzerati dalla maschera e gli alias SAL. Le scritture RAM passano dai controlli dei permessi, dagli osservatori del risultato e dalla transazione condivisa; un arresto o un errore di callback ripristina CPU e memoria. KVM, WHP e Unicorn in modalità controllata condividono questo confine. Le forme LOCK e MMIO restano non supportate.
X64LoopInstructions.def ammette LOOP/LOOPE/LOOPNE tramite il trasporto del processore. La dimensione dell’indirizzo seleziona RCX o ECX esteso con zeri; FLAGS resta invariato. La larghezza della destinazione segue il modello CPU: Intel ignora 66H in modalità lunga, AMD conserva la selezione a 16 bit e REX.W ha precedenza. KVM/WHP nativi usano il processore host; Unicorn usa il modello Intel Haswell predefinito. Le regole comuni rifiutano LOCK e REP prima degli effetti, anche quando il decoder li omette.
X64BranchModel mantiene coerenti decodifica ed esecuzione di JMP/Jcc relativi. KVM/WHP nativi misurano salti 66H non presi e la precedenza di REX.W durante l’avvio con limite temporale; Unicorn controllato usa il proprio modello Intel. Il risultato immutabile seleziona il decoder per osservatori e politica dei driver Windows. In modalità lunga Intel conserva rel32 e l’intera larghezza delle destinazioni; AMD rispetta la modifica a 16 bit. Byte incompleti falliscono prima degli osservatori o dell’ingresso nel CPU.
X64StackInstructions.def ammette PUSH/POP a 16/64 bit con registri generali e RAM ordinaria, oltre a PUSH immediato su KVM, WHP e Unicorn controllato, incluso driver-strict. PUSH legge prima di decrementare RSP; POP calcola una destinazione basata su RSP/ESP dopo averlo incrementato. La limitazione della larghezza dell’indirizzo riguarda solo l’operando esplicito. Permessi sull’intero intervallo, osservazioni ordinate e un’unica transazione RAM preservano CPU e memoria in caso di errore, annullamento o callback fallita. LOCK e dispositivi restano esclusi.
KVM, WHP e checked Unicorn ammettono anche LEAVE a 16/64 bit. Il frame salvato viene letto tramite l’intero RBP, anche con 67H; la forma a 16 bit conserva i bit non selezionati di RBP. Fault e letture annullate conservano RSP originale e contesto CPU. LOCK, REP e frame nella memoria dei dispositivi restano non supportati.
KVM, WHP e checked Unicorn supportano ENTER a 16/64 bit: allocazione senza segno a 16 bit, annidamento modulo 32, RSP/RBP completi e ordine effettivo dei prefissi. Un fault guest conserva le scritture di stack completate, mentre RSP, RBP e PC mantengono i valori iniziali. Il controllo finale verifica i permessi di scrittura per l’intera larghezza dell’operando senza scrivere dati. LOCK, REP, prefissi APX e frame di dispositivi restano esclusi.
L'x64 controllato ammette il ritorno vicino a due byte F3 C3. I compilatori emettono il prefisso di ripetizione davanti a un ritorno che è destinazione di salto, e il processore lo ignora: l'istruzione è quindi il trasferimento C3 già ammesso, con la stessa lettura dello stack. Ogni altro ritorno con prefisso, compresi F2 C3, un secondo prefisso, un cambio di dimensione dell'operando e F3 C2 iw, resta fuori dal contratto. X64ReturnPrefixTests.cpp controlla KVM, WHP e Unicorn controllato.
X64PackedIntegerInstructions.def ammette 45 operazioni intere packed legacy SSE2: addizione/sottrazione modulare o saturata, confronti, moltiplicazione, medie, estremi, differenze di byte, packing e unpacking. Le sorgenti XMM e RAM a 128 bit allineate condividono il percorso checked di KVM, WHP e Unicorn. FLAGS e MXCSR restano invariati; errori e annullamenti degli osservatori preservano lo stato. MMX, VEX/EVEX e operandi di dispositivo restano esclusi.
X64PackedShiftInstructions.def ammette dieci scorrimenti packed SSE2 classici. Gli scorrimenti per elemento accettano conteggi imm8 o XMM/m128 allineati; quelli per byte solo imm8. I conteggi variabili usano i 64 bit inferiori senza segno, senza mascheratura scalare, ignorando i 64 superiori. Anche con zero o conteggi eccessivi, la lettura di memoria richiede tutti i 16 byte. FLAGS e MXCSR restano invariati; MMX, VEX/EVEX e gli operandi di dispositivo restano esclusi.
X64VectorOperands.def definisce forme complete degli operandi per trasferimenti, calcoli, scorrimenti, conversioni e maschere SSE classici. MOVMSKPS, MOVMSKPD e PMOVMSKB estraggono i bit di segno XMM in r32/r64 e azzerano gli altri bit della destinazione. KVM, WHP e checked Unicorn condividono queste regole; FLAGS, MXCSR e i registri sorgente restano invariati. Gli operandi in memoria delle maschere e le forme MMX e VEX/EVEX restano esclusi.
X64ShuffleInstructions.def aggiunge PSHUFD, PSHUFHW, PSHUFLW, SHUFPS e SHUFPD. X64VectorOperands.def richiede tre operandi completi: destinazione XMM, sorgente XMM o m128 allineata e imm8. Le istruzioni originali selezionano i bit delle lane senza modificare FLAGS o MXCSR. Le forme in memoria verificano tutti i 16 byte; gli errori di allineamento precedono le osservazioni dei dati. KVM, WHP e checked Unicorn condividono queste regole. Lo stesso inventario ammette UNPCKLPS, UNPCKHPS, UNPCKLPD e UNPCKHPD con esattamente due operandi. Interlacciano i bit degli elementi della destinazione originale e della sorgente. L’hardware può leggere solo i 64 bit selezionati; la RAM checked verifica l’operando m128 allineato.
MOVLPS, MOVHPS, MOVLPD e MOVHPD trasferiscono esattamente otto byte di RAM senza vincoli di allineamento. X64VectorInstructions.def dichiara la metà da scrivere; X64VectorOperands.def richiede una coppia XMM/m64. I caricamenti preservano gli altri 64 bit e gli osservatori delle scritture alte ricevono la metà superiore. KVM, WHP e checked Unicorn condividono i controlli dei permessi sull’intero intervallo e il ripristino della RAM. Le forme solo registro MOVHLPS/MOVLHPS mantengono la propria semantica.
CVTSI2SS e CVTSI2SD convertono interi con segno a 32/64 bit secondo l’arrotondamento MXCSR e preservano lo stato di precisione. La regola condivisa IntegerSource richiede una destinazione XMM e una sorgente r32/r64 o m32/m64. Le forme legacy preservano i 96/64 bit superiori; i controlli di memoria usano la larghezza intera. KVM, WHP e checked Unicorn eseguono l’istruzione originale. MMX e VEX/EVEX restano esclusi.
CVTSS2SI e CVTSD2SI producono interi con segno a 32/64 bit con arrotondamento MXCSR tramite la regola comune IntegerResult; CVTTSS2SI e CVTTSD2SI troncano sempre verso zero. Le conversioni mascherate di NaN o fuori intervallo restituiscono l’intero indefinito e impostano lo stato non valido; risultati validi inesatti impostano lo stato di precisione. Restano invariati i bit persistenti, FLAGS e le sorgenti XMM. Un risultato r32 azzera la metà superiore del GPR. La lettura RAM usa la larghezza della sorgente in virgola mobile indipendentemente dalla destinazione; FTZ non elimina gli ingressi subnormali. Le regole valgono per KVM, WHP e checked Unicorn.
COMISS, COMISD, UCOMISS e UCOMISD confrontano scalari XMM o m32/m64 tramite la regola comune Source. Impostano CF/PF/ZF, azzerano OF/SF/AF e preservano gli altri FLAGS e le sorgenti. COMIS segnala operazione non valida per ogni NaN; UCOMIS solo per NaN segnalanti. I NaN hanno priorità sullo stato denormale. I bit persistenti MXCSR sono preservati; arrotondamento e FTZ non cambiano il confronto. KVM, WHP e checked Unicorn condividono controlli esatti di memoria. Le funzioni di confronto della versione fissata di Unicorn riutilizzano la classificazione esistente degli ingressi denormali.
CMPSS, CMPSD, CMPPS e CMPPD eseguono gli otto predicati classici su KVM, WHP e checked Unicorn. La regola comune Source accetta gli alias decodificati; i controlli riservati restano esclusi. Le forme scalari preservano le corsie superiori e leggono m32/m64; quelle vettoriali richiedono m128 allineato. FLAGS e lo stato MXCSR esistente sono preservati, accumulando gli stati non valido/denormale per corsia attiva. Capstone gestisce ID di famiglia e condizioni SSE, sostituendo la correzione limitata al lifter. Unicorn classifica gli ingressi denormali in ogni funzione di confronto.
CVTSS2SD, CVTSD2SS, CVTPS2PD e CVTPD2PS convertono la precisione SSE classica tramite la regola comune Source. I risultati scalari conservano i 64/96 bit superiori. L’estensione vettoriale legge m64 e scrive due double; la riduzione legge m128 allineato, scrive due float e azzera i 64 bit superiori. Le istruzioni originali su KVM, WHP e checked Unicorn preservano FLAGS e accumulano gli stati MXCSR mascherati secondo arrotondamento e FTZ. Unicorn classifica ogni ingresso denormale attivo nelle funzioni di conversione. VEX/EVEX restano esclusi.
CVTDQ2PS e CVTDQ2PD convertono interi con segno a 32 bit tramite Source. La precisione singola legge m128 allineato con arrotondamento MXCSR; la doppia legge m64 anche non allineato ed è esatta. Tutto XMM destinazione viene sostituito; FLAGS e stato MXCSR restano invariati e i risultati singoli inesatti accumulano lo stato di precisione. KVM, WHP e checked Unicorn eseguono le istruzioni originali. Unicorn identifica entrambe le estensioni vettoriali per leggere otto byte. MMX e VEX/EVEX restano esclusi.
CVTPS2DQ e CVTPD2DQ usano l’arrotondamento MXCSR; CVTTPS2DQ e CVTTPD2DQ troncano verso zero. Source richiede m128 allineato o XMM. Una corsia NaN o fuori intervallo produce signed32 indefinite e stato non valido; le corsie valide inesatte aggiungono indipendentemente lo stato di precisione. Gli ingressi singoli danno quattro interi, i doppi due e azzerano i 64 bit superiori. FLAGS e MXCSR preesistente sono conservati; FTZ non scarta ingressi subnormali. KVM, WHP e checked Unicorn eseguono istruzioni originali. MMX e VEX/EVEX restano esclusi.
X64AlignmentTests.cpp verifica che gli operandi disallineati delle istruzioni aligned SSE ammesse segnalino un #GP(0) recuperabile o terminale prima di osservatori, controlli dei permessi o callback del dispositivo. L’intero contesto pubblico dei registri x64, PC e RAM rimane invariato. Il riporto alla larghezza dell’indirizzo precede l’aggiunta di FS/GS; correggere l’indirizzo consente di ritentare l’istruzione originale. Test diretti KVM/WHP verificano indipendentemente il confine hardware. Windows ring3 consegna i fault classificati operand_alignment; altre cause di #GP restano non supportate.
Il thread pointer copre FS/GS su x64 e TPIDR_EL0 su ARM64 con codifiche MRS/MSR esatte. Trasporti nativi e snapshot CPU preservano lo stato separatamente dalla memoria; non creano thread OS né blocchi TLS. x64 supervisor ammette transazioni MMIO scalari allineate da 1/2/4 byte e un elemento MOVS per confine di ripresa. Le letture dispositivo richiedono una preview pura e commit al massimo una volta. I profili user rifiutano mapping di dispositivi; RMW, MMIO largo e I/O di porta restano rifiutati.
KVM e WHP annullano gli ingressi nativi attivi e ne riconoscono l’annullamento prima di ritirare le risorse. KVM usa un thread privato e sblocca temporaneamente un segnale realtime; il segnale scelto non deve essere ignorato durante l’ingresso. Maschere e handler del chiamante non cambiano. Se il progresso guest è incerto, l’annullamento è terminale; non è garantita una deadline wall-clock rigida.
Le DIV/IDIV checked x64 usano risultati reali del processore e #DE. KVM usa una IDT/IST supervisor privata, WHP una bitmap esplicita; contesto originale e codici disponibili restano distinti dagli errori di trasporto. Il sistema operativo consuma l’evento recuperabile prima di impostare la continuazione. I driver Windows traducono divisione per zero e overflow del quoziente in STATUS_INTEGER_DIVIDE_BY_ZERO, eseguendo veri filtri SEH, __finally e tentativi successivi. NeverDX64ExceptionTests compila senza Unicorn; DriverWDMCPUException verifica casi WDK originali. Gli host ARM64 non disponibili sono saltati esplicitamente.
RAMTransaction conserva soltanto l’unione fisica delle scritture dichiarate di un’istruzione, sotto il blocco di esecuzione. Ripristina la RAM originale prima degli osservatori dei risultati; annullamento, errore di trasporto o eccezione dell’osservatore non pubblicano RAM o registri parziali. Dopo il ripristino della RAM, gli errori CPU mantengono lo stato architetturale di eccezione. Le scritture singole e doppie ARM64 usano la stessa autorità. x64 esegue XCHG, XADD e CMPXCHG a 8/16/32/64 bit, con allineamento naturale per forme bloccate o implicitamente bloccate. NeverDRAMTransactionTests confronta i risultati con la CPU host e verifica ripristino, alias e permessi; le piattaforme indisponibili sono saltate esplicitamente. Le atomiche dei dispositivi usano il loro provider; gli snapshot CPU non ripristinano la RAM già confermata.
CMPXCHG8B e CMPXCHG16B eseguono le istruzioni originali con KVM, WHP e checked Unicorn nei profili driver e utente. Il confronto richiede permessi di lettura e scrittura sia in caso di successo sia di insuccesso; i fault sono classificati come scritture. CMPXCHG16B verifica l’allineamento a 16 byte prima dell’accesso alla memoria e segnala #GP(0) se non è rispettato. Le due osservazioni del risultato condividono una transazione RAM: un arresto o un’eccezione in una delle due impedisce la pubblicazione di registri e RAM. CMPXCHG8B senza lock può attraversare pagine; gli operandi con lock richiedono ancora l’allineamento naturale. X64WideAtomicTests.cpp confronta i risultati originali dell’host e i fault nativi diretti e verifica alias, prefissi, indirizzamento, riparazione e annullamento. Le fixture originali del driver Windows e del PE ring3 eseguono entrambe le larghezze; quella WDK esegue anche _InterlockedCompareExchange128. Il modello CPU deve supportare CMPXCHG16B.
NeverDEmulationArch possiede i contratti ISA, le tabelle delle pagine e il formato FP condiviso dai trasporti nativi e Unicorn. I contesti x64 conservano controllo, stato, TOP, tag fisici, opcode, puntatori istruzione/dati e otto registri a 80 bit. FP0–FP7 usano RegisterValue; gli accessi scalari rifiutano il troncamento. FPTag è la maschera fisica dei registri non vuoti. NeverDX64FPTests verifica tutti i TOP, operazioni esatte contro FXSAVE/FXRSTOR dell’host e ripristino. Ciò non ammette istruzioni x87 nel contratto checked e non prova tutti gli arrotondamenti. Gli host nativi non disponibili vengono esplicitamente saltati.
driver-strict supporta KVM su host Linux x64 compatibili e WHP su host Windows x64 compatibili; auto sceglie quel trasporto nativo, mentre ISA diverse usano Unicorn. Unicorn esplicito e la precedente API V1 mantengono il profilo software portabile. L’esecuzione nativa verifica indirizzi canonici ed effetti prima dell’ingresso; hardware assente produce un errore senza ripiego. Istruzioni e comportamento OS non supportati falliscono esplicitamente. La CI nativa Windows x64 con Unicorn disattivato supera tutti i 359 controlli obbligatori: 131 controlli CPU, 224 risultati di driver da 26 immagini integrate, 46 immagini WDK e 40 casi di scenario alle basi preferite e rilocate, più quattro controlli dei limiti SEH (9d4c130c). Mancano prove native ARM64; non è stabilita la compatibilità universale dei driver o Android/Darwin.
Interrogare il profilo selezionato con executionCapabilities(Contract, ISA, Backend). NativeLegacyX64 descrive l’esecuzione nativa dei driver x64. NeverDNativeDriverTests verifica il corpus esistente e può essere eseguito anche in una compilazione senza Unicorn.
ARM64 checked usa un unico confine per lo stato completo. Registers.def definisce 39 campi scalari e 32 vettori da 128 bit; captureAArch64State prepara tutte le letture, applica le larghezze e normalizza NZCV prima di pubblicare una sola volta. Unicorn, KVM, WHP e HVF trasferiscono lo stesso inventario, inclusi TPIDR_EL0, TPIDRRO_EL0, TPIDR_EL1, FPCR e FPSR. Gli adattatori nativi abilitano FP/SIMD tramite CPACR_EL1. Letture fallite e ingressi annullati conservano tutto lo stato del chiamante.
L’avvio ARM64 KVM/WHP/HVF esegue il programma privato AArch64MachineProbe.def: NOP, somma FP32 arrotondata verso infinito positivo e somma SIMD a due lane. Ogni passo confronta tutti i 39 campi scalari e 32 vettori, inclusi TLS, NZCV, azzeramento dei bit superiori del risultato e stato FPCR/FPSR conservato/cumulativo. Il probe usa solo memoria del monitor supervisor e una scadenza globale. Le sonde verificano soltanto questa inizializzazione limitata. La validazione dei carichi Linux ARM64 KVM e Windows ARM64 WHP resta da completare; i risultati nativi macOS sono nella guida HVF. Il programma include anche la firma e l’autenticazione A/B degli indirizzi di ritorno con le chiavi disattivate e tutte e quattro le forme BTI su pagine non protette.
Il probe esegue anche due letture MRS CTR_EL0, oltre a DC CVAU, DSB ISH, IC IVAU e ISB, verificando geometria cache stabile e stato completo. Checked EL0/EL1 ammette le istruzioni originali, tutte le opzioni DSB di base con nome e solo ISB SY. CTR proviene dalla CPU virtuale scelta e può variare tra trasporti. I destinatari devono essere RAM ordinaria leggibile con i permessi correnti; indirizzi non allineati e alias sono ammessi, gli altri sono rifiutati come non supportati. La manutenzione non genera eventi di lettura/scrittura dati. La proiezione mantiene coerente l’esecuzione senza modellare cache private o SMP hardware parallelo. NeverDAArch64CacheTests verifica stato, fine pagina in sola lettura, rifiuti, arresti, contesti, budget e aggiornamenti del codice guest tramite alias RW/RX su due pagine. Gli host KVM/WHP non disponibili sono saltati esplicitamente.
L'inizializzazione nativa x64 KVM/WHP/HVF esegue X64MachineProbe.def in pagine supervisor private. Un'unica scadenza copre NOP, somma FP32 arrotondata verso infinito positivo, somma SIMD a due corsie e letture FS/GS e CS/SS/CR8; ogni passo confronta lo stato completo scalare, XMM, x87 fisico e di controllo. Le sonde x64 e ARM64 richiedono il diritto esclusivo di esecuzione della memoria fisica. MemoryProjection possiede l'identità della cache (ISA, spazio di indirizzi, generazione dei mapping, privilegio e variante del monitor) e la cronologia delle radici confermate per ISA. I costruttori invalidano prima di riscrivere: un aggiornamento fallito non riusa tabelle parziali e i chiamanti non forniscono radici obsolete. Le sonde verificano soltanto questa inizializzazione limitata. La validazione dei carichi Linux ARM64 KVM e Windows ARM64 WHP resta da completare; i risultati nativi macOS sono nella guida HVF.
Il decodificatore XSAVE condiviso distingue lo stato SSE iniziale standard e compatto. Con XSTATE_BV[1] azzerato, entrambi inizializzano XMM; il formato standard legge e valida comunque MXCSR, mentre quello compatto lo inizializza. X64XsaveCases.def fornisce disposizioni indipendenti e programmi XRSTOR host originali. X64XsaveTests.cpp verifica il rifiuto atomico e confronta entrambi i formati con l’esecuzione reale, preservando lo stato FP/SSE del chiamante. L’oracolo viene saltato esplicitamente se l’architettura o la funzionalità di istruzione richiesta non è disponibile.
X64FPState.def dichiara disposizioni compatte AVX, AVX-512, CET_U/CET_S e AMX, incluso l’allineamento dei componenti a 64 byte. I dati presenti devono rappresentare lo stato iniziale nullo; componenti assenti e riempimento non definiscono stato. I bit di disposizione determinano gli offset; disposizioni sconosciute, dati non iniziali o lunghezze errate falliscono prima della pubblicazione. CompactedOffsetsFollowLayoutRatherThanPresentBits, WideLayoutIgnoresAbsentComponentsAndAlignmentPadding, InitialCETComponentsDoNotHideFPState e InitialWideComponentsDoNotHideFPState coprono pacchetti WHP di 872 e 10752 byte. Il trasporto non ammette le istruzioni di tali estensioni.
WhpXsaveRegisters.def integra i pacchetti XSAVE completi con i registri di controllo x87/SSE nominati. L’ultimo opcode e i puntatori a istruzione/dati vengono scritti esplicitamente e letti dall’host. I campi nulli possono essere completati; conflitti non nulli o controlli comuni incoerenti falliscono prima della pubblicazione. NamedMetadataRestoresOmittedPacketFields verifica i campi omessi mantenendo tutti i dati FP.
I campi nativi FOP/FIP/FDP seguono le regole x87 dell’host. AMD può azzerarli senza un’eccezione pendente non mascherata; gli snapshot conservano i valori osservati. X64MachineProbe.def e i test esatti NOP/contesto impostano un’eccezione pendente coerente per confrontare ogni campo valido senza nascondere differenze. Il riferimento FXRSTOR64/FXSAVE64 nel processo host verifica entrambi gli stati; i backend non sostituiscono mai i risultati dell’host con metadati di ingresso.
Il codec condiviso encodeX64XsaveState / decodeX64XsaveState possiede pacchetti FP/SSE standard e compattati, rotazione TOP fisica, stato iniziale dei componenti assenti e validazione atomica. WHP usa le API XSAVE complete, preferendo WHvGetVirtualProcessorState / WHvSetVirtualProcessorState, con le API XSAVE precedenti come percorso compatibile. I singoli vecchi registri x87 non sostituiscono pacchetti completi. Componenti estesi non iniziali, intestazioni malformate, controlli invalidi e acquisizioni troncate falliscono esplicitamente. Gli errori di mapping WHP conservano HRESULT, GPA e dimensione per la diagnosi.
CheckedX64Instructions.def ammette MUL senza segno a 8/16/32/64 bit e CBW/CWDE/CDQE/CWD/CDQ/CQO tramite il trasporto CPU esistente. NeverDX64IntegerTests usa codifiche e valori attesi indipendenti di X64IntegerCases.def a entrambi i livelli di privilegio: conservazione parziale dei registri, estensione con zeri a 32 bit, entrambe le metà del prodotto, risultati CF/OF definiti e flag invariati per l’estensione del segno. La moltiplicazione nella RAM ordinaria conserva i controlli dei permessi sull’intero intervallo e gli osservatori di lettura; un errore o un arresto dell’osservatore preserva i registri di uscita impliciti e PC. Gli operandi di dispositivo restano non supportati. I casi vengono eseguiti anche con checked Unicorn; i trasporti nativi non disponibili vengono saltati esplicitamente.
X64BitInstructions.def ammette BT/BTS/BTR/BTC su registri e RAM ordinaria a 16/32/64 bit. L’indice di registro è interpretato con segno alla larghezza dell’operando e seleziona una parola intera; l’immediato resta nella parola di base. Il troncamento alla larghezza dell’indirizzo precede l’aggiunta della base FS/GS. Il processore fornisce CF e valori scritti; RAMTransaction mantiene privato il risultato finché gli osservatori lo accettano. I permessi vengono verificati sull’intero intervallo, incluse pagine allocate separatamente e alias. Arresti, errori dei callback e accessi negati preservano CPU e RAM. LOCK richiede allineamento naturale; le modifiche MMIO richiedono un provider esplicito di atomiche preparate. X64BitStringTests.cpp confronta codifiche indipendenti con l’esecuzione x64 reale e verifica indici negativi, troncamento, attraversamenti di pagina, annullamento e forme LOCK non valide. Vedere il riferimento Intel.
X64StringInstructions.def definisce MOVS/STOS/LODS sulla RAM ordinaria a 8/16/32/64 bit; CLD/STD modifica soltanto la direzione. Ogni elemento REP verifica l’intero operando prima dell’osservazione e conferma gli effetti a un confine di ripresa. Un errore successivo conserva gli elementi completati; arresti o eccezioni dei callback lasciano intatto l’elemento corrente. FS/GS si aggiunge soltanto alla sorgente, dopo il troncamento dell’indirizzo. AL/AX conserva i bit alti, mentre EAX estende con zeri. REP con conteggio nullo e indirizzi a 32 bit richiede bit alti nulli nel contatore e, per MOVS/STOS, negli indirizzi utilizzati: altrimenti i processori reali divergono. REPNE per MOVS/STOS/LODS e gli operandi di dispositivo STOS/LODS restano esclusi. X64StringTransferTests.cpp confronta larghezze, direzione, sovrapposizioni e conteggi nulli con istruzioni host indipendenti e verifica permessi, alias, riavvolgimento degli indirizzi, errori e ripresa. Il driver WDK originale delle risorse esegue tutte le quattro larghezze STOS/LODS tramite driver_resource_strings.def.
X64StringInstructions.def definisce anche CMPS/SCAS sulla RAM ordinaria a 8/16/32/64 bit con REPE/REPNE. Ogni elemento verifica tutte le letture prima degli osservatori, aggiorna sei flag aritmetici e termina alla prima condizione di uscita. Un errore dati ripristina i flag iniziali del REP ininterrotto, conservando puntatori e contatore degli elementi completati; una ripresa pubblica parte dallo stato CPU pubblicato. Arresti ed eccezioni degli osservatori non cambiano l’elemento corrente; l’uscita anticipata non legge il successivo. FS/GS riguarda soltanto la sorgente CMPS; SCAS conserva accumulatore e registro sorgente inutilizzato. Restano esclusi dispositivi e bit alti ambigui a conteggio nullo a 32 bit. X64StringComparisonTests.cpp confronta istruzioni host indipendenti, flag, direzione, alias, riavvolgimento, permessi e ripresa; l’oracolo Linux x64 cattura i registri al guasto reale. Il driver WDK originale esegue entrambe le ripetizioni condizionali nelle quattro larghezze tramite driver_resource_strings.def. Vedere il riferimento Intel. L’oracolo nativo Linux verifica i fault prima e dopo il primo elemento. Distingue il ripristino dei flags iniziali di Intel dai flags dell’ultimo confronto osservati su AMD EPYC 7763 con Hyper-V (osservazioni native); un produttore CPU sconosciuto causa un errore esplicito. I guest checked ripristinano i flags iniziali su tutti i backend.
Le CPU WHP esistenti condividono una partizione nativa; chiusura finale e ricreazione usano lo stesso blocco del registro. WhpResourceCache.h riutilizza il VP 0 cooperativo; il cambio di CPU logica rimuove prima quel VP e le sue mappature. Le CPU parallele mantengono VP e intervalli GPA separati. Ogni trasferimento di registri, operazione XSAVE e annullamento riguarda il proprio VP. x64 conserva le funzionalità XSAVE predefinite dell’host e verifica la configurazione effettiva con WHvGetPartitionProperty. La pianificazione resta cooperativa per impostazione predefinita.
CheckedBackend mantiene per CPU un buffer di lettura e un record di istruzione cs_disasm_iter. Ogni passo rilegge i byte autorizzati e li decodifica nuovamente; non riutilizza risultati decodificati dopo scritture del codice, modifiche degli alias o riprese. Il vincolo di esecuzione esclusiva rifiuta gli ingressi ricorsivi prima di accedere alla memoria riutilizzata. Si eliminano così le allocazioni per istruzione mantenendo osservazioni, intercettazione dei servizi di sistema e gestione precisa dei fault. Il passo singolo della versione fissata di Unicorn termina prima di leggere l’istruzione successiva, anche nella ricerca indiretta della traduzione, e non conta un tentativo interno ripetuto di scrittura del codice come istruzione completata.
WhpX64Processor.h gestisce il riuso dei registri x64 WHP per ogni processore virtuale. I pacchetti fissi usano WhpX64Registers.def e X64HostRegisters.def; ogni passo riuscito acquisisce tutti i registri generali, di controllo, di segmento e FP/SSE. Solo un’uscita di debug interamente confermata consente di omettere ingressi invariati. Il confronto ignora bit riservati e padding delle union. Le modifiche a CR3, CPL, TLS, registri generali o FP vengono installate; errori parziali, annullamenti ed eccezioni invalidano il riuso. Un nuovo VP richiede un’installazione completa. Si riducono i trasferimenti senza ampliare le istruzioni ammesse né affermare un’accelerazione complessiva.
WHP acquisisce i metadati x87/SSE di WhpXsaveRegisters.def insieme ai registri ordinari nella stessa chiamata a WHvGetVirtualProcessorRegisters. La vCPU ferma resta protetta dalla stessa lease della partizione. Acquisizione XSAVE completa e controlli di coerenza precedono ancora la pubblicazione. Si elimina una chiamata host per passo, senza dichiarare un incremento misurato delle prestazioni.
CheckedAArch64Instructions.def e AArch64InstructionEffects ammettono a EL0/EL1 aritmetica FP32/FP64 di base limitata, confronti, trasferimenti e SIMD a larghezza fissa. FPCR conserva quattro arrotondamenti, FZ e DN; FPSR conserva stato cumulativo e QC. I bit non supportati vengono rifiutati prima delle modifiche. FP16 aritmetico, SVE/SME, eccezioni non mascherate, estensioni opzionali e forme non elencate falliscono esplicitamente. Non aggiunge caricamento di driver Windows ARM64 o altri ambienti OS.
AArch64InstructionEffects possiede gli intervalli RAM scalari e FP/SIMD singoli o accoppiati, fino a 128 bit per operando. Lo spazio condiviso verifica ogni pagina prima dell’ingresso; RAMTransaction conferma solo scritture fisiche dichiarate complete. L’osservatore da 128 bit riceve due parole ordinate da 64 bit prima degli effetti. Stop e fault conservano RAM, vettori e aggiornamento dell’indirizzo. Lo stesso numero Xn/Vn è valido; le coppie con riavvolgimento dell’indirizzo sono rifiutate. NeverDAArch64MemoryTests usa AArch64CrossPageCases.def e AArch64VectorMemoryCases.def indipendenti.
KVM x64/ARM64 usa KvmRunControl per preparare, entrare in KVM_RUN e acquisire lo stato sullo stesso worker vCPU privato. La preparazione avviene una volta anche con EINTR; annullamento e lettura fallita impediscono la pubblicazione. KvmAArch64Machine.cpp esegue manutenzione delle traduzioni e trasferimenti scalari/vettoriali completi con una sola scadenza di passo. Il chiamante pubblica dopo conferma e mantiene decodifica ISA, transazioni RAM, politica OS e osservatori. Le prove native ARM64 restano mancanti.
KVM confronta i registri generali e lo stato FP/SSE completo con l’ultima acquisizione di debug confermata tramite X64HostRegisters.def e X64FPState.def, reinstallando gli ingressi modificati. Il confronto include scritture host e ripristini del contesto; eccezioni, annullamenti ed errori invalidano il riuso. Passo singolo e lettura dello stato generale/FP effettivo restano eseguiti per ogni istruzione.
Su x64, KVM interroga KVM_CAP_SYNC_REGS e usa separatamente gli insiemi supportati KVM_SYNC_X86_REGS e KVM_SYNC_X86_SREGS. Un KVM_RUN confermato restituisce i registri reali nella memoria condivisa; passi consecutivi riusciti possono evitare KVM_GET_REGS e KVM_GET_SREGS. Gli insiemi non disponibili o una query facoltativa fallita mantengono il percorso ioctl. Gli ingressi modificati vengono ancora installati prima di KVM_SET_GUEST_DEBUG; i bit dirty condivisi restano a zero. Eccezioni, annullamenti e acquisizioni fallite invalidano il riuso. La cattura FP/SSE completa resta obbligatoria; ingressi FP invariati evitano una nuova codifica XSAVE. Ciò riduce le chiamate di trasferimento, senza dimostrare un miglioramento complessivo della velocità. API KVM.
L’esecuzione hardware da sola non garantisce una latenza complessiva inferiore. L’esecuzione nativa attuale effettua ammissione, osservazione, trasferimento di stato e uscita VM per ogni istruzione. Confrontare le stesse immagini e gli stessi scenari originali con budget identici di istruzioni ed eventi e riportare la corrispondenza dei risultati insieme ai tempi; includere avvio e caricamento nella latenza CLI.
Unicorn verificato usa MachineRunControl: un unico margine copre manutenzione ARM64, esecuzione guest e acquisizione completa dello stato. UC_HOOK_CODE controlla il token di arresto preso in prestito e la scadenza all’ingresso dell’istruzione. La chiamata sincrona rilascia il riferimento del hook prima del ritorno, ma il passo macchina conserva il controllo fino alla pubblicazione. Unicorn e WHP preparano tutto lo stato CPU e verificano lo stesso controllo prima di pubblicare un passo riuscito. WHP crea il margine una sola volta prima della preparazione. Un’eccezione CPU x64 autenticata ha precedenza su un arresto ricevuto durante l’acquisizione. La transazione RAM verificata scarta scritture speculative quando l’acquisizione è annullata; il contratto software non limitato resta invariato. MachineInterruptedError distingue un annullamento confermato da un errore host o di acquisizione. La CPU verificata condivisa restituisce Stopped o Deadline, conserva CPU/RAM e consente il tentativo successivo; i veri errori restano BackendFailure anche con un arresto simultaneo.
RunDeadline::invoke rifiuta un ingresso WHP già arrestato o scaduto prima della chiamata host, conserva il risultato host effettivo durante l'annullamento e conferma la fine dei callback di interruzione prima di rilasciare il token preso in prestito. KVM e WHP convalidano lo stato privato interamente acquisito sul thread chiamante titolare del diritto di esecuzione, prima di classificare un arresto o una scadenza simultanei. Gli errori effettivi dell'host o dell'acquisizione e le eccezioni CPU x64 autenticate mantengono la priorità. Uno stato ordinario riuscito rimane privato fino alla fine dei controlli di annullamento; un'interruzione confermata scarta gli effetti CPU/RAM speculativi e permette un nuovo tentativo. Preparazione, esecuzione nativa e acquisizione condividono una sola tolleranza per passo. Il controllo è cooperativo e non garantisce un limite rigido di tempo reale.
hvf · Hypervisor.framework · Apple Silicon → ARM64 · Intel Mac → x86-64.
Setup, signing and native hardware validation (English)
ARM64 checked supporta LDXR/STXR a 8/16/32/64 bit, coppie LDXP/STXP a 32/64 bit, varianti acquire/release e CLREX. KVM, WHP e Unicorn checked condividono un monitor ISA con prenotazioni fisiche di 16 byte; le uscite per passo singolo non bloccano i cicli. Le scritture confermate invalidano le prenotazioni anche senza cambiare i byte, inclusi alias e viste conservate. Gli arresti preservano lo stato non pubblicato; gli snapshot non annullano le scritture intermedie. Gli esclusivi checked seguono FEAT_LSE2: ammettono operandi non allineati entro un blocco allineato di 16 byte; attraversarlo produce alignment. Gli store della stessa larghezza corrispondono al granulo fisico prenotato. Allineamento e permessi sono verificati prima del risultato della scrittura condizionale, anche con prenotazione scaduta. Le istruzioni esclusive richiedono ancora RAM ordinaria. Unicorn ARM64 usa questo monitor anche nel contratto Software, inclusi CPU software e checked che condividono la RAM fisica. Il contratto Software di Unicorn mantiene l’allineamento naturale del motore.
Lo stesso livello ISA supporta FEAT_LSE CAS/CASP, SWP, LDADD/LDCLR/LDEOR/LDSET e min/max con o senza segno, per byte, mezza parola, parola e doppia parola e varianti acquire/release. Checked usa l’allineamento sopra descritto; Unicorn Software mantiene quello naturale. Il confronto rispetta la larghezza e i vecchi valori restituiti sono estesi con zeri. Un CAS fallito richiede comunque permessi di scrittura e riscrive il vecchio valore, scelta ammessa da Arm che invalida le prenotazioni fisiche. I callback vedono lo stato CPU/RAM precedente; annullamenti ed errori sincroni non pubblicano effetti parziali. I contratti seguenti di CPU parallele e atomiche MMIO definiscono il commit concorrente. MRS/MSR NZCV trasferisce i quattro flag rispettando bit riservati e registro zero. Si verifica prima il permesso di lettura: un operando illeggibile produce un errore di lettura, uno di sola lettura un errore di scrittura, come nelle osservazioni originali Windows ARM64.
Prelazione esplicita su CPU0, tempo virtuale e limiti sono descritti nello scheduling dei driver.