Traduzione indirizzi virtuali in indirizzi fisici

[71104]

Supponiamo di trovarci in una piattaforma Windows (NT-based) e che in un certo momento in un certo processo sia allocata una pagina di memoria virtuale, leggibile, scrivibile e senza nessun page guard impostato. supponiamo anche che in un momento in cui la pagina è residente (cioè si trova in memoria fisica) il processo tenti di accedere ad una sua locazione, in lettura o in scrittura a vostra scelta. in una tale situazione, secondo voi, l'HAL (Hardware Abstraction Layer) di Windows o qualche altro componente del sistema operativo sono tenuti a fare una qualsiasi operazione? durante questa operazione di accesso in memoria, viene eseguita una qualsiasi riga di codice del sistema operativo, in particolare qualche parte di codice relativa alla traduzione da indirizzi virtuali ad indirizzi fisici? e in caso di risposta affermativa, tali operazioni vengono eseguite anche al fetch di ogni singola istruzione di codice del programma?

mi scuso con l'utente ekerazha se ho mal posto la questione (si tratta di una nostra discussione proveniente da altrove che stiamo spostando qui).

[andbin]

Originariamente inviato da 71104

Supponiamo di trovarci in una piattaforma Windows (NT-based) e che in un certo momento in un certo processo sia allocata una pagina di memoria virtuale, leggibile, scrivibile e senza nessun page guard impostato. supponiamo anche che in un momento in cui la pagina è residente (cioè si trova in memoria fisica) il processo tenti di accedere ad una sua locazione, in lettura o in scrittura a vostra scelta. in una tale situazione, secondo voi, l'HAL (Hardware Abstraction Layer) di Windows o qualche altro componente del sistema operativo sono tenuti a fare una qualsiasi operazione? durante questa operazione di accesso in memoria, viene eseguita una qualsiasi riga di codice del sistema operativo, in particolare qualche parte di codice relativa alla traduzione da indirizzi virtuali ad indirizzi fisici? e in caso di risposta affermativa, tali operazioni vengono eseguite anche al fetch di ogni singola istruzione di codice del programma?

No, se la pagina virtuale è mappata ad una pagina fisica, il S.O. non interviene in alcun modo durante l'accesso alla memoria.

Sui processori x86 che operano in modalità protetta le cose funzionano così: il selettore (che fa riferimento ad un descrittore di segmento) viene usato insieme all'offset a 32 bit per comporre un indirizzo lineare. Se il sistema di paging è disabilitato, l'indirizzo lineare è già a tutti gli effetti l'indirizzo fisico.

Quando il sistema di paging è attivato, le cose cambiano un pochino. Una pagina ha tipicamente una dimensione di 4 KByte (anche se sui x86 si possono avere pagine da 2MB o 4MB).
L'indirizzo lineare è suddiviso in 3 parti: Directory, Table e Offset. Senza entrare nei dettagli (si veda la documentazione Intel), tramite una serie di tabelle organizzate su 2 livelli, il processore è in grado di convertire l'indirizzo lineare in un indirizzo fisico.

