On Thursday, November 26, 2020 6:26 PM, Alex Smirnoff <arke...@gmail.com> wrote:

> It is rather a xen issue, but I did not find xen groups alive enough, so..
> I have a 6-core cpu, so.. xen thinks there are two "CPU's" per core, probably 
> due to HT.
> And it does, apparently, cause a lot of confusion.
> from "xenpm start 1:
> Socket 0
> Core 0 CPU 0
> Core 1 CPU 2
> Core 2 CPU 4
> Core 3 CPU 6
> Core 4 CPU 8
> Core 5 CPU 10
> But, when I try to get CPU states, xenpm assumes the core count to the cpu 
> count! thus, it tries to get status of CPU0-CPU5, which succeeds only for 
> even CPUs, odd CPUs get dropped and return error when xenp tries to control 
> them, and CPU6-CPU10 are ingored.
> also, xenpm get-cpufreq-para returns obviously incorrect values (for even 
> CPUs only, again, for odd ones it just "falied to get cpufreq parameter" and 
> 6-10 are igored), as well as xentop. At the same time, values at 
> get-cpufreq-average are apparently right.
> Is it a known issue?

Yes, similar things mentioned here 
https://github.com/QubesOS/qubes-issues/issues/4252 and here 
Additional logical cores have been disabled in Qubes OS to mitigate serious 
vulnerability https://www.qubes-os.org/news/2018/09/02/qsb-43/ , in this QSB it 
is also shown how to re-enable Hyper-Threading (SMT), though it's not 

To make xenpm show only physical cores disable Hyper-Threading in UEFI 
(suggested in issue 4252).

But to make it show correct frequencies it may be needed 1) disable GT in UEFI 
2) re-enable SMT in xen.cfg (it shouldn't have adverse effects since HT already 
disabled in UEFI)

You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Reply via email to