VirtualBox

Ticket #19644 (closed defect: fixed)

Opened 4 months ago

Last modified 3 weeks ago

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

Reported by: fbatschu Owned by: fbatschu
Component: other Version: VirtualBox 6.1.10
Keywords: linux kernel 5.8 Cc:
Guest type: Linux Host type: Linux

Description

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

Attachments

fixes_for_mm_struct.patch Download (5.1 KB) - added by Larry Finger 4 months ago.
Apply fixes needed for kernel 5.8 difference in struct mm_struct
fixes_for_changes_in_cpu_tlbstate.patch Download (834 bytes) - added by Larry Finger 4 months ago.
Fixes associated with hiding of cputlbstate
fixes_for_module_memory.patch Download (1.7 KB) - added by Larry Finger 4 months ago.
Fixes for module memory
local_patches Download (666 bytes) - added by Larry Finger 4 months ago.
Changes needed for kernel 5.8 for patch to module_memory to work
VBox.log Download (33.6 KB) - added by burdi01 8 weeks ago.
VBox.log - VB 6.1.97-139689 against kernel 5.7.12-burdi64
kernel-5.8-4.patch Download (700 bytes) - added by LocutusOfBorg 7 weeks ago.
drop-vermagic
vbox-setup.log-CentOS7-kernel-ml-5.8 Download (399.4 KB) - added by pjwelsh 6 weeks ago.
CentOS7-kernel-ml-5.8 build fail
vbox-setup.log Download (7.0 KB) - added by robatino 4 weeks ago.
/var/log/vbox-setup.log after running /sbin/vboxconfig in F32 with kernel-5.8.4-200.fc32.x86_64
vbox-setup.log.1 Download (31.8 KB) - added by Sten 4 weeks ago.
vbox-setup.log F32
vbox-setup.2.log Download (60.7 KB) - added by MHamati 4 weeks ago.
Fedora 32

Change History

comment:1 Changed 4 months ago by fbatschu

  • Keywords linux kernel 5.8 added
  • Owner set to fbatschu
  • Status changed from new to accepted

comment:2 Changed 4 months ago by fbatschu

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.

Last edited 2 months ago by fbatschu (previous) (diff)

comment:3 Changed 4 months ago by 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.

Changed 4 months ago by Larry Finger

Apply fixes needed for kernel 5.8 difference in struct mm_struct

Changed 4 months ago by Larry Finger

Fixes associated with hiding of cputlbstate

Changed 4 months ago by Larry Finger

Fixes for module memory

Changed 4 months ago by Larry Finger

Changes needed for kernel 5.8 for patch to module_memory to work

comment:4 Changed 4 months ago by 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.

comment:5 Changed 3 months ago by 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.

comment:6 Changed 3 months ago by burdi01

Any news from the front?
:D

Last edited 3 months ago by burdi01 (previous) (diff)

comment:7 Changed 3 months ago by 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.

comment:8 Changed 3 months ago by 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. 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

Last edited 2 months ago by burdi01 (previous) (diff)

comment:9 Changed 2 months ago by 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.

Last edited 2 months ago by burdi01 (previous) (diff)

comment:10 Changed 2 months ago by 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

Last edited 2 months ago by burdi01 (previous) (diff)

comment:11 Changed 2 months ago by 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}


Last edited 2 months ago by burdi01 (previous) (diff)

comment:12 Changed 8 weeks ago by 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 :)

comment:13 Changed 8 weeks ago by 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/

Last edited 8 weeks ago by burdi01 (previous) (diff)

Changed 8 weeks ago by burdi01

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

comment:14 Changed 8 weeks ago by 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.

Last edited 8 weeks ago by burdi01 (previous) (diff)

comment:15 Changed 8 weeks ago by 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

Last edited 8 weeks ago by burdi01 (previous) (diff)

comment:16 Changed 8 weeks ago by burdi01

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

Last edited 8 weeks ago by burdi01 (previous) (diff)

