À qui appartient cette adresse physique ?

(désolé pour le titre du sujet, je n'ai pas réussi à trouver quelque chose de plus parlant)

Bonjour à tous,

J'ai une petite question toute bête sur un détail auquel je n'ai pas encore réussi à trouver de réponses claires (j'ai un peu honte é_é). Du coup j'inaugure. Ma question concerne en particulier l'architecture x86.

Une fois que le CPU a récupéré l'adresse physique correspondant à ce qu'il manipule, dans la plupart des architectures contemporaines, il fait une requête Memory Controller (qui, dans les architectures les plus récentes, est compris dans le CPU). Ce Memory Controller doit déterminer si cette adresse physique correspond, dans sa memory map, à une adresse en RAM ou à une mémoire d'un périphérique mappé en mémoire.

Ma question est fort simple, en fait : comment est gérée cette mémoire externe mappée en mémoire (la Memory-Mapped IO) ? Est-ce que c'est décidé de façon statique et fixé dans la doc du contrôleur ? Est-ce que ça peut être fait de manière plus dynamique (et dans ce cas là, comment ?).

Je sais que les devices PCI ont des Base Address Registers pour faire ça dynamiquement au niveau du Bus PCI, mais j'imagine que la plage d'adresse qui leur est assignée est limitée par l'IO Controller ?

Voilà, c'est des questions qui me paraissent super naïves mais en même temps, j'aimerai bien avoir les réponses et j'ai du mal à m'y retrouver dans les ressources que je trouve sur le net.

Salut lethom,

La réponse à ta question m'intéresse. Je pense que tu la connais déjà.

Selon moi, le processeur passe effectivement par un contrôleur physique qui ira "activer" le périphérique correspondant (RAM, ROM…) à l'adresse physique concernée.

Par exemple, si tu tapes dans une adresse comprise entre 0x0000 et 0x0FFF, ça serait la ROM. Si c'est de 0x1000 à OxFFFF, ça serait la RAM, etc.

J'avoue que la réponse reste vague, mais il me semble que ça fonctionne tel quel.

Merci pour ta réponse. Je suis d'accord sur le principe. Je me demande juste comment se débrouille le « dispatcher ».

Par exemple, si tu tapes dans une adresse comprise entre 0x0000 et 0x0FFF, ça serait la ROM. Si c'est de 0x1000 à OxFFFF, ça serait la RAM, etc.

Du coup, les plages d'adresse sont bien spécifiées en dures dans les specs des différents contrôleurs ?

Alors je pense que le dispatcher c'est en fait une combinaisons de portes logiques. Dans mon exemple il va vérifier si le bit 12 (0000 0000 0000 0000) est à 1. Si c'est le cas, il pioche dans la RAM. Sinon, il pioche dans la ROM. C'est bien ça que tu cherches à savoir ?

Je ne saurais répondre à ta seconde question. J'avoue que j'aimerais bien savoir également. Gwenn, mewtwo, si vous passez par là…

Okok, impeccable ! Merci beaucoup pour ces précisions, c'était les engrenages qui me manquaient pour que ça coule bien dans ma tête.

Autre question pendant que j'y suis : au sujet des ports IO (donc, espace d'adresses séparé). Dans les specs que j'ai pu lire, ils sont écrits « en dur ». Par exemple, le registre APMC correspond au port 0xb2 et je peux très simplement écrire dedans avec l'instruction assembleur out. Soit. En l'occurrence, le port 0xb2 est dans le contrôleur mémoire, donc c'est assez safe, mais est-ce qu'il serait possible que deux devices exposent un port aux mêmes adresses ?

Logiquement, on évite au maximum le partage d'adresse entre périphériques, sauf dans quelques cas exceptionnels. Les périphériques/IO sont configurables, voire conçus pour éviter ce genre de situation : on peut configurer leurs plages d'adresses dans l'espace IO pour éviter ce genre de choses.

Je suis d'accord sur le « fonctionnement normal », je m'intéresse plus aux cas limites avec un device pas forcément bienveillant (qui pourrait, a priori, mentir). Mais je ne savais pas que l'espace IO était configurable. Merci !

Question H.S. : mewtwo, tu fais comment tes schémas ? Ça m'intéresse…

Pour les cas frauduleux ou buggés, je ne sais pas trop comment cela se passe.

Une chose est sure : il y a un risque que plusieurs devices accèdent en même temps au bus en écriture, ce qui peut ne pas être possible électriquement, ou être géré par un système d'arbitrage ou le chipset. Il y a surement possibilité que le périphérique frauduleux profite de l'algorithme d'arbitrage pour autoriser ses écritures, mais je ne parierais pas dessus.

Pour les lectures, cela dépend du bus et de ses caractéristiques électriques, mais il y a possibilité que le périphérique frauduleux puisse espionner ce qui se passe sur le bus.

De mémoire, il n'y a pas des conflits de plage d'adresse DMA sur les anciens PC qui correspondent à ce genre de cas ? C'était une cause de périphériques non-reconnus sous certaines anciennes versions de Windows, si je dis pas de conneries.

Réponse au HS : Mes schémas, c'est du Paint version XP ou Windows 8 (ça dépend du PC que j'utilise).

Je ne sais pas très bien ce qu'il en est sur un PC aujourd'hui, mais il y a de bonnes chances que ce soit comme sur les téléphones portables, tablettes, … Aujourd'hui, sur un système à base de cœur ARM, il n'y a plus réellement un bus mémoire. A la place, on retrouve une IP nommée Interconnect, qui va fournir une interface par maitre (par cœur processeur, notamment), et par esclave (chipset graphique, contrôleur mémoire, …). Un même device peut avoir à la fois une interface maître et une interface esclave sur le bus (c'est le cas par exemple des chipset graphiques, qui vont aussi avoir besoin d'être maîtres vis-à-vis de la mémoire).

L'interconnect va gérer beaucoup de choses : les accès concurrents au même esclave par des maîtres différents, les problèmes de "salissure" (quand les caches deviennent dirty), de cohérence et de transferts de caches, … Leur présence permet aussi d'éviter qu'un élément espionne les transferts effectués entre deux autres. C'est la base de l'extension de sécurité ARM TrustZone, par exemple.

Le SoC est synthétisé avec des valeurs d'initialisation pour l'interconnect, qui va ensuite gérer les consignes invalides (par exemple en figeant toutes les transactions, ce qui peut ne laisser comme solution que de re-démarrer le SoC). Le device n'a in-fine aucun contrôle sur la plage d'adresse qu'il occupe sur le bus.

PS : je sais que le sujet date un peu, mais comme j'avais quelques billes pour aller avec celles de mewtow, j'ai essayé de compléter la réponse