@gduperrey
@olivierlambert

First of all ...... a BIG THANK YOU for this patch !

Tested on Minisforum AMD 7945HX based pc; and I can confirm that XCP-ng boots with ACPI PSS & C Cores as mentioned in this post and it works with both options enabled.

So excited that I have tested this only and replied before testing other things..

UPDATE :
While updating this, I actually had to do 2 updates (last stable update patch of 7 files + this one)

After this installation, GPU (Nvidia) passthrough completely seems to be broken. Before the update(s) the host had to be turnoff completely, power cable had to be removed and then replugged to reset the graphics card (which used to work as I was able to run the card); but now attaching the graphics card to VM makes the VM hang on VM boot and at times, the host is also abruptly restarted (as if someone as pressed the HW reset button).

I am not sure whether the problem is in this update or the last stable one; but graphics card reset for Nvidia ( I think it has to do with ACPI reset ) still remains a problem.

Would be great if you guys can look into this.

@stormi

Did minor testing. Seems ok.
Haven't tested Backups.

@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

@ronan-a @dthenot @Team-Storage

Guys, Can you please clarify which method to use for installing XOSTOR in XCP-ng 8.3 ?

Simple :

yum install xcp-ng-linstor
yum install xcp-ng-release-linstor
./install --disks /dev/nvme0n1 --thin

Or the script in the first post ?
Or Some other script ?

Installed fine. Didn't get a chance to deep dive and/or test features.

@stormi said in XCP-ng 8.3 updates announcements and testing:

A few days late because internal tests led to a few fixes, here are the pre-release ISO images for a refreshed XCP-ng 8.3 installer:

https://repo.vates.tech/tmp/

$ cat SHA256SUMS
22deae59e7c5cff7d4691c447af9dbf27b29a372748c1844c280bdc212ef2a5f  xcp-ng-8.3-20250606-linstor-upgradeonly.pre3.iso
9a5dcc8d98949ee207d28307b8b94320d1ffd24841e34ca74e1c0f0422e5ecab  xcp-ng-8.3-20250606-netinstall.pre3.iso
4d6f5a99da0d70920bc313470ad2b14decab66038f0863ca68a2b81126ee2977  xcp-ng-8.3-20250606.pre3.iso

1. No need to upgrade XCP-ng 8.3 with these. It is not a new release. It's refreshed installation images, with all updates included.
2. When we release them, at the same time, XCP-ng 8.3 will be officially labeled LTS. Again, the existing XCP-ng 8.3 that you already use. Not a new XCP-ng release.
3. This is also when XOSTOR becomes officially supported in XCP-ng 8.3 .

This is definitely the best part... I just installed XCP-NG on my test bench (a few days back) with the previous ISOs to test the updates !
Will try this ISO as soon as I get my new PC!
Was eagerly waiting to try XOSTOR in the meantime.

@olivierlambert @stormi

I have a suggestion w.r.t interface-rename.
Can we have a screen at the installation (using iso method) which lists all the NICs and we can rename the interfaces at install time itself ?

@olivierlambert
I don't mean to push or ask for an ETA; but since it's been a few months so I was wondering if there is any update on this ?
Waiting eagerly to have XOSTOR on 8.3

@stormi
Just for clarification sake (I know this might have been said before), installing patches is the same as upgrading from iso in this case ?
(Unlike with previous update where it was mandatory to upgrade using iso)

@olivierlambert
Sure.

@olivierlambert
+1 For creating vApps GUI in XO
Reason:
I recently had this configuration:

VM1 - Delay 90 Seconds
VM2 - Delay 100 Seconds
VM3 - Delay 0 Seconds

The VM3 instead of starting first, always starts last without fail.
One difference I noticed is that VM3 is UEFI vs VM1 & 2 being in BIOS mode.

I read elsewhere in the forum that vApps is the only reliable way to have an order.
Maybe if we can somehow ensure that delay works, vApps will become less significant ?

@rzr said:

