Hello,
The hang bug will be fixed in a future release of Xen, but Windows requires enabling all Viridian extensions (currently 6) to ensure optimal performance and reliability. Enabling Viridian extensions also fixes the hang bug via a different way.
On Windows guests, please reenable all Viridian extensions using these instructions: https://docs.xcp-ng.org/vms/#enabling-viridian-extensions
Hello all,
Version 9.2.445 of the XCP-ng Windows Guest Tools has been released.
Download the latest release here: https://github.com/xcp-ng/win-pv-drivers/releases
This release brings important bug fixes to the Windows drivers and installer.
Important note for users upgrading from 9.2.350: You must first install the XenTools-fix-9.2.351.msp hotfix to upgrade to 9.2.351 before installing 9.2.445. Otherwise, upgrades from 9.2.350 will be blocked. Reboot is not required after installing the hotfix.
The installer downloads include a copy of XenClean and XenBootFix. It is not necessary to run XenClean when upgrading from previous versions of the XCP-ng Windows guest tools, unless prompted by the installer. Remember to carefully read XenClean docs before use.
Note: Always download the latest XenClean/XenBootFix from https://github.com/xcp-ng/win-pv-drivers/releases . You can find them in the latest release ZIP/ISO archives.
Thank you for using our Windows PV tools. Please carefully read the instructions below.
If you encounter installation/uninstallation errors, please try again with one of the following commands:
For installing:
msiexec.exe /i XenTools-x64.msi /l*vx install.log
For uninstalling:
msiexec.exe /x XenTools-x64.msi /l*vx uninstall.log
Please include this log along with the file C:\Windows\INF\setupapi.dev.log in your bug report. These files will help us troubleshoot any installation issues.
Additionally, please report any errors or BSOD you encounter during testing of this release. Your feedback is very appreciated.
@XCP-ng-JustGreat Windows VMs will pass the Measured Boot check even after an edk2 update if BitLocker is set up to only use Secure Boot for integrity validation (see the "Configure TPM platform validation profile for native UEFI firmware configurations" policy, PCRs 7 and 11)
@fred974 Hello,
Could you please provide the logs produced by XenClean after its execution?
If your VM couldn't boot after XenClean, XenBootFix executed from a recovery environment should get your VM working again.
Instructions are available here: https://docs.xcp-ng.org/troubleshooting/windows-pv-tools/#windows-fails-to-boot-hangs-inaccessible_boot_device
I'm also investigating on a solution to make XCP-ng opportunistically resize device BAR; in case the firmware didn't do it (or has no support for it).
Did some investigations.
TL;DR: You have Resized BARs for the Intel Arc (and any device) in VMs, iff you have Resizable BAR feature enabled in the firmware.
64-bits BAR works inside guests. BARs too large to fit in the legacy area ("MMIO hole") are going to be placed over TOM (above guest RAM).
However, the logic to resize the BAR dynamically isn't available in the guest. If the device BAR starts at 256 MB, the guest won't be able to resize it.
When Resizable BAR feature is enabled in the firmware, device BARs that can be resized are resized to their maximum early at boot, hence the device will have large BARs in XCP-ng.
Such BAR are passed through entirely, iow, you have resized BARs in the guest, this shows up in @jamesg guest lspci https://xcp-ng.org/forum/topic/12316/pcie-pass-through-lanes-and-lane-performance/12?_=1793630786768
In cases firmware has no support for "Resizable BAR" but has support for 64-bits BARs, Resizable BAR can be triggered manually from Dom0 through /sys/bus/pci/devices/.../resourceN_resize (yet, it's still going to be tricky to use in practice), but that's not a kernel feature available as of XCP-ng 8.3.
@acebmxer Hello, could you look into the xen and kernel logs for errors?
Consider this feature as experimental Many Intel CPUs have support for Intel APICv (APIC Virtualization) features that aims at reducing the number of APIC-related VM-Exits in guests, hence improving performance.
This has been introduced circa Intel Ivy Bridge-EP, and is also available on somewhat recent client CPUs as well. But keep in mind that not all SKUs have support for it.
Xen has support for it since roughly Xen 4.3, yet XenServer (and XCP-ng) originally disabled by default due to issues at this time around live migration between hardware that supports it and ones that don't.
Internal testing on the feature shows performance improvements in various benchmarks (5-10% in I/O benchmarks up to 30% on nginx with a Ice Lake Xeon). We didn't test on other CPUs, but older CPUs (in particular those affected by L1TF/Foreshadow) may observe larger improvements.
This feature exists in the Xen version shipped in XCP-ng, but disabled by default, you can enable support on the host with
/opt/xensource/libexec/xen-cmdline --set-xen apicv=1
# then reboot
Once enabled, you can check hardware support with
xl dmesg | grep -A 25 "VMX: Supported advanced features"
And look for APIC Register Virtualization and Virtual Interrupt Delivery.
The feature can be disabled with
/opt/xensource/libexec/xen-cmdline --delete-xen apicv
# then reboot
Along with general feedback on the feature (does it work, supported hardware, ...), we're interested on :
AMD counterpart is AVIC (Advanced Virtualized Interrupt Controller) introduced (in practice) with Zen 2 (but also existed on some Carrizo CPUs) then improved with x2AVIC with Zen 4.
Xen support for (x2)AVIC is currently work in progress.
Refer to Denis Mukhin's presentation on AVIC for Xen (Xen Summit 2026) : https://youtu.be/RhaJsOU_PIA
|
20
Posts
16
Reputation
|
|
180
Posts
55
Reputation
|
|
2
Posts
1
Reputation
|
