fd55e2a13b
Bumping xen to version RELEASE-4.18.2-19-g01f7a3c792, which comprises the following commits:
01f7a3c792 update Xen version to 4.18.3-pre
7cdb1fa2ab x86/mtrr: avoid system wide rendezvous when setting AP MTRRs
f3d20dd317 tools/xentop: Fix cpu% sort order
dfabab2cd9 x86: respect mapcache_domain_init() failing
3999b675ca xen/sched: set all sched_resource data inside locked region for new cpu
8271f0e8f2 libxl: Fix handling XenStore errors in device creation
9966e54131 libxl: fix population of the online vCPU bitmap for PVH
a42c83b202 x86/ucode: Distinguish "ucode already up to date"
0673eae8e5 x86/cpu-policy: Fix migration from Ice Lake to Cascade Lake
2bc52041ca tools/libxs: Open /dev/xen/xenbus fds as O_CLOEXEC
a4c5bbb9db VT-d: correct ATS checking for root complex integrated devices
47cf06c09a xen/x86: Fix Syntax warning in gen-cpuid.py
026542c857 xen/xsm: Wire up get_dom0_console
f0ff1d9cb9 x86/spec: adjust logic that elides lfence
0b0c7dca70 x86/spec: fix reporting of BHB clearing usage from guest entry points
eb7059767c x86/MTRR: correct inadvertently inverted WC check
af0e9ba44a x86/rtc: Avoid UIP flag being set for longer than expected
8bdcb0b98b altcall: fix __alt_call_maybe_initdata so it's safe for livepatch
2d38302c33 x86/entry: Fix build with older toolchains
d152a04246 Update CHANGELOG.md with 4.18.2 line
b2863e468e Update Xen version to 4.18.2
40f2c69ad8 x86/spec-ctrl: Support the "long" BHB loop sequence
9be85b14aa x86/spec-ctrl: Wire up the Native-BHI software sequences
72a357f4fa x86/spec-ctrl: Software BHB-clearing sequences
73a4229807 x86/spec-ctrl: Support BHI_DIS_S in order to mitigate BHI
2be76f2018 x86/tsx: Expose RTM_ALWAYS_ABORT to guests
62844c4415 x86: Drop INDIRECT_JMP
9fd732d18d x86: Use indirect calls in reset-stack infrastructure
40a6795480 x86/spec-ctrl: Widen the {xen,last,default}_spec_ctrl fields
fb12e8d8f7 x86/vmx: Add support for virtualize SPEC_CTRL
a6cefb2686 x86/spec-ctrl: Detail the safety properties in SPEC_CTRL_ENTRY_*
ccc6603b79 x86/spec-ctrl: Simplify DO_COND_IBPB
5b28a4af1f x86/spec_ctrl: Hold SCF in %ebx across SPEC_CTRL_ENTRY_{PV,INTR}
9bc337497c x86/entry: Arrange for %r14 to be STACK_END across SPEC_CTRL_ENTRY_FROM_PV
e382cddcc2 x86/spec-ctrl: Rework conditional safety for SPEC_CTRL_ENTRY_*
57e5cab3de x86/spec-ctrl: Rename spec_ctrl_flags to scf
32cdecf1c3 x86/cpuid: Don't expose {IPRED,RRSBA,BHI}_CTRL to PV guests
a482be9211 x86/alternatives: fix .init section reference in _apply_alternatives()
855e261337 x86/tsx: Cope with RTM_ALWAYS_ABORT vs RTM mismatch
125b1a7808 x86/spec-ctrl: Move __read_mostly data into __ro_after_init
594dd0920f VMX: tertiary execution control infrastructure
4c2208d06c x86/CPU: convert vendor hook invocations to altcall
8a8c626281 x86/guest: finish conversion to altcall
b6fad02a54 x86: arrange for ENDBR zapping from <vendor>_ctxt_switch_masking()
0f6696a780 x86/spec-ctrl: Expose BHI_CTRL to guests
a546399829 x86/spec-ctrl: Expose RRSBA_CTRL to guests
fa7f2f9a86 x86/spec-ctrl: Expose IPRED_CTRL to guests
1fe30f552a IRQ: generalize [gs]et_irq_regs()
f7bd03b608 x86/MCE: switch some callback invocations to altcall
9fdbcd84d3 x86/MCE: separate BSP-only initialization
b06cf0701a x86/PV: avoid indirect call for I/O emulation quirk hook
a2922d8097 x86/MTRR: avoid several indirect calls
5c5d4eeee4 core-parking: use alternative_call()
ba951c5f29 x86/HPET: avoid an indirect call
a44c2c9f89 cpufreq: finish conversion to altcall
6b8ee35088 x86/APIC: finish genapic conversion to altcall
6d4055b9a5 x86/spec-ctrl: Fix BTC/SRSO mitigations
1166467ed3 hypercall_xlat_continuation: Replace BUG_ON with domain_crash
429a125dba x86/HVM: clear upper halves of GPRs upon entry from 32-bit code
17cf285d87 tests/resource: Fix HVM guest in !SHADOW builds
5c4aacab17 x86/boot: Support the watchdog on newer AMD systems
a790c670bb x86/boot: Improve the boot watchdog determination of stuck cpus
d0173bbed1 x86/livepatch: Relax permissions on rodata too
4fc27254de xen/virtual-region: Include rodata pointers
8c13f6c565 xen/virtual-region: Rename the start/end fields
b576e09b66 x86/cpu-policy: Fix visibility of HTT/CMP_LEGACY in max policies
03cc579ae3 x86/cpu-policy: Hide x2APIC from PV guests
0a8b92d0a4 tools/oxenstored: Make Quota.t pure
3f3158fc32 tools/oxenstored: Use Map instead of Hashtbl for quotas
c9ea3b49a5 x86/PoD: tie together P2M update and increment of entry count
cb7b84d3d5 x86/boot: Fix setup_apic_nmi_watchdog() to fail more cleanly
62d9ca19f9 x86/mm: use block_lock_speculation() in _mm_write_lock()
3d67ba0371 update Xen version to 4.18.2-pre
ea82c8cdbf update Xen version to 4.18.1
4da8ca9cb9 x86: protect conditional lock taking from speculative execution
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
||
|---|---|---|
| .. | ||
| files | ||
| README | ||
| README.test | ||
| xen_4.17.bb | ||
| xen_4.18.bb | ||
| xen_git.bb | ||
| xen-arch.inc | ||
| xen-blktap.inc | ||
| xen-hypervisor.inc | ||
| xen-tools_4.17.bb | ||
| xen-tools_4.18.bb | ||
| xen-tools_git.bb | ||
| xen-tools.inc | ||
| xen.inc | ||
| xtf_git.bb | ||
Xen
For any issues with the Xen recipes please make sure you CC: christopher.w.clark@gmail.com cardoe@gentoo.org
configuring the hypervisor
Since 4.7.0 Xen supports using Kconfig to configure the hypervisor. Similarly to how the recipe for busybox works, you can provide a .config as a defconfig to override the default configuration of the hypervisor. The easiest way for you to take advantage of this is to create a .config for Xen and then copy it to your Yocto layer as 'defconfig' inside of 'recipes-extended/xen/files/' and then create a bbappend adding 'file://defconfig' to your SRC_URI.
To generate your own .config file for Xen, you can use the interactive menuconfig via bitbake:
bitbake xen -c menuconfig
Select the config settings that you want and Save the file. If you save it to the default ".config" file when prompted by menuconfig, you can find it in the 'xen' subdirectory of the build tree.
Configuration fragments are also supported. To use them you need to list the .cfg files in the SRC_URI.
security patches
The base recipe does not include security fixes that the Xen community releases as XSAs (http://xenbits.xen.org/xsa/). The easiest way to include those is to drop patches in 'recipes-extened/xen/files' and create a bbappend adding those patches to SRC_URI and they will be applied. Alternatively, you can override the SRC_URI to a git repo you provide that contains the patches.
recipe maintenance
Xen version update
The following rules shall be followed to define which versions of Xen have recipes in meta-virtualization:
-
Before a Yocto release meta-virtualization shall have recipes for:
-
the latest stable major version of Xen, and
-
the current version of the Xen master branch (known as the git recipes)
-
In addition, there may also be recipes included for the previous stable major version of Xen, in the case where the latest stable major version is new and the prior stable major version of Xen is to be the preferred version for the Yocto release
-
-
On Yocto LTS and the latest stable Yocto release branch, the preferred Xen major version that is present when the Yocto release is issued must stay supported and the recipes shall be regularly updated to follow updates available in the Xen stable branch for that Xen major release.
-
On Yocto LTS and the latest stable Yocto release branch, the recipes for the latest Xen major version shall also be regularly updated to follow updates available in the Xen stable branch for that Xen major release.
-
On the master / in-development Yocto branch, new Xen recipes shall be added when there is a new Xen major release.
-
depending on the timing of the next Yocto release, the new recipes may be preferred, or the prior major version recipes may remain preferred until after the Yocto release
-
the recipes for the previous Xen stable major version shall be removed from the branch when it is no longer the preferred Xen version
-
-
On Yocto LTS and the latest stable Yocto release branch, new Xen recipes shall be added when there is a new Xen major release.
-
The preferred version of the Xen recipes shall always stay at the same Xen major version once a Yocto release has been issued, and shall receive regular updates to track the stable Xen branch of that Xen release.
-
When new Xen recipes are added to a Yocto branch for a new Xen major version, then any older Xen recipes present, except for the original preferred version recipes, shall be marked as not updated anymore by adding a comment inside the recipes. The older recipes will not receive any build tests or be updated to follow the Xen branch.
-