I think you're right because the issue you are facing is reported by kernel itself (which was not updated), Can you please share more details about the hardware you're using (is any USB device involved ? try smartmon tools too) eventually post details in other sections of forum.

@rzr
CPU is AMD Ryzen 7 7840HS in a mini pc.

No USB involved in boot, but I do have an external USB HDD connected which is passed through to a VM (this should not effect boot)

What details are you looking for and where so you want me to post them ?

Update: I also tried on a AMD Ryzen 9 7945HX, which does not seem to have this message.

Do you think its USB related or motherboard/bios driver related ?

Hello,
After updating I get this:

This seems harmless as I don't have and scsi drive attached. But these messages were not there before.

Other than that, the server seems to boot fine.

Regards,

PS:
I have updated once for several updates (not one by one) so this messages may also be there in previous updates and may not be related to this particular update.

@exetico
I have updated my script.
Please use your previous install file (if you have it saved) to remove your previous version (remember to save your config before running uninstall), before you proceed to install the new version.

@stormi

Great Idea!
Post updated !

Update: I also added 'Automatic Backup' which backs up your original file in case something goes wrong.

@olivierlambert

I did post an alternative script here:
https://xcp-ng.org/forum/topic/8620/usb-passthrough-override-script-to-ensure-usb-policy-conf-consistency

But it was later removed due to request by @stormi .

I'm currently using my script which basically backs up your settings and overrides the default one (after backing it up on first install) on every boot. I know its a crude way to handle but it was only meant to be temporary till you guys find a solution.

I have reposted it.

Please note : Issues caused by this script (if any) shall not be covered by the XCP-NG Support Team 

@zeropointer @numo68
I have added my script back seeing so many people might require a solution.
I have also added automatic backup and change detection.

@olivierlambert

You can still pass the device even if it's not in xe pci-list. Use the lspci address to pass it directly to the VM via the xe CLI.

Thanks for the prompt response.

The docs say I need to pass xe pci-disable-dom0-access uuid=<pci uuid>
but the UUID is not present in the lspci.

Are you meaning the old method:

1. I edit grub or use /opt/xensource/libexec/xen-cmdline --set-dom0 "xen-pciback.hide=<lspci address>"
2. Asssign to VM using xe vm-param-set other-config:pci=0/<lspci-address> uuid=<vm-uuid>

Update:

I purchased Renesas Technology Corp. uPD720202 USB 3.0 Host Controller which is a controller that goes into PCI Express Slot (A/E Key, usually slot for WiFi cards) specifically for testing this.
The host seems to recognize the controller and also attaching the keyboard works.

However, XCP-NG does not show it in xe pci-list despite being available in lspci
Since its not available in xe pci-list, I am unable to assign it as a passthrough.

@TeddyAstie @olivierlambert
Guys, any help on how I can make the item available in xe pci-list so that I can continue my testing ?
Is there any reason or decision factor for XCP-NG to put/not put the controller in xe pci-list (maybe uses some kind of logic based on configuration files) ?

I have noticed that lspci and xe pci-list give different lists. However, only the xe pci-list items are pci-passthrough enabled.

Would depend on your urgent help to continue my test and diagnostics on this.

@gduperrey
@olivierlambert

First of all ...... a BIG THANK YOU for this patch !

Tested on Minisforum AMD 7945HX based pc; and I can confirm that XCP-ng boots with ACPI PSS & C Cores as mentioned in this post and it works with both options enabled.

So excited that I have tested this only and replied before testing other things..

UPDATE :
While updating this, I actually had to do 2 updates (last stable update patch of 7 files + this one)

After this installation, GPU (Nvidia) passthrough completely seems to be broken. Before the update(s) the host had to be turnoff completely, power cable had to be removed and then replugged to reset the graphics card (which used to work as I was able to run the card); but now attaching the graphics card to VM makes the VM hang on VM boot and at times, the host is also abruptly restarted (as if someone as pressed the HW reset button).

I am not sure whether the problem is in this update or the last stable one; but graphics card reset for Nvidia ( I think it has to do with ACPI reset ) still remains a problem.

Would be great if you guys can look into this.