Xen Winter Meetup 2025 design session notes: PVH

["Samuel Verschelde" <samuel.verschelde@xxxxxxxxxx>]

The description of the design session was:

PVH: limitations, requirements & future considerations

A general discussion on PVH from both guest and Dom0 perspectives, covering:

     Trade-offs and key limitations
     Required work for PCI passthrough and SR-IOV support
     Dom0 feasibility: kernel requirements and long-term viability
     Impact on end users compared to HVM simplicity

This session aims to clarify open questions and guide future development
priorities.

---

Rather than an actual design session, we had a Q&A session regarding
PVH, to "keep the ball rolling", with Roger and Andrew answering the
questions.

I will reference these notes in the gitlab EPIC related to full PVH
support: https://gitlab.com/groups/xen-project/-/epics/2

First, see Roger's presentation for PVH:
https://www.youtube.com/watch?v=J4qA-efLXJo

We discussed the advantages and tradeoffs of PVH.

Advantages:
- HVM guests without Qemu (lower attack surface, less usage)
- Reduction of attack surface in the hypervisor too, no HPET...

Neutral:
- No difference between modes for the Hypervisor

Tradeoffs / challenges (for guests):
- Biggest differences => no emulated VGA, text console that can be
turned into VNC but no GUI.
- No QEMU => no clipboard "hack" as exists in XenServer and XCP-ng.
- No device emulator, can't boot other kernel than Linux at the moment.
- PVH DomU no passthrough
- PVH DomU PCIe passthrough => should be priority

Tradeoffs / challenges (for dom0)
- PVH Dom0 is a lot of problems
- PVH Dom0 no passthrough for any guests

There's work from AMD on SR-IOV for PVH guests.

Roger: has a branch mostly working, should not be used with security in mind

x86 needs a root complex exposed to guest, needs Q35 support.
Minimal emulation of a PCIe root complex to attach SR-IOV to PVH guests.
Could be another emulator in Dom0 but some people don't want Dom0 (dom0less)
Emulator in the hypervisor needed in this case

Question: difference between normal root complex for SR-IOV and normal
devices?
=> Need IOAPIC for normal devices (SRIOV doesn't use IOAPIC, no legacy
PCI interrupt)
=> SR-IOV first is because it has more restrictions on things it can do
=> Since it needs some kind of logic to trap weird accesses (work
already done in Qemu that need to be added to the Xen emulator)
==> Roger's post-session addition, when we had trouble understanding the
notes: "SR-IOV VF have less registers implemented by the hardware, and
it requires a bit more emulation on QEMU (or vPCI) to work.  I think
that's the point of Andrew's remark."

=> Root complex is not that different for SR-IOV and normal devices
==> Roger's post-session addition: "root complex emulation should likely
be the same whether it's VFs or regular PCI devices that are exposed."

There's a plan to make Windows work: PVH OVMF
Plan to Windows install driver thanks to UEFI interface to ask it to
install drivers
Should be faster, can boot on PV device directly

Question: How does a PVH guest boot?
=> It's complicated, wait for documentation entries about this.

Question: When will PCIe passthrough for PVH guests happen?
=> Patches welcomed

Question: Is IOAPIC needed for devices doing MSI?
=> Yes, because line interrupt are the only needing things for a normal
PCIe while MSI are not needed. SR-IOV devices don't need legacy PCI
interrupts.
Windows does message on a bus saying that devices won't do line interrupt.

Question: What if a driver disables legacy interrupt?
=> Would work only until one device does a line interrupt. And some
devices would do legacy interrupt if MSI are masked.

Viridian and VMBUS are not the same thing, VMBUS is not a open
interface, one implementation might become available in Linux soon.



Samuel Verschelde | Vates XCP-ng Lead Maintainer / Release Manager / Technical 
Product Manager

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech