Initial brief test seems ok
Will see if i can do more of the tests later...

Updated from 8.1 via yum which caused windows 10 & windows 2019 server to hang on the tiano logo.
Interestingly a debian 10 uefi vm worked fine...

After the update to uefistored both windows VMs started in recovery and did whatever it is windows does besides spin dots on your screen
After a reboot both Windows 10 2004 and windows 2019 server booted just fine

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?

@andSmv
Damn - i was quick and have a coral m2 A+E coming in a few days

It's just for fun/learning so as long as it doesn't break my homelab too much i will be willing to test so we might get it included
Already using the 4.17 test version without a hitch since it came out.

@Teddy-Astie

I think that is the patch i tested here:
https://xcp-ng.org/forum/topic/7066/coral-tpu-pci-passthrough/26?_=1730909872550

And no it made no difference...
I don't know if @andSmv has any more info? - ref. the thread above.

There seems to be a lot of work in the Xen repo on MSI stuff but i could not figure out what would be relevant for the Coral.

@stormi said in XCP-ng 8.3 betas and RCs feedback :

Optional package

• kernel-alt-4.19.316+1-2.xcpng8.3: Enable CONFIG_X86_AMD_PLATFORM_DEVICE in kernel config

I see some mentions of this option in relation to fan speeds.

But what is the status on AMD support in general?
I have a recent AMD platform, and from what i can see a lot has been added for AMD support in the past few kernel versions.
Particularly in relation to power management.

I did a purely unscientific test and booted a ubuntu 24.04 live cd on my XCP-NG server, and the power consumption was 10-15% lower at similar load level, compared to XCP-NG.

Is the hardware support for e.g. power management handled by the kernel in dom0 or by Xen?

What are the current plans for a more recent kernel for dom0 - i have not seen anything on kernel version plans for a long time?

Keep up the good work

@manilx said in EOL: XCP-ng Center has come to an end (New Maintainer!):

@redakula Hi,
This build stopped working with the latest beta 8.3 updates (last or last couple).
Worked before.

I just tested and it connects just fine for me to a fully up to date 8.3 install...

@manilx
I don't really use xcp-ng center so i don't know how stable but the build from january connects to 8.3 and seems to work?

https://github.com/xcp-ng/xenadmin/releases/tag/v.99.99.99.30

@andSmv

Thanks
Let me know and i will be happy to continue testing

@andSmv Thanks!

I tried to be as uninvasive as possible and changed the symbolic link xen.gz to point to the xen.gz from the RPM you created.

Unfortunately still the same error (It does seem to boot the xen from the RPM as this has version 4.17.3-3 vs. the one currently in the repos which has version 4.17.3-4).

