On 02/11/18 16:40, Jan Beulich wrote:
> The system Intel have handed me for AVX512 emulator work ("Gigabyte
> Technology Co., Ltd. X299 AORUS Gaming 3 Pro/X299 AORUS Gaming 3
> Pro-CF, BIOS F3 12/28/2017") would not come up under Xen - it hung in
> the middle of Dom0 PCI initialization. As it turned out, Xen's time
> management did not work because of the firmware setting (only) the boot
> CPU's TSC_ADJUST MSR to a large negative value (on the order of -2^50).
>
> Follow Linux (also shamelessly stealing their comments) in
> - clearing the register for the boot CPU (we don't have a need for
> exceptions here yet, as the only exception in Linux is a class of
> systems Xen doesn't work on anyway as far as I'm aware),
> - forcing non-negative values uniformly (commit 855615eee9 ["x86/tsc:
> Remove the TSC_ADJUST clamp"] dropped this, but without this my
> Haswell box won't boot anymore),
> - syncing the registers within sockets.
> Linux, prior to aforementioned commit, capped at 0x7fffffff as well, but as
> the
> description there says this issue has been addressed with a microcode
> update. Hence until someone runs into such a system without being able
> to update its microcode, I think we should leave out that specific part.
>
> In order to avoid making init_percpu_time() depend on running _before_
> set_cpu_sibling_map() (and hence the booting CPU _not_ being accounted
> in socket_cpumask[] yet), move that call slightly earlier in
> start_secondary().
>
> Signed-off-by: Jan Beulich <jbeul...@suse.com>
Acked-by: Andrew Cooper <andrew.coop...@citrix.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
