Xen Project 4.15 Release Notes: Difference between revisions
From Xen
Jump to navigationJump to search
IanJackson (talk | contribs) (zstd) |
IanJackson (talk | contribs) (tweaks) |
||
| 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> |
* 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>dom0=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 is likely to mention a "GP fault" in a backtrace, 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 kernels, zstd-devel needs to be installed. If it isn't, the support for zstd is disabled at build-time. |
* To enable the new support for zstd-compressed guest kernels, 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:47, 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=trueoption in `xl.cfg`, or thedom0=msr-relaxedhypervisor 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 is likely to mention a "GP fault" in a backtrace, 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 guest kernels, 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, printingIO-APIC + timer doesn't work!
We hope to fix these issues in point releases.
