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
