Cross-development for ARM64 on x64 hosts

I will start doing ARM kernel driver development using an x86_64 host machine. I’ve looked into the official Microsoft Dev Kit, but I’d like to know what the current community standard is for cross-platform driver development and debugging. I'm targeting the latest Snapdragon-based Microsoft laptops. Also, my host machine has a Thunderbolt 4 controller. Would KDNET over USB a work for kernel debugging on these targets? Microsoft doesn't mention Thunderbolt on setting up page. So what kind of stack you guys got for cross-debugging ARM64 machines?

I’d like to know what the current community standard is for cross-platform driver development and debugging.

It’s no different than the old days when we built x86 and x64 binaries on a single system. If you set up your Visual Studio project to indicate the targets you want, it will find and use the appropriate cross-compiler. Painless.

Microsoft doesn't mention Thunderbolt on setting up page. So what kind of stack you guys got for cross-debugging ARM64 machines?

Personally, I found USB debugging to be way too finicky. I had consistent success with network debugging. Of course, I’ve been off for a couple of years, so maybe the experience has changed.

Do the consumer grade ARM laptops even have a KDNET compatible NIC?

I’ve had alot of success with USB debugging by following this article. In my case though the target wasn’t ARM, not sure if that changes things.

I believe the Snapdragon chips have some specific support for a debugger interface over the USB-C port. I’ve also used QEMU for ARM64 Windows kernel debugging with the windbg EXDI interface to the QEMU gdb interface. If you just run kdnet.exe on the target system with no parameters it will tell you the available debug interfaces. You might read Setting Up USB KDNET EEM Kernel-Mode Debugging (KDNET-EEM-USB) - Windows drivers | Microsoft Learn

Wasn't the experience slow? Also WinDbg is very buggy for me in EXDi. It often cannot read gsbase until the machine is fully rebooted with it being attached. It also sometiems refuses to execute other commands due to same reason. !running, !thread, !process, !object etc.

I used kdnet on arm64 but the machine used was a HyperV and windbg host was an x64 (my dev laptop). Arm64 was just a “server box” that I never touched rly.

QEMU was troublesome with KDNET! I had to change two XML lines to not be Windows and not be QEMU (but KVMKVMKVM like OSR article randonly suggested). Then kdnet also worked.