Re: [Xen-devel] Xen 4.12.0 Dom0=pvh mode EFI variables 'not supported' after boot

[Roger Pau Monné <royger@xxxxxxxxxxx>]

On Fri, May 24, 2019 at 08:33:51AM -0700, PGNet Dev wrote:
> After upgrading Kernel to 5.1.4/release on an x86_64 server, Xen 4.12.0 Dom0 
> successfully boots in PVH mode (dom0=pvh ...), with efi vars available so 
> that efibootmgr functions,
> 
>       xl list
>               Name                                        ID   Mem VCPUs      
> State   Time(s)
>               Domain-0                                     0  4015     4     
> r-----     847.6
>               Xenstore                                     1    31     1     
> -b----       0.0
> 
>       dmesg | grep -i pvh
>               [    0.181973] Booting paravirtualized kernel on Xen PVH
> 
>       efibootmgr
>               BootCurrent: 0000
>               Timeout: 1 seconds
>               BootOrder: 0000,0002,0003
>               Boot0000* xensvr 
> HD(2,GPT,9711255e-d11d-31c5-88fe-1e164d4d4c95,0x1000,0x96000)/File(\EFI\OPENSUSE\GRUBX64.EFI)
>               Boot0002* UEFI OS       
> HD(2,GPT,9711255e-d11d-31c5-88fe-1e164d4d4c95,0x1000,0x96000)/File(\EFI\BOOT\BOOTX64.EFI)..BO
>               Boot0003* UEFI: Built-in EFI Shell      
> VenMedia(5126c8dc-e6a4-b3e9-a119-cf41345c9754)..BO
> 
> From
> 
>       
> https://xenproject.org/2018/07/10/xen-project-hypervisor-4-11-brings-cleaner-architecture-to-hypervisor-core-technologies/
> 
> I understand that PVH Dom0 *removes* qemu dependency,

Let's clarify this a bit:

 * PVH domU doesn't require a QEMU to run (as opposed to a HVM domU).
 * PVH dom0 also doesn't require a QEMU, the more that running a QEMU for
   dom0 is very, very complex if possible (you would have to boot
   something like a stubdom before booting dom0).

Classic PV dom0 also doesn't have a QEMU dependency, and the QEMU
process that you see running in dom0 when using either a PV or PVH
dom0 is not used for emulation (see below).

>       "PVH Dom0 Reduces the Attack Surface of Xen Project Based Systems
> 
>       PVH combines the best of PV and HVM mode to simplify the interface 
> between operating systems with Xen Project Support and the Xen Project 
> Hypervisor and to reduce the attack surface of Xen Project Software. PVH 
> guests are lightweight HVM guests that use hardware virtualization support 
> for memory and privileged instructions. PVH does not require QEMU.
> 
>       Xen Project 4.11 adds experimental PVH Dom0 support by calling Xen via 
> dom0=pvh on the command line. Running a PVH Dom0 removes approximately 1 
> million lines of QEMU code from Xen Project’s computing base shrinking the 
> attack surface of Xen Project based systems."
> 
> Checking, qemu is still resident,
> 
>       ps ax | grep qemu
>               1895 ?        Sl     0:00 /usr/bin/qemu-system-i386 -xen-domid 
> 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor /dev/null 
> -serial /dev/null -parallel /dev/null -nodefaults -no-user-config -pidfile 
> /var/run/xen/qemu-dom0.pid
> 
> Is this still expected?

Yes, this QEMU is not emulating any devices for dom0, it is just used
to locally attach disks to dom0 in order to run pygrub (or any
dom0-based bootloader).

> If so, why the *i386* variant, not /usr/bin/qemu-system-x86_64?

It makes no difference: when using QEMU together with Xen the CPU
emulation parts of QEMU are not used, hence it doesn't matter if the
i386 or the x86_64 variants are used, both provide the same set of
emulated devices, which is what Xen guests use from QEMU.

> If not, is there some additional config required to disable its use here?

You can modify the init script (xencommons) or disable
xen-qemu-dom0-disk-backend if using systemd to prevent launching a
QEMU for dom0, but then certain toolstack operations would fail (ie:
trying to boot a domU with a qcow disk using pygrub).

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel