WIP: Allow compiling the virtio-gpu driver

[arichardson]

This imports the Linux 5.5 sources for virtio-gpu and adds some basic compilation fixes on top of that.

Depends on https://reviews.freebsd.org/D32372.

When starting QEMU with -device virtio-gpu-pci the driver autoloads and promptly panics the kernel 😄

Building /boot/kernel/linker.hints
Autoloading module: intpm
Autoloading module: virtio_gpu
[drm:drm_core_init] Initialized
Autoloading module: virtio_random
intsmb0: <Intel PIIX4 SMBUS Interface> irq 9 at device 1.3 on pci0
intsmb0: intr IRQ 9 enabled revision 0
smbus0: <System Management Bus> on intsmb0
vtgpu_probe
vtrnd0: <VirtIO Entropy Adapter> on virtio_pci2
random: registering fast source VirtIO Entropy Adapter
vtgpu_probe
vtgpu_probe
vtgpu0: <Virtio GPU driver> on virtio_pci3
vtgpu_attach


Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address	= 0x30
fault code		= supervisor read data, page not present
instruction pointer	= 0x20:0xffffffff80c637ef
stack pointer	        = 0x28:0xfffffe0085d3e850
frame pointer	        = 0x28:0xfffffe0085d3e860
code segment		= base 0x0, limit 0xfffff, type 0x1b
			= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags	= interrupt enabled, resume, IOPL = 0
current process		= 115 (devctl)
trap number		= 12
panic: page fault
cpuid = 0
time = 1633727026
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0085d3e4f0
vpanic() at vpanic+0x187/frame 0xfffffe0085d3e550
panic() at panic+0x43/frame 0xfffffe0085d3e5b0
trap_fatal() at trap_fatal+0x387/frame 0xfffffe0085d3e610
trap_pfault() at trap_pfault+0x99/frame 0xfffffe0085d3e670
trap() at trap+0x2a7/frame 0xfffffe0085d3e780
calltrap() at calltrap+0x8/frame 0xfffffe0085d3e780
--- trap 0xc, rip = 0xffffffff80c637ef, rsp = 0xfffffe0085d3e850, rbp = 0xfffffe0085d3e860 ---
device_add_child_ordered() at device_add_child_ordered+0x2f/frame 0xfffffe0085d3e860
device_initialize() at device_initialize+0x7d/frame 0xfffffe0085d3e890
drm_sysfs_minor_alloc() at drm_sysfs_minor_alloc+0x9b/frame 0xfffffe0085d3e8d0
drm_minor_alloc() at drm_minor_alloc+0xb7/frame 0xfffffe0085d3e900
drm_dev_init() at drm_dev_init+0x22b/frame 0xfffffe0085d3e960
drm_dev_alloc() at drm_dev_alloc+0x3c/frame 0xfffffe0085d3e990
virtio_gpu_probe() at virtio_gpu_probe+0x26/frame 0xfffffe0085d3e9c0
device_attach() at device_attach+0x3c1/frame 0xfffffe0085d3ea00
vtpci_modern_probe_and_attach_child() at vtpci_modern_probe_and_attach_child+0x77/frame 0xfffffe0085d3ea30
devclass_driver_added() at devclass_driver_added+0x39/frame 0xfffffe0085d3ea70
devctl2_ioctl() at devctl2_ioctl+0x6ea/frame 0xfffffe0085d3eb40
devfs_ioctl() at devfs_ioctl+0xcd/frame 0xfffffe0085d3eb90
vn_ioctl() at vn_ioctl+0x131/frame 0xfffffe0085d3eca0
devfs_ioctl_f() at devfs_ioctl_f+0x1e/frame 0xfffffe0085d3ecc0
kern_ioctl() at kern_ioctl+0x202/frame 0xfffffe0085d3ed30
sys_ioctl() at sys_ioctl+0x124/frame 0xfffffe0085d3ee00
amd64_syscall() at amd64_syscall+0x12e/frame 0xfffffe0085d3ef30
fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0085d3ef30
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8011a946a, rsp = 0x7fffffffeb08, rbp = 0x7fffffffebc0 ---
KDB: enter: panic
[ thread pid 115 tid 100075 ]
Stopped at      kdb_enter+0x37: movq    $0,0x12722ce(%rip)
db>

[evadot]

Few things :
We are at 5.6 now but updating shouldn't be hard.
We don't want new GPL-2.0 licensed file as the plan is to move everything back to base and unfortunately drm_gem_shmem_helper.c is not dual licensed.
It looks like that you import some files in one commit and fix compile after, I would prefer to import patched files, this avoid ending in this commit during a bisect and finding that the tree isn't buildable.

[arichardson]

Few things : We are at 5.6 now but updating shouldn't be hard.

Will update to 5.6 shortly.

We don't want new GPL-2.0 licensed file as the plan is to move everything back to base and unfortunately drm_gem_shmem_helper.c is not dual licensed.

I haven't looked at what is actually needed in drm_gem_shmem_helper.c, I could also add stubs for the functions that are called there instead of importing the file?

It looks like that you import some files in one commit and fix compile after, I would prefer to import patched files, this avoid ending in this commit during a bisect and finding that the tree isn't buildable.

In the commit that imports them they are not hooked up to the build, so it shouldn't cause bisection issues. I did it as separate commit since it makes it much easier to re-apply the compilation fixes when updating the baseline to a new linux version.

[evadot]

Few things : We are at 5.6 now but updating shouldn't be hard.

Will update to 5.6 shortly.

We don't want new GPL-2.0 licensed file as the plan is to move everything back to base and unfortunately drm_gem_shmem_helper.c is not dual licensed.

I haven't looked at what is actually needed in drm_gem_shmem_helper.c, I could also add stubs for the functions that are called there instead of importing the file?

Pretty sure that stubs will not be enough so you might need to rewrite this file.

It looks like that you import some files in one commit and fix compile after, I would prefer to import patched files, this avoid ending in this commit during a bisect and finding that the tree isn't buildable.

In the commit that imports them they are not hooked up to the build, so it shouldn't cause bisection issues. I did it as separate commit since it makes it much easier to re-apply the compilation fixes when updating the baseline to a new linux version.

Ah indeed, I've seen the virtio-gpu/Makefile and though it was hooked into the build.

[ylluminate]

Thanks so much for your work in this critically important effort. I'm sorry it seems you've hit some delays / roadblocks here. I understand from the conversation thus far that challenges presently seem to consist of the following points:

• addressing the kernel panic issue when starting QEMU,
• navigating licensing concerns around drm_gem_shmem_helper.c, and
• the potential update to Linux 5.6 sources.

Are these the main points and has any progress been made since the last July 2022 update?

Is there any chance any points could be moved along by those of us who are not as intimate with the project or can provide you with some level of support, etc?

[arichardson]

I'm afraid I stopped working on this a long time ago and have not had time to get back to it.

However, it appears a basic virtio-gpu drive has already been merged to the kernel: https://reviews.freebsd.org/D40094. I have no idea how the functionality compares to the Linux driver though (CC: @zxombie)