comment:17 follow-up: ↓ 18 Changed 8 weeks ago by matthewls

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

comment:18 in reply to: ↑ 17 Changed 8 weeks ago by 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.

comment:19 Changed 8 weeks ago by 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}

comment:20 Changed 8 weeks ago by 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.

comment:21 Changed 7 weeks ago by matthewls

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

comment:22 Changed 7 weeks ago by matthewls

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

comment:23 follow-up: ↓ 24 Changed 7 weeks ago by LocutusOfBorg

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

Last edited 7 weeks ago by LocutusOfBorg (previous) (diff)

Changed 7 weeks ago by LocutusOfBorg

drop-vermagic

comment:24 in reply to: ↑ 23 Changed 7 weeks ago by fbatschu

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.

comment:25 Changed 7 weeks ago by 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

comment:26 Changed 7 weeks ago by 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.

comment:27 Changed 7 weeks ago by 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

comment:28 follow-up: ↓ 29 Changed 6 weeks ago by drankinatty

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'

comment:29 in reply to: ↑ 28 Changed 6 weeks ago by fbatschu

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.

comment:30 follow-up: ↓ 31 Changed 6 weeks ago by 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.

comment:31 in reply to: ↑ 30 Changed 6 weeks ago by fbatschu

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?

comment:32 Changed 6 weeks ago by 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’?

comment:33 Changed 6 weeks ago by 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

Last edited 6 weeks ago by burdi01 (previous) (diff)

comment:34 Changed 6 weeks ago by GoofyXL

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

Changed 6 weeks ago by pjwelsh

CentOS7-kernel-ml-5.8 build fail

comment:35 follow-up: ↓ 36 Changed 6 weeks ago by 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

comment:36 in reply to: ↑ 35 ; follow-up: ↓ 37 Changed 6 weeks ago by 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

comment:37 in reply to: ↑ 36 ; follow-up: ↓ 38 Changed 6 weeks ago by 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

Last edited 6 weeks ago by pjwelsh (previous) (diff)

comment:38 in reply to: ↑ 37 ; follow-up: ↓ 39 Changed 6 weeks ago by 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.

comment:39 in reply to: ↑ 38 Changed 6 weeks ago by 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.

comment:40 follow-up: ↓ 42 Changed 6 weeks ago by 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

comment:41 in reply to: ↑ description Changed 6 weeks ago by 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.

comment:42 in reply to: ↑ 40 Changed 5 weeks ago by drankinatty

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.

comment:43 follow-up: ↓ 51 Changed 5 weeks ago by 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.

comment:44 Changed 4 weeks ago by jvitalii

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

comment:45 Changed 4 weeks ago by burdi01

Details please

Changed 4 weeks ago by robatino

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

comment:46 Changed 4 weeks ago by 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.

Changed 4 weeks ago by Sten

vbox-setup.log F32

comment:47 Changed 4 weeks ago by 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.

Changed 4 weeks ago by MHamati

Fedora 32

comment:48 Changed 4 weeks ago by 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.

Last edited 4 weeks ago by MHamati (previous) (diff)

comment:49 Changed 4 weeks ago by fbatschu

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

comment:50 Changed 4 weeks ago by 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.

comment:51 in reply to: ↑ 43 Changed 4 weeks ago by 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)

comment:52 Changed 3 weeks ago by drankinatty

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.

Last edited 3 weeks ago by drankinatty (previous) (diff)

comment:53 Changed 3 weeks ago by robatino

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

comment:54 follow-up: ↓ 55 Changed 3 weeks ago by fbatschu

  • Status changed from accepted to closed
  • Resolution set to fixed
  • Summary changed from Linux kernel version: 5.8 - we need changes to Linux kernel version: 5.8 - we need changes (fixed in 6.1.14)

fixed in Virtualbox release 6.1.14

comment:55 in reply to: ↑ 54 Changed 3 weeks ago by 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.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use