XEN PVH Virtualization Mode - "What Color Is Your Xen?"

In my previous post Why smaller code size with XEN on ARM?, one of reasons I explained is that XEN on x86 must support different guest working modes with backward compatibility due to historical x86 virtualization technology limitations (e.g. in the first x86 VT-x version, no hardware-assisted Paging support). This post just shares some useful information/links on a new XEN virtualization mode (PVH) I read recently. 

Problems arises when supporting EFI + GRUB2 + Xen with Multiboot2 boot specification

Previously I wrote a post to discuss the limitations for Multiboot boot specification, today I saw that XEN hypervisor also has the similar problems. 

Enable UEFI Firmware BIOS and Debug Xen/EFI on VMware Player

Since VMware product (e.g. Player) now supports nested virtualization VT-x/VMX , recently I wanted to use this feature to debug XEN w/ EFI on top of VMware Player. This post details some best practices, and some issues I encountered. 

Why smaller code size with XEN on ARM?

This white paper (Xen ARM with Virtualization Extensions whitepaper) indicates that "Xen on ARM is 1/6 of the code size of x86_64 Xen, while still providing a similar level of features". what does this mean? Does this mean that Xen/ARM is better than Xen/x86? We cannot simply just make this conclusion, but anyway smaller code size means smaller TCB, which can reduce security risks (e.g. security vulnerabilities). 

Multiboot Specification and limitations (Bootloader -> OS)

Typically in a computer system, the boot sequence is like this: firmware -> bootloader -> Operating System.  The problem is that nowadays we have the largest variety of operating systems, boot loaders, and firmwares (UEFI/Legacy), and even some of them are proprietary software that are not public. So, the interaction might be a problem if the interface is not well-defined.