Re: NetBSD 9.0 RC1 amd64 not working on VirtualBox 6.1.0

To: bodie%bodie.cz@localhost
Subject: Re: NetBSD 9.0 RC1 amd64 not working on VirtualBox 6.1.0
From: Chavdar Ivanov <ci4ic4%gmail.com@localhost>
Date: Sat, 14 Dec 2019 13:19:09 +0000

On Sat, 14 Dec 2019 at 12:52, Chavdar Ivanov <ci4ic4%gmail.com@localhost> wrote:
>
> I can attach the whole log file, should you need it; in the mean time
> the three variable mentioned above are the same:
> ...
> 00:00:03.502252   IBRS_IBPB - IA32_SPEC_CTRL.IBRS and
> IA32_PRED_CMD.IBPB  = 0 (1)
> 00:00:03.502253   STIBP - Supports IA32_SPEC_CTRL.STIBP
>    = 0 (1)
> ...
> 00:00:03.502256   SSBD - Supports IA32_SPEC_CTRL.SSBD
>    = 0 (1)
> ...
>
> BTW there is some mistake in this - released now - version of
> VirtualBox 6.1. They were deprecating 3D acceleration when using
> VBoxVGA driver and up to a point were warning any machine under 6.0.x
> in this mode that it will be removed with 6.1. Now the interface
> accepts 3D acceleration *only* if one has VBoxVGA selected as a
> display device and it apparently works as before (well, glmark2 now
> half way through crashes under -current with:
>
> [pulsar] light=false:quads=5:texture=false:llvm (version 0x700) found
> no intrinsic for llvm.x86.sse2.paddus.b, going to crash...
> [1]    2046 abort (core dumped)  glmark2 and the following trace:
> ...
> Core was generated by `glmark2'.
> Program terminated with signal SIGABRT, Aborted.
> #0  0x00007e168358606a in _lwp_kill () from /usr/lib/libc.so.12
> [Current thread is 1 (process 1)]
> (gdb) bt
> #0  0x00007e168358606a in _lwp_kill () from /usr/lib/libc.so.12
> #1  0x00007e168358640a in abort () from /usr/lib/libc.so.12
> #2  0x00007e167b549b2a in lp_build_intrinsic () from
> /usr/X11R7/lib/modules/dri/swrast_dri.so
> #3  0x00007e167b549b69 in lp_build_intrinsic_binary () from
> /usr/X11R7/lib/modules/dri/swrast_dri.so
> #4  0x00007e167b1ad212 in lp_build_blend () from
> /usr/X11R7/lib/modules/dri/swrast_dri.so
> #5  0x00007e167b1abd15 in lp_build_blend_aos () from
> /usr/X11R7/lib/modules/dri/swrast_dri.so
> #6  0x00007e167b1a34ae in ?? () from /usr/X11R7/lib/modules/dri/swrast_dri.so
> #7  0x00007e167b1a71a7 in ?? () from /usr/X11R7/lib/modules/dri/swrast_dri.so
> #8  0x00007e167b1a84a8 in llvmpipe_update_fs () from
> /usr/X11R7/lib/modules/dri/swrast_dri.so
> #9  0x00007e167b1ad709 in llvmpipe_update_derived () from
> /usr/X11R7/lib/modules/dri/swrast_dri.so
> #10 0x00007e167ad9fd00 in ?? () from /usr/X11R7/lib/modules/dri/swrast_dri.so
> #11 0x00007e167af17e45 in ?? () from /usr/X11R7/lib/modules/dri/swrast_dri.so
> #12 0x00007e167b0f9cca in ?? () from /usr/X11R7/lib/modules/dri/swrast_dri.so
> #13 0x00007e167b0f9d60 in _mesa_DrawArrays () from
> /usr/X11R7/lib/modules/dri/swrast_dri.so
> #14 0x0000000000491c9e in Mesh::render_vbo
> (this=this@entry=0x7e1685b0b100) at ../src/mesh.cpp:583
> #15 0x000000000045b9cb in ScenePulsar::draw (this=0x7e1685b0b000) at
> ../src/scene-pulsar.cpp:219
> #16 0x000000000040c41d in MainLoop::draw (this=0x7e16853d5a40) at
> ../src/main-loop.cpp:133
> #17 0x000000000040cb4f in MainLoop::step
> (this=this@entry=0x7e16853d5a40) at ../src/main-loop.cpp:108
> #18 0x0000000000406bd3 in do_benchmark (canvas=...) at ../src/main.cpp:119
> #19 0x00000000004cc755 in main (argc=<optimized out>, argv=<optimized
> out>) at ../src/main.cpp:214
> ....
>
> but that is of course a different matter.
>
> I'll go ahead and try to build the additions now.

They build:
...
Starting local daemons:13:16:02.318613 main     VBoxService 6.1.0
r135406 (verbosity: 0) netbsd.amd64 (Dec 14 2019 13:11:39) release log
13:16:02.318626 main     Log opened 2019-12-14T13:16:02.318549000Z
13:16:02.319953 main     OS Product: NetBSD
13:16:02.320201 main     OS Release: 9.99.23
13:16:02.320543 main     OS Version: NetBSD 9.99.23 (GENERIC) #0: Fri
Dec 13 13:54:46 GMT 2019
sysbuild@ymir:/home/sysbuild/amd64/obj/home/sysbuild/src/sys/arch/amd64/compile/GENERIC
13:16:02.320773 main     Executable: /usr/local/bin/additions/VBoxService
13:16:02.320779 main     Process ID: 5230
13:16:02.320785 main     Package type: BSD_64BITS_GENERIC
13:16:02.323205 main     6.1.0 r135406 started. Verbose level = 0
.....

I only needed:
....
--- ./src/VBox/Runtime/common/path/RTPathAbsEx.cpp.ORIG    2019-07-20
11:55:09.661784205 +0100
+++ ./src/VBox/Runtime/common/path/RTPathAbsEx.cpp      2019-07-20
11:55:38.098838914 +0100
@@ -265,22 +265,8 @@
         cchInPlace = 0;
         cbCwd      = RT_MAX(cbCwd * 4, RTPATH_BIG_MAX);
         pszCwdFree = pszCwd = (char *)RTMemTmpAlloc(cbCwd);
-        if (pszCwdFree)
-        {
-            rc = RTPathGetCurrentOnDrive(pszPath[0], pszCwd, cbCwd);
-            if (RT_FAILURE(rc))
-            {
-                if (rc == VERR_BUFFER_OVERFLOW)
-                    rc = VERR_FILENAME_TOO_LONG;
-                RTMemTmpFree(pszCwdFree);
-                return rc;
-            }
-        }
-        else
-        {
-            *pcbAbsPath = cbCwd + 1 + pParsed->cchPath + 1;
-            return rc;
-        }
+        *pcbAbsPath = cbCwd + 1 + pParsed->cchPath + 1;
+        return rc;
     }
     else
         return rc;
--- src/VBox/Runtime/r3/posix/utf8-posix.cpp.ORIG       2019-11-21
19:20:15.727330932 +0000
+++ src/VBox/Runtime/r3/posix/utf8-posix.cpp    2019-11-22
11:12:23.114855612 +0000
@@ -77,7 +77,7 @@


 /* There are different opinions about the constness of the input buffer. */
-#if defined(RT_OS_LINUX) || defined(RT_OS_HAIKU) || defined(RT_OS_SOLARIS) \
+#if defined(RT_OS_LINUX) || defined(RT_OS_HAIKU) ||
defined(RT_OS_SOLARIS) || defined(RT_OS_NETBSD) \
   || (defined(RT_OS_DARWIN) && defined(_DARWIN_FEATURE_UNIX_CONFORMANCE))
 # define NON_CONST_ICONV_INPUT
 #endif
..........

>
> On Sat, 14 Dec 2019 at 11:57, Bodie <bodie%bodie.cz@localhost> wrote:
> >
> >
> >
> > On 14.12.2019 12:43, Chavdar Ivanov wrote:
> > > FWIW, the installation iso of my yesterday's build of 9.99.23 amd64
> > > boots just fine under VirtualBox 6.1.
> > >
> >
> > Do you have VBox.log to see what host is under and what CPU
> > capabilities?
> >
> > > On Sat, 14 Dec 2019 at 10:22, Bodie <bodie%bodie.cz@localhost> wrote:
> > >>
> > >>
> > >>
> > >> On 12.12.2019 17:38, Maxime Villard wrote:
> > >> > Le 12/12/2019 à 16:34, Valery Ushakov a écrit :
> > >> >> On Thu, Dec 12, 2019 at 06:47:50 +0100, Bodie wrote:
> > >> >>
> > >> >>> On 11.12.2019 23:32, Valery Ushakov wrote:
> > >> >>>> On Wed, Dec 11, 2019 at 23:15:38 +0100, Bodie wrote:
> > >> >>>>
> > >> >>>>> FYI https://www.virtualbox.org/ticket/19146
> > >> >>>>>
> > >> >>>>> Not possible to boot installer of NetBSD 9.0RC1. cc me as I am not
> > >> >>>>> subscribed to list.
> > >> >>>>
> > >> >>>> CPUID values are ... = guest (host):
> > >> >>>>
> > >> >>>> IBRS_IBPB - IA32_SPEC_CTRL.IBRS and IA32_PRED_CMD.IBPB  = 0 (1)
> > >> >>>> STIBP - Supports IA32_SPEC_CTRL.STIBP                   = 0 (1)
> > >> >>>> SSBD - Supports IA32_SPEC_CTRL.SSBD                     = 0 (1)
> > >> >>>>
> > >> >>>> so the NetBSD guest is told the cpu doesn't support IA32_SPEC_CTRL
> > >> >>>> (0x48),
> > >> >>>> but still the guest tries to read it:
> > >> >>>
> > >> >>> NetBSD 8.1 STABLE amd64 on same configuration with same values boots
> > >> >>> just fine and works.
> > >> >>
> > >> >> Right, b/c NetBSD 8 doesn't read that nonexistent MSR.
> > >> >>
> > >> >>
> > >> >>>> 00:00:11.518912 IEM: rdmsr(0x48) -> #GP(0)
> > >> >>>> 00:00:11.518920 Changing the VM state from 'RUNNING' to
> > >> >>>> 'GURU_MEDITATION'
> > >> >>
> > >> >> 00:00:11.520158 CPUM0: 0008:ffffffff8022714b 0f 32
> > >> >> rdmsr
> > >> >>
> > >> >> This is mitigation_v2_apply_cpu(), V2_MITIGATION_INTEL_ENHANCED_IBRS
> > >> >> case it seems, so either the kernel misdetects the mitigation variant
> > >> >> to use, or vbox doesnt' scrub host capabilities enough.  Someone with
> > >> >> the clue should look at the VBox.log (it has the cpuinfo dump).
> > >> >>
> > >> >> -uwe
> > >> >
> > >> > The CPU has
> > >> >
> > >> >       CPUID.IBRS = 1
> > >> >       CPUID.STIBP = 1
> > >> >       ARCH_CAP.IBRS_ALL = 1
> > >> >
> > >> > VirtualBox only clears the CPUID:
> > >> >
> > >> >       CPUID.IBRS = 0
> > >> >       CPUID.STIBP = 0
> > >> >       ARCH_CAP.IBRS_ALL = 1
> > >> >
> > >> > NetBSD sees ARCH_CAP.IBRS_ALL == 1, and tries to use the SPEC_CTRL MSR,
> > >> > which
> > >> > faults.
> > >> >
> > >> > Technically, NetBSD is not wrong, because you cannot have
> > >> > ARCH_CAP.IBRS_ALL set
> > >> > to one and CPUID.IBRS/STIBP set to zero. Still, I will add a check on
> > >> > the
> > >> > CPUIDs.
> > >> >
> > >>
> > >> Once there will be some daily build to check I can do that of course.
> > >>
> > >> > Meanwhile VirtualBox should be fixed not to report ARCH_CAP.IBRS_ALL,
> > >> > because
> > >> > this is technically incorrect.
> > >> >
> > >>
> > >> yeah it may take a while I fear
> > >> > Maxime
>
>
>
> --
> ----



-- 
----

References:
- Re: NetBSD 9.0 RC1 amd64 not working on VirtualBox 6.1.0
  - From: Valery Ushakov
- Re: NetBSD 9.0 RC1 amd64 not working on VirtualBox 6.1.0
  - From: Maxime Villard
- Re: NetBSD 9.0 RC1 amd64 not working on VirtualBox 6.1.0
  - From: Bodie
- Re: NetBSD 9.0 RC1 amd64 not working on VirtualBox 6.1.0
  - From: Chavdar Ivanov
- Re: NetBSD 9.0 RC1 amd64 not working on VirtualBox 6.1.0
  - From: Bodie
- Re: NetBSD 9.0 RC1 amd64 not working on VirtualBox 6.1.0
  - From: Chavdar Ivanov

Prev by Date: Re: NetBSD 9.0 RC1 amd64 not working on VirtualBox 6.1.0
Next by Date: Re: NetBSD 9.0 RC1 amd64 not working on VirtualBox 6.1.0
Previous by Thread: Re: NetBSD 9.0 RC1 amd64 not working on VirtualBox 6.1.0
Next by Thread: Re: NetBSD 9.0 RC1 amd64 not working on VirtualBox 6.1.0
Indexes:

Home | Main Index | Thread Index | Old Index