@bogdantomasciuc Glad to hear. I was hoping it was just something missed or miss typed. If you can replicate the issue let me know. Its possible i might have missed that little nuance or something.

I finally got access to a machine with Intel Arc machine. There are issues around hvm-pirq, hence hvm-pirq=0 is required (see https://docs.xcp-ng.org/troubleshooting/common-problems/#pci-passthrough-error-unsupported-msi-delivery-mode-7). For some reason, Fedora Workstation has a issue with this GPU (a Fedora bug I guess), but CachyOS (desktop iso) works fine. Ran a clpeak bench, and performance looks normal for this class of GPU. Host-device transfer is a bit slower than "theorical", but definetely not PCIe 1x1 and more PCIe 3x8-ish (matching reality as it's plugged as PCIe 3.0). in-VM inxi -CGM Machine: Type: Xen System: Xen product: HVM domU v: 4.17 serial: 2c66cb09-57db-340c-ad8e-f505eb25ca3e Mobo: N/A model: N/A serial: N/A Firmware: UEFI vendor: Xen v: 4.17 date: 10/06/2026 CPU: Info: 6x 1-core model: Intel Xeon Silver 4112 bits: 64 type: SMP cache: L2: 6x 1024 KiB (6 MiB) Speed (MHz): avg: 2594 min/max: N/A cores: 1: 2594 2: 2594 3: 2594 4: 2594 5: 2594 6: 2594 Graphics: Device-1: driver: bochs-drm v: N/A Device-2: Intel Battlemage G21 [Arc Pro B50] driver: xe v: kernel Display: unspecified server: Xwayland v: 24.1.13 driver: gpu: bochs-drm tty: 212x48 API: EGL v: 1.5 drivers: iris,swrast platforms: gbm,surfaceless,device API: OpenGL v: 4.6 vendor: mesa v: 26.1.6-arch3.1 note: console (EGL sourced) renderer: Mesa Intel Arc Pro B50 Graphics (BMG G21), llvmpipe (LLVM 22.1.8 256 bits) API: Vulkan v: 1.4.357 drivers: intel surfaces: N/A Info: Tools: api: clinfo, eglinfo, glxinfo, vulkaninfo de: kscreen-console,kscreen-doctor gpu: gputop, intel_gpu_top, lsgpu, nvidia-smi wl: wayland-info x11: xdpyinfo, xprop, xrandr Raw numbers Backend: Vulkan Device 0: Intel(R) Arc(tm) Pro B50 Graphics (BMG G21) Driver version : 26.2.4 API version : 1.4.354 VRAM : 16048 MB Single-precision compute float : 9.47 TFLOPS float2 : 9.48 TFLOPS float4 : 9.52 TFLOPS Half-precision compute fp16xfp16+fp16 half : 18.3 TFLOPS half2 : 18.8 TFLOPS half4 : 19.1 TFLOPS Double-precision compute double : 650 GFLOPS double2 : 647 GFLOPS double4 : 640 GFLOPS Mixed-precision compute fp16xfp16+fp32 mp : 9.31 TFLOPS mp2 : 9.32 TFLOPS mp4 : 9.42 TFLOPS BF16 compute bf16xbf16+fp32 bf16 : 9.17 TFLOPS bf16_2 : 9.30 TFLOPS bf16_4 : 9.28 TFLOPS Integer compute int32 int : 1.81 TOPS int2 : 1.88 TOPS int4 : 1.82 TOPS INT8 dot-product compute int8_dp : 28.0 TOPS int8_dp2 : 26.3 TOPS int8_dp4 : 27.1 TOPS Cooperative matrix fp16 : 67.3 TFLOPS fp16 f16acc : 68.9 TFLOPS bf16 : 68.9 TFLOPS int8 : 141 TOPS Global memory bandwidth float : 196 GB/s float2 : 206 GB/s float4 : 212 GB/s Local memory bandwidth float : 2.55 TB/s float2 : 3.65 TB/s float4 : 4.23 TB/s Image memory bandwidth float4 : 213 GB/s Transfer bandwidth h2d : 4.81 GB/s d2h : 5.48 GB/s Kernel launch latency dispatch : 48.7 us roundtrip : 113 us Real performance is much higher than the "displayed" Speed 2.5GT/s, Width x1.

Good morning So I might've found an issue with this driver release. That I'm trying to troubleshoot and collect data on. We have two LUNs presented to our dev-pool (xcp-dev), running on R650xs. When I have attached one LUN to xcp-dev I can't see the other LUN. This works on our older R350s Removing the attached LUN, makes a LUN visible again. But now we're getting some strange behaviour. And looking into if it is misconfigured from the Dell Powerstore, or if it is on the host(s) itself. Details: multipath is enabled Host on xcp-dev 98:00.0 Fibre Channel [0c04]: Emulex Corporation LPe37000/LPe38000 Series 32Gb/64Gb Fibre Channel Adapter [10df:f500] (rev 11) Subsystem: Emulex Corporation Device [10df:f522] Kernel driver in use: lpfc Kernel modules: lpfc14 98:00.1 Fibre Channel [0c04]: Emulex Corporation LPe37000/LPe38000 Series 32Gb/64Gb Fibre Channel Adapter [10df:f500] (rev 11) Subsystem: Emulex Corporation Device [10df:f522] Kernel driver in use: lpfc Kernel modules: lpfc14 Update: After managing to revert my previous tests and forget the existing (wrong) LUN from xcp-dev. I can now confirm a problem. There are three LUNs. Let's call them 101, 102, 103 When I attach one LUN (103) to xcp-dev, I am no longer able to see the other LUNs. That means I can't add a second one. I am expecting to be able to see 102 available. However, on old-dev, that has two LUNs attached already (101 & 102). It can see 103 as expected. host on old-dev 02:00.0 Fibre Channel [0c04]: Emulex Corporation LPe12000 Series 8Gb Fibre Channel Adapter [10df:f100] (rev 03) Subsystem: Emulex Corporation LPe12000 Series 8Gb Fibre Channel Adapter [10df:f100] Kernel driver in use: lpfc Kernel modules: lpfc 02:00.1 Fibre Channel [0c04]: Emulex Corporation LPe12000 Series 8Gb Fibre Channel Adapter [10df:f100] (rev 03) Subsystem: Emulex Corporation LPe12000 Series 8Gb Fibre Channel Adapter [10df:f100] Kernel driver in use: lpfc Kernel modules: lpfc Second Update: This might be unrelated. Seems that we're having weird behaviour with the LUNs in general. Please disregard the statement above for now