Difference between revisions of "XenParavirtOps/yielding"

From Xen
Line 49: Line 49:
 
== MTRR ==
 
== MTRR ==
   
Being written
+
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.
  +
  +
=== 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.

Revision as of 01:14, 8 August 2015

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.

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.

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.