Linux kernel version: 5.8 - we need changes (fixed in 6.1.14)

[Frank Batschulat (Oracle)]

From: "Larry Finger" <> To: vbox-dev@… Subject: [vbox-dev] Problem with kernel 5.8 Date: Fri, 05 Jun 2020 23:39:08 +0200

In a little over one week, Linus will release Kernel 5.8.0-rc1. Shortly thereafter, openSUSE Tumbleweed will start builds using that kernel. Unless I have patched our copy of the code for the VB kernel modules, my mailbox will be flooded with build failure messages.

Thus far, I have found two incompatibilities with the 5.8 APIs. The first was the removal of get_vm_area(). This one can be trivially replaced with get_vm_area_caller(), which has one additional argument that is always "builtin_return_address(0)."

A second API change is more complicated, and above my understanding. In the associated patch entitled "mm: only allow page table mappings for built-in zsmalloc", symbols map_vm_area() and unmap_kernel_range() are no longer exported. The first of these are used in this snippet found in src/vboxdrv/r0drv/linux/alloc-r0drv-linux.c:

      if (iPage == cPages)
      {
          /*
           * Map the pages.
           *
           * Not entirely sure we really need to set nr_pages and pages  
here, but
           * they provide a very convenient place for storing something we  
need
           * in the free function, if nothing else...
           */
# if LINUX_VERSION_CODE < KERNEL_VERSION(3, 17, 0)
          struct page **papPagesIterator = papPages;
# endif
          pVmArea->nr_pages = cPages;
          pVmArea->pages    = papPages;
          if (!map_vm_area(pVmArea, PAGE_KERNEL_EXEC,
# if LINUX_VERSION_CODE < KERNEL_VERSION(3, 17, 0)
                           &papPagesIterator
# else
                           papPages
# endif
                           ))
          {
              PRTMEMLNXHDREX pHdrEx = (PRTMEMLNXHDREX)pVmArea->addr;
              pHdrEx->pVmArea     = pVmArea;
              pHdrEx->pvDummy     = NULL;
              return &pHdrEx->Hdr;
          }
          /* bail out */
# if LINUX_VERSION_CODE < KERNEL_VERSION(3, 17, 0)
          pVmArea->nr_pages = papPagesIterator - papPages;
# endif
      }

I think the code could use vm_map_ram() to map the papPages array directly, but I would appreciate any help the developers could provide.

Thanks,

Larry

[Frank Batschulat (Oracle)]

Text string: get_vm_area

  File                Line
0 alloc-r0drv-linux.c  43 * Starting with 2.6.23 we can use __get_vm_area and map_vm_area to allocate
1 alloc-r0drv-linux.c 171 pVmArea = __get_vm_area(cbAlloc, VM_ALLOC, MODULES_VADDR, MODULES_END);

trunk/src/VBox/Runtime/r0drv/linux/alloc-r0drv-linux.c

 40 #if (defined(RT_ARCH_AMD64) || defined(DOXYGEN_RUNNING)) && !defined(RTMEMALLOC_EXEC_HEAP)                                         
 41 # if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 23)                                                                                
 42 /**                                                                                                                                
 43  * Starting with 2.6.23 we can use __get_vm_area and map_vm_area to allocate                                                       
 44  * memory in the moduel range.  This is preferrable to the exec heap below.                                                        
 45  */                                                                                                                                
 46 #  define RTMEMALLOC_EXEC_VM_AREA                                                                                                  
 47 # else                                                                                                                             
 48 /**                                                                                                                                
 49  * We need memory in the module range (~2GB to ~0) this can only be obtained                                                       
 50  * thru APIs that are not exported (see module_alloc()).                                                                           
 51  *                                                                                                                                 
 52  * So, we'll have to create a quick and dirty heap here using BSS memory.                                                          
 53  * Very annoying and it's going to restrict us!                                                                                    
 54  */                                                                                                                                
 55 #  define RTMEMALLOC_EXEC_HEAP                                                                                                     
 56 # endif                                                                                                                            
 57 #endif    

