In the Linux kernel, the following vulnerability has been resolved: virtio: use virtiodeviceready() in virtiodevicerestore() After waking up a suspended VM, the kernel prints the following trace for virtio drivers which do not directly call virtiodeviceready() in the .restore: PM: suspend exit irq 22: nobody cared (try booting with the "irqpoll" option) Call Trace: <IRQ> dumpstacklvl+0x38/0x49 dumpstack+0x10/0x12 _reportbadirq+0x3a/0xaf noteinterrupt.cold+0xb/0x60 handleirqevent+0x71/0x80 handlefasteoiirq+0x95/0x1e0 _commoninterrupt+0x6b/0x110 commoninterrupt+0x63/0xe0 asmcommoninterrupt+0x1e/0x40 ? _dosoftirq+0x75/0x2f3 irqexitrcu+0x93/0xe0 sysvecapictimerinterrupt+0xac/0xd0 </IRQ> <TASK> asmsysvecapictimerinterrupt+0x12/0x20 archcpuidle+0x12/0x20 defaultidlecall+0x39/0xf0 doidle+0x1b5/0x210 cpustartupentry+0x20/0x30 startsecondary+0xf3/0x100 secondarystartup64noverify+0xc3/0xcb </TASK> handlers: [<000000008f9bac49>] vpinterrupt [<000000008f9bac49>] vpinterrupt Disabling IRQ #22 This happens because we don't invoke .enablecbs callback in virtiodevicerestore(). That callback is used by some transports (e.g. virtio-pci) to enable interrupts. Let's fix it, by calling virtiodeviceready() as we do in virtiodevprobe(). This function calls .enablects callback and sets DRIVEROK status bit. This fix also avoids setting DRIVEROK twice for those drivers that call virtiodevice_ready() in the .restore.