Making Xen's dom0 I/O path NUMA aware

This article is a great example of the limits of LLM technical writing.

Say what you will about—or try to prompt out—their rhetorical flourishes, they can link together a series of background, observations, implications, …

But man, they are hopeless at crafting a high-level narrative. It’s one big hedge maze of a garden path:

This part makes good on that - and along the way it covers two things we did not plan to fix. One we hit before the real work could start: dom0's own memory placement was so skewed that synthesising a topology for dom0 without fixing it first would have been an exercise in lying to a kernel that had no memory to back the lie with. That one is a prerequisite, not a detour - everything else in this part is built on top of it. The other we hit after the work was nominally done: a memory-placement bug in our own toolstack that had been silently broken for as long as multi-vnode vNUMA had existed in our tree, and only ever surfaced under a memory-bandwidth benchmark. That one is the genuine detour, and it waits until the end.

Let's start with the prerequisite.

Where are we going here and why?!

Why is Xen a thing when we have great and free KVM virtualization? Honest and dumb question.