@hoh said in Early testable PVH support:
Then I tried to get rid of the (fake) UEFI magic.
Well, it is actually a full standard UEFI implementation, but that works in PVH instead of HVM.
I thought it should work to just change the PV-bootloader to pygrub. Calling pygrub on the disk image works fine and is able to extract the images and args
# pygrub -l alpine.img Using <class 'grub.GrubConf.Grub2ConfigFile'> to parse /boot/grub/grub.cfg title: Alpine, with Linux virt root: None kernel: /boot/vmlinuz-virt args: root=UUID=4c6dcb06-20ff-4bcf-be4d-cb399244c4c6 ro rootfstype=ext4 console=hvc0 initrd: /boot/initramfs-virtBut starting the VM fails. It looks like it starts but then immediately something calls force shutdown, I'll dive deeper into the logs later.
But setting everything manually actually works. If extract the kernel and initrd to dom-0 and configure
PV-kernel=/var/lib/xcp/guest/kernel PV-ramdisk=/var/lib/xcp/guest/ramdisk PV-args="root=/dev/xvda1 ro rootfstype=ext4 console=hvc0"it boots and I looks pretty much the same as with the pvh-ovmf magic. So perhaps the idea to use pygrub is wrong.
I don't know how good is supported pygrub nowadays, especially since PV support got deprecated in XCP-ng 8.2 then completely dropped in XCP-ng 8.3; with the pv-shim (pv-in-pvh) being the only remaining (but not endorsed) way of booting some PV guests today.
In my tests, pygrub was very clunky and rarely work as I expect. In practice (what upstream Xen Project mostly uses), it got replaced with pvgrub/pvhgrub and pvh-ovmf (OvmfXen) which are more reliable and less problematic security-wise (runs in the guest rather than in the dom0).
(for using pvhgrub, you need to set a pvhgrub binary (grub-i386-xen_pvh.bin which is packaged by some distros like Alpine Linux's grub-xenhost) as kernel like done with pvh-ovmf)
