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

Hans de Goede hdegoede at redhat.com
Thu Jun 1 13:59:10 GMT 2017


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.

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

>> 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.

Regards,

Hans



More information about the vbox-dev mailing list