Xen Project 4.15 Release Notes: Difference between revisions

From Xen
Jump to navigationJump to search
(reorder)
(upates)
Line 29: Line 29:
In general, our aim is to keep old guests working on new versions of Xen, and to allow live migration from the previous Xen major version.
In general, our aim is to keep old guests working on new versions of Xen, and to allow live migration from the previous Xen major version.


* Accesses to x86 MSRs ("Model Specific Registers", a cpu interface used for a wide variety of features) not known (by Xen) to be safe, are now disallowed; previously, they were allowed by default (with writes being largely ignored). This is a security and stability improvement but has some compatibility implications with some guests. The <code>msr_relaxed=true</code> option in `xl.cfg`, or the <code>msr=relaxed</code> hypervisor command line option, could help - see the documentation. If you find you need to use one of these please report this as a bug, so that we can update the hypervisor to not need this workaround, by providing the affected MSR(s) to the guest.
* Accesses to x86 MSRs ("Model Specific Registers", a cpu interface used for a wide variety of features) not known (by Xen) to be safe, are now disallowed; previously, they were allowed by default (with writes being largely ignored). This is a security and stability improvement but has some compatibility implications with some guests. The <code>msr_relaxed=true</code> option in `xl.cfg`, or the <code>msr=relaxed</code> hypervisor command line option, could help - see the documentation. If you find you need to use one of these please report this as a bug, so that we can update the hypervisor to not need this workaround, by providing the affected MSR(s) to the guest. Typically if this is needed, the symptom is a guest crash; the guest may mention a "GP fault", but it is likely that both Xen and the guest will ''not'' mention "MSR" anywhere.


* The very old qemu-xen-traditional device model is deprecated, and no longer security supported, when used as a host process. (It is still fully supported when used as a stub domain device model.)
* The very old qemu-xen-traditional device model is deprecated, and no longer security supported, when used as a host process. (It is still fully supported when used as a stub domain device model.)

* To enable the new support for zstd-compressed kernel/initramfs, zstd-devel needs to be installed. If it isn't, the support for zstd is disabled at build-time.


* In Xen 4.15 for ARM, we increased the minimum GCC support version.
* In Xen 4.15 for ARM, we increased the minimum GCC support version.

Revision as of 12:09, 7 April 2021

Overview

Xen Project 4.15.0 was released on 8th April 2021.

Xen Project 4.15.0 is the work of 9 months of development.

New Feature Highlights

The list of new features can be found on the following page: Xen Project 4.15 Feature List

You can find information on support status (including security support) for various features in SUPPORT.md and Hypervisor Support Matrix.

Documentation is available online: Xen 4.15 Documentation

Build Requirements

Xen requires gcc v4.1.2 or later (x86), gcc 4.9 or later (arm32), or gcc 5.1 or later (arm64).

Build

First of all you will have to get the Xen 4.15 source code, which you can either download through our release tarball (including signature) from our download page. Alternatively, you can get the source in the following way:

  • With a recent enough git (>= 1.7.8.2) just clone and checkout the proper tag (RELEASE-4.15.0) from the xen.git repo directly:
git clone -b RELEASE-4.15.0 https://xenbits.xen.org/git-http/xen.git

Build instructions can be found at Compiling Xen From Source or Compiling Xen From Source on NetBSD.

Changes affecting downstreams and users

In general, our aim is to keep old guests working on new versions of Xen, and to allow live migration from the previous Xen major version.

  • Accesses to x86 MSRs ("Model Specific Registers", a cpu interface used for a wide variety of features) not known (by Xen) to be safe, are now disallowed; previously, they were allowed by default (with writes being largely ignored). This is a security and stability improvement but has some compatibility implications with some guests. The msr_relaxed=true option in `xl.cfg`, or the msr=relaxed hypervisor command line option, could help - see the documentation. If you find you need to use one of these please report this as a bug, so that we can update the hypervisor to not need this workaround, by providing the affected MSR(s) to the guest. Typically if this is needed, the symptom is a guest crash; the guest may mention a "GP fault", but it is likely that both Xen and the guest will not mention "MSR" anywhere.
  • The very old qemu-xen-traditional device model is deprecated, and no longer security supported, when used as a host process. (It is still fully supported when used as a stub domain device model.)
  • To enable the new support for zstd-compressed kernel/initramfs, zstd-devel needs to be installed. If it isn't, the support for zstd is disabled at build-time.
  • In Xen 4.15 for ARM, we increased the minimum GCC support version.

Known issues

While we do the utmost to make the release perfect, there are always fixes which are not quite complete on time. We will add those here. So if you run into trouble, please check this section.

Currently known issues are:

  • Very recent versions of qemu mainline (qemu 6.0 and later - an RC at the time of writing) do not work as a device model.
  • Some quite new Intel systems which use "ITSSPRC static PIT clock gating" need a hypervisor command line option hpet=legacy-replacement. This should be tried if Xen panics at boot time, printing IO-APIC + timer doesn't work!

We hope to fix these issues in point releases.