Re: [PATCH v11 04/10] virtio-gpu: Support asynchronous fencing

[Sean Christopherson <seanjc@google.com>]

On Sun, Apr 27, 2025, Alex Bennée wrote:
> 刘聪 <liucong2565@phytium.com.cn> writes:
> 
> > Hi Dmitry,
> >
> > The virglrender patch can fix the virgl issue, but the native context still
> > fails to run on my machine.  I'm not sure if anyone has successfully run it
> > on an ARM64 machine before.
> >
> > When running with Venus, the virtual machine can successfully run vkcube.
> > However, when using the native context, a KVM error is triggered. Both my
> > guest and host kernels are already updated to version 6.14.
> >
> > Here are the commands and error messages I encountered:
> >
> > ```
> > phytium@ubuntu:~/working/virglrenderer$
> > /opt/native-context-v11/bin/qemu-system-aarch64 --machine
> > virt,accel=kvm,memory-backend=mem1 -cpu host -smp 4 -m 4G -drive
> > file=/home/phytium/working/ubuntu24.04-aarch64-native-context,format=raw,if=virtio
> > -bios /usr/share/AAVMF/AAVMF_CODE.ms.fd -netdev user,id=net0 -device
> > virtio-net-pci,netdev=net0 -device
> > virtio-gpu-gl,hostmem=4G,blob=on,venus=on -object
> > memory-backend-memfd,id=mem1,size=4G -display sdl,gl=on,show-cursor=on
> > -device usb-ehci,id=usb -device usb-mouse,bus=usb.0 -device
> > usb-kbd,bus=usb.0
> > phytium@ubuntu:~/working/virglrenderer$ 
> > phytium@ubuntu:~/working/virglrenderer$
> > /opt/native-context-v11/bin/qemu-system-aarch64 --machine
> > virt,accel=kvm,memory-backend=mem1 -cpu host -smp 4 -m 4G -drive
> > file=/home/phytium/working/ubuntu24.04-aarch64-native-context,format=raw,if=virtio
> > -bios /usr/share/AAVMF/AAVMF_CODE.ms.fd -netdev user,id=net0 -device
> > virtio-net-pci,netdev=net0 -device
> > virtio-gpu-gl,hostmem=4G,blob=on,drm_native_context=on -object
> > memory-backend-memfd,id=mem1,size=4G -display sdl,gl=on,show-cursor=on
> > -device usb-ehci,id=usb -device usb-mouse,bus=usb.0 -device
> > usb-kbd,bus=usb.0
> > error: kvm run failed Bad address
> 
> That very much looks like a page not being accessible when trying to do
> something.

Yep.  The most likely scenario where KVM_RUN returns -EFAULT is when KVM can't
obtain a PFN for the faulting GPA.  Odds are good it's this code:

	pfn = __kvm_faultin_pfn(memslot, gfn, write_fault ? FOLL_WRITE : 0,
				&writable, &page);
	if (pfn == KVM_PFN_ERR_HWPOISON) {
		kvm_send_hwpoison_signal(hva, vma_shift);
		return 0;
	}
	if (is_error_noslot_pfn(pfn))   <==========
		return -EFAULT;

where under the hood, __kvm_faultin_pfn() is a wrapper to gup() and
follow_pfnmap_start() (and some other things).

If you can figure out which GPA is failing, then it's "just" a matter of figuring
out why KVM doesn't find a valid mapping.