[vbox-dev] Linux-4.12-rc1 and rc2 not working as vbox guest ?

Frank Mehnert frank.mehnert at oracle.com
Mon May 29 13:12:22 GMT 2017 

Hi Hans,

On Montag, 29. Mai 2017 13:27:33 CEST Hans de Goede wrote:
> On 29-05-17 12:23, Hans de Goede wrote:
> > On 25-05-17 11:57, Hans de Goede wrote:
> >> On 24-05-17 18:13, Michael Thayer wrote:
> >>> 24.05.2017 16:02, Michael Thayer wrote:
> >>>> 24.05.2017 15:16, Hans de Goede wrote:
> >>>> [...]
> >>>>> I cannot get a Fedora 26 guest to boot with either distro-provided or
> >>>>> self-built 4.12-rc# kernels, the distro-provided 4.11 kernel works fine.
> >>>>>
> >>>>> After selecting a 4.12# kernel in the grub menu the vm shows an empty
> >>>>> text screen with a cursor in the top left corner and then just hangs.
> >>>>>
> >>>>> Anyone know how to fix this ? This is with VirtualBox 5.1.22 on a Fedora
> >>>>> host.
> >>>>
> >>>> Hello Hans,
> >>>>
> >>>> Downloading F26 alpha now to take a look.  Did you try a serial console
> >>>> redirected to a host file to get early boot messages?
> >>>>
> >>>> And I am back at work now and hope look at your patches soon!
> >>>
> >>> Just tried 4.12-rc1 from Rawhide (is that right?)  It boots fine here, Ubuntu 17.04 host.  Could it be something in your virtual machine configuration or your host?  A log file for the machine might tell us more.
> >>
> >> Ok, so here is what I did:
> >>
> >> 1) Download F26 nightly compose live iso
> >> 2) Start virtualbox 5.1.20 from rpmfusion pkgs, create new vm, type "Fedora 64 bit"
> >> 3) Use vm for a while to test vboxvideo stuff
> >> 4) Manually install a kernel build from Torvald's latest master with the
> >> intend to start working on putting the vboxvideo code under drivers/staging
> >> 5) Hmm, does not boot, lets try a Fedora built 4.12-rc# kernel from rawhide
> >> 6) Hmm still does not boot, remove 5.1.20 pkgs from rpmfusion, install
> >>     5.1.22 from virtualbox.org
> >> 7) Still does not boot (and the 4.11 kernel does still boot) time to mail
> >>     this list.

sorry, but did you also try to boot the kernel from Torvald's latest master
without any VBox-related kernel modules added? I'm not sure about that when
reading your instructions.

It is known that the 5.1.22 VirtualBox Guest Additions kernel modules do not
compile against Linux 4.12-rc, therefore I assume you only added the vboxvideo
stuff to your kernel but you didn't use any vboxguest code, is that correct?

> >> I've just tried installing and booting kernel-4.12.0-0.rc1.git0.1.fc27.x86_64 and
> >> still no luck. I guess I can try re-recreating the vm, might that help ?
> > 
> > So this morning again I've tried to get my vm to boot with a 4.12 kernel,
> > no luck. One thing I did notice is that the 4.11 kernel which does work
> > gives this error very early on during boot:
> > 
> > [    0.000000] ------------[ cut here ]------------
> > [    0.000000] WARNING: CPU: 0 PID: 0 at arch/x86/kernel/fpu/xstate.c:596 fpu__init_system_xstate+0x48f/0x870
> > [    0.000000] XSAVE consistency problem, dumping leaves
> > ...
> > 
> > Which I guess is not normal. Could this be a problem with my host ?
> > My host is a Fedora 26 install, running 4.11.3, I've tried downgrading
> > the host kernel to 4.10.7 but that does not help.

This guest warning is expected on certain CPUs. VirtualBox does not expose the
whole XSAVE state to the guest and that causes gaps which Linux warns about.
This is a warning, not a fatal error.

I get the exact same warning if I boot a Fedora 25 guest on VBox 5.1.22 on a
host with Linux 4.11 running on a Skylake processor.

> > Maybe something with Fedora 26's gcc version ? :
> > 
> > [hans at shalem ~]$ rpm -q gcc
> > gcc-7.1.1-1.fc26.x86_64
> > 
> > Causing a miscompile of the host drivers ?

Very unlikely. We are using gcc 7.1 on some hosts as well.

> Ok, this is indeed a host problem, I copied the vm to a Fedora 25 64 bit
> host with a 4.10.5 kernel and there it works fine, including the 4.11
> kernel not showing the "XSAVE consistency problem" message, and the 4.12
> kernel working just fine.

The XSAVE consistency problem and the guest being unable to boot are most
likely two different problems.