[2024-05-24 17:06:33] (XEN) [  674.051176] Domain 14 (vcpu#2) crashed on cpu#22:
[2024-05-24 17:06:33] (XEN) [  674.051178] ----[ Xen-4.17.3-3  x86_64  debug=n  Not tainted ]----
[2024-05-24 17:06:33] (XEN) [  674.051179] CPU:    22
[2024-05-24 17:06:33] (XEN) [  674.051180] RIP:    0010:[<ffffffffa8581584>]
[2024-05-24 17:06:33] (XEN) [  674.051180] RFLAGS: 0000000000000286   CONTEXT: hvm guest (d14v2)
[2024-05-24 17:06:33] (XEN) [  674.051182] rax: ffffbd9c00149800   rbx: ffff9e9247cc9000   rcx: 0000000000000000
[2024-05-24 17:06:33] (XEN) [  674.051182] rdx: 00000000fee77000   rsi: 0000000000000000   rdi: 0000000000000000
[2024-05-24 17:06:33] (XEN) [  674.051183] rbp: ffffbd9c00327690   rsp: ffffbd9c00327658   r8:  0000000000000000
[2024-05-24 17:06:33] (XEN) [  674.051183] r9:  0000000000000000   r10: 0000000000000000   r11: 0000000000000000
[2024-05-24 17:06:33] (XEN) [  674.051184] r12: ffffbd9c003276ac   r13: 0000000000000011   r14: ffff9e92413390c0
[2024-05-24 17:06:33] (XEN) [  674.051185] r15: 0000000000000077   cr0: 0000000080050033   cr4: 0000000000750ef0
[2024-05-24 17:06:33] (XEN) [  674.051185] cr3: 0000000103806000   cr2: 0000000000000000
[2024-05-24 17:06:33] (XEN) [  674.051186] fsb: 00007b6e7a42a8c0   gsb: ffff9e925b500000   gss: 0000000000000000
[2024-05-24 17:06:33] (XEN) [  674.051186] ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: 0018   cs: 0010

It does appear that there is some movement upstream on this (if i interpret the xen mailing list correctly).
This patch series references the same title as the patch in this thread from 2022 and a bunch of other related work:
https://lore.kernel.org/xen-devel/cover.33fb4385b7dd6c53bda4acf0a9e91748b3d7b1f7.1715313192.git-series.marmarek@invisiblethingslab.com/

@andSmv
As expected the VM with the coral m2 crashes on boot.

Where would i start with building a custom Xen? The Koji docs seem directed at authorized package maintainers so would i need to build the sources directly from Xen?
Feeling old admitting it was in the 2.6 days i last regularly built custom kernels

@gecant

Yep - i just tried stressing a single core and got to 5.4GHz.

But would be nice to get power management also for these cpu's as they are pretty awesome

@gecant said in Non-server CPU compatibility - Ryzen and Intel:

@redakula Indeed, low power consuption on "amd_pstate" driver allows much lower frequencies down to 400 MHz.

That is what i suspected from the p-state driver being heavily developed in kernel 6.5 and 6.9... Hope we will get support soon in XCP-NG.
The 7900 is ridiculously overkill for most of my homelab use so each watt saved helps

Can you also please try to see the output of command xenpm start 1|grep "Avg freq" under some CPU load?
This allows to see the CPU frequency regardless of the available scaling frequencies.

For example, you can run in one VM stress-ng -c 4 to have 4 CPUs at full load and while this is running see the output of xenpm start 1|grep "Avg freq" on your Dom0 to see the CPU frequencies achieved under that stress.

Thank you.

Seems to scale above base frequency (3,7GHz for the 7900) just fine - but does not go below 3GHz. 5GHz is pretty close to the max boost of 5,4GHz.
System is running 8.3 Beta with xen 4.17.
This is running stress on a few cores:

[17:25 xenserver ~]# xenpm start 1|grep "Avg freq"
  Avg freq      2960000 KHz
  Avg freq      2960000 KHz
  Avg freq      2960000 KHz
  Avg freq      2923000 KHz
  Avg freq      2960000 KHz
  Avg freq      2960000 KHz
  Avg freq      2960000 KHz
  Avg freq      2960000 KHz
  Avg freq      2960000 KHz
  Avg freq      2960000 KHz
  Avg freq      3922000 KHz
  Avg freq      3108000 KHz
  Avg freq      5069000 KHz
  Avg freq      5069000 KHz
  Avg freq      5069000 KHz
  Avg freq      5069000 KHz
  Avg freq      2886000 KHz
  Avg freq      2886000 KHz
  Avg freq      5069000 KHz
  Avg freq      5069000 KHz
  Avg freq      2923000 KHz
  Avg freq      3034000 KHz
  Avg freq      5069000 KHz
  Avg freq      5069000 KHz

@gecant said in Non-server CPU compatibility - Ryzen and Intel:

If anyone with a Zen4 CPU can check the CPU frequencies that VMs are able to reach by default, I guess this would be useful.

I have a Ryzen 9 7900 which reports this:

[14:50 xenserver ~]# xenpm get-cpufreq-para 0
cpu id               : 0
affected_cpus        : 0
cpuinfo frequency    : max [3700000] min [3000000] cur [3000000]
scaling_driver       : powernow
scaling_avail_gov    : userspace performance powersave ondemand
current_governor     : ondemand
  ondemand specific  :
    sampling_rate    : max [10000000] min [10000] cur [20000]
    up_threshold     : 80
scaling_avail_freq   : 3700000 *3000000
scaling frequency    : max [3700000] min [3000000] cur [3000000]
turbo mode           : enabled

But i might have disabled boost in BIOS for power saving - i can check later

Also very interested in details on the support of newer Ryzens. From what i understand power management for new zen architectures is fairly recent in the kernel so i do wonder how well supported these cpu's are currently.
From xenpm output it does not appear to scale below 3GHz - my previous intel cpu would scale to 800MHz.