Xen 4.17 on XCP-ng 8.3!
-
@stormi Thanks! 4.17 Installed and running on a NUC10. Things seem to be working, but it's just a test... And for everyone who will ask... No, Windows Hyper-V server does not work (as expected).
-
@stormi I have it up and running on an HP Microserver N36L. Both of my test VMs work as they did before the update. One is running Alpine Linux 3.19.1 using UEFI secure boot and the other is a Windows Server 2008 R2 setup using Citrix drivers and agent.
-
Installed on a HP EliteDesg 800 G3 Mini running 6VMs Linux nad FreeBSD all iwith UEFI one Linux with vTPM so far no issues. Will keep monitoring and testing.
-
setting it up on a dell poweredge r720 with 3 vms (2 debian 1 freebsd)
will report if i encounter any issues -
Just updated to the latest on a dell T430, all seems to be working as expected.
-
Testing now on ryzen 1700.
-
Running stable as always for a couple of days so far
- homelab with 10-15 vms.Is there anything in particular we should be testing in order to help test 4.17?
-
@redakula That the system works fine on your hardware with your usual load is a good test already.
Now the most motivated might try to produce before/after benchmarks, but I don't know myself exactly what kind of benchmarks would be appropriate.
-
ive been running it for 3 days so far with no issues, everything seems to be working fine
-
@stormi Intel 9th gen on C242 chipset if you are keeping track of hardware.
Not 100% sure if it is related (but i believe it was working before updating) but stats are unavailable in XOfor both host and VM's. Simply says "No stats."
XO from sources and fully up to date on the latest commit.Can anyone else check if they have stats in XO?
-
@redakula That's a known issue that was due to 2 problems, and both are fixed for the end of the month
-
S stormi referenced this topic on
-
New updates are available in
xcp-ng-labfor Xen 4.17.Update with:
yum update --enablerepo=xcp-ng-labThen reboot.
Here's the changelog, from XenServer's development repository for Xen:
* Tue Feb 13 2024 Andrew Cooper <andrew.cooper3@citrix.com> - 4.17.3-2 - De-virtualise more function pointers, based on boot time configuration - Improve the performance of IOMMU construction for dom0 - Fix a bug with the determination of IVMD memory regions - Fix inefficiencies with XEN_{SYS,DOM}CTL_getdomaininfo{,list} - Fix undefined behaviour in compat_set_timer_op() - Fix the Raw CPU Policy rescan when CPUID Masking is active -
After the update, besides testing manually, there is another way you can contribute to the testing of Xen 4.17 for XCP-ng.
- Run XTF: https://docs.xcp-ng.org/project/development-process/tests/#test-the-xen-hypervisor-itself
- Run xen-dom0-tests: https://docs.xcp-ng.org/project/development-process/tests/#xen-dom0-tests
In order not to flood this thread with your test results:
- only share the output if there's an error, or when in doubt
- you can quote errors here, but if you think it's useful to share the full output, then please use https://paste.vates.tech.
If you have extra hosts you can temporarily dedicate to this, even if you don't have any VMs to run on them, you can very well take part in the testing effort by installating XCP-ng 8.3 beta2, updating, installing Xen 4.17, and then running these automated tests.
The more diverse hardware we get to test, the better.
-
@stormi I already installed 4.17 before, now doing today's update
yum update --enablerepo=xcp-ng-labwants to install from both lab and base, but they conflict because yum picks base. This happens for all of the updated lab packages, not just one in the example:---> Package forkexecd.x86_64 0:23.31.0-1.1.0.xen417.2.xcpng8.3 will be updated ---> Package forkexecd.x86_64 0:23.31.0-1.5.xcpng8.3 will be an update Updating: forkexecd x86_64 23.31.0-1.5.xcpng8.3 xcp-ng-base 1.7 Mhttps://paste.vates.tech/?f4dea5fc787301a9#6XKfAJyxkRjuLVkrJVznRJpV3x1VQVL5NE2oaRLHKWA7
-
@stormi Never mind....
yum update --enablerepo=xcp-ng-labis working now on that system... -
@stormi
HP DL360p G8 (Xeon E5-2680) XCP 8.3 Xen version 4.17.3-2- Dom0 ALL TESTS PASSED.
- xtf selftest SUCCESS.
- xtf all tests SKIP/SUCCESS.
Intel NUC10 (i5-10210U) XCP 8.3 Xen version 4.17.3-2
- Dom0 ALL TESTS PASSED.
- xtf selftest SUCCESS.
- xtf HARD system freeze at test-hvm64-xsa-304. (only XCP hard lockup I have seen)
- xtf With
ept=no-exec-sp, all tests SKIP/SUCCESS.
-
WHAT THIS VERSION OF XEN CHANGES
I must admit I haven't done my homework yet here. You can check the upstream changelogs at the Xen Project. I'll update this post if someone provides a useful bullet list.
Here you go :
Notable Features
This release has seen the increase in hardware support for both x86 and Arm, together with the addition of other improvements and features:- MISRA-C integration: The project has officially adopted four directives and 24 rules, added MISRA-C checker build integration, and defined how to document deviations. A number of MISRA-C violations have been fixed.
- Static configuration options for ARM: In many embedded environments, we know ahead of time exactly what resources all guests will need at boot time. In constrained resource environments, allocation on use increases the possibility that the allocation will fail at runtime. With static configuration, resources are allocated statically when the hypervisor boots, removing the possibility of runtime failure. Resources which can be statically configured as of 4.17 include event channels, shared memory, and hypervisor heap.
- ARM: Add “tech preview” implementation for VirtIO. Xen now includes full support for VirtIO on embedded systems, on ARM, for the virtio-mmio transport, allowing a wide range of VirtIO devices to be supported. This includes front-end support in Linux, toolstack (libxl/xl) and dom0less support, and a userspace backend. Currently, the following stand-alone backends are available and have been tested: virtio-disk, virtio-net, i2c, and gpio.
- dom0less / Hyperlaunch: cpupools can be specified at boot using device tree. This allows the use of cpupools in dom0less / Hyperlaunch -style configurations; in particular, it makes it possible to assign different types of CPUs of an ARM big.LITTLE system to different cpupools at boot time.
- dom0less / Hyperlaunch: PV frontend / backend connections can now be specified between guests, allowing statically booted guests with PV devices
- On ARM, p2m structures are now allocated out of a pool of memory set aside at domain creation; this provides better isolation between guests against memory resource failures
- ARM: Mitigations against Spectre-BHB
- x86: IOMMU superpage support for all guest types; improving performance of PCI pass-through
- x86: Security support hosts with up to 12 TiB of RAM
- x86: Can now set cpuid parameters for dom0 at boot time
- x86: mwait-idle support: Added SPR and ADL
- x86: Improved speculative mitigation support, including VIRT_SSBD and MSR_SPEC_CTRL features to help guests know what speculative mitigations they don't need to be done (due to mitigations on the hypervisor side), and to control what kind of speculative mitigations the hypervisor performs on their behalf
- Out-of-tree builds for the hypervisor now supported
- ARM: Since addition of Zephyr RTOS guests support (Xen 4.15, Zephyr 3.1.0), work has been done on making it possible to run Zephyr in dom0 improving boot time, stability and paving the way for future safety certification for Xen-based systems
Source : https://wiki.xenproject.org/wiki/Xen_Project_4.17_Feature_List
-
@gb-123 Thanks! I updated the first message.
-
@Andrew said in Xen 4.17 on XCP-ng 8.3!:
xtf HARD system freeze at test-hvm64-xsa-304. (only XCP hard lockup I have seen)
xtf With ept=no-exec-sp, all tests SKIP/SUCCESS.It's guest exploitable, and locks up the CPU so hard it doesn't even reset properly. It's also very expensive to work around, hence why it's not mitigated by default.
-
dell poweredge r720 with dual xeon e5-2670
all tests successful or skipped on xtf and dom0 (without setting no-exec-fp)
