{"id":4868,"date":"2023-01-31T09:05:43","date_gmt":"2023-01-31T08:05:43","guid":{"rendered":"https:\/\/sanctuary.dev\/?p=4868"},"modified":"2023-02-09T09:41:29","modified_gmt":"2023-02-09T08:41:29","slug":"hypervisor-assisted-debugging","status":"publish","type":"post","link":"https:\/\/sanctuary.dev\/de\/blog\/hypervisor-assisted-debugging\/","title":{"rendered":"Hypervisor-assisted Debugging"},"content":{"rendered":"
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t

Die Arbeit an einem Hypervisor bringt eine Reihe von Herausforderungen mit sich. Eine besondere Herausforderung ist dabei die Ger\u00e4teemulation. Das mag \u00fcbertrieben sein, wenn man in simulierten Umgebungen wie der Fixed Virtual Platform von ARM arbeitet. Sobald man jedoch zu echter Hardware wechselt, k\u00f6nnen die Dinge aus dem Ruder laufen.<\/p>\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t

Verlassen der simulierten Umgebung<\/h2>\n

Eine h\u00e4ufige Komponente in allen eingebetteten Ger\u00e4ten sind Power Management Integrated Circuit (PMIC) Regler. Ihre Grundfunktion ist relativ einfach: Sie verwalten den Fluss und die Richtung des Stroms. Dazu regeln sie die Eingangsspannungen und -str\u00f6me und schalten die verf\u00fcgbaren Ger\u00e4te ein. Aber die Dinge sind komplexer. In Wirklichkeit verwendet jeder Hersteller unz\u00e4hlige verschiedene Regler mit mindestens ebenso vielen Funktionen, die er noch zus\u00e4tzlich anh\u00e4uft. So kann z. B. ein bestimmter Ger\u00e4tetreiber eine Teilmenge der Funktionen des Leistungsreglertreibers implementieren und ihn direkt \u00fcber syscon<\/a> direkt abfragen, um den Zustand eines zugeh\u00f6rigen Subsystems zu ermitteln. Bei diesem Teilsystem k\u00f6nnte es sich um einen Frequenzteiler handeln, der vor dem Zur\u00fccksetzen des Ger\u00e4ts aktiv sein muss.<\/p>\n\n

Typische Probleme mit Power Regulators<\/h2>\n

All dies wird zu einem Problem, wenn die Integration in einem SoC zu unflexibel ist. Leistungsregler (oder deren Treiber) m\u00fcssen mit Blick auf die Virtualisierung entwickelt werden. Nehmen wir zum Beispiel an, es sollen Ger\u00e4te zwischen mehreren VMs aufgeteilen werden, wobei jede VM exklusiven Zugriff auf das ihr zugewiesene Ger\u00e4t hat. Da auf Arm-Architekturen Device Trees anstelle von Mechanismen wie ACPI Device Enumeration<\/a>verwendet werden, ist der erste logische Schritt, die nicht ben\u00f6tigten Ger\u00e4teknoten aus dem Ger\u00e4tebaum der einzelnen VMs zu l\u00f6schen. Gesagt und getan. Aber jetzt stellt man fest, dass der Treiber der einen VM das Ger\u00e4t eingeschaltet hat, w\u00e4hrend der andere Treiber der zweiten VM es wieder ausgeschaltet hat. Und warum? Weil dieser Treiber erwartet hat, den Ger\u00e4teknoten der ersten VM im Device Tree zu finden und davon ausgeht, dass sein Fehlen bedeutet, dass das Ger\u00e4t deaktiviert wurde. Warum also nicht sicherstellen, dass seine Stromversorgung ebenfalls deaktiviert ist? Es kann sehr lange dauern bis solche Probleme aufgesp\u00fcrt werden. Dar\u00fcber hinaus sind Hardware-Debugging-L\u00f6sungen aufgrund mangelnder Unterst\u00fctzung f\u00fcr bestimmte Plattformen manchmal keine Option (normalerweise hat OpenOCD<\/a> immerhin noch eine bessere Schnittstelle zu Hardware-Debuggern zu haben als OEM-Software). Und damit sind wir wieder beim eigentlichen Thema.<\/p>\n\n

Vorteile des Hypervisor-assisted Debugging<\/h2>\n

Wenn man an einem Punkt angelangt ist, an dem nicht einmal ein \"printk\"-Debugging m\u00f6glich ist, scheinen die M\u00f6glichkeiten begrenzt zu sein. Tats\u00e4chlich bleibt ohne Hardware-Debugger nur die M\u00f6glichkeit, den ausf\u00fchrenden Kernel in EL2 (Hypervisor-Space) zu trappen, vorausgesetzt, es gibt einen Hypervisor. Dies kann auf verschiedene Weise geschehen:<\/p>\n\n