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 _______________________________________________ vbox-dev mailing list [email protected] https://www.virtualbox.org/mailman/listinfo/vbox-dev
