Did you mean "stub domains and driver domains"? I'm pretty sure dom0less was used in production before it even made it into the main Xen tree. :-)
As I said, using Xen from a plain vanilla distro is more difficult to set up. There are a couple of reasons for this; one of them being simply that RedHat's main product is itself a distro, and so the setup of their product translates over directly into making it easy to be set up within other distros.
The companies with products shipping Xen, on the other hand, primarily ship fully-integrated products. Citrix Hypervisor (was XenServer) and XCP-ng are "virtualization appliances" in which everything is integrated. OpenXT and QubesOS are the same way. Citrix Hypervisor / XCP-ng don't use driver domains, but they do have custom QEMU deprivileging for device models. OpenXT and QubesOS do (as I understand it). If you install one of these, you get a secure setup by default.
Fundamentally, none of these organizations would benefit directly from making it easier to set up driver domains on plain vanilla distros; and so making it easier to use driver domains on a plain vanilla distro never gets to the top of their engineers' priority queue. If you're interested in using Xen on a server fleet, I would definitely recommend going with XCP-ng or Citrix Hypervisor; if you want a secure desktop, definitely go with QubesOS or OpenXT. On the other hand, if having your fleet / desktop based on a vanilla Linux distro is a priority for you, then KVM might be a better bet at the moment.
Thanks for the interesting reply. These are fair points. And I hadn't considered the Citrix products. If you read this then I do have another question. Is there way to disable PV guest support in Xen? IIRC this code represented a good portion of Xen's CVE list. It is an attack surface that we no longer need on modern CPUs. In theory you can just never run a PV guest but the code would still be present?
TLDR: Yes, you can disable PV entirely on x86 systems; on ARM systems, there never was PV.
On x86, as you say, has "classic" Xen PV, which doesn't require virtualization extensions. It also has "HVM", which includes a full system emulation (motherboard, etc); but also "PVH", which is basically what PV would be if it were designed today: It takes advantage of hardware support when it makes sense, and paravirtualizes when it makes sense. It doesn't require a devicemodel to be running at all, but also isn't susceptible to the PV XSAs. There's also a mode called "shim" mode, which allows you to run "classic PV" kernels in PVH mode.
Xen now has KConfig, and you can now disable PV mode entirely when building Xen. You can run dom0 in PVH mode, and then run all of your guests either in PVH mode or HVM mode.
The ARM port was made after ARM had virtualization extensions; so it never had a "classic PV"; nor does it require any devicemodel whatsoever. There's only one guest mode, which corresponds roughly to the "PVH" mode above.
As I said, using Xen from a plain vanilla distro is more difficult to set up. There are a couple of reasons for this; one of them being simply that RedHat's main product is itself a distro, and so the setup of their product translates over directly into making it easy to be set up within other distros.
The companies with products shipping Xen, on the other hand, primarily ship fully-integrated products. Citrix Hypervisor (was XenServer) and XCP-ng are "virtualization appliances" in which everything is integrated. OpenXT and QubesOS are the same way. Citrix Hypervisor / XCP-ng don't use driver domains, but they do have custom QEMU deprivileging for device models. OpenXT and QubesOS do (as I understand it). If you install one of these, you get a secure setup by default.
Fundamentally, none of these organizations would benefit directly from making it easier to set up driver domains on plain vanilla distros; and so making it easier to use driver domains on a plain vanilla distro never gets to the top of their engineers' priority queue. If you're interested in using Xen on a server fleet, I would definitely recommend going with XCP-ng or Citrix Hypervisor; if you want a secure desktop, definitely go with QubesOS or OpenXT. On the other hand, if having your fleet / desktop based on a vanilla Linux distro is a priority for you, then KVM might be a better bet at the moment.
But as always, "patches accepted". :-)