virtio_console: Honour tty input flow control

[kfv]

Summary

vtcon_port_in() ignored ttydisc_rint() failing once the tty
input queue was full, so input not yet read was lost: of a
4 MiB paste, about 2 KB arrived.

Hold the receive buffer back from the host instead, with
receive interrupts disabled, so the host stops sending until
tsw_inwakeup reports room, and resume where the tty stopped
taking input.

PR: 299244
Reported by: David 'equinox' Lamparter <[e-mail]>

[fuz]

I wonder if this has deadlock potential if due to error the terminal never asserts that it is ready to receive more.

sys/dev/virtio/console/virtio_console.c

257

Why do you use uint32_t here? I don't quite get it. If it's supposed to be a buffer length or index, size_t seems more appropriate.

[kfv]

In D60897#1397156, @fuz wrote:

I wonder if this has deadlock potential if due to error the terminal never asserts that it is ready to receive more.

Nothing in the kernel is blocked. While input is held, no thread sleeps, spins, or holds a lock waiting for the wakeup; the port just records which buffer it's holding and disables its receive interrupts. The interrupt thread returns and other ports carry on, so a missing wakeup can't deadlock anything.

sys/dev/virtio/console/virtio_console.c

257

virtqueue_dequeue() reports the length as a uint32_t, and the receive path uses it as such. You're right about size_t, and I'd normally go with it too, but IMHO keeping uint32_t for now is preferable, as it matches the virtqueue interface and the code around it.

[fuz]

Ok, that clears it up.
Please once again seek external review.
Approved commit once you have obtained it.

sys/dev/virtio/console/virtio_console.c

257

Weird design, but fine with me then.