Xen 4.17 on XCP-ng 8.3!

JeffBerntsen

@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.

bufanda

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.

kait

setting it up on a dell poweredge r720 with 3 vms (2 debian 1 freebsd)
will report if i encounter any issues

caponate

Just updated to the latest on a dell T430, all seems to be working as expected.

ravenet

Testing now on ryzen 1700.

redakula

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?

stormi

@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.

kait

ive been running it for 3 days so far with no issues, everything seems to be working fine

redakula

@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?

olivierlambert

@redakula That's a known issue that was due to 2 problems, and both are fixed for the end of the month

stormi

New updates are available in xcp-ng-lab for Xen 4.17.

Update with:

yum update --enablerepo=xcp-ng-lab

Then 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

stormi

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.

Andrew

@stormi I already installed 4.17 before, now doing today's update yum update --enablerepo=xcp-ng-lab wants 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 M

https://paste.vates.tech/?f4dea5fc787301a9#6XKfAJyxkRjuLVkrJVznRJpV3x1VQVL5NE2oaRLHKWA7

Andrew

@stormi Never mind.... yum update --enablerepo=xcp-ng-lab is working now on that system...

Andrew

@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.

gb.123

@stormi

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

stormi

@gb-123 Thanks! I updated the first message.

andyhhp

@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.

XSA-304 is https://www.intel.com/content/www/us/en/developer/articles/troubleshooting/software-security-guidance/technical-documentation/machine-check-error-avoidance-page-size-change.html

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.

kait

dell poweredge r720 with dual xeon e5-2670
all tests successful or skipped on xtf and dom0 (without setting no-exec-fp)

Ajmind 0

Server:

Intel S5520UR Dual Xeon E5645

Dom0 all Tests passed
xtf selftest SUCCESS
xtf expected skip results SKIP/SUCCESS
except:

test-pv64-cpuid-faulting                 SKIP
test-pv64-pv-fsgsbase                    SKIP
with or without xl set-parameters ept=no-exec-sp