155 #ifdef RTMEMALLOC_EXEC_VM_AREA                                                                                                     
156 /**                                                                                                                                
157  * Allocate executable kernel memory in the module range.                                                                          
158  *                                                                                                                                 
159  * @returns Pointer to a allocation header success.  NULL on failure.                                                              
160  *                                                                                                                                 
161  * @param   cb          The size the user requested.                                                                               
162  */                                                                                                                                
163 static PRTMEMHDR rtR0MemAllocExecVmArea(size_t cb)                                                                                 
164 {                                                                                                                                  
165     size_t const        cbAlloc = RT_ALIGN_Z(sizeof(RTMEMLNXHDREX) + cb, PAGE_SIZE);                                               
166     size_t const        cPages  = cbAlloc >> PAGE_SHIFT;                                                                           
167     struct page       **papPages;                                                                                                  
168     struct vm_struct   *pVmArea;                                                                                                   
169     size_t              iPage;                                                                                                     
170                                                                                                                                    
171     pVmArea = __get_vm_area(cbAlloc, VM_ALLOC, MODULES_VADDR, MODULES_END);   

get_vm_area() has been removed from the 5.8 kernel tree with:

    Subject: [PATCH 07/28] mm: remove __get_vm_area
    From: Christoph Hellwig <hch@xxxxxx>
    Date: Wed, 8 Apr 2020 13:59:05 +0200
    In-reply-to: <20200408115926.1467567-1-hch@lst.de>
Switch the two remaining callers to use __get_vm_area_caller instead.

​https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20200408115926.1467567-8-hch@lst.de/
​https://www.spinics.net/lists/arm-kernel/msg797407.html

Solution: replace with:

__get_vm_area_caller(cbAlloc, VM_ALLOC, MODULES_VADDR, MODULES_END, 
   __builtin_return_address(0));

​http://linuxppc.10917.n7.nabble.com/decruft-the-vmalloc-API-td172511.html#none
​https://lkml.org/lkml/2020/4/8/298
10/28 mm: only allow page table mappings for built-in zsmalloc
This allows to unexport map_vm_area and unmap_kernel_range, which are
rather deep internal and should not be available to modules. ​https://patchwork.ozlabs.org/project/netdev/patch/20200408115926.1467567-11-hch@lst.de/
​http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/sanitize-vmalloc-api

Text string: map_vm_area

  File                Line
0 alloc-r0drv-linux.c  43 * Starting with 2.6.23 we can use __get_vm_area and map_vm_area to allocate
1 alloc-r0drv-linux.c 204 if (!map_vm_area(pVmArea, PAGE_KERNEL_EXEC,

trunk/src/VBox/Runtime/r0drv/linux/alloc-r0drv-linux.c

163 static PRTMEMHDR rtR0MemAllocExecVmArea(size_t cb)                                                                                 
...
199 # if LINUX_VERSION_CODE < KERNEL_VERSION(3, 17, 0)                                                                                 
200         struct page **papPagesIterator = papPages;                                                                                 
201 # endif                                                                                                                            
202         pVmArea->nr_pages = cPages;                                                                                                
203         pVmArea->pages    = papPages;                                                                                              
204         if (!map_vm_area(pVmArea, PAGE_KERNEL_EXEC,                                                                                
205 # if LINUX_VERSION_CODE < KERNEL_VERSION(3, 17, 0)                                                                                 
206                          &papPagesIterator                                                                                         
207 # else                                                                                                                             
208                          papPages                                                                                                  
209 # endif 

Could not find the text string: unmap_kernel_range

cpu_tlbstate:

Text string: cpu_tlbstate
  File               Line
0 SUPDrv-linux.c     760 RTCCUINTREG uOld = this_cpu_read(cpu_tlbstate.cr4);
1 SUPDrv-linux.c     764 this_cpu_write(cpu_tlbstate.cr4, uNew);
2 the-linux-kernel.h 169 /* for cr4_init_shadow() / cpu_tlbstate. */

hidden with:
Subject: [patch 00/15] x86/tlb: Unexport per-CPU tlbstate
Date: Sun, 19 Apr 2020 22:31:37 +0200
​https://lore.kernel.org/lkml/20200419203137.214111265@linutronix.de/

The per-CPU tlbstate contains sensitive information which 
should be really only accessible in core code. It is exported
to modules because some inline functions which are required by
KVM need access to it.

The following series creates regular exported functions for
the few things which are needed by KVM and hides the struct
definition and some low level helpers from modules.

[​https://lore.kernel.org /lkml/20200419203336.226245149@…/]

Subject: [patch 02/15] x86/cpu: Uninline CR4 accessors
​https://lore.kernel.org/lkml/20200419203335.856333226@linutronix.de/

Apparently we've also had a change affecting: trunk/src/VBox/Additions/linux/sharedfolders/vfsmod.c

starting with 5.8-rc1 vermagic.h cannot be included anymore: ​https://elixir.bootlin.com/linux/v5.8-rc1/source/include/linux/vermagic.h

#ifndef INCLUDE_VERMAGIC
#error "This header can be included from kernel/module.c or *.mod.c only"
#endif

but we don't need it anyways in that file.

[Larry Finger]

The situation got worse. In another patch,

 __get_vm_area_caller()

is no longer exported. At this point, I see no way to map an area of VM short of recreating all the code used in the kernel, and that runs into all kinds of interactions with static variables used by the kernel.

Clearly, the trend is to prevent external modules from getting any control of virtual memory mappings. It will likely be required to rewrite vboxdrv and submit it for inclusion in the kernel. The vboxnet* modules will probably be OK out of the kernel.

[Larry Finger]

Apply fixes needed for kernel 5.8 difference in struct mm_struct

[Larry Finger]

Fixes associated with hiding of cputlbstate

[Larry Finger]

Fixes for module memory

[Larry Finger]

Changes needed for kernel 5.8 for patch to module_memory to work

[Larry Finger]

A few days before the expected release of kernel 5.8.0-rc1, there are 3 areas that have changed since 5.7.0. The first of these is that In struct mm_struct, member mmap_sem is renamed to mmap_lock. That change is straight-forward and the fix is in patch file fixes_for_mm_struct.patch. A second simple patch handles that the structure cpu_tblstate is now hidden Patch fixes_for_changes_in_cpu_tlbstate.patch handles this. The third kernel change is much more problematic. Kernel routine get_vm_area() was first changed to get_vm_area_caller(), and then the latter routine was no longer exported. In addition, routine map_vm_area() has been removed. I do not have a fix for this. At first it seemed that reverting to the method used before kernel 2.6.13 would work by not defining RTMEMALLOC_EXEC_VM_AREA and using RTMEMALLOC_EXEC_HEAP instead. Unfortunately, this code fails to allocate the memory correctly, and VMs fail to start. I have been unable to fix that problem. My work-around is in file fixes_for_module_memory.patch; however, this change requires that 2 additional exports be added to the kernel at least until the problem with using RTMEMALLOC_EXEC_HEAP is fixed. The patch for the kernel is shown in attachment local_patches.

[Larry Finger]

I have been unable to find a solution that does NOT require modifying the kernel. From what I see, the kernel developers have effectively blocked all access to allocation of executable memory other than through the KVM mechanism.

[burdi01]

Any news from the front?
:D

[Larry Finger]

Any news here? Kernel 5.8.0 will be out in approximately 3 weeks. At that point, every host trying to run that kernel will break. I have been unable to find a method of allocating executable memory that will work with vboxdrv.

[burdi01]

Actually I applied the "local_patches" patch to the vanilla 5.8-rc5 kernel and the 3 "fixes-for-*" patches to VB 6.0.10-138449-Linux_amd64. Building that kernel and vboxdrv went without a hitch. Running a non-guest-additions guest seems to be OK.

However the rc3 and rc5 kernels that I tested with have overlayfs/squasfs problems. However I do not think these problems are related to VB.

@lwfinger: The in-tree rtw-8723de driver (which triggered me to test things) seems OK.
:D

[burdi01]

I applied the "local_patches" patch to a vanilla 5.8-rc6 kernel and the 3 "fixes-for-*" patches to VB 6.0.12-139181-Linux_amd64 and 6.1.13-139358-Linux_amd64. Building that kernel and both vboxdrv's went without a hitch. Running non-guest-additions guests shows no anomalies.

The squashfs problem I mentioned above is resolved by rc6.

It is likely that the kernel 5.8 release is only some 2 weeks away. I am curious how patching that kernel for VB will be implemented or can be circumvented.

[burdi01]

In VB 6.1.13-139554 as well as in VB 6.1.97-139549 I see that the kernel 5.8 support is being worked on -- not all "fixes-for-*" patches are applicable anymore. Building the vboxdrv's either fails or seems to be ok, but then running it fails because of incompatibilities.
:D

[burdi01]

I tested VB 6.1.13-139679 (no "fixes-for-*") against kernel 5.8-rc7: Building the vboxdrv fails with:

/tmp/vbox.0/linux/SUPDrv-linux.c: In function ‘supdrvOSChangeCR4’:
/tmp/vbox.0/linux/SUPDrv-linux.c:760:38: error: ‘cpu_tlbstate’ undeclared (first use in this function); did you mean ‘cpuhp_state’?

I also tested VB 6.1.97-139665 (no "fixes-for-*") against kernel 5.8-rc7: Building the vboxdrv succeeds but running it fails with:

Failed to open a session for the virtual machine Burdi01z97.

The version of the device registration structure is unknown to this VBox version. Either mixing incompatible versions or the structure isn't correctly initialized. (VERR_PDM_UNKNOWN_DEVREG_VERSION).

Result Code: NS_ERROR_FAILURE (0x80004005)
Component: ConsoleWrap
Interface: IConsole {872da645-4a9b-1727-bee2-5585105b9eed}

[Jags]

Well, I can confirm that the version VirtualBox-6.1.97-139689-Linux_amd64 runs just fine with Kernel 5.8_RC7 on Ubuntu MATE 20.04

Host and guest OS were both Ubuntu MATE 20.04 64-bit.

Thanks guys :)

[burdi01]

Over here *1) running VB 6.1.97-139689 fails with the same error as 6.1.97-139665 did (see my previous post).

*1) Slackware Current64, gcc 9.3.0, kernel 5.8-rc7 downloaded from ​https://www.kernel.org/, no patches applied, configured and built by me.

To my very surprise building and running VB 6.1.97-139689 succeeded on my Xubuntu 20.04 *2).

*2) Linux riposo 5.8.0-050800rc7-generic #202007262231 SMP Sun Jul 26 22:33:51 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux downloaded from ​https://kernel.ubuntu.com/~kernel-ppa/mainline/

[burdi01]

VBox.log - VB 6.1.97-139689 against kernel 5.7.12-burdi64

[burdi01]

Actually I found that VB 6.1.97-139689 fails with the same error against kernel 5.7.12, whereas VB 6.0.12-139181 runs OK against that kernel.
Provided the VBox.log in case someone would want to see it.

[burdi01]

I cloned Xubuntu's kernel 5.8.0-050800rc7-generic to this Slackware Current64 installation.
Running VB 6.1.97-139689 fails with exactly the same error against this kernel.
Possibly the fact that this is Slackware, so e.g. without systemd is relevant here...
:D

[burdi01]

Kernel 5.8 released! Success with VB 6.1.97-139689 and Extention Pack 6.1.97-139662!
Thank you!
Dick :D

[matthewls]

Where can I find VB 6.1.97-139689 and Extention Pack 6.1.97-139662?

[What4]

Replying to matthewls:

Where can I find VB 6.1.97-139689 and Extention Pack 6.1.97-139662?

https://www.virtualbox.org/wiki/Testbuilds Under the Development snapshots section.

[matthewls]

Thanks. Same problem as before with kernel 5.7.12 and 5.8.0. Install works, VMs crash on start with

The version of the device registration structure is unknown to this VBox version. Either mixing incompatible versions or the structure isn't correctly initialized. (VERR_PDM_UNKNOWN_DEVREG_VERSION).

Result Code: NS_ERROR_FAILURE (0x80004005) Component: ConsoleWrap Interface: IConsole {872da645-4a9b-1727-bee2-5585105b9eed}

[matthewls]

The last VB version that can run VMs using kernel 5.7.12. is Version 6.1.13 r139554 (Qt5.6.1)

No VBox version I've tried works with kernel 5.8. It's likely the host modules supported by Arch/Manjaro aren't up to date yet.

[matthewls]

Updated linux58-virtualbox-host-module fixes r139554. Will test if newer VBox versions work as well.

[matthewls]

Nope, newer versions still don't run VMs, bc the vbox host module for manjaro targets VB 6.12

[LocutusOfBorg]

I'm adding the last trivial patch needed for kernel 5.8

[LocutusOfBorg]

drop-vermagic

[Frank Batschulat (Oracle)]

Replying to LocutusOfBorg:

I'm adding the last trivial patch needed for kernel 5.8

fencing linux/vermagic.h is already in the trunk gate.

[burdi01]

Stock kernel 5.8.1 on Slackware Current64:
-- VirtualBox-6.1.97-139787-Linux_amd64.run with Oracle_VM_VirtualBox_Extension_Pack-6.1.97-139662.vbox-extpack: OK
-- VirtualBox-6.1.13-139853-Linux_amd64.run with Oracle_VM_VirtualBox_Extension_Pack-6.1.13-139853.vbox-extpack: OK
:D

[matthewls]

5.8.1-2-MANJARO, Version 6.1.13 r139853 (Qt5.6.1), Oracle_VM_VirtualBox_Extension_Pack-6.1.13-139853.vbox-extpack: All work fine.

Earlier versions stopped working.

[pjwelsh]

Hopefully not a thread hijack, but CentOS 7 latest with kernel-ml (aka kernel 5.8.x at this time) does not build modules with VirtualBox-6.1-6.1.13_139853_el7-1.x86_64.rpm. No kernel-ml newer that 5.7.8 will build with VB of any current nightly version. "tail" of vbox-setup.log looks like: ./include/asm-generic/bug.h:97:3: note: in expansion of macro ‘WARN_FLAGS’

WARN_FLAGS(BUGFLAG_NO_CUT_HERE | BUGFLAG_TAINT(taint));\

./include/asm-generic/bug.h:129:3: note: in expansion of macro ‘WARN_printf’

WARN_printf(TAINT_WARN, format); \

./include/linux/debug_locks.h:31:4: note: in expansion of macro ‘WARN’

WARN(1, "DEBUG_LOCKS_WARN_ON(%s)", #c); \

./arch/x86/include/asm/desc.h:324:2: note: in expansion of macro ‘DEBUG_LOCKS_WARN_ON’

DEBUG_LOCKS_WARN_ON(preemptible());

cc1: some warnings being treated as errors

make[3]: * tmp/vbox.0/linux/SUPDrv-linux.o Error 1

make[2]: * tmp/vbox.0 Error 2

make[1]: * [sub-make] Error 2

make: * [vboxdrv] Error 2

[David C Rankin]

Archlinux 5.8 has hit. 5.2.45 testbuild (139677) fails to build modules. make.log contents:

DKMS make.log for vboxhost-5.2.45 for kernel 5.8.1-arch1-1 (x86_64)
Sat 15 Aug 2020 12:02:53 AM CDT
make: Entering directory '/usr/lib/modules/5.8.1-arch1-1/build'
  CC [M]  /var/lib/dkms/vboxhost/5.2.45/build/vboxnetflt/linux/VBoxNetFlt-linux.o
  CC [M]  /var/lib/dkms/vboxhost/5.2.45/build/vboxdrv/linux/SUPDrv-linux.o
In file included from ./include/asm-generic/percpu.h:7,
                 from ./arch/x86/include/asm/percpu.h:556,
                 from ./arch/x86/include/asm/preempt.h:6,
                 from ./include/linux/preempt.h:78,
                 from ./include/linux/spinlock.h:51,
                 from /var/lib/dkms/vboxhost/5.2.45/build/vboxdrv/linux/../SUPDrvInternal.h:76,
                 from /var/lib/dkms/vboxhost/5.2.45/build/vboxdrv/linux/SUPDrv-linux.c:32:
/var/lib/dkms/vboxhost/5.2.45/build/vboxdrv/linux/SUPDrv-linux.c: In function ‘supdrvOSChangeCR4’:
/var/lib/dkms/vboxhost/5.2.45/build/vboxdrv/linux/SUPDrv-linux.c:759:38: error: ‘cpu_tlbstate’ undeclared (first use in this function); did you mean ‘cpuhp_state’?
  759 |     RTCCUINTREG uOld = this_cpu_read(cpu_tlbstate.cr4);
      |                                      ^~~~~~~~~~~~
./include/linux/percpu-defs.h:318:9: note: in definition of macro ‘__pcpu_size_call_return’
  318 |  typeof(variable) pscr_ret__;     \
      |         ^~~~~~~~
/var/lib/dkms/vboxhost/5.2.45/build/vboxdrv/linux/SUPDrv-linux.c:759:24: note: in expansion of macro ‘this_cpu_read’
  759 |     RTCCUINTREG uOld = this_cpu_read(cpu_tlbstate.cr4);
      |                        ^~~~~~~~~~~~~
/var/lib/dkms/vboxhost/5.2.45/build/vboxdrv/linux/SUPDrv-linux.c:759:38: note: each undeclared identifier is reported only once for each function it appears in
  759 |     RTCCUINTREG uOld = this_cpu_read(cpu_tlbstate.cr4);
      |                                      ^~~~~~~~~~~~
./include/linux/percpu-defs.h:318:9: note: in definition of macro ‘__pcpu_size_call_return’
  318 |  typeof(variable) pscr_ret__;     \
      |         ^~~~~~~~
/var/lib/dkms/vboxhost/5.2.45/build/vboxdrv/linux/SUPDrv-linux.c:759:24: note: in expansion of macro ‘this_cpu_read’
  759 |     RTCCUINTREG uOld = this_cpu_read(cpu_tlbstate.cr4);
      |                        ^~~~~~~~~~~~~
make[2]: *** [scripts/Makefile.build:281: /var/lib/dkms/vboxhost/5.2.45/build/vboxdrv/linux/SUPDrv-linux.o] Error 1
make[1]: *** [scripts/Makefile.build:497: /var/lib/dkms/vboxhost/5.2.45/build/vboxdrv] Error 2
make[1]: *** Waiting for unfinished jobs....
  CC [M]  /var/lib/dkms/vboxhost/5.2.45/build/vboxnetflt/VBoxNetFlt.o
  CC [M]  /var/lib/dkms/vboxhost/5.2.45/build/vboxnetflt/SUPR0IdcClient.o
  CC [M]  /var/lib/dkms/vboxhost/5.2.45/build/vboxnetflt/SUPR0IdcClientComponent.o
  CC [M]  /var/lib/dkms/vboxhost/5.2.45/build/vboxnetflt/linux/SUPR0IdcClient-linux.o
  LD [M]  /var/lib/dkms/vboxhost/5.2.45/build/vboxnetflt/vboxnetflt.o
make: *** [Makefile:1756: /var/lib/dkms/vboxhost/5.2.45/build] Error 2
make: Leaving directory '/usr/lib/modules/5.8.1-arch1-1/build'

[Frank Batschulat (Oracle)]

Replying to drankinatty:

Archlinux 5.8 has hit. 5.2.45 testbuild (139677) fails to build m

5.2.X and 6.0.X are no longer supported.

https://www.virtualbox.org/wiki/Downloads

If you're looking for the latest VirtualBox 6.0 packages, see 
VirtualBox 6.0 builds. Please also use version 6.0 if you need to
 run VMs with software virtualization, as this has been discontinued
 in 6.1. Version 6.0 will remain supported until July 2020. 

 If you're looking for the latest VirtualBox 5.2 packages, see
 VirtualBox 5.2 builds. Please also use version 5.2 if you still 
need support for 32-bit hosts, as this has been discontinued in 6.0.
 Version 5.2 will remain supported until July 2020.

[David C Rankin]

5.2.44 does not build against Linux 5.8 -- that is why I posted this bug. I don't understand your comment "5.2.X" is no longer supported? That's news to me. I maintain that package for Archlinux through their AUR repository specifically to handle windows guests headless which the 6.X version does not handle well. (a simply "Dir" listing may take 5 minutes for 200 files) 5.2 never had that problem. With the new 5.2.44 less than 2-weeks old -- where did I miss the announcement that 5.2.X was being discontinued? It is critical given the number of headless guests I run.

[Frank Batschulat (Oracle)]

Replying to drankinatty:

5.2.44 does not build against Linux 5.8 -- that is why I posted this bug. I don't understand your comment "5.2.X" is no longer supported? That's news to me. I maintain that package for Archlinux through their AUR repository specifically to handle windows guests headless which the 6.X version does not handle well. (a simply "Dir" listing may take 5 minutes for 200 files) 5.2 never had that problem. With the new 5.2.44 less than 2-weeks old -- where did I miss the announcement that 5.2.X was being discontinued? It is critical given the number of headless guests I run.

As Is aid, see the statement on web page: https://www.virtualbox.org/wiki/Downloads

5.2.X and 6.0.X are out of support life and are unlikely getting 5.8 support.

What is the bugid of the windows/dir/headless performance problem you mentioned?

[medmedin2014]

Why are you excluding old machines without virtualization technology ? We as students need really Virtualbox for running Linux and Windows 7 VMs to practice networking and system administration courses, we don't have money to buy new machines with new CPUs, and most of machines available in our university does not support any virtualization technologies.

We need really support for 6.0 version because with the new 5.8 kernel on Manjaro I got an error while installing the .run file: error: ‘cpu_tlbstate’ undeclared (first use in this function); did you mean ‘cpuhp_state’?

[burdi01]

Stock kernel 5.8.1 on Slackware Current64:
-- VirtualBox-6.1.13-139930-Linux_amd64.run with Oracle_VM_VirtualBox_Extension_Pack-6.1.13-139930.vbox-extpack: OK
:D

[GoofyXL]

5.8-rc1 was released on June 14th and still, after 2 months, no solution for this.

[pjwelsh]

CentOS7-kernel-ml-5.8 build fail

[pjwelsh]

Just posted build log for failed build with most recent VB testbuild VirtualBox-6.1-6.1.13_139930_el7-1.x86_64.rpm

[Frank Batschulat (Oracle)]

Replying to pjwelsh:

Just posted build log for failed build with most recent VB testbuild VirtualBox-6.1-6.1.13_139930_el7-1.x86_64.rpm

Posting the build log is not enough, it helps when you actually read it.

https://www.virtualbox.org/attachment/ticket/19644/vbox-setup.log-CentOS7-kernel-ml-5.8

  gcc -Wp,-MMD,/tmp/vbox.0/linux/.SUPDrv-linux.o.d  -nostdinc -isystem /usr/lib/'''gcc/x86_64-redhat-linux/4.8.5'''
...
14	In file included from ././include/linux/compiler_types.h:68:0,
15	                 from <command-line>:0:
16	./include/linux/compiler-gcc.h:15:3: error: #error Sorry, your compiler is too old - please upgrade it.
17	 # error Sorry, your compiler is too old - please upgrade it.
18	   ^

​https://elixir.bootlin.com/linux/v5.8/source/include/linux/compiler-gcc.h

/* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145 */
#if GCC_VERSION < 40900
# error Sorry, your compiler is too old - please upgrade it.
#endif

And you are using: /usr/lib/gcc/x86_64-redhat-linux/4.8.5

[pjwelsh]

Thank you for replying. That error did strike me as odd as the same system with the same gcc setup will build under the 3.10.x kernel. The compiler is not changing. Yes, the /usr/lib/gcc/x86_64-redhat-linux/4.8.5 is in place on these systems. Why would the "el7" version of VB not be able to use it or think it's too old?

rpm -qf /usr/lib/gcc/x86_64-redhat-linux/4.8.5
gcc-4.8.5-39.el7.x86_64

Replying to fbatschu:

Replying to pjwelsh:

Just posted build log for failed build with most recent VB testbuild VirtualBox-6.1-6.1.13_139930_el7-1.x86_64.rpm

Posting the build log is not enough, it helps when you actually read it.

https://www.virtualbox.org/attachment/ticket/19644/vbox-setup.log-CentOS7-kernel-ml-5.8

  gcc -Wp,-MMD,/tmp/vbox.0/linux/.SUPDrv-linux.o.d  -nostdinc -isystem /usr/lib/'''gcc/x86_64-redhat-linux/4.8.5'''
...
14	In file included from ././include/linux/compiler_types.h:68:0,
15	                 from <command-line>:0:
16	./include/linux/compiler-gcc.h:15:3: error: #error Sorry, your compiler is too old - please upgrade it.
17	 # error Sorry, your compiler is too old - please upgrade it.
18	   ^

​https://elixir.bootlin.com/linux/v5.8/source/include/linux/compiler-gcc.h

/* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145 */
#if GCC_VERSION < 40900
# error Sorry, your compiler is too old - please upgrade it.
#endif

And you are using: /usr/lib/gcc/x86_64-redhat-linux/4.8.5

[Frank Batschulat (Oracle)]

Replying to pjwelsh:

Thank you for replying. That error did strike me as odd as the same system with the same gcc setup will build under the 3.10.x kernel. The compiler is not changing. Yes, the /usr/lib/gcc/x86_64-redhat-linux/4.8.5 is in place on these systems. Why would the "el7" version of VB not be able to use it or think it's too old?

Please read my comment carefully. The error message is not from VB, the error message comes from the Linux 5.8 kernel header files. Feel free to discuss this matter further with the Linux kernel community or the CentOS maintainers.

[pjwelsh]

Again, thank you for the response. I did not catch the inference of the issue. Thank you for pointing that out directly.

Replying to fbatschu:

Replying to pjwelsh:

Thank you for replying. That error did strike me as odd as the same system with the same gcc setup will build under the 3.10.x kernel. The compiler is not changing. Yes, the /usr/lib/gcc/x86_64-redhat-linux/4.8.5 is in place on these systems. Why would the "el7" version of VB not be able to use it or think it's too old?

Please read my comment carefully. The error message is not from VB, the error message comes from the Linux 5.8 kernel header files. Feel free to discuss this matter further with the Linux kernel community or the CentOS maintainers.

[burdi01]

Stock kernel 5.8.2 on Slackware Current64:
-- VirtualBox-6.1.13-139989-Linux_amd64.run with Oracle_VM_VirtualBox_Extension_Pack-6.1.13-139990.vbox-extpack: OK
:D

[Kwhat4]

Is there a release date for this yet? I'm asking because I need to figure out if I am going to have to put in mitigations for 5.8 upgrades on my system or if a release is coming out next week. The workarounds for this are starting to get irritating.

[David C Rankin]

Replying to burdi01:

Stock kernel 5.8.2 on Slackware Current64:
-- VirtualBox-6.1.13-139989-Linux_amd64.run with Oracle_VM_VirtualBox_Extension_Pack-6.1.13-139990.vbox-extpack: OK
:D

Confirmed in Archlinux as well with 5.8.2 and with the addition of virtualbox-ext-oracle-6.1.13.139990 (though having split testbuild build versions for virtualbox and the SDK does add a bit of complexity...) Modules build for Linux 5.8.1 and 5.8.2.

[pentagonik]

We generally don't communicate any estimated release dates and/or schedules to the public. An update will come in the not too distant future though.

[jvitalii]

Fedora 32: can't find mm/vmalloc.c

[burdi01]

Details please

[Andre Robatino]

/var/log/vbox-setup.log after running /sbin/vboxconfig in F32 with kernel-5.8.4-200.fc32.x86_64

[Andre Robatino]

I'm running F32 and did not see jvitalii's error. Attached /var/log/vbox-setup.log while running kernel-5.8.4-200.fc32.x86_64 in F32. The kernel modules build in 5.7.17 but not in 5.8.4.

[Sten]

vbox-setup.log F32

[Sten]

The /var/log/vbox-setup.log on Fedora32 produced by dkms during kernel-5.8.4 installation. Mostly the same as @robatino's except for the last few lines.

[MHamati]

Fedora 32

[MHamati]

Trying to install VBox in Fedora 32 without success:

# rpm -qa kernel |sort -V |tail -n 1
kernel-5.8.4-200.fc32.x86_64

# uname -r
5.8.4-200.fc32.x86_64

# /usr/lib/virtualbox/vboxdrv.sh setup
vboxdrv.sh: Stopping VirtualBox services.
vboxdrv.sh: Starting VirtualBox services.
vboxdrv.sh: Building VirtualBox kernel modules.
vboxdrv.sh: failed: Look at /var/log/vbox-setup.log to find out what went wrong.

# cat /var/log/vbox-setup.log
Building the main VirtualBox module.
Error building the module:
(...)
make[1]: * * * [Makefile:1756: /tmp/vbox.0] Error 2
make: * * * [ /tmp/vbox.0/Makefile-footer.gmk:117: vboxdrv] Error 2

Log attached.

[Frank Batschulat (Oracle)]

@robatino @Sten @MHamati

based on your compile error logs you all are using a released version of Virtualbox that does not support the 5.8 kernel. ONly the Trunk version with its test builds does so currently.

please stop cluttering this bug with your individual error messages unless you have something new to contribute that is not already mentioned in this bug!

Also post your Virtualbox version corresponding to the failed attempts.

[medmedin2014]

@fbatschu We need really support for 6.0 with 5.8 kernel, we use Manjaro stable in our center and we have many old machines that have not any virtualization technology (some old dual core cpus), and we need really virtualbox to help students practice network and administration courses.

[sergiomb]

Replying to pentagonik:

We generally don't communicate any estimated release dates and/or schedules to the public. An update will come in the not too distant future though.

Well, this time would be nice , know if you going release it this week . Or if I should look for alternatives like of use VirtualBox-6.1.13. like in ​https://build.opensuse.org/package/show/Virtualization/virtualbox

Kernel-5.8.4 was landed on Fedora 32 and very soon on Fedora 31 (stable versions of Fedora)

[David C Rankin]

I don't know if you want this bug here, but 6.1.13 testbuilds cause Windows7 Headless guests to BlueScreen when attempting to install or update software. After the UAC screen is shown, and Okay clicked, the entire desktop remains grayed as if the UAC dialog was displayed, about 5 seconds pass and then Wham! Blue Screen and windows crashes back to the VirtualBox 6.1 boot screen and reboots.

It definitely has something to do with "Interactive Terminal Detection". When that is displayed and you click to return BLUE SCREEN- reboot. The Event Viewer logs the crash as a "kernel power" crash.

I can move this to another bug if needed, but I have never seen behavior like this before.

[Andre Robatino]

Confirming that the newly released VB 6.1.14 works with the 5.8.4 kernel. Thanks!

[Frank Batschulat (Oracle)]

fixed in Virtualbox release 6.1.14

[medmedin2014]

Replying to fbatschu:

fixed in Virtualbox release 6.1.14

Such a shame to be fixed only for new version and not for 6.0. You care only for people who have new hardware and not for the common people (especially poor ones) that have already old machines and need them for studying or working.

[hwertz]

6.0.24 patch 1

[hwertz]

6.0.24 patch 2

[hwertz]

Virtualbox 6.0.24 patch 3

[hwertz]

Virtualbox 6.0.24 patch 4

[hwertz]

Virtualbox 6.0.24 patch 5

[hwertz]

Virtualbox 6.0.24 patch 6

[hwertz]

For 6.0.24, these get it to build. I pulled these from "meta-oe-vboxguestdrivers-Fix-build-with-kernel-5.8.patch" which was for 6.1.x series. These are I suppose against the build tree, but I patched the (6.0.24) files in /usr/share/virtualbox/src/vboxhost/vboxdrv/ that are used to build the kernel modules. For the -p4 patches, I changed to /usr/share/virtualbox/src/vboxhost/vboxdrv/ and applied them like "sudo patch -p4 < ~/path/to/vb-6.0.24-kernel-5.8-p4-1.patch" on each patch. The other patch, "sudo patch -p5 < ~/path/to/vb-6.0.24-kernel-5.8-p5-1.patch". Patch 2 rejects 1 line, but it's a one-line comment saying (paraphrasing) "todo, kernel 5.8 always applies NX (No eXecute) anyway" so no problem on the reject.

The sharedfolder patch, I didn't use it but I suppose it's for guest extensions? Included it if you do want to try patching guest extensions, but I didn't try it. I'm guessing it's possible to run 6.1.x guest additions if I need to run a 5.8+ VM (running non-matching guest additions is likely not supported, but neither is vb 6.0.x series anyway, if it works it works, if not try the patch I suppose.)

[hwertz]

Still doesn't run... SUP_IOCTL_LDR_OPEN failed (VERR_NO_EXEC_MEMORY). Will look into it.

[hwertz]

Sorry, looks like patching up 6.0.x will be more difficult. Those patches above compile, and I found several more patches from the 5.8 meta-oe-vboxguestdrivers-Fix-buil-with-kernel-5.8.patch I had missed that applied and built cleanly, but no dice. I ended up with "Failed to load R0 module /usr/lib/virtualbox/VMMR0.r0: RTLdrGetBits failed (VERR_SYMBOL_VALUE_TOO_BIG).", due to not applying more needed patches that will not apply cleanly.

The first few patches are the "the system call got renamed, or moved to another header" type of patches, a 1 line fix; the map_vm_area() changes look more extensive but contained, and patch code that's identical in 6.0.24 to 6.1.14 or whatever they were for... however, the map_vm_area() replacement relies on the ELF loader patches that are in the meta-oe patch (ring 0 binary it loads is an ELF executable), but THOSE patches don't apply cleanly at all, even patching files that don't exist in 6.0.24. Probably doable but a bit more time than I care to spend working through it... my single 64-bit system that does not have virtualization extensions is not fast at all, and runs a VM even slower, I just thought I'd put up some quick patches if I could.