Design session PVH dom0

[Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>]

Session description (by Jan):
In the course of working on an XSA I had to finally get PVH Dom0 work on at 
least one of my systems, in a minimal fashion. This had turned up a number of 
issues, some of which have since remained pending. Therefore I’d like to gain 
understanding on whether there is any future to this mode of Dom0 operation, 
and if so when it can be expected to be better than tech preview or even just 
experimental.

Open issues off the top of my head: - PCI pass-through / SR-IOV - passing of 
video settings to Dom0 kernel - serial console (at least when on a plug-in PCI 
card)


Jürgen: PVH dom0 would be nice, related to feature parity PV vs PVH (PCI 
passthrough etc)

George: gitlab has related tickets
https://gitlab.com/groups/xen-project/-/epics/2
When completed, PV could be called "legacy"

Stefano: dom0less could help with PV-less setup
      fully featured vPCI required

Roger: still need to support HVM way of passthrough with qemu, otherwise some 
devices via vPCI and some emulated for the same guest

Stefano: qemu is not certifiable, should be avoided in cerifiable configurations

Jürgen: use qemu for virtio

Stefano: ioreq server needs to work together with vPCI

George: move from just qemu to vPCI may move devices -> Windows BSOD

Jan: no problem with qemu coexisting with vPCI

Roger: some use cases still require qemu for passthrough (HVM), if some parts 
are special handling

George: GVT-g(?) is such case

Marek: actually, the ioreq server is in dom0 kernel, qemu only reserves slot

Jan: host bridge, root complex emulation currently is ARM specific

George: who is going to do the work?

Jan: that's why this session, no progress, or even patch review

Stefano: there was proposal from Julien about using platform hypercalls for 
[???]

George: track what's happening to related patches

Stefano: PVH dom0 is useful

Roger: EPAM already do vPCI for PVH dom0, minimal configuration for Q35

Stefano: what other gaps for PVH dom0?

George: see gitlab epic

Jan: hide serial cards - if dom0 doesn't enumerate it, something gets confused 
(overlap check?)
Jan: video information - for PV dom0 framebuffer info is in start_info, but no 
equivalent for PVH

Jürgen: use Linux boot config protocol?

Jan: Xen don't speak it

Stefano: EFI services?

Jan: dom0 doesn't have boot services access

Stefano: that was video output on RPi

Jan: do hypercall to obtain the info

Roger: PVH is a thing on firecracker

George: there are definitely more issues, but the big ones are the above

Jürgen: PVH dom0 performance?

Roger: it's bad; mostly relevant is qemu interfaces

George: only for safety certifications? performance penalty may be okay

Jürgen: hypercalls can be improved (virtual buffers?)

Stefano: litte sense in performance optimization before feature complete

Roger: limited capacity what we can work on

Stefano: safety certification may motivate the effort

George: sell it this way to AMD






-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

Attachment: signature.asc
Description: PGP signature