# Design Perspective

The following diagram illustrates how HyperDbg works on its kernel debugging mechanism.

![](/files/-MQTqs_VO0wd4OZrygKw)

Based on the design of HyperDbg, all the cores are halted and spinning on ring -1 (hypervisor).

The current operating code is listening for new commands from the debugger on a polling mode serial.

There are two scenarios in which the kernel debugger is paused.

1. The user requests a pause (for example, by pressing CTRL+C), then it sends a packet to pause the debugger, and the debuggee starts processing the packet from user-mode and invokes an IOCTL, and that IOCTL executes a VMCALL and goes from the kernel-mode to the vmx-root.
2. A breakpoint is triggered either by a break request from an event or the script engine. There are two possible scenarios, first, if the user is in kernel-mode, then a VMCALL happens, and if the user is already in vmx-root mode, we should notify all the other cores.

In order to notify all the other cores, we send NMIs to all the cores using XAPIC or X2APIC. All the cores are configured to cause vm-exit in the case of NMIs (PIN-Based VM-Exec controls are set to 1).

All the cores in vmx-root mode are spinning and waiting for a new command from the debugger.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.hyperdbg.org/design/debugger-internals/kernel-debugger/design-perspective.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.