[vbox-dev] Problem with kernel 5.8

Larry Finger Larry.Finger at lwfinger.net
Thu Jun 11 22:21:03 GMT 2020


On 6/8/20 4:12 AM, Frank Batschulat wrote:
> Larry, thanks - this work will be tracked with:
> 
> Ticket #19644 (accepted defect)
> Linux kernel version: 5.8 - we need changes
> https://www.virtualbox.org/ticket/19644

With each update to the mainline kernel, another API change for Kernel 5.8 
emerges. Thus far, there have been three different changes:

1. In struct mm_struct, member mmap_sem is renamed to mmap_lock. The comment in 
the commit says "Rename the mmap_sem field to mmap_lock.  Any new uses of this 
lock should now go through the new mmap locking api.  The mmap_lock is still
implemented as a rwsem, though this could change in the future." Until that 
unknown future time, only the member name needs to change, and that is what I 
propose.

2. The shadow set of kernel quantities stored in cpu_tlbstate are no longer 
available. The only quantity used from that structure is CR4. My fix is to use 
__read_cr4() rather than this_cpu_read(cpu_tlbstate.cr4) to read CR4, and 
ASMSetCR4(uNew) rather than this_cpu_write(cpu_tlbstate.cr4, uNew) to write a 
new value into CR4. This change has tested OK.

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

Until there is a fix for the code using RTMEMALLOC_EXEC_HEAP, I will be 
recommending that the openSUSE versions of 5.8 include a patch that exports 
__get_vm_area_caller() and map_kernel_range(). The latter routine is used to 
replace map_vm_area. With these two changes, the VB modules build and execute. I 
will be posting the patches for vboxdrv and the proposed kernel patch at 
https://www.virtualbox.org/ticket/19644.

As an editorial aside, it is clear that VirtualBox needs to get at least part of 
vboxdrv into the kernel as a module in the way that VMWare has done so that this 
incompatibility with memory management never occurs again.

Larry






More information about the vbox-dev mailing list