virtio_console: Make the transmit path usable without the tty lock

[kfv]

Summary

vtcon_port_out() spun in virtqueue_poll() under the tty
mutex until the host completed the buffer, which a reset
device never does; detaching while a process was writing
to a port thus deadlocked, with the writer spinning and
detach waiting for its mutex. Stop transmitting, control
messages included, before the device is reset at detach
or shutdown.

Also, serialise each port's virtqueues with a spin mutex
and keep the transmit buffer in the per-port softc where
it outlives both the call and the port, so a system
console can transmit where the tty mutex cannot be taken.

[markj]

Also, serialise each port's virtqueues with a spin mutex
and keep the transmit buffer in the per-port softc where
it outlives both the call and the port, so a system
console can transmit where the tty mutex cannot be taken.

Why exactly does it need to be a spin mutex? Are you planning to define CONSOLE_DRIVER methods?

[kfv]

No, not really. It's for the console patch following in the series. That registers via cnadd()​ once the device is up (and the device doesn't exist at cninit()​ yet, so CONSOLE_DRIVER​ won't do), and its cn_putc()​/cn_getc()​ run under cnputs_mtx​ and in ddb/panic, so they cannot take the tty mutex. The deadlock fix alone doesn't strictly need the spin mutex, though; I just didn't want to rework the tx path twice. Happy to move it into the console patch if you’d rather keep this one minimal.

[kfv]

Drop redundant reference to prior behaviour

[kfv]

Reclaim transmit buffers and stop TX before disabling interrupts