Em qua., 20 de jan. de 2021 às 12:13, Jürgen Groß <jgr...@suse.com> escreveu: > > On 20.01.21 09:50, Jan Beulich wrote: > > On 19.01.2021 20:36, Claudemir Todo Bom wrote: > >> I do not have serial output on this setup, so I recorded a video with > >> boot_delay=50 in order to be able to get all the kernel messages: > >> https://youtu.be/y95h6vqoF7Y > > > > This doesn't show any badness afaics. > > > >> This is running 4.14 from debian bullseye (testing). > >> > >> I'm also attaching the dmesg output when booting xen 4.8 with the same > >> kernel version and same parameters. > >> > >> I visually compared all the messages, and the only thing I noticed was that > >> 4.14 used tsc as clocksource and 4.8 used xen. I tried to boot the kernel > >> with "clocksource=xen" and the problem is happening with that also. > > > > There's some confusion here I suppose: The clock source you talk > > about is the kernel's, not Xen's. I didn't think this would > > change for the same kernel version with different Xen underneath, > > but the Linux maintainers of the Xen code there may know better. > > Cc-ing them. > > This might depend on CPUID bits given to dom0 by Xen, e.g. regarding > TSC stability. >
Looks like the CPUID changes I observed and wrote on the other messages are another problem I may end up with. I narrowed down the cause of the problem on booting of dom0 with more than 1 core on the following commit: https://github.com/xen-project/xen/commit/63e1d01b8fd948b3e0fa3beea494e407668aa43b Code built from this commit doesn't boot, built from the parent of it, boots. Now, there is something I can do on the command line to make it boots? Or its needed to fix on the code? Best regards, Claudemir
