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

[Frank Mehnert]

Hi Hans,

On Donnerstag, 1. Juni 2017 15:59:10 CEST Hans de Goede wrote:
> Hi,
> 
> On 01-06-17 15:42, Frank Mehnert wrote:
> > Hi Hans,
> > 
> > On Donnerstag, 1. Juni 2017 14:22:29 CEST Hans de Goede wrote:
> >>> Again, this is not a VirtualBox bug although this panic will probably not
> >>> happen on real hardware.
> >>
> >> [...]
> >>
> >> No as for the disagree-ing with this not being a VirtualBox bug,
> >> even with 4.11 the oops is a problem and is IMHO a VirtualBox bug,
> > 
> > why do you think it's a VirtualBox bug?
> 
> Because it does not happen on real hardware and VirtualBox
> is supposed to faithfully emulate real hardware.

Any prove that it does not happen on real hardware? :-) I think that would
be more a guess.

> But I understand that modern hardware is so complex that it may be
> an issue on the kernel side...

Right.

> >> I was sorta surprised when you said earlier in this thread that this
> >> is normal and can be ignored. Oopses are never normal and should never
> >> be ignored. Fedora / RHEL users will get a notification that the kernel
> >> has hit a bug as soon as they login because of the oops, and oopses
> >> are being actively tracked for people who opt-in to reporting crashes
> >> to our backtrace server:
> >>
> >> https://retrace.fedoraproject.org/faf/problems/
> >>
> >> Now maybe this really is 2 kernel bugs, 1. The oops turning into a
> >> hang with 4.12 and 2. The oops happening at all, but an oops is never
> >> normal and really must be fixed. In case you believe that the oops
> >> happening at all is also a kernel bug please file a bug for that
> >> too and cross-reference the 2.
> > 
> > I think so. The Linux kernel oops is about a wrong expectation of the
> > kernel: VirtualBox exposes the size of the XSAVE area (same value as
> > on the host, 0x3c0 = 960 bytes). VBox does not expose bits 0...3 of
> > the eax register (XSAVEOPT, XSAVEC/XRSTOR, XGETBV, XSAVES/XRSTORS
> > all not available). In general it's all about do_extra_xstate_size_checks().
> > That function is a bit hard to follow without any additional debug
> > output. All I can see is that
> > 
> >    fpu_kernel_xstate_size = 0x440 while
> >    paranoid_xstate_size   = 0x240
> > 
> > and therefore the XSTATE_WARN_ON() statement triggers. As I said, the
> > kernel expects different values in the CPUID registers and warns about
> > mismatched expectations. I'm 99% sure that the kernel would run correctly
> > if this warning is just ignored. The warning is paranoia.
> 
> Ok, thank you for the explanation, lets see what the upstream devs
> have to say. My main desire here is to not have the kernel oops,
> independent of whether the fix is on the vbox or kernel side.
> 
> > That XSAVE stuff is work in progress and future versions of VirtualBox
> > will change the exposed features.
> > 
> > I will create bug reports.
> 
> Thank you.

Created https://bugzilla.kernel.org/show_bug.cgi?id=195961 for the first
issue (hanging kernel during early init). I have to clear up my mind before
I report the 2nd problem (the actual XSTATE warning).

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