{"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\/en\/blog\/hypervisor-assisted-debugging\/","title":{"rendered":"Hypervisor-assisted Debugging"},"content":{"rendered":"\t\t
\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

Working on a hypervisor has its own set of challenges. Among them, one of particular note is that of device emulation. This may be an exaggeration if you work in simulated environments such as ARM’s Fixed Virtual Platform. However, things can get out of hand once you switch to actual hardware.<\/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

Departure from Simulated Environments<\/h2>\n

A common component found on any embedded device is Power Management Integrated Circuit (PMIC) regulators. Their base function is relatively straightforward: managing the flow and direction of electrical power. They clamp input voltages\/currents and power on the available devices. But things are more complex. In truth, every manufacturer uses myriad different regulators with at least as many features heaped on top for good measure. E.g., a particular device driver may implement a subset of the power regulator driver’s features and probe it directly via syscon<\/a> to ascertain the state of a related subsystem. That subsystem could be a frequency divider that needs to be active before resetting the device.<\/p>\n\n

A Typical Problem with Power Regulators<\/h2>\n

All this becomes a problem when the integration with an SoC is too inflexible. Power regulators (or their drivers) need to be developed with virtualization in mind. Say, for example, that you want to partition devices between several VMs, each VM having exclusive access to its assigned device. Since on Arm architectures, device trees are used instead of mechanisms such as ACPI Device Enumeration<\/a>, the first logical step is to delete the unrequired device nodes from each VM’s device tree. Said and done. But now you realize that while one VM’s driver has powered on its device, the second VM’s different driver has shut it back down. Why? Because that particular driver was expecting to find the first VM’s device node in the device tree and assumes that its absence indicates that the device was disabled. So why not make sure that its power supply is also disabled? As you can imagine, problems such as these take time to track down. Moreover, hardware debugging solutions are sometimes not an option due to lackluster support for specific platforms (usually, at least OpenOCD<\/a> tends to have better interfacing with hardware debuggers than OEM software). And this brings us back to the topic at hand.<\/p>\n\n

Advantages of Hypervisor-assisted Debugging<\/h2>\n

If you’re at a point where not even ‘printk’ debugging is possible, your choices may seem limited. In fact, without a hardware debugger, the only option left is trapping the executing kernel into EL2 (hypervisor space), given that there is a hypervisor. This can be done in several ways:<\/p>\n\n