Quand dois-je spécifier add_efi_memmap comme argument du noyau lors du démarrage UEFI / EFI?

Je suis en train de lire quelques tutoriels sur la façon de charger un stub EFI (efistub) du noyau Linux. Ces instructions utilisent souvent le paramètre de démarrage du noyau add_efi_memmap. Le matériel prévu est Intel x64 avec 8 Go de RAM. Ma configuration actuelle exécute le grub-efichargeur de démarrage et le noyau v3.13.

Grub boot sans l' add_efi_memmapargument de démarrage:

• 23Lignes BIOS-e820 _{comptées pardmesg | grep BIOS-e820: | wc -l}
• 243Lignes de mémoire EFI _{comptées pardmesg | grep efi:\ mem | wc -l}
• Zone DMA: 24pages réservées
• Mémoire: 7840568K / 8283384K disponible
• 442816K réservé

Le démarrage de GRUB avec add_efi_memmap et la taille de la carte mémoire EFI semblent différer:

• 23 Lignes BIOS-e820
• 57 Lignes de mémoire EFI
• Zone DMA: 22pages réservées
• Mémoire: 7885076K / 8283384K disponible
• 398308K réservé

Botte de talon EFI sans add_efi_memmap :

• 22 Lignes BIOS-e820
• 60 Lignes de mémoire EFI
• Zone DMA: 21pages réservées
• Mémoire: 7885012K / 8283384K disponible

Botte de talon EFI avec add_efi_memmap :

• 22 Lignes BIOS-e820
• 66 Lignes de mémoire EFI
• Zone DMA: 21pages réservées
• Mémoire: 7882124K / 8283384K disponible

Après avoir lu plus d'informations - comme indiqué ci-dessous - je ne sais pas s'il faut ajouter add_efi_memmapou non. Il fait quelque chose de plus qui ne semble pas absolument nécessaire pour démarrer. En revanche, il peut donner pour donner une meilleure vue (plus complète) de la mémoire utilisable.

Dans quels cas cet argument de démarrage add_efi_memmap doit-il être utilisé pour le démarrage du stub EFI? Est-ce que cela augmenterait / diminuerait la vitesse de démarrage du stub EFI et augmenterait ou diminuerait la mémoire libre disponible pour les applications? Comment (mieux) vérifier si ma carte mémoire EFI comprend plus d'entrées que ma carte E820?

Quelques documentations add_efi_memmep déjà consultées:

add_efi_memmap : inclut la carte mémoire EFI de la RAM physique disponible.
Si le mappage de mémoire EFI contient des entrées supplémentaires ne figurant pas dans le mappage E820, vous pouvez inclure ces entrées dans le mappage de mémoire de noyaux de la RAM physique disponible en utilisant le paramètre de ligne de commande de noyau suivant. - https://www.kernel.org/doc/Documentation/x86/x86_64/uefi.txt

---

Au lieu d'ajouter toujours des entrées de mappage de mémoire EFI (le cas échéant) à la mappe de mémoire après avoir initialement trouvé des entrées de mappage de mémoire du BIOS E820 et / ou des entrées de mappage de ligne de commande du noyau, -au lieu d'ajouter uniquement ces entrées de mappage de mémoire EFI supplémentaires si l'option de démarrage du noyau : add_efi_memmapest spécifié. - http://www.gossamer-threads.com/lists/linux/kernel/937817

---

Le démarrage se bloque - Si le démarrage est bloqué sans aucun message d'erreur après que GRUB a chargé le noyau et le disque virtuel initial, essayez de supprimer le paramètre de noyau add_efi_memmap. - https://wiki.archlinux.org/index.php/GRUB#Boot_freezes

---

Ce correctif modifie le comportement du chargeur kexec lorsque l' add_efi_memmapoption est présente sur la ligne de commande du noyau en cours d'exécution, pour lire la carte mémoire du noyau à la /proc/iomemplace de /sys/firmware/memmap.

Sur les systèmes EFI, la table e820 est parfois manquante ou incomplète. Des systèmes comme ceux-ci utilisent l' add_efi_memmapoption pour ajouter des entrées de table de mémoire EFI à la table de mémoire du noyau pour construire une image complète de la mémoire du système; toutefois, l'utilisation de l'option n'ajoute pas ces entrées à la table utilisée pour remplir /sys/firmware/memmap, ce qui est censé être une copie d'origine vierge.

Le chargeur kexec utilise la carte mémoire vierge par défaut, ce qui provoque des problèmes lorsque le chargeur n'a pas une image complète du système et charge incorrectement le noyau ou le disque virtuel dans des endroits qui ne sont pas réellement utilisables. Cette modification oblige le chargeur kexec à vérifier la ligne de commande du noyau en cours d'exécution pour l' add_efi_memmapoption et s'il la trouve, utilisera la carte modifiée au lieu de la carte d'origine. - http://lists.infradead.org/pipermail/kexec/2011-April/005014.html

---

La solution (hack), arrivée par les développeurs du noyau Linux en 2009 après un certain nombre de faux départs, était d'ajouter une option de ligne de commande du noyau, add_efi_memmap- pour dire au noyau de regarder la carte mémoire EFI et de l'utiliser pour corriger diverses entrées dans la carte mémoire de l'E820. - http://blog.fpmurphy.com/2012/08/uefi-memory-v-e820-memory.html

Les chargeurs de démarrage, ou Grub d'ailleurs, reconstruit la carte mémoire comme e820, je suppose que c'est la raison pour laquelle vous voyez des valeurs différentes entre GRUB et le chargeur de stub EFI.

Il y a un commentaire dans le code source Linux qui dit que EFI autorise "plus que les 128 entrées maximum qui peuvent tenir dans la carte mémoire héritée e820 (zeropage).". Cela ne semble pas être le cas selon les chiffres que vous avez publiés, donc je doute que l'ajout de add_efi_memmap soit utile ... Cependant, cela ne fait certainement pas de mal d'analyser ce tableau aussi ...

Si votre distribution Linux démarre avec succès EFI STUB, il n'est pas nécessaire d'utiliser add_efi_memmap. Cette option de ligne de commande du noyau est rarement nécessaire de nos jours - le firmware UEFI et le support du noyau Linux pour celui-ci se sont considérablement améliorés depuis l'ère 2009.