# Réu projet - 19/01/2024

## Questions:

* Est ce qu'on a les plages d'adresses physiques
* Comment avoir ethernet dessus ? Besoin pour installer Make poru pouvoir build les modules linux sur Petalinux.

Normalement possible par défaut: il faut configurer un tat de chose dont le device tree pour exposer la carte ethernet à la VM.
IOMMU : même chose pour les périphériques, écrite directement dans la mémoire. Agit de la même manière que la MMU. On ajoute un espace dans la RAM pour la carte ethernet.
Tout est dans le meme commit.
- IOMMU : drivers/iommu/arm-smmu.c
- arch/arm/dts/xilinx/zynqmp.dtsi : device tree de xvisor pour qu'il utilise la iommu

- tests/arm64/virt-v8/linux/virt-v8.dts et tests/arm64/virt-v8/virt-v8-guest.dts il y a les blocs "ethernet" pour permettre d'utiliser la carte réseau en pass-through (configs côté xvisor et côté vm)

Pour utiliser en pass through: les adresses de config de la carte ethernet soexposé presque directement à la VM

Thèse de master : sensée contenir les adresses du mécanisme de trace

test: enlever une partie de la RAM

On a pour la zcu 104 qui n'est pas très loin.
Adresses: de 0xfe920000 à 0xfe980000, dans un premier temps. range continu.
Peut etre une liste de range d'adresses.

Un ensemble de registre de 64 bits, placés de manière contigue dans la mémoire. Tout ce range est l'espace de config du PTM.
Document PDF qui décrit précisémment ça. Document de Xilinx qui décrit ça.

STM permet de générer des traces programmatiquement, génère des instructions qui font des traces.

Ecrire un ptit bout de programme qui fasse une écriture dans un de ces composants, et cette écriture doit marcher si pas protégé et pas marcher sinon.
On peut maper ces adresses dans l'espace utilisateur?
On peut les modifier de 2 manière: module noyau permet avec une interface de modifier ces trucs là. => quand on boot, le noyau a ce support. Puis exposés dans des périphériques dans /sys/bus/coresight/devices. En faisant des echo 0 ou 1 ça écrite dans le composant qui va bien. Support de coresight dans notre processeur?

dans /sys/bus/coresight/devices on voit apparaitre nos composants. Le noyau prend nos lectures et écrite à l'endroit des périhpériques. Après protection, ça devrait échouer. Faire une modification de configuration => activer le Funel (mettre un 1). La configuration doit etre persistante. On relance en désactivant le range, et ça doit échouer.

Et puis, bibli fourtnie par arm qui map cet adressage pgysique dans l'adressage virtuel du processus et vient écrire directement via des write dans l'espace du processus => un peu un enfer. askip on va utiliser ça après, mais pour tester, c'est un enfer.

1e truc à faire => boot petalinux, vérifier qu'on a bien le support dans devices, qui correspond au shema: etm, funel, ets.
2e etape: essayer de jouer pour programemr un des composants => activer. Verifier en lecture si la config est persistante.
3e mettre en place la protection via hyperviseur. Dans le noyau ça doit plus marcher.
4e configurer le machin, depuis l'hyperviseur.

# Réu projet 26/01/2024

Lancer sur la carte un linux construit avec petalinux qui accède la carte
Petalinux: permet de construire l'imlage selon les bseoin, en activant certains options pour avoir la bonne image

Construire l'image nous meme. Solution: machine avec Petalinux à CS, donner accès pour faire ça. Il y a un vpn tailscale

Login github

Essayer de parler à la carte ethernet dans uboot.

prompt avec zynqmp = uboot, essayer de communiquer avec l'ethernet

Quel uboot est ce qu'il prend? par défaut dans l'image petalinux? ou celle de la flash ?

Dans xvisor build:

udisk: system de fichier pour xvisor
dtb: device tree pour xvisor
uvmm: vmm.bin -> bin pour xvisor

on peut dire d'aller chercher tel fichier sur le reseau -> bootp au lieu de bootm