> Here are more complete guest kernel logs of the "XSAVE consistency problem"
> when using A Fedora 26 64 bit host with kernel 4.10 and a 4.11 guest kernel:
> 
> [    0.000000] Linux version 4.11.0-2.fc26.x86_64 (mockbuild at bkernel01.phx2.fedoraproject.org) (gcc version 7.1.1 20170503 (Red Hat 7.1.1-1) (GCC) ) #1 SMP Tue May 9 15:24:49 UTC 2017
> [    0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.11.0-2.fc26.x86_64 root=/dev/mapper/fedora-root ro rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet LANG=en_US.UTF-8
> [    0.000000] ------------[ cut here ]------------
> [    0.000000] WARNING: CPU: 0 PID: 0 at arch/x86/kernel/fpu/xstate.c:596 fpu__init_system_xstate+0x48f/0x870
> [    0.000000] XSAVE consistency problem, dumping leaves
> [    0.000000] Modules linked in:
> [    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.11.0-2.fc26.x86_64 #1
> [    0.000000] Call Trace:
> [    0.000000]  dump_stack+0x63/0x84
> [    0.000000]  __warn+0xcb/0xf0
> [    0.000000]  warn_slowpath_fmt+0x5a/0x80
> [    0.000000]  ? xfeature_size+0x56/0x74
> [    0.000000]  fpu__init_system_xstate+0x48f/0x870
> [    0.000000]  ? get_cpu_cap+0x2a3/0x370
> [    0.000000]  ? msr_clear_bit+0x3a/0xa0
> [    0.000000]  ? 0xffffffff91000000
> [    0.000000]  fpu__init_system+0x1e1/0x208
> [    0.000000]  early_cpu_init+0x102/0x104
> [    0.000000]  setup_arch+0xba/0xcf3
> [    0.000000]  ? printk+0x52/0x6e
> [    0.000000]  ? early_idt_handler_array+0x120/0x120
> [    0.000000]  start_kernel+0xb2/0x47b
> [    0.000000]  ? early_idt_handler_array+0x120/0x120
> [    0.000000]  x86_64_start_reservations+0x24/0x26
> [    0.000000]  x86_64_start_kernel+0x13c/0x15f
> [    0.000000]  start_cpu+0x14/0x14
> [    0.000000] ---[ end trace 9d5a61c263f77bce ]---
> [    0.000000] CPUID[0d, 00]: eax=00000007 ebx=00000440 ecx=00000440 edx=00000000
> [    0.000000] CPUID[0d, 01]: eax=00000000 ebx=000003c0 ecx=00000000 edx=00000000
> [    0.000000] CPUID[0d, 02]: eax=00000100 ebx=00000240 ecx=00000000 edx=00000000
> [    0.000000] CPUID[0d, 03]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
> [    0.000000] CPUID[0d, 04]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
> [    0.000000] CPUID[0d, 05]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
> [    0.000000] CPUID[0d, 06]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
> [    0.000000] CPUID[0d, 07]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
> [    0.000000] CPUID[0d, 08]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
> [    0.000000] CPUID[0d, 09]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
> [    0.000000] CPUID[0d, 0a]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
> [    0.000000] CPUID[0d, 0b]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
> [    0.000000] CPUID[0d, 0c]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
> [    0.000000] CPUID[0d, 0d]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
> [    0.000000] CPUID[0d, 0e]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
> [    0.000000] CPUID[0d, 0f]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
> [    0.000000] CPUID[0d, 10]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
> [    0.000000] CPUID[0d, 11]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
> [    0.000000] CPUID[0d, 12]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
> [    0.000000] CPUID[0d, 13]: eax=00000000 ebx=00000000 ecx=00000000 edx=00000000
> [    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
> [    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
> [    0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
> [    0.000000] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
> [    0.000000] x86/fpu: Enabled xstate features 0x7, context size is 1088 bytes, using 'standard' format.
> [    0.000000] e820: BIOS-provided physical RAM map:
> 
> I think that fixing this guest oops stands a good chance of also making
> the 4.12 kernel boot as guest on a F26 host.
> 
> Next step is to downgrade gcc on my F26 machine to the F25 version and see if
> that fixes things on F26. I've rebuild the host modules on F26 with the
> current gcc version redirecting stderr to catch any compiler warnings which
> might be helpful, but no such luck, the only thing I got was:
> 
> /usr/share/virtualbox/src/vboxhost/vboxdrv/r0drv/linux/memuserkernel-r0drv-linux.o: warning: objtool: .fixup: unexpected end of section
> 
> Which I'm seeing when building on Fedora 25 too.

No idea. But we build Linux kernel modules according to the Linux rules,
that is, the Linux Makefiles and the same tools as for the Linux kernel
are used. You should double-check that gcc as installed at the time you
are compiling the Linux modules is the same version as used to compile
the Linux kernel.

Kind regards,

Frank
-- 
Dr.-Ing. Frank Mehnert | Software Development Director, VirtualBox
ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | 71384 Weinstadt, Germany

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstraße 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

More information about the vbox-dev mailing list