Bug#1102889: linux-image-6.1.0-33-amd64: KVM GPU passthrough broken
Control: tags -1 + upstream moreinfo
Hi Markus,
On Sat, Apr 12, 2025 at 10:23:23PM +0200, Markus wrote:
> Package: src:linux
> Version: 6.1.133-1
> Severity: normal
>
> Dear Maintainer,
>
> Upgrading to newest kernel yields to not being able to start my Windows VM any more with GPU passthough.
> Without GPU passthrough, it still works.
> In the qemu log it says:
>
> --------------
> 2025-04-12T19:37:09.158005Z qemu-system-x86_64: vfio_dma_map(0x561d923994f0, 0xc0000, 0x20000, 0x7f3c09a00000) = -12 (Cannot allocate memory)
> qemu: hardware error: vfio: DMA mapping failed, unable to continue
> CPU #0:
> EAX=00000000 EBX=00000000 ECX=00000000 EDX=000506e3
> ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000
> EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
> ES =0000 00000000 0000ffff 00009300
> CS =f000 ffff0000 0000ffff 00009b00
> SS =0000 00000000 0000ffff 00009300
> DS =0000 00000000 0000ffff 00009300
> FS =0000 00000000 0000ffff 00009300
> GS =0000 00000000 0000ffff 00009300
> LDT=0000 00000000 0000ffff 00008200
> TR =0000 00000000 0000ffff 00008b00
> GDT= 00000000 0000ffff
> IDT= 00000000 0000ffff
> CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000
> DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
> DR6=00000000ffff0ff0 DR7=0000000000000400
> EFER=0000000000000000
> FCW=037f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
> FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
> FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
> FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
> FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
> XMM00=0000000000000000 0000000000000000 XMM01=0000000000000000 0000000000000000
> XMM02=0000000000000000 0000000000000000 XMM03=0000000000000000 0000000000000000
> XMM04=0000000000000000 0000000000000000 XMM05=0000000000000000 0000000000000000
> XMM06=0000000000000000 0000000000000000 XMM07=0000000000000000 0000000000000000
> -----------------
>
> Snippets from my KVM config:
> -----------------
> <cpu mode='custom' match='exact' check='full'>
> <model fallback='forbid'>Skylake-Client-IBRS</model>
> <vendor>Intel</vendor>
> <topology sockets='1' dies='1' cores='8' threads='1'/>
> <maxphysaddr mode='passthrough'/>
> <feature policy='require' name='ss'/>
> <feature policy='require' name='pcid'/>
> <feature policy='require' name='hypervisor'/>
> <feature policy='require' name='arat'/>
> <feature policy='require' name='tsc_adjust'/>
> <feature policy='require' name='umip'/>
> <feature policy='require' name='md-clear'/>
> <feature policy='require' name='ssbd'/>
> <feature policy='require' name='xsaveopt'/>
> <feature policy='disable' name='rtm'/>
> <feature policy='disable' name='hle'/>
> </cpu>
> -----------------
> <hostdev mode='subsystem' type='pci' managed='yes'>
> <driver name='vfio'/>
> <source>
> <address domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
> </source>
> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
> </hostdev>
> <hostdev mode='subsystem' type='pci' managed='yes'>
> <driver name='vfio'/>
> <source>
> <address domain='0x0000' bus='0x01' slot='0x00' function='0x1'/>
> </source>
> <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/>
> </hostdev>
> <hostdev mode='subsystem' type='pci' managed='yes'>
> <driver name='vfio'/>
> <source>
> <address domain='0x0000' bus='0x00' slot='0x14' function='0x0'/>
> </source>
> <address type='pci' domain='0x0000' bus='0x07' slot='0x00' function='0x0'/>
> </hostdev>
> -----------------
>
> The devices in question are listed below (01:00.0 and 01:00.1). No, they are not claimed by any driver within Debian..
>
> * What led up to the situation?
> Upgrading from linux-image-6.1.0-32-amd64 to linux-image-6.1.0-33-amd64
>
> * What exactly did you do (or not do) that was effective (or
> ineffective)?
> Trying to start a KVM VM with GPU passthrough
> Booting into linux-image-6.1.0-32-amd64 fixed the problem and I can start my Windows VM again.
>
> * What was the outcome of this action?
> See log above
>
> * What outcome did you expect instead?
> VM starts
Thanks a lot for the report, want to look at it ASAP.
Do you have after trying to start such a VM a full kernel log as well
from the host please?
Would you have the capacity to do a bisection of the upstream kernels
between 6.1.129 and 6.1.133 (and ideally test the newest 6.1.134 as
well) to identify the breaking commit?
Regards,
Salvatore
Reply to: