panic: the crash screen reaches every display, not just the console's

"it also doesn't show crash screen on virtio gpu or just other gpu than default
vga" -- true, and on the virtio-gpu it was worse than nothing. The head kept
showing the console from a second before the panic: one screen saying the
kernel is dead, the other showing a shell prompt.

panic() painted into the console framebuffer and stopped there. Two cases were
missing, and they are not the same problem.

**The kernel still drives it.** display_acquire() hands back a buffer; the
report is copied in and presented. Ordinary, and a no-op when the display
class's buffer *is* the console's, so a one-screen machine does not do the work
twice.

**A process drives it.** The hard one, and the one hybrid.md owed an answer
for. The kernel let go of the device deliberately, and the process holding it
will never run again -- there is no scheduling after a panic -- so there is
nobody left to ask. It is not a race that can be won by being careful.

So the userspace driver says where it is scanning out *in advance*:
PCIIOC_PANICFB, registered by vgpud after bring-up and after every modeset. On
a panic the kernel paints the report into that memory and asks the kernel
driver the device was taken from to put it on screen one last time --
`panic_present` in struct pci_driver, which virtio-gpu implements by resetting
the device out from under a driver that is still nominally running. That is
safe here and nowhere else, because nothing is going to run again.

The panic path allocates nothing. It cannot: a corrupted heap is one of the
ways a machine gets here, and an allocator that deadlocks takes the crash
screen *and* the serial log's last chance to be read. So the driver keeps its
BAR mappings across the handover, rebuilds one queue from 20 KB of static
memory, and bounds every spin -- including the reset acknowledge, which is an
unbounded `while` in probe() and correct there.

**The registration is checked like the promise it is.** The range must lie
inside a block that process got from PCIIOC_DMA on that device. Without that,
a claimed device would be a way to nominate any physical address in the machine
-- page tables, kernel text -- to be overwritten with four megabytes of crash
report at the one moment nothing is left to notice. That is a worse bug than
the one this fixes. It goes away with the claim and with the process.

What it buys is worth stating plainly: a device can be evicted to userspace
without the kernel losing its ability to tell you the machine died. The
alternative was a driver boundary that is also a blind spot.

Verified both ways under QEMU with two heads, `echo c > /proc/sysrq`, and a
screendump of each over QMP:

  vgpud holding the device   both heads byte-identical, serial says
                             "The report is on the virtio-gpu display too."
  kernel holding it          same, via display_acquire/display_present
                             (/proc/pci shows 1af4:1050 [virtio-gpu])

Both supported configurations: one boot each, no traps, no panics, socktest and
memfdtest green.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

include/pciuser.h

@@ -91,6 +91,7 @@ struct pciuser_dma {
 #define PCIIOC_RELEASE  0x9003   // in: int index
 #define PCIIOC_DMA      0x9004   // struct pciuser_dma
 #define PCIIOC_CFG      0x9006   // struct pciuser_cfg -- read config space
+#define PCIIOC_PANICFB  0x9007   // struct pciuser_panicfb -- see below
 #define PCIIOC_IRQ      0x9005   // in: int index -- deliver this device's
                                  //     interrupts to this process
 
@@ -123,6 +124,52 @@ struct pciuser_dma {
 
 
 
+// --- the crash screen, on a display the kernel no longer drives ------------
+//
+// A userspace display driver leaves a hole the kernel cannot see around: when
+// the machine panics, the screen this process is scanning out is frozen at
+// whatever it last put there. The machine is dead and its second monitor is
+// still showing a shell prompt.
+//
+// The kernel cannot fix that by itself. It let go of the device deliberately
+// (PCIIOC_CLAIM), and the process that took it will not run again -- panic
+// means no scheduling, so there is nobody left to ask.
+//
+// So a userspace display driver tells the kernel, in advance, where its
+// scanout lives:
+//
+//     struct pciuser_panicfb pfb;
+//     pfb.index  = index;         // the device, already claimed
+//     pfb.paddr  = dma.paddr;     // the framebuffer, from PCIIOC_DMA
+//     pfb.width  = 1280;
+//     pfb.height = 800;
+//     pfb.stride = 1280 * 4;      // bytes per row; XRGB8888 only
+//     ioctl(fd, PCIIOC_PANICFB, &pfb);
+//
+// and on a panic the kernel paints the crash report into that memory and asks
+// the driver it handed the device to -- its *kernel* driver, the one that was
+// told to let go -- to put it on screen one last time. That driver resets the
+// device and brings up a minimal queue from static memory: no allocation, no
+// locks, nothing that can fail differently depending on what the machine was
+// doing when it died.
+//
+// Registering is a promise about memory, so it is checked like one: the range
+// must lie inside a block this process got from PCIIOC_DMA on this device.
+// Without that check it would be a way to nominate any physical address in the
+// machine to be overwritten at panic, which is a worse bug than the one it
+// fixes.
+//
+// A zero paddr unregisters. The registration goes away with the claim and with
+// the process, so a driver that exits leaves nothing behind.
+struct pciuser_panicfb {
+    unsigned int       index;    // in: the claimed device
+    unsigned long long paddr;    // in: physical address of the scanout, 0 to
+                                 //     unregister
+    unsigned int       width;    // in: pixels
+    unsigned int       height;
+    unsigned int       stride;   // in: bytes per row
+};
+
 // Registers are reached with mmap() on this device, where the *offset is the
 // physical address of the BAR*:
 //