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.