hybrid: the GPU driver now runs in userspace
docs/plan/hybrid.md's first eviction. cmd/vgpud is the virtio-gpu driver as a
process: it finds the device by vendor and device id, asks the kernel for it,
and does the whole virtio 1.0 bring-up from outside -- reset, feature
negotiation, a virtqueue in DMA memory, GET_DISPLAY_INFO, RESOURCE_CREATE_2D,
ATTACH_BACKING, SET_SCANOUT, TRANSFER and FLUSH.
vgpud: virtio-gpu at 00:03.0, currently held by virtio-gpu
virtio-gpu: released to userspace; screen is the VBE framebuffer
vgpud: claimed
vgpud: display is 1280x800
vgpud: scanout is ours, framebuffer at physical 0x3eceb000
vgpud: drew a test pattern from userspace
Verified by screendumping the virtio-gpu head: the pattern is there, with a
checkerboard that would shear if the stride were wrong. The console carries on
in VBE on the other head at the same time, which is the fallback rule from the
plan working rather than being described.
No syscall knows this is a GPU. The kernel handed over a PCI device and the
process decided what it was -- which is the property that makes this a general
mechanism, and the reason the evictions come before anything foreign.
Four things the first real driver needed that the test program had not:
- PCI config space (PCIIOC_CFG). A virtio device says where its registers
are in vendor capabilities, which live in config space, so a driver that
cannot read it cannot find its own registers.
- a way for the incumbent to let go: struct pci_driver gained a release
hook. A driver without one keeps its device, which is always safe and for
anything on the path to a shell is also correct.
- the outgoing driver freeing its DMA. Releasing the device but keeping its
4 MB framebuffer is half a handover -- the incoming driver asks for one and
is told there is no room.
- a 16 MB DMA arena. 4 MB was exactly one framebuffer at this resolution,
and either side of a handover there are two.
And one bug it reproduced on its first working run: vgpud polls the used ring,
so it registered no interrupt handler, and a virtio device interrupts on every
completion. The storm detector said so immediately --
irq 11: 77780 interrupts/second -- a device on this line is not
acknowledging it. handler 'e1000' is attached
-- naming the line, the rate and the neighbour it was drowning. One line fixes
it (VRING_AVAIL_F_NO_INTERRUPT before the queue is enabled), and that detector
was worth every minute it cost.
include/virtio.h moved out of the driver directory. Its own comment said it
should when a second reader appeared; one has.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VQ7Qx8E1q1M1bbCq8QLHS2
This commit is contained in:
parent
72074a960e
commit
ea68ef4b54
12 changed files with 799 additions and 9 deletions
|
|
@ -71,6 +71,9 @@ struct pci_dev {
|
|||
uint8 header_type;
|
||||
struct pci_bar bar[6];
|
||||
const char *driver; // name of whatever claimed it, or 0
|
||||
// The driver itself, so it can be asked to release the device. The name
|
||||
// alone cannot be called.
|
||||
const struct pci_driver *drv;
|
||||
};
|
||||
|
||||
// One row of a driver's match table. Terminate the table with a row whose
|
||||
|
|
@ -116,4 +119,17 @@ struct pci_driver {
|
|||
// Without this the second card of the same model is either refused or
|
||||
// silently shares the first one's registers.
|
||||
void (*attached)(struct pci_dev *, struct device *);
|
||||
// Give the device up, so a userspace driver can take it.
|
||||
//
|
||||
// docs/plan/hybrid.md is built on the kernel *handing over* a device
|
||||
// rather than a process wrestling it away: two drivers writing one set of
|
||||
// registers is not a subtle failure, it is hardware that appears to have
|
||||
// started lying. So the transfer is the incumbent's decision, and this is
|
||||
// where it is made.
|
||||
//
|
||||
// A driver that implements this must leave the device in a state the next
|
||||
// one can start from, and must stop touching it. A driver that does not
|
||||
// implement it keeps its device: refusing is always safe, and for anything
|
||||
// on the path to a shell it is also correct.
|
||||
int (*release)(struct pci_dev *);
|
||||
};
|
||||
|
|
|
|||
Loading…
Reference in a new issue