Team - Hypervisor Kernel group | XCP-ng and XO forum

TeddyAstie

FYI I will get my hands on a Intel Arc Pro B50 to make various tests with it (in the next weeks). If something don't behave as expected, I will try to find a solution.

dinhngtu

@clip Just right-click the icon and select Hide, which will stick across reboots for you. You can also set this via Registry (using GP preference if you wish):

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\XCP-ng\XenPlus]
"ShowTrayIcon"=dword:00000000

dinhngtu

@Greg_E NTP sync assist will work with any W32Time time sources, AD or external.

dinhngtu

Hello all,

Version 9.2.350 Release of the Windows guest tools has been released.

Download the latest release here: https://github.com/xcp-ng/win-pv-drivers/releases

It will be integrated into the XCP-ng built-in tools ISO after a test period of 2 weeks.

This major release brings a new Windows guest agent with many new features, plus multiple other improvements.

To download XenClean, click here. The installer downloads also includes 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

Before installing

Thank you for using our Windows PV tools. Please carefully read the instructions below.

It is not necessary to run XenClean when upgrading from previous versions of the XCP-ng Windows guest tools, unless prompted by the installer.
Not compatible with the "Manage Citrix PV drivers via Windows Update" option. You must disable this option before installing.

Changes since 9.1.200

NEW: Overhauled Windows guest agent with many new features:
- Supports configuring guest IP addresses from within the host using xe vif-configure-ipv4 and xe vif-configure-ipv6.
- Session agent now gains a tray icon and About dialog.
- Improved clipboard sync stability and accuracy.
- Better reporting of OS versions.
- Time sync is now integrated with W32Time. NTP is now the only recommended setup for time sync on XCP-ng Windows guests.
Improved: Update XSTDVGA to v0.1.211.1039; improve compatibility.
Improved: Better reporting of IPv6 addresses.
Fixed: Better network stability during high load.
Fixed: Storage driver bug fixes.
Fixed: Better installer resilience when the offboard task is pending.

Help / Community support

If you encounter installation/uninstallation errors, please try again with one of the following commands:

For installing:
msiexec.exe /i XenTools-x64.msi /log install.log

For uninstalling:
msiexec.exe /x XenTools-x64.msi /log 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.

Discussion: https://xcp-ng.org/forum (preferred)
Issue Tracker: https://github.com/xcp-ng/xcp/issues
IRC: #xcp-ng and #xcp-ng-dev on irc.freenode.net

Full Changelog: https://github.com/xcp-ng/win-pv-drivers/compare/v9.1.200...v9.2.350
Original build: https://github.com/xcp-ng/win-pv-drivers/actions/runs/31088530595

dinhngtu

@kagbasi-wgsdac Normally, this issue has already been fixed upstream since a long time.
XS tools 9.4.0 is pretty old, you should update to 9.6.0 which should contain a newer Xenbus balloon driver.
Better yet, you can switch to the XCP-ng tools (as you've done), since the XCP-ng tools are what we now recommend for all Windows guests.
A new version of the XCP-ng tools is coming out soon with lots of improvements.

You can check for the driver version by running this command on the host:

xe vm-param-get uuid=<VM UUID> param-name=PV-drivers-version

For XS 9.6.0, I'd expect it to report xenbus: XenServer 9.1.13.23.

yannsionneau

@steff22
I am making good progress on this and I will soon have some packages to share for people to try and give feedback

TeddyAstie

@JamesG

You can't PCI Passthrough a PCI bridge (and even if you could, it wouldn't be very useful), as it's a part of PCI internals and not really something the guest requires to use the device.

As I asked previously, is there any issue (aside display like PCIe 1.0 1x) with the device, is it behavior correctly or having the expected performance ?

yannsionneau

Just FYI, we had some issues with some Debian VMs for instance, with old kernel
where the VM would suddenly take 100% CPU and would we completely frozen and unresponsive.
It was in fact Debian enabling the suspend, the guest would suspend and trigger a bug in xen PV driver in the guest kernel which would never be able to wake up anymore.
Newer kernel don't have this issue and are able to wake up.
I'm quoting Debian here but it might very well happen on other distro

TeddyAstie

@ravenet said:
@teddyastie separate from the above, a standing question whenever you have a minute: is it expected that passthrough GPU MSIs are never delivered at all on 8.3? Both my working rig and PessimistTech's broken one show the amdgpu xen-pirq MSI vector at zero on all CPUs, forever — everything survives on driver-side polling. It works, but it means any driver path that hard-depends on an interrupt has no safety net, and I suspect it's why the amdgpu ring resets in his log keep failing. Curious whether that's a known limitation of the pirq MSI path for passthrough devices or something worth a ticket.

TL;DR This is likely a known issue, and we're currently discussing on a potential fix.

There is a known bug regarding MSI on AMDGPU when using "hvm_pirq" ("use event channels for device interrupts"), see
https://lore.kernel.org/xen-devel/20240110095311.61809-1-roger.pau@citrix.com/
https://github.com/QubesOS/qubes-issues/issues/7971

The easy fix is to disable "HVM PIRQ" feature (which has been made disabled by default in Xen 4.19), but on the XCP-ng side, this is configured by XAPI Project which needs to be updated as well to apply this change (which appears to be a bit tricky for various reasons).

TeddyAstie

@PessimistTech
That looks a bit odd indeed.

In addition to what proposed @yannsionneau, can you also give the output of :

xl dmesg (in Dom0)
dmesg (in Dom0)
dmesg (in the guest)

So that we can try to pin-point what may be happening.