[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

High-speed KDNET transport for Xen guests


  • To: win-pv-devel <win-pv-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Tu Dinh <ngoc-tu.dinh@xxxxxxxxxx>
  • Date: Mon, 26 Oct 2026 11:46:15 +0100
  • Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=vates.tech header.i="@vates.tech" header.h="From:Subject:Date:Message-ID:To:MIME-Version:Content-Type:Feedback-ID"
  • Delivery-date: Mon, 26 Oct 2026 10:46:21 +0000
  • Feedback-id: default:8631fc262581453bbf619ec5b2062170:Sweego
  • List-id: Developer list for the Windows PV Drivers subproject <win-pv-devel.lists.xenproject.org>

Hello all,

You may have experienced difficulties with using hvm_serial for 
debugging Windows guests on Xen: it is incredibly slow and very 
difficult to do anything substantial (e.g. large scripts, complex 
commands) with it. KDNET with emulated NICs works, but then you cannot 
debug xenvif or xennet with it.

I've prepared a custom KDNET transport, which works along with Windbg's 
KDNET functionality:

https://github.com/xcp-ng/win-xenkd

It can reach speeds over 30 MB/s, which is fast enough to do a kernel 
memory dump in a few seconds. It also reconnects cleanly whenever

It uses the default console ring as a configuration channel, so you 
might want to patch that out of xenbus first.

It requires a dummy PCI device (5853:C201 by default), which you can add 
to QEMU like so:

     -device xen-pvdevice,vendor-id=0x5853,device-id=0xc201

Finally, by default, Windows refuses to load testsigned KDNET transport 
DLLs even with testsigning enabled. That's a pain, but there are ways to 
work around it.


--
Ngoc Tu Dinh | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.