XenParavirtOps/yielding
Xen Paravirt yielding
While pv_ops enables multiple hypervisors to co-exist and produce a single binary the hypervisor and Linux must still avoid conflicts for functionality which Linux would otherwise implement. Prior to pv_ops, yielding was addressed through a series of Kconfig entries which would prevent certain architecture code from running when a hypervisor was be supported. This code never made it upstream, and over the years different yielding strategies have been devised to address this. The different yielding strategies and areas that Linux yields to or should yield to are documented in this section to Xen.
IOMMU yielding
Hypervisors can support PCI-passthrough for PV guests, when they do this an IOMMU is needed to translate bus (DMA) to virtual and vice-versa and a mechanism to provide contiguous pages for device drivers operations (DMA operations).
Paravirt hypervisor IOMMUs need to make use of the IOMMU_INIT*() macros and ensure they are are probed for in the appropriate order to ensure dependencies align and to avoid conflicts with other IOMMUs. For instance, once you find out in what order your IOMMU init code should run in consideration for the others you must also ensure to use IOMMU_INIT_FINISH() if no other IOMMUs init code should be run after yours.
Xen's IOMMU uses IOMMU_INIT_FINISH() and its IOMMU init code is the first to run, as such Linux PV guests only allow the Xen IOMMU to run.
Furthermore IOMMU API calls should always call iommu_present() prior to execution. This checks if the give bus_type has no iommu_ops registered, this would always return false for paravirt hypervisors.
CPU Microcode
The Linux kernel microcode code uses paravirt_enabled() to bail early and yield to CPU microcode control over to the hypervisor. For Xen's paravart CPU microcode options refer to Xen pv_ops microcode update section for further details.
arch/x86/kernel/cpu/microcode/core.c
static int __init microcode_init(void) {
struct cpuinfo_x86 *c = &cpu_data(0);
int error;
if (paravirt_enabled() || dis_ucode_ldr)
return 0;
...
}
MTRR
Being written.
Topology
Being written.
New conflicts
This is a list of features known to cause issues with Xen, which may not yet be addressed.
Needs review
This is a list of other code which requires review / vetting:
* PCI ATS * PRI * PASID * i915 DRM driver should be fixed to not use the Intel AGP code. Intel should be working on this. Konrad will poke them.
Kasan
In order for Kasan to work kasan_map_early_shadow() would need to have been called on Xen guests early. When Kasan was introduced this was not done.
Automatic detection possible ?
Prior to pv_ops Linux would address yielding strategies for Xen by using !XEN through a series of Kconfig options. Admittedly the only way these conflicting components would be known would be when Linux was modified with Xen paravirtualization support. There was no way to automatically detect which components should conflict other than chained reaction build failures if new feature depending on previously conflicting and disabled !XEN features.
How do we avoid future conflicts? How can we prevent issues such as the Kasan, as an example of a new feature, to not conflict with Xen ?
One possibility is active maintainer review on early x86 code, but at least for Kasan Xen folks were not copied on this.