Il nocciolo di tutta la gestione del paging è 1 bit che è presente nelle entry di queste tabelle. Se il bit di 'Present' indica che la pagina è mappata in memoria fisica, l'accesso è immediato da parte del processore e non richiede l'intervento di alcun altro componente hardware/software. Se il bit indica che la pagina non è presente, allora viene generata una eccezione di Page-Fault (#PF). A quel punto è esclusivamente compito del S.O. gestire la cosa: dovrà certamente caricare la pagina dal file di swap, scegliere una pagina fisica in cui metterla, risistemare le entry nelle tabelle, invalidare nella TLB la entry della pagina e quindi alla fine, riavviare l'istruzione che ha generato il #PF.

[71104]

bene bene, concordo al 100%
aspetto solo che quel troll ignorante di ekerazha legga
grazie andbin.

[h1jack3r]

Provo a rispondere, vediamo se ho ben capito la domanda.
Se un processo ha allocata della memoria (non importa se fisica o virtuale), a quello spazio può accedere solo quel processo.
Quando si swappa dal processo A al processo B il sistema operativo si preoccperà di salvare i registri contenuti nel processore relativi al processo A, per poter poi ritornare all'esecuzione del processo A quando sarà il caso.
Mettiamo caso che ora sul processore stia girando il processo B.
La fase di decodifica degli indirizzi avviene a livello HW, dato la complessità delle operazioni e la quantità richiesta.
Se il processo B chiede di accedere ad un indirizzo riservato al processo A si scatena un interrupt e il controllo passa al Kernel del sistema operativo che genera un'eccezione.
In sostanza il processore non sa se una locazione di memoria è in memoria fisica o in swap, lui cerca comunque in memoria fisica, se non è presente è il sistema operativo che prende il controllo e trasferisce quella porzione di dati in memoria fisica.

[71104]

Originariamente inviato da h1jack3r

Se il processo B chiede di accedere ad un indirizzo riservato al processo A si scatena un interrupt e il controllo passa al Kernel del sistema operativo che genera un'eccezione.

1) un processo non può tentare di accedere ad una locazione di memoria di un altro processo: a ciascun processo sono assegnati 2 (a volte 3) GB di memoria virtuale, di cui una minima parte è allocata; qualsiasi indirizzo un programma tenti di leggere o scrivere farà sicuramente parte del suo spazio di indirizzamento, non di quello di un altro processo.

2) un'eccezione non richiede uno switch in kernel-mode, o almeno non mi risulta

[71104]

Originariamente inviato da 71104

qualsiasi indirizzo un programma tenti di leggere o scrivere farà sicuramente parte del suo spazio di indirizzamento, non di quello di un altro processo.

aggiungo: al massimo potrebbe non far parte di quei 2 o 3 GB, nel qual caso sarebbe un indirizzo che si riferisce al kernel space, ma di certo non allo spazio di indirizzamento di un altro processo.

[h1jack3r]

era da prendere con le pinze
non avevo visto che Andbin aveva già ampiamente risposto alla domanda.

Originariamente inviato da andbin

No, se la pagina virtuale è mappata ad una pagina fisica, il S.O. non interviene in alcun modo durante l'accesso alla memoria.

Quindi stai dicendo che su piattaforma Windows NT-based, un eventuale applicazione avrebbe accesso diretto alla memoria centrale senza "passare" dal sistema operativo?

Tratto da "Finnel, Lynn (2000). MCSE Exam 70-215, Microsoft Windows 2000 Server. Microsoft Press. ISBN 1-57231-903-8" (riportato su Wikipedia):

The architecture of Windows NT is highly modular and consists of two main layers: a user mode and a kernel mode. Programs and subsystems in user mode are limited in terms of what system resources they have access to, while the kernel mode has unrestricted access to the system memory and external devices. The kernels of the operating systems in this line are all known as hybrid kernel, although this term is disputed, with the claim that the kernel is essentially a monolithic kernel that is structured somewhat like a microkernel. The architecture comprises a hybrid kernel, hardware abstraction layer (HAL), drivers, and a range of services (collectively named Executive), which all exist in kernel mode.

Aggiungo anche uno schemino che sembra piuttosto intuitivo: http://en.wikipedia.org/wiki/Image:W...chitecture.svg

[The3DProgrammer]

no, sta dicendo che la cpu è in grado di interpretare autonomamente un eventuale linear address se la pagina è caricata in memoria (cioè nn è richiesto swap). Nel caso di page fault, allora il sistema operativo deve intervenire come tutti sappiamo.

ciauz

Originariamente inviato da The3DProgrammer

no, sta dicendo che la cpu è in grado di interpretare autonomamente un eventuale linear address se la pagina è caricata in memoria (cioè nn è richiesto swap). Nel caso di page fault, allora il sistema operativo deve intervenire come tutti sappiamo.

ciauz

Quindi rimane il fatto che su piattaforma con architettura NT-based, una applicazione per effettuare operazioni sulla memoria deve passare attraverso il sistema operativo?

[ilsensine]

Originariamente inviato da 71104

2) un'eccezione non richiede uno switch in kernel-mode, o almeno non mi risulta

[se per eccezione intendi "page fault"] Sì invece, chi vuoi che procuri al processo la pagina che manca?

[ilsensine]

Originariamente inviato da ekerazha

Quindi stai dicendo che su piattaforma Windows NT-based, un eventuale applicazione avrebbe accesso diretto alla memoria centrale senza "passare" dal sistema operativo?

Il sistema operativo provvede a scegliere e procurare le pagine fisiche e mapparle negli indirizzi lineari del processo; fatto questo, la pagina _è_ del processo e ci accede tramite l'MMU -- il lavoro del s/o è finito.

[The3DProgrammer]

Ma nn ho capito bene, che intendi per operazioni sulla memoria?

Allocazione/deallocazione?


O, come avevo capito prima, si vuole chiarire se ad es in un'istruzione tipo mov eax,00FFAxxh (indirizzo a ca@@) interviene anche il sistema operativo nella traduzione di quell'indirizzo?

[The3DProgrammer]

Ecco mentre scrivevo forse ilsensine ha chiarito la questione

ciau

[andbin]

Originariamente inviato da ekerazha

Quindi stai dicendo che su piattaforma Windows NT-based, un eventuale applicazione avrebbe accesso diretto alla memoria centrale senza "passare" dal sistema operativo?

Sì e se hai letto la mia spiegazione tecnica sopra, capisci anche il perché. Il processore esegue le istruzioni e sempre il processore, grazie a quel sistema di paging descritto, determina autonomamente, prima di tutto, se la pagina è mappata in memoria fisica o no.

Originariamente inviato da ekerazha

Tratto da "Finnel, Lynn (2000). MCSE Exam 70-215, Microsoft Windows 2000 Server. Microsoft Press. ISBN 1-57231-903-8" (riportato su Wikipedia):

Programs and subsystems in user mode are limited in terms of what system resources they have access to, while the kernel mode has unrestricted access to the system memory and external devices.

Aggiungo anche uno schemino che sembra piuttosto intuitivo: http://en.wikipedia.org/wiki/Image:W...chitecture.svg

Tutto ciò è solo per descrivere il fatto che sui moderni sistemi operativi ci possono essere diversi livelli di privilegio. Sui processori x86 tecnicamente ci sono 4 livelli (o "ring" come sono chiamati): 0 (il più alto), 1, 2 e 3 (il più basso).
Concettualmente in genere ne bastano solo due: User e Supervisor (in altri processori come i Motorola in effetti ce ne sono solo 2 di livelli, appunto quelli appena menzionati).

Questo significa solamente che in modalità supervisor è possibile eseguire tutte le istruzioni che si vuole, pure quelle "privilegiate" e accedere a qualunque locazione di memoria indirizzabile. In modalità user invece non è possibile eseguire istruzioni privilegiate e non è possibile accedere a zone di memoria che il codice in modalità supervisor ha chiaramente marcato come non accessibili dal livello user.

Originariamente inviato da The3DProgrammer

no, sta dicendo che la cpu è in grado di interpretare autonomamente un eventuale linear address se la pagina è caricata in memoria (cioè nn è richiesto swap). Nel caso di page fault, allora il sistema operativo deve intervenire come tutti sappiamo.

Esatto.

Originariamente inviato da andbin

Sì e se hai letto la mia spiegazione tecnica sopra, capisci anche il perché. Il processore esegue le istruzioni e sempre il processore, grazie a quel sistema di paging descritto, determina autonomamente, prima di tutto, se la pagina è mappata in memoria fisica o no.

Si, però come ha detto "ilsensine" (se non ho frainteso) ciò avviene comunque a posteriori di quella che è una chiamata dell'applicazione al sistema operativo.

Per andare sul banale: se nella mia applicazione ho una malloc() o una realloc() (o qualcosa di simile) la chiamata deve comunque passare dal sistema operativo o no?

Detto questo, devo fare una parziale rettifica in quanto pensavo che il sistema operativo intervenisse sempre durante l'accesso alla MMU e non che su x86 la cosa venisse gestita direttamente dalla CPU.

[ilsensine]

Originariamente inviato da ekerazha

Si, però come ha detto "ilsensine" (se non ho frainteso) ciò avviene comunque a posteriori di quella che è una chiamata dell'applicazione al sistema operativo.

Per andare sul banale: se nella mia applicazione ho una malloc() (o qualcosa di simile) la chiamata deve comunque passare dal sistema operativo o no?

I dettagli sono un pò più complicati di quello che sembra.

Innanzitutto, le chiamate al s/o non servono per allocare memoria; smetti di pensare in termini di "memoria" e pensa in termini di "indirizzi virtuali". La malloc non ritorna memoria (lo faceva ai tempi del DOS), ritorna indirizzi virtuali. Per far questo, occorre sì una chiamata al s/o -- chi vuoi che abbia i diritti per manipolare le tabelle di pagine? (chiamate comunque ottimizzate e ridotte tramite una gestione di un heap in user space).
Solo quando accedi alle pagine il s/o si pone il problema di fornirti la pagina di memoria, ma lo fa in maniera trasparente tramite la gestione dei page fault.
Fatto questo, la pagina è tua -- per il momento. Può accadere che il s/o si "riprenda" la pagina (mettendo il contenuto in swap, durante il page reclaim o per "anzianità"), oppure che il contenuto venga spostato su una pagina fisica diversa da quella inizialmente assegnata (perché ad es. un driver sta richiedendo una serie di pagine fisicamente continue per operazioni dma). Questo avviene su tutti i s/o che utilizzano l'mmu.
Una volta però che la pagina fisica è associata ai tuoi indirizzi virtuali, ripeto, il s/o è come se non esistesse, puoi utilizzarla liberamente senza impatti prestazionali.

[andbin]

Originariamente inviato da ekerazha

Per andare sul banale: se nella mia applicazione ho una malloc() (o qualcosa di simile) la chiamata deve comunque passare dal sistema operativo o no?

Stiamo parlando di cose diverse: una cosa è la traduzione da un indirizzo virtuale a un indirizzo fisico e un'altra cosa è la chiamata di determinati servizi di sistema.

Ora ... malloc è solo una funzione della libreria standard del "C". Non so esattamente cosa faccia (dipende dalla implementazione). Su Windows posso solo presumere che chiami una delle API Win32 per la allocazione di memoria, che a sua volta chiamerà presumibilmente funzioni kernel-mode per fare quello che serve per allocare la memoria nel processo.

Originariamente inviato da andbin

Stiamo parlando di cose diverse: una cosa è la traduzione da un indirizzo virtuale a un indirizzo fisico e un'altra cosa è la chiamata di determinati servizi di sistema.

Ora ... malloc è solo una funzione della libreria standard del "C". Non so esattamente cosa faccia (dipende dalla implementazione). Su Windows posso solo presumere che chiami una delle API Win32 per la allocazione di memoria, che a sua volta chiamerà presumibilmente funzioni kernel-mode per fare quello che serve per allocare la memoria nel processo.

Originariamente inviato da ilsensine

I dettagli sono un pò più complicati di quello che sembra.

Innanzitutto, le chiamate al s/o non servono per allocare memoria; smetti di pensare in termini di "memoria" e pensa in termini di "indirizzi virtuali". La malloc non ritorna memoria (lo faceva ai tempi del DOS), ritorna indirizzi virtuali. Per far questo, occorre sì una chiamata al s/o -- chi vuoi che abbia i diritti per manipolare le tabelle di pagine? (chiamate comunque ottimizzate e ridotte tramite una gestione di un heap in user space).

Esatto... questo intendevo quando dicevo che l'applicazione, su piattaforma NT-based, non accede direttamente alla memoria ma passa dal sistema operativo.

[...]
Una volta però che la pagina fisica è associata ai tuoi indirizzi virtuali, ripeto, il s/o è come se non esistesse, puoi utilizzarla liberamente senza impatti prestazionali.

Questo invece è il particolare punto sul quale ho parzialmente rettificato, in quanto, indipendentemente da quanto scritto sopra, pensavo erroneamente che il sistema operativo intervenisse anche ad ogni accesso alla